Bonnes pratiques relatives à Windows Server Update Services

Article
12/05/2023

Cet article fournit des conseils pour éviter les configurations qui présentent des performances médiocres en raison de limitations de conception ou de configuration dans WSUS.

Version de produit d’origine : Configuration Manager (Current Branch), Windows Server Update Services
Numéro de base de connaissances d’origine : 4490414

Limites de capacité

WSUS peut prendre en charge 100 000 clients par serveur (150 000 clients quand vous utilisez Configuration Manager). Il n’est toutefois pas recommandé d’approcher cette limite.

Envisagez plutôt d’utiliser une configuration de 2 à 4 serveurs qui partagent la même base de données SQL Server. Avec cette mesure de prudence, si un serveur tombe en panne, vous ne gâcherez pas votre week-end, car aucun client ne peut se mettre à jour, et ne subirez pas une attaque de type « zero-day ».

Le scénario de base de données partagée empêche également un afflux d’analyse (« scan storm »).

Une situation de « scan storm » peut se produire quand de nombreux clients changent de serveur WSUS et que les serveurs ne partagent pas de base de données. WSUS suit l’activité dans la base de données, afin que ces deux composants sachent ce qui a changé depuis la dernière analyse d’un client et n’envoient que les métadonnées mises à jour entre-temps.

Si les clients passent à un autre serveur WSUS qui utilise une base de données différentes, ils doivent effectuer une analyse complète, qui peut entraîner des transferts de métadonnées volumineux. Des transferts supérieurs à 1 Go par client peuvent se produire dans ces scénarios, en particulier si le serveur WSUS n’est pas géré correctement. La charge générée peut suffire à provoquer des erreurs quand les clients communiquent avec une instance WSUS. De plus, dans ce cas, les clients effectuent à plusieurs reprises de nouvelles tentatives.

Dans le cas du partage d’une base de données, quand un client bascule vers une autre instance WSUS qui utilise la même base de données, la pénalité d’analyse n’est pas appliquée. Les augmentations de charge ne sont pas la pénalité importante subie pour le changement de base de données.

Les analyses des clients Configuration Manager sollicitent davantage WSUS que les mises à jour automatiques autonomes. Étant donné qu’il inclut la vérification de la conformité, Configuration Manager demande des analyses selon des critères qui retournent toutes les mises à jour ayant n’importe quel état, sauf refusée.

Durant l’analyse de l’agent des mises à jour automatiques ou si vous sélectionnez Vérifier des mises à jour dans le Panneau de configuration, l’agent envoie des critères pour récupérer uniquement les mises à jour approuvées pour l’installation. Le volume de métadonnées retournées est généralement plus faible que quand l’analyse est lancée par Configuration Manager. L’agent de mise à jour met en cache les données, et les demandes d’analyse suivantes retournent les données du cache client.

Désactiver le recyclage et configurer les limites de mémoire

WSUS implémente un cache interne qui récupère les métadonnées de mise à jour de la base de données. Cette opération coûteuse nécessite beaucoup de mémoire. Elle peut entraîner le recyclage du pool d’applications IIS qui héberge WSUS (appelé WSUSPool) quand WSUSPool dépasse les limites de mémoire privée et virtuelle par défaut.

Lors du recyclage du pool, le cache est supprimé et doit être reconstruit. Il ne s’agit pas d’un problème important quand les clients font l’objet d’analyses delta. Toutefois, si vous vous retrouvez dans un scénario de « scan storm », le pool est recyclé en permanence. De plus, les clients reçoivent des erreurs quand vous effectuez des demandes d’analyse, telles que des erreurs HTTP 503.

Il est recommandé d’augmenter la longueur de la file d’attente par défaut et de désactiver la limite de mémoire virtuelle et privée en attribuant la valeur 0. IIS implémente un recyclage automatique du pool d’applications toutes les 29 heures, un test ping et un délai d’inactivité, qui doivent tous être désactivés. Ces paramètres se trouvent dans les pools> d’applications du Gestionnaire>IIS, choisissez WsusPool, puis cliquez sur le lien Paramètres avancés dans le volet droit du gestionnaire IIS.

Voici un résumé des modifications recommandées et une capture d’écran associée. Pour plus d’informations, consultez l’article Planifier les mises à jour logicielles dans Configuration Manager.

Nom du paramètre	Valeur
Longueur de la file d’attente	2000 (valeur par défaut : 1000)
Délai d’inactivité (minutes)	0 (valeur par défaut : 20)
Ping activé	False (valeur par défaut : True)
Limite de la mémoire privée (Ko)	0 (mémoire illimitée ; valeur par défaut : 1 843 200 Ko)
Intervalle de temps régulier (minutes)	0 (pour empêcher le recyclage ; valeur par défaut : 1740)

Capture d’écran des paramètres dans la fenêtre Paramètres avancés.

Dans un environnement où environ 17 000 mises à jour sont mises en cache, plus de 24 Go de mémoire peuvent être nécessaires quand le cache est généré jusqu’à ce qu’il se stabilise (à environ 14 Go).

Vérifier si la compression est activée (pour économiser la bande passante)

WSUS utilise un type de compression appellé « encodage Xpress ». Il implémente la compression sur les métadonnées de mise à jour et peut entraîner d’importantes économies de bande passante.

L’encodage Xpress est activé dans le fichier IIS ApplicationHost.config avec la ligne suivante sous l’élément <httpCompression> et un paramètre de Registre :

ApplicationHost.Config

<scheme name="xpress » doStaticCompression="false » doDynamicCompression="true » dll="C :\Program Files\Update Services\WebServices\suscomp.dll » staticCompressionLevel="10 » dynamicCompressionLevel="0 » />
Clé du Registre

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\IIsDynamicCompression

Si aucun de ces éléments n’est présent, activez l’encodage en exécutant cette commande, puis en redémarrant le pool d’applications WsusPool dans IIS.

cscript "%programfiles%\update services\setup\DynamicCompression.vbs" /enable "%programfiles%\Update Services\WebServices\suscomp.dll"

L’encodage Xpress augmente légèrement la surcharge du processeur et peut être désactivé si la bande passante n’est pas problématique, contrairement à l’utilisation du processeur. La commande suivante permet de le désactiver.

cscript "%programfiles%\update services\setup\DynamicCompression.vbs" /disable

Configurer les produits et catégories nécessaires

Quand vous configurez WSUS, choisissez uniquement les produits et catégories que vous prévoyez de déployer. Vous pouvez toujours synchroniser ultérieurement les catégories et les produits nécessaires. Si vous les ajoutez alors que vous n’envisagez pas de les déployer, vous augmentez la taille des métadonnées et la surcharge sur les serveurs WSUS.

Désactiver les mises à jour Itanium et les autres mises à jour inutiles

Ce problème sera bientôt résolu, car Windows Server 2008 R2 est la dernière version qui prend en charge Itanium. Il convient toutefois de le signaler.

Personnalisez et utilisez ce script dans votre environnement pour refuser les mises à jour de l’architecture Itanium. Le script peut également refuser les mises à jour dont le titre contient Preview (Pré-version) ou Beta (Version bêta).

Ce script permet à la console WSUS d’être plus réactive, sans perturber l’analyse du client.

Refuser les mises à jour remplacées et exécuter la maintenance

ll s’agit de l’une des choses les plus importantes que vous pouvez faire pour améliorer l’exécution de WSUS. Conserver les mises à jour qui sont remplacées plus longtemps que nécessaire (par exemple, une fois que vous ne les déployez plus) est la cause principale des problèmes de performances de WSUS. Vous pouvez les conserver durant leur déploiement, mais il est recommandé de les supprimer par la suite.

Pour plus d’informations sur le refus des mises à jour remplacées et d’autres éléments de maintenance de WSUS, consultez l’article Guide complet de la maintenance de Microsoft WSUS et de Configuration Manager SUP.

WSUS avec configuration SSL

Par défaut, WSUS n’est pas configuré pour utiliser SSL pour la communication avec les clients. La première étape après l’installation doit consister à configurer SSL sur WSUS pour garantir la sécurité des communications entre serveur et client.

Vous devez effectuer l’une des actions suivantes :

Créez un certificat auto-signé. Cette action n’est pas idéale, car chaque client doit approuver ce certificat.
Obtenir un certificat auprès d’un fournisseur de certificats tiers.
Obtenir un certificat auprès de l’infrastructure de certificats interne.

Votre certificat doit avoir le nom court de serveur, le nom de domaine complet (FQDN) et les noms SAN (alias) correspondants.

Une fois le certificat installé, mettez à niveau la stratégie de groupe (ou les paramètres de configuration du client pour les mises à jour logicielles dans Configuration Manager) pour utiliser l’adresse et le port SSL du serveur WSUS. Le port est généralement 8531 ou 443.

Par exemple, configurez l’objet de stratégie de groupe spécifier l’emplacement du service de mise à jour Microsoft intranet surhttps://wsus.contoso.com:8531<> .

Pour commencer, consultez la section Sécuriser WSUS avec le protocole SSL (Secure Sockets Layer).

Configurer les exclusions d’antivirus

Informations sur les mises à jour cumulatives et les correctifs cumulatifs mensuels

Vous pouvez rencontrer les termes « correctif cumulatif mensuel » et « mise à jour cumulative » utilisés dans le cadre des mises à jour du système d’exploitation Windows. Ces termes peuvent être utilisés indifféremment. Les correctifs cumulatifs désignent les mises à jour publiées pour Windows 7, Windows 8.1, Windows Server 2008 R2 et Windows Server 2012 R2 qui sont uniquement partiellement cumulatives.

Pour plus d’informations, consultez les billets de blog suivants :

Simplified servicing for Windows 7 and Windows 8.1: the latest improvements (en anglais uniquement)
More on Windows 7 and Windows 8.1 servicing changes (en anglais uniquement)

Avec Windows 10 et Windows Server 2016, les mises à jour étaient cumulatives depuis le début :

Windows 10 update servicing cadence

Dans le cas d’une mise à jour cumulative, vous installez la version commerciale du système d’exploitation et vous devez uniquement appliquer la dernière mise à jour cumulative pour quel e système soit entièrement corrigé. Pour les systèmes d’exploitation plus anciens, ce type de mise à jour n’existe pas encore, même si c’est la voie qui est empruntée.

Par conséquent, pour Windows 7 et Windows 8.1, après l’installation du dernier correctif cumulatif mensuel, d’autres mises à jour sont toujours nécessaires. Voici un exemple pour Windows 7 et Windows Server 2008 R2 qui indique comment obtenir un système presque entièrement corrigé.

Le tableau ci-dessous contient la liste des correctifs cumulatifs mensuels et des mises à jour cumulatives Windows. Vous pouvez également les trouver en recherchant l’historique des mises à jour de version> Windows<.

Version de Windows	Update
Windows 7 SP1 et Windows Server 2008 R2 SP1	Historique des mises à jour de Windows 7 SP1 et de Windows Server 2008 R2 SP1
Windows 8.1 et Windows Server 2012 R2	Historique des mises à jour de Windows 8.1 et de Windows Server 2012 R2
Windows 10 et Windows Server 2016	Historique des mises à jour de Windows 10 et de Windows Server
Windows Server 2019	Historique des mises à jour de Windows 10 et de Windows Server 2019

Un autre point à prendre en compte est que les mises à jour ne sont pas toutes publiées pour être synchronisées automatiquement avec WSUS. Par exemple, les mises à jour cumulatives des semaines C et D sont des mises à jour de pré-version et ne sont pas synchronisées avec WSUS, mais doivent être importées manuellement. Consultez la section Monthly quality updates de l’article Windows 10 update servicing cadence.

Utilisation de PowerShell pour se connecter à un serveur WSUS

Voici un exemple de code pour vous aider à démarrer avec PowerShell et l’API WSUS. Vous pouvez l’exécuter à l’emplacement où la console d’administration WSUS est installée.

[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$WSUSServer = 'WSUS'
# This is your WSUS Server Name
$Port = 8530
# This is 8531 when SSL is enabled
$UseSSL = $False
#This is $True when SSL is enabled
Try
{
    $Wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($WSUSServer,$UseSSL,$Port)
}
Catch
{
    Write-Warning "$($WSUSServer)<$($Port)>: $($_)"
    Break
}

Partager via