Nobody knows more about IT than our own Mitch Tulloch. (Actually, nobody knows more about everything than Mitch Tulloch, but that’s another story!) In this article from February, Mitch walks us through the various ways to deploy fully patched Windows 10 computers — kind of the holy grail for IT admins. Mitch’s simple solutions to this perplexing problem made this article a sure bet to be included in our 20 Best for 2020 series.
I know it’s not very politically correct these days, but it’s been said that there is more than one way to skin a cat. In other words, there are often many different ways to perform a task or accomplish some goal. Well, the same is usually true when it comes to almost anything when you’re working in the tech field, including deploying Windows 10 computers. Windows deployment is something I’ve been involved with since the early days of personal computers. In the old days, we would just put the setup program on a network share and run it from there. Third-party tools like Ghost made our work as IT professionals even easier because they allowed us to capture an image of an existing Windows installation and clone (copy) it onto the disk drive of a bare-metal PC. Of course, we had to use Sysprep on it afterward to ensure our cloned PC was unique so it could communicate with other PCs already on our network. Then Microsoft released its Business Desktop Deployment (BDD), which became Microsoft Deployment Toolkit (MDT) and made deploying Windows computers a breeze. Integrating MDT with System Center Configuration Manager (SCCM or ConfigMgr) created an even more powerful — but also more complex — solution for deploying Windows in enterprise environments. Fast-forward to today, however, and there are a plethora (defined as a large or excessive amount) of tools and solutions for getting Windows 10 onto the PCs and other end-user computing devices in your environment. On the Microsoft side, there’s the constant push towards the cloud expressed in Windows AutoPilot. And numerous third-party solutions are now available for deploying Windows.
So, given this vast choice of deployment solutions and methodologies now available, which is best? The answer is, of course, it depends. What’s best for you may not be what’s best for others because what’s best for me really means what I feel most comfortable with. And what you’re comfortable with depends on what you’re used to using, how much you like to learn new things, how much pressure you’re under in your job, and so on.
Since I’m a packrat, I’m always collecting information from other IT pros on which tool is best for this, what method is good for doing that, and so on. And one of my Evernote notebooks is full of snippets from various sources describing different ways of deploying Windows 10 PCs. And not just deploying them, but deploying them fully patched, so they’re ready to be dropped onto the network and assigned to users. Since many of our readers who work in IT have been and will continue to be involved with deploying Windows, I thought I’d share some of the snippets from my notebook — cleaned up, of course, so they are hopefully understandable. And if after reading this article you’d like to share in brief your own approach for deploying fully-patched Windows PCs, feel free to do so using the comments feature at the bottom of this article.
So without further ado — and in no particular order — here are several ways I’ve learned how other IT pros have been deploying Windows PCs fully patched. For this article, I’ll focus only on methods that utilize Microsoft tools and solutions.
Method #538
This approach is to use OSDBuilder to service your WIM file. OSDBuilder is a PowerShell module that lets you perform Offline Servicing to a Windows operating system image, and you can use it to update your WIM file. Then once you’ve serviced your image, you can add it to MDT along with apps and drivers and then deploy it using a task sequence, either in MDT alone or with SCCM for enterprise environments.
There’s an excellent walkthrough on this on the site ModernDeployment, and I encourage IT pros who struggle with deploying Windows 10 to walk through this tutorial carefully as you can learn a lot by reading it (and by trying out the procedures in your lab environment).
Two tips concerning this approach that were shared with me by a colleague who learned about them from someone else were to be sure to use Modern Driver and BIOS management as part of your OSD task sequence and to have a separate task sequence for updating existing devices with drivers and BIOS.
One limitation of OSDBuilder needs to be mentioned, however, and that’s that OSDBuilder can’t be used to patch Microsoft Office (at least the locally deployed version). Of course, if you give in to Microsoft’s gentle nudge (lol) and switch from Office 2016 to Office 365, then you don’t have to worry about this.
Method #812
This is a modified version of the OSDBuilder approach in Method #633 that involves rerunning OSDBuilder every few months to patch your WIM file and then use SCCM with OSD to deploy your WIM file as a plain vanilla image onto target systems. At that point, you can run a PowerShell script that cleans up any unwanted Windows Store apps from your image, and you can use WSUS to update the systems with any patches released since the last time you ran OSDBuilder. And if you’re using SCCM, you can configure it to uninstall any of the apps you don’t want during the deployment.
The problem with this approach is that it looks like Microsoft is planning to phase out the Windows Store for Business (WSfB), as Mary Jo Foley recently reported. If that’s the case, then this approach to deploying Windows may need to be reconsidered, and it also highlights the difficult IT pros are having with Windows these days as Microsoft keeps making changes that can affect those customers who most dislike change: large enterprise customers. And not only that, ever since Windows 10 was released five years ago, Microsoft kept changing which apps were installed by default, which made upgrading Windows 10 versions a nightmare for organizations that wanted to lock down which apps users had on their machines.
Method #49
Yes, some people are still using “fat images” to deploy Windows 10 using MDT alone or with Windows Deployment Services running on Windows Server. System builders often use this approach and keep multiple WIM files for different customers or sites. MDT by itself has pretty good driver management, and you can set up a task sequence to update a target PC as part of the installation process.
Method #666
And finally, here’s a snippet that a colleague copied from some message board somewhere and forwarded it over to me and which I’m including here as-is with only slight reformatting. Note that the approach described here does not involve using either MDT or SCCM for performing your deployment:
- Start with ISO image
- Put in audit mode
- Install all needed drivers
- Install user apps
- Install all needed patches
- Capture Image using DISM (Pre-Sysprep)
- Generalize with unattended XML
- Capture Image using DISM (Post-Sysprep)
- Apply image using DISM
- Run a bat file to fix issues that 1703 introduced
- Add to domain
- Apply Group Policies to set Startup tiles, lockdown start menu, and generally screw up Windows 10
I don’t know who came up with this particular method, but it sounds like the simplest (and therefore best) approach for OCD-brained people like myself.
Featured image: Shutterstock
