Le blog technique

Suite au remplacement du serveur de site dans une infrastructure SCCM, les clients ne recevaient plus aucune mise à jour.

L’analyse du fichier de log UpdatesDeployment.log révèle le message “EnumerateUpdates for action (UpdateActionInstall) – Total actionable updates = 0 ‘ “.

Bien qu’il ne s’agisse pas à proprement parler d’une erreur, cette information est manifestement erronée : il y a bien des mises à jour manquantes, et l’exécution de la commande powershell suivante sur un client en donne la liste :

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

Le client SCCM n’en reconnait pourtant aucune comme actionnable, comme le montre cette nouvelle commande qui ne renvoie rien :

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

Il faut savoir qu’à chaque synchronisation du catalogue WSUS, SCCM incrémente la version du catalogue. Cela permet aux agents de savoir si une version plus récente que celle qu’ils ont déjà téléchargé est disponible.

Or, lors du changement de serveur ou de la restauration d’une sauvegarde, il arrive que ce compteur reparte de 0… Si votre infrastructure SCCM existe depuis longtemps, il pourrait donc falloir des milliers de mise à jour du catalogue avant que la version n’atteigne à nouveau celle attendue par les agents!

Heureusement, le correctif est simple : il suffit de modifier dans le registre la version du catalogue afin de reprendre là où les agents s’étaient arrêté.

Commencons donc par identifier la version du catalogue qu’attendent les agents, à l’aide de la requête SQL suivante qui indique la plus haute valeur attendue :

;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  

Il faut ensuite incrémenter d’une unité cette valeur, puis l’insérer dans la base de registre dans les clés suivantes :

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_WSUS_SYNC_MANAGER]
"ContentVersion"=x
"SyncToVersion"=x
"LastAttemptVersion"=x

Enfin, il faut exécuter une nouvelle synchronisation du catalogue dans SCCM afin que sa valeur reflète les modifications effectuées (ou attendre la prochaine synchronisation planifiée), puis exécuter un Machine policy refresh suivi d’un Update evaluation cycle sur les agents si vous souhaitez forcer le téléchargement des mises à jour.

Encore un petit souci de jeunesse de la nouvelle console web introduite dans SCOM 1801 lorsque vous tentez d’y accéder depuis Internet Explorer 11, une page blanche est affichée alors qu’elle fonctionne parfaitement sous Chrome/Firefox/Edge.

Pour pallier ce problème, il suffit de rajouter le HTTP Host Header suivant dans IIS, pour les sites OperationsManager et MonitoringView :

Nom : X-UA-Compatible

Valeur: IE=edge

Ce problème est normalement réglé par le passage à SCOM 1807, mais si tel n’était pas le cas, ce contournement devrait vous permettre de rétablir un accès normal!

Encore un souci lié à la nouvelle console web, introduite dans SCOM 1801 : lors de la création d’une Notification pour envoyer des alertes par mail, il est d’usage d’intégrer dans le corps du mail l’URL permettant d’ouvrir la console web sur l’URL en question, en utilisant le raccourci généré par le wizard :

Seulement voilà, l’URL insérée ici est incorrecte, elle ne correspond pas à la nouvelle console Web et cette adresse renvoie donc à la page d’accueil de la console !

Ce bug a été corrigé lors du passage à SCOM 1807 :

On voit ici que le bon format d’URL à utiliser est en réalité $Target/Property[Type= »Notification!Microsoft.SystemCenter.AlertNotificationSubscriptionServer »]/WebConsoleUrl$/#/monitoring/drilldown/alert/$UrlEncodeData/Context/DataItem/AlertId$ , ce qui correspond au nouveau dashboard “Alert Drilldown”, auquel on accède normalement à partir d’un dashboard Alerts “nouvelle génération” (plus d’explications sur les nouveaux dashboards et les relations entre eux ici : https://blogs.technet.microsoft.com/momteam/2018/02/12/new-scom-web-console-blog-series-post4-the-all-new-drilldown-experience/ ) :

Malheureusement, cela engendre un nouveau problème : si l’utilisateur qui reçoit ce mail mais n’a qu’un accès limité à SCOM (permission accordée uniquement à quelques dossiers/vues), il risque fort de se trouver face à cet écran :

Ou, dans le meilleur des cas, celui-ci qui n’est pas beaucoup plus utile :

La raison en est que ce nouveau dashboard Alert Drilldown contient une série de widgets qui nécessitent également que l’utilisateur aie le droit d’y accéder individuellement. Or, cette permission n’est accordée par l’assistant User Roles que lorsqu’on accorde la permission à un dashboard qui y fait appel… dont aucun n’existe par défaut. Et même s’il en existait, vous pourriez très bien ne pas vouloir les montrer à tout le monde!

Un contournement serait donc de créer un dashboard Alerts “nouvelle génération”, de le cibler sur un groupe vide créé également pour l’occasion et d’en déléguer l’accès à tous les User Roles susceptibles de devoir accéder au Drilldown d’une alerte :

L’utilisateur devrait maintenant avoir accès au dashboard Drilldown alert :

En espérant que Microsoft corrige cela dans la prochaine version…