wsus - Windows Updates not working via SCCM 2012 R2

We upgraded from SCCM 2012 SP1 on Server 2008 R2 to SCCM 2012 R2 CU2 on Server 2012 R2. Very simple site hierarchy - one site server provides MP, DP, SUP, etc. roles, and has WSUS installed (with all configuration performed by SCCM).

I am trying to deploy Windows updates and SCEP updates; my SCEP definition updates work perfectly, but Windows 7 updates, such as security and critical, do not jive so well. Between the Windows and the SCEP updates, the respective software update groups, ADRs, deployments, etc. are all identical to the extent that is relevant. There are no errors in UpdatesDeployment.log, UpdatesHandler.log, UpdatesStore.log, WUAHandler.log, or WindowsUpdate.log. The only thing that particularly stands out to me is that when I a Software Update Scan Cycle (an SCCM client action) from a client, WindowsUpdate.log offers this information:

Agent   ** START **  Agent: Finding updates [CallerId = CcmExec]
Agent     * Include potentially superseded updates
Agent     * Online = Yes; Ignore download priority = Yes
Agent     * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"
Agent     * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
Agent     * Search Scope = {Machine}

PT  +++++++++++  PT: Synchronizing server updates  +++++++++++
PT    + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asmx
PT  +++++++++++  PT: Synchronizing extended update info  +++++++++++
PT    + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asm
PT        + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asmx
Agent     * Added update {0BCA6C00-4FD3-4280-96BE-B89988FA1702}.101 to search result
 ~[Omitting 425 more lines identical except for the particular update GUID.]
Agent     * Found 426 updates and 75 categories in search; evaluated appl. rules of 2398 out of 3466 deployed entities
Agent   **  END  **  Agent: Finding updates [CallerId = CcmExec]
~[Omitting a lot of identical lines that describe WUA's (successful) reporting.]

COMAPI  >>--  RESUMED  -- COMAPI: Search [ClientId = CcmExec]
COMAPI    - Updates found = 426
COMAPI  --  END  --  COMAPI: Search [ClientId = CcmExec]

So it sure as heck seems like it's found some updates, but it never installs anything, nor does are the updates shown in Software Center, even though the deployment is configured to do so. However, if I use Windows Update to check for updates on the client, I get this result in WindowsUpdate.log:

Agent   ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
Agent     * Online = Yes; Ignore download priority = No
Agent     * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"

Agent     * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
Agent     * Search Scope = {Machine}
Setup   Checking for agent SelfUpdate
Setup   Client version: Core: 7.6.7600.320  Aux: 7.6.7600.320
~[Omitting lines about signature validation and SelfUpdate check (spoiler alert: "SelfUpdate is NOT required").]
PT  +++++++++++  PT: Synchronizing server updates  +++++++++++
PT    + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asmx
PT  +++++++++++  PT: Synchronizing extended update info  +++++++++++
PT    + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asmx
Agent     * Found 0 updates and 75 categories in search; evaluated appl. rules of 2398 out of 3466 deployed entities

Agent   **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
AU  >>##  RESUMED  ## AU: Search for updates [CallId = {87B4DC09-5A34-4351-975C-EE9BB69D9346}]
AU    # 0 updates detected
AU  ##  END  ##  AU: Search for updates [CallId = {87B4DC09-5A34-4351-975C-EE9BB69D9346}]

I have no idea if the results from Windows Automatic Updates are relevant to a WSUS/SCCM issue, so forgive me if my second chunk of logs is useless.

I have attempted the solutions offered in this question, with no change in results. Can anyone offer any other suggestions?

Additional details:

• Synchronization between WSUS and SCCM is happy (confirmed successful by wsyncmgr.log).


• Content is distributed in SCCM (confirmed successful by distmgr.log).


• No errors in server-side logs: PatchDownloader.log, SUPSetup.log, WCM.log,WSUSCtrl.log, or wsyncmgr.log.

Answer

This was answered in a TechNet thread.

SCCM 2012's splendid version control increments its SUP catalog version every time it downloads new updates, as seen in the Catalog Version column under Monitoring -> Software Update Point Synchronization Status. Every update that the SUP adds is entered as a row in the CI_ConfigurationItems table in the SCCM database. One column in this table, SDMPackageDigest, contains XML metadata, including a line that specifies which Catalog Version number the update was added to: , where [x] is a decimal integer. When upgrading from 2012 SP1 to 2012 R2, we imported our entire database to the new server, which meant that all updates had an entry for the MinCatalogVersion, reaching at least as high as 2200. However, SCCM stores the catalog version in registry keys, which were not imported, which meant that on the new server, the version number was restarted at 1. Thus, the SUP would not install updates that had a higher MinCatalogVersion than the catalog version, which was...essentially all of them.

The fix for this is to change three registry values on the SCCM server, all located in the key HKLM\SOFTWARE\Microsoft\SMS\Components\SMS_WSUS_SYNC_MANAGER.

• ContentVersion


• LastAttemptVersion


• SyncToVersion

After restarting the SMS_Executive service, updates promptly became available to all workstations they were deployed to.

I acknowledge that the proper thing to do would have been to use XQuery to search the XML data in the SQL table for the highest value for MinCatalogVersion; however, I was on a very tight deadline to fix the issue and did not have time to try to figure out an appropriate query. Thus, I just set all three of the registry values to 10,000 (decimal) and hoped for the best.