Migration Strategy for WSUS to SCCM & Software Updates

The key to protecting an environment from incidental patching during a transition from using WSUS to using SCCM with Software Updates is to reconfigure three group policies which have an impact on SCCM software updates.

• Specify intranet Microsoft update service location: the SCCM client sets this as a local GPO pointing to the SCCM\WSUS server.  (Note: It could be possible to set these values as domain GPO, but the trouble is that there are two SCCM servers acting as WSUS for their clients, so managing multiple GPOs would be more pain than value.)
• Configure Automatic Updates: this will set the automatic update settings.  I’ve seen that once this was turned off in GPO, it kept the default to automatically download and install updates.  It is possible to set this to Disabled without impacting SCCM’s delivery of security updates, but it will impact delivery of FEP definition updates.  With SCCM 2007 and FEP 2010, in order for definition updates to automatically install, auto approval actually gets set in WSUS itself, so therefore disabling AU would mean no delivery of those updates and need to be re-enable in the future.
• The final GPO is just configuration of the Automatic Updates windows service.  If the GPO disables the service, then no updates will work.  A forced enable of the service through GPO would be a good thing.

A route for the WSUS to SUP migration could look like this:

1. Configure Automatic Updates set to Disabled
2. Enable the AU windows service
3. Optional: continue to disable user’s ability to get updates themselves from Windows Update
4. Set all other WSUS related GPOs to not configured
5. Deploy the SCCM client upgrade/changeover
6. Later, as part of a FEP migration, use GPO to configure automatic updates to be enabled (since that will be needed for automating the definition update releases)

IIS Bindings and SCCM Software Updates

You may be asking, what does IIS bindings have to do with SCCM software updates.  Well, let me tell you lol.

I’ve stood up a new SCCM infrastructure including site configuration/roles and deployed a few clients.  When testing software updates on a client, software update scan/deployment cycles kept failing.  Upon investigation of logs, the scan were failing with “Scan failed with error = 0x80072efd”.  Furthermore, reporting showed scan error failure code -2147012867.  These errors indicate that the Windows Update Agent could not communicate with the defined source location.

The troubleshooting difficulty is that there are many possibilities of causing this.

• Local GPO “Specify intranet Microsoft update service location”.  When using SCCM software updates, the client sets this local GPO on the client pointing to the WSUS location.  In my case this wasn’t it.
• Windows Firewall blocking the ports used by WSUS, on either the client or server.  In my case this wasn’t it.
• A proxy or bad winhttp settings redirecting the traffic incorrectly from client to server.  In my case this wasn’t it.
• Various other things.

I believed that I had reached the end of the Internet at this point when finally I came across a posting on WindowsNoob that steered me in the right direction.  To fix a different technical problem with WSUS conflicting with Symantec Endpoint Protection, I swapped the Software Updates Component from using ports 80/443 to using ports 8530/8531.  I guess with this change, SCCM didn’t automagically configure the default website in IIS bindings to listen for requests on the newly defined port.

So to resolve the issue, I did the following:

1. Open IIS Manager
2. Right-click on the default website and select “Edit Bindings”
3. Add port 8530 as an IIS binding….and voila it works.

Workaround for Installing Office Updates During an Image Build

Ran into an interesting situation with an image build.  I created a custom Office 2010 SP1 install using the OCT.  During execution of my image build task sequence, Software Updates was not detecting any of the updates for Office.  Further diagnosis revealed that the OCT-built install did not put its “hooks” into the Windows Update Agent, therefore neither the SUP or Microsoft Updates could detect for Office updates.  (Side note: once the image was sysprepped, captured, and added into a deployment task sequence, the updates were suddenly available and installed.)

While the cause as to why an OCT-built Office 2010 SP1 install prohibits installation of updates has not been found yet, there is a workaround to run a script that forces Microsoft Update (e.g. WUA) to receive updates for “other products”.  By executing the following VBScript after installing Office, SCCM Software Updates will then be able to install the updates during the image build task sequence.  The original code is from a TechNet blog post, I just added some extra logging for troubleshooting.  Also, if your TS advertisement is configured to “run from server”, then the script will cause the TS to fail.  To get past this, simply copy the script locally first then execute it from that location.

Const ForAppending = 8
Set oFSO = CreateObject ("Scripting.FileSystemObject")
Set oLogFile = oFSO.OpenTextFile ("C:\ConfigOfficeUpdates.txt", ForAppending, True)
oLogFile.WriteLine "Starting execution of VBScript to configure Office to use Microsoft Updates"
Set ServiceManager = CreateObject("Microsoft.Update.ServiceManager")
ServiceManager.ClientApplicationID = "My App" 

' add the Microsoft Update Service by GUID
Set NewUpdateService = ServiceManager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"")
oLogFile.WriteLine "Script completed successfully"
wscript.Quit(oLogFile.Close)

SCOM alert for ‘SMS_WSUS_SYNC_MANAGER’

If both SCCM and SCOM are implemented in your environment (and SCOM is monitoring SCCM) then you may at some time receive the following alert:

The availability state for SMS component ‘SMS_WSUS_SYNC_MANAGER’ in site XYZ changed from ‘Online’ to ‘Failed’. Its installation state is ‘Installed’. Its execution state is ‘Hung’. This component last provided a heartbeat at ‘DATE TIME‘. The next heartbeat is expected in ’3600′ seconds from that time.

Investigation of the alert (SCCM console, logs, etc.) reveals that the component is truly functional and never reports being hung.  After a long drawn out support case with Microsoft, this is what was discovered:

Whenever a scheduled sync is triggered it does a complete sync and that is by default to run for about 40-50 minutes. And during this action the SCCM marks a registry as “3″(HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\SMS\Operations Management), which means that the service is hung. This registry change is made if the heart beat is not received by the WSUS component(this heart beat is from the WSUS component to the SCCM), by default the heart beat is received within 6 minutes every hour(i.e. 2:00-2:06, 3:00-3:06…and so on), and whenever next time the heart beat is received then the component is marked as online and usable. So SCCM console doesn’t show any issue. However during this time MON monitors the registry and comes to know that the component is marked as “3″ so it send the alert. Our motive here is SCCM should not mark the registry as “3″ and that can be established if we have the sync process start after 2:06 and end before 3:06 or respectively. This behavior is by default.

So the solution (just a workaround) is to schedule the sync to occur in the 7^th minute of the hour (e.g. 2:07 instead of what I had at 2:00).  Additionally they said a true fix won’t be created because there has not been enough reported issues to justify a fix.  Anyway, I hope this helps!

**** Update as of 2/28/11 ****

To help determine that SCCM was incorrectly setting the registry values, I wrote a simply VBScript to log the registry values (code below).  Then on the server, I created a custom scheduled task to run the script every 1 minute for the period being monitored.

' This script runs via a scheduled task to capture registry entries SCCM WSUS Sync
' Written by Nick Moseley
Option Explicit
Const HKLM = &H80000002
Const ForAppending = 8
Const sLogFile = "C:\PSS_WSUS.log"
Dim oShell, oFSO, sKeyPath
Set oShell = CreateObject("WScript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")
sKeyPath = "HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\Operations Management\Components\SMS_WSUS_SYNC_MANAGER\Execution State"
Dim oLogFile
If Not oFSO.FileExists (sLogFile) Then 
    oFSO.CreateTextFile sLogFile
End If
Set oLogFile = oFSO.OpenTextFile (sLogFile, ForAppending, True)
oLogFile.WriteLine  "ExecutionState: " & oShell.RegRead(sKeyPath) & " (" & Date & ", " & Time & ")"
wscript.Quit(oLogFile.Close)