In this article, we will discuss an issue that may occur after recovering WSUS or SCCM. This issue results in software updates no longer installing on SCCM clients. When looking at the UpdatesDeployment.log, you might find:
'EnumerateUpdates for action (UpdateActionInstall) - Total actionable updates = 0 '.
If you do a PowerShell query on a client to list all "missing" 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 show you all the "pending" to be deployed.
get-wmiobject -query "SELECT * FROM CCM_SoftwareUpdate" -namespace "ROOT\ccm\ClientSDK"
As you can see, it returns nothing. So it has missing updates but no "installable" updates. SCCM does not recognize these updates as "applicable" because the catalog version is not the same between WSUS and SCCM.
Each time SCCM successfully synchronizes 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 value of the latest catalog version then updates will be considered "not applicable" ;.
I created a script that will help you resolve this issue by fetching the latest version of the catalog from the ConfigMgr database and setting that in the registry so that ConfigMgr can display the correct CatalogVersion so that your customers can receive their 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 retrive 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 allows you to retrieve the most recent version of the catalog and configure it in the registry so that SCCM can retrieve it. Therefore, after running this script, you must run a "Synchronize Software Updates" from the SCCM console. Next, SCCM agents must perform a "Machine-Policy refresh" to obtain the latest version of the catalog and an "Update Evaluation Cycle" to achieve change.
Your update should then start to install and in the UpdatesDeployment.log you will see that the updates are now "functional".
For more details on this issue, you can refer to the original article by Roger Zander here in English. Many thanks to him for this article which I translated and modified to my liking by adding a script to automate the correction.