Skip to content

December 8, 2015


Software Updates Fail to Detect After Site Recovery

I recently ran into a problem where my Software Update point stopped working after performing a Site Recovery of my System Center Configuration Manager Site Server. In my scenario, I was performing a Site Recovery in order to upgrade my OS from Windows Server 2008 R2 to Windows Server 2012 R2 and SQL Server 2008 R2 to SQL 2014 SP1. After the upgrade was completed, all post-recovery steps were done, and all other functions were validated; I found my Software Updates were still not working. When checking Compliance on all updates, they simply reported back “Compliance Unknown”.

I checked through all the SCCM server logs (such as SUPSetup.log, WSUSCtrl,log, wsysmgr.log, etc.) and the SCCM client logs (such as UpdatesDeployment.log, UpdatesHandler.log, UpdatesStore.log, WUAHandler.log, etc.) and did not find any obvious errors. Also, WSUS and SCCM were syncing new updates successfully without error.

After much research and reaching out to Microsoft, I found that the problem is when a Site Recovery happens, the Site Database retains the WSUS/SUP Catalog version, but the SCCM registry keys storing this are not restored (they are reset). To resolve the issue, I had find out what version the catalog was before the recovery and set the registry keys to that value.

The catalog version can be in the ScanAgent.log file, however, debug logging must be turned on first. To enable ensure that HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\CCM\LOGGING\@GLOBAL\LogLevel is set to 0, and create an empty key at HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\CCM\LOGGING\DebugLogging. Once debug logging is enabled, restart SCCM agent and perform a Software Updates scan. Search the ScanAgent.log for Required-ContentVersion=<VersionNumber>. (If multiple catalog versions are found in the log, the one with the highest version is needed).

To resolve the issue, find the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_WSUS_SYNC_MANAGER key. Replace the values in the ContentVersion, SyncToVersion and LastAttemptVersion DWORD entries with the catalog version retrieved above + 1. For example, if Required-ContentVersion=1231, then set the registry values to 1232.

Once these keys have been updated and SCCM has been restarted, Software Updates should begin functioning. For good measure, another WSUS Synchronization can be performed to ensure all is working (the registry values will be incremented by 1).

2 Comments Post a comment
  1. Gabe
    Jul 15 2016

    I had spent hours of work trying to figure this out on my own and would have spent countless hours more had I not found this post. Thank you, thank you, thank you…

  2. Sven
    Feb 5 2018

    I spent hours trying to figure out what was wrong. This post pointed me in the right direction! PS: It’s also possible to search for the required contentversion in the SQL database:

    Thanks for taking the time to write this post.


Share your thoughts, post a comment.


Note: HTML is allowed. Your email address will never be published.

Subscribe to comments