Microsoft Deployment Toolkit has a built-in script designed to update images, with Microsoft Updates, during a Lite-Touch deployment. I’ve been meaning to write this article for a while now but the enormity of the topic has deterred me from seeing it through to completion. This post also applies to MDT 2010.
To be clear, this article does not relate to implementing a patch management strategy. It does however, demonstrate how to deploy fully patched machines during a Lite-Touch deployment. Also, how to create up-to-date reference images or deployment templates. Most organisations recreate their images on a regular basis to ensure that newly deployed machines do not require excessive patching after their initial deployment. This is usually to reduce the load on the WSUS server.
These are the techniques I use in my test-lab and enterprise Lite-Touch deployments to ensure Windows XP, Vista, 7 and 2008 server editions are fully patched at the time of deployment.
- Enabling updates within your Lite-Touch Deployments
- How does it work?
- Managing Lite-Touch Deployment updates in the Enterprise
- Skipping updates during your Lite-Touch Deployments
- Checking for updates only
The Windows Update task sequence steps are built into the standard operating system deployment templates but are disabled by default. To use them, simply edit your task sequence and un-tick the ‘Disable this step’ button. Now during your Lite-Touch deployments this Task Sequence Step will download all available updates automagically from Microsoft Update rebooting and resuming as needed.
The task sequence step is repeated post application installation. It can be useful to enable the Windows Update (Post application installation) step during deployments when you’re installing Microsoft Office 2010 or another product that can be patched using Microsoft Update.
The task sequence steps run a script called ZTIWindowsUpdate.wsf. The script uses the Windows Update Agent API to manage the downloading and installation of updates. All audit information is written to the ZTIWindowsUpdate.log file. If you find any unusual error codes in your log returned from the API (although I never have) you can compare the codes here. The script will also check and update the Windows Update Agent(WUA) as needed at the start.
In its default state, the ZTIWindowsUpdate.wsf script will connect to Microsoft Update then search for and download all available updates including Security Patches, Drivers, Browser Updates and Service Packs. This is essentially the same as opening the GUI and selecting check for updates.
Many corporate environments block Microsoft Update and have an internal Windows Server Update Services (WSUS) server. In these scenarios you can configure MDT to connect to your WSUS server and download the updates internally. This is done in the CustomSettings.ini file by adding a single line targeting the WSUS server as demonstrated in this example:
What this does is points the client to an internal WSUS server by creating the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer, "http: //ScriptimusWSUSServer", "REG_SZ" HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer, "ScriptimusWSUSServer", "REG_SZ"
Now, you may not want MDT to download all updates, for example, the latest Internet Explorer or the annoying Microsoft Browser Choice Screen update. In this case you can create an exclusion list using the customsettings.ini property WUMU_ExcludeID or WUMU_ExcludeKB. You can add as many of these lines as you like by incrementing a number at the end. In this example I use WUMU_ExcludeKB to exclude 3 windows updates.
WUMU_ExcludeKB001=976002 WUMU_ExcludeKB002=2267621 WUMU_ExcludeKB003=2434419
In the ZTIWIndowsUpdate.log file you can see that it has skipped over them without having installed them.
One final tip, is that you may wish to discover which updates are going to be applied during your deployment without actually downloading them. This is done by editing the task sequence step and adding the /query switch to the command line.
The results can be seen in the ZTIWindowsUpdate.log file. It will list which updates will be installed or skipped.