Jean-Sébastien DUCHENE Blog's

Actualité, Tips, Articles sur l'ensemble des Technologies Microsoft (SCCM/SMS, EMS, Microsoft Intune, Microsoft Azure, Windows 10, SCOM, MDOP...)

[SCCM CB] Optimiser la gestion des mises à jour logicielle en assainissant son catalogue WSUS (nettoyage base de données, etc.)

Depuis plusieurs mois maintenant, je rencontre des problématiques récurrentes autour de la gestion des mises à jour logicielles via System Center Configuration Manager chez tous les clients que je rencontre. Parmi ces problèmes, on retrouve :

  • L’incapacité de déployer des mises à jour pendant le déploiement de système d’exploitation
  • Des tempêtes d’analyses/scans ou une taille du catalogue de mises à jour (métadonnées) engendrant une surconsommation de la bande passante
  • Des clients qui ne se mettent pas à jour correctement en ne récupérant pas la liste de mises à jour comme attendu (timeout).
  • Une surcharge importante du serveur hébergeant le rôle Software Utapdate Point

Les symptômes peuvent trouver leurs origines dans différentes raisons et je vais aborder l’une d’entre elles qui reste la plus commune et mérite une maintenance régulière.

Avec les années, les entreprises ont utilisé System Center Configuration Manager pour mettre à jour différents produits et classifications. Avec l’arrivée de Windows 10, la multiplication des versions et la complexité du système de mises à jour. La quantité de métadonnées présentent dans le catalogue des serveurs WSUS a explosé. Il n’est pas rare de voir des clients récupérer un catalogue WSUS allant jusqu’à plusieurs centaines de mégaoctets. Ceci peut engendrer des timeouts lors de la récupération de ce catalogue et une surcharge de l’infrastructure. La multiplication des timeouts a l’effet pervers d’augmenter le nombre d’aller/retour des clients sur le serveur WSUS et ainsi d’empirer la situation.

Avant d’aller plus loin, sachez que les manipulations réalisées dans cet article sont à vos risques et périls. Pour assainir son catalogue WSUS, il peut y’avoir un certain nombre d’actions de maintenance :

  1. Reconfigurer les classifications, langues et produits selon vos besoins
  2. Reconfigurer les règles de remplacement des mises à jour
  3. Configurer le nettoyage intégré après la synchronisation
  4. Lancer manuellement le nettoyage WSUS
  5. Décliner les mises à jour remplacées
  6. Décliner les mises à jour inutiles
  7. Supprimer les mises à jour déclinées
  8. Réindexer la base de données WSUS

 

1. Reconfigurer les classifications, langues et produits selon vos besoins

C’est la première action à réaliser ! Vous devez revalider les classifications, les langues et produits et s’assurer que vous ne synchronisez que ce dont vous avez besoin.

Pour ce faire, ouvrez la console d’administration, et naviguez dans Administration – Site Configuration – Sites. Sélectionnez le site puis Configure Site Components – Software Update Point.

Pour reconfigurer les classifications, choisissez l’onglet classifications :

Par exemple si vous ne déployez pas de mises à jour de fonctionnalités, vous pouvez aisément décocher Upgrades.

 

Pour configurer les produits, sélectionnez l’onglet Products :

Retirez tous les produits que vous n’utilisez plus (Windows 2000, Windows XP, etc.). Une autre erreur commune est de cocher les produits ayant la mention :

  • <…> and later drivers
  • <…> and later upgrade and servicing drivers
  • <…> and later servicing drivers
  • <…> Dynamic Update
  • <…> Feature On-Demand
  • <…> GDR-DU
  • Windows 10 LTSB
  • <…> Language Interface Packs
  • <…> Drivers

Ces produits ne sont pas supportés par Configuration Manager et ne peuvent pour l’instant pas être déployés par ce biais. Visez donc à assainir la partie produit.

 

Faites de même dans l’onglet Languages en retirant toutes les langues que vous n’utilisez plus :

 

Une fois la reconfiguration effectuée, vous pouvez lancer une synchronisation en naviguant dans Software Library – Software Updates – All Software Updates. Cliquez droit sur All Software Updates et sélectionnez Synchronize Software Updates.

 

2. Reconfigurer les règles de remplacement des mises à jour

Une erreur assez commune est aussi de configurer des règles de remplacement avec un délai relativement long. Par défaut, Configuration Manager expire les mises à jour remplacées après 3 mois. Avec le changement de la stratégie de Microsoft visant à fournir des correctifs cumulatifs, ce délai peut être réduit. Il n’est plus nécessaire de garder des mises à jour remplacées sur plusieurs mois. Vous pouvez donc aisément réduire ce délai à 2 mois voire même expirer immédiatement les mises à jour.

Le choix de la valeur dépend de vos prérequis en matière de suivi du déploiement. L’expiration immédiate de la mise à jour arrêtera son déploiement et frisera donc votre pourcentage de conformité. Si vous devez atteindre un objectif (par exemple 98% de machines conformes), vous devez donc laisser un délai suffisant pour que les machines puissent continuer à récupérer les mises à jour. Néanmoins, les machines privilégieront potentiellement l’application d’une mise à jour plus récente.

Depuis Configuration Manager 1810, les règles de remplacement sont séparées pour les mises à jour classiques et les mises à niveau (Features Update/Upgrades). Pour ce faire naviguez dans la console d’administration puis dans Administration – Site Configuration – Sites. Sélectionnez le site puis Configure Site Components – Software Update Point. Sélectionnez l’onglet Supersedence Rules :

 

3. Configurer le nettoyage intégré après la synchronisation

Depuis plusieurs versions de Configuration Manager Current Branch, il est maintenant possible d’exécuter un nettoyage de WSUS intégré après la synchronisation des mises à jour. Le mécanisme comporte de nombreux points faibles mais permet de faire un premier nettoyage. L’activation peut donc être bénéfique pour réaliser une maintenance récurrente.

Pour ce faire naviguez dans la console d’administration puis dans Administration – Site Configuration – Sites. Sélectionnez le site puis Configure Site Components – Software Update Point. Sélectionnez l’onglet Supersedence Rules. Cochez la case Run WSUS Cleanup after synchronization:

 

4. Lancer manuellement le nettoyage WSUS

Cette opération doit être réalisée sur l’ensemble des serveurs WSUS associé au site ou à la hiérarchie Configuration Manager.

Avant de réaliser cette opération, procédez à la sauvegarde de la base de données WSUS ainsi que la sauvegarde du site SCCM.

Une action préliminaire à ce nettoyage en profondeur peut être lancer manuellement l’assistant de nettoyage de WSUS. Pour ce faire, ouvrez la console d’administration de WSUS. Déroulez le nom du serveur WSUS puis Options. Sélectionnez Server Cleanup Wizard.

Sur l’assistant, cochez l’ensemble des cases et lancez l’opération de nettoyage :

 

5. Décliner les mises à jour remplacées

Cette opération doit être réalisée sur l’ensemble des serveurs WSUS associé au site ou à la hiérarchie Configuration Manager.

Avant de réaliser cette opération, procédez à la sauvegarde de la base de données WSUS ainsi que la sauvegarde du site SCCM.

Bien que Configuration Manager expire les mises à jour remplacées, un nombre important de mises à jour ont pu passer outre ce mécanisme. Pour cela, je vous recommande le script Decline-SupersededUpdates.ps1 que l’équipe Configuration Manager a fourni sur son blog.

Lancez PowerShell en tant qu’administrateur et naviguez où vous avez stocker le script. Exécutez la commande suivante :

.\Decline-SupersededUpdates.ps1 -UpdateServer <NomDuServer> -Port 8530 -ExclusionPeriod XX -SkipDecline

Le paramètre ExclusionPeriod permet de spécifier le nombre de jours depuis la date d’aujourd’hui. Si vous avez spécifié une période dans les règles de remplacement des mises à jour, vous devez réutiliser cette valeur (nombre de mois) et convertir en jours. Si vous expirez immédiatement les mises à jour remplacées, vous pouvez retirer ce paramètre.

Le paramètre SkipDecline permet de lancer la commande sans véritablement décliner les mises à jour. Un fichier CSV permet de revalider

Vous pouvez ajouter le paramètre -UseSSL si WSUS est configuré en mode SSL. Il vous faudra aussi changer le port avec 8531.

Par exemple :

.\Decline-SupersededUpdates.ps1 -UpdateServer WSUSSERVER -Port 8531 -ExclusionPeriod 60

Je vous recommande d’exécuter la commande avec le paramètre -SkipDecline afin de vérifier la liste des mises à jour dans le fichier CSV. Une fois validé, relancez la commande sans ce paramètre.

 

6. Décliner les mises à jour inutiles

Cette opération doit être réalisée sur l’ensemble des serveurs WSUS associé au site ou à la hiérarchie Configuration Manager. Commencez par le site le plus haut dans la hiérarchie puis descendez sur les serveurs WSUS des sites primaires et des sites secondaires.

Avant de réaliser cette opération, procédez à la sauvegarde de la base de données WSUS ainsi que la sauvegarde du site SCCM.

Maintenant que nous avons réalisé les opérations de nettoyage des mises à jour remplacées, nous pouvons réaliser une opération plus agressive de nettoyage des mises à jour inutiles. On peut par exemple penser :

  • Aux mises à jour Itanium pour les produits Windows Server
  • Aux mises à jour ARM64 pour Windows 10
  • Aux mises à jour pour des produits inutilisés : Windows 2000, Windows XP, Windows 2003, etc. En effet certaines mises à jour ne sont jamais déclinées.
  • Aux mises à niveau (Feature update) dans des langues, des architectures, des éditions (Team, Education, etc.) non présentes dans votre parc informatique.
  • Aux mises à niveau Office 365 ProPlus qui ne seraient pas déployées (Targeted, First Release, Monthly Channel, etc.)
  • Aux mises à jour Version Next de Windows 10 et Windows Server qui ont été proposées pour les versions préliminaires.
  • Aux mises à jour s’appliquant à des versions Windows 10 qui ne sont pas présentes sur votre parc.
  • Aux anciennes mises à jour Windows 7 qui pourraient être inclues dans les Cumulative Updates que vous déployez.
  • Aux préversions (Preview) des mises à jour (Cumulatives, etc.)

La liste est non exhaustive et peut être enrichie avec d’autres cas selon vos usages.

Attention : Toutes mises à jour déclinées qui sont ensuite supprimées, ne peuvent plus être retrouvées. Il vous faudra réinstaller WSUS et recréer la base de données. Réfléchissez donc bien avant de décliner une mise à jour !!

Pour ce faire, vous devez ouvrir la console d’administration WSUS et naviguer dans Update Services - <NOMSERVER> - Updates – All Updates. Sur cette vue, vous devez sélectionner le mode Approval : Any Except Declined avec le Statut Any.

Vous retrouvez la liste des mises à jour non expirées. Vous retrouvez notamment le nombre total de mises à jour ayant un statut autre qu’expiré et le nombre total de mises à jour (incluant les mises à jour expirées).

Vous pouvez ensuite via la fonction recherche (Search…) pour rechercher les mises à jour via un mot clé. Par exemple, si vous savez que vous n’aurez jamais d’édition Education sur votre Parc ; vous pouvez alors décliner toutes les mises à niveau ciblant ces versions.

Faites une revue complète de toutes les mises à jour listées puis sélectionner-les et choisissez Decline :

 

Validez la fenêtre d’avertissement pour décliner les mises à jour. Vérifiez le nombre associé.

 

Une fois terminé, rafraichissez la vue pour voir le nombre de mises à jour non déclinées se réduire. Répétez l’opération pour toutes les mises à jour éligibles à votre contexte (ARM64, anciennes mises à jour Windows 2000, langues de mise à niveau non présentes dans votre parc etc.) selon la liste que j’ai détaillée plus haut. Par exemple si vous n’avez que des systèmes d’exploitation anglais et français, vous pouvez retirer toutes les mises à niveau des autres langues (Feature Update). Veillez à ne pas retirer des langues qui pourraient être introduites dans le futur. Vous devez aussi valider le type d’édition éventuelle sur votre parc (Consumer ou Business). Je ne saurais vous recommander que de garder les deux si des machines venaient à apparaître dans une édition consumer.

 

Notez toutes les mises à jour déclinées de manière à répéter l’opération sur l’ensemble des serveurs WSUS de votre hiérarchie. Les serveurs WSUS partageant la même base de données ne nécessite la réalisation de l’opération qu’une seule fois.

 

Pour les mises à jour Itanium (si vous avez activé des produits relatifs à Windows Server), vous pouvez utiliser le script suivant. Ce dernier déclinera automatiquement toutes les mises à jour en utilisant la commande : .\Decline-WsusItaniumUpdates.ps1 -WsusServer <NOMDUSERVER> -PortNumber 8530 -TrialRun $false

 

7. Supprimer les mises à jour déclinées

Cette opération doit être réalisée sur l’ensemble des serveurs WSUS associé au site ou à la hiérarchie Configuration Manager. Commencez par le site le plus haut dans la hiérarchie puis descendez sur les serveurs WSUS des sites primaires et des sites secondaires.

Avant de réaliser cette opération, procédez à la sauvegarde de la base de données WSUS ainsi que la sauvegarde du site SCCM.

Une fois le déclin des mises à jour réalisé, nous allons pouvoir physiquement supprimer les mises à jour déclinées de la base de données.

ATTENTION ! Cette opération est irréversible et supprimera définitivement la mise à jour sans avoir la possibilité de la réinjecter. Vous devez donc être sûr en revalidant les mises à jour déclinées avant de lancer cette suppression.

Pour cette opération, on retrouve deux scripts potentiels que je vous recommande d’exécuter. Le premier est script SQL et a été réalisé par Benjamin Reynolds (MSFT). Vous pouvez le retrouver sur le site de Steve Thompson (MVP). Il permet notamment d’ajouter un index permettant d’optimiser l’opération tout en supprimer une partie des mises à jour déclinées.

Si vous déployez les mises à jour de définition Windows Defender ou System Center Endpoint Protection, vous observerez un grand nombre de mises à jour de définition déclinées.

Vous avez deux cas :

  • Soit la base de données est hébergée sur SQL Server (configuration préférable pour des raisons de maintenance)
  • Soit la base de données utilise Windows Internal Database.

Dans le premier cas pour exécuter le script, ouvrez SQL Server Management Studio avec un compte utilisateur ayant les droits sur l’instance et sur la base de données WSUS (SUSDB). Chargez le script via un fichier tsql ou procédez à la création d’une requête (New Query) en copiant/collant le script tsql. Enfin, lancez l’exécution et laissez tourner. Vous pouvez observer l’avancement de la suppression et le nombre total de mises à jour à supprimer dans l’onglet Messages de la sous-partie de SQL Server Management Studio :

 

Dans le second cas (WID) pour exécuter le script, utiliser les outils en ligne de commande sqlcmd en pointant sur l’emplacement du script :

sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query –i <emplacement du script>\DeclineUpdates.sql

 

Pour vérifier qu’il ne reste pas de mises à jour à supprimer, ouvrez PowerShell en tant qu’administrateur et utiliser les cmdlets PowerShell suivantes :

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer()

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | Out-Null

$wsus.getupdates() | Where {$_.isdeclined -match 'true'} | ForEach-Object { $wsus.DeleteUpdate($_.Id.UpdateID); Write-Host $_.Title removed }

 

Notez toutes les mises à jour déclinées de manière à répéter l’opération sur l’ensemble des serveurs WSUS de votre hiérarchie. Les serveurs WSUS partageant la même base de données ne nécessite la réalisation de l’opération qu’une seule fois.

Cette opération réalisée, la taille du catalogue de mises à jour à considérablement baissée et la taille des métadonnées téléchargées par les clients aussi. Outre l’impact sur le réseau, cela allège les phases d’analyse du catalogue sur les clients.

 

8. Réindexer la base de données WSUS

Une fois les opérations de nettoyage terminées, je vous recommande de procéder à la ré-indexation de la base de données WSUS. Ceci peut être réalisé de différentes manières. On retrouve les célèbres scripts de maintenance d’Ola Hallengren mais vous pouvez aussi utiliser le script proposé par les ScriptingGuys. Le second est dédié à WSUS et peut être plus facile à utiliser.

Pour exécuter le script, ouvrez SQL Server Management Studio avec un compte utilisateur ayant les droits sur l’instance et sur la base de données WSUS (SUSDB). Chargez le script via un fichier tsql ou procédez à la création d’une requête (New Query) en copiant/collant le script tsql. Enfin, lancez l’exécution et laissez tourner. Vous pouvez observer l’avancement de la suppression et le nombre total de mises à jour à supprimer dans l’onglet Messages de la sous-partie de SQL Server Management Studio :

Même remarque si la base de données est hébergée via Windows Internal Database (WID), vous devez exécuter le script via la commande :

sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query –i <scriptLocation>\WsusDBMaintenance.sql

Ces scripts peuvent être exécuter de manière hebdomadaire afin d’assurer une indexation correcte de la base de données. Note la base de données WID n’ayant pas d’agent SQL Server, il vous faudra planifier l’exécution via une tâche planifiée par exemple.

Facebook Like
Anonymous