Plateforme personnelle : MDT et WSUS
Lors de la mise en œuvre de MDT, un post concernait l’installation de WSUS sur notre plateforme. J’avoue que je l’avais un peu oublié celui-la. Mais je prend de bonnes résolutions avant même le début de la fin d’année:)
Première étape : Télécharger les mises à jour.
Cela fait quelques temps que le serveur WSUS est installé mais aucune synchronisation n’a été réalisée. Pour cela :
- Lancer la console “Microsoft Windows Update Services 3.0 PS1”
- Se positionner sur le nœud “Synchronizations”
- Afficher le menu contextuel tel qu’illustré ci-dessous :
- Sélectionner l’option “Synchronize now”
- Faites comme moi et allez prendre un grand café par ce que cela peut être excessivement long!
Au terme de l’opération, l’interface nous indiquera le nombre de mises à jour téléchargées
Seconde étape: Approuver les mises à jour.
Les télécharger, c’est bien, les approuver, c’est encore mieux. Pour cela le plus simple, c’est encore de se positionner sur le nœud représentant le serveur WSUS tel qu’illustré ci-dessous :
Le résumé présenté indique qu’au moins toutes les mises à jour critiques ont été approuvées, ne restent que quelques 1142 mises à jour en attente d’approbation. Faites votre choix! Attention cependant, cela comprend aussi des applications comme Internet Explorer qui sont des téléchargement obligatoires passés un certain temps.
Troisième étape : Télécharger le client WSUS 3.O
MDT est capable d’utiliser WSUS à condition que les systèmes d’exploitation utilisent au moins la version 3.0. Par défaut, seuls Windows Vista et Windows Server 2008 intègrent la version 3.0. Pour eux, c’est sans problème. Pour Windows XP et Windows Server 2003, une mise à niveau s’impose :
Le client 32 Bits devra être placé tel que dans le répertoire “.\Distribution\Tools\X86” et son équivalent X64 dans le répertoire “.\Distribution\Tools\X64”.
Le fait de placer ces exécutables à ces emplacements fera que le script “ZTIWindowsUpdate.Wsf” pourra les installer si le système d’exploitation n’est pas à jour. Pour cela, il faut impérativement conserver les noms des exécutables téléchargés. Si le script “ZTIWindowsUpdate.Wsf” ne peut localiser ces exécutables, alors il tentera de télécharger celui correspondant à la plateforme sur Internet.
Quatrième étape : Activation du script “ZTIWindowsUpdate.Wsf”
Techniquement le script est bien présent dans les séquences de tâches mais il est désactivé par défaut.
Si on développe le nœud “State restore” dans la séquence de tâche tel qu’illustré ci-dessous :
On constate que la tâche existe bien mais qu’elle est désactivée par défaut. Charge à nous de la réactiver en décochant la case d’option.
On remarquera que l’exécution de cette tâche est soumise à condition. Elle ne s’exécute que si :
- La séquence de tâches n’est pas en phase de Sysprep
- La séquence de tâches n’est pas non plus en phase de préparation de Sysprep
On remarquera qu’il y a deux séquences de tâches “Windows Updates”. La différence est qu’entre les deux on installe les applications qui pour certaines nécessiteront d’être mises à jour (Office par exemple)
Une fois les deux tâches réactivées, MDT exécutera le script “ZTIWindowsUpdate.Wsf”. Il ne manque plus qu’une seule information, ou télécharger les mises à jour?
Cinquième étape : La propriété WSUSServer
Dans la configuration actuelle, le script “ZTIWindowsUpdate.Wsf” va tout simplement travailler avec Windows Update, rien que cela! WSUS permet non seulement de disposer d’un repository local des mises à jour, mais aussi de la capacité à spécifier quelles seront celles qui doivent être appliquées. Encore faut-il que le script sache avec quel serveur WSUS il doit travailler. Pour cela, il faut actualiser le point de distribution en ajoutant la ligne suivante dans le fichier “CustomSettings.Ini”
WsusServer=http://<nom FQDN de votre serveur SUS>:Port
Note : Pour rappel, si on a réalisé une installation personnalisée de WSUS (ce qui est mon cas), on a décidé de créer un site web dédié, donc ne répondant pas au port par défaut mais 8530!
Quand la sécurité s’en mêle
Jusqu’à maintenant, tout allais pour le mieux mais, il y a bien un mais. L’installation automatique du client WUAU par MDT, cela fonctionne que si le système d’exploitation n’est pas sécurisé (globalement Windows XP SP1 et Windows Server 2003 RTM, sic, …). Dès qu’on utilise Windows XP SP2 et Windows Server 2003 SP1, les choses se corsent. La sécurité a fait son apparition. Lorsqu’on tente d’exécuter un programme localisé sur un partage réseau (ce que fait le script “ZtiWindowsUpdate.Wsf”), le système d’exploitation informe l’utilisateur de l’opération et en profite pour l’avertir sur les risques de sécurité tel qu’illustré ci-dessous :
Le script “ZtiWindowsUpdate.Wsf” bloque sur l’installation du client Windows Update Agent. Face à cette problématique, la première approche aurait été de revoir le niveau de sécurité pour désactiver cette fonctionnalité, la seconde de réécrire le script incriminé. Ce sont typiquement des solutions que je veux éviter! On a ruser avec une solution propre à MDT, à savoir une application. L’astuce va consister à installer une application dans la séquence de tâches avant la tâche “Windows Update”. Cette application ne sera ni plus ni moins que l’agent Windows Update. Pour cela on va
- Décompresser le contenu des exécutables dans deux répertoires (une application X86 et une autre X64)
- Créer deux applications avec comme ligne de commande “WUSETUP /QUIET /NORESTART”
- Insérer une tâche “Install Application tel qu’illustré ci-dessous :
Lors de l’exécution de la séquence de tâches on repère facilement le processus de mise à jour :
D’une part, il est visible, d’autre part il est lent! Pourquoi, tout simplement car il repose sur un protocole qui est particulièrement économe en bande passante. Un peu de tuning au niveau de Bits permettait d’accélérer les choses. Au terme du déploiement, le système d’exploitation aura fait son rapport au serveur WSUS pour indiquer dans quelle mesure il a réussi à installer les mises à jour ou non. Nous n’auront plus qu’à demander la génération d’un rapport dans WSUS.
L’idéal est d’intégrer cette application dans la séquence de tâches utilisée pour créer nos images de références (Windows XP et Windows Server 2003). De cette manière le problème ne se posera plus. Les tâches “Windows Updates” peuvent elles êtres conservées dans les séquences de tâches de déploiement pour finaliser l’installation des postes de travail en intégrant les dernières mises à jour qui ne sont pas encore intégrées aux images de références. Attention cependant à un détail, le processus gère de lui même les éventuels redémarrages mais est limité à sept. Donc s’il y a trop de mises à jour qui nécessitent un redémarrage, il se peut que le système ne soit pas complètement à jour au terme du processus de déploiement.
Voila, un de plus
Bon noël
Benoît – Simple by Design