sccm.haas.se
21Nov/113

Build and Capture + Software Updates in Native mode

The goal of  this article is to describe how to insert Software Updates into the Base Image, the Windows-image you want to base your Operating System deployment on, in SCCM Native Mode.

In order to shorten the installation time of the operating system for your end-users you want to include as many patches and updates as possible in the image you’re deploying. But you want to include as few programs as possible so that you don’t end up updating your Golden base image every two weeks…

Obviously you will want to update your image with new Software Updates every once in a while – but that will not be manual labour but automated in the task-sequence that builds the Base Image.

I could have written a book about all the things I tried to get this to work… Let’s just establish the fact that Software Updates and in particular WSUS must have been written the morning after some very big Microsoft launch party…  ;-)

That said. I finally managed to get this to work. It took a a week of Googling, trial and error, troubleshooting, late nights and lots of coffee. And the silly thing is that’s it pretty easy to get it to work – if you know exactly what to do. As always.

I’ll summarize what this article does:

  1. Use only one Hotfix (KB2509007).
  2. Use SLP as a parameter for your CM-client.
  3. Check “Allow HTTP for roaming…” and rebuild the boot-image.
  4. Run a script to trigger software updates scan and run it a couple of times!

Here’s an overview of a standard Build And Capture Task Sequence. As you can see I’ve added Microsoft Deployment Toolkit to SCCM to get support for language packs in the image.

Download the task-sequence here. Rename it to .xml afterwards and import it into SCCM.

1. First you will need a hotfix in your CM-Client package-folder. Download KB2509007. Run it on your SCCM-server, it will create a package for you with the unextracted files from the CAB in <server>\SMS_CEN\CLIENT\I386\HOTFIX\KB2509007.  Make sure that this is the same path as the package source catalog for your SCCM client in your Task Sequence.

Unless you apply this patch, the Task-Sequence will hang on “Installing Updates 1%”  for 30 minutes and then time-out and fail.

2. Make double sure that you have no other updates in the Hotfix directory of your CM-client. It doesn’t make sense to include more than this one anyway since the CM-Client will be uninstalled at the Capture-step. It makes more sense to install hotfixes together with your base image. Installing multiple hotfixes at the same time can really confuse the CM-client and KB2509007 doesn’t seem to work well with others. I found that out the hard way. So if you’re using the same source package for Configuration Manager when you’re building your image as well as when you’re deploying it – you can’t have more than one patch in it or you’ll be in trouble. (Jörgen Nilsson has come up with a solution for how to include multiple CM Client Patches when deploying the image.)

3. Make sure that you have SMSSLP=<your SLP Site System> as a parameter to your CM-Client. In a Workgroup that’s the only way to find the CM-server unless you’re using WINS. And we’re not using that anymore, right? I did of course write Workgroup because Sysprep doesn’t work if your machine is in a domain. We’ll also add the Management Point for good measure.

4. In “Site Settings” -> Site Mode Check “Allow HTTP Communication for roaming and site assignment“.

This allows Workstation-Computers that aren’t in native mode to communicate with Configuration Manager which is in native mode. Otherwise the installation will hang with error “0x800705B4” after 30 minutes. It will never start the percentage counter either but will look like this:

 This setting originally (or so I always  thought) was for native SCCM-clients  that travel to sites in the CM-hierachy that yet aren’t in native mode and allows them to talk to the MPs/DPs in the new site. This setting also works for Workgroup-computers trying to talk to the CM-server which is necessary since they can’t speak SSL. This might be  a little bit unobvious at first. It is supported by Microsoft though (and properly documented here). If you clicked on the first link you might have read that you’re supposed to edit a file called “MobileClient.tcf“. I noticed that this file is updated automatically by CM as soon as you check “Allow HTTP-Communication for…”. I haven’t verified this on dozens of servers, so double check that and tell me if I’m right or not. (Here’s an explanation for the IISSSLState value in MobileClient.tcf.)

5. Rebuild your Boot Image. I really don’t know why you have to do this after you changed the “Allow HTTP-Communication for…”. I can only assume that somehow that setting needs to be propagated to the boot image although I would think that that’s something the client would ask the MP for… I can tell you though that unless you rebuild your image you’ll be stuck waiting 30 minutes for the “Installing Updates” window to crash. If you’re booting from an ISO (VMWare/Virtual Box and similar) just create the new image as usual from Task Sequences -> Create Task Sequence Media.  I’m using a boot image since I’m building my Base Image on a virtual machine which is more or less how you should do it since you avoid getting lots of unneccesary drivers in your Base Image. Since I’m building on a virtual machine I’m unsure if you need to do anything with the regular x64/x86 boot-images that come with CM (or the MDT-boot image that comes with MDT). Please send feedback if you’ve tried this!

This is what a happy c:\Windows\WindowsUpdate.log looks like on the computer you’re going to image:

There’ll be lots of references to download.microsoft.com before that with error messages. That’s ok, that happens during the Windows-installation phase. The important thing is that the Windows WSUS-client finds your Software Update Point during the Install Updates-phase.

6. After the task sequence step “Setup Windows and ConfigMgr” you could normally run the built in task sequence step “Install Software Updates”. BUT as soon as you insert anything else before that, software updates will find no updates. Zero. Nil. Nada. As in my example above, you can’t apply software updates for IE9 before IE9 is installed and hence you need to install it before scanning for updates. Which will make the scanning for updates fail since it won’t find any new updates. So… enter the workaround script that I modified a little but comes from here! The script sets the registry values to your WSUS-server/SoftwareUpdatePoint and then it triggers a rescan.

The script looks like this:

' COMMENT: Sets registry keys to the WSUS/SUP-server and initiates a WSUS-rescan locally.
  1. '     Needed for Build And Capture image creation.
  2. '==========================================================================
  3.  
  4. '—– Create Registry Settings Required for Workgroup Updating —–
  5. Dim oShell
  6. Set oShell = CreateObject("WScript.Shell")
  7. oShell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer", "https://Your.SoftwareUpdatePoint.com:8531", "REG_SZ"
  8. oShell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer", "https://Your.SoftwareUpdatePoint.com:8531", "REG_SZ"
  9. oShell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer", 1, "REG_DWORD"
  10.  
  11. '—– Restart wuauserv Service so Settings Take Effect —–
  12. Set oWMIService = GetObject("winmgmts:" &amp; "{impersonationLevel=impersonate}!\\.\root\cimv2")
  13. Set colServiceList = oWMIService.ExecQuery ("Select * from Win32_Service Where Name='wuauserv'")
  14. For Each objService in colServiceList
  15. objService.StopService()
  16. Wscript.Sleep 5000
  17. objService.StartService()
  18. Next
  19. Wscript.Sleep 5000
  20.  
  21. '——– Trigger Software Updates Rescan ——
  22. Schid = "{00000000-0000-0000-0000-000000000113}"
  23. sMachine = "."
  24. Set WMItarget = GetObject("winmgmts://" &amp; sMachine)
  25. Set WMICCM=GetObject("Winmgmts:{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" &amp; sMachine &amp; "\root\ccm")
  26. set SMSCli = WMICCM.Get("SMS_Client")
  27. set oParams = SMSCli.Methods_("TriggerSchedule").inParameters.SpawnInstance_()
  28. oParams.sScheduleID = Schid
  29. set res = WMICCM.ExecMethod("SMS_Client", "TriggerSchedule", oParams)
  30. wscript.sleep(180000)
  31.  
  32. WScript.Quit(0)

Download the entire script here. Remember to change .txt to .vbs and insert your SUP/WSUS Servername into the script.

THEN you can run the normal tasksequence step “Install Software Updates” afterwards. And you will actually need to run it a few times since many updates require a reboot before WSUS can apply even more patches. Note that I’m addressing port 8531 in my script since my SUP is on my SCCM server. If you’re running your SUP on a different server than your SCCM you may be using port 80.

So this part of the Tasksequence will look like this:

That’s it! I can’t believe it took me a week to find that out… I hope this guide might help some other poor souls out there in the future.

Other basic tips are:

  • Create a Software Update Package that you advertise to the same collection that your Build and Capture Task Sequence is advertised to.
  • Check that the computers IP that you’re building the image is in a boundary assigned to your site server.
  • That the Software Update Package you’ve made actually is on a distribution point!
  • Install Software Updates Offline is for injecting updates into an existing image. Not for Build and Capture.
  • Microsoft doesn’t recommend you to build the image, join the domain, install patches, leave the domain and to the capture. You’ll get lots of GPOs messing with your base image and other traces from having joined the domain.

The best of  luck!
/Mathias.