I’ve always been a fan of the thinnest image possible. Taking that to an extreme, that means using the original image straight off the Microsoft media. But over time if you did this you’d find that the time required to apply patches to that image becomes unmanageable. (Case in point: I started up a new laptop for the first time with an OEM-installed image that had hooks to require all patches be applied before first logon. It took three hours for that to happen.)
I’ve also been a fan of doing “just in time” patching, which is something that MDT can do too: Instead of patching the image in advance, you can inject updates offline after the image has been applied to the disk but before it boots for the first time. That does often improve the time required, but it doesn’t eliminate it – it adds time when initially injecting the updates offline, and then more time on first boot as the “online actions” for those “offline patches” are completed (you’ll see the messages on the screen during the first boot showing a percentage complete while this is happening).
So reading between the lines, that means I would suggest always creating your own master image containing at least all the current service packs and patches. (Don’t try to install the OS service pack yourself – just download “slipstreamed” media from the Microsoft licensing website, as that’s the ultimate time-saving technique.) So how should you do this? Well, there are a few ways:
Not surprisingly, MDT 2010 Lite Touch provides a way to implement my preferred method above – and actually multiple methods that can be used. Let’s go through those methods.
This is the easy way, as long as you have good internet bandwidth (all updates are downloaded from the internet) and a direct path to these downloads (as we don’t really support proxy servers in the MDT task sequence), and always want to install all critical updates. (We skip language packs, drivers, and service packs by default, and you can exclude additional updates, but the exclusion process requires a little work.)
To use this method, all you need to do is search your task sequence for the following steps:
Enable both of them, and then build a new image – that’s all there is to it. (Why are there two steps you ask? Well, the first might be required in order for the subsequent application installs to complete; the second might be required to patch the applications, e.g. Office, after it’s installed. If the second step doesn’t need to install any additional patches, it won’t take very long.)
To give you better control over patched put into your image, you may only want to install approved updates. If you are using Windows Server Update Services (WSUS), then you already have such an approval mechanism in place, all you need to do is tell the task sequence to talk to WSUS instead of going to the internet. This is pretty simple too:
Make sure that you have configured WSUS to install updates on unknown computers, because when building a reference computer it is indeed unknown to WSUS at the point the task sequence is executing.
This one is probably the most work, primarily because you need to manually download all the updates that you want to install, and it only works for OS updates (as they are the only ones that can be injected offline). The steps required:
When the task sequence runs, the “Apply Patches” will identify all the updates for the OS and platform being deployed, download them to the client, and update the unattend.xml to inject them. (SETUP.EXE will later call DISM.EXE to do the actual injection after the image has been extracted and applied to the hard drive.) If you want to apply a particular set of patches, you can configure a selection profile with one or more folders containing those updates, then configure the “Apply Patches” step to use that selection profile.
Well, that’s a completely different discussion. Some people do a new image monthly (and probably don’t do much testing on that image each time they recreate it). Some do it every few months. Some do it once a year. You just need to balance the efforts required to build it (easy), test it (not quite so easy), and distribute it (can be really painful) against the added time of applying some updates later.
You can actually use any (or all) of the above methods in that “later” deployment task sequence too:
Some additional links that might be useful:
Windows Update in MDT 2010 « Xtreme Deployment
Approving Windows Updates in an MDT 2010 Standalone Environment
What if you WSUS server in integrated with SCCM? How would you recommend doing the patches.
If building or deploying with ConfigMgr, you would want to use the built-in "Install Updates" ConfigMgr task to install all the needed updates.
If you are talking about using the ConfigMgr SUP (WSUS server) to deliver updates to Lite Touch, that's a little trickier. See myitforum.com/.../publishing-a-configmgr-update-list-to-wsus-for-use-with-microsoft-deployment-toolkit-mdt-lite-touch-builds.aspx for one possibility.
Excellent article! I often do a combination depending on how many times I will deploy. However, I'm having some problems adding IE9 update to the Deployment Share. I've read Microsoft's article technet.microsoft.com/.../ff986260.aspx and they talk about the MSU file but no matter which file I try to download, I only end up with an .exe file and when I extract it with /x I get a .CAB file. Any tips?
Okay I'm just starting to learn how to use MDT but I'm a little lost as to how to get a MSU file. Every patch I've tried to download and extract just has another exe file or just a dll. And even if I was able to get a MSU how to I add it to the MDT task sequence? I see the "Apply Patch" step but not sure how to add patches to that.
I have run through this a couple times and had nothing but issues with the just in time patch injection within MDT. IE9 worked a treat however I then tried to import all the post SP1 patches for Win7 and it would fail the installer during deployment. Logging gave some bizarre errors about folders on C: already existing and cause it couldn't create them and in the end just ditched them and left just IE9 and doing the rest with WSUS.
Would love to pre-install all the patches though.
I've run into the same thing too. Why is it so difficult to add the patches to the image and then redeploy. I've got inconsistent result when adding the patches and then it totally blows up when I try to install.
I attended your MDT seesion in New Orleans and since then have been trying to find the right time to work on building a VM template based on MDT image. I now have that time but I can't get past what I've run into above. I have successfully built an W2K8r2 SP1 image with IE9. I've gone through the patching process, identified and downloaded the patches installed and injected those patches into my image. After creating a new ISO, I can't get it to install at all. Is there a problem with my process? Also, can you tell me where to find the logs of the installation process?
how to cature image and deploy wid MDT 2010 what is the process from starting from instaletion pulling , capturing to deploying image on other users
So, trying to integrate patches (MSU) files as packages, seems to give a lot of injection errors with DISM during update deployment share. Seems that certain ones fail consistently and then i get an offline servicing error. I guess i will have to fall back to just enabling the windows update step. OS deploy is Windows 7 SP1 ENT.
There are definitely some updates that can't be injected offline. Unfortunately, there isn't a list that says what they are, so finding them is a "trial-and-error" process.
There are others that might not be applicable - those won't cause any issues, just a little extra processing to figure out during the deployment that they aren't needed.
You can build a selection profile that doesn't contain those (build a folder containing the ones you want, create a selection profile with that folder).