I'm having an issue with getting mandatory updates to install during an OSD task sequence. I found that when I image a machine, the tasksequnce item for installing mandatory updates would time out with the "Timedout waiting for updates refresh complete notification" error in the SMSTS.log. I found that this is caused by the PC object not being a member of the collection where our software updates are advertised to. When imaging a PC, it creates a duplicate entry in the SCCM DB and that duplicate entry does not get put into the software updates collection until 24 hours later. To complicate matters more, if I manually update the collection membership of our software updates collection when the task sequence reaches the "install updates" step, the task sequence no longer times out but gives a "No updates need to be installed on this machine." message in the SMSTS.log. It's very odd seeing as the updates install automatically after 24 hours after PC is imaged. So I guess my questions are, How do I get my machines to automatically get into my software updates collection during the task sequence? And once they are in the collection, what determines whether updates are "mandatory" for task sequences" Also, is there another way I can install sofware updates in a task sequence, like using a cmdlines.txt file or something similar? Any help on this would be greatly appreciated.

I'm also having problems with the install updates task.So much so that I am now at the point where I do not believe it actually works properly.I have installed a vanilla Windows XP from an install package, installed Office 2003 and run the 'install updates' task. It will then proceed to patch Office up to SP3 but not beyond. It also upgrades IE6 to IE7 but fails to apply any IE7 hotfixes. I can see from the lastscan in theWUAHandler.log file that16 updates are detected as 'missing', the scan completes successfully and then the program just seems to exit rather than download andinstall the missing updates. All of these updates are targetted to the collection and get installed by the configmgr client at a later time. I would also be very interested to see if there is any way of forcing an update via some sort of 'run command line' task but I'm not going to hold my breath. At the moment my ConfigMgr OS deployment is a step back from my previous WDS server which I had automated to a 'zero touch' deployment system. Something I do not believe ConfigMgr is capable of. I am now just hoping that the issue I'm having is fixed in ConfigMgr R2 and it turns out to be the product I believed it was when I bought it.

I've finally managed to get a 100% patched task sequence. I did it by completely ditching the 'Install Updates' task and just using a couple of scripts that force the computer to perform a Windows Updates task with the WU client. The first script sets the wsus server to connect to (you'll have tochange it accordingly)rather downloading updates via the internet (needed if your computer is joined to a workgroup rather than a domain). The second does the actual update. SetWSUS.vbs: Code Snippet '----- Create Registry Settings Required for Workgroup Updating -----Dim oShellSet oShell = CreateObject("WScript.Shell")oShell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer", "http://server.domain.net:80", "REG_SZ"oShell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer", "http://server.domain.net:80", "REG_SZ"oShell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer", 1, "REG_DWORD" '----- Restart wuauserv Service so Settings Take Effect -----Set oWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\.\root\cimv2")Set colServiceList = oWMIService.ExecQuery ("Select * from Win32_Service Where Name='wuauserv'")For Each objService in colServiceListobjService.StopService()Wscript.Sleep 5000objService.StartService()NextWscript.Sleep 5000 InstallWSUSUpdates.vbs: Code Snippet '----- Create Session -----Set UpdateSession = CreateObject("Microsoft.Update.Session")Set UpdateSearcher = UpdateSession.CreateUpdateSearcher() '----- Search for Updates -----Set SearchResult = UpdateSearcher.Search("IsInstalled=0 and Type='Software'")For I = 0 To SearchResult.Updates.Count-1Set Update = SearchResult.Updates.Item(I)Next '----- Quit if No Updates Found -----If SearchResult.Updates.Count = 0 ThenWScript.QuitEnd If '----- Create List of Updates to Download -----Set UpdatesToDownload = CreateObject("Microsoft.Update.UpdateColl")For I = 0 to SearchResult.Updates.Count-1Set Update = SearchResult.Updates.Item(I)UpdatesToDownload.Add(Update)Next '----- Download Updates -----Set Downloader = UpdateSession.CreateUpdateDownloader() Downloader.Updates = UpdatesToDownloadDownloader.Download() '----- Create List of Updates to Install -----Set UpdatesToInstall = CreateObject("Microsoft.Update.UpdateColl")For I = 0 To SearchResult.Updates.Count-1set Update = SearchResult.Updates.Item(I)If Update.IsDownloaded = true ThenUpdatesToInstall.Add(Update) End IfNext '----- Install Updates -----Set Installer = UpdateSession.CreateUpdateInstaller()Installer.Updates = UpdatesToInstallInstaller.Install() '----- Quit -----WScript.Quit

James, This is an interesting approach. I've snagged your code (and cited it in the scripts) to do patching during an OS task sequence. I've modified it to take a command line variable and am using SMSDP for site sensativity since I haveWSUS serversat different locations and I want to be able to use one TS. My question is where you are placing this in your TS. I've added in a set script for the WSUS server (with command line) and then follow it with a install updates script as shown above. The server is getting set but no updates are coming down. If I run the same script after the machine is up and going it fires off the updates just fine. Probably a timing issue on my side. I have done this exact same type of script for patching servers in the past with great success but it was while they were online. Not during an OS deployment obviously. Just curious where in your TS you are placing the Software Updates scripts - just disabling the one that is provided with MDT and putting yours in there? Additionally, I am using SUPs but not in the traditional sense. I have WSUS integrated into SCCM as SUP's but using WSUS to auto install / approve updates per the customer request and SCCM is merely grabbing the status information from the WSUS servers and reporting it. This configuration is also in native mode but that shouldn't be keeping the updates from coming down if they are coming from WSUS as far as I can tell. Anyway...good idea on the scripts. Just curious where you placed them. Thanks Jim

Hi Jim, I'm running it a number of times at various different points during my "Build and Capture Reference Computer" Task Sequence for 100% patch compliance on XP clients. Firstly I run the script immediately after the "Setup Windows and ConfigMgr" task. This installs the bulk of the updates. However, certain updates (IE7) applied here need patching and these can only be detected after a reboot. So after the reboot I and install the WGA Tool, Office 2k3, .NET 1.1 and run the script again. This patches Office 2k3 to SP3 and applies some .NET updates. I then reboot again and install Office 2k7 Compatibility Pack and Visio Viewer 2007. I then install updates again to patch these to SP1 and then reboot and install once more to install the post SP1 updates. I'm then sysprep'ing the reference computer and capturing an image of the OS. The majority of deployments are done by applying this image. I'm not using the software update point at all during my deployments/patch management. Using WSUS seems to be a far more sensible option. It means I don't have to copy all the updates into 'Software Update Packages' taking up nearly an extra 30gb of space on our server for no reason. I also don't have to create monthly update packages on 'patch Tuesday'. I prefer 'set and forget'.

Thanks James. So for me I prefer to build the reference image without all the applications and adding the patches in the image means you need to keep refreshing that image every so often right? So I did this in the TS for deployments (granted takes a bit of time but at least it pulls the latest updates). So setup a TS group for Installing Windows Updates just after the configmgr setup like you had stated. I set the server according to the SMSDP Property variable so I could state what WSUS server to use https://sccmserver.domain.corp:8531, then ran the install wsus updates script. Then installed all my software during the TS and then added one more script to install updates and that is working. Thanks for the info. Great solid solution for getting updates on there. I agree it is a bit of a hassle with SCCM updates. Jim

Hi, Glad it's all working for you now. It's very possible that I may need to update my image at some point in the future but I'm not planning on it. We're running Microsoft Forefront Client Security as our anti-virus solution with which the client and definition updates are both distributed via WSUS and only to domain members. This means that it doesn't get installed during my Build and Capture task sequence and I have to run the Install Updates script during my image deployment twice, once to deploy the client and a second time to update it. This will add any further updates that are released during my image deployment task sequence. We're looking to move to Vista/Office2k7 as our standard platform in the new year so now I'm cracking on getting these task sequences working while all this all is fresh in my memory. I figure that by the time I need to update my XP base image I'll be rolling out Vista as standard instead.

I assume that since you are building a reference image that the computer is in a workgroup. In that case, the problem with the "Install Software Updates" step in the task sequence is that it can't receive the WSUS settings via GPO (no domain to apply the GPO settings). To work around this without all the gyrations that you went through, you can modify the "Setup Windows and ConfigMgr" action to specify "SMSSLP=<servername>". This enables the client to get the needed settings so that it can successfully talk to the SUP/WSUS server to apply updates. (The scripts that you are running get around the same problem, just in a different way that ends up bypassing the ConfigMgr update process.) See http://technet.microsoft.com/en-us/library/bb693951.aspxwhich documents the SMSSLP requirement: "If you are installing the Configuration Manager 2007 client on a computer that is a member of a workgroup you must specify a Configuration Manager 2007 server locator point. The server locator point will locate the assigned software packages and updates that will be installed on the target computer." It's just not really clear that all you have to do is add the command line parameter... -Michael Niehaus Senior Software Development Engineer mniehaus@microsoft.com

Unfortunately I had to write the script because the update process doesn't work properly. I have tried the settings you have suggested (netbios, dns and ip address) but they do not make a difference to this problem. I have managed to narrow this down to being a conflict between Office 2003 and Office 2007 compatibility pack/Visio Viewer 2007. Removing both of these applications results in the update process completing successfully.

Did removing the Office 2007 compat pack and Visio Viewer solve the problem without the need to use your scripts? I am having EXACTLY the same problem you describe.I am installing the compat pack and viewerin the image after my first Install Software Updates task. I can understand that I would need to run the Install Software Updates task multiple times to patch IE7 which installed in the first run. And to patch Office which was installed after the first update run. Problem is, it says there are no patches applicable during the second Software Updates run. I am wondering if I can just move the compat pack and Visio Viewer to the end of the task sequence.

The only thing that solved my problem 100% was the script. I found that the "Install Software Updates" task has another problem where it can only be run successfullyonce. It seems like you're getting the same thing there too! If you run it straight after installing your OS it will patch it100% fine. If you then decide to install .NET 1.1 or Office for example and re-run the "Install Software Updates" task it will not detect any more updates even if these updates are targetted to your reference computer. The flip side of this is the problem that you are seeing. If you install all your applications and then run the "Install Software Updates" task at the end of your sequence the conflict between Office 2003 and the compat pack/visio viewer prevents the "Install Software Updates" task from completing successfully, resulting in error code 80244010. Putting the "Install Software Updates" task after Office 2003 but before these Compat pack/Visio also doesn't work. Office is fully patched fine but ,again, it won't find the required updates for anything that was installed after the first time it was run. The only way I got it to fully work was by using the script and patching in stages.Once after the OS install,Twice after Office is installed and twice after the Compat pack and Visio.If I installed all the applications and then run the script I would see the same (80244010) error codein the %WINDIR%\WindowsUpdate.log. After months of trying I never got it to fully work using the "out of the box" method and personally I don't believe it's fit for purpose to be honest.Go with the script, I know it's adirty workaroundbut it willsave you weeks of tearing your hair out!

James, I am going to give your scripts a try in the morning (with credit of courrse). I have a couple of questions first. 1. Are you pointing to a WSUS server or an SCCM SUP/WSUS server? I do not have a standalone WSUS server and I am wondering if it will work pointing to a SUP. Not sure how it would know what is approved without the SCCM policies to tell it so. 2. Is there a reason you have two scripts? I am wondering if I can just combine them into one. Great post. Thanks again.

Steven, the two scripts are useful (one for setting the WSUS server) and one of course for pulling the updates. You don't need to set the server over and over again so having two scripts is worthwhile. You can make those two different TS tasks and only use the first script once but duplicate the other script as I did and James recommended. Also this is independent of whether you have WSUS or a SUP. Both have the WSUS components. This is bypassing software update points and using WSUS to update the machine.

Hi, 1. Yes, I'm pointing it at my SSCM SUP. It only installs 'High Priority' updates so anything that would normally be in the 'Optional Updates' section of the update.microsoft.com must be installed manually. During my task sequence I install in in the following order: OS Windows Genuine Advantage Tool (from redistributable package downloaded from MS) .NET 1.1(from redistributable package downloaded from MS) .NET 3 (from redistributable package downloaded from MS) "Install Software Updates task"- 4 updates targeted. KB898461 (Update for XP), KB925850 (WMP11), KB931152 (Update for Root Certificates) and KB957938 (Microsoft Silverlight). Restart Computer Install WSUS script Restart Computer Install WSUS script Restart Computer Office 2003 Restart Computer Install WSUS script Restart Computer Install WSUS script Restart Computer Office Compat Pack Visio Viewer 2007 Acrobat Reader Flash Player Shockwave Player Java Install WSUS script Reboot Install WSUS script Install Microsoft Update 2. I posted two scripts for the exact reason above. It's better practice to set your server once rather than every time. But to be perfectly honest I've combined them in to one script too now. Glad I can help others that are having the same problems as me!

Thanks Jim and James, The only questionI have right now is I am wondering how the WSUS server approves anything. Through the SUP all the approvals are done in SCCM and sent to the client via policy not the WSUS server. I am thinking I have to configure the WSUS server to auto approve the patches. My curiosity is whether SCCM will override this as it does other settings. If not, then it all sounds like it will work. I missed my morning build cycle, so I will give it a try later. Thanks again.

It should just depend upon where it is getting the policy. If you are using WSUS as the patching engine and leveraging SCCM for reporting (not really supported but works) then you configure the approvals in WSUS. If you are using SUPs and using groups with patches targeted according to how SCCM handles them, then no need to configure WSUS because those settings are ignored. It really depends on whether you are using WSUS as the patching engine or SUPs. James probably has 2 more cents =) .. Good luck Steven.

We have Forefront Client Security as our AV solution and it uses WSUS to distribute it's definition updates (about half a dozen a day), because of this I have to have my WSUS server set for auto approvals and therefore must use the WSUS engine to deploy my updates. If I go into ConfigMgr and selectthe productsto distributeit will overwrite the WSUS settings and de-select Forefront. I then just go back into the WSUS console and re-add Forefront asthis doesn'tdeselectthe ConfigMgr'Local Publishers'product that WSUS doesn't support. They seem to co-exist very well. I'm also not too overwhelmed by ConfigMgr's lack of support for auto approvals. I know it's supposed to be an Enterprise Class product where each patch is fully tested before being rolled out but unfortunately I don't have time for this (probably because I'm too busy trying to figure out how to 100% patch a Reference PC!).

We have run into the same issue. I was able to fix it buy adding the Install Updates task 3 times in a row. It works fine but adds a considerable amount of time to the deployment and I am afraid that the more office patches that are added the more times I will need to add the task.

@fusiongroup, your script is great. It installs all available updates of our wsus server.My problem is to install these wsus updates while running the task sequence.in process of installation a reference computer via sccm task sequence the error occurs, the there is no token for running the line:Set UpdateSearcher = UpdateSession.CreateUpdateSearcher()i think, it is a problem with connecting the wsus server of the task sequence environmentis there any help?

Hello I am relatively new to this. And have no idea how to do scripting. Im looking to run the script on multiple servers. I need a script to update the WSUS settings to download and install patches at a specific time on the server And then alter the settings back after the patching to download only. I dont want the servers to reboot. Please can you assist me.

Hey... I am having a similar issue when applying software updates as a part of TS. How are you calling these scripts (command line) we have SCCM pulling updates from WSUS, will this script help with that? We are on ConfigMgr Sp2 and installing software update as part of a TS still seems to be an issue. Your help will be appreciated.

Excellent Script Boredazfcuk! I have just recently started to experience issues when installing software updates as part of an SCCM OSD Task Sequence. I have a sneaking suspicion that .net framework patches are to blame, however your above scripts work around the issue nicely! FYI for those that are woundering how to use the abouve scripts, simply create a package with the two VBscripts from above, and then add a 'run command line task' to your task sequence. Tick the package box and select your package. for the command line box just enter "cscript.exe InstallWSUSUpdates.vbs" (wont need the quotes) and the scripts should work just fine. Try your scripts out with continue on error checked first and once you have verified that they are working, you can uncheck this option. </Scott>

I haven't been able to test your script, however I found that during our reference captures and Windows 7 deployments the "Install Software Updates" task wasn't properly applying applicable patches. This appears to be due to the fact that the "Software Updates Scan" isn't performed so the client doesn't understand what patches are needed for the machine. The following thread and script mentioned in the thread resolves that issue for me. We do deploy the configuration manager agent during the reference image capture with the SMSSLP parameter and value. Reference Image Task Sequence Steps around this are: Setup ConfigMgr Agent (SMSSLP parameter and value supplied) Perform SCCM Update Scan (using script mentioned below) Restart Computer Install Software Updates The last three steps used above apply to the Windows 7 Deployment Task Sequence. The difference is we perform Installed Software Updates multiple times. Specifically before Office is installed (this takes care of Windows 7 updates), and once after Office and other products are installed (this takes care of Office 2010 and other products). http://social.technet.microsoft.com/Forums/en-US/configmgrsum/thread/b525aafc-b613-49a2-9015-3ae1c2db2e01 hid = "{00000000-0000-0000-0000-000000000113}" sMachine = "." Set WMItarget = GetObject("winmgmts://" & sMachine) Set WMICCM=GetObject("Winmgmts:{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" & sMachine & "\root\ccm") set SMSCli = WMICCM.Get("SMS_Client") set oParams = SMSCli.Methods_("TriggerSchedule").inParameters.SpawnInstance_() oParams.sScheduleID = Schid set res = WMICCM.ExecMethod("SMS_Client", "TriggerSchedule", oParams) wscript.sleep(180000) Oh and don't forget this article, it is a must! http://support.microsoft.com/kb/2009754

Could please elaborate on how it is done? i have been struggling with the same issues for weeks now. it would be great if you could even throw in an xml to stranger dot 46 at hotmail.com Many thanks.-- Onions have layers, so does SCCM, and both will make you cry..

Could please elaborate on how it is done (XP Updates)? i have been struggling with the same issues for weeks now. it would be great if you could even throw in an xml to stranger dot 46 at hotmail.com Many thanks. -- Onions have layers, so does SCCM, and both will make you cry..

If you deploy Windows 7 to the unknown computers collection you can assign the updates to that collection and it will happen automtically. Check this wonderful method, http://deploymentcd.com-- Onions have layers, so does SCCM, and both will make you cry..

I've tried implementing this in my environment. The script is successful in applying all windows updates, but after the task completes the system goes on to the windows logon prompt instead of the Capture the Reference Machine group and it never finishes. I've tried adding system reboots to the task but that doesnt seem to help. Any suggestions?