Histoires de BureauDéploiement de Windows dans un monde virtuel

Wes Miller

L'informatique virtuelle est partout. Si vous ne l'exploitez pas encore, vous manquez quelque chose. La virtualisation réduit la dépendance matérielle en créant une véritable couche d'abstraction matérielle et en permettant de déplacer un ou plusieurs systèmes invités, tels que Windows Server ou des systèmes d'exploitation clients Windows, ce qui inclut les systèmes hôtes.

La virtualisation est, bien sûr, différente de l'émulation dans la mesure où elle n'imite pas le processeur de l'invité. Il représente simplement les ressources du système hôte de façon à ce que les systèmes invités puissent y accéder. Par conséquent, les systèmes hôtes sont génériques par rapport aux invités. Vous pouvez normalement déplacer un invité virtuel d'un système créé par un OEM vers un système différent, créé par un autre OEM. De manière générale, le matériel de l'hôte est sans importance. Il est cependant essentiel de prendre en compte un certain nombre d'éléments. Par exemple, si vous déplacez un invité d'un matériel avec processeur d'un fabriquant donné, tel qu'AMD, vers un autre, tel qu'Intel, vous risquez d'avoir des problèmes (selon la technologie de virtualisation que vous utilisez). Ceci est dû au fait que la technologie d'informatique virtuelle transmet uniquement des informations de l'hôte vers l'invité et inversement. Elle n'émule pas un processeur spécifique pour l'invité (comme c'est le cas, par exemple, d'une solution Microsoft® Virtual PC s'exécutant sur un Macintosh hérité de type PowerPC).

Toutefois, la virtualisation émule bien les composants matériels clés pour l'invité. Dans la plupart des cas, ceci est limité au réseau, à la vidéo (en général un périphérique très contraint sans GPU émulé avancé) et au stockage de masse. Ceci regroupe toutes les fonctions en présentant un ou plusieurs types de périphériques émulés à l'invité. Si vous avez déjà lu mes articles, vous avez sans doute remarqué qu'il s'agit de la même liste de périphériques que celle qui est traitée par Windows® PE. Dans le domaine de la virtualisation, il s'agit bien des types de périphériques indispensables au bon fonctionnement de Windows. De plus, toute technologie de virtualisation doit émuler un BIOS. Ces technologies pourraient également émuler l'interface EFI (Extensible Firmware Interface), mais l'offre limitée de systèmes d'exploitation EFI rendrait ceci d'un intérêt limité. Toute cette émulation permet aux invités virtuels de démarrer. Le BIOS et chacun des périphériques émulent un périphérique réel et le présentent à des invités. Ceci signifie qu'ils nécessitent les mêmes pilotes (pas nécessairement fournis par Windows) que le véritable périphérique. Il est important de conserver ce concept à l'esprit.

Alors que certaines technologies de virtualisation autorisent également les interfaces de périphériques USB (ou USB 2.0), je ne m'étendrai pas sur ces technologies ici. Hormis ces périphériques USB qui nécessitent des pilotes (imprimantes, cartes réseau sans fil USB, et ainsi de suite) ou une certaine forme de prise en charge DirectX® (généralement absent de la plupart des technologies de virtualisation), vous ne devriez pas avoir grand chose à faire pour les faire fonctionner. N'oubliez pas que la prise en charge des périphériques USB ou de tout autre périphérique non émulé dépend, bien sûr, de la technologie de virtualisation que vous utilisez. Vous devez connaître les limitations du produit de virtualisation avant d'essayer de faire fonctionner de nouveaux périphériques.

Il existe actuellement deux grands fournisseurs de technologie de virtualisation sous Windows : Microsoft et VMware (vmware.com). Il faut également mentionner les nouveaux fournisseurs à l'avenir prometteur, tels que Parallels (parallels.com).

Maintenant que nous avons mieux défini la virtualisation, je vais consacrer le reste de cet article à sa configuration, à l'identification des pièges les plus communs et au déploiement sur les différents ordinateurs de votre environnement.

Déploiement virtuel

Le déploiement des systèmes virtuels n'est pas nécessairement différent de celui des systèmes physiques. Mais comme vous allez le constater, il y a de bonnes raisons de préserver des différences.

Lors des débuts de Windows NT®, le déploiement se faisait sous la forme d'une installation. Vous pouviez créer un script à cet effet, mais vous aviez néanmoins à exécuter tout le processus. Une fois l'installation terminée, le concept de copie de cette image sur plusieurs systèmes, était certes pratique, mais n'était tout simplement pas pris en charge.

Depuis, Microsoft a compris qu'il serait intéressant de prendre en charge les systèmes Windows NT dupliqués sur un disque ou « clonés ». Par conséquent, toute méthode disponible lors du déploiement de systèmes physiques est également disponible pour le déploiement d'un système virtuel. Vous pouvez utiliser : Winnt32 (ou setup.exe dans le cas de Windows Vista® et Windows Server® 2008) ; Windows PE (1. x ou 2. x, selon le client que vous déployez et comme expliqué dans mes articles précédents) ; les services d'installation à distance (RIS) ou les services de déploiement de Windows (WDS) ; ou Sysprep (l'outil de préparation système pour le déploiement introduit avec Windows NT 4.0) et votre technologie de duplication de disques préférée (ImageX, par exemple).

Naturellement, ceci ne peut se faire que la première fois que vous déployez un système d'exploitation spécifique. Ensuite, vous avez la possibilité de le copier simplement. Les méthodes de duplication au niveau du disque, telles que celles que je viens de mentionner, présentent un problème.

Utilisation de Sysprep

Le refus initial de Microsoft concernant la prise en charge de la duplication au niveau du disque dépendait principalement de l'identificateur de sécurité de Windows NT (SID). Heureusement, Sysprep a fourni une solution. Mais examinons tout d'abord le problème qu'il résout. Comme exposé dans support.microsoft.com/kb/314828, le SID consiste en un numéro de révision de structure SID (généralement un identifiant unique global, ou GUID) qui identifie un ordinateur Windows. Cet identifiant est ensuite utilisé en tant que section racine de l'identificateur pour tous les comptes locaux. Les comptes locaux ont leur propre identificateur unique, appelé identificateur relatif (RID). Le RID consiste en un identifiant de compte concaténé à la fin du SID. Par conséquent, la combinaison des deux devient l'identificateur des comptes locaux.

Nous allons voir en quoi il s'agit d'un problème en utilisant le SID d'administrateur S-1-5-21-191058668-193157475-1542849698-500. Ici, S-1- 5 est le descripteur qui définit qu'il s'agit bien d'un SID (le S est omniprésent dans la représentation textuelle d'un SID). 1 et 5 représentent le numéro de révision SID de Windows NT et la valeur d'identificateur d'autorité (ici Windows Security). Le reste correspond au SID en tant que tel, ce qui inclut le numéro 500, qui est le mieux connu étant donné qu'il s'agit du compte administrateur de Windows. Le compte Administrateur créé par défaut (et qui ne peut pas être supprimé) sur toutes les installations Windows a un SID qui se termine par 500. Les comptes utilisateur locaux ajoutés à Windows après l'installation commencent l'itération à partir de 1 000.

PSGetSID, disponible dans Windows Sysinternals (mentionné dans mon article PSTools sur technetmagazine.com/issues/2007/03/DesktopFiles), permet d'énumérer un SID pour un utilisateur donné sur un système ou le SID système. Voir la figure 1 pour la sortie de PSGetSID en relation avec le SID de mon système virtuel et le SID de mon compte utilisateur, 1003.

Figure 1** Sortie de PSGetSID pour un SID de système virtuel et le SID du compte utilisateur 1003 **(Cliquer sur l'image pour l'agrandir)

Dans la mesure où les RID de comptes locaux reposent sur ce SID, le problème qui survient lorsque vous dupliquez le disque d'un système ou copiez simplement une image de machine virtuelle doit être relativement évident. En ne modifiant pas le SID (la tâche principale, mais non exclusive, de Sysprep), vous finissez par obtenir une copie du composant clé qui rend le système Windows unique. Si les systèmes A et B ont le même SID d'administrateur, les utilisateurs de chacun de ces systèmes s'identifient de façon légitime comme étant le même utilisateur. La même chose s'applique à tous les comptes locaux du système B lors de l'authentification sur le système A, et inversement. Pire, ces systèmes auront le même SID lorsqu'ils seront présentés à Active Directory®. Donc, si vous autorisez le système A à s'identifier auprès d'une ressource de domaine, alors que vous le refusez au système B, vous provoquerez une collision. Si vous demandez le refus de B, A sera également refusé.

Ainsi, il est essentiel de régénérer des SID sur les systèmes recourant à Sysprep, surtout dans les scénarios avec systèmes virtuels, car les images système risquent de se propager trop facilement. N'utilisez pas d'outil tiers de modification du SID, limitez-vous à Sysprep. Sysprep est conçu, testé et pris en charge par Microsoft pour la préparation de systèmes à dupliquer, ce qui inclut les systèmes virtuels. Voir la figure 2 pour consulter un exemple de Sysprep avant la modification du SID sur un système. Assurez-vous maintenant que l'option « Ne pas régénérer les identificateurs de sécurité » reste non cochée si l'étape suivante est une étape de préparation à la duplication du système.

Figure 2** L'option "Ne pas régénérer les identificateurs de sécurité" doit rester désactivée lors de la préparation de la duplication. **

En outre, pour mettre à jour l'identifiant du SID, Sysprep modifie également les magasins de données privés détectés en fonction du SID et du nom de l'ordinateur ou pour modifier leur chiffrement de façon à ce qu'il fonctionne avec le nouvel SID. Parmi les exemples possibles, citons le magasin de données Tâches planifiées et les valeurs de la métabase IIS (si IIS est installé).

Sysprep supprime également d'office toute les cartes réseau du système et les données de configuration correspondantes. Dans la mesure où la configuration réseau repose sur la carte réseau de la base de registres et que la relation de cette carte dépend de son identifiant matériel (ce qui, à l'exception des déplacements d'un système virtuel à l'autre, est susceptible de se rompre), Sysprep nettoie ces données généralement abandonnées.

Sysprep nettoie également les informations d'appartenance à Active Directory du système. Par conséquent, il doit supprimer un système du domaine dans le cadre de son processus. Ceci permet de s'assurer que les systèmes qui viennent de recevoir les nouveaux SID peuvent être joints au domaine de façon sûre. Certains utilitaires de changement de SID permettent de modifier le SID d'un ordinateur sans le supprimer du domaine, mais cette opération n'est ni fiable, ni sécurisée. Si vous devez absolument exécuter Sysprep sur un ordinateur qui appartient à un domaine, supprimez-le du domaine avant d'exécuter Sysprep ou exécutez Sysprep, puis laissez-le gérer cette tâche pour vous.

Pour rester sur la même note, si vous virtualisez l'un de vos contrôleurs de domaine (DC), vous devez dupliquer des systèmes qui sont simplement des serveurs autonomes qui n'ont pas encore été promus en tant que contrôleurs de domaine et ne sont pas joints au domaine. À l'exception de Windows Server 2003 Small Business Server Edition, vous ne pouvez pas dupliquer un disque de contrôleur de domaine de manière sécurisée. Pour créer de nouveaux contrôleurs de domaine de façon sécurisée, vous devez créer une image de disque à partir d'un serveur qui est prêt à être joint au domaine et être promu au statut de contrôleur de domaine. Sysprep (sauf dans le cas de l'instance SBS, très spécialisée, qui est une forêt/un serveur unique), ne sait pas comment modifier de manière sécurisée des SID sur un contrôleur de domaine.

Enfin, en supplément de la modification des SID et de la suppression de l'ordinateur du domaine, Sysprep change également le nom de l'ordinateur.

Il peut sembler superflu de procéder aux tâches ci-dessus lors de la création d'une image, voire la copie, de systèmes virtuels. Elles sont cependant essentielles. Surtout si vous utilisez ces systèmes sur un réseau avec d'autres systèmes, physiques ou virtuels, dans un domaine, ou avec une autre copie de ces derniers sur le réseau.

Si vous n'utilisez pas Sysprep lors de la duplication de systèmes virtuels, vous allez être confronté à toute une série de problèmes évidents (Active Directory ou toute autre collision réseau) et de problèmes que vous ne pouvez pas prévoir. Par exemple, vos images virtuelles sont très exposées au piratage dans la mesure où l'accès à l'une ouvre la voie vers toutes les autres.

Pilotes et couches d'abstraction matérielle

J'ai indiqué plus haut que les périphériques virtuels inclus dans une image virtuelle peuvent ne pas disposer de pilotes intégrés pour Windows. Assurez-vous que vous disposez des pilotes requis pour vos périphériques lors du déploiement (ou lors du déploiement des images de disque avec Sysprep) en prévision de la tristement célèbre erreur 0x0000007B de pilote, qui peut se manifester tout aussi facilement lors du déplacement d'une image virtuelle d'un pilote de bus de stockage à l'autre, que lors de l'utilisation d'un matériel physique. La même chose s'applique aux cartes réseau. Alors que la plupart des produits de virtualisation ont cherché à fournir un périphérique virtuel plutôt universel, vous devez toujours disposer d'un pilote supplémentaire pour ce dernier.

La couche d'abstraction matérielle (HAL) ne se laissera pas ignorer non plus. Dans l'idéal, vous devez créer des machines virtuelles qui prennent en charge les processeurs multiples ACPI (advanced configuration and power interface) (voir intel.com/technology/iapc/acpi), si c'est ce que votre technologie de virtualisation prend en charge. La conversion entre plusieurs HAL n'est pas généralement prise en charge (voir support.microsoft.com/kb/309283 pour plus de détails). Cependant, certaines technologies de virtualisation ou, de façon plus importante, de nombreuses technologies de migration, promettent qu'elles peuvent déplacer de manière sécurisée une installation Windows « non-ACPI » vers une installation ACPI, ou inversement. C'est faux, et en plus, l'installation Windows qui en résulte n'est pas prise en charge par Microsoft en cas de problèmes. Les restrictions qui sont abordées sur la page Web de prise en charge que je viens de mentionner s'appliquent également aux systèmes virtualisés. Voir la figure 3 pour consulter un exemple de HAL dans le Gestionnaire de périphériques de l'une de mes machines virtuelles, dans ce cas avec la couche HAL monoprocesseur ACPI. Ne confondez pas ceci avec un processeur unique, qui est interchangeable avec la variante à processeurs multiples.

Figure 3** HAL dans le Gestionnaire de périphériques d'une machine virtuelle **(Cliquer sur l'image pour l'agrandir)

Diverses modifications

Modifiez ce que vous pouvez et acceptez ce que vous ne pouvez pas modifier

Sous l'optique d'une migration de physique vers virtuel et inversement, vous devez conserver à l'esprit les choses qui peuvent et ne peuvent pas changer. Vous pouvez modifier les aspects suivants d'une installation Windows :

• La couche HAL (mais uniquement de monoprocesseur vers processeurs multiples ou inversement, à condition de reprendre la même configuration d'alimentation).
• Les contrôleurs de stockage de masse (c'est difficile, mais la plupart des solutions de migration physique vers virtuel tentent cette opération d'office). La plupart des fournisseurs offrent des solutions de stockage IDE et SCSI. Choisissez avec prudence lors du déploiement, car le déplacement de l'un à l'autre n'est pas très facile. En général, la sélection de SCSI produit un périphérique plus fiable (c'est le cas avec la plupart des fournisseurs de mises en œuvre d'émulation de périphérique SCSI).
• Contrôleur réseau (dans un scénario de migration virtuel vers virtuel, cependant, ceci sera généralement identique au sein des technologies d'un fournisseur).

Vous ne pouvez pas modifier les aspects suivants d'une installation Windows :

• La couche HAL (sauf dans les cas mentionnés plus haut, lorsque la même configuration d'alimentation s'applique). Vous ne devez pas croire qu'une solution qui effectue ces opérations permet d'obtenir une installation Windows stable ou fiable (et encore plus important, elle ne sera pas prise en charge par Microsoft).

Outre la modification du SID et du nom de l'ordinateur, vous devez également modifier certaines valeurs qui peuvent être propres à la technologie d'informatique virtuelle que vous utilisez. Notamment, vous devez modifier l'adresse MAC (l'identifiant unique pour les périphériques réseau). De plus, de nombreuses applications virtuelles disposent de leur propre identifiant unique. La plupart stockent ces informations dans leurs propres fichiers de configuration de l'ordinateur. Il est donc important de savoir comment manipuler ces entrées (et les conserver valides). La plupart des produits de virtualisation qui prennent en charge PXE (Pre-Boot Execution Environment) entrent l'UUID SMBIOS en fonction de leur propre identifiant unique, ce qui rend impératif cette modification (ou laissez le logiciel de virtualisation procéder à cette modification à votre place, si cette opération est prise en charge) lorsque vous le joignez à un domaine. Sinon, la gestion des systèmes client WDS ou RIS peut devenir impossible (en cas de conflit des GUID). La plupart des solutions de virtualisation que j'ai utilisées peuvent subir de graves problèmes réseau en cas de doublons d'adresses MAC. Par conséquent, si vous ne vous contentez pas de déplacer une machine virtuelle, il est crucial de modifier l'adresse MAC si le logiciel de virtualisation ne le fait pas automatiquement.

Les autres composants à conserver à l'esprit lors de la préparation du déploiement d'un système virtuel sont les disques ou les instantanés liés. Selon votre solution de virtualisation, ceux-ci pourraient être également appelés disques différentiels ou recevoir un autre nom. Si vous exécutez Sysprep pour préparer un système et disposez d'instantanés (ou tout autre état réversible) correspondant au système virtuel, ces derniers doivent être détruits pour que l'image reste sûre, fiable et sécurisée lorsqu'elle est dupliquée. Dans le cas d'un instantané ou toute autre technologie « d'annulation des modifications de disque », le rétablissement d'un instantané risquerait de faire revenir le système à un point où plusieurs systèmes provenant de la machine virtuelle d'origine sont en conflit entre eux (voire le système source d'origine s'il est rétabli). Par conséquent, Sysprep doit être exécuté sur tout instantané ou toute relation différentielle de disques.

Optimisation

La plupart des technologies de virtualisation incluent des ajouts de machines virtuelles ou des outils qui permettent d'améliorer les performances et la qualité de l'interaction avec l'invité à partir de l'hôte. Ceci implique généralement un travail d'optimisation des entrées de la souris et du clavier, ainsi que d'autres améliorations de performance, et inclut souvent une interaction copier/coller (ou autre hôte vers invité) améliorée. Installez la version la plus récente de ces outils sur vos systèmes virtuels avant le déploiement.

Vous devez également vous assurer que la mémoire du client est configurée de façon optimale pour le système d'exploitation de l'invité, mais également dans le contexte des hôtes sur lequel il sera déployé. La dernière chose à faire consiste à déployer une image de Windows XP définie pour utiliser 1 Go de RAM sur les systèmes hôtes qui ne disposent pas de beaucoup de RAM.

Tenez également compte des restrictions actuelles de la plupart des technologies virtuelles. Vos utilisateurs veulent savoir comment interagir avec les périphériques reliés au système virtuel et les applications qui pourront ou ne pourront pas fonctionner sur le système d'exploitation invité (la plupart ne prennent pas en charge DirectX 9 ou 10, par exemple, ou prennent en charge des versions antérieures de façon limitée). Les utilisateurs peuvent ne pas savoir ce que cela signifie ou la façon dont cela se manifeste (certaines applications ne traitent pas très bien ce type de défaillance).

Problèmes au niveau de l'hôte

De manière générale, le PC hôte qui exécute la technologie de virtualisation ne posera pas beaucoup de problèmes, que ce dernier repose sur un système d'exploitation complet ou sur un hyperviseur de type 1 qui s'exécute directement sur le matériel. La plupart des technologies de virtualisation sont conçues pour s'assurer que le système d'exploitation invité ne nécessite aucune information (ou alors très peu) sur l'hôte. Vous devez toutefois savoir quels hôtes sont en cours d'utilisation, en cas de problème sur un invité qui est déplacé d'un hôte à l'autre. Vous devez également connaître les limitations du produit du fournisseur de virtualisation sur certaines plates-formes. Vous pourrez probablement passer d'une plate-forme à l'autre, mais vous risquez de perdre ou d'ajouter certaines fonctionnalités des hyperviseurs de type 2 du système d'exploitation (l'application de virtualisation) au cours du processus.

Autres mécanismes de déploiement

Liens relatifs à Sysprep

Les documents suivants vous apporteront une aide précieuse concernant Sysprep :

• Conception d'installations à base d'images avec Sysprep
• Comment utiliser l'outil Sysprep pour automatiser le déploiement de Windows XP
• Comment utiliser l'outil de préparation du système (Sysprep.exe) pour procéder à la duplication de disques
• Utilisation de l'outil de préparation du système sur des ordinateurs différents

Le recours à Sysprep ou à la duplication de disques (voire à la simple exécution de Sysprep et la copie de la machine virtuelle) sont des choix évidents lors du déploiement de systèmes virtuels, mais il y a d'autres possibilités. En fait, que vous procédiez avec des images ou une installation, l'utilisation de Windows PE peut se faire plus facilement avec la technologie de virtualisation qu'avec les machines physiques, dans la mesure où vous manipulez des fichiers ISO et non pas un CD physique. Certaines technologies de virtualisation s'adaptent mal aux DVD. Il est donc important de consulter votre fournisseur de virtualisation pour la prise en charge de ce support. Vous pouvez utiliser winnt32 ou setup.exe (avec Windows Vista ou Windows Server 2008), mais il n'y a pas d'avantages spécifiques. Si vous utilisez d'autres technologies de déploiement Microsoft, telles qu'Automated Deployment Services, votre technologie de virtualisation prend en charge PXE pour amorcer le déploiement à partir du réseau, comme si vous utilisiez RIS ou WDS.

Migration

Enfin, à moins de devoir faire migrer tout un PC, pensez à l'outil USMT (User State Migration Tool). USMT permet de déplacer les paramètres d'un utilisateur d'un client physique vers un nouveau système virtuel facilement. Par conséquent, si vos utilisateurs souhaitent faire migrer leurs anciennes données vers une nouvelle machine virtuelle vous pouvez, par exemple, obtenir facilement les fichiers et les paramètres de Windows XP, les stocker sur une UNC, puis les pousser sur une nouvelle machine virtuelle.

Wes Miller vit à Austin, au Texas. Auparavant, il a travaillé chez Winternals Software à Austin et chez Microsoft en tant que responsable de programme et responsable de produit pour Windows. 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.