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:

  • Mount the existing WIM image and just inject the updates offline with DISM.  This is certainly doable, but there are three challenges:
    • The online actions for these updates will still take some time
    • It introduces a “human touch” into the process, unless you go through the effort of automating this to make it a repeatable process.
    • It only works for operating system updates.
  • Build a new image and install all the updates into that image before sysprepping and capturing the image using a completely automated process.  This is my preferred approach, because it’s a consistent process for any other type of update being made to the image.

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.

Install all updates from Microsoft Update directly

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:

  • Windows Update (Pre-Application Installation)
  • Windows Update (Post-Application Installation)

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.)

Install all updates approved on your WSUS server

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:

  • Enable the same “Windows Update” task sequence steps listed in the previous section (two of them).
  • Add an entry into the [Default] section of CustomSettings.ini that says:
    WsusServer=http://SERVERNAME:PORT
    where “SERVERNAME” is the fully-qualified name of your WSUS server and “PORT” is the port number that WSUS was configured to use (only needed if that is something other than port 80).

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.

Download all updates and import into your deployment share

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:

  • From the monthly security bulletin, or using a site such as http://catalog.update.microsoft.com, download all the updates which are typically packaged as MSU files.  (If they come down as executables, you’ll need to extract the MSU files from the executable.)
  • Import the MSU files into Deployment Workbench from the “OS Packages” node.  (This will extract a CAB file that is contained in the MSU file, since that’s the piece that gets installed offline.)

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.

How often should I do this, and what should I do in between?

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:

  • Enable the “Windows Update” steps in the deployment task sequence to download and install any updates released since the last image was created (from Microsoft Update or from WSUS if you set the WsusServer variable).
  • Download and import any new MSU files into Workbench (but keep these separate from all the ones in the image as MDT won’t know which are installed and which aren’t so it will download all of them and let DISM figure it out).

For more information

Some additional links that might be useful:

Windows Update in MDT 2010 « Xtreme Deployment

Approving Windows Updates in an MDT 2010 Standalone Environment