This blog post was shared with me by a colleague of mine, Daniel Dorner, a Microsoft Premier Field Engineer. It’s a really an interesting one because it highlights the creativity of my colleagues - a very, very broad range of personalities that have one thing in common: an absolute dedication to customer's success.
Automated reference image creation became common as IT professionals use tools like Microsoft Deployment Toolkit or System Center Configuration Manager. In most cases, creating a Windows reference image is fairly straightforward if you follow established best practices. However, there are still issues out there that may catch you off guard and you will suffer the consequences.
It’s been a busy couple of weeks for me, so I’m slowly going through a backlog of things to cover. The push to get modern continues with the third part of my series on automating the process of transitioning from BIOS to UEFI using MDT. Today's blog post discusses the process of configuring BIOS settings on supported Dell Inc. enterprise systems.
This is the second post in my series that explores one of the most common questions I’ve been asked from folks who are migrating to Windows 10: "How do I go about transitioning from BIOS to UEFI?". So naturally, I’m addressing this question. This time, I am going to discuss automating firmware configuration on supported HP (Hewlett-Packard) notebook, desktop, and workstation models. Now, it's not as if it's been no-man's-land before. I am fully aware that there are blogs out there that talk about doing this kind of thing and I’ve tried a few of the solutions with various rates of success. Still, the feedback I've been getting over the past few weeks has been that I should share my approach when working with the Microsoft Deployment Toolkit (MDT), so, here's my attempt to do precisely that.
This article is the first blog post in a series I'll write over the coming days that will provide a comprehensive overview that explains how you can automate the process of transitioning from BIOS to UEFI during "wipe-and-load" OS deployment scenario. To be able to migrate from BIOS to UEFI effectively you need to understand how to configure firmware settings, such as secure boot, legacy support, and TPM device configuration, as well as how to use the MBR2GPT tool. Unfortunately, though it seems like a relatively straightforward process when using Microsoft Deployment Toolkit, based on questions I received as well as threads posted on TechNet over the past few weeks, there is still some confusion around this in the Windows technical community. Converting a device to UEFI comes with quite a few benefits including the ability to make full use of Windows 10 modern security features, so I thought it would be worth taking a few minutes to share my approach to dealing with BIOS to UEFI conversions.
My customers often send me exciting cases. This particular one is especially interesting because it is common in infrastructures that use "Local Administrator Password Solution" (LAPS) for password management. LAPS, which I can't recommend highly enough, provides management of common local administrator account by setting a different, random password on every managed domain-joined computer. The case opened when a customer contacted me a few weeks ago reporting that they experienced issues when re-installing computers using Microsoft Deployment Toolkit: after OS deployment, LAPS didn't update the local administrator password which in turn significantly increased the risk of lateral escalation (Pass-the-Hash (PtH)) that results when the same administrative local account and password combination is used. Given the importance of the customer, I immediately sat down to investigate.
Continuing the theme of focusing on disk-related cases (yesterday I posted an article detailing how to fix the "Verify BCDBootEx" step failing on HP ProDesk 600 MT G3 systems), this post showcases yet another reason why you should stop deploying systems in Legacy mode. It also shows how a little time spent on reviewing log files to get a couple of clues can quickly lead to a solution.
If you’ve read any of my tweets, you know that I emphasize how Microsoft Deployment Toolkit and ConfigMgr are powerful OS deployment tools which allow a high grade of customization. This blog post is another demonstration of MDT flexibility. It also shows how a PowerShell script can quickly lead to a solution.
As my regular blog readers will be aware (yes, all three of you), there is something increasingly traditional about me writing about my customer engagements and today should be no different. With the new way of building, deploying, and servicing OS introduced with Windows 10 (Windows as a Service a.k.a. Hustle as a Service) I often kick off customer engagements with a workshop for IT professionals addressing biggest benefits of adopting Windows 10 and detailing comprehensive set of intelligent security solutions which allow organizations to protect against security threats and to better protect user and company data against sophisticated attacks thus allowing them to align themselves with the GDPR requirements. By outlining these benefits heads on, I can often persuade my customers to adopt a comprehensive set of advanced security capabilities including, but not limited to Credential Guard, Windows Information Protection, Windows Defender ATP and BitLocker.
A few days ago I stumbled upon a question on the Microsoft Deployment Toolkit (MDT) forum where a user asked for guidance on how to install support for additional keyboard layouts using MDT. This post explains how you can add additional keyboards in Windows during OSD.
Automated OS deployment became common as IT professionals install systems using tools like Microsoft Deployment Toolkit or System Center Configuration Manager. In most cases, deploying Windows OS is fairly straightforward if you follow established best practices. However, there are still issues out there that may catch you off guard and you will suffer the consequences of task sequences misbehaving.
These days most of my blog posts start off with a question from a customer. At least, this time around the question was relatively simple: How do you sideload a modern application into Windows 10? If you have followed Windows 10 development closely, then you have probably heard that Microsoft Deployment Toolkit has the ability to sideload apps, assuming you have the necessary source files handy. But what if you are using a third-party tool to deploy applications?
Quite a few of my blog posts start off with a customer engagement - this one is no different. This week I am implementing a LoginVSI Automation Machine powered RDS infrastructure at a large automotive company. This process involves packaging quite a few applications including Dell Active Roles 7.1 MMC Interface, a single, intuitive tool designed for comprehensive privileged account management in Active Directory and Azure Active Directory. Packaging Dell Active Roles console is *SUPER* easy with Login VSI Automation Machine because it comes in an MSI package, so all you need to do is simply importing the MSI file into the media repository, creating the corresponding package and adding Install MSI action item. However, when opening the Dell Active Roles 7.1 console, the following error reared its ugly head: "MMC could not create the snap-in. The snap-in might not have been installed correctly.", followed by "CLSID: {D50F5BB7-337F-4A59-8797-BDA0B7DC1DF0}".
The other day, as I was working with a customer on improving and optimizing his Windows 10 image, one of IT technicians asked if it would be possible to import a wireless network profile to devices during the OS deployment without resorting to Group Policies (I am sure they had good reasons). By deploying these settings, the customer hoped to minimize the effort that end users require to connect to the corporate wireless network.