Fixing the "CatalogVersion" Issue Between SCCM and WSUS
Fixing the “CatalogVersion” Issue Between SCCM and WSUS
In this article, we will discuss an issue that can occur after recovering WSUS or SCCM. This issue results in software updates no longer installing on SCCM clients. When examining the UpdatesDeployment.log, you might find the following entry:
'EnumerateUpdates for action (UpdateActionInstall) - Total actionable updates = 0 '.
If you run a PowerShell query on a client to list all “missing” updates based on the WSUS catalog, you will get a list of missing updates:
get-wmiobject -query "SELECT * FROM CCM_UpdateStatus" -namespace "root\ccm\SoftwareUpdates\UpdatesStore" | where {$_.status -eq "Missing"}
The following PowerShell command will display all updates “pending” deployment:
get-wmiobject -query "SELECT * FROM CCM_SoftwareUpdate" -namespace "ROOT\ccm\ClientSDK"
As you will notice, it returns nothing. There are missing updates, but no “installable” updates. SCCM does not recognize these updates as “applicable” because the catalog version differs between WSUS and SCCM.
Every time SCCM successfully synchronizes with the WSUS catalog, it increments the “catalog version.” After a site recovery, SCCM may reset this counter and start from 0. Until the counter reaches the last catalog version value, updates will be considered “not applicable.”
I created a script to help resolve this issue by retrieving the latest catalog version from the ConfigMgr database and setting it in the registry so that ConfigMgr correctly displays the CatalogVersion, allowing clients to receive updates.
Here is the script:
<#
.SYNOPSIS
Solves CatalogVersion mismatch issue between WSUS and SCCM.
.DESCRIPTION
This script retrieves the latest catalog version and sets it in the SCCM registry.
.AUTHOR
Alexin.Tech
.DATE
14/06/2023
.VERSION
1.0
#>
# Define the server name and database name variables
$serverName = "<your_server_name>"
$databaseName = "<your_database_name>"
# SQL query to retrieve the latest catalog version
$query = @"
;WITH XMLNAMESPACES ( DEFAULT 'http://schemas.microsoft.com/SystemsCenterConfigurationManager/2009/07/10/DesiredConfiguration')
SELECT MAX(CI.SDMPackageDigest.value('(/DesiredConfigurationDigest/SoftwareUpdateBundle/ConfigurationMetadata/Provider/Operation[@Name="Detect"]/Parameter/Property[@Name="MinCatalogVersion"]/@Value)[1]', 'int')) MinCatalogVersion
FROM [CI_ConfigurationItems] as CI
WHERE CIType_ID = 8
"@
# Execute the SQL query and retrieve the latest catalog version
$connectionString = "Data Source=$serverName;Initial Catalog=$databaseName;Integrated Security=SSPI;"
$connection = New-Object System.Data.SqlClient.SqlConnection($connectionString)
$command = New-Object System.Data.SqlClient.SqlCommand($query, $connection)
$connection.Open()
$result = $command.ExecuteScalar()
$connection.Close()
# Display the result of the SQL query
Write-Host "The latest catalog version is: $result"
# Set the registry values
$regPath = "HKLM:\SOFTWARE\Microsoft\SMS\Components\SMS_WSUS_SYNC_MANAGER"
Set-ItemProperty -Path $regPath -Name "ContentVersion" -Value $result -Type DWORD
Set-ItemProperty -Path $regPath -Name "SyncToVersion" -Value $result -Type DWORD
Set-ItemProperty -Path $regPath -Name "LastAttemptVersion" -Value ($result - 1) -Type DWORD
This script retrieves the latest catalog version and configures it in the registry so that SCCM can recognize it. After executing this script, you must initiate a “Synchronize Software Updates” action from the SCCM console. Then, SCCM agents should perform a “Machine Policy Refresh” to obtain the latest catalog version and an “Update Evaluation Cycle” to apply the changes.
Your updates should then start installing, and in UpdatesDeployment.log, you will see that updates are now “functional.”
For more details on this issue, you can refer to the original article by Roger Zander here in English. Huge thanks to him for the article, which I translated and modified by adding a script to automate the fix.
