jump to navigation

Windows Update in MDT 2010 November 9, 2009

Posted by keithga in MDT 2010, Troubleshooting.

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


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 Garner is a Deployment Specialist with Xtreme Consulting Group


1. Amar - February 28, 2013

I’m trying to do a build and capture x64 but for some reason on the windows update step it takes an unusual amount of time to finish. I thought maybe because ZTIwindowsupdate.wsf was not pointed to our WSUS server but when I checked it was.

I need some advice, any sort of help would be appreciated.



2. cary@ualberta.ca - December 6, 2012

Not really sure who I would talk to about this but I am trying to use ztiwu without MDT and was wondering if i could just make a cu.ini with the excludes i want and put it in the same directory.

3. SCCM: Windows Updates for an XP Task Sequence | Windows Stuff That Your Dreams Dreamed Of - May 26, 2012

[…] This will run the MDT script ZTI windows update (ZTIWU) during your task sequence. ZTIWU will download and install most of the windows updates needed for your machine. During the process, ZTIWU will restart your computer as needed. Note that ZTIWU is configured to reject any updates that can accept user input (because SCCM will not display dialogue), so any updates that need user input will not install with ZTIWU. Beware that  this step can take a while. You can configure updates and packages that you want skipped, for information on how to do this check out this article at Xtreme Deployment: Windows Update in MDT 2010. […]

4. Martin - May 13, 2012

Thank you for writting this Blog: I am learning a lot.
I am having a adventure with MDT and ZTIWindowsUpdate.wsf I am attempting to image over the network. BUT my network segment is on the wrong end of a slow noisy DSL Link. I have managed to start an install, even completes the copy process and the file expand. BUT it fails the update. I suppect my network.
I have a copy of the MDT I can put on a external USB hard drive. I know I can change the BOOTSTRAP.INI to not point to the MDT server. But without going to where the MDT server is I do not know how to turn off ZTIWindowsUpdate.wsf.
My hope is that I can get the basic image on the computer the WUS will use BITS to pull the needed updates.

Any sugestions about troubleshooting and or disabling ZTIWindowsUpdate.wsf on a “copy” of the Deployroot?

Thank you,

5. Andrew - January 11, 2012

I know it’s old but thought this might be the best place for this.
In my initial build I notice ZTIWindowsUpdate tries to INSTALL KB2532531 2 times and has 4 more FOUND lines but it never quite finishes installing. I have to do this after the deployment.
It’s not a big deal and I haven’t troubleshot it – but there you go.

6. Brian - October 21, 2010

Hi Derek

What I did was just to add a script to the tasksequence that reset the regkey to 0 after ZTIWindowsUpdate.wsf has run.

oShell.RegWrite “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate”, 0, “REG_DWORD”.

I have a feeling that this error only accour if you make a custom image and import it into MDT. But im not sure.

7. Alan - July 13, 2010

How do you change the script to point to WSUS?

Stephan Schwarz - September 3, 2010

here’s an example of how to point the script to wsus when you’re using MDT2010 ( with or without update 1)

Go to the properties of you Deployment Share, and then open the rules tab, add the following line somewhere under the [Default] header.


examROAR - September 10, 2010

You use customsettings.ini to point to the WSUS server. Like this:

Dustin - March 17, 2011

Use the following setting in your CS.INI


8. Derek - April 10, 2010

Brian is right, i have this same issue. I’ve been pulling my hair out trying to figure out what it is. No matter what, if i enable the windows update task, after deployment is complete, you cannot change the windows update settings and it sets it to never install updates.

Did anyone ever find a solution to this?

9. Eric - December 23, 2009

First I’d like to say thank you for creting this script. It’s been working very well for me. I was wondering if there is a way to only have critical patches identified? I’ve been having problems with windows updates updating drivers with less than desirable ones. Having the script only pull down critical patches would be greately appreciated.

Again, thank you for all your work on this. It’s a very good script.

tmintner - December 28, 2009

Hi Eric,

There isn’t a way to select only critical updates but you can use the exclude variables in the customsettings.ini to exclude certain driver packages that are causing problems. You might also consider implementing a WSUS server. By implementing WSUS, you can specifically control what updates are approved and the script will only download and install the approved updates.

Bart V - July 30, 2010

Can you post an example of the exclude variables?

I have many sections in my customsettings.ini file (Ex. cpackages, settings, rpackages, etc) and am not sure where to place them, if they need their own ” [xxxxx]” header or not.

10. Brian Larsen - November 23, 2009

Hi Keithga

But “NoAutoUpdate_Previous” is set to blank the first time the script runs, because the regkey (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate) doesn’t exists the first time. The second time the script runs, after a reboot, the “NoAutoUpdate_Previous” equals “” in line 484 is still true, but then get set to the value of 1, because line 493 creates the regkey the first time the script runs and set the value of “NoAutoUpdate” to 1.

I can send you a logfile if you want to?

Regards Brian

Handige Harry - August 26, 2010

In MDT 2010 I’m seeing the same issue as Brian. I have enabled the default MDT ‘Windows Update (Post)’ task, and the script leaves the values NoAutoUpdate (1) and UseWUServer (1) afterwards. (We don’t currently use a WU Server.)

Otherwise, thanks for a very useful script and thanks to Brian and Google for allowing me to solve the issue pretty quick.

11. keithga - November 20, 2009

I just did a quick scan of the code, and I think it should be working properly. After the reboot “NOAutoUpdate_Previous” should be set to , not blank so the code at lines 485-890 shouldn’t overwrite it.
Later after the scan has completed, the NoAUtoUpdate will be restored to the value from NoAutoUPdate_Previous.

12. Brian Larsen - November 20, 2009

Hi Keithga

Maybe you can help me out here. I think there is a problem with your ZTIWindowsUpdate.wsf script concerning the variable “NoAutoUpdate_Previous”.
The problem occurs when the computer needs to do a restart. The second time around the script test to see if “NoAutoUpdate_Previous” equals “”, it is still true (but in the registry “NoAutoUpdate” is really 1 because the script has already run once). So the second time the script runs, the variable “NoAutoUpdate_Previous” is set to 1. That means when there are no more updates left and the script has finished, it will always set HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate to 1, no matter what it was before the script started. (Line 313 is true, and then uses the value in “NoAutoUpdate_Previous” to write to registry).
This means that you can’t enable “windows update” when deployment is done trough the user interface.
So if the computer needs to reboot, you need to make sure that the value in “NoAutoUpdate_Previous” corresponds to the first time the script runs, and not the last time the script runs.

Pleas correct me if I am wrong.

Kind Regards

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: