The not-to-do list: 25 ways to derail your Windows 10 deployment


I’ve worked with and written about Windows deployment a lot over the years. I even wrote a 29-part series of articles for WindowsNetworking.com (now TechGenix.com) called Deploying Windows 7, which was designed to help get people started with learning how to deploy Windows using the Microsoft Deployment Toolkit (MDT). I haven’t updated that series for Windows 10 because there are others out there who have done a better job in that regard, including Microsoft with its own helpful guidance on how to deploy Windows 10 with MDT. I’ve also helped write about OSD deployment using System Center in several of the free ebooks from Microsoft Press where I’m listed as being the Series Editor of the title.

But one thing I haven’t seen much of is a description of things you shouldn’t do when you try to deploy Windows 10. That’s what this article is about, and to make it more interesting I’ve framed my “recommendations” as ways you can send your deployment project off the rails should you for some reason decide that you want to. After all, who doesn’t love watching a train wreck on YouTube?

So, in light of the above, I’ve compiled the below list of things you shouldn’t do (framed as recommendations) when you want to deploy Windows 10 using MDT in your environment. The list has been compiled from my own experience and those of some of my colleagues, and it’s not meant to be complete or ordered in any fashion. It’s just a list of things you can do if you want to blow up your Windows 10 deployment project. Here goes…

Let’s derail our Windows 10 deployment: The list

Using an older version of MDT instead of the current one is a great way of getting frustrated right at the start of your Windows 10 deployment project!

For even more fun, use a different version of the Windows ADK than the version of Windows 10 you’re going to be deploying. I especially like to mix 1511 with 1703 which adds up to 3214, which is obviously the future as far as Windows 10 deployment goes.

Creating your Windows 10 reference image on a physical system is preferable to doing it in a virtual machine since you like dealing with puzzling hardware-related issues and garbage from driver packages you won’t need on your target systems.

Better yet, why not forgo creating a reference image entirely? That way you can stretch out the time it takes for you to complete your project and use up all the money your department has allocated for this purpose.

Configuring read permissions on the MDT deployment share for the user account you’re going to use for creating your build image is a great way of sending the image you create into Na-Na Land.

If you forget to add the full source Windows 10 setup files to your MDT deployment share you’ll have loads of fun trying to build your golden image!

Don’t forget to omit adding your applications and sample scripts to your MDT build lab share! After all, who needs applications anyway? Users can always write their company reports using Notepad.

The retail version of Microsoft Office is so much easier to deploy than the volume licensed version since that confusing Office Customization Tool won’t be available.

The last thing you want to do once you’ve built your reference image is to create a task sequence for capturing it and configure the task sequence to enable patching using your WSUS server. Patches are like Band-Aids, they’re sticky and messy and fall off when you take a shower or bath.


If for some reason you decide to build your reference image on a virtual machine with MDT, you better include every single device driver in the PC universe just in case!

Always leave the .NET Framework out of your reference image. It’s big and ugly and might take up too much space on the hard drives of your target systems, plus most applications today don’t use .NET anyway, right?

You should never update your boot image when you make a change to your Bootstrap.ini file.

It’s also a good idea to put all your Windows 10 deployment rules in Bootstrap.ini and leave CustomSettings.ini more or less empty. Why use two files when you can get by with only one?

Always, always, always add the password for your Administrator account to your Bootstrap.ini file so it can be read in plain text. After all, if you don’t write your Admin password down and you forget it, you’re toast!

Don’t bother updating your deployment share after you’ve finished configuring it, that’s only going to slow things down and your boss will get impatient.

Always run Sysprep at least three times on your reference image after you’ve created it.

You can use your build share for your production share when you’re ready to start deploying your reference image. Shares take disk space and you should always try and economize.

For security reasons you should use AppLocker to create a policy that prevents that nasty executable Dism.exe from running on your deployment machines.

It’s a waste of time to create a central repository for device drivers from different manufacturers like Lenovo, Dell, and HP since they all now use the same drivers for their devices. Besides, you’ve already added every known driver in the universe to that 2TB reference image you built, right?

Don’t add any drives for the Microsoft Surface Pro to your boot images. No one in your company can afford that machine anyway.


Windows Deployment Services (WDS) should never be used when deploying Windows 10 with MDT. Purchase a full System Center license for every seat in your environment instead.

Multicast deployment is a terrific option if you have enough network cables available to do it.

Performing an offline media deployment of Windows 10 is difficult to do since most of us leave our phones on all the time nowadays so we’re never actually offline.

If you are going to perform a UEFI-based deployment then you should build your reference image in a Generation 1 virtual machine on a Hyper-V host. That way the BIOS will be all messed up, which will leave you with the maximum opportunity for customization of your image.

And finally

The best deployments happen when you burn the Windows 10 ISO to DVD, pop it into the DVD drive of each company computer, and run Setup manually on each machine. Then, once Windows is installed you can download and install each application needed for each system. Why is this the best approach? Two reasons. First, you’ll probably need to buy portable USB DVD drives for each machine since modern systems often no longer include a built-in DVD drive. That way, once your Windows 10 deployment is finished, you can sell all the DVD drives on eBay and recoup some of the money you had to budget for your deployment project, which will make your Pointy-Haired Boss happy. The second reason why the good old manual installation approach is best is because it’ll take you all night at least to finish the deployment on a single floor of your building, which means you’ll need to order at least four pizzas each evening to keep you going!