Histoires de BureauDémarrage réseau de Windows

Wes Miller

Sommaire

Fonctionnement de PXE
Présentation de RIS
WDS—Les origines
Autres intervenants
Conclusion

Au cours des mois qui viennent j'ai l'intention de parler de Windows Deployment Services (WDS), qui est disponible pour Windows Server 2003 et est intégré à Windows Server 2008. WDS peut être un composant essentiel de votre infrastructure de déploiement, donc je veux m'assurer que vous abordez cette discussion sur de bonnes bases. Ce

premier article va explorer l'architecture du protocole PXE (Pre-Boot eXecution Environment), l'historique de Remote Installation Services (RIS), ainsi que d'autres technologies relatives à PXE et utilisées par Microsoft.

Lorsque j'ai intégré le groupe Windows OS en 2001, RIS était l'une des technologies dont j'ai hérité. Un héritage terrifiant en raison de sa complexité et sa dépendance par rapport aux mises en œuvre du BIOS et au matériel. Mais c'était, en supplément de Windows® PE, l'une des technologies que j'ai appréciées le plus dans mon rôle de responsable de programme.

Je me souviens de ma première installation de Windows 3.0, avec toute une série de disquettes de 3,5 pouces. Progressivement, l'installation est devenue plus facile grâce aux CD de démarrage (inclus dans certaines versions de Windows 98). Mais dans tous les cas, l'installation nécessitait un support physique quelconque, ainsi qu'un disque dur local.

Ensuite, une des principales demandes de nos clients était un démarrage complet à partir du réseau, sans disque dur. Certaines versions anciennes de Windows disposaient de cette capacité, mais ne fut jamais le cas pour Windows NT®. Et tandis que les versions actuelles de Windows Server® 2003 et Windows Server 2008 peuvent être démarrées via un initiateur iSCSI, le processus est tout à fait différent dans la mesure où il n'est pas véritablement local, elles impliquent une dépendance continue par rapport à un lecteur de démarrage distant.

Préconfiguration des clients

• Évaluation du processus de préconfiguration du client RIS
• Préparation de l'amélioration de la sécurité du réseau à l'aide de clients préconfigurés
• Préconfiguration des ordinateurs clients
• Installation d'un système d'exploitation distant

À partir de Windows 2000, Microsoft a commencé à développer une technologie qui allait progressivement devenir RIS et qui tiendrait lieu d'installation réseau. L'objectif de RIS était relativement simple : placer une image du système d'exploitation sur le disque local de l'ordinateur cible au moyen de PXE.

Fonctionnement de PXE

La figure 1 représente la séquence de démarrage PXE. Le protocole PXE est relativement simple et a été développé par Intel et d'autres fournisseurs dans le cadre de l'initiative « Wired for Management ». PXE est dérivé du protocole DHCP (Dynamic Host Configuration Protocol), lui-même dérivé de BootP, et est généralement implémenté sur votre carte d'interface réseau (NIC). Pour présenter les choses de façon simple, voici ce qui se produit :

Figure 1 Séquence de démarrage de PXE (cliquer sur l'image pour l'agrandir)

Étape 1 Le BIOS système démarre et détermine la séquence de démarrage.

Étape 2 Si la séquence de démarrage place PXE avant les disques durs, ou les lecteurs flash, ou les CD-ROM, ou si aucun de ces périphériques n'est présent, l'interface UNDI (Universal Network Driver Interface) est chargée à partir du NIC. Le NIC comporte un tout petit pilote de périphérique réseau et le protocole TFTP (Trivial File Transfer Protocol). (Dans certaines implémentations du BIOS, les utilisateurs doivent appuyer sur la touche F12 pour démarrer PXE. Cette fonctionnalité n'est pas standard et le fait d'avoir le choix de la désactiver me paraît intéressant).

Étape 3 Le système commence à créer une diffusion UDP simple, afin de rechercher un serveur DHCP. Il s'agit en fait de première étape de la séquence de démarrage PXE, que l'on appelle Discover (détection). Tenez compte du fait que le protocole est UDP, ce qui signifie que vous devrez très bien connaître vos routeurs et vos commutateurs afin de garantir que les communications PXE puissent transiter sans problèmes.

Étape 4 Si un serveur DHCP reçoit la diffusion, il répond en conséquence avec une adresse IP. Cette étape est appelée Offer (proposition). Ici, il est important de se souvenir que PXE n'a pas d'état et que la quantité d'informations sur l'état propre au système offerte par le client est plutôt limitée (l'adresse MAC et, si disponible, le GUID BIOS de gestion du système, également appelé GUID SMBIOS).

Étape 5 Le client, après avoir reçu le paquet avec l'adresse IP, demande un supplément d'informations, à savoir l'adresse du serveur PXE. Une autre diffusion se produit, qui inclut les informations provenant du serveur DHCP qui a répondu au début. Dans ce cas, le client demande au serveur DHCP « j'ai besoin de plus d'informations, notamment sur l'emplacement d'un programme de démarrage réseau ». Cette étape est appelée Request (demande).

Étape 6 Le serveur PXE répond avec l'adresse du serveur PXE et l'emplacement du programme de démarrage réseau, un tout petit exécutable de démarrage qui doit faire moins de 32 Ko. Cette étape est appelée Acknowledge (accusé de réception). Si vous faites quelques essais, vous allez sans doute voir l'acronyme DORA (Discover, Offer, Request, Acknowledge), qui est une excellente façon de mémoriser la séquence.

Si vous avez installé Microsoft DHCP et WDS (ou utilisé toute autre forme de technologie d'autres fournisseurs), l'étape de requête ne se produit pas et, en fait, le paquet « Offer » d'origine provenant du serveur DHCP inclut déjà l'emplacement du serveur PXE et du programme NBP (en supprimant ainsi deux étapes, et en gagnant ainsi un peu de temps).

Étape 7 Le client, qui dispose de la petite pile de protocole TFTP mentionnée plus haut, télécharge le NBP à partir de l'emplacement réseau spécifié par le serveur PXE. TFTP est un protocole démodé, extrêmement petit et sans état. Il n'a pas été choisi pour sa sécurité ou ses performances et de nombreux administrateurs de routeur le désactivent donc par défaut. Il doit être activé pour que PXE fonctionne.

De nombreuses implémentations PXE (y compris RIS) inclut la possibilité de demander à l'utilisateur d'appuyer sur F12 pour poursuivre à partir de ce point. En général, ceci peut être désactivé par l'administrateur du serveur PXE. Le mois suivant, lors d'une analyse plus approfondie de WDS, j'examinerai les améliorations apportées par Microsoft au TFTPD (TFTP Daemon) dans WDS pour Windows Server 2008 afin d'améliorer les performances.

Étape 8 NBP est initialisé. Dans le cas de RIS, ceci active un chargeur de démarrage Windows qui lance le processus de déploiement. PXE (au moins le véritable protocole au niveau du démarrage) n'est plus un composant du processus.

Il est important de se rappeler que PXE (qu'il s'agisse de RIS, WDS ou toute autre infrastructure) ne fonctionne pas correctement sur les liens lents (il peut avoir à transférer des quantités considérables de données) ou les liens à forte latence, tels que les liens satellites (la communication s'exécute très mal, voire pas du tout).

Vous pouvez constater dans le processus de démarrage PXE que lorsque le client envoie la requête, rien ne pose de question du genre, « Êtes-vous ma mère ? » Il n'y a pas suffisamment d'informations d'état pour que le serveur PXE puisse prendre connaissance de son environnement. Les serveurs se trouvent alors dans une situation compétitive : le premier serveur qui répond à la requête client l'emporte. Deux choses peuvent aider à réduire ce problème :

• Ajustez la vitesse de réponse de l'un des serveurs PXE. La latence du réseau et la puissance du serveur influeront sur le temps de réponse des serveurs. En fait, chez Microsoft, les serveurs utilisés par le service informatique étaient si bons que même si le serveur PXE était dans votre bureau, les serveurs d'entreprise arrivaient à l'emporter. Dans ce cas, vous définissez votre serveur local PXE de façon à ne pas avoir de délai d'expiration du tout pour vos clients préconfigurés.
• Préconfiguration des clients. Ceci est très important si vous manipulez votre serveur PXE pour répondre plus rapidement que les autres serveurs d'entreprise. En préconfigurant vos clients, vous autorisez Active Directory® à dire à WDS ou RIS que oui, en fait, « je suis votre mère ». Notez que l'utilisation du GUID SMBIOS est de loin préférable en tant qu'identificateur unique pour vos systèmes dans Active Directory, mais si un GUID SMBIOS n'est pas implémenté dans les systèmes (plus probablement pour le matériel plus ancien), vous pouvez (et devrez) utiliser un GUID reposant sur l'adresse MAC. Pour plus d'informations, consultez le volet « Préconfiguration des clients ».
• N'autorisez pas les communications PXE à transiter sur les commutateurs ou les routeurs. Mettez un serveur PXE de chaque côté. Ceci a comme inconvénient d'être aussi cher à implémenter qu'à gérer (la maintenance de l'image des serveurs est nécessaire).

Les serveurs RIS (et maintenant WDS), tels que les serveurs DHCP de Microsoft, doivent être authentifiés contre la mise en œuvre d'Active Directory à laquelle ils sont associés. L'objectif est de réduire les problèmes que les serveurs PXE anormaux peuvent causer (comme les orages de diffusion PXE) en permettant à Active Directory de tout savoir sur ces serveurs.

Cette opération permet de se protéger uniquement par rapport aux serveurs connus par Active Directory. Si vous configurez votre propre domaine ou un serveur PXE non Microsoft, cela n'est pas le cas.

Un jour, chez Microsoft, un employé a fait du zèle et a configuré un serveur PXE non RIS, sous forme de déploiement « sans intervention humaine ». Cette mise en œuvre effaçait complètement le disque dur et créait une nouvelle image. Ceci n'aurait pas posé de problème si ce déploiement avait eu lieu dans un laboratoire isolé (hors réseau), mais ce ne fut pas le cas. Il a effacé le disque d'un cadre de Microsoft pour lequel PXE figurait dans la partie supérieure de sa séquence de démarrage, avant le disque dur.

Ceci n'avait causé aucun problème auparavant, dans la mesure où le service informatique de Microsoft demandait toujours d'appuyer sur F12 pour démarrer avec PXE. Mais ce serveur PXE n'avait pas de délai, d'invite F12 ou tout autre type de notification. Par conséquent, ce cadre a perdu son ordinateur et toutes les données non protégées par son profil d'utilisateur itinérant.

Cette histoire est là pour mettre en avant la nécessité d'isoler vos serveurs PXE si vous souhaitez éliminer toute intervention humaine ou n'utiliser que la touche F12.

Approfondissement de RIS

J'ai hérité de RIS après avoir hérité de Windows 2000. Le temps a fait subir ses irréparables outrages à Windows 2000 en ce qui concerne RIS, et les tests, performances et autres contraintes ont fait que RIS pour Windows Server 2000 n'est utilisé que pour le déploiement de Windows 2000 Professionnel. Les produits serveur, malheureusement, ne pouvaient pas être déployés avec RIS. Windows 2000 était uniquement disponible pour les machines x86. Il s'agit donc d'un bon banc d'essai pour RIS, dans la mesure où il s'agissait d'un seul produit sur une seule architecture. RIS incluait (et nécessitait) une intégration complète avec Active Directory, s'intégrait bien avec le serveur DHCP de Microsoft et incluait son propre TFTPD.

RIS utilise le programme de démarrage réseau pour poursuivre le téléchargement TFTP et apporter une proportion suffisante du noyau Windows pour amorcer le processus d'installation. (À un certain stade, seul Windows a basculé de la connexion serveur TFTPD vers un bloc de message serveur ou SMB. Le chemin de code littéral est en fait partagé avec une installation traditionnelle par disquette de Windows 2000 ou Windows XP). Une fois le mode natif de Windows initialisé, l'installation lance l'Assistant sélection du système d'exploitation RIS (OSC).

Les écrans OSC peuvent être configurés en partie, un peu comme des pages en HTML 2.0. Ils sont soumis à des contraintes strictes et ne peuvent pas contenir d'image ou tout autre élément graphique et, en fait, ne peuvent pas contenir de caractères non ANSI (ce qui compliquait le déploiement de certaines versions localisées de Windows).

Le produit final de RIS est un fichier txtsetup.sif qui repose sur le serveur RIS. Lorsque l'Assistant de sélection du système d'exploitation se termine, le client subi un « redémarrage logiciel », mais l'emplacement du serveur RIS et du fichier txtset­up.sif est conservé et rechargé après ce redémarrage. Ce fichier txtsetup.sif est en fait identique à un fichier unattend.txt, avec plusieurs champs supplémentaires inclus pour aider RIS à terminer le processus d'installation.

RIS pourrait également procéder à une installation beaucoup plus proche de l'installation sans assistance traditionnelle (RISetup) et il disposait d'une infrastructure de type clonage semblable à Sysprep (RIPrep) et, en fait, partageait du code avec cette dernière. Mais RIPrep pouvait également charger sa propre image sur un serveur RIS.

RIS comportait des restrictions fondamentales qui sont ensuite devenues apparentes. La première était le manque de prise en charge pour le déploiement du serveur. Certains codes malveillants, tels que Code Red et Sasser, combinés à la complexité informatique que plusieurs clients clés ont pu mesurer en procédant à la restauration directement à partir de la tragédie du 11 septembre 2001, nous a conduit à accélérer une solution pour les serveurs RIS existants de Windows 2000 existants, afin d'autoriser le déploiement de Windows Server. Nous avions déjà travaillé sur la question pour Windows Server 2003 mais n'avions pas publié une version formelle.

Plus de détails sur les technologies de type PXE

• Description des interactions PXE entre le client PXE, DHCP et le serveur RIS
• Planification des déploiements de systèmes d'exploitation initiés par PXE
• Architecture PXE
• Services d'installation à distance
• Installation à distance du système d'exploitation
• Guide détaillé de la désinstallation de système d'exploitation à distance
• Fournisseur PXE WDS
• Qu'est-ce que les services d'installation à distance ?
• Services automatisés de déploiement de Windows Server 2003

Ensuite, RIS ne permettait d'automatiser complètement l'Assistant de sélection du système d'exploitation, qui était activé plus tard avec l'élément <META ACTION="AUTOENTER"> dans Windows Server 2003. Enfin, l'Assistant fonctionnait exclusivement avec des caractères ANSI. Cette faiblesse nous a été reprochée par de nombreux utilisateurs en dehors des États-Unis.

Ainsi, vous ne pouviez pas terminer l'installation de RIS avec un clavier français, par exemple. Adapter de façon sûre les caractères non-ANSI au niveau du BIOS sur les PC du monde entier était extrêmement complexe à concevoir et à appliquer.

Avec la parution de Windows Server 2003, nous avons ajouté la prise en charge formelle de l'architecture Itanium d'Intel et de toutes les variantes de Windows 2000 et Windows Server 2003. Windows Server 2003 est allé encore plus loin en prenant en charge l'architecture x64.

RIS a également bénéficié d'un TFTPD réécrit en grande partie pour améliorer ses performances. Windows Server 2003 prenait en charge le démarrage simultané de 75 clients. Tenez compte du fait que la limite supérieure est atteinte ici au fur et à mesure que le trafic réseau remplit le canal SMB avec le trafic réseau vers les clients.

WDS — Les origines

Lorsque nous avons commencé à travailler sur RIS pour « Longhorn » (le nom de code de ce qui allait devenir Windows Server 2008), il est devenu évident que nous devions prendre du recul. Comme je l'ai mentionné dans mon article précédent, nous avions déjà beaucoup misé sur l'installation avec image (WIM) de Windows PE. Par conséquent, le principe clé de WDS était le déploiement de type image à partir d'une instance démarrée par PXE de Windows PE.

Nous savions également que Windows Server 2003 servirait de plate-forme commune pour le déploiement de Windows Vista® et que nous aurions besoin d'une solution « hors bande » pour le niveau inférieur de WDS. Par conséquent, WDS pouvait s'exécuter sur Windows Server 2003 SP1 et était intégré à Windows Server 2003 SP2.

Dans la mesure où il peut fonctionner en tant que serveur RIS (mode Hérité), serveur hybride (mode Mixte) ou serveur WDS uniquement (mode Natif), WDS permet de migrer vers les déploiements formels de style WDS comme prévu. Des clients m'ont demandé s'il était possible d'installer RIS sur un système Windows Server 2003 SP2. Oui, c'est possible. Vous installez WDS, puis exécutez en mode Hérité. La figure 2 présente les systèmes d'exploitation pris en charge.

Figure 2 Plates-formes prises en charge pour le déploiement

WDS dans Windows Server 2003 SP1 et SP2 a tenté d'amorcer le processus de migration vers WDS. Comme indiqué plus haut, les fonctionnalités clés de WDS qui ont été ajoutées dans Windows Server 2008 avaient pour objectif de prendre en charge un TFTPD révisé et le démarrage EFI (Extensible Firmware Interface), ainsi que, naturellement, le déploiement de type multidiffusion.

Autres intervenants

ADS (Automated Deployment Services) a été créé par une autre équipe Microsoft, avec pour principal objectif la mise à disposition rapide des serveurs. ADS disposait d'une imagerie formelle en fonction du secteur, de son propre agent de démarrage (plus petit que Windows PE, mais pas multifonction), son propre TFTPD et une multidiffusion très avancée. La fonctionnalité créée dans ADS est devenue disponible en partie dans SCCM (System Center Configuration Manager), même si les fonctionnalités ne sont pas totalement identiques.

Windows XP Embedded disposait d'une fonctionnalité de démarrage PXE par l'intermédiaire de son propre TFTPD sur un disque RAM, mais ne pouvait pas être déployé à distance de cette façon. Cette technologie a été conçue pour prendre en charge le démarrage de nombreux systèmes à partir de la même image de disque et en même temps via PXE.

Conclusion

L'essentiel de l'article en quelques lignes. Pour en savoir plus, consultez le volet « Plus de détails sur les technologies de type PXE ». Le mois prochain, je me plongerai dans les principes de base de WDS, suivis par des rubriques sur la fonctionnalité avancée de WDS (multidiffusion et plus) et, enfin, l'utilisation de WDS sans WDS ce qui signifie que je souhaite expliquer comment dépasser l'environnement WDS/installation actuel pour appliquer vos propres techniques de déploiement.

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.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.