Windows deployment: Where it was, where it is now, where it’s heading

The tools and procedures used for Windows deployment have gone through many changes over the years. And since the arrival of Windows 10, it has continued to evolve. I still remember as early as 2004 how Microsoft was starting to experiment with developing light and zero-touch deployment methodologies that made use of such tools as the Sysprep utility, the User State Migration Tool (USMT), Systems Management Server (SMS), and SQL Server. Microsoft initially promoted using these tools together with scripts, templates, and documentation that they called the Business Desktop Deployment (BDD) Solution Accelerator (SA). BDD then went through several revisions until in 2007 it was rechristened the Microsoft Deployment SA, which was later called the Microsoft Deployment Toolkit (MDT), which could integrate with Microsoft’s SMS successor, System Center Configuration Manager (SCCM) 2007, with Windows Deployment Services, and with the Windows Automated Installation Kit (WAIK) to provide a single solution for creating and deploying Windows images for Windows XP, Windows Vista, and Windows Server 2003. MDT has itself since then gone through many revisions to enhance its capabilities and support each new version of Windows, and SCCM has also gone through multiple new releases.

So where does that leave us today? Are the tools and processes we used as administrators to create and deploy Windows 7 images still basically the same in the last several years, which have seen Windows 10 v. 1507, 1511, 1607, 1703, 1709, and now v.1803? Or has Windows deployment fundamentally changed in the Windows 10 era? To get an idea of where Windows deployment is at present and where it might be heading in the future, I reached out recently and talked with Keith Garner, who formerly worked for Microsoft and is now a consultant based out of the Seattle area. If anybody knows his stuff about Windows deployment, it’s Keith since until recently he was working closely on the Microsoft Deployment Toolkit as a developer, technical program manager, and subject matter expert. Keith’s Consulting Blog can be found at and you can follow him on Twitter at @KeithGa1.

OEM scenario: The future of Windows deployment

Windows deployment

If a company wants to really get ahead of the Windows deployment game they should adopt the OEM scenario that Keith recommends for provisioning new Windows 10 machines. “This is the future of PC provisioning,” he says, “and Windows AutoPilot is a variation of this method.” I asked Keith how does this work and he explained as follows: “The machine comes from the OEM with Windows 10 Professional and all the drivers preinstalled.” Windows 10 Pro? What about all the junkware OEMs typically install on those systems? “If you are paranoid about malware/adware being in the image, demand that the OEM use only Microsoft Signature Editions,” Keith says. Like Lenovo does for example with its ThinkPad series of laptops and PCs. Keith continues by saying, “Once the machine is on site, have the user join to your domain (or other MDM). The MDM will apply policies/settings, and then we can apply a SKU Transform from Pro to Windows 10 Enterprise VL. We then install any required applications, based on the user or machine. Additionally, we may need to upgrade the OS to the latest version, say from 1703 to 1709, and/or install the latest cumulative update (CU). We’re done!” That does sound like a good way to provision new Windows 10 machines in your environment.

Upgrade/servicing scenario: The present

But what if you already have Windows 10 deployed and you want to keep the machines functional? “Windows 10 ongoing,” says Keith, “means you have a fully functional Windows 10 machine with all the required apps/drivers/files/settings installed, and you keep the machine up to date using Windows 10 in-place upgrades, cumulative updates, updated drivers from the OEM, and updated apps from the ISVs. This process will be ongoing throughout the life of the machine moving forward. Users can keep their machines up to date using Windows Update, or if they are domain-joined from a centralized management tool like SCCM.” What confuses many administrators who deployed previous versions of Microsoft Windows like Windows 7 and Windows 8.1 is that MDT is not involved in the Windows 10 ongoing Windows deployment scenario. “Note that you wouldn’t use MDT to refresh the machine like we did when moving from Windows 7 to Windows 8.1 with USMT. Instead, when going from one Windows 10 version to another, we can upgrade settings, files, apps and drivers in-place. But this is where it starts to get tricky because we can not use a Windows 10 Image that has been Sysprepped.” Why not? I asked him, and Keith replied: “What happens, for example, if the old OS has Adobe Reader 10.5, and the image has 10.4? Which one wins? The Windows team decided to give up and not allow any unknown stuff in the image, only stuff on the old OS wins.”

Standard imaging: The past

Windows deployment

So does this mean everything we learned in the past about building Windows images with MDT should be discarded? “Recall,” says Keith, “that one of the challenges of MDT is that it really doesn’t do OS Servicing — that’s where WSUS and SCCM come into place. MDT works fine, however, for break fix/new computer installation. So if you already have an existing imaging process that can get a machine to 90 percent functionality today, with OS, settings, apps, and drivers, then you may choose to skip the OEM scenario described above for now. After all, why rock the boat? And you can use Sysprep to install some of your more common applications that are used by most machines and take a while to install, such as Office ProPlus. But when you’re finished the machine should go straight into the upgrade/servicing bucket described above and be updated with the latest CU Drivers and apps.” That’s not the only problem, however. “Another problem with the old model of corporate OS installation is that it really isn’t keeping up with the modern Windows 10 release cadence of a new OS, every six months, like clockwork. No rest for the weary! And for many companies, when Microsoft comes out with a new OS, they may doddle around for three months before getting into serious testing and broad rollout. But they are already too late. Best to get into the habit now of continuous rollouts of OS updates, CUs, drivers, and apps.”

Everything is changing

I recently read The World of Yesterday, the memoir of Austrian writer Stefan Zweig. Like Zweig, I sometimes feel that the era from Windows XP to Windows 7 was a kind of Golden Age where deployment tools were simple to learn and use. Now with Windows 10, everything has begun to change. Maybe I should sign up for that deployment workshop being offered next month at the Grand Budapest Hotel.

3 thoughts on “Windows deployment: Where it was, where it is now, where it’s heading”

  1. “Best to get into the habit now of continuous rollouts of OS updates, CUs, drivers, and apps.”

    I agree.
    Why miss out on all the new juicy compatibility problems that come with every new Windows 10 release and that takes three months to fix?

  2. I’m surprised there was nothing about deploying Windows 10 to computers currently running Windows 7. Surely we’re not the only company that still hasn’t done that yet?

    1. Most large companies I’ve had contact with have already either begun their 7>10 migrations or have already finished. The recommendations in this article are forward-looking.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top