MECM | AlexIn Tech

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

Tue, 13 Jun 2023 00:00:00 +0000

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.

Réinstaller WSUS et le rôle Software Update Point dans ConfigMgr

Thu, 06 Oct 2022 00:00:00 +0000

Réinstaller WSUS et le rôle Software Update Point dans ConfigMgr

J’ai été confronté récemment à quelques soucis d’erreur de synchronisation au niveau du Software Update Point dans SCCM / MECM . Il faut savoir que le rôle SUP dans ConfigMgr va piloter le rôle serveur WSUS. J’ai tenté un reset de WSUS mais au final ça m’a purement et simplement tout planté. Donc je dois repartir sur une base saine et pour se faire j’ai tout désinstallé et tout réinstallé.

Je te fais la version courte ci-dessous et une version plus longue en dessous.

La version courte

Afin de remettre le tout d’équerre voici la version courte à suivre en step by step :

Lancer la console de ConfigMgr et désinstaller le rôle SUP (Software Update Point) dans ConfigMgr
Lancer Server Manager et désinstaller le rôle WSUS du serveur.
Reboot du serveur
Ensuite deux options s’offrent à toi, soit supprimer/restaurer la DB SUSDB de ton serveur SQL , soit la conserver. Dans mon cas j’avais un backup fonctionnel qui datait de avant que je foute le dawa donc j’ai fait le choix de restaurer ma DB et j’ai tout OVERWRITE.
Lancer Server Manager et installer le rôle WSUS sur le serveur => Comme j’ai un serveur MS SQL dessus je choisis l’option “SQL Server Connectivity” et non WID. Je spécifie mon instance SQL Server et le tour est joué, je lance l’install.
Depuis la fenêtre de succès de l’installation de WSUS, cliquer sur “Launch Post-Installation tasks”. Il va ainsi détecter si une DB SUSDB existe ou non, si non, il la créée, si oui , alors il va utiliser l’existante. Dans mon cas il a détecté ma DB que j’ai restaurée auparavant et l’a utilisée.
Reboot du serveur
Lancer la console de ConfigMgr et installer le rôle SUP (Software Update Point) dans ConfigMgr
Depuis ConfigMgr, lancer une synchro à vide (sans produits) => histoire de vérifier si tout fonctionne bien. (log wsyncmgr.log)
Configurer ton rôle SUP (choisir les produits et les classifications)
Lancer une synchro et revérifier si tout fonctionne bien (log wsyncmgr.log)

Et voilà, le tour est joué tu as réinstallé WSUS et le rôle SUP de ConfigMgr.

Si tu as un soucis de mismatch avec la version du catalogue entre ConfigMGR et WSUS, voici un fix à appliquer: https://rzander.azurewebsites.net/query-to-get-mincatalogversion-from-sccm-updates/

En espérant que ça t’a aidé , dans mon cas ça ronronne ! 😎

La version longue

Cette version est la même que la courte mais avec quelques screenshots et infos en plus.

1) Désinstaller le rôle Software Update Point de ConfigMgr

Lancer la console de SCCM/MECM et aller dans Administration>Overview>Site Configuration>Servers and Site System Roles.

Cliquer sur le site concerné puis effectuer un clique droit sur “Software update point” et choisir “Remove Role”

Suivre le step by step pour désinstaller le rôle.

2) Désinstaller le rôle WSUS du serveur

Lancer Server Manager , cliquer dans “Manage” puis “Remove Roles and Features”

Il faut décocher un produit pour le désinstaller, dans notre cas on décoche “Windows Server Update Services”

Cliquer sur Next et suivre le step by step.

3) Reboot du serveur

4) Ensuite deux options s’offrent à toi, soit supprimer/restaurer la DB SUSDB de ton serveur SQL , soit la conserver.

Dans mon cas j’avais un backup fonctionnel qui datait de avant que je foute le dawa donc j’ai fait le choix de restaurer ma DB et j’ai tout OVERWRITE.

5) Installer le rôle WSUS sur le serveur

Lancer Server Manager et installer le rôle WSUS sur le serveur => Comme j’ai un serveur MS SQL dessus je choisis l’option “SQL Server Connectivity” et non WID. Je spécifie mon instance SQL Server et le tour est joué, je lance l’install.

6) Lancer la Post-Install

Depuis la fenêtre de succès de l’installation de WSUS, cliquer sur “Launch Post-Installation tasks”. Il va ainsi détecter si une DB SUSDB existe ou non, si non, il la créée, si oui , alors il va utiliser l’existante. Dans mon cas il a détecté ma DB que j’ai restaurée auparavant et l’a utilisée.

Il y a un log de PostInstall disponible dans le dossier de l’utilisateur courant C:\Users\CurrentUserThatMadeTheInstall\local\Temp\WSUS_PostInstall_XXXXXXXXXX.log

7) Reboot du serveur

8) Installer le rôle SUP dans ConfigMgr

Lancer la console de SCCM/MECM et aller dans Administration>Overview>Site Configuration>Servers and Site System Roles.

Faire un clique droit sur le site concerné puis cliquer sur “Add Site System Roles”

Effectuer le setup en ayant choisi le rôle “Software Update Point” et en ne sélectionnant aucun produits car nous allons faire une première synchronisation à vide. Cliquer sur les produits afin de tous les sélectionner lors puis recliquer dessus afin d’être sûr qu’aucun produit n’est sélectionner. (à faire pendant le setup)

9) Lancer une première synchro à vide sans produits

Pour se faire aller dans “Software Library > Overview > Software Updates > All Software Updates”

Effectuer un clic droit sur “All Software Updates” et choisir “Synchronize Software Updates”

Vous pouvez effectuer le suivi de la synchro dans le log “wsyncmgr.log” .

10) Configurer ton rôle SUP (choisir les produits et les classifications)

Lancer la console de SCCM/MECM et aller dans Administration>Overview>Site Configuration>Servers and Site System Roles.

Cliquer sur le site concerné puis effectuer un clique droit sur “Software update point” et choisir “Properties”

Là tu pourra sélectionner ta classification ainsi que tes produits.

11) Lancer une synchro et revérifier si tout fonctionne bien

Pour se faire aller dans “Software Library > Overview > Software Updates > All Software Updates”

Effectuer un clic droit sur “All Software Updates” et choisir “Synchronize Software Updates”

Vous pouvez effectuer le suivi de la synchro dans le log “wsyncmgr.log” .

Et voilà, le tour est joué tu as réinstallé WSUS et le rôle SUP de ConfigMgr.

En espérant que ça t’a aidé , dans mon cas ça ronronne ! 😎

Trouver le sitecode SCCM (MECM) en PowerShell

Wed, 21 Sep 2022 00:00:00 +0000

Trouver le sitecode SCCM (MECM) en PowerShell

L’information du sitecode SCCM (MECM) est stockée dans WMI, nous pouvons donc aller rechercher l’info en utilisant du PowerShell.

Voici la commande à utiliser :

$SCCMSiteCode = $([WmiClass]"\\localhost\ROOT\ccm:SMS_Client").GetAssignedSite()
$SCCMSiteCode.sSiteCode

Si tu souhaites en savoir plus sur la méthode SMS_Client je te redirige sur ce lien :

https://msdn.microsoft.com/en-us/library/jj874307.aspx

Enjoy ! 😎