Un serveur Windows Server Update Services, ou WSUS, permet de diffuser des mises à jour Windows sur le réseau local pour tous les ordinateurs Windows. Ainsi, les mises à jour sont téléchargées une seule fois depuis le serveur Windows Update sur Internet. Ensuite, les différents postes peuvent récupérer les mises à jour depuis ce serveur WSUS, limitant les téléchargements depuis Internet depuis un grand nombre d’ordinateurs. Comme les mises à jour sont récupérées depuis le réseau local, la bande passante Internet est libérée pour d’autres données.

Jusqu’à présent, un serveur WSUS est présent sur Meudon et un autre serveur WSUS est présent à Orléans. Depuis quelques semaines, le serveur de mises à jour d’Orléans a cessé de fonctionner, empêchant tous les postes de Meudon de recevoir leur mises à jour. De plus, un problème d’espace disque faible sur le serveur vieillissant de Meudon provoque des instabilités du serveur WSUS et donc des problèmes de livraison des mises à jour.

Pour remédier à ce problème, j’ai installé deux nouveaux serveur WSUS (un à Meudon, un à Orléans). A Meudon, cette installation a été faite sur le serveur physique où est installé le système de déploiement Windows. Pour Orléans, j’ai réutilisé un serveur physique assez récent qui ne servait plus. Sur ce dernier serveur, j’ajouterai par la suite une réplique du système de déploiement de Meudon, afin d’en bénéficier directement à Orléans.

L’initialisation du serveur WSUS de Meudon, le premier à être installé, s’est avérée plus compliquée que prévue. Devant télécharger de nombreuses mises à jour pour divers produits en synchronisation initiale, le serveur WSUS était trop instable et n’arrivait pas à tout télécharger. Il y a eu plantage du serveur sur les premières tentatives de synchronisation. La seule solution a été de désinstaller le rôle WSUS, nettoyer les fichiers et la base de données intégrée manuellement (la désinstallation ne supprime ni les fichiers de mises à jour, ni la base associée) avant de réinstaller le rôle et tout reconfigurer. Ce n’est qu’en ajoutant petit à petit les classes de mises à jour à récupérer et en effectuant une synchronisation et un téléchargement complet des mises à jour à chaque fois que le serveur a pu être mis en route définitivement. Afin de faciliter la tâche, j’ai également modifié des paramètres d’allocation de RAM sur le serveur IIS (Internet Information Service, dépendance de WSUS). En effet, la quantité de RAM par défaut de 1,8 Go est assez faible par rapport aux 16 Go disponibles sur le serveur. L’augmentation de ce paramètre (Private Memory Limit) à 4 Go a permis de rendre le serveur significativement plus disponible et plus stable.

Les postes raccordés à chaque serveur sont classés en deux catégories, qui sont attribuées par GPO (Group Policy Object), ce qui évite d’avoir à attribuer chaque poste sur le serveur WSUS directement. L’attribution se fait automatiquement en fonction l’OU (Unité d’Organisation) et de la GPO associée.

Le même procédure d’installation et de configuration est reproduite à Orléans en synchronisation directe avec Windows Update. Connaissant déjà les problèmes de synchronisation initiale trop volumineuse, j’ai ajouté les produits et les classes de mises à jour petit à petit et tout s’est bien déroulé du premier coup. Le résultat est un téléchargement total de 680 Go par serveur !

A Orléans, sur ce même serveur physique, il me restera à répliquer le système de déploiement Windows, ce qui fera l’objet du prochain article.