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!
I for one can appreciate snarkiness and sarcasm. With that said, I was disappointed that this did not give me a list of don’ts, but rather a confusing list of scenarios.
I can imagine you have a lot of information that would be very productive with some added humor – sad that it did not come across in a better format.
I guess everyone’s sense of humor is different 😉
Not too many Win10 deployment articles make me laugh, thanks!
same here..i was actually confused about the scenarios…couldn’t figure out which one is do’s and which one is don’ts
Great Post – but can you make it in usual format.. This sarcasm confusing me!
I don’t agree with this post. Some of these suggestions are okay, but most are not. As a Desktop Architect for years supporting environments as small as 500 devices to as large as 12,000 spread throughout the country, this list will set you up for failure. This list may be okay for a buildlab or for a VERY small environment. Here just a couple things that I believe are wrong:
1) Better yet, why not forgo creating a reference image entirely – I have never heard of anyone creating a reference image in a large environment. Always user a thin image. “Golden Images” are a thing of the past and for environments that are small and never changing.
2) Always leave the .NET Framework out of your reference image. Yes, always leave this out. For 3.5-/+ you can use a simple PowerShell command to install and enable this during your task sequence. Why spend time doing this in an archaic Thick Image?
3) Always, always, always add the password for your Administrator account to your Bootstrap.ini – this is incredibly silly because you also mention it is a bad idea to use a ServiceAccount… make up your mind
4) You can use your build share for your production share when you’re ready to start deploying your reference image – for a lot of companies this is a perfect fine idea since only a few people will be imaging computers anyways. And if you’re a good admin with security in place, like service accounts, who cares?
5) Windows Deployment Services (WDS) should never be used when deploying Windows 10 with MDT – this is probably the most egregious one on the list. Makes sense you later bad mouth SCCM, I guess. But for your viewers – you only need WDS if you plan to PXE boot your devices. Some offices only image in a “build lab” so you can just boot from a flash and pull a Win10 OS if you’d like. WDS has some advantages, but when you combine this with your other silly suggestions it doesn’t make much sense. If you’re supporting multiple physical sites you would need Distribution Points unless you want to be sending gigs of bandwidth… but maybe this isn’t a concern?
Would be a good article if you added notes and reasoning behind your statement. I would assume you have not managed the desktop space in quite some time.
Thanks for the feedback
#ObviousSarcasmIsNotObvious
TOO funny! At first, I was annoyed because I was expecting this to be useful information for my W10 build image…after seeing the “advice”, I saw where this article was going – and LMAO!!
For others who didn’t like it – chill out – you need to calm down and take things less seriously once in a while. …life is short – enjoy it! (and go find another article about W10 deployment!)
This is difficult to follow because it’s unclear at certain points whether or not your suggestions are genuine. What a shame.