[Tuto] Installer, configurer et exploiter un serveur WSUS (+vidéo)

Microsoft a prévu, il y a des années maintenant, un rôle permettant aux administrateurs systèmes de gérer de façon centralisée l’ensemble des mises à jour des produits Microsoft dans leur parc informatique.

Ce service, bien que capricieux parfois, est tout de même très utile pour maintenir un parc à jour et donc sécurisé. Dans ce tuto, vous allez donc faire connaissance avec « Windows Server Update Services », alias WSUS !

Prendre en main WSUS pour assurer un suivi efficace des updates Microsoft

Bon allez on attaque direct avec une petite intro rapide concernant WSUS avant de commencer histoire de bien comprendre de quoi on parle sinon c’est nul…

Info ++ : Pour ceux qui sont allergiques à la lecture, rassurez-vous, il y a en réalité très peu de texte mais plus de 100 captures d’écran avec des explications simples .
Vous trouverez également un sommaire pour accéder directement à ce dont vous avez besoin sous cette introduction.

Windows Server Update Services, alias WSUS, comme vous l’aurez compris, est un service propre aux systèmes d’exploitation Windows qui permet de centraliser la gestion des mises à jour des produits Microsoft et d’avoir un suivi global de votre parc informatique niveau update.

Outre la gestion centralisée, il offre de nombreux avantages dont le principal étant indéniablement un gain de bande passante. En effet, les mises à jour pour les produits Microsoft dont vous avez besoin seront toutes stockées au même endroit, à savoir sur votre serveur WSUS.

Info + : Pour fonctionner, WSUS a besoin du service web IIS et d’une base de données. Il utilise pour communiquer des requêtes HTTP/HTTPS sur les ports, non pas 80 ou 443 qui sont ceux par défaut des protocoles web, mais les ports 8530 (http) et 8531 (https).

Dans un environnement sans WSUS, vos machines Windows vont toutes sur Internet pour récupérer leurs mises à jour chez Microsoft. Si vous avez 100 PC, les 100 PC vont donc émettre des requêtes sur le web pour demander au final souvent les mêmes choses…

Avec WSUS, c’est lui et lui seul qui va émettre des requêtes auprès des serveurs de Microsoft, donc au lieu d’avoir 100 PC qui vont tirer sur la bande passante, il n’y aura que le serveur ! Les postes clients interrogeront directement le serveur WSUS situé dans le réseau local, plus besoin de sortir sur Internet !

Autres avantages, vous pourrez sélectionner de façon minutieuse uniquement les mises à jour dont vous avez vraiment besoin dans votre parc et les tester sur une ou deux machines avant de les déployer à toutes les autres.

L’intérêt de tester une mise à jour sur une machine dédiée avant de l’autoriser sur le reste du parc est justement de limiter les petites catastrophes (un peu trop nombreuses dernièrement…) avec les mises à jour Windows, que ce soit à cause de pilotes ou de potentiels conflits avec des logiciels métier ou autres.

Grâce à WSUS, vous pourrez gérer en totalité la distribution des mises à jour de nombreux produits Microsoft dans votre réseau (antivirus, OS, pack office, cloud azure, messagerie exchange, service pack, drivers…). Alors on commence ?

⇒ Accès rapide aux différentes parties de cet article :

Démonstration en vidéo disponible au lien suivant : Installation, configuration et exploitation du service WSUS. La vidéo diffère quelque peu de l’article, elle n’est là que pour illustrer ce tuto et aider à mieux visualiser les manipulations.

1. Présentation rapide de l’infrastructure virtuelle

Commençons comme toujours par détailler le laboratoire virtuel mis en place… il est assez simple au final car je ne dispose pour la démo que d’un serveur 2019 et d’un ou deux clients Windows 10 qui sont sur le même réseau 192.168.3.0/24.

Info ++ : Le switch ainsi que le routeur sont virtuels, c’est mon hyperviseur (VMWare en l’occurrence) qui fait office de matériel physique. Pour cela, c’est à vous de configurer le réseau directement sur votre hyperviseur, ça ne sera pas détaillé ici.

WSUS est un service très gourmand en ressources, il faudra donc configurer le serveur en conséquence. Voici les spécifications techniques de ma machine virtuelle serveur :

2 CPU
8 Go de RAM (risque moins de poser problème avec WSUS)
2 disques de stockage de 50Go chacun (1 dédié uniquement au système d’exploitation, l’autre qui sera dédié au stockage des données du service WSUS car il est important de ne pas polluer l’OS)
1 carte réseau avec un adressage IP fixe et un accès à Internet

Si par la suite vous rencontrez l’erreur suivante en ouvrant la console de gestion du service WSUS, c’est que votre machine manque de mémoire vive, il faudra donc augmenter la RAM :

Pour la suite du tuto, j’estime que votre serveur est prêt. Comme vous pouvez le voir dans la capture suivante, je lui ai donné un nom, j’ai configuré une adresse IP fixe dans mon réseau virtuel, j’ai initialisé le second disque de stockage et j’ai vérifié son accès à internet par un simple ping vers google.fr qui fonctionne.

A ce stade, aucun rôle n’a encore été installé comme on peut le voir dans le gestionnaire de serveur, colonne de gauche.

Côté poste client, je l’ai simplement renommé et j’ai donné un adressage IP fixe complet car je n’ai pas mis de serveur DHCP. Je n’ai pas d’AD ni de DNS (j’utilise en DNS public) dans mon réseau car ça ne change rien au fonctionnement de WSUS en lui-même. Vous verrez dans le chapitre 6 que je fais référence à AD pour lier un poste client membre d’un domaine à WSUS via GPO mais rien de plus. A vous d’adapter les informations selon votre propre configuration.

Maintenant que votre infra est prête, nous pouvons passer à l’installation du rôle WSUS

2. Installation du rôle WSUS

Depuis le tableau de bord du gestionnaire de serveur, cliquez sur « Ajouter des rôles et des fonctionnalités ».

Vous aurez une première fenêtre « Avant de commencer » présentant la console, vous pouvez passer directement à la suivante en cliquant sur Suivant.

Ensuite, il vous faut sélectionner le type d’installation, dans notre cas, nous voulons installer un rôle donc on coche la première bulle et on clique sur Suivant.

Il faut sélectionner dans la liste le serveur sur lequel on souhaite installer le rôle. Ici c’est facile nous n’en avons qu’un seul donc on passe directement à la suite.

Maintenant, on peut sélectionner le rôle qui nous intéresse. Vous aurez ici la vue de tous les rôles disponibles sur le serveur. Recherchez dans la liste « Service WSUS » et cochez la case à gauche de son nom pour le sélectionner.

Une fenêtre va s’ouvrir automatiquement pour vous présenter les fonctionnalités nécessaires au rôle que vous voulez installer. Ces fonctionnalités sont obligatoires pour assurer un bon fonctionnement, cliquez sur « Ajouter des fonctionnalités » et faites Suivant.

La page suivante concerne justement les fonctionnalités. Nous les avons déjà ajoutés à l’étape précédente, donc on clique sur Suivant sans rien modifier.

Vous aurez ensuite une page de présentation très succincte du service que vous vous apprêtez à installer. Faites Suivant.

Laissez cochés les deux services de rôle déjà sélectionnés et faites simplement Suivant.

Info + : Un service de rôle est un logiciel complémentaire à un rôle pour en assurer le fonctionnement et son installation varie selon les besoins. Par exemple ici, le service WSUS a besoin d’une base de données, un service de rôle est prévu pour cela et il s’appelle « WID » (Windows Internal Database). Comme nous n’avons pas de serveur de base de données SQL par exemple dans notre infrastructure, autant utiliser le service de rôle WID directement.

Ensuite, il faut saisir l’emplacement où seront stockés toutes les données de notre service WSUS.

Souvenez-vous que le serveur possède un second disque de stockage prévu à cet effet. Donc dans mon cas, je saisis la lettre correspondant à mon second disque (C étant l’OS et D étant le lecteur CD) et je lui dis de mettre ça dans un dossier appelé « WSUS » pour être bien organisé (si le dossier n’existe pas, il sera créé automatiquement), ce qui me donne comme chemin de stockage « E:\WSUS »

Le service WSUS a besoin du rôle IIS (qui correspond au service web chez Microsoft) pour fonctionner, vous en avez une description dans la fenêtre suivante que vous pouvez passer.

Une fois encore, on ne touche rien aux services de rôle, on laisse ce qui est déjà coché par défaut (sauf si vous savez précisément ce que vous faites) et on clique sur Suivant.

On vérifie dans la fenêtre finale que tout ce dont on a besoin est bien prêt à être installé et on lance l’installation.

Patientez une à deux minutes le temps que tout se mette en place, de préférence ne fermez pas cette fenêtre.

Une fois l’installation des rôles achevée, l’assistant d’ajout de rôle vous informe que WSUS a besoin d’une configuration supplémentaire pour terminer. Cliquez sur « Lancer les tâches de post-installation ».

Patientez encore une petite minute, la configuration est en cours.

Tant que vous verrez le symbole attention dans le gestionnaire de serveur, cela signifie que votre serveur est en train de se configurer. Cela ne prend en général pas plus d’une minute.

L’assistant vous informe désormais qu’il a terminé, vous pouvez cliquer sur Fermer.

Dans votre gestionnaire de serveur, colonne de gauche, vous retrouvez désormais les rôles que vous venez d’installer et principalement le service WSUS.

Le rôle WSUS est désormais prêt à être configuré, passons donc à l’étape suivante !

3. Configuration du service WSUS et 1ère synchronisation

Le service WSUS est donc installé sur le serveur mais pas encore fonctionnel. Nous allons maintenant le configurer et initier une première synchronisation auprès des serveurs de Microsoft.

Commencez par ouvrir la console de gestion du service. Pour cela, dans le gestionnaire de serveur, colonne de gauche, cliquez sur « WSUS ». Ensuite faites un clic droit sur le nom de votre serveur puis « Services WSUS (Windows Server Update Services) ».

Comme c’est la première fois que l’on ouvre la console, l’assistant de configuration du service va se lancer automatiquement. Vous arrivez sur une page avec quelques informations de base, cliquez sur Suivant.

Vous pouvez choisir ou non d’envoyer des informations à Microsoft, personnellement chez moi c’est non donc je ne coche pas la case et je continue.

Il faut maintenant définir si le serveur actuel doit se synchroniser auprès de Microsoft directement ou auprès d’un autre serveur WSUS dans le réseau (oui vous pouvez avoir plusieurs serveurs WSUS dans votre réseau pour faire de la répartition de charge ou de la tolérance de panne par exemples). Pour nous, ce sera auprès de Microsoft, on laisse donc cochée la première bulle et on poursuit.

Le serveur vous demande si vous disposez d’un proxy pour accéder à Internet. Ce n’est pas le cas dans notre infrastructure, on ignore cette page.

Info + : Pour faire simple, un proxy est un logiciel qui permet de sécuriser et filtrer les accès à Internet. Il va jouer le rôle de mandataire en émettant les requêtes à votre place comme si c’était lui-même qui effectuait les demandes.

L’étape suivante consiste à établir un premier contact avec les serveurs de Microsoft afin de récupérer une liste des types de mises à jour disponibles. Cliquez sur le bouton « Démarrer la connexion ».

Cette étape va durer entre 10 et 15 minutes en moyenne, alors soyez patient 😉. Une fois terminée, vous pouvez poursuivre la configuration du service.

Commençons par choisir les langues pour nos mises à jour. Vous disposez de la liste de toutes les langues proposées par Microsoft.

Personnellement, je vais juste sélectionner le français, je décoche donc « Anglais ». Le serveur n’aime pas trop qu’on décoche l’anglais donc il risque de crier un peu . C’est normal, cliquez simplement sur OK si vous avez le message suivant :

Seul le français est bien sélectionné, on peut continuer.

Vous arrivez maintenant à la sélection des produits.

Le service WSUS permet de mettre à jour une quantité assez énorme de produits purement Microsoft, petit tour très rapide !

Vous trouverez des produits concernant le cloud de Microsoft nommé Azure ou encore le moteur de recherche Bing…

… mais aussi tout ce qui concerne Exchange, le service de messagerie de Microsoft…

… le pack Office bien sûr (la base ! )…

… le service de base de données SQL…

… l’antivirus natif Defender, le navigateur Edge, et même Internet Explorer dans ses versions antiques (RIP)…

… et bien entendu tous ses systèmes d’exploitation pour les postes clients…

… et les systèmes d’exploitation pour les serveurs. En résumé, il y a énormément de produits Microsoft disponibles (même des trucs utilisés au temps des pharaons !).

Dans le cadre de ce tuto (et pour soulager ma bande passante pourrie…), je ne vais sélectionner que les mises à jour de base pour le système d’exploitation de mon PC client Windows 10. Dans la liste des produits (vers la fin), je coche « Windows 10, version 1903 and later ». Mon poste client est sous Windows 21h1 mais ce n’est pas grave car en réalité le noyau n’a pas vraiment changé depuis la version 19h1, c’est pour cela que pour le moment, WSUS ne propose pas de versions plus récentes.

La fenêtre suivante va concerner les classifications c’est-à-dire le type de mises à jour que je souhaite gérer avec mon serveur. Cela peut comprendre, les mises à jour qui vont concerner la sécurité critique de la machine, des correctifs mineurs, des pilotes, des services pack… vous trouverez plus d’informations sur ces classifications dans la documentation officielle de Microsoft : Classifications WSUS.

Une fois encore, je vais sélectionner le minimum syndical, je ne coche donc ici que les « mises à jour de sécurité », à vous de choisir ce dont vous avez besoin.

Info ++ : Attention, plus vous sélectionnez de langues, produits et classifications, plus votre serveur aura besoin de ressources, surtout en termes d’espace disque car les mises à jour seront très volumineuses, sans compter que la première synchronisation et le premier téléchargement de tout ce que vous aurez choisi pourront également être trèèèsss longs.

Bien, maintenant j’ai sélectionné tout de dont j’avais besoin pour mon infrastructure. Il faut désormais configurer la synchronisation sur le serveur.

La synchronisation de WSUS signifie la correspondance que le serveur local va établir avec les serveurs de Microsoft pour récupérer de nouvelles mises à jour et vous les proposer. Il ne s’agit pas ici de téléchargement, attention à ne pas confondre « synchronisation » et « téléchargement ».

Vous pouvez la définir manuellement, il faudra donc que vous la lanciez vous-même pour être sûr d’obtenir les nouvelles mises à jour.

Vous pouvez également l’automatiser et la planifier à intervalles réguliers en sélectionnant une heure (je vous conseille vivement de planifier cela de nuit) et le nombre de synchronisation quotidienne dont vous avez besoin.

Dans mon cas, je vais rester en mode manuel.

La configuration du service WSUS est désormais terminée, la dernière fenêtre vous propose de lancer la première synchronisation afin de récupérer toutes les mises à jour disponibles selon les produits et classifications choisis. Cochez la case « Commencer la synchronisation initiale » et cliquez sur Terminer.

Cette première synchro de mon côté a pris environ 1 heure avec le peu de choses sélectionnés. Il faut être très patient avec WSUS et ne pas jouer les furieux car c’est lui qui gagnera toujours .

Voici la vue globale de la console de gestion de WSUS :

Dans le prochain chapitre, nous allons faire un tour du propriétaire pendant que la synchronisation est en cours.

4. Présentation globale de la console de gestion WSUS

C’est depuis cette console que vous pourrez gérer l’ensemble du service WSUS. En haut à gauche, cliquez sur la petite flèche située à côté du nom de votre serveur. Vous aurez ainsi accès à d’autres menus vous permettant de voir les mises à jour, voir les machines associées au serveur, créer des rapports, modifier les paramètres etc…

Cliquez sur le nom de votre serveur pour arriver sur son tableau de bord. Vous avez ici une vue globale du service et de ce qui s’y passe.

Vous pouvez y voir une liste des tâches à effectuer ou des informations utiles comme par exemple le nombre de mises à jour dernièrement synchronisées. On voit également l’état d’avancement de la synchronisation initiale dans la partie de droite. Sur la partie de gauche, vous avez une vue d’ensemble de l’état des mises à jour, des ordinateurs liés au serveur (sont-ils à jour ? en erreur ? en attente ?), et quelques statistiques. En dessous, vous verrez l’état d’avancement du téléchargement des mises à jour lorsque vous les aurez approuvées (on voit ça un peu plus tard ) .

Si vous allez dans le menu de gauche « Ordinateurs », vous trouverez toutes les machines qui ont été liées au serveur et qui donc reçoivent leurs mises à jour directement du serveur. Vous pouvez créer des groupes d’ordinateurs pour différencier par exemples les versions d’OS, les départements de l’entreprise, pour faire un groupe de machines test ou autre, à vous de définir votre organisation.

Par défaut, une machine va atterrir dans « Ordinateurs non attribués », vous pourrez la déplacer dans les groupes si vous en avez.

Vous pourrez filtrer la vue en modifiant la zone « Etat » et cliquant sur Actualiser à côté, afin de voir toutes les machines, uniquement celles en erreur, uniquement celles qui ne communiquent plus avec le serveur depuis quelques temps, uniquement celles qui ont des mises à jour nécessaires, etc…

Vous disposez également d’un menu « Rapports » permettant d’obtenir des rapports (bah oui…) sur différents états du service WSUS tels que des informations sur l’état de tous les ordinateurs, avec ou sans détail, l’état des mises à jour présentes sur le serveur, avec ou sans détail aussi, des rapports de synchronisations, des rapports sur un ordinateur bien précis etc…

Info + : Afin de générer et lire des rapports, il faudra au préalable installer sur le serveur le package « Types CLR du système Microsoft pour SQL Server 2012 » puis ensuite le package « Microsoft Report Viewer 2012 Runtime » (précisément dans cet ordre) et réouvrir la console de gestion de WSUS. Le lien direct de téléchargement du package Type CLR ne fonctionne pas parfois… dans ce cas là pas de panique, allez sur le lien de téléchargement du second package (Microsoft Report Viewer 2012 Runtime), descendez en bas de la page dans la zone “Related Resources” et cliquez sur “x64 – SQLSysClrTypes”.

Dans le menu « Options », vous pourrez modifier la configuration du service WSUS, ajouter des produits ou des classifications, faire du ménage, définir des règles d’approbation, etc…

Et enfin (oui j’ai gardé le meilleur pour la fin ), vous avez le menu « Mises à jour » qui va centraliser tout ce que vous avez demandé aux serveurs de Microsoft. Vous pouvez créer vous-même des catégories de mises à jour si vous le souhaitez pour mieux organiser votre vue.

Si vous cliquez sur « Toutes les mises à jour », vous pourrez modifier le filtre d’affichage pour ne voir que les mises à jour qui ont été approuvées pour le téléchargement, refusées ou en attente. Dans le champ « Etat », vous pouvez cibler uniquement les mises à jour qui ont besoin d’être réalisées ou qui sont en erreur sur au moins une machine liée au serveur WSUS.

Dans la capture suivante par exemple, j’ai choisi d’afficher toutes les mises à jour qui n’ont pas encore été approuvées et donc non téléchargées sur le serveur :

Afin d’avoir une vue un peu plus utile sur l’état des mises à jour et en faciliter la gestion, je vais ajouter des colonnes à l’affichage actuel. Pour cela, faites un clic droit sur l’entête de la colonne « Titre » par exemple, vous verrez alors tout ce qu’il est possible d’afficher. Les coches devant les noms signifient que ce champ est actuellement actif.

Cliquez sur « Etat d’installation », « Etat du fichier » et « Remplacement ».

Sur la gauche, 3 petites colonnes ont été rajoutées. Une pour chaque champ que l’on vient de sélectionner. Ces colonnes vont contenir des petits pictogrammes que nous allons voir en détail dans le chapitre suivant.

Ils vont nous permettre de voir rapidement si une mise à jour approuvée a bien été téléchargée sur le serveur ou au contraire est en erreur ou en attente de téléchargement mais également si les mises à jour proposées par Microsoft sont vraiment utiles. Certaines mises à jour récentes en remplacent des plus anciennes qui ne servent peut-être plus forcément etc… cela va nous aider par la suite à ne conserver que ce qui est vraiment nécessaire.

Si vous passez la souris sur l’un des pictogrammes, vous verrez ce qu’il signifie comme dans les deux exemples ci-dessous :

Pour avoir des détails sur une mise à jour précise, il suffit de cliquer dessus et de regarder dans la partie inférieure de la console.

Si je retourne dans mon tableau de bord du service WSUS (en cliquant sur le nom du serveur dans le menu de gauche), je peux de nouveau suivre l’état d’avancement de la synchronisation. Actuellement à 64%, et dans les statistiques je vois que 250 mises à jour ont été proposés par les serveurs de Microsoft mais sont non approuvées pour le moment.

Lorsque la synchronisation sera terminée, elle passera en état « En attente ». Mes statistiques m’indiquent 395 mises à jour non approuvées et 12 mises à jour refusées.

Allons jeter un coup d’œil sur ses mises à jour refusées alors que je n’ai encore rien fait .

Allez dans le menu « Toutes les mises à jour », définissez le filtre approbation sur « Refusées » et cliquez sur le bouton Actualiser. Nous retrouvons bien nos douze mis à jour.

Il arrive que certaines mises à jour expirent, elles deviennent donc obsolètes et Microsoft les passe directement à l’état refusé. Si je regarde en détail une mise à jour qui a été refusée automatiquement, je verrai le bandeau d’informations jaune comme dans la capture suivante. La mise à jour ne pourra jamais être approuvée et donc ne sera jamais téléchargée.

Passons maintenant aux mises à jour en attente d’approbation. Modifiez le filtre sur « Non approuvées » et « Toutes » puis actualisez. On retrouve bien 395 mises à jour.

Il faudra faire le tri dans tout cela afin de définir ce qui doit être approuvé ou refusé. Seules les mises à jour approuvées seront téléchargées sur le serveur et pourront être déployées sur les postes clients par la suite. On voit tout cela dans le projet chapitre .

Lors de la prochaine synchronisation au serveur de Microsoft, d’autres mises à jour viendront se greffer à votre liste et ainsi de suite.

Si vous allez dans le menu de gauche « Synchronisations », vous pourrez voir si tout c’est bien passé (combien de nouvelles mises à jour ont été détectées sur les serveurs de Microsoft, combien ont expiré…) ou au contraire s’il y a eu des erreurs.

Si vous cliquez sur une ligne en « Echec », vous pourrez avoir des informations sur l’erreur. Dans la capture suivante, on signale une erreur http. Si vous cliquez sur « Détails… », vous aurez un petit popup avec des informations plus précises (oui ou pas des fois…).

Dans l’erreur que vous voyez ci-dessus, cela signifie que le serveur n’a pas réussi à communiquer avec les serveurs de Microsoft. Ce qui est normal car pour la générer, j’ai tout simplement coupé le réseau sur mon serveur, il ne pouvait donc plus accéder à Internet. Lorsque vous avez cette erreur, assurez-vous que le serveur peut bien sortir sur l’extérieur et qu’il arrive à résoudre des noms de domaine en adresse IP (grâce à un DNS) en effectuant des tests de ping (le plus simple pour vérifier : « ping google.fr »).

Bon vous connaissez maintenant un peu mieux la console du serveur WSUS, on va donc passer à la gestion des mises à jour !

5. Gestion des mises à jour : approbation et téléchargement

Rentrons dans la partie la plus importante : apprendre à bien gérer ses mises à jour !

Comme nous l’avons vu dans le chapitre précédent, la synchronisation permet de récupérer une liste des mises à jour disponibles sur les serveurs de Microsoft qui correspond aux produits et classifications que nous avons demandées. Grâce à cette synchronisation, nous avons pu récupérer 407 mises à jour dont 12 refusées et 395 non approuvées (dans ce tuto bien sur, ça varie tous les jours donc n’attendez pas précisément à avoir 407 mises à jour…).

L’approbation d’une mise à jour est très importante, c’est justement grâce à cela qu’elle va être téléchargée sur le serveur et pourra ensuite être dispatchée sur les autres machines du parc. En l’état actuelle, aucune mise à jour n’a encore été téléchargée. Il faut commencer par faire le tri !

Parmi les mises à jour en attente d’approbation, il faut prendre le temps de ne conserver que ce qui est utile pour votre parc informatique. Vous verrez par exemple des mises à jour pour des architectures en 32 bits ou ARM, si vous n’en avez pas dans votre infrastructure, aucun intérêt de les approuver. Idem pour tout ce qui va être version de Windows : 1903, 1909, 20h1, 20h2, 21h1… C’est à vous de savoir ce que vous avez dans votre parc, si vous n’avez pas de 1903 par exemple, n’approuvez pas les mises à jour pour Windows 10 version 1903, ça fera un téléchargement inutile et cela prendra de la place pour rien.

Dans mon labo virtuel, j’ai juste du Windows 10 version 21h1 en 64 bits. Si je repère une mise à jour pour Windows 1909, je fais un clic droit sur cette mise à jour et « Refuser ».

La console va me demander confirmation, je clique sur « Oui » tout simplement.

La mise à jour passera en état « Refusée » dans la colonne Approbation.

Alors là je sais que certains sont en train de se dire « attends faut les refuser une par une ? Mais j’en ai pour 6 mois ! », mais nonnnn keep calm !

Les informaticiens étant par nature un peu faignants, vous vous doutez bien qu’il existe une méthode pour aller plus vite. Sur la droite de la console, vous verrez le menu « Actions » (si vous ne le voyez pas, cliquez sur le petit icone tout en haut à gauche entourez en rouge dans la capture suivante). Dans ce menu Actions, cliquez sur « Rechercher… »

Vous verrez apparaître cette petite fenêtre.

Je souhaite supprimer toutes les mises à jour qu’on me propose pour les systèmes en x86 par exemple car je n’ai que des 64 bits dans mon parc.

Dans la partie « Texte » de l’onglet « Mises à jour », je vais donc saisir « x86 » et cliquer sur le bouton « Rechercher ».

Info + : Ne vous alarmez pas si la fenêtre ne retourne rien tout de suite, c’est normal et ça sera plus ou moins longs selon le nombre de mises à jour synchronisées, laissez-lui le temps de chercher…

Après quelques secondes, il me sort la liste de toutes les mises à jour synchronisées sur mon serveur qui ont « x86 » indiqué dans leur nom.

Je vais toutes les sélectionner d’un seul coup et toutes les refuser. Pour cela, placez-vous sur la 1^ère de la liste qui devra s’afficher en bleu en cliquant simplement une fois dessus.

Ensuite, descendez avec le petit ascenseur tout en bas de cette liste. Appuyez sur la touche shift de votre clavier (celle juste au-dessus de la touche « ctrl » en bas à gauche du clavier) et restez bien appuyé et cliquez en même temps avec le bouton gauche de votre souris sur la dernière mise à jour de la liste. Cela aura pour action de sélectionner toute la liste, toutes les mises à jour seront surlignées en bleu comme ceci :

Ensuite vous pouvez faire un clic droit sur n’importe quelle mise à jour en bleu pour pouvoir la refuser.

Une fenêtre va vous demander une confirmation de suppression, si vous êtes sûr que vous n’en avez pas besoin, cliquer sur le bouton Oui.

Le refus va alors s’effectuer.

Si je change la vue « Toutes les mises à jour » de ma console WSUS en filtrant sur « Refusées », je vais bien retrouver mes mises à jour pour les systèmes en x86. Celles-ci ne seront donc jamais téléchargées et ne vont pas inutilement polluer mon serveur.

Info + : Vous pouvez faire cette manipulation pour approuver également plusieurs mises à jour d’un seul coup mais clairement je ne vous y encourage pas, il y a encore du tri à faire donc lisez la suite car on n’approuve pas tout et n’importe quoi…

On peut également cibler plutôt des mises à jour plus récentes que d’autres. Vous aurez peut-être remarqué ce bandeau sur certaine mise à jour dans la partie base de la console :

Les mises à jour évoluent vite et certaines, bien qu’elles ne soient pas encore obsolètes au point d’être refusée automatiquement, ont été remplacées par d’autres ou même en remplacement d’autres… .

Je vais choisir de ne pas approuver pour le téléchargement les mises à jour qui ont été remplacées car je n’en ai pas besoin. Une fois encore mon choix est propre à ce tuto uniquement donc attention à vos infra !

Mais comme j’ai la flemme de les chercher, je vais me servir des petits pictogrammes de la colonne « Remplacement » que nous avons ajouté plus tôt. C’est la colonne à gauche de « Titre » qui a ce symbole en entête :

Pour trier les mises à jour selon leur état de « Remplacement », cliquez sur l’entête de la colonne. Elles vont alors se regrouper par état justement.

Vous pourrez normalement remarquer 4 états différents qui correspondent à ceci :

Dans mon cas, je vais refuser toutes les mises à jour remplacées même si elles en remplacent d’autres. Je vais donc rechercher toutes les mises à jour avec les 2 et 3^ème symboles du tableau précédent, et comme j’ai trié ma vue par état de remplacement, je devrais vite les repérer puisqu’elles vont toutes être à la suite .

Je vais toutes les sélectionner d’un coup (clic gauche sur la 1ère mise à jour à sélectionner, touche shift du clavier maintenue enfoncée et clic gauche sur la dernière mise à jour à sélectionner.), faire un clic droit et les refuser.

Une fois ceci fait, si j’actualise ma vue, je n’aurais plus que 58 mises à jour en attente d’approbation, on commence à y voir plus clair .

Il ne vous reste qu’à contrôler les mises à jour restantes pour voir si elles sont utiles à votre parc ou non. Souvenez-vous que pour avoir des informations détaillées, vous pouvez cliquer sur une mise à jour et consulter la partie inférieure de la console. Vous verrez alors plus en détail quelles mises à jour elle remplace, etc…

Dans le cadre de ce tuto, je ne vais pas faire plus de tri même si j’aurai clairement pu (au final il y aura très peu de mises à jour utiles à mon client, je table sur 2 ou 3…).

Imaginons qu’on soit des bons sysadmin… on a fait un super tri, tout est nickel il ne reste que les mises à jour dont nous avons besoin dans notre infrastructure ! Et bien maintenant, il faut approuver ces mises à jour ! La manipulation est simple, placez-vous sur une mise à jour, faites un clic droit dessus, et cliquez sur « Approuver ».

Il faudra ensuite sélectionner un groupe d’ordinateurs pour lequel la mise à jour sera approuvée. Je n’ai pas fait de groupe personnellement donc je vais tout simplement approuver pour « Tous les ordinateurs ».

Cliquez sur le panneau à gauche du groupe d’ordinateurs que vous souhaitez et cliquez sur « Approuvée pour l’installation ».

Info + : Si vous avez besoin de supprimer une mise à jour qui cause des perturbations sur vos postes clients, c’est également ici que vous devrez venir. Vous devrez alors sélectionner le groupe et cliquer sur « Approuvée pour la suppression ».

Vous verrez alors une coche verte devant le groupe de machines, cliquez sur OK pour terminer.

L’approbation se lance, elle ne prend que quelques millisecondes car il n’y a qu’une seule mise à jour approuvée ici.

Et dans la vue globale, son état d’approbation passe sur « Installer ». Ne comprenez pas que la mise à jour est installée et hop finito, non, cela signifie plutôt qu’elle est disponible pour l’installation sur les postes clients. Mais elle ne le sera définitivement que quand elle aura été téléchargée sur le serveur.

Et c’est justement ce téléchargement que nous allons surveiller maintenant.

Nous allons nous intéresser à la colonne « Etat du fichier » cette fois-ci. Cette colonne sert à surveiller l’état des fichiers des mises à jour sur le serveur, c’est-à-dire à contrôler si les fichiers nécessaires ont bien été téléchargés et sont bien stockés sur le serveur ou si au contraire le téléchargement est en attente car une erreur est survenue ou l’approbation n’a pas été effectuée.

Vous pourrez normalement remarquer 4 états différents qui correspondent à ceci :

Info ++ : Si une seule mise à jour est en erreur, relancez son téléchargement en la sélectionnant et en cliquant à droite sur « Essayer à nouveau de télécharger ». Si toutes les mises à jour sont impactées par l’erreur, vous avez un problème dans votre infrastructure, vérifiez votre connectivité réseau, l’espace disque, la configuration du service WSUS, l’état des services WSUS et IIS et consultez la tableau de bord du serveur ainsi que les journaux d’événements.

Si on passe la souris sur le pictogramme d’une mise à jour approuvée, nous verrons son état.

L’approbation d’une mise à jour va entrainer directement son téléchargement. Vous pourrez suivre l’avancement dans le tableau de bord principal du service WSUS en cliquant sur le nom de votre serveur, partie « Etat de téléchargement ».

Dans mon exemple, on voit que la mise à jour approuvée fait 584Mo et que 17Mo ont déjà été téléchargé. Je n’ai plus qu’à attendre…

Toujours dans mon exemple, j’ai finalement approuvé les 58 mises à jour (oui flemme de trier mais ne faites surtout pas ça…) donc les 58 vont devoir se télécharger. On voit dans mon dashboard que cela représente un peu plus de 5Go (et comme mon débit est pourri, cela m’a pris 2h30… Ce n’est qu’au bout d’une heure d’attente que j’ai regretté de ne pas avoir trié donc vraiment j’insiste ne gardez que ce dont vous avez besoin !).

Il est également possible de définir des règles d’approbations automatiques de mises à jour dans WSUS. Attention avec ces règles, soyez conscient que vous perdrez l’occasion de tester en amont qu’une mise à jour ne va pas créer des problèmes ! Le mieux est de ne les activer que pour des produits ou classifications sensibles comme par exemples les mises à jour de Defender ou autres.

Pour utiliser ces règles, rendez-vous dans le menu « Options » de la console de gestion de WSUS et cliquez sur « Approbations automatiques ». Une règle par défaut est déjà présente mais non active.

Vous pouvez alors créer une nouvelle règle et définir ce que vous souhaitez dans les propriétés. Il suffit de cliquer sur une valeur soulignée en bleu pour la remplacer par ce que vous voulez.

Retournons voir où en est le téléchargement sur le dashboard. On voit ici que 3Go ont déjà été téléchargés.

Si j’ouvre l’explorateur de fichiers sur mon serveur et que je vais dans « Ce PC », je vois en effet que mon disque de stockage sur lequel j’ai demandé le stockage des données propres à WSUS comment doucement à se remplir.

Pour voir les fichiers des mises à jour, allez dans le dossier où vous avez réalisé la configuration de WSUS et ensuite dans « WsusContent ». On retrouve pas mal de choses qui concernent les fameux fichiers de nos mises à jour approuvées (ne touchez pas à ces fichiers !).

Lorsque tout sera fini, le dashboard indiquera « Mises à jour nécessitant des fichiers : 0 ».

Si on vérifie la colonne « Etat du fichier », elles sont toutes bien passées en état « Prêt pour l’installation ».

Info ++ : La colonne « Pourcentage installé / non applicable » est actuellement à 0% car aucune machine cliente n’a encore été liée au serveur WSUS. Si vous avez une machine et que celle-ci dispose déjà de la mise à jour ou qu’elle ne s’applique pas à elle, le pourcentage sera à 100%. Si vous avez 2 machines liées au serveur et que l’une d’elle a besoin de la mise à jour mais l’autre non, le pourcentage sera à 50%, etc… Cette colonne fait référence au nombre d’ordinateurs qui ont déjà, ou non, cette mise à jour.

Bon et bien on dirait que le serveur est fin prêt à remplir sa mission ! Il ne nous reste plus qu’à lier des ordinateurs au service WSUS ! On voit ça au prochain chapitre ?

6. Gestion des ordinateurs : liaison à WSUS et surveillance d’état

A ce stade aucune machine n’a encore été liée au serveur WSUS.

Rendez-vous sur une machine cliente. Si vous allez dans les paramètres de la machine puis sur Windows Update, vous aurez la vue suivante :

C’est le fonctionnement classique d’une machine Windows qui va chercher ses mises à jour sur Internet.

Afin de lier un ordinateur au service WSUS, il y a plusieurs façons de procéder.

Dans le cadre de ce tuto, je vais en utiliser deux sans toutefois les détailler car ce n’est pas le sujet, ce sera à vous de bien effectuer vos configurations selon vos infrastructures.

La première méthode implique que vous ayez un serveur avec les services AD et DNS installés et fonctionnels. Elle est à privilégier dans des infrastructures disposant d’un AD car cela évite une intervention manuelle poste par poste mais une configuration centralisée grâce aux stratégies de groupe (GPO) qui sont faites pour cela justement.

Sur un serveur disposant d’Active Directory, j’ai donc créé une nouvelle GPO au niveau d’une unité d’organisation globale. Voici une vue générale des paramètres de ma GPO (cliquez sur l’image pour agrandir) :

Vous trouverez tous les paramètres de stratégies nécessaires en modifiant la GPO et en vous rendant dans Configuration ordinateur > Stratégies > Modèles d’administration > Composant Windows > Windows Update.

Info ++ : Les manipulations ne seront pas ici détaillées car ce n’est pas l’objet de cet article qui consiste plutôt à savoir bien apprivoiser la console de gestion de WSUS. Si vous ne souhaitez pas ensuite attendre que la GPO s’applique automatiquement sur la machine, vous pouvez la forcer en lançant un cmd sur le poste client et la commande « gpupdate /force ».

La seconde méthode proposée ici va nécessiter une intervention manuelle sur chaque poste devant être liés au serveur WSUS. Elle est destinée aux organismes ne disposant pas (ou ne souhaitant pas disposer…) d’Active Directory (petite structure de moins de 20 machines en général), les machines ne sont donc pas dans un domaine mais en « Workgroup ».

Je vous propose d’utiliser un petit outil gratuit et sans installation qui s’appelle « WSUS ClientManager for Workgroups ». Il est disponible ICI (attention à vos versions d’OS).

Il devra être utilisé directement sur les postes que vous voulez lier au serveur WSUS. Voici un exemple de configuration de l’outil, une fois encore, à adapter selon vos besoins (je mets l’adresse IP du serveur WSUS et non pas son nom cette fois-ci car le PC client ne peut pas résoudre le nom du serveur en adresse IP, j’utilise un DNS public dans ce tuto) :

Vous remarquerez après avoir cliqué sur « Activate WSUS » que les champs contenant l’IP du serveur se sont transformés automatiquement en lien « http://adresse_ip:8530 », c’est tout à fait normal, je vous l’ai dit, ce petit outil fait très bien son job .

Info + : Si vous n’êtes pas dans un environnement Active Directory et que vous ne souhaitez pas utiliser le petit exécutable proposé ici, vous pouvez modifier manuellement la base de registre de la machine ou utiliser les stratégies de groupe locales de la même façon que sur un AD. Je trouve tout simplement que c’est plus contraignant donc je me sers de ce petit exécutable qui fait très bien son job et évite de faire plusieurs manipulations. Il m’arrive aussi parfois de configurer juste une machine avec l’outil, d’enregistrer les clés de registre modifiées et de les déployer via scripts sur les autres PC…

Bien, maintenant que vous avez choisi votre méthode d’ajout de poste à WSUS, nous pouvons continuer. Que vous ayez appliqué la GPO ou utilisé l’outil WSUS For Workgroup, votre machine doit déjà être prête à communiquer avec le serveur WSUS.

Pour le vérifier, retournez dans le Windows Update sur le poste client. Vous devriez maintenant avoir la vue suivante :

Il est désormais indiqué que l’organisation gère certains paramètres, cela signifie que votre configuration (via GPO ou via l’outil WSUS for Workgroup) a bien été fonctionnée. Allons sans plus attendre vérifier dans la console de gestion de WSUS si on trouve notre nouvel ordinateur !

Info ++ : Il est fort probable que l’ordinateur ne soit pas visible de suite dans la console WSUS, surtout dans un environnement sans AD. Afin de ne pas attendre que le client communique une première fois avec la machine (ce qui peut prendre des heures…), sur le client, allez dans Windows Update et lancer manuellement une recherche de mise à jour. Au bout de quelques secondes, vous trouverez la machine dans la console WSUS.

Allez dans « Tous les ordinateurs », modifiez le filtre d’état sur « Toutes » et actualisez la vue. La machine est bien présente dans la console de gestion de WSUS. A partir de maintenant, elle interrogera périodiquement le serveur pour avoir les dernières mises à jour disponibles et elle lui enverra également des informations sur son état actuel.

Vous pouvez voir actuellement un message informant que « cet ordinateur n’a pas encore émis de rapport d’état » et que la colonne pourcentage installé est à 0%. Ceci est tout à fait normal, l’ordinateur a seulement établi un 1^er contact avec WSUS, cela s’actualisera par la suite no panic .

Si ce n’est pas déjà fait, lancez une recherche de mise à jour manuellement sur le poste client afin de ne pas attendre. Actuellement, ma machine Windows 10 ne récupère qu’une seule mise à jour sur WSUS, la « KB5005033 » précisément.

Le fait de lancer une recherche de mise à jour sur le client a fait remonter des informations d’état dans la console WSUS. On voit bien désormais que la machine est à 98% de mises à jour installées/non applicables et que 2 mises à jour sont nécessaires.

Et là je sais ce que vous vous dites : « Pourquoi WSUS dit 2 mises à jour nécessaires et le client n’en télécharge qu’une seule ? ».

Ahah vous avez l’œil ! Tout simplement parce que j’ai relancé une synchronisation de WSUS, et donc qu’une des deux mises à jour nécessaire n’est pas encore approuvée et donc pas disponible à l’installation sur le client ! Et oui souvenez-vous ce que j’ai dû dire 24 fois depuis le début de ce tuto : une mise à jour n’est pas téléchargée tant qu’elle n’est pas approuvée !

Vérifions cela en commençant par aller sur « Toutes les mises à jour » avec le filtre « Approuvées » et l’état « Toutes ».

On constate qu’un petit triangle jaune apparait sur l’une des mises à jour. Cela signifie que cette mise à jour est nécessaire sur au moins une machine liée au serveur. Et si on regarde de plus près, on voit bien qu’il s’agit de la KB5005033 qui est en cours d’installation sur le poste client.

La coche verte à la place du triangle jaune peut signifier deux choses : soit que la mise à jour a été installée sur tous les ordinateurs liés au serveur, ou soit qu’elle n’est pas applicable sur les ordinateurs tout simplement.

Si je modifie le filtre d’approbation sur « Non approuvées », je retrouve bien une mise à jour qui est toujours en stand-by côté serveur, mais qui est nécessaire sur le client.

La console de gestion de WSUS permet également de faire des groupes d’ordinateurs afin de les différencier dans le cas par exemples de versions d’OS différentes ou de groupe de tests. Pour cela, faites un clic-droit sur le menu « Tous les ordinateurs » puis « Ajouter un groupe d’ordinateurs ».

Il ne vous reste qu’à donner un nom à ce groupe. Personnellement, je vais faire un groupe pour les machines membre de mon domaine, et un autre pour celles en dehors du domaine car j’ai ajouté une seconde machine avec la méthode du client for workgroup.

Ensuite, faites un clic droit sur une machine dans la vue globale, puis « Modifier l’appartenance ». Il ne vous restera qu’à choisir le groupe auquel assigner la machine.

Vous pourrez tout de même garder une vue globale en allant dans le menu « Tous les ordinateurs ».

Comme vous pouvez le constater, j’ai maintenant deux ordinateurs liés à mon serveur WSUS. L’un est à jour à 100% et l’autre pas tout à fait. Si nous allons consulter « Toutes les mises à jour », nous verrons que c’est toujours la KB5005033 qui est nécessaire. La différence dans cette capture est que la colonne « pourcentage installé/non applicable » est passé à 50%.

Ce qui signifie tout simplement que 50% des ordinateurs liés au serveur ont besoin de cette mise à jour. Ce qui est vrai car je n’ai que 2 ordinateurs dont un est déjà full à jour (oui là sorry faut des bases en maths les gars )

Si vous allez dans le menu « Ordinateurs », vous verrez le tableau de bord qui résumé l’état de vos machines qui récupèrent leurs mises à jour via WSUS.

Vous le retrouverez également dans le dashboard général de la console en cliquant sur le nom de votre serveur en haut à gauche.

Lors de la prochaine synchronisation, de nouvelles mises à jour potentielles pour vos postes clients seront peut être disponibles. Il faudra donc bien penser à les approuver pour qu’elles soient téléchargées et disponibles pour les clients et ainsi de suite jusqu’à… bah pour toujours en fait !

Vous savez désormais comment gérer vos ordinateurs dans WSUS et surveiller leur état !

7. Pour aller plus loin

WSUS n’est pas un service compliqué à gérer mais il demande quand même de la surveillance afin de conserver un environnement à jour.

Il faut également penser à nettoyer régulièrement le serveur de tout ce qui n’est plus utile en allant dans le menu Options et « Assistant de nettoyage du serveur WSUS » et surtout bien contrôler son espace disque car ça peut vite gonfler.

Je vous conseille d’ailleurs vivement de créer un script en Powershell pour purger le serveur WSUS et de le planifier (au moins 1 fois par mois). Vous pouvez regarder du côté de la cmd-let « Invoke-WsusServerCleanup ».

Vous pourrez également tomber parfois sur des postes récalcitrants à communiquer avec le serveur. Pour corriger cela, vous pouvez utiliser les options de la commande « wuauclt » que vous pouvez consulter ICI (dans ce lien vous aurez aussi des infos sur les commandes powershell utiles et sur la fonctionnalité « usoclient » qui est plus récente que wuauclt qui est un peu boudé par Microsoft depuis Windows Server 2016) :

Microsoft recommande également quelques « bonnes pratiques » afin de conserver un serveur WSUS fonctionnel, notamment au niveau du service web IIS qui peut jouer des tours dans des environnements plutôt grands… Vous trouverez plein d’infos sur le site officiel de Microsoft : Windows Server Update Services meilleures pratiques.

Vous avez désormais toutes les clés en main pour bien apprivoiser WSUS !

Nous allons nous arrêter là pour cet article car il est déjà beaucoup plus long que prévu…

Pour conclure, je dirais clairement que la console de gestion de WSUS est très bien optimisée pour gérer aisément ses mises à jour et voir rapidement qui a besoin de quoi en un coup d’œil. Ce n’est pas un service compliqué à utiliser mais il demande en revanche beaucoup de ressources et d’attention.

Vous n’avez désormais plus d’excuses pour ne pas tenir vos parcs correctement à jour !