4. Scénarios de déploiement et gestion des sites distants
Les entreprises se développant de plus en plus, elles ont besoin de
posséder un réseau homogène dans l'ensemble de ses succursales. Microsoft a donc
tenu compte de ces attentes et optimisé son logiciel de gestion des mises à jour
pour fonctionner de mieux en mieux sure des réseaux complexes dispersés.
Voyons tout d'abord les différents scénarios de déploiement
:
 |
Dans ce scénario là (le plus simple
à mettre en place), un serveur WSUS unique se synchronisant directement
sur Internet au travers de votre pare-feu.
Vos clients se connectent
simplement à votre serveur WSUS et se mettent à jour.
C'est le modèle classique utilisé
pour les petites entreprises possédant un unique site. Vous pouvez même
l'implémenter chez vous si vous avez plusieurs ordinateurs :)
|
|
Vous pouvez choisir de mettre en
place plusieurs serveurs WSUS dans votre entreprises de manière
indépendante. C'est à dire que chacun possède sa propre console
d'administration et chacun télécharge son contenu depuis le site de
Microsoft Update sur Internet.
Dans ce scénario on peut imaginer
que chaque serveur est utilisé pour des réseaux LAN différents voir des
réseaux WAN (succursales).
On peut définir par exemple un
serveur WSUS chargé de mettre jour le réseau des serveurs et
applications et un autre uniquement pour les systèmes d'exploitation
clients comme Windows XP ou Vista...
|
 |
 |
Il est également possible de mettre en place un
structure hiérarchisée et liée de serveur WSUS. On parlera alors
de serveur amont et serveur aval. Dans ce cas seul
un serveur WSUS se synchronisent et accède à Internet. C'est bien
évidemment le serveur amont.
Pour les serveurs "aval" il existe deux
cas de figure : soit simple réplica dans ce cas là c'est une copie
conforme du premier serveur (même mise à jour, même groupes d'ordinateurs)
soit serveur autonome.
Rendez-vous plus bas dans cet article pour obtenir
plus de détails sur ces deux possibilités. |
|
Dans certaine entreprise l'accès à
Internet est très limité voir inexistante.
Dans ce scénario, un seul serveur WSUS possède une connectivité et est
donc responsable du téléchargement des mises à jour.
Ensuite un administrateur exporte les
métadonnées (wsusutil.exe) et le contenu des mises à jour (ntbackup) sur DVD puis les importes sur un
autre serveur WSUS qui est est connecté au réseau local des clients.
On peut également imaginer l'envoie de
ce DVD dans des sites ne possédant pas de connexion internet... |
 |
En vous rendant dans Source des mises à jour et serveur
proxy vous
pouvez choisir de modifier la source des vos mises à jour c'est à dire soit Microsoft Update
ou un serveur amont. Ceci n'était pas possible avec la version 2 de WSUS sans
réinstallation préalable.
Concernant les serveurs avals nous allons retrouver
deux cas de figure :
-
Serveurs avals en mode autonome : c'est la configuration
de serveur que vous allez utiliser dans une structure hiérarchisée
comportant un siège social et des succursales. Pour cela il suffit de
configurer comme source de mises à jour un serveur amont. Dans ce cas, le
serveur aval dispose de sa propre base de groupe d'ordinateur. Il n'y a
aucun lien avec le serveur amont à ce niveau là. Le serveur aval autonome
n'est pas libre de choisir la liste des produits et classification qui
l'intéresse; il dépend pour cela de son serveur amont. D'ailleurs si vous
vous rendez dans les options afin de les modifier un message indique : "Ce
serveur est configuré pour être synchronisé à partir d'un serveur WSUS en
amont. Les produits et les classifications peuvent uniquement être
configurés sur le serveur en amont".
En revanche, une nouveauté de la version 3 de WSUS,
est la possibilité de sélectionner les langues que l'on souhaite télécharger
sur le serveur aval autonome. Ainsi on peut imaginer une multinational dont
le siège social se trouve à Paris, muni d'un serveur WSUS téléchargeant les
mises à jour avec les langues Françaises, Allemandes et Anglaises. Cette
entreprise possède des succursales à Londres et Munich et bien on pourra
choisir que les serveurs WSUS locaux ne prennent en compte que leur langue
respective. Concernant les mises à jour, vous êtes libres de les approuver
ou non et de les installer à votre guise.
-
Serveurs avals en mode réplica : dans ce cas de
figure il s'agît d'une copie conforme du serveur amont. En effet ici
l'ensemble des options de configuration (produits et classification),
approbation des mises à jour ainsi que les groupes d'ordinateurs seront
répliqués. A noter que seul les noms des groupes sont répliqués et non la
liste des ordinateurs présents à l'intérieur. Si vous tentez de modifier certaines options, vous pourrez voir
le message suivant s'afficher : "Les options sont désactivées, car
ce serveur est un serveur réplica". Vous ne pouvez pas contrôler l'approbation des
mises à jour au niveau d'un serveur aval en mode réplica. Ce type de
configuration est mis en place dans des gros sites afin de répartir les
ordinateurs sur 2 ou plusieurs serveurs WSUS par exemple.
Encore une nouveauté de WSUS 3 concernant
ces modèles de déploiement est sa possibilité de changer de statut sans
réinstallation. C'est à dire qu'un serveur aval peu être défini en tant
que serveur autonome ou réplica et inversement sans réinstaller pour autant le logiciel. Ce qui
n'était pas le cas dans les versions antérieurs. De même il peut passer de
serveur hiérarchisé en serveur indépendant en modifiant simplement les options
de source.
Une autre nouveauté qui s'applique aussi bien au niveau des
serveurs indépendant que des serveurs avals est la configuration avancée de
la réplication. Contrairement aux éditions précédentes, il est dorénavant
possible de planifier une synchronisation plusieurs fois par jour. En effet avec
WSUS, vous étiez limités à 1 fois par jour, soit toutes les 24 heures. Maintenant
vous avez un maximum de 24 fois par jours soit 1 fois par heure. Alors bien
évidemment, ceci n'est peut être pas très utilisé de se synchroniser toutes les
heures, mais on peut imaginer que ceci peut être pratique pour les sites
distants afin d'éviter en cas d'erreur de connexion d'attendre 24h avant de
recommencer. Cela permet surtout de réduire les délais de réplication en cas
d'approbation de mises à jour importantes ou de rajout de produits...
Nous pouvons également noter quelques éléments de configuration
au niveau de la localisation des mises à jour. En effet un serveur aval peut
très bien récupérer toutes les méta données au niveau du serveur amont et le
contenu des mises à jour directement sur Internet. Ce qui peut s'avérer très
pratique dans le cas d'une succursale disposant d'un faible accès à la maison
mère (suffisant pour récupérer les informations sur les mises à jour), mais
d'une connexion haut débit pour Internet.
Pour cela, rendez-vous dans les options de Fichiers et langues des mises à jour
:
Puis cochez la case "Téléchargez les fichiers à partir de
Microsoft Update (ne pas télécharger à partir d'un serveur en amont)".
Ceci permet donc pour un serveur en aval d'être contrôlé par un autre serveur en
amont sans pour autant surcharger l'intégralité de la bande passante entre les
deux sites.
Il est même possible pour les clients distants qui sont connectés avec une
liaison lente au site principale de leur spécifier de télécharger les mises à
jour approuvées par WSUS directement à partir de Microsoft Update.
Une autre option possible est l'utilisation des fichiers d'installation
rapide. En quoi cela consiste-t-il ? Généralement une mise à jour remplace
un fichier existant sur votre disque dur afin de combler un bug ou une faille de
sécurité dans le code. C'est donc l'intégralité du fichier qui est écrasé.
Seulement, juste une infime partie dudit fichier nécessite une modification.
L'utilisation des fichiers d'installation rapide permet justement d'installer
uniquement la différence entre les deux fichiers (ce que l'on appelle le
delta).
Contrairement à ce que l'on peut penser la taille des fichiers
téléchargés est plus grosse car pour chaque fichier il faut avoir toutes les
versions possibles. Par contre pour les clients cela va beaucoup plus vite par
la suite. Voici un schéma expliquant ainsi la comparaison des tailles des
fichiers téléchargés en MO. Par défaut cette option est désactivée.
|
- Comparaison de l'utilisation des fichiers
d'installation rapide - |
|
 |
 |
|
Option activée |
Option désactivée |
Si vous possédez une entreprise disposant de plusieurs sites
géographiques, une problématique peut s'initier... En effet on peut facilement
imaginer que vous disposiez de nombreux utilisateurs mobiles. Ces utilisateurs
voyageant beaucoup ont donc l'habitude de se connecter à de nombreux réseaux
différents. Bien évidemment vous souhaitez que ces derniers récupèrent leurs
mises à jours sur le serveur WSUS le plus proche. C'est ce que nous allons
aborder ici.
-
La première chose à faire est d'identifier tous les
serveurs WSUS de chaque réseau et de noter leur adresse ip.
-
Dans le console DNS, créez un nouvel enregistrement de
ressource (RR) de type A (hôte) nommé WSUSServer par exemple point vers
l'adresse ip d'un serveur WSUS. Répétez cette même étape pour chaque server
WSUS.
-
Dans les propriétés du serveur DNS, pensez à activer la
prise en charge du Round Robin ainsi que la fonction de tri des masques
réseau.
-
Configurez vos clients pour utiliser WSUS en spécifiant
comme nom : WSUSServer (comme définie dans le DNS)
Ainsi avec cette méthode, lorsqu'un client voudra contacter
son serveur WSUS, il interrogera le DNS qui à lui reverra l'adresse IP du
Serveur WSUS local.
 Introduction
1. Installation de WSUS 3
1.1 Les prérequis
1.2 Mise à jour depuis WSUS 2.0
1.3 Nouvelle installation
1.4 Installation automatisée
1.5 Remarques (recommandations…)
2. Nouveautés de WSUS 3 (Partie 1/2)
2.1 La console MMC 3
2.2 Ciblage des ordinateurs
2.3 Deux nouveaux assistants
3. Nouveautés de WSUS 3 (Partie 2/2)
3.1 Surveillance / Reporting
3.2 Performances
3.3 Gestion des mises à jour
3.4 Personnalisation de l'affichage
4. Scénarios de déploiement et gestion des sites distants
4.1 Les différents scénarios de déploiement
4.2 Source des mises à jour et serveur proxy
4.3 Planification de la syncrhonisation
4.4 Fichiers et langues des mises à jour
4.5 Prise en charge des utilisateurs mobiles
5. Mise en place d'un cluster WSUS (NLB) + Remote SQL
5.1 Configuration du serveur SQL distant
5.2 Configuration des autorisations administratives
5.3 Installation de WSUS sur les serveurs frontaux
5.4 Mise en place d'un partage DFS
5.5 Configuration de IIS pour accéder au partage DFS
5.6 Configuration du NLB : Network Load Balancing
5.7 Derniers paramètres et test du cluster !
Conclusion
|
|
 |
 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|
WSUS 3 : nouveautés et mise en production !
