Histoires de BureauPersonnalisation des Services de déploiement Windows

Wes Miller

Sommaire

Remplacer ce que vous avez
Coup d'œil sur la pile
Programme de démarrage réseau
Fournisseur PXE WDS
Démon TFTP
Magasin de données de configuration de démarrage
Windows PE
Serveur de transport
Multidiffusion personnalisée
Conclusion

Cela fait trois mois que j'explore les Services de déploiement Windows (WDS) et leurs origines, suivies par une présentation, puis par un examen plus détaillé de certains sujets avancés tels que WDSUtil et la multidiffusion. Dans ce dernier article de la série, nous allons voir où et comment personnaliser et configurer WDS pour répondre aux besoins de votre organisation. La plupart des outils Microsoft sont conçus avec une certaine souplesse de configuration. Toutefois, c'est en les mettant à l'épreuve que vous découvrez si ces outils répondent effectivement à vos besoins ou si, comme c'est souvent le cas, ils doivent être légèrement adaptés à vos scénarios.

Remplacer ce que vous avez

Ces derniers temps, les lecteurs me posent souvent la question suivante : « Je possède x (une technologie de déploiement existante). Les services WDS sont-ils compatibles avec x et disposent-ils de fonctionnalités similaires » ? Avec l'obsolescence des services ADS (Automated Deployment Services), une question encore plus intéressante serait : « Comment puis-je effectuer un déploiement et une reconfiguration rapides de serveurs, et WDS peut-il le faire pour moi » ?

Bien que WDS n'ait pas été conçu comme un remplacement exact pour ADS et qu'il lui manque en fait quelques composants clés pour être considéré comme un vrai remplaçant, avec quelques efforts, vous pouvez utiliser WDS à la place d'ADS. De même, si certaines fonctions de WDS ne fonctionnent pas pour vous, vous verrez qu'un grand nombre de ses composants peuvent être remplacés, avec un niveau de complexité et d'ingénierie variable. Jetons un coup d'œil sur le déploiement via WDS et examinons les composants que vous pourriez vouloir personnaliser ainsi que la manière de le faire.

Coup d'œil sur la pile

La figure 1 illustre les composants dans le processus de déploiement de WDS. Chacune de ces étapes peut être personnalisée dans une certaine mesure. J'ai utilisé des couleurs différentes pour chaque étape afin de refléter ce que je crois être la complexité (généralement les compétences de développement) du processus de remplacement ou de personnalisation de cette étape. Plus le bleu est foncé, plus l'étape risque d'être difficile à personnaliser.

Figure 1 Complexité de la personnalisation de WDS

Le degré de complexité de la personnalisation de chaque étape, dépend, bien sûr, des compétences de votre équipe (développement ou script) et de votre connaissance de WDS, du format WIM (Windows Imaging Format), d'Active Directory ou de toute autre technologie que vous souhaitez intégrer, telle que SQL ou ADSI. Examinons chacune de ces étapes ; réfléchissez à la façon dont vous voudriez les personnaliser et les méthodes que vous utiliseriez.

Programme de démarrage réseau

Je doute que vous ayez besoin de créer des Programmes de démarrage réseau (NBP) personnalisés pour remplacer ceux qui existent sur WDS, mais il est possible que vous ayez à le faire. WDS inclut des NBP destinés à être utilisés avec des systèmes sans affichage (généralement les serveurs) ou des systèmes où vous pouvez ou non appeler F12, et ainsi de suite. Ces NBP sont préconfigurés dans Active Directory avec WDSUtil, ou vous pouvez remplacer Startrom.com par le NBP que vous voulez utiliser pour tous les systèmes qui ne sont pas préconfigurés (par exemple, si tous vos systèmes sont sans affichage ou si vous ne voulez jamais utiliser F12).

Malheureusement, les documents qui peuvent vous aider à créer votre propre NBP ne sont pas très nombreux (voir msdn.microsoft.com/library/bb870970.aspx pour plus d'informations). Un NBP est un tout petit exécutable de 16 bits comportant des restrictions sévères et nécessitant des connaissances de programmation spécifiques. Je recommande généralement l'utilisation des NBP existants qui sont fournis avec WDS, à moins que vous ne tentiez de satisfaire à une exigence bien particulière et ne disposiez d'une équipe de développement possédant les compétences appropriées.

Fournisseur PXE WDS

Avec les services d'installation à distance (RIS), les commentaires que nous recevions de nos clients nous faisaient souvent part de leur souhait d'utiliser un autre magasin de données qu'Active Directory pour leurs informations, notamment SQL Server. Avec WDS, la conception inclut une infrastructure enfichable pour les fournisseurs PXE (Pre-Boot eXecution Environment). Cela signifie que dans vos tâches de développement, vous pourriez utiliser un autre magasin de sauvegarde, en plus d'Active Directory, pour les informations sur PXE.

WDS comprend son propre fournisseur qui utilise Active Directory ; désormais, SCCM (System Center Configuration Manager) se connecte également à WDS et implémente son propre fournisseur. La documentation liée à l'écriture de votre propre fournisseur est rare, et les exemples de code ne sont pas faciles à trouver non plus (bien que le SDK Windows propose un peu de documentation et quelques exemples). Il s'agit donc d'une tâche plutôt complexe. À moins d'avoir des exigences bien particulières pour cet aspect du processus de démarrage, je vous conseille encore une fois de ne pas utiliser de fournisseur PXE personnalisé.

Démon TFTP

Il arrive parfois que les clients aient déjà investi dans leur propre démon TFTP (Trivial File Transfer Protocol) avant l'arrivée de WDS. Puisque les serveurs PXE ne fonctionnent pas bien ensemble, cela signifie souvent qu'il faut se contenter d'un seul serveur.

D'après mon expérience, les clients prennent généralement un démon TFTP existant, souvent un démon TFTP de type Linux, et lui font démarrer d'autres systèmes d'exploitation. Avec l'infrastructure RIS originale, vous ne pouviez pas le faire. Toutefois, avec l'avènement du démarrage RAMDisk, cette opération est devenue possible, et peut toujours être exécutée avec des images de démarrage de type WDS.

N'oubliez pas, cependant, que vous vous aventurez dans un domaine où Microsoft, n'assure aucun support technique, et qui peut causer des problèmes qui seront difficiles à diagnostiquer. En outre, avec le démon TFTP amélioré de WDS, il est possible que vous vous éloigniez des bonnes performances. Dans l'idéal, je vous conseille d'utiliser le démon TFTP de WDS existant et d'essayer d'utiliser les délais d'expiration de PXE, la préconfiguration et/ou les bords du réseau pour déterminer quel client démarre depuis quel serveur PXE au lieu d'essayer de forcer un serveur existant à s'ajuster à cette opération.

Magasin de données de configuration de démarrage

Avec RIS, il n'était jamais possible, au niveau du démarrage, de spécifier ce qui devrait être démarré ; il fallait toujours passer par l'Assistant de sélection du système d'exploitation (OSC) et sélectionner une option (installation, Windows PE ou autre). Comme WDS utilise un chargement complet pour lancer le réseau, il prend également en charge la personnalisation du magasin de données de configuration de démarrage (BCD) servi aux clients. Les données BCD par défaut de chaque architecture résident sous RemoteInstall\Boot\<arch>\Default.bcd, <arch> étant l'architecture spécifique du système démarré.

Vous pouvez personnaliser ces données BCD pour chaque client, et le client les utilisera pour démarrer. Vous pouvez, par exemple, configurer une entrée de BCD pour démarrer l'installation, une autre pour exécuter l'environnement WinRE (Windows Recovery Environment) et une autre pour exécuter un test de mémoire ; vous pouvez également configurer une entrée d'installation entièrement automatisée comme défaut et une entrée manuelle (ou expérience d'installation personnalisée) comme option sélectionnable par l'utilisateur. (Pour plus d'informations, consultez l'article « Comment modifier le magasin BCD à l'aide de Bcdedit » à l'adresse go.microsoft.com/fwlink/?LinkId=115267.)

Bien sûr, l'essentiel du travail de WDS intervient dans Windows PE ; par conséquent le réglage de Windows PE pour répondre à vos besoins spécifiques peut être un élément important pour un environnement personnalisé. Par défaut, WDS fournit un modèle d'installation très standard qui inclut l'environnement d'installation complet. Cette solution peut parfois ne pas être adaptée à vos besoins en matière de déploiement. Dans ce cas, vous pouvez créer votre propre image de démarrage Windows PE. Commençons par le début.

En plus d'utiliser les données BCD pour indiquer quelle image utiliser, vous pouvez spécifier cette image en personnalisant l'objet MAO (machine account object) d'un ordinateur dans Active Directory. Dans RIS, un attribut MAO spécifique stockait chaque élément (quels fichiers SIF Startrom et Unattend utiliser). Avec WDS, ils sont stockés en tant que paires nom-valeur sous l'entrée netBootMirrorDataFile. Par exemple, l'image de démarrage et le fichier Unattend qui doit être utilisé par un ordinateur donné sont stockés dans cette entrée. La forme des entrées est une liste de paires nom-valeur délimitée par des points-virgules. Les entrées servant à modifier l'image de démarrage et le fichier Unattend sont BootImage et UnattendFilePath, respectivement.

Bien sûr, vous pouvez choisir d'ignorer l'environnement d'installation existant et de créer le vôtre. Peut-être avez-vous besoin d'une plus grande souplesse de configuration, d'une automation plus poussée ou d'une génération automatisée par SQL Server. Vous souhaiterez peut-être faire ce que certains clients ont fait avec RIS et Windows PE et créer votre propre front-end pour l'installation. Quel que soit l'environnement d'installation que vous écrivez, vous devez réaliser les tâches suivantes :

• Recueillir les informations propres à chaque utilisateur ou à chaque ordinateur. Ces informations peuvent provenir des entrées utilisateurs, de SQL Server ou d'un fichier texte, par exemple.
• Copier et appliquer une image d'installation au système client. Cette tâche peut être accomplie en utilisant directement l'installation, en utilisant ImageX pour appliquer une image d'un partage réseau, ou à l'aide de la multidiffusion (copier tout simplement l'image et l'appliquer via ImageX).
• Fournissez un fichier Unattend (tel qu'Unattend.xml ou sysprep.inf, en fonction de la version Windows déployée) pour terminer l'installation.
• Automatisez toutes les étapes de migration post-installation que vous souhaitez effectuer (ou toute étape d'application de rôles dans le cas de Windows Server 2008).

ADS a lancé le concept de séquence de tâches qui permet d'attribuer des étapes répétables à un ou plusieurs ordinateurs. Étant donné qu'ADS n'était pas destiné à être utilisé avec Windows XP, vous ne pouviez pas l'utiliser pour déployer le système d'exploitation. Toutefois, les séquences de tâches ADS ne sont en fait que des scripts structurés, et vous pouvez effectuer les mêmes étapes en utilisant un processus d'installation personnalisé.

Je suis fan de Microsoft SQL Server depuis longtemps (depuis la sortie de SQL Server 6.5), donc mon instinct est de créer une telle structure en utilisant SQL. Pour cela, il faut bien sûr ajouter les fonctionnalités SQL à votre build de Windows PE. En outre, vous pourriez soit écrire votre propre GUI, application HTML (HTA) ou exécutable compilé, soit utiliser WSH (Windows Script Host) pour exécuter un environnement d'installation minimaliste à ligne de commande uniquement. HTA ou WSH doivent également être ajoutés à Windows PE pour pouvoir être utilisés.

Le degré de complexité de la conception de votre propre environnement d'installation dépend entièrement de vos compétences et de votre imagination. J'ai vu des systèmes tout à fait élégants qui ont été définis uniquement à l'aide de SQL et WSH ou HTA, compétences relativement faciles à acquérir. Il est très important, toutefois, de ne pas oublier les contraintes que j'ai mentionnées dans les articles précédents :

• Windows PE n'est doté d'aucun sous-système Windows on Windows (WOW), si bien que vous devez compiler une fois pour chaque architecture que vous envisagez de prendre en charge.
• Vous ne pouvez pas utiliser Visual Basic 6.0 si vous devez déployer via Windows PE x64 ou IA64.
• Vous pouvez utiliser Visual Studio 2005 ou 2008 pour créer des applications, mais vous devez créer une application Visual C++ non gérée, vu qu'il n'existe aucune version Microsoft .NET Framework prise en charge sur Windows PE.
• En outre, sans .NET Framework, vous ne pouvez pas utiliser Windows PowerShell pour l'automation.

Il va de soi que vous pouvez également utiliser un utilitaire d'imagerie tiers via WDS si vous voulez écrire votre propre environnement d'installation. Le format WIM et ImageX peuvent probablement répondre aux exigences de la plupart des scénarios de déploiement, mais votre outil d'imagerie existant peut lui-même répondre aux exigences de certains d'entre eux.

De même, certains scénarios peuvent nécessiter un partitionnement personnalisé, par exemple si vous déployez Windows Vista avec BitLocker, si vous créez des systèmes Windows XP et stockez les données de profil sur un deuxième volume, ou si vous déployez un système Windows Server et souhaitez créer un volume séparé sur le même disque pour la journalisation. Chacun de ces scénarios nécessite l'automation de DiskPart, qui, comme dans les versions précédentes, peut être effectuée en envoyant à DiskPart un script (n'importe quel format de fichier) contenant les commandes que vous voulez exécuter et se terminant par exit, pour quitter DiskPart.

Il n'est pas facile de créer votre propre environnement d'installation dans la mesure où vous reconstruisez en fait l'exécutable d'installation (ou reflétez au moins ses fonctionnalités) et où la conception et la génération peuvent demander un travail considérable. Cela se résume, toutefois, au nombre de fonctionnalités que vous voulez y intégrer par défaut et à ce que vous y intégrez (HTA ou WSH ou un langage de programmation compilé).

Serveur de transport

Si vous n'utilisez pas la plupart des fonctionnalités de WDS (telles qu'Active Directory) ou si vous construisez votre propre solution personnalisée complète, le serveur de transport peut répondre à vos besoins sans imposer des conditions dont vous ne voulez pas. Le tableau de la figure 2 (reproduite du document « Utilisation du serveur de transport » disponible à l'adresse go.microsoft.com/fwlink/?LinkID=115298) décrit ce qui est inclus dans le cadre du rôle de serveur de transport de WDS.

Figure 2 Serveur de déploiement et serveur de transport

Lorsque je dis que ce serveur de transport est un élément compliqué à implémenter, je ne parle pas du rôle lui-même qui est, bien sûr, facile à déployer (voir figure 3). C'est l'implémentation d'une installation personnalisée autour du serveur de transport qui nécessite beaucoup de travail. L'utilisation du rôle de serveur de transport supprime de fait une grande partie de la convivialité intégrée à WDS en tant que rôle.

Figure 3 Le serveur de transport peut être utile dans les scénarios de déploiement personnalisés (cliquez sur l'image pour l'agrandir)

Multidiffusion personnalisée

Que vous utilisiez ou pas le rôle de serveur de transport, mais surtout si vous l'utilisez, je vous conseille d'utiliser la multidiffusion si vous effectuez un déploiement de plusieurs systèmes. ADS propose une fonctionnalité de multidiffusion très puissante que vous pouvez dupliquer en utilisant WDS avec la multidiffusion. WDS propose la multidiffusion toute seule, mais si vous créez votre propre solution personnalisée, vous pouvez profiter de la multidiffusion en utilisant WDSMCast, comme je l'ai mentionné le mois dernier (voir figure 4). N'oubliez pas que vous devez transférer les fichiers d'image devant être déployés avant de les appliquer. En général, cela signifie que vous avez besoin de suffisamment d'espace disque local pour stocker l'image avant de l'appliquer.

Figure 4 Exécution de WDSMCast (Cliquez sur l'image pour l'agrandir)

Conclusion

WDS est suffisamment puissant, à lui seul, pour répondre aux attentes de nombreuses organisations. Mais si vous souhaitez créer votre propre solution, une solution qui va au-delà des limites de WDS, rien ne vous en empêche. Tout dépend de votre imagination, de votre calendrier et de vos compétences techniques.

Wes Miller est responsable de produit technique pour CoreTrace (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.