Guide complet de la maintenance de Microsoft WSUS et de Configuration Manager SUP

Cet article répond à certaines questions courantes sur la maintenance WSUS pour Configuration Manager environnements.

Version du produit d’origine : Serveurs Windows, Windows Server Update Services, Configuration Manager
Numéro de base de connaissances d’origine : 4490644

Introduction

Les questions portent souvent sur la façon d’exécuter correctement cette maintenance dans un environnement Configuration Manager, ou sur la fréquence d’exécution de cette maintenance. Il n’est pas rare que les administrateurs Configuration Manager de conscience ignorent que la maintenance WSUS doit être exécutée du tout. La plupart d’entre nous viennent de configurer des serveurs WSUS, car il s’agit d’un prérequis pour un point de mise à jour logicielle (SUP). Une fois le sup configuré, nous fermons la console WSUS et supposons qu’elle n’existe pas. Malheureusement, cela peut être problématique pour Configuration Manager clients et les performances globales du serveur WSUS/SUP.

En comprenant que cette maintenance doit être effectuée, vous vous demandez quelle maintenance vous devez effectuer et à quelle fréquence vous devez le faire. La réponse est que vous devez effectuer une maintenance mensuelle. La maintenance est facile et ne prend pas longtemps pour les serveurs WSUS qui ont été bien gérés depuis le début. Toutefois, si la maintenance WSUS a été effectuée depuis un certain temps, le nettoyage peut être plus difficile ou chronophage la première fois. Il sera beaucoup plus facile ou plus rapide dans les mois à venir.

Pour plus d’informations sur les étapes concises et les scripts automatiques, consultez Maintenance manuelle et automatique de la base de données WSUS.

Gérer WSUS tout en pris en charge Configuration Manager current branch version 1906 et versions ultérieures

Si vous utilisez Configuration Manager version current branch 1906 ou ultérieure, nous vous recommandons d’activer les options de maintenance WSUS dans la configuration du point de mise à jour logicielle sur le site de niveau supérieur pour automatiser les procédures de nettoyage après chaque synchronisation. Il gère efficacement toutes les opérations de nettoyage décrites dans cet article, à l’exception de la sauvegarde et de la réindexation de la base de données WSUS. Vous devez toujours automatiser la sauvegarde de la base de données WSUS, ainsi que la réindexation de la base de données WSUS selon une planification.

Pour plus d’informations sur la maintenance des mises à jour logicielles dans Configuration Manager, consultez La maintenance des mises à jour logicielles.

Remarques importantes

1. Avant de commencer le processus de maintenance, lisez toutes les informations et instructions de cet article.

2. Lorsque vous utilisez WSUS avec des serveurs en aval, les serveurs WSUS sont ajoutés du haut vers le bas, mais doivent être supprimés du bas vers le haut. Lors de la synchronisation ou de l’ajout de mises à jour, elles passent d’abord au serveur WSUS en amont, puis répliquent vers les serveurs en aval. Lorsque vous effectuez un nettoyage et supprimez des éléments des serveurs WSUS, vous devez commencer en bas de la hiérarchie.

3. La maintenance WSUS peut être effectuée simultanément sur plusieurs serveurs du même niveau. Dans ce cas, assurez-vous qu’un niveau est effectué avant de passer au niveau suivant. Les étapes de nettoyage et de réindexation décrites ci-dessous doivent être exécutées sur tous les serveurs WSUS, qu’ils soient ou non un serveur WSUS de réplication. Pour plus d’informations sur la détermination si un serveur WSUS est un réplica, consultez Refuser les mises à jour remplacées.

4. Assurez-vous que les SUP ne se synchronisent pas pendant le processus de maintenance, car cela peut entraîner la perte d’un travail déjà effectué. Vérifiez la planification de synchronisation SUP et définissez-la temporairement sur manuellement pendant ce processus.

   

5. Si vous avez plusieurs suPs du site principal ou de l’administration centrale qui ne partagent pas la base de données SUSDB, considérez le serveur WSUS qui se synchronise avec le premier serveur sup sur le site comme résidant dans un niveau situé sous le site. Par exemple, mon site d’administration centrale comporte deux sups :

   • Celui nommé Nouvelle synchronisation avec Microsoft Update, il s’agirait de mon niveau supérieur (niveau 1).
   • Le serveur intitulé « 2012 » se synchronise avec « Nouveau » et sera considéré comme le second niveau. Il peut être nettoyé en même temps que je ferais tous mes autres serveurs de niveau 2, tels que le sup unique de mon site principal.

   

Effectuer la maintenance WSUS

Les étapes de base nécessaires à la maintenance WSUS appropriée sont les suivantes :

1. Sauvegarder la base de données WSUS
2. Créer des index de champ personnalisé
3. Réindexer la base de données WSUS
4. Refuser les mises à jour remplacées et exécuter la maintenance
5. Assistant de nettoyage du serveur WSUS.

Sauvegarder la base de données WSUS

Sauvegardez la base de données WSUS (SUSDB) à l’aide de la méthode souhaitée. Pour plus d’informations, consultez Créer une sauvegarde complète de base de données.

Créer des index de champ personnalisé

Ce processus est facultatif, mais recommandé, il améliore considérablement les performances lors des opérations de nettoyage suivantes.

Si vous utilisez Configuration Manager current branch version 1906 ou une version ultérieure, nous vous recommandons d’utiliser Configuration Manager pour créer les index. Pour créer les index, configurez l’option Ajouter des index non cluster à l’option de base de données WSUS dans la configuration du point de mise à jour logicielle pour le site le plus haut.

Si vous utilisez une version antérieure de Configuration Manager ou des serveurs WSUS autonomes, procédez comme suit pour créer des index personnalisés dans la base de données SUSDB. Pour chaque SUSDB, il s’agit d’un processus unique.

1. Vérifiez que vous disposez d’une sauvegarde de la base de données SUSDB.

2. Utilisez SQL Management Studio pour vous connecter à la base de données SUSDB, comme décrit dans la section Réindexer la base de données WSUS .

3. Exécutez le script suivant sur SUSDB pour créer deux index personnalisés :

   -- Create custom index in tbLocalizedPropertyForRevision
   USE [SUSDB]
   
   CREATE NONCLUSTERED INDEX [nclLocalizedPropertyID] ON [dbo].[tbLocalizedPropertyForRevision]
   (
        [LocalizedPropertyID] ASC
   )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
   
   -- Create custom index in tbRevisionSupersedesUpdate
   CREATE NONCLUSTERED INDEX [nclSupercededUpdateID] ON [dbo].[tbRevisionSupersedesUpdate]
   (
        [SupersededUpdateID] ASC
   )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
   

   Si des index personnalisés ont été créés précédemment, l’exécution du script entraîne à nouveau une erreur similaire à celle qui suit :

   Msg 1913, Niveau 16, État 1, Ligne 1
   L’opération a échoué, car un index ou des statistiques nommés « nclLocalizedPropertyID » existent déjà sur la table « dbo.tbLocalizedPropertyForRevision ».

Réindexer la base de données WSUS

Pour réindexer la base de données WSUS (SUSDB), utilisez la réindexation du script T-SQL de la base de données WSUS .

Les étapes de connexion à SUSDB et d’exécution de la réindexation diffèrent, selon que SUSDB s’exécute dans SQL Server ou Base de données interne Windows (WID). Pour déterminer l’emplacement d’exécution de SUSDB, vérifiez la valeur de l’entrée SQLServerName de Registre sur le serveur WSUS situé sur la HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup sous-clé.

Si la valeur contient uniquement le nom du serveur ou de l’instance, SUSDB s’exécute sur un SQL Server. Si la valeur inclut la chaîne ##SSEE ou ##WID dans celle-ci, SUSDB s’exécute dans WID, comme indiqué :

Si SUSDB a été installé sur WID

Si SUSDB a été installé sur WID, SQL Server Management Studio Express doit être installé localement pour exécuter le script de réindexation. Voici un moyen simple de déterminer la version de SQL Server Management Studio Express à installer :

• Pour Windows 10 version 2012 ou ultérieure :

  • Accédez au C:\Windows\WID\Log journal des erreurs qui contient le numéro de version.

  • Comment déterminer la version, l'édition et le niveau de mise à jour de SQL Server et de ses composants Cette valeur vous indique le niveau Service Pack (SP) en cours d’exécution. Incluez le niveau sp lors de la recherche de SQL Server Management Studio Express dans le Centre de téléchargement Microsoft.

• pour Windows Server 2008 R2 (KB3139164)

  • Accédez au C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\LOG dernier journal des erreurs et ouvrez-le avec le Bloc-notes. En haut, il y a un numéro de version (par exemple, 9.00.4035.00 x64). Comment déterminer la version, l'édition et le niveau de mise à jour de SQL Server et de ses composants Ce numéro de version vous indique le niveau Service Pack qu’il exécute. Incluez le niveau sp lors de la recherche de SQL Server Management Studio Express dans le Centre de téléchargement Microsoft.

Après avoir installé SQL Server Management Studio Express, lancez-la et entrez le nom du serveur auquel vous connecter :

• Si le système d’exploitation est Windows Server 2012 ou versions ultérieures, utilisez \\.\pipe\MICROSOFT##WID\tsql\query.
• Si le système d’exploitation est antérieur à Windows Server 2012, entrez \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query.

Pour WID, si des erreurs similaires à ce qui suit se produisent lors d’une tentative de connexion à SUSDB à l’aide de SQL Server Management Studio (SSMS), essayez de lancer SSMS à l’aide de l’option Exécuter en tant qu’administrateur.

Si SUSDB a été installé sur SQL Server

Si SUSDB a été installé sur une SQL Server complète, lancez SQL Server Management Studio et entrez le nom du serveur (et de l’instance si nécessaire) lorsque vous y êtes invité.

Exécution du script

Pour exécuter le script dans SQL Server Management Studio ou SQL Server Management Studio Express, sélectionnez Nouvelle requête, collez le script dans la fenêtre, puis sélectionnez Exécuter. Une fois l’opération terminée, un message de requête exécuté avec succès s’affiche dans la barre d’état. Et le volet Résultats contient des messages liés aux index qui ont été reconstruits.

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

Refusez les mises à jour remplacées dans le serveur WSUS pour aider les clients à analyser plus efficacement. Avant de refuser les mises à jour, assurez-vous que les mises à jour remplacées sont déployées et que celles remplacées ne sont plus nécessaires. Configuration Manager inclut un nettoyage distinct, qui lui permet d’expirer les mises à jour remplacées en fonction des critères spécifiés. Pour plus d’informations, consultez les articles suivants :

• Règles de remplacement
• Comportement de nettoyage WSUS à partir de la version 1810

La requête SQL suivante peut être exécutée sur la base de données SUSDB pour déterminer rapidement le nombre de mises à jour remplacées. Si le nombre de mises à jour remplacées est supérieur à 1 500, cela peut entraîner divers problèmes liés aux mises à jour logicielles côté serveur et côté client.

-- Find the number of superseded updates
Select COUNT(UpdateID) from vwMinimalUpdate where IsSuperseded=1 and Declined=0

Si vous utilisez Configuration Manager version current branch 1906 ou une version ultérieure, nous vous recommandons de refuser automatiquement les mises à jour remplacées en activant les mises à jour ayant expiré dans WSUS en fonction de l’option de règles de remplacement dans la configuration du point de mise à jour logicielle pour le site le plus haut.

Lorsque vous utilisez cette option, vous pouvez voir combien de mises à jour ont été refusées en examinant le fichier WsyncMgr.log une fois le processus de synchronisation terminé. Si vous utilisez cette option, vous n’avez pas besoin d’utiliser le script décrit plus loin dans cette section (soit en l’exécutant manuellement, soit en le configurant comme tâche pour l’exécuter selon une planification).

Si vous utilisez des serveurs WSUS autonomes ou une version antérieure de Configuration Manager, vous pouvez refuser manuellement les mises à jour remplacées à l’aide de la console WSUS. Vous pouvez également exécuter ce script PowerShell. Ensuite, copiez et enregistrez le script en tant que fichier de scriptDecline-SupersededUpdatesWithExclusionPeriod.ps1 .

Si Configuration Manager est défini sur Expirer immédiatement les mises à jour remplacées (voir ci-dessous), le script PowerShell peut être utilisé pour refuser toutes les mises à jour remplacées. Elle doit être effectuée sur tous les serveurs WSUS autonomes de la hiérarchie Configuration Manager/WSUS.

Vous n’avez pas besoin d’exécuter le script PowerShell sur des serveurs WSUS définis en tant que réplicas, tels que des SKU de site secondaire. Pour déterminer si un serveur WSUS est un réplica, vérifiez les paramètres de la source de mise à jour .

Si les mises à jour ne sont pas configurées pour expirer immédiatement dans Configuration Manager, le script PowerShell doit être exécuté avec une période d’exclusion qui correspond au paramètre Configuration Manager pour le nombre de jours d’expiration des mises à jour remplacées. Dans ce cas, cela fait 60 jours que les propriétés du composant SUP sont configurées pour attendre deux mois avant l’expiration des mises à jour remplacées :

Les lignes de commande suivantes illustrent les différentes façons dont le script PowerShell peut être exécuté :

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -Port 8530 –SkipDecline

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -Port 8530 –ExclusionPeriod 60

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -Port 8530

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -UseSSL -Port 8531

Exécution du script avec a -SkipDecline et -ExclusionPeriod 60 collecte des informations sur les mises à jour sur le serveur WSUS et le nombre de mises à jour pouvant être refusées :

Exécution du script avec -ExclusionPeriod 60, pour refuser les mises à jour remplacées antérieures à 60 jours :

Les indicateurs de sortie et de progression sont affichés pendant l’exécution du script. Notez le fichier SupersededUpdates.csv , qui contient une liste de toutes les mises à jour refusées par le script :

Une fois les mises à jour remplacées refusées, pour de meilleures performances, SUSDB doit être réindexé. Pour plus d’informations, consultez Réindexer la base de données WSUS.

Assistant de nettoyage du serveur WSUS.

L’Assistant Nettoyage du serveur WSUS fournit des options pour nettoyer les éléments suivants :

• Mises à jour inutilisées et révisions de mises à jour (également appelées mises à jour obsolètes)
• Ordinateurs ne contactant pas le serveur
• Fichiers de mise à jour inutiles
• Mises à jour expirées
• Mises à jour remplacées

Dans un environnement Configuration Manager, les ordinateurs qui ne contactent pas le serveur et les options de fichiers de mise à jour inutiles ne sont pas pertinents, car Configuration Manager gère le contenu et les appareils de mise à jour logicielle, sauf si les options Créer tous les événements de création de rapports WSUS ou Créer uniquement des événements de rapport d’état WSUS sont sélectionnées sous Paramètres de synchronisation des mises à jour logicielles. Si l’une de ces options est configurée, vous devez envisager d’automatiser le nettoyage du serveur WSUS pour effectuer le nettoyage de ces deux options.

Si vous utilisez Configuration Manager version current branch 1906 ou une version ultérieure, l’activation des mises à jour expirées de Decline dans WSUS conformément aux règles de remplacement gère le déclin des mises à jour expirées et des mises à jour remplacées en fonction des règles de remplacement spécifiées dans Configuration Manager. L’activation de l’option Supprimer les mises à jour obsolètes de l’option de base de données WSUS dans Configuration Manager current branch version 1906 gère le nettoyage des mises à jour inutilisées et des révisions de mise à jour (mises à jour obsolètes). Il est recommandé d’activer ces options dans la configuration du point de mise à jour logicielle sur le site de niveau supérieur pour permettre à Configuration Manager de nettoyer la base de données WSUS.

Si vous n’avez jamais nettoyé les mises à jour obsolètes de la base de données WSUS, cette tâche peut expirer. Vous pouvez consulter WsyncMgr.log pour plus d’informations et exécuter manuellement le script SQL spécifié dans HELP ! Mon WSUS a été en cours d’exécution pendant des années sans jamais avoir la maintenance effectuée et l’Assistant nettoyage garde le minutage une fois, ce qui permettrait les tentatives suivantes de Configuration Manager pour s’exécuter avec succès. Pour plus d’informations sur le nettoyage et la maintenance WSUS dans Configuration Manager, consultez la documentation.

Pour les serveurs WSUS autonomes, ou si vous utilisez une version antérieure de Configuration Manager, il est recommandé d’exécuter régulièrement l’Assistant Nettoyage WSUS. Si l’Assistant Nettoyage du serveur WSUS n’a jamais été exécuté et que WSUS est en production depuis un certain temps, le nettoyage peut expirer. Dans ce cas, réindexez d’abord les étapes 2 et 3 , puis exécutez le nettoyage avec uniquement l’option Mises à jour inutilisées et révisions de mise à jour activée.

Si vous n’avez jamais exécuté l’Assistant Nettoyage WSUS, l’exécution du nettoyage avec les mises à jour inutilisées et les révisions de mise à jour peut nécessiter quelques passes. S’il expire, exécutez-le à nouveau jusqu’à ce qu’il se termine, puis exécutez chacune des autres options l’une après l’autre. Enfin, effectuez une passe complète avec toutes les options vérifiées. Si des délais d’expiration continuent de se produire, consultez l’alternative SQL Server dans HELP! Mon WSUS a été en cours d’exécution pendant des années sans jamais avoir la maintenance effectuée et l’Assistant nettoyage garde le délai d’attente. L’Exécution de l’Assistant Nettoyage du serveur ou sqL peut prendre plusieurs heures ou jours.

L’Assistant Nettoyage du serveur WSUS s’exécute à partir de la console WSUS. Il se trouve sous Options, comme illustré ici :

Pour plus d’informations, consultez la section Afficher le journal des erreurs SQL Server.

Une fois qu’il a signalé le nombre d’éléments qu’il a supprimés, le nettoyage se termine. Si vous ne voyez pas ces informations retournées sur votre serveur WSUS, il est sûr de supposer que le nettoyage a expiré. Dans ce cas, vous devez le redémarrer ou utiliser l’alternative SQL.

Une fois les mises à jour remplacées refusées, pour de meilleures performances, SUSDB doit être réindexé. Pour plus d’informations, consultez la section Réindexer la base de données WSUS .

Dépannage

aide Mon WSUS a été en cours d’exécution pendant des années sans jamais avoir la maintenance effectuée et l’Assistant nettoyage garde le délai d’attente

Il existe deux options différentes ici :

1. Réinstallez WSUS avec une nouvelle base de données. Il existe un certain nombre de mises en garde à ce sujet, notamment la longueur de la synchronisation initiale et les analyses client complètes sur SUSDB, par rapport aux analyses différentielles.

2. Vérifiez que vous disposez d’une sauvegarde de la base de données SUSDB, puis exécutez une réindexation. Une fois cette opération terminée, exécutez le script suivant dans SQL Server Management Studio ou SQL Server Management Studio Express. Une fois l’opération terminée, suivez toutes les instructions ci-dessus pour exécuter la maintenance. Cette dernière étape est nécessaire, car la spDeleteUpdate procédure stockée supprime uniquement les mises à jour inutilisées et les révisions de mise à jour.

DECLARE @var1 INT
DECLARE @msg nvarchar(100)

CREATE TABLE #results (Col1 INT)
INSERT INTO #results(Col1) EXEC spGetObsoleteUpdatesToCleanup

DECLARE WC Cursor
FOR
SELECT Col1 FROM #results

OPEN WC
FETCH NEXT FROM WC
INTO @var1
WHILE (@@FETCH_STATUS > -1)
BEGIN SET @msg = 'Deleting' + CONVERT(varchar(10), @var1)
RAISERROR(@msg,0,1) WITH NOWAIT EXEC spDeleteUpdate @localUpdateID=@var1
FETCH NEXT FROM WC INTO @var1 END

CLOSE WC
DEALLOCATE WC

DROP TABLE #results

L’exécution du script Decline-SupersededUpdatesWithExclusionPeriod.ps1 expire lors de la connexion au serveur WSUS, ou une erreur 401 se produit lors de l’exécution

Si des erreurs se produisent lorsque vous tentez d’utiliser le script PowerShell pour refuser les mises à jour remplacées, un autre script SQL peut être exécuté sur SUDB.

1. Si Configuration Manager est utilisé avec WSUS, vérifiez les règles de remplacement des propriétés>de composant du point de mise à jour logicielle pour voir à quel point les mises à jour remplacées expirent rapidement, par exemple immédiatement ou après X mois. Notez ce nom.

   

2. Si vous n’avez pas sauvegardé la base de données SUSDB, faites-le avant de continuer.

3. Utilisez SQL Server Management Studio pour vous connecter à SUSDB.

4. Exécutez la requête suivante. Le nombre 90 dans la ligne qui inclut DECLARE @thresholdDays INT = 90 doit correspondre aux règles de remplacement de l’étape 1 de cette procédure, et au nombre correct de jours qui s’alignent sur le nombre de mois configurés dans les règles de remplacement. Si cette valeur est définie pour expirer immédiatement, la valeur de la requête @thresholdDays SQL doit être définie sur zéro.

   -- Decline superseded updates in SUSDB; alternative to Decline-SupersededUpdatesWithExclusionPeriod.ps1
   DECLARE @thresholdDays INT = 90 -- Specify the number of days between today and the release date for which the superseded updates must not be declined (i.e., updates older than 90 days). This should match configuration of supersedence rules in SUP component properties, if ConfigMgr is being used with WSUS.
   DECLARE @testRun BIT = 0 -- Set this to 1 to test without declining anything.
   -- There shouldn't be any need to modify anything after this line.
   
   DECLARE @uid UNIQUEIDENTIFIER
   DECLARE @title NVARCHAR(500)
   DECLARE @date DATETIME
   DECLARE @userName NVARCHAR(100) = SYSTEM_USER
   
   DECLARE @count INT = 0
   
   DECLARE DU CURSOR FOR
     SELECT MU.UpdateID, U.DefaultTitle, U.CreationDate FROM vwMinimalUpdate MU
     JOIN PUBLIC_VIEWS.vUpdate U ON MU.UpdateID = U.UpdateId
   WHERE MU.IsSuperseded = 1 AND MU.Declined = 0 AND MU.IsLatestRevision = 1
     AND MU.CreationDate < DATEADD(dd,-@thresholdDays,GETDATE())
   ORDER BY MU.CreationDate
   
   PRINT 'Declining superseded updates older than ' + CONVERT(NVARCHAR(5), @thresholdDays) + ' days.' + CHAR(10)
   
   OPEN DU
   FETCH NEXT FROM DU INTO @uid, @title, @date
   WHILE (@@FETCH_STATUS > - 1)
   BEGIN
     SET @count = @count + 1
     PRINT 'Declining update ' + CONVERT(NVARCHAR(50), @uid) + ' (Creation Date ' + CONVERT(NVARCHAR(50), @date) + ') - ' + @title + ' ...'
     IF @testRun = 0
        EXEC spDeclineUpdate @updateID = @uid, @adminName = @userName, @failIfReplica = 1
     FETCH NEXT FROM DU INTO @uid, @title, @date
   END
   
   CLOSE DU
   DEALLOCATE DU
   
   PRINT CHAR(10) + 'Attempted to decline ' + CONVERT(NVARCHAR(10), @count) + ' updates.'
   

5. Pour vérifier la progression, surveillez l’onglet Messages dans le volet Résultats .

Que se passe-t-il si j’ai découvert que j’avais besoin d’une des mises à jour que j’ai refusées ?

Si vous décidez d’avoir besoin de l’une de ces mises à jour refusées dans Configuration Manager, vous pouvez la récupérer dans WSUS en cliquant avec le bouton droit sur la mise à jour et en sélectionnant Approuver. Remplacez l’approbation par Non approuvé, puis resynchronisez le sup pour rétablir la mise à jour.

Si la mise à jour n’est plus dans WSUS, elle peut être importée à partir du catalogue Microsoft Update, si elle n’a pas expiré ou n’a pas été supprimée du catalogue.

Automatisation de la maintenance WSUS

Les tâches de maintenance WSUS peuvent être automatisées, en supposant que quelques exigences sont d’abord remplies.

1. Si vous n’avez jamais exécuté le nettoyage WSUS, vous devez effectuer les deux premiers nettoyages manuellement. Votre deuxième nettoyage manuel doit être exécuté 30 jours à partir de votre premier, car il faut 30 jours pour que certaines mises à jour et révisions de mise à jour expirent. Il existe des raisons spécifiques pour lesquelles vous ne souhaitez pas automatiser avant votre deuxième nettoyage. Votre premier nettoyage s’exécutera probablement plus longtemps que d’habitude. Vous ne pouvez donc pas déterminer combien de temps cette maintenance prendra normalement. Le deuxième nettoyage est un meilleur indicateur de ce qui est normal pour vos machines. Cela est important, car vous devez déterminer le temps nécessaire à chaque étape en tant que ligne de base (j’aime également ajouter une salle de basculement d’environ 30 minutes) afin que vous puissiez déterminer le minutage de votre planification.

2. Si vous avez des serveurs WSUS en aval, vous devez d’abord effectuer la maintenance sur ces serveurs, puis effectuer les serveurs en amont.

3. Pour planifier la réindexation de la base de données SUSDB, vous avez besoin d’une version complète de SQL Server. Base de données interne Windows (WID) n’a pas la possibilité de planifier une tâche de maintenance bien que SQL Server Management Studio Express. Cela dit, dans les cas où wid est utilisé, vous pouvez utiliser le planificateur de tâches avec SQLCMD mentionné précédemment. Si vous effectuez cette route, il est important de ne pas synchroniser vos serveurs/suPs WSUS pendant cette période de maintenance ! Si c’est le cas, il est possible que vos serveurs en aval finissent par resynchroniser toutes les mises à jour que vous venez de tenter de nettoyer. Je planifie cette opération pendant la nuit avant ma synchronisation AM. J’ai donc le temps de vérifier la synchronisation avant l’exécution de ma synchronisation.

Liens nécessaires/utiles :

• Réindexer la base de données WSUS
• Option de configuration du serveur XPs de l’agent
• Scripteur de week-end : utiliser le planificateur de tâches Windows pour exécuter un script Windows PowerShell

Script de nettoyage WSUS

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")`
 | out-null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("SERVERNAME",$true,PORT);
$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;
$cleanupScope.DeclineSupersededUpdates = $true
$cleanupScope.DeclineExpiredUpdates = $true
$cleanupScope.CleanupObsoleteUpdates = $true
$cleanupScope.CompressUpdates = $true
#$cleanupScope.CleanupObsoleteComputers = $true
$cleanupScope.CleanupUnneededContentFiles = $true
$cleanupManager = $wsus.GetCleanupManager();
$cleanupManager.PerformCleanup($cleanupScope);

Configuration de la tâche de nettoyage WSUS dans le planificateur de tâches

Le billet de blog weekend Scripter mentionné dans la section précédente contient des instructions de base et la résolution des problèmes pour cette étape. Toutefois, je vais vous guider tout au long du processus dans les étapes suivantes.

1. Ouvrez le planificateur de tâches , puis sélectionnez Créer une tâche. Sous l’onglet Général , définissez le nom de la tâche, l’utilisateur sur lequel vous souhaitez exécuter le script PowerShell (la plupart des utilisateurs utilisent un compte de service). Sélectionnez Exécuter si un utilisateur est connecté ou non, puis ajoutez une description si vous le souhaitez.

   

2. Sous l’onglet Actions , ajoutez une nouvelle action et spécifiez le programme/script que vous souhaitez exécuter. Dans ce cas, nous devons utiliser PowerShell et le pointer vers le fichier PS1 que nous voulons qu’il exécute. Vous pouvez utiliser le script de nettoyage WSUS. Ce script effectue des options de nettoyage qui n’Configuration Manager current branch version 1906. Vous pouvez les annuler si vous utilisez WSUS autonome ou une version antérieure de Configuration Manager. Si vous souhaitez un journal, vous pouvez modifier la dernière ligne du script comme suit :

   Note

   Lorsque vous exécutez le script sur le serveur WSUS, utilisez LOCALHOST plutôt que le script réel SERVERNAME. En outre, remplacez-en PORT l’utilisation.

   [reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null
   $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("SERVERNAME",$true,PORT);
   $cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;
   # $cleanupScope.DeclineSupersededUpdates = $true # Performed by CM1906
   # $cleanupScope.DeclineExpiredUpdates    = $true # Performed by CM1906
   # $cleanupScope.CleanupObsoleteUpdates   = $true # Performed by CM1906
   $cleanupScope.CompressUpdates          = $true
   $cleanupScope.CleanupObsoleteComputers = $true
   $cleanupScope.CleanupUnneededContentFiles = $true
   $cleanupManager = $wsus.GetCleanupManager();
   $cleanupManager.PerformCleanup($cleanupScope) | Out-File C:\WSUS\WsusClean.txt;
   

   Vous recevrez une erreur d’identification/avertissement dans le planificateur de tâches lorsque vous enregistrez. Vous pouvez ignorer cet avertissement.

   

3. Sous l’onglet Déclencheurs , définissez votre planification pour une fois par mois ou selon la planification souhaitée. Là encore, vous devez vous assurer que vous ne synchronisez pas votre WSUS pendant l’intégralité du nettoyage et de la réindexation.

   

4. Définissez d’autres conditions ou paramètres que vous souhaitez également modifier. Lorsque vous enregistrez la tâche, vous pouvez être invité à entrer les informations d’identification de l’utilisateur d’identification .

5. Vous pouvez également utiliser ces étapes pour configurer le script Decline-SupersededUpdatesWithExclusionPeriod.ps1 à exécuter tous les trois mois. J’ai l’habitude de définir ce script pour s’exécuter avant les autres étapes de nettoyage, mais seulement après l’avoir exécuté manuellement et j’ai vérifié qu’il s’est terminé avec succès. Je cours à 00h00 le premier dimanche tous les trois mois.

Configuration de la réindexation SUSDB pour WID à l’aide de SQLCMD et du planificateur de tâches

1. Enregistrez le script de base de données Reindex WSUS sous la forme d’un fichier .sql (par exemple, SUSDBMaint.sql).

2. Créez une tâche de base et donnez-lui un nom :

   

3. Planifiez le démarrage de cette tâche environ 30 minutes après la fin de l’exécution de votre nettoyage. Mon nettoyage est en cours d’exécution à 1h00 tous les premiers dimanches. L’exécution prend environ 30 minutes et je vais lui donner 30 minutes de plus avant de commencer ma réindexation. Cela signifie que je planifierais cette tâche tous les premiers dimanches à 2h00, comme illustré ici :

   

4. Sélectionnez l’action pour démarrer un programme. Dans la zone Programme/script , tapez la commande suivante. Fichier spécifié après le -i paramètre est le chemin d’accès au script SQL que vous avez enregistré à l’étape 1. Le fichier spécifié après le paramètre est l’emplacement -o où vous souhaitez placer le journal. Voici un exemple :

   "C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.exe" -S \\.\pipe\Microsoft##WID\tsql\query -i C:\WSUS\SUSDBMaint.sql -o c:\WSUS\reindexout.txt

   

5. Vous recevrez un avertissement, similaire à celui que vous avez reçu lors de la création de la tâche de nettoyage. Sélectionnez Oui pour accepter les arguments, puis sélectionnez Terminer pour appliquer :

   

6. Vous pouvez tester le script en le forçant à s’exécuter et en examinant le journal à la recherche d’erreurs. Si vous rencontrez des problèmes, le journal vous indique pourquoi. En général, en cas d’échec, le compte exécutant la tâche ne dispose pas des autorisations appropriées ou le service WID n’est pas démarré.

Configuration d’une tâche de maintenance planifiée de base dans SQL pour les SUSDB non WID

1. Démarrez Microsoft SQL Server Management Studio et connectez-vous à l’instance de votre serveur local. Développez Gestion, cliquez avec le bouton droit sur Plans de maintenance, puis sélectionnez Nouveau plan de maintenance. Attribuez un nom à votre plan.

   

2. Sélectionnez sous-plan1 , puis vérifiez que votre boîte à outils est dans le contexte :

   

3. Faire glisser la tâche Exécuter la tâche de l’instruction T-SQL.

   

4. Cliquez avec le bouton droit sur Windows.edb, puis sélectionnez Propriétés. Copier et coller le script de réindexation WSUS, puis cliquer sur OK.

   

5. Planifiez l’exécution de cette tâche environ 30 minutes après la fin de l’exécution de votre nettoyage. Mon nettoyage est en cours d’exécution à 1h00 tous les premiers dimanches. L’exécution prend environ 30 minutes, et je vais lui donner 30 minutes de plus avant de commencer la réindexation. Cela signifie que je planifierais cette tâche pour qu’elle s’exécute tous les premiers dimanches à 2h00.

   

6. Lors de la création du plan de maintenance, envisagez également d’ajouter une sauvegarde du FICHIER SUSDB dans le plan. J’ai l’habitude de sauvegarder en premier, puis réindexer. Cela peut ajouter plus de temps à la planification.

Exemple complet

Lors de son exécution dans une hiérarchie, l’exécution du nettoyage WSUS doit être effectuée à partir du bas de la hiérarchie. Toutefois, lorsque vous utilisez le script pour refuser les mises à jour remplacées, l’exécution doit être effectuée à partir du haut vers le bas. Le déclin des mises à jour remplacées est en fait un type d’ajout à une mise à jour plutôt qu’une suppression. Dans ce cas, vous ajoutez un type d’approbation .

Étant donné qu’une synchronisation ne peut pas être effectuée pendant le nettoyage réel, il est recommandé de planifier/d’effectuer toutes les tâches du jour au lendemain. Vérifiez ensuite leur achèvement par le biais de la journalisation le lendemain matin, avant la synchronisation planifiée suivante. En cas d’échec, la maintenance peut être replanifiée pour la nuit suivante, une fois le problème sous-jacent identifié et résolu.

Ces tâches peuvent s’exécuter plus rapidement ou plus lentement en fonction de l’environnement, et le minutage de la planification doit le refléter. J’espère qu’ils sont plus rapides, car mon environnement de laboratoire a tendance à être un peu plus lent qu’un environnement de production normal. Je suis un peu agressif sur le minutage des scripts de déclin. Si tier2 chevauche Tier3 de quelques minutes, cela ne causera pas de problème, car ma synchronisation n’est pas planifiée pour s’exécuter.

Le fait de ne pas synchroniser empêche les baisses de circuler accidentellement dans mes serveurs WSUS de réplica de niveau 3 à partir du niveau 2. Je me suis donné plus de temps entre le déclin tier3 et le nettoyage tier3, car je veux certainement m’assurer que le script de déclin se termine avant d’exécuter mon nettoyage.

Cela soulève une question courante : étant donné que je ne synchronise pas, pourquoi ne pas exécuter tous les nettoyages et réindexations en même temps ?

La réponse est que vous pourriez probablement, mais je ne le ferais pas. Si mon collègue à travers le monde a besoin d’exécuter une synchronisation, avec cette planification, je minimiserais le risque de mises à jour orphelines dans WSUS. Et je peux planifier sa réexécution pour se terminer la nuit suivante.

Pour plus d’informations sur les espaces de noms disjoints, consultez les articles suivants :

• Gérer la maintenance des mises à jour logicielles
• Maintenance des mises à jour logicielles dans Configuration Manager