I have a confession to make, ZTIWindowsUpdate.wsf was written by me, it’s my fault. When it works, it’s the biggest time saver for getting my machines up to date, when it’s not working, yes even I get frustrated. It was designed to fill problem of mine and still has some advantages for the right customers.

I wrote it back in 2007 when I was working for Microsoft IT. At the time, Microsoft IT didn’t have a good Update/Patching story, there were some tools that ran occasionally as part of Group Policy, but it was hard to tell if a given machine was up to date, and what the correct manifest of patches for a given machine were. I was setting up a Litetouch deployment server and wanted to ensure that each machine was up to date when litetouch was done.

ZITWindowsUpdate.wsf was designed to fulfill a specific task: Update the local machine to the latest Updates/Patches/Drivers from Windows Update (WU), Microsoft Update (MU), or a WSUS server.

When the script works, its great. Most of my Dell and HP test machines have great Windows Update Driver support, so I have to spend less time updating my MDT 2010 Out-Of-Box driver folder with the latest drivers. I also don’t have to spend too much time staying up to date on the latest patches from Microsoft (hello patch Tuesday). The script does a good job downloading the latest/greatest patches from Microsoft.

However, things are not always perfect, and it does require some work once in a while. This might be due to new packages that don’t install properly, or other problems.

Most of the changes to ZTIWindowsUpdate.wsf between MDT 2008 and MDT 2010 were changes to improve the robustness of the system if the package failed to install.

One example was a specific patch from Windows Update that would try to install, and fail. However it reported back to the system that it passed. The script would keep retrying, and get into an infinite loop. We added some better logic to ensure that ZTIWindowsUpdate would not get into those kinds of infinite loops.

By default, ZTIWindowsUpdate.wsf will install everything from the WU/MU servers. There are some exceptions:

• If the package says that it “can” request user input, then we skip over the update. ZTIWindowsUpdate.wsf should be fully automated, and User Input could break automation. I added this primarily for IE7 and IE8 updates. So be sure you have IE8 install packages elsewhere if you require IE8.
• We skip Windows Vista and Windows 7 Ultimate “Language Pack” files. It’s just too much data to download.
• We can also skip packages for a specific KB article, or by Package ID.

Manually Excluding Updates

Occasionally you may come across cases where you need to exclude specific packages from installing on ZTIWindowsUpdate.wsf.

First step is to find the bdd.log or ZTIWindowsUpdate.log file generated by your test machine. We need the log files to know which Update ID numbers to exclude. While Microsoft Deployment is running, the log will be located at c:\minint\smsosd\osdlogs, however after the installation has finished, the logs could be uploaded to your SLShare Log Share, or to c:\windows\temp\deploymentlogs.

At the start of the log there will be some connection/diagnostic information. ZTIWindowsUpdate.wsf needs to connect to Microsoft Servers to ensure that the runtime binaries are up to date (yes, even Windows Update needs updating). You’ll want to look for the line “Start Search…”, then we see a list of packages:

Start Search...  INSTALL - d49c3450-6646-4fbc-9e67-da7947bf3f13 -
Update for Microsoft Office Outlook 2007 Junk Email Filter (KB974810)   
  SKIP  - 254a9c2e-0431-4a37-b977-f1652d9d4b4d -
Windows Malicious Software Removal Tool x64 - October 2009 (KB890830)   

Here we see a list of all the relevant packages Windows Update has returned for this machine.

• First column is either “INSTALL” or “SKIP”, all items marked “INSTALL” are to be installed, all items marked “SKIP” are *not* going to be installed.
• Then we see a 36 character GUID – This is the unique ID For the package. Please note that x86 and x64 packages of the same fix may have different ID’s.
• A short description of the fix.
• And sometimes we may have also have the associated Microsoft KB article.

Once you have identified the package you wish to exclude in the future, you can add the ID or the KB article in your customsettings.ini file. Test the install again to ensure that all packages are marked as “SKIP” in the log file, and you are good to go.

Here are some examples of ID’s that I included recently in my customsettings.ini file.

WUMU_ExcludeKB1 = 941160  ; Ultimate Extras WUMU_ExcludeKB2 = 928416  ; .NET Framework 3.0 WUMU_ExcludeKB3 = 955020  ; Add En/De words to dictionary WUMU_ExcludeKB4 = 905474  ; Windows Genuine Advantage ; Bad AuthenTec Driver, blocks installation.
WUMU_ExcludeID001 = 3a130260-44f8-4769-9b9e-57c3bbd4ce45

Other

One trick I use often when testing ZTIWindowsUpdate.wsf directly is to use the /query flag.

net use z: \\server\deploymentshare$
cd /d z:\scripts
cscript \ztiwindowsupdate.wsf /query

When you specify the flag, it will only query windows update, it won’t download or install anything. This is helpful if you need to test your WUMU_ExcludeKB or WUMU_ExcludeID entries to see if they match.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group