Histoires de BureauGuide de l'utilisateur expérimenté de WIM et ImageX

Wes Miller

Cet article se base sur une version préliminaire du Kit d’installation automatisée (Windows AIK) et de Windows Server 2008. Toutes les informations contenues dans cet article sont susceptibles d’être modifiées.

J'ai abordé dans plusieurs de mes articles précédents ImageX et le format Windows Imaging (WIM). À Tech Ed, il y a quelques mois, j'ai entendu les commentaires et les questions de professionnels de l'informatique commençant à utiliser les Services de déploiement Windows (WDS), ImageX et le Kit d’installation automatisée (Windows AIK) et me suis rendu compte

que les utilisateurs avaient besoin de davantage de conseils. J'aimerais donc dans l'article de ce mois-ci me concentrer sur ImageX et le format WIM, et la façon d'en tirer le meilleur parti. Ensemble, ImageX et WIM vous permettent de déployer facilement non seulement Windows Vista® et Windows Server® 2008, mais également Windows® XP, Windows Server 2003 et Windows 2000.

Modifications de Windows AIK

La sortie prochaine de Windows Server 2008 peut vous inciter à vous demander quel sera son impact sur Windows AIK. Microsoft a l'intention de publier une version mise à jour de Windows AIK coïncidant avec le calendrier de sortie de Windows Server 2008. Aucune modification significative n'a été apportée au format WIM (l'outil ImageX et le format restent inchangés) ; WDS pour Windows Server 2003 n'a pas non plus changé. Contrairement à la rumeur, la multidiffusion ne sera pas disponible pour Windows Server 2003 WDS. Seuls les serveurs WDS exécutant Windows Server 2008 bénéficieront de la nouvelle fonctionnalité de déploiement en multidiffusion pour WDS.

Windows PE 2.0 et le programme d'installation de Windows seront modifiés afin de prendre en charge :

  • Le déploiement de Windows Server 2008 et de Windows Vista.
  • Le déploiement multidiffusion avec WDS à partir d'un serveur WDS Windows Server 2008.
  • Le déploiement des versions x64 ainsi que des versions x86 de Windows Vista et de Windows Server 2008 à partir de Windows PE x86.

Tout d'abord, cela signifie que Windows PE 2.0 pourra déployer Windows Server 2008 tout aussi facilement que Windows Vista : les mêmes outils et processus fonctionnent pour l'un comme pour l'autre. Deuxièmement, vous pourrez utiliser le déploiement multidiffusion avec WDS une fois que vos serveurs WDS s'exécuteront sur Windows Server 2008. Enfin, cela signifie que vous aurez la possibilité d'utiliser un disque Windows PE 2.0 x86 et de déployer une image x86 ou x64 de Windows à partir de celui-ci.

J'ai mentionné ce dernier point à Tech•Ed au cours de ma session sur Windows x64. Malheureusement, il y a eu une certaine confusion autour de ceci dans les blogs et dans la communauté technique Windows. Cela ne signifie pas que Microsoft distribuera Windows x64 et Windows x86 sur tous les DVD Windows Vista ou Windows Server 2008. Cela ne signifie pas non plus que vous devez combiner les images Windows x64 et Windows x86 dans un fichier WIM unique (bien que vous puissiez le faire). Cette procédure ne permet en aucun cas de réaliser une économie de stockage grâce à une seule instance, mais elle a toutefois l'avantage de permettre aux images WIM d'être groupées dans un seul fichier.

Cela signifie en fait que les clients d'entreprise et les OEM qui ont passé des années à développer des processus de déploiement basés sur x86 (ainsi que des scripts et des outils personnalisés) pourront maintenant déployer Windows x86 ou x64 depuis WIM à l'aide d'un programme d'installation 32 bits, ce que ces clients d'entreprise demandent depuis l'arrivée de Windows x64 en 2005.

ImageX au quotidien

Utilisation de /mount, /mountrw et /delete

Voici quelques conseils importants pour l'utilisation des commutateurs /mount, /mountrw et /delete avec ImageX :

  • Montez un volume avec /mountrw si vous avez l'intention de le modifier.
  • Montez une image WIM dans un répertoire vide, simplement pour éviter toute confusion avec les fichiers qui sont stockés et pour empêcher ImageX de lancer un message d'avertissement inutile.
  • N'oubliez pas les commutateurs /unmount /commit pour votre image en lecture/écriture si vous voulez enregistrer les modifications que vous avez effectuées. J'ai bien trop souvent effectué des modifications et oublié ensuite de les valider (et les ai par conséquent perdues).
  • La suppression de fichiers avec /mountrw et la suppression d'images de volume avec /delete ne permettent pas de récupérer de l'espace ; elles peuvent en fait utiliser davantage d'espace. Consultez la section de cet article concernant /export pour plus de détails.
  • Vous ne pouvez monter un fichier WIM unique qu'une seule fois pour l'accès en lecture/écriture. Deux utilisateurs ne peuvent pas modifier la même image WIM simultanément et vous ne pouvez pas modifier deux images de volume simultanément.
  • Même en mode de lecture seule (/mount), vous devez limiter le nombre d'images de volume que vous montez simultanément, car le pilote est dépendant de la quantité de mémoire de réserve non paginée disponible sur votre système pour chaque image montée. Cela se traduit par une limite qui peut varier en fonction du système (ou de l'architecture de systèmes). Je recommande de ne pas essayer de monter plus de cinq images simultanément.
  • Les modifications importantes avec /mountrw ne prendront que peu de temps lorsque vous les effectuerez, mais peuvent entraîner une durée de traitement de /commit considérable, car il doit compresser et stocker toutes les données du nouveau fichier.
  • Utilisez /delete et /mountrw avec précaution. Une fois les modifications validées, elles ne peuvent pas être annulées.
  • Vous ne pouvez pas exécuter /delete s'il y a seulement une image de volume dans un fichier WIM (supprimez le fichier WIM entier ou ajoutez à la place une autre image de volume).
  • Pour obtenir rapidement une arborescence des contenus d'une image de volume, utilisez cette commande à la place de /mount :
ImageX /dir <path_to_wim_file> <image index>
  • Si vous modifiez deux fichiers WIM à la fois, n'essayez pas d'exécuter /unmount pour les deux en même temps. Séquencez vos événements /mount et /unmount pour que l'un ne bloque pas l'autre.

ImageX a été conçu tout spécialement pour refléter la façon dont les OEM et les clients d'entreprise indiquent qu'ils utilisent ces outils. La figure 1 présente ce processus.

Figure 1 Utilisation d'ImageX

Figure 1** Utilisation d'ImageX **

Il est à souligner que l'étape 5 est essentielle. En réalité, une image change constamment. Par conséquent, la capture et la modification de l'image se devait d'être aussi rapide et facile que possible.

À cette fin, vous pouvez ajouter une image supplémentaire (en utilisant le commutateur /append) à une image que vous avez déjà créée. Au début, l'équipe de développement pensait que vous souhaiteriez ajouter une référence supplémentaire (version de Windows) à votre image précédente, mais plus j'ai travaillé avec les clients d'entreprise à un stade précoce du développement de Windows Vista, plus j'ai entendu qu'elle était utilisée pour déployer rapidement X, puis recapturer X1 dans lequel les modifications de l'étape 2 avaient été effectuées. Il était ainsi possible de recapturer rapidement l'image puisque seul un nombre réduit de fichiers avait été modifié.

Lorsque l'équipe a compris cela, elle s'est rendu compte qu'il n'était peut-être pas toujours judicieux de conserver l'image originale. Plus loin dans cet article, j'aborderai le commutateur /export qui a été ajouté tout spécialement en raison de ce scénario et de celui qui suit.

Le changement est une constante

Très tôt, l'équipe de développement a décidé que les fichiers WIM devaient être modifiables. Puisqu'ils avaient déjà décidé qu'un format de création d'image basé sur les secteurs ne fonctionnerait pas (voir l'article de décembre 2006 sur technetmagazine.com/issues/2006/12/DesktopFiles pour des explications), ils ont dû créer une solution qui monterait facilement les fichiers de en mode natif en tant que partie du système de fichiers Windows et modifierait les images de volume montées dans le fichier WIM. Ceci impliquait un plus grand nombre d'« éléments mobiles », comme j'aime à les appeler. Le montage d'une image basée sur les secteurs est relativement facile, mais le montage d'un format d'archivage propriétaire tel que WIM a nécessité des outils très spécifiques.

Le format devait bénéficier d'un accès à partir de l'invite de commande, ce qui éliminait les extensions du shell Windows habituellement utilisées pour gérer les fichiers ZIP et CAB de manière native. Malheureusement, ces gestionnaires offrent uniquement à l'Explorateur Windows un accès abstrait à un objet.

Par conséquent, la solution WIM comprend un pilote (wimfltr.sys) et ImageX, qui sert en fait de méthode de chargement du pilote et gère l'interface de montage de l'image WIM. Le pilote sert à ajouter une abstraction au système de fichiers Windows, comme illustré à la figure 2. Lorsque vous exécutez une commande telle que celle-ci, vous indiquez à ImageX de charger le pilote wimfltr.sys et au pilote de superposer la première image de volume (le 1 des commandes utilisées ici) sur le montage de répertoire vide, comme vous pouvez le voir ici :

Figure 2 Montage d'une image de volume WIM

Figure 2** Montage d'une image de volume WIM **(Cliquer sur l'image pour l'agrandir)

ImageX /mount iso\sources\boot.wim 1 mount 
ImageX /mountrw iso\sources\boot.wim 1 mount 

Il s'agit du comportement par défaut dans Windows AIK. Ainsi, lorsque vous explorez ou générez une liste des répertoires dans le répertoire de montage, vous voyez la racine de Volume Image 1 dans boot.wim. Bien sûr, l'utilisation de /mountrw ou /mount déterminera si ce répertoire est en lecture seule ou en lecture/écriture (voir l'encadré « Utilisation de /mount, /mountrw et /delete » pour plus de détails).

La fonctionnalité /mountrw a été conçue au départ pour ajouter facilement des pilotes ou autres fichiers ou contenus pouvant être copiés avec xcopy, définir des fichiers de réponse ou modifier le registre hors connexion d'un fichier WIM monté pour le modifier selon les besoins (voir la figure 3). Elle n'a pas été conçue pour que des applications entières soient ajoutées ou supprimées (puisque les applications installées avec MSI ne peuvent pas être installées hors connexion).

Figure 3 Modification d'un fichier WIM monté

Figure 3** Modification d'un fichier WIM monté **(Cliquer sur l'image pour l'agrandir)

Il est essentiel de comprendre que lorsque vous effectuez des modifications dans le fichier WIM lorsqu'il est monté, vous ne modifiez pas directement le fichier WIM (tout du moins pas tout de suite) ; au lieu de cela, vous modifiez un cache du fichier WIM qui est en fait une fusion de la superposition et des modifications que vous avez effectuées. Comme je le fais remarquer dans l'encadré, ceci m'a déjà coûté cher. Veillez, lorsque vous avez terminé, à utiliser les commutateurs /unmount et /commit car ce n'est qu'une fois ceci effectué que vos modifications seront validées dans le fichier WIM. Si vous ne le faites pas, elles seront complètement perdues.

Lorsque vous enregistrez vos modifications en les validant, vous indiquez au pilote d'effectuer les modifications dans le fichier WIM même. Le pilote ajoute les données de fichiers supplémentaires. (Notez que si vous avez effectué une grande quantité de modifications, cela signifie que le traitement de /commit peut prendre un temps considérable, car ce n'est qu'alors que vous ajoutez les données des fichiers à l'image WIM).

En outre, contrairement à un format de création d'image basé sur les secteurs, vous pourriez avoir modifié un ou plusieurs fichiers dans l'image du volume. Par conséquent, ils ne possèdent plus une instance unique (à moins que ce même fichier ait déjà été enregistré une fois) et cela se traduira par la perte des données du fichier d'origine. Un volume WIM, contrairement à un volume NTFS ou FAT, ne marque pas un fichier comme supprimé. Il n'y fait plus référence mais n'effectue aucun nettoyage. Par conséquent, si vous effectuez des modifications fréquentes avec /mountrw, que vous ajoutez plusieurs images avec /append ou encore utilisez /delete pour supprimer un fichier d'image de volume, cela a pour seul effet de faire oublier les références aux données de fichiers au fichier WIM. Il n'abandonne en aucun cas les données de fichiers connexes.

C'est pourquoi l'équipe de développement a créé le commutateur /export, également connu en quelque sorte comme le « défragmenteur WIM ».

Exportation

Remarques importantes concernant /export

Lorsque /export est utilisé pour créer un nouveau fichier WIM, vous pouvez spécifier le type de compression à utiliser au lieu d'accepter le type de compression par défaut actuellement utilisé. Si vous modifiez le type de compression actuel, l'exportation peut prendre un temps considérable.

Lorsqu'il est utilisé efficacement comme /append (en ajoutant une image de volume à un fichier WIM existant), /export ne vous permet pas de modifier l'attribut /compression du fichier WIM.

Vous pouvez spécifier le commutateur /boot si vous exportez une image de volume Windows PE 2.0 entièrement nouvelle.

Le commutateur /export a été créé en réponse aux deux scénarios précédemment mentionnés et à quelques autres scénarios plus ésotériques découverts par l'équipe. Pour résumer, /export vous permet de prendre une image de volume existante (ou deux, ou trois) et de l'exporter. Cela signifie prendre rapidement les fichiers WIM X et X1 ci-dessus et créer un nouveau fichier WIM avec X seulement, avec X1 seulement, ou avec X1 et Y1, en exportant à partir d'un autre fichier WIM.

Imaginons un scénario dans lequel vous apportez des modifications à X et ajoutez (avec /append) les modifications en tant que X1. Vous décidez que vous voulez supprimer X car vous l'avez remplacé en tant que nouvelle image pour ce trimestre. Vous pouvez utiliser le commutateur /delete et ImageX oubliera l'image X. Cependant, pour économiser de l'espace en éliminant toute information liée à X, vous exécuteriez cette commande :

ImageX /export source.wim 2 destination.wim "New image for Q4CY07"

Ceci exportera la deuxième image de volume vers un nouveau fichier WIM avec le nouveau nom, en éliminant complètement les informations précédentes de Volume Image 1. Vous pouvez également procéder à l'exportation à partir d'images WIM fractionnées si vous voulez les rassembler dans un fichier WIM (comme je le décrirai plus loin dans cette rubrique). Les images fractionnées ne peuvent pas être modifiées à l'aide de /mountrw, ce qui peut être l'une des raisons pour lesquelles vous souhaiteriez les reconstruire. Il est important de noter qu'il n'existe aucune commande /import pour ImageX puisque /export peut soit créer de nouveaux fichiers WIM, soit effectuer des ajouts aux fichiers existants. Consultez l'encadré « Remarques importantes concernant /export » pour plus d'informations sur ce sujet.

C'est également essentiel si vous exécutez peimg /prep : bien que cette commande prépare votre image Windows PE à utiliser, elle ne nettoie rien dans l'image WIM. Dans l'idéal, dans le cadre de votre processus de publication Windows PE, vous devez préparer l'image, puis l'exporter dans un nouveau fichier boot.wim. Notez que le processus de démarrage ne peut rechercher le fichier WIM que dans \sources\boot.wim. Veillez donc à ce qu'il soit correctement nommé et marqué comme image de volume de démarrage.

J'ai mentionné qu'il est probablement souhaitable d'optimiser vos images en exécutant /export avec celles-ci lorsque vous êtes prêt à mettre hors service les anciennes images de volume ou à combiner plusieurs images ensemble. Vous devrez également optimiser vos images si vous avez effectué de nombreuses modifications avec /mountrw ou /delete. Dans le cas contraire, votre fichier WIM continuera à croître au fil du temps (de manière mystérieuse impossible à diagnostiquer). Si vous utilisez /mountrw ou /delete régulièrement, envisagez d'utilisez /export dans votre séquence de travail pour vous assurer que vos images sont entièrement optimisées.

Fractionnement

Très rapidement, un autre problème est survenu : la nécessité probable de fractionner les fichiers WIM sur plusieurs supports amovibles. Nous avions prévu que Windows serait livré sur un ou plusieurs CD (et potentiellement sur DVD, comme ce fut le cas) et avons par conséquent ajouté la prise en charge du fractionnement dans WIM et ImageX.

Comme je l'ai mentionné, une image fractionnée à l'aide de /split est fondamentalement en lecture seule. Vous ne pouvez pas exécuter /capture directement sur une nouvelle image fractionnée, elle ne peut pas être montée à l'aide d'ImageX et ne peut pas être ajoutée à l'aide de /append. Par conséquent, je recommande de fractionner un fichier WIM uniquement après avoir terminé le flux de travail standard et d'être prêt à effectuer la publication. Pour être plus précis, faites toutes vos modifications sur le fichier WIM normal et envisagez le fractionnement dans le cadre du processus de publication de votre scénario de déploiement.

En ce qui concerne l'application de l'image, les images fractionnées peuvent poser une difficulté. Je recommande d'utiliser ImageX au lieu d'un programme d'installation pour l'utilisation d'images fractionnées. Je recommande également d'appliquer les images sur le réseau (pour des performances optimales sans créer d'image du disque à partir duquel vous effectuez l'application) ou de les copier directement sur le lecteur et de les appliquer ensuite (notez que vous serez dépendant du disque, car le disque lit et écrit à partir de/sur lui-même au moment de l'application).

Recherche de la validation

Lorsque vous utilisez ImageX, vous déplacez beaucoup de données, des données très importantes. L'une des questions que j'ai fréquemment entendues à Tech•Ed cette année était « Comment puis-je m'assurer que mes images sont valides » ? Pour tout dire, ce n'est pas enfantin, mais ce n'est pas vraiment difficile non plus.

L'essentiel est de comprendre que WIM est, comme la plupart des formats d'archivage, susceptible d'altération. Le plus souvent, cette altération survient lorsqu'un fichier WIM est transmis sur le réseau. À un state très précoce du développement de Windows Vista, nous avons observé des problèmes spécifiques avec des cartes réseau particulières. Si elles abandonnaient des paquets, le fichier WIM était corrompu et pas toujours d'une manière facile à diagnostiquer. Cette situation reflétait en fait ce qui était arrivé des années auparavant lorsque la taille du fichier driver.cab avait augmenté. Une altération aléatoire similaire était survenue. Généralement, si vous obtenez des rapports d'images incorrectes ou d'échec d'installation, il est souhaitable de vérifier le type de carte réseau utilisé sur les systèmes générant ces rapports. C'est le cas que vous utilisiez ImageX seul ou que vous exécutiez WDS.

Par conséquent, comment voir si une image est bonne ou pas ? Pour commencer, vous pouvez utiliser le commutateur /check. Celui-ci enregistre des vérifications d'intégrité supplémentaires dans le fichier WIM et vérifie, avant l'application, qu'il n'a pas été corrompu. Veillez à exécuter /check au moment de l'application également, ce qui validera l'image (bien qu'un temps plus long soit nécessaire).

En outre, si vous rencontrez des problèmes, ou souhaitez juste être méticuleux, vous pouvez exécuter un utilitaire de hachage pour les fichiers avant la capture et après l'application. Vous pouvez également effectuer une vérification après la capture en montant l'image et en effectuant un nouveau hachage, ce qui n'est pas une mauvaise façon de s'assurer qu'une image a été correctement capturée.

Il est souhaitable de s'assurer que les images sont correctement capturées dès le début. Le commutateur /check et le format lui-même sont conçus comme des points de contrôle, et non comme outils de récupération pour la réparation d'une image incorrectement capturée.

Démarrage et indicateurs

J'ai mentionné auparavant que vous pouvez utiliser /boot pour capturer une image de volume WIM de Windows PE et la démarrer. Considérez ceci comme un secteur d'amorçage sur une image de volume particulière. Il peut uniquement exister sur une image de volume par WIM, et est uniquement valide pour Windows PE 2.0. Notez que vous ne pouvez pas lancer un démarrage WIM de Windows PE 1. x ; ce n'est tout simplement pas possible.

Vous pouvez observer des références aux indicateurs dans les images de volume Windows. Les indicateurs sont uniquement utilisés par le programme d'installation de Windows. Un indicateur 2 sur une image de volume signifie qu'elle contient Windows PE et le programme d'installation. Un indicateur 9 signifie qu'elle contient uniquement Windows PE. Tout autre indicateur ou l'absence d'indicateur signifient que l'image ne peut pas et ne sera pas utilisée par le programme d'installation. Remarquez que vous pouvez définir des indicateurs sur une image après qu'elle a été capturée en utilisant ImageX pour les modifier. Je recommande l'utilisation de Windows AIK (et éventuellement Business Desktop Deployment Solution Accelerator) pour créer votre image de démarrage WIM Windows PE car, pour commencer, les indicateurs seront correctement définis.

Remarque pour les utilisateurs de HTA

On m'a récemment communiqué des problèmes concernant l'exécution de fichiers HTA sur Windows PE 2.0. Il semble malheureusement qu'il y ait un problème avec les fichiers HTA contenant tout script de taille significative. Á la figure 4, observez la capture d'écran de l'exemple de fichier que j'ai créé et notez l'erreur de script (sans aucune information) renvoyée. Ce problème a été signalé par plusieurs clients et j'en ai moi-même fait l'expérience.

Figure 4 Erreur de script HTA

Figure 4** Erreur de script HTA **(Cliquer sur l'image pour l'agrandir)

Heureusement, ce problème est cependant facile à corriger. Pendant la préparation de votre image, ajoutez la prise en charge de XML ainsi que la prise en charge de HTA. La dépendance manquante dans le composant HTA semble être incluse dans le module de complément XML, résolvant ainsi ce problème.

J'aimerais remercier Bruce Green, développeur ImageX, ainsi que Minxiao Zhou et Raja Ganjikunta de l'équipe de test de déploiement de Windows pour leur contribution à cette rubrique.

Wes Miller est responsable du développement chez Pluck (www.pluck.com) à 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.