Histoires de BureauFonctionnalités avancées de WDS

Wes Miller

Sommaire

Gestion de ligne de commande
Magasin d'image
Multidiffusion
Journalisation WDS
Autres problèmes
Conclusion

Depuis deux mois, je consacre cette rubrique aux Services de déploiement Windows (WDS). J'ai commencé par m'intéresser à l'historique des outils de déploiement basés sur l'environnement d'exécution de prédémarrage (PXE) proposés par Microsoft, puis j'ai présenté les Services de déploiement Windows. Ce mois-ci, je vais approfondir la question et traiter des sujets suivants :

WDSUtil (le puissant utilitaire de ligne de commande pour WDS), le magasin d'image WDS, la journalisation WDS et l'utilisation de la fonctionnalité de multidiffusion dans WDS pour Windows Server® 2008.

Lorsque les services d'installation à distance (RIS) étaient fournis dans Windows® 2000 et Windows Server 2003, ils n'étaient pas aussi riches en fonctionnalités que beaucoup l'auraient souhaité. Trois domaines sont particulièrement concernés :

  • Performances (déploiement plus évolutif)
  • Journalisation/Audit
  • Automation de ligne de commande

Au cours de la lecture de cet article, vous verrez qu’avec la version initiale de WDS, et en particulier avec WDS dans Windows Server 2008, des avancées significatives ont été réalisées sur chacun de ces fronts.

Gestion de ligne de commande

J'ai noté le mois dernier que WDS offrait une console de gestion considérablement améliorée. Mais, et c'est encore plus important pour la plupart des entreprises, WDS dispose d'un nouvel utilitaire de ligne de commande pour la gestion, WDSUtil.exe (voir la figure 1). WDSUtil est installé avec le composant facultatif WDS sur Windows Server 2003 (SP1+WDS ou SP2) et avec le rôle WDS sur Windows Server 2008.

fig01.gif

Figure 1 Paramétrage de l'option de découverte d'architecture sur Oui avec WDSUtil (Cliquez sur l'image pour l'agrandir)

WDSUtil est un utilitaire étonnamment puissant, mais complexe. En effet, tout ce que vous pouvez faire via Microsoft® Management Console (MMC), et plus encore, peut être fait via WDSUtil. En fait, pour en avoir la preuve et diagnostiquer du même coup d'éventuels problèmes, exécutez :

wdsutil /get-server /show:config

Les résultats reflètent presque entièrement ce que vous verriez dans la MMC WDS, bien que WDSUtil puisse les présenter dans un format facilement lu que vous pouvez ensuite convertir en un fichier texte.

Pas assez d'informations ? Essayez d'exécuter la commande suivante, elle est encore plus détaillée :

wdsutil /get-server /show:all /detailed

Et vous pouvez arrêter et redémarrer le serveur WDS en exécutant :

wdsutil /stop-server
wdsutil /start-server

Vous trouverez une référence de commandes pour WDSUtil à l'adresse go.microsoft.com/fwlink/?LinkId=112194. Si vous préférez, vous pouvez également en télécharger une version .chm (avec tous les documents WDS 2008) à l'adresse go.microsoft.com/fwlink/?LinkId=89381.

Avec les services d'installation à distance, il n'était pas facile, à moins d'être un gourou des interfaces de service Active Directory®, de trouver via la ligne de commande si une GUID ou une adresse MAC spécifique était associée à un objet compte d'ordinateur (MAO) dans Active Directory. Avec WDSUtil, votre requête peut porter sur l'une ou l'autre.

Les GUID peuvent être déroutantes, car vous pouvez les entrer sous forme de chaînes binaires ou de chaîne GUID, la seule différence étant l'ordre des octets et l'absence de trait d'union. Les adresses MAC peuvent être entrées avec ou sans trait d'union en utilisant l'une des lignes de code suivantes :

wdsutil /get-device /id:01-23-45-67-89-AB
wdsutil /get-device /id:0123456789AB

Vous pouvez obtenir des informations sur les périphériques par chaîne binaire en utilisant cette commande :

wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6

Ou vous pouvez obtenir des informations sur les périphériques par chaîne GUID à l'aide de la commande suivante :

wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6

Un grand nombre de vos ordinateurs sont probablement capables d'exécuter la version 64 bits de Windows, mais malheureusement, certains ne signalent pas leur architecture correctement. Vous pouvez laisser WDS essayer de déterminer si un système est compatible x64 en exécutant un petit programme de démarrage réseau fourni avec WDS. Comme l'illustre la figure 1, vous pouvez le faire avec la commande suivante :

wdsutil /set-server /architecturediscovery:yes

En fait, la commande set-server de WDSUtil vous permet de configurer un grand nombre de paramètres de serveur. Pour voir les possibilités, exécutez cette commande :

wdsutil /set-server /?

Si vous avez mis à niveau un serveur WDS Windows Server 2003 vers Windows Server 2008, vous pouvez convertir n'importe quelle image RIPrep au format Windows Imaging (WIM) en exécutant cette commande :

WDSUtil /convert-RIPrepImage

Bien que WDSUtil puisse convertir les images RIPrep, les images RISetup restantes (installations par script WDS hérité/RIS traditionnelles) ne peuvent pas être converties.

La puissance de WDSUtil réside dans sa capacité à automatiser les tâches répétitives. Les commandes de la figure 2 vous donnent une idée des fonctionnalités de WDSUtil. Que vous introduisiez de nouveaux serveurs WDS, ajoutiez ou modifiez des images sur plusieurs serveurs, administriez votre infrastructure de multidiffusion ou spécifiez quel programme de démarrage réseau utiliser pour un client de démarrage spécifique, WDSUtil apporte une puissance qui n'était auparavant pas disponible dans les Services d'installation à distance.

Figure 2 Commandes de WDSUtil

Commande Description
/add Ajoute des périphériques, des images ou des groupes d'images.
/approve-AutoAddDevices Approuve les périphériques d'ajout automatique en attente et vous permet de définir les informations de configuration les concernant.
/convert-RiprepImage Convertit une image RIPrep héritée en une image WIM.
/copy-Image Duplique une image dans un magasin d'image.
/delete-AutoAddDevices Supprime la totalité ou certains périphériques d'ajout automatique spécifiques en attente.
/disable Désactive un serveur WDS ou un serveur de transport.
/disconnect-Client Déconnecte un client d'une transmission par multidiffusion ou d'un espace de noms.
/enable Active un serveur WDS ou un serveur de transport.
/export-Image Comme avec /export dans ImageX, cette commande exporte une image existante du magasin d'image vers une image WIM.
/get Obtient les propriétés et les attributs pour un périphérique, une image, un groupe d'images, un serveur WDS ou un serveur de transport.
/initialize-Server Configure un serveur WDS à des fins d'utilisation après la première installation.
/new Crée des images de capture ou de découverte, des transmissions par multidiffusion et des espaces de noms.
/progress Affiche les progrès lorsqu'une commande donnée est exécutée.
/reject-AutoAddDevices Rejette la totalité ou certains périphériques d'ajout automatique spécifiques en attente.
/remove Supprime des images, des groupes d'images, des transmissions par multidiffusion et des espaces de noms.
/replace-Image Remplace (écrase) une image par une nouvelle image.
/set Définit les propriétés et les attributs pour un périphérique, une image, un Groupe d'images, un serveur WDS ou un serveur de transport.
/start Démarre un serveur WDS ou un serveur de transport.
/stop Arrête un serveur WDS ou un serveur de transport.
/uninitialize-Server Annule les modifications apportées au serveur pendant l'initialisation du serveur (le ramène à un état non configuré).
/update-ServerFiles Met à jour les fichiers dans le dossier partagé REMINST avec les dernières versions du répertoire System32\RemInst du serveur.
/verbose Affiche la sortie détaillée lorsqu'une commande donnée est exécutée.

Magasin d'image

Le mois dernier, j'ai expliqué comment le stockage d’instance simple (SIS) utilisé par les RIS pour stocker les fichiers plus efficacement sur le disque a été abandonné dans WDS. Maintenant, toutes les images en mode natif (WIM), quel que soit le système d'exploitation, sont conservées dans le magasin d'image WDS. Comme je l'ai indiqué dans les articles précédents, cette fonctionnalité d'instance unique vous faisait gagner de l'espace dans les fichiers .wim lorsque les images de volume avaient des fichiers associés. Le magasin d'image WDS fonctionne de la même façon. En fait, il utilise la fonctionnalité WIM pour stocker les images.

Pour travailler avec le magasin d'image, vous devez avoir au moins un groupe d'images ; l'initialisation de WDS vous invite généralement à en créer un. Vous pouvez également créer un nouveau groupe d'images lorsque vous ajoutez une image d'installation, et l'image lui sera ajoutée (voir la figure 3).

fig03.gif

Figure 3 Création d'un nouveau groupe d'images (Cliquez sur l'image pour l'agrandir)

Qu'est-ce que le magasin d'image ? Regardez dans le répertoire RemoteInstall, dans le répertoire Images, et vous trouverez des répertoires pour chaque groupe d'images que vous avez créés. Comme l'illustre la figure 4, il y a un fichier .wim pour chaque image d'installation que vous avez importée dans le groupe d'images et un seul fichier .rwm (Resource WIM).

fig04.gif

Figure 4 Contenu d'un groupe d'images (Cliquez sur l'image pour l'agrandir)

Regardez attentivement les fichiers à la figure 4. Ce groupe d'images comprend :

  • install.wim (Windows Server 2008, Standard Edition)
  • install-(2).wim (Windows Server 2008, Enterprise Edition)
  • install-(3).wim (Windows Server 2008, Datacenter Edition)
  • install-(4).wim (Windows Server 2008, Standard Edition (Server Core)
  • install-(5).wim (Windows Server 2008, Enterprise Edition (Server Core)
  • install-(6).wim (Windows Server 2008, Datacenter Edition (Server Core)

Comparez à présent les tailles de ces fichiers à celles des fichiers de MMC (voir la figure 5). La taille de chaque fichier .wim de la figure 4 est une nettement inférieure à la taille du fichier .Res.rwm. Pourquoi ? Hé bien, pour économiser l'espace, les fichiers .wim affichés sont simplement des stubs des véritables fichiers. Ils contiennent les métadonnées permettant de restaurer le fichier .wim mais ne contiennent pas réellement les ressources du fichier. Toutes les ressources de fichier d'un groupe d'images sont stockées dans le fichier .rwm pour ce groupe d'images.

fig05.gif

Figure 5 Images affichées dans le gestionnaire de serveur (Cliquez sur l'image pour l'agrandir)

Pour modifier une image d'installation dans un magasin d'image, vous pouvez exporter l'image, apporter vos modifications puis remettre en place l'image (ou l'importer de nouveau), ou vous pouvez interagir avec elle en désactivant l'image d'installation appropriée à partir de MMC et apporter vos modifications en montant et modifiant le fichier .wim.

La réplication d'image à toujours posé problème avec les RIS. Lorsque vous copiez des fichiers SIS via le réseau, le SIS est perdu car il s'agit d'un attribut NTFS. Cela signifie que si vous aviez 40 Go d'images RISetup et RIPrep et que vous les répliquiez sur un autre serveur, même si le SIS Groveler les avait réduites à seulement 5 Go, vous répliquiez toujours 40 Go via le réseau. Ce n'est pas le cas avec le magasin d'image WDS. En fait, du fait de l'architecture du magasin d'image, vous pouvez l'enregistrer sur un serveur de fichiers distribué (DFS) et utiliser Réplication DFS (DFS-R) pour le répliquer de site à site.

Les détails de cette opération varient en fonction de la version de WDS. Pour Windows Server 2003, reportez-vous au chapitre 7, « Utilisation des images », dans la documentation téléchargeable à l'adresse go.microsoft.com/fwlink/?LinkId=81031. Pour Windows Server 2008, reportez-vous à « Stockage et réplication d'images à l'aide de DFS » sur go.microsoft.com/fwlink/?LinkId=121960. Comme les ressources sont toutes stockées dans le fichier .rwm, même lorsque vous copiez un groupe d'images d'un serveur à l'autre, la quantité de données échangée est une nettement inférieure à ce qu'elle serait si chaque fichier .wim entier était transmis (ou dans l'ancienne architecture SIS des RIS).

Quand créer un nouveau groupe d'images, et quand utiliser l'ancien groupe ? Les règles sont généralement identiques à celles en vigueur pour un fichier .wim. Bien que vous puissiez mettre une image de Windows XP Professionnel SP3 dans un groupe d'images composé principalement d'images de Windows Server 2008, cela n'aurait pas vraiment de sens, car vous ne gagneriez pas beaucoup d'espace. Comme avec les fichiers .wim, vous voudrez généralement avoir un groupe d'images pour, au moins :

  • Chaque version spécifique de Windows, version étant à la fois une référence standard (Windows XP Professionnel) et une révision sous forme de Service Pack (SP3).
  • Windows Server 2003 et versions antérieures : chaque version localisée dans une langue (pas le pack d'interface utilisateur multilingue). Avant Windows Vista®, les versions localisées étaient des binaires complètement différents, donc ils ne se stockaient pas bien dans un fichier .wim en termes d'instanciation unique.
  • Chaque Service Pack de chaque version. Bien que vous puissiez stocker des images Windows Server 2008 et Windows Vista SP1 ensemble, demandez-vous si cela est intéressant du point de vue fonctionnel dans votre organisation.

Le magasin d'image, encore plus que SIS avant lui, permet d'économiser l'espace, à la fois sur disque et via le réseau, et nécessite généralement peu de travail pour continuer à fonctionner sans problème.

L'une des plus grandes faiblesses des RIS résidait dans son manque d'évolutivité. Le déploiement multidiffusion est sur le point de rectifier cela. Les gens perçoivent souvent la multidiffusion comme un déploiement plus « rapide », mais il ne s'agit pas réellement de rapidité, mais de « plus ». Vous pouviez déjà déployer plusieurs systèmes via les RIS. En fait, les RIS pouvaient gérer le déploiement simultané de quelque 75 systèmes.

Mais bien avant d'approcher de cette limite, les performances étaient affectées et chaque installation prenait de plus en plus de temps. Pire encore, lorsque le nombre d'installations augmentait, le risque de défaillance faisait de même. Parallèlement, les installations multiples saturaient votre réseau avec le trafic réseau SMB (ainsi, pendant le déploiement, les employés pouvaient ne pas arriver à accéder à des ressources réseau critiques telles que Microsoft Exchange Server).

La multidiffusion permet d'augmenter considérablement le nombre de vos déploiements. Que vous déployiez quatre serveurs ou un centre de conférence avec 100 systèmes, la multidiffusion vous permet de réaliser ce déploiement dans un délai raisonnable et sans saturer le réseau. Bien que vous puissiez utiliser la multidiffusion pour déployer un seul système, ce n'est que lorsque vous avez plusieurs systèmes écoutant la transmission que les avantages d'échelle deviennent évidents.

Pour utiliser la multidiffusion, vous devez avoir des routeurs qui prennent en charge la multidiffusion. Généralement, cela signifie que l'espionnage par Internet Group Management Protocol (IGMP) doit être activé. Vous devez également avoir Windows PE 2.1 (Windows Server 2008 RTM ou Windows Vista SP1), car la version (2.0) accompagnant Windows Vista RTM ne peut pas recevoir de transmission par multidiffusion.

Vous devez également veiller, si vous avez plusieurs serveurs WDS (ou d'autres serveurs de multidiffusion) sur le même réseau, à spécifier une plage d'adresses IP personnalisée. Celle-ci peut être facilement modifiée via la MMC WDS en cliquant avec le bouton droit sur le serveur, puis en cliquant sur Propriétés et enfin sur l'onglet Paramètres réseau.

Lors de l'exécution d'une diffusion par multidiffusion, le serveur de multidiffusion peut régler la vitesse à laquelle le client le plus lent peut recevoir, ou il peut réguler la vitesse à un niveau plus élevé et abandonner les clients qui ne peuvent pas suivre. Pour garantir la fiabilité, WDS fonctionne à la vitesse du client le plus lent recevant la transmission.

Si vous trouvez que les performances de transmission sont plus lentes que prévu, exécutez wdsutil /Get-Multicast­Transmission/­Show-clients. Cette commande révèle le client maître qui limite la transmission. Vous pouvez ensuite déconnecter ce client et il recommencera à utiliser SMB au lieu de la multidiffusion. Pour un exemple de script qui déconnecte automatiquement les clients lents, allez sur go.microsoft.com/fwlink/?LinkId=121961.

Pour créer une transmission par multidiffusion, vous pouvez cliquer avec le bouton droit sur une image d'installation et sélectionner Créer une transmission par multidiffusion, ou vous pouvez cliquer avec le bouton droit sur Transmissions par multidiffusion dans la console WDS et sélectionner Créer une transmission par multidiffusion. Lorsque vous créez la transmission par multidiffusion, vous pouvez créer une Diffusion automatique ou une Diffusion planifiée. La diffusion automatique est utile lorsque vous avez plusieurs clients qui viennent régulièrement en ligne, et qui ont tous besoin exactement de la même image ; les nouveaux clients seront automatiquement ajoutés à la transmission en cours qui a été établie pour le tout premier client demandant une image d'installation. La diffusion planifiée vous permet de configurer une taille de groupe qui, si elle est atteinte, entraîne le début d'une transmission.

Vous pouvez également configurer la transmission pour qu'elle démarre à une heure spécifiée. Une fois que les clients utilisent la transmission par multidiffusion, vous pouvez les afficher en cliquant sur le nom d'image. Dans le volet de droite, vous voyez les détails des clients connectés à la transmission.

Généralement, vos utilisateurs finaux utilisent la multidiffusion du client d'installation WDS. Cependant, il existe un utilitaire de ligne de commande appelé WDSMCast et intégré au kit d'installation automatisé (WAIK) de Windows Server 2008, qui vous permet de demander un fichier .wim via une transmission par multidiffusion depuis WDS. Le fichier .wim doit être transféré en intégralité et appliqué au client ; en conséquence vous devrez vérifier que l'espace disque est suffisant pour l'image à stocker et appliquer. Le mois prochain, je vous expliquerai comment intégrer WDSMCast dans votre propre processus de déploiement personnalisé.

Journalisation WDS

WDS est capable d'exécuter une journalisation et un suivi considérables, bien qu'une grande partie de cette fonctionnalité soit désactivée par défaut pour économiser de l'espace. Il existe deux types d'enregistrement des événements : lorsqu'un client écrit dans le journal des événements Windows et l'enregistrement dans les journaux de suivi pour d'autres aspects de WDS.

Cependant, dans Windows Server 2008, WDS exécute pas mal de journalisation par défaut. Ces journaux sont disponibles sous Outils d'administration | Observateur d'événements. Les journaux WDS sont visibles dans l'Observateur d'événements sous Journaux des applications et des services | Microsoft | Windows | Déploiement-Services-Diagnostic. Par souci de commodité, ce sont les mêmes journaux qui sont visibles lorsque vous affichez le rôle WDS dans MMC (voir la figure 6).

fig06.gif

Figure 6 Affichage des événements WDS dans le gestionnaire de serveur (Cliquez sur l'image pour l'agrandir)

L'enregistrement des clients WDS (visible dans les journaux des événements de la figure 6) peut être démarré en exécutant WDSUtil avec les arguments suivants :

wdsutil /wdsclientlogging /enabled:yes /logginglevel:info

Vous pouvez également activer la journalisation de suivi sur plusieurs sous-composants de WDS. Pour configurer le suivi, définissez une valeur de Registre DWORD en conséquence sous la ou les clés de Registre, comme illustré à la figure 7. Tous les journaux de suivi sont stockés sous \Windows\tracing. Vous devez ensuite redémarrer le composant approprié pour que la journalisation commence.

Figure 7 Paramétrage de la journalisation de suivi

Composant WDS Clé de Registre Valeur de Registre Nom du journal
Serveur HKLM\SOFTWARE\Microsoft\Tracing\WDSServer\EnableFileTracing 1 wdsserver.log
Multidiffusion HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\TraceDisabled 0 wdsserver.log
Composants de gestion HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMGMT\EnableFileTracing 1 wdsmgmt.log
MMC HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMMC\EnableFileTracing 1 wdsmmc.log

WDS dispose également de compteurs de performances (décrits à l'adresse go.microsoft.com/fwlink/?LinkId=121962) que vous pouvez contrôler en cas de problèmes de performances du système (ou pour exécuter des analyses des performances du système à l'avance). Comme indiqué ci-dessus, vous pouvez obtenir des informations plus détaillées si vous rencontrez des problèmes en utilisant les commutateurs /detailed, /verbose, ou /progress avec WDSUtil.

Si vous avez des problèmes avec des clients WDS se connectant ou interagissant avec un serveur WDS, Microsoft Network Monitor (Netmon) est un excellent outil pour déboguer ces problèmes. Network Monitor est disponible au téléchargement à l'adresse go.microsoft.com/fwlink/?LinkId=121491.

Autres problèmes

Je pense qu'il convient de mentionner deux autres problèmes. Le premier concerne la mémoire : n'oubliez pas qu'au niveau de son noyau, WDS est basé sur Windows PE 2.x. Cela signifie que les clients WDS ont besoin d'au moins 384 Mo de mémoire RAM, et idéalement de 512 Mo pour des performances optimales. Rappelez-vous également que Windows PE 2.x ne peut pas démarrer sur des systèmes non ACPI (Advanced Configuration and Power Interface), et que ce n'est pas toujours synonyme de vieux matériel. Des systèmes relativement récents ne prenant pas en charge ACPI ont été signalés.

Notez que ces systèmes ne prennent pas non plus en charge Windows Vista ou Windows Server 2008. Pour les systèmes qui ne prennent pas en charge ACPI, vous devez garder un serveur RIS ou WDS Windows Server 2003 ou version antérieure disponible, avec ces clients préconfigurés sur ce serveur, ou installer Windows via un mécanisme non-PXE.

Enfin, n'oubliez pas que si vous voulez démarrer Windows PE 1.x depuis votre serveur, vous devrez également utiliser un serveur RIS ou WDS Windows Server 2003 ou version antérieure, car WDS dans Windows Server 2008 ne peut pas démarrer une image Windows PE 1.x (RAMDisk ou PXE).

Jusqu'ici, je me suis plongé dans l'historique, les principes de base et les notions avancées de WDS. Le mois prochain, j'examinerai certains scénarios WDS personnalisés, en particulier comment vous pouvez interagir avec WDS et l'amener à exécuter les tâches pour lesquelles vous en avez besoin, souvent sans utiliser le WDS/l'installation existants.

Wes Miller est responsable de produit technique pour CoreTrace (www.CoreTrace.com) à Austin au Texas. Il travaillait auparavant chez Winternals Software et comme responsable de programme pour Microsoft. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.