WSUS
ConfigMgr 2012 R2 – Remote SUP
When setting up ConfigMgr 2012 R2 to use a remote server to host the Software Update Point on Windows Server 2012 R2, configuration of the SUP may fail. The WCM.log will show entries such as:
Checking for supported version of WSUS (min WSUS 3.0 SP2 + KB2720211 + KB2734608) Checking runtime v2.0.50727... Failed to create assembly name object for Microsoft.UpdateServices.Administration. Error = 0x80131701 Checking runtime v4.0.30319... Did not find supported version of assembly Microsoft.UpdateServices.Administration Supported WSUS version not found Remote configuration failed on WSUS Server
The error implies that WSUS 3.0 SP2 is required for the remote SUP, however it is not for Windows Server 2012 R2. Rather, since the SUP is on a remote server, the WSUS admin console server feature is required to be installed on the primary site server.
ConfigMgr 2012 – Cannot install WSUS on Server 2012 R2
I’ve come across this for a couple of customers. During installation of prerequisites for ConfigMgr 2012 R2 Software Updates, it is necessary to have the server WSUS role installed. If any domain GPO for WSUS is being applied, it may prevent the installation of the WSUS role on Windows Server 2012 R2. The specific policy is for the “Log on as a service”, which in GPO can be set to restrict access to specific AD groups. WSUS needs to create a local service and grant the logon rights during the install process, even when not selecting the setup to use the Windows Internal Database (WID).
KB2832204 describes the issue precisely, even though it was written with regard to ADFS (and not WSUS). The workaround was to do the following:
- Move the server into the Computers container (so the GPO is not applied)
- Install WSUS (either as a database on SQL Server or the WID)
- Perform the WSUS post install tasks
- Move the server back into the proper OU
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:
- Configure Automatic Updates set to Disabled
- Enable the AU windows service
- Optional: continue to disable user’s ability to get updates themselves from Windows Update
- Set all other WSUS related GPOs to not configured
- Updated 6/14 (Tip from Kevin in Denver) – remove any Domain Group Policy setting pointing to a location for Automatic Updates. This needs to be left“Unconfigured” in order for SCCM’s SUP to work correctly.
- Deploy the SCCM client upgrade/changeover
- 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:
- Open IIS Manager
- Right-click on the default website and select “Edit Bindings”
- 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 7th 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)
t3chn1ck 