Corriger le problème de "CatalogVersion" entre SCCM et WSUS

Dans cet article, nous allons aborder un problème qui peut se produire après la récupération de WSUS ou SCCM. Ce problème se traduit par le fait que les mises à jour logicielles ne s'installent plus sur les clients SCCM. En examinant le UpdatesDeployment.log, vous pourriez trouver la mention :

'EnumerateUpdates for action (UpdateActionInstall) - Total actionable updates = 0 '.

Si vous faites une requête PowerShell sur un client pour lister toutes les mises à jour "manquantes" basées sur le catalogue WSUS, vous obtiendrez une liste de mises à jour "manquantes".

get-wmiobject -query "SELECT * FROM CCM_UpdateStatus" -namespace "root\ccm\SoftwareUpdates\UpdatesStore" | where {$_.status -eq "Missing"}

La commande PowerShell suivante va vous afficher toutes les mises à jours "en attente" d'être déployées.

get-wmiobject -query "SELECT * FROM CCM_SoftwareUpdate" -namespace "ROOT\ccm\ClientSDK"

Comme vous pourrez le constater, il ne retourne rien. Il a donc des mises à jours manquantes mais aucunes mises à jours "installables". SCCM ne reconnaît pas ces mises à jour comme "applicables" car la version du catalogue n'est pas la même entre WSUS et SCCM.

A chaque fois que SCCM synchronise avec succès le catalogue WSUS, il incrémente la "version du catalogue". Après une récupération du site, il se peut que SCCM réinitialise ce compteur et commence à partir de 0. Tant que le compteur n'aura pas atteint la valeur de la dernière version du catalogue alors les mises à jours seront considérées comme "non applicable".

J'ai créé un script qui vous aidera à résoudre ce problème en récupérant la dernière version du catalogue dans la base de données ConfigMgr et en settant cela dans le registre afin que ConfigMgr puisse afficher la bonne CatalogVersion et que vos clients puissent donc recevoir leurs mises à jours.

Voici le 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

Ce script permet de récupérer la version la plus récente du catalogue et de la configurer dans le registre pour qu'SCCM aille la récupérer. Par conséquent, après avoir exécuté ce script, il faut lancer une "Synchronize Software Updates" depuis la console SCCM. Ensuite, les agents SCCM doivent effectuer un "Machine-Policy refresh" pour obtenir la dernière version du catalogue et un "Update Evaluation Cycle" pour obtenir le changement.

Votre mise à jour devrait alors commencer à s'installer et dans le UpdatesDeployment.log, vous verrez que les mises à jour sont maintenant "fonctionnelles".

Pour plus de détails sur ce problème, vous pouvez consulter l'article original de Roger Zander ici en anglais. Milles merci à lui pour cet article que j'ai traduit et modifié à ma sauce en y ajoutant un script afin d'automatiser la correction.