WSUS dans une architecture multisite
Pour déployer le service WSUS au sein d’une infrastructure, il y a plusieurs scénarios envisageables et qui permettent de s’adapter à l’environnement, à l’architecture du système d’information. Lorsque l’on a un seul site, la question ne se pose pas : on déploie un seul et unique serveur WSUS, comme nous venons de faire.
À l’inverse, lorsqu’il y a plusieurs sites géographiques, on peut se poser une question légitime : faut-il déployer plusieurs serveurs WSUS ? À cette question, j’ai envie de répondre « ça dépend », car on ne va pas mettre en place un serveur WSUS pour gérer 5 machines. Dans ce cas, autant s’appuyer sur le serveur WSUS déjà présent sur l’autre site de l’entreprise.
I. Les scénarios de déploiement de WSUS
Le service WSUS prend en charge différents scénarios de déploiement, notamment pour les environnements multisites. En fait, il est possible de créer une hiérarchie de serveurs WSUS avec un serveur en amont, que l’on peut considérer comme le serveur principal, et des serveurs secondaires qui vont s’appuyer sur ce serveur.
Prenons un exemple. Une entreprise dispose de deux sites conséquents avec à chaque fois plusieurs dizaines d’ordinateurs et des serveurs. Il est envisageable de déployer deux serveurs WSUS, mais l’idée c’est qu’ils ne soient pas indépendants !
En effet, le serveur « SRV-WSUS-01 » à gauche sur le schéma ci-dessous sera synchronisé sur les serveurs de Microsoft Update. C’est lui qui réceptionnera les mises à jour de Microsoft et qui va les diffuser au second serveur WSUS. Quant au second serveur, nommé « SRV-WSUS-02 » sur le schéma, il est configuré de façon à s’appuyer sur « SRV-WSUS-01 ». Cela signifie qu’il récupère les mises à jour depuis ce premier serveur WSUS et qu’il n’a pas besoin d’accéder directement à Internet.
Dans certains cas, les entreprises disposent d’un Cloud privé qui regroupe les principaux serveurs de l’entreprise, comme le serveur WSUS « maître ». Ensuite, sur les différents sites de l’entreprise, il est envisageable de déployer un serveur WSUS (si cela est cohérent vis-à-vis du nombre de machines) qui va s’appuyer sur le serveur WSUS en amont, qui est en quelque sorte le serveur WSUS principal (« maître »). Les serveurs WSUS situés sur les sites distants sont des serveurs répliqua.
L’intérêt étant d’avoir un seul serveur WSUS à gérer pour la synchronisation avec les serveurs Microsoft Update, mais aussi un seul emplacement pour gérer l’approbation des mises à jour. En effet, une mise à jour non approuvée par le serveur « maître » ne sera pas distribuable par les serveurs des sites distants.
Un serveur WSUS répliqua hérite des approbations de mises à jour, des paramètres, des ordinateurs et des groupes du parent. En fait, ce serveur agit comme un cache local pour diffuser les mises à jour auprès des clients du site en question.
II. Serveur WSUS en amont et serveur WSUS répliqua
Pour mettre en place une hiérarchie de serveurs WSUS, il faut commencer par déployer le serveur WSUS principal, comme nous l’avons fait précédemment. Lorsque le serveur WSUS répliqua sera déployé, veillez à lui attribuer le même espace de stockage que le serveur principal, et la bande passante entre les deux serveurs doit être suffisante pour permettre la synchronisation des données.
Ensuite, la connexion au serveur WSUS en amont à partir d’un serveur WSUS secondaire s’effectue depuis le serveur secondaire au moment de l’installation. Après l’installation du rôle, souvenez-vous qu’un assistant s’exécute pour nous permettre de sélectionner l’emplacement des mises à jour, etc…
Parmi ces étapes, il y a une étape intitulée « Choisir le serveur en amont ». Sur le serveur principal, c’est l’option « Synchroniser à partir de Microsoft Update » qui est retenue. Néanmoins, sur ce deuxième serveur, c’est l’option « Synchroniser à partir d’un autre serveur Windows Server Update Services » qu’il faut choisir.
Le formulaire doit être complété avec le nom complet du serveur principal, le numéro de port, et l’option « Il s’agit d’un répliqua du serveur en amont » doit être cochée pour que ce nouveau serveur soit une copie du principal. Ainsi, la gestion s’effectue au niveau du serveur principal.
Attention, si vous souhaitez que ce second serveur s’appuie sur le premier serveur pour la synchronisation uniquement, mais que vous souhaitez garder la main sur la configuration, ne cochez pas cette option.
Le processus d’initialisation doit être finalisé sans effectuer une autre modification particulière. Sur ce nouveau serveur répliqua, dans les options « Source des mises à jour » de la console WSUS, on retrouve bien cette nouvelle configuration avec un message clair « Les options sont désactivées, car ce serveur est un serveur répliqua ».
Note : les connexions entre les serveurs WSUS s’effectuent au travers d’une connexion http/8530 ou https/8531, comme les connexions entre le serveur WSUS et les clients.
Par ailleurs, dans la console WSUS du serveur principal, la liste des serveurs répliqua est disponible dans la section « Serveurs en aval ». Ici, il y a la liste des serveurs WSUS qui s’appuient sur ce serveur local, que ce soit en mode « réplica » ou simplement pour la synchronisation des mises à jour.
La mise en place d’un ou plusieurs serveurs répliqua est assez simple, mais c’est une fonctionnalité très pratique qui est indispensable pour optimiser certains déploiements. Les serveurs répliqua sont très pratiques pour distribuer les mises à jour à un ensemble de machines, en agissant comme un cache local puisque la gestion s’effectue à partir du serveur WSUS en amont pour reprendre le terme officiel.
Il restera à configurer les clients pour utiliser ce nouveau serveur WSUS répliqua. Autrement dit, une stratégie de groupe avec l’adresse de ce serveur WSUS répliqua doit être appliquée sur les clients qui doivent se connecter sur ce serveur WSUS. Souvenez-vous du paramètre « Spécifier l’emplacement intranet du service de mise à jour Microsoft ».
