La gestion des mises à jour permet de mieux
contrôler les différents statuts et les déploiements.
En effet, l'approbation d'une ou plusieurs mises à jour
se fait très simplement dans la console. Une fois l'ensemble des mises
à jour sélectionnées, clic droit puis
choisir Approuver pour l'installation. Choisir
pour quels groupes d'ordinateurs la ou les mises à jour doit
s'appliquer. Bien évidemment il y a un héritage selon
l'imbrication des groupes. On peut pour un groupe donné (ici New York et
Pékin) refuser la mise à jour. Il est également possible
de définir une deadline pour l'installation de la mise à jour,
c'est à dire une date limite comme par exemple, un jour - une semaine -
un mois - ou une date personnalisée. Il est possible avec WSUS 3 de
créer plusieurs règles d'approbations en fonction du type de mise
à jour et du produit. Il est également possible que les
règles d'auto approbation peuvent être appliquées au
contenu déjà existant dans WSUS.
Figure 20 : approbation des
MAJ 1- PERSONNALISATION DE L'AFFICHAGE
Cette option propose de personnaliser un peu l'affichage de
votre console WSUS. Elle est découpée en trois sous parties :
· Données des serveurs réplicas en
aval : on peut choisir d'inclure dans l'affichage de notre serveur ou
non les données provenant d'un serveur en aval en mode
réplica.
· Accessibiité : Afficher les
erreurs de validation dans des fenêtres contextuelles
· Liste des tâches à effectuer
: on peut choisir la liste des tâches à effectuer sur ce
serveur qui apparaissent sur la page d'accueil de la console de gestion. En
effet par exemple l'utilisation du protocole SSL est quelque chose qui nous ai
constamment rappelé, si on décide de ne pas l'implémenter,
il peut
être préférable de supprimer l'affichage
permanant du message stipulant qu'on doit le mettre en place.
Figure 21 :
personnalisation de l'affichage de la console MMC.3 2- SOURCE DES
MISES A JOUR ET SERVEUR PROXY
En se rendant dans Source des mises à jour et
serveur proxy on peut choisir de modifier la source des vos mises à
jour c'est à dire soit Microsoft Update ou un serveur amont
sans réinstallation préalable de celui-ci.
Concernant les serveurs avals nous allons retrouver deux cas de
figure :
· Serveurs avals en mode autonome :
c'est la configuration de serveur qu'on va 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. 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 on se rende 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, on a 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, on est
libres de les approuver ou non et de les installer à notre 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 on tente de modifier certaines
options, on pourra voir le message suivant
s'afficher : "Les options sont désactivées,
car ce serveur est un serveur réplica". On ne peut 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.
Dans les modèles de déploiement on a la
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. De même il peut passer de serveur
hiérarchisé en serveur indépendant en modifiant simplement
les options de source.
3- PLANIFICATION DE LA
SYNCHRONISATION
Une possibilité d'appliquer au niveau des serveurs
indépendant que des serveurs avals la configuration avancée de la
réplication. Contrairement aux éditions
précédentes, on peut ainsi planifier une
synchronisation plusieurs fois par jour. On a un maximum de 24 fois par
jours soit 1 fois par heure. 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.
Figure 22 : planification
de la synchronisation
4- FICHIERS ET LANGUES DES MISES A
JOUR
On peut é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étas donnés 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.
On coche 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.
Figure 23 : fichiers et
langues des MAJ
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 notre 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
Figure 24 : comparaison
d'installation rapide de fichier 5- PRISE EN CHARGE DES UTILISATEURS
MOBILES
Si on possède une entreprise disposant de plusieurs sites
géographiques, une
problématique peut s'initier. En effet on peut facilement
imaginer que l'on dispose de nombreux utilisateurs mobiles. Ces utilisateurs
voyageant beaucoup ont donc
l'habitude de se connecter à de nombreux réseaux
différents. Bien évidemment on
souhaite que ces derniers récupèrent leurs mises
à jour sur le serveur WSUS le plus proche.
· La première chose à faire est d'identifier
tous les serveurs WSUS de chaque réseau et de noter leur adresse ip.
· Dans la console DNS, créer un nouvel
enregistrement de ressource (RR) de type A (hôte) nommé
WSUSServer qui point vers l'adresse ip d'un serveur WSUS.
Répéter cette même étape pour chaque server WSUS.
· Dans les propriétés du serveur DNS, activer
la prise en charge du Round Robin ainsi que la fonction de
tri des masques réseau.
· On configure nos 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.
