Lier les machines du domaine au serveur WSUS

Afin de lier les machines du domaine Active Directory au serveur WSUS, il faut bien entendu disposer d’un annuaire Active Directory opérationnel et que les machines soient rattachées au domaine. C’est notre cas puisque nous avons le serveur « SRV-ADDS-01 » qui est contrôleur de domaine ainsi que DNS.

I. Modifier la méthode d’affectation des ordinateurs

Avec la configuration par défaut de WSUS, lorsqu’une nouvelle machine est liée au serveur WSUS, elle ira se positionner dans le groupe d’ordinateurs nommé « Ordinateurs non attribués ». Ensuite, ce sera à l’administrateur système de déplacer les machines de ce groupe vers un autre groupe.

Ce n’est pas très pratique et cette méthode oblige l’administrateur système à effectuer la répartition manuellement à chaque fois qu’une nouvelle machine doit être gérée par le serveur WSUS. Sur un petit parc informatique d’une dizaine de machines, pourquoi pas, mais sur des parcs informatiques plus vastes et qui évoluent constamment, cela me semble inadapté.

La bonne nouvelle, c’est que l’on peut modifier ce comportement pour que la machine soit ajoutée au groupe défini dans la stratégie de groupe que l’on va créer par la suite. Ainsi, la répartition dans les groupes sera gérée automatiquement.

Pour utiliser ce mode de fonctionnement :

• Ouvrez la console WSUS
• Cliquez sur « Options» à gauche (1)
• Cliquez sur « Computers » / « Ordinateurs » à droite (2)
• Cochez l’option « Use Group Policy or registry settings on computers » / « Utiliser les paramètres de stratégie de groupe ou de Registre sur les ordinateurs » (3).
• Validez

Désormais, l’affectation sera effectuée selon la valeur définie par stratégie de groupe ou directement dans le Registre de la machine.

II. Créer des groupes d’ordinateurs dans WSUS

Pour indiquer aux machines qu’elles doivent se connecter à un serveur WSUS (plutôt qu’au serveur de Microsoft), nous devons créer une nouvelle stratégie de groupe. D’ailleurs, il y a divers paramètres de stratégies de groupe qui permettent de configurer la fonctionnalité « Windows Update » de Windows (desktop et server).

Nous verrons qu’il y a un paramètre pour spécifier l’emplacement du serveur WSUS, donc ce sera commun à toutes les machines, que ce soit des postes de travail ou des serveurs.

Il y a également un paramètre qui permet d’indiquer dans quel groupe du serveur WSUS la machine doit être intégrée (afin d’avoir une attribution automatique, comme je l’évoquais précédemment). Si l’on veut organiser le serveur WSUS en créant des groupes d’ordinateurs, par exemple un groupe « PC » et un groupe « Serveurs », il faut que l’on configure deux GPO pour appliquer des noms de groupe différents. Au total, cela fait 3 GPO à créer.

Avant d’entamer la création de nos stratégies de groupe, nous allons créer nos deux groupes sur le serveur WSUS : « PC » et « Serveurs ». En production, vous pouvez créer également un groupe nommé « Tests » pour tester les mises à jour avant le déploiement à grande échelle.

Ouvrez la console « WSUS », effectuez un clic droit sur « Tous les ordinateurs » puis cliquez sur « Add Computer Group ». Nommez ce premier groupe « PC » puis recommencez pour le second groupe.

Au final, on obtient l’arborescence suivante :

Pour la création des groupes dans WSUS, il y a plusieurs approches. Il est possible de créer des groupes par type de machines, comme nous venons de le faire, mais également de reprendre le principe des anneaux comme le fait le nouveau service de Microsoft, Windows Autopatch. Ainsi, une mise à jour serait approuvée dans un premier temps à l’anneau de test, et si les tests sont concluants, elle serait approuvée pour l’anneau de production afin d’effectuer un déploiement plus large.

III. Lier les PC et les serveurs à WSUS par GPO

A. GPO WSUS pour les paramètres communs

Commençons par créer la stratégie de groupe qui va contenir les paramètres communs à toutes les machines, peu importe leur type (postes de travail et serveurs). La configuration qui suit est donnée à titre d’exemple, et bien qu’elle me semble pertinente, elle doit être adaptée à votre environnement.

Sur votre contrôleur de domaine, ou à partir d’une machine équipée des outils d’administration, ouvrez la console de « Gestion de stratégie de groupe ».

Créez une nouvelle GPO liée sur la racine du domaine pour gérer l’intégralité des machines du domaine via le serveur WSUS. Pour ma part, je nomme la GPO « WSUS – Paramètres communs ».

Note : si vous souhaitez utiliser WSUS uniquement sur certaines machines, appliquez un filtrage de sécurité sur un groupe de sécurité spécifique ou liez la GPO uniquement sur certaines OUs.

Modifiez la GPO et parcourez les paramètres de cette façon :

Configuration ordinateur > Stratégies > Modèles d’administration > Composants Windows > Windows Update

A cet emplacement, deux cas de figure : soit vous avez tous les paramètres en vrac, soit vous avez 4 sous-catégories comme sur l’image ci-dessous. En fait, vous avez la répartition comme la mienne, en sous-catégorie, si vous utilisez la dernière version des modèles ADMX pour Windows 11.

En janvier 2022, Microsoft a mis en ligne une liste de 18 paramètres de stratégies de groupe qui ne fonctionnent pas (ou qui ne fonctionnent pas correctement) sur Windows 10 et Windows 11.

Il s’agit de paramètres historiques regroupés au sein de la sous-catégorie « Stratégies héritées ». Si tous les paramètres sont dans « Windows Update » sur votre infrastructure, cela signifie que les paramètres obsolètes sont mélangés avec les paramètres valides. Ce n’est pas bien grave, c’est seulement gênant visuellement.

Pour vous aider, voici la liste des paramètres à ne pas configurer si vous utilisez Windows 10 et/ou Windows 11 (ainsi que les dernières versions de Windows Server) :

Pour intégrer les modèles d’administration ADMX sur votre contrôleur de domaine, suivez cet article complémentaire : Installer les templates ADMX de Windows 11

Passons à la configuration des paramètres.

Tout d’abord, nous allons devoir définir l’adresse de notre serveur WSUS, à savoir « http://srv-wsus.it-connect.local:8530 » (8530 étant le port par défaut lorsque le WSUS est accessible en http), dans le paramètre « Spécifier l’emplacement intranet du service de mise à jour Microsoft » (sous « Gérer les mises à jour proposées de Windows Server Update Service »). Dans un autre chapitre, nous verrons comment sécuriser la connexion via le protocole HTTPS.

Il faut commencer par activer ce paramètre (1), puis définir l’adresse du serveur WSUS comme emplacement pour la détection des mises à jour (2), mais aussi pour les statistiques (3). Les autres options peuvent être laissées par défaut.

Ce qui donne la configuration suivante, où vous devez bien sûr adapter l’adresse de votre serveur WSUS.

Le second paramètre à configurer se nomme « Configuration du service Mises à jour automatique » (sous « Gérer l’expérience utilisateur final »). Il sert à agir sur le comportement des machines notamment pour télécharger et installer les mises à jour.

Il faut commencer par activer ce paramètre. Je vous laisse prendre connaissance de ma configuration ci-dessous puis des explications à la suite.

L’option « Configuration de la mise à jour automatique » est déterminée sur « 4 – Téléchargement automatique et planification des installations » afin que Windows Update télécharge et installe régulièrement les mises à jour, quand elles sont approuvées en amont sur le serveur WSUS.

Par défaut, Windows recherche les mises à jour toutes les 22 heures environ. Là, on précise que les mises à jour seront téléchargées (sur le WSUS, donc) et installées à 12:00 tous les jours. Néanmoins, on n’installe pas les mises à jour toutes les semaines : seulement en troisième et quatrième semaine du mois.

Pourquoi ? Je vous rappelle que Microsoft publie ses mises à jour le second mardi de chaque mois, donc si l’on installe les mises à jour en fin de mois, cela permet de récupérer les dernières mises à jour.

Autrement dit, sur la deuxième partie du mois, les machines chercheront à installer les nouvelles mises à jour disponibles.

Note : Ici, nous sommes sur la configuration des paramètres communs, donc aussi bien ordinateurs que serveurs. Si vous souhaitez définir des horaires différentes, il vaut mieux configurer ce paramètre de GPO dans deux stratégies distinctes.

Un troisième paramètre est à configurer afin d’empêcher les machines de se connecter sur les serveurs Microsoft Update pour appliquer des mises à jour.

Il s’agit du paramètre « Ne pas se connecter à des emplacements Internet Windows Update » (sous « Gérer les mises à jour proposées de Windows Server Update Service ») et il suffit de l’activer.

Validez, cette première GPO est prête !

Pour terminer, voici un résumé de la configuration de cette stratégie de groupe :

B. GPO WSUS spécifique aux postes de travail

Créez une nouvelle stratégie de groupe nommée « WSUS – PC » et liez cette GPO à l’unité d’organisation qui contient vos postes de travail. Au sein de mon annuaire, il s’agit de l’OU « PC ».

Cette stratégie va servir à déterminer deux paramètres pour :

• Indiquer le nom du groupe WSUS dans lequel doivent aller les postes de travail
• Indiquer la plage horaire correspondante aux heures d’activité

Les paramètres se situent au même endroit, à savoir :

Configuration ordinateur > Stratégies > Modèles d’administration > Composants Windows > Windows Update

Commencez par configurer le paramètre « Autoriser le ciblage côté client » (sous « Gérer les mises à jour proposées de Windows Server Update Service »). Pour cela, activez le paramètre et pour l’option « Nom du groupe cible de cet ordinateur », indiquez « PC », car je vous rappelle que c’est le nom du groupe créé sur le serveur WSUS.

Ce qui donne :

Dans cette GPO, nous allons configurer un deuxième paramètre nommé « Désactiver le redémarrage automatique pour les mises à jour pendant les heures d’activité » (sous « Gérer l’expérience utilisateur final ») dans le but d’éviter les redémarrages intempestifs en pleine production !

Par exemple, voici la configuration à appliquer pour définir une plage horaire de 07h00 à 19h00 sur les postes de travail :

Remarque : la plage horaire des heures d’activité peut représenter au maximum un total de 18 heures.

La stratégie de groupe propre aux ordinateurs est prête, voici un résumé :

Passons à la stratégie de groupe propre aux serveurs.

C. GPO WSUS spécifique aux serveurs

Créez une nouvelle stratégie de groupe nommée « WSUS – Serveurs » et liez cette GPO à l’unité d’organisation qui contient vos serveurs, ainsi qu’à l’OU « Domain Controllers » pour cibler les contrôleurs de domaine. Au sein de mon annuaire, il s’agit de l’OU « Serveurs ».

Cette stratégie va servir à déterminer deux paramètres pour :

• Indiquer le nom du groupe WSUS dans lequel doivent aller les serveurs
• Indiquer la plage horaire correspondante aux heures de production

Le processus de création de cette stratégie de groupe est similaire à celle des postes de travail, alors je passe directement à la synthèse :

Pour les serveurs, on définit une plage horaire beaucoup plus large pour les heures d’activités : de 05h00 à 23h00.

D. Tester la GPO WSUS

Notre configuration étant prête, il va falloir tester pour s’assurer qu’elle fonctionne. Pour cela, je vais utiliser la machine « PC-01 » actuellement sous Windows 11, et intégrée au domaine.

Je me connecte sur PC-01 afin d’actualiser les GPO et d’enchaîner par un redémarrage.

Après le redémarrage, il est fort probable que l’ordinateur soit visible sur le serveur WSUS. Pour le vérifier, il est nécessaire d’ouvrir la console WSUS et d’ouvrir le groupe « PC ». Ensuite, il faut basculer l’état sur « Toutes » (« Any ») et cliquer sur « Actualiser » (« Refresh »).

L’ordinateur « PC-01.it-connect.local » est bien visible ! Il est désormais lié au serveur WSUS !

C’est assez étonnant de voir « OS : Windows 10 Education » alors qu’il s’agit d’une machine sous « Windows 11 Education ».

Si la machine ne remonte pas sur le serveur WSUS, pas de panique ! Patientez encore un instant, ou forcez le destin en déclenchant une recherche de mises à jour manuellement.

Ouvrez les paramètres de Windows, cliquez sur « Windows Update » (1) puis sur « Rechercher des mises à jour ».

D’ailleurs, on peut s’assurer que la stratégie est bien appliquée via l’outil « gpresult », mais aussi, sous Windows 11, en cliquant sur « Options avancées » (toujours dans Windows Update) puis « Stratégies de mises à jour configurées ».

Dans le prochain chapitre, nous allons étudier le cas d’une machine en « groupe de travail ».