Les fichiers du bureauLes coulisses du format Windows Imaging

Wes Miller

Cette rubrique est basée sur des versions préliminaires des outils de déploiement Windows. Toutes les informations contenues dans le présent document peuvent faire l'objet de modifications.

La sortie de Windows Vista se traduit par des changements importants dans la manière dont Windows est installé et déployé. Le moteur d'installation et la série complète d'outils de déploiement pour Windows Vista (ainsi que la version à venir de Windows Server, dont le nom de code est « Longhorn », ont été réécrits. J'ai étudié ces modifications ainsi que le travail fourni par

l'équipe de déploiement Windows® pour les réaliser dans de récents articles de TechNet Magazine. Mais il y a beaucoup à dire à ce sujet ; dans cette nouvelle rubrique qui interviendra de manière régulière, je traiterai donc de Windows PE, de l'installation et du déploiement de Windows ainsi que d'autres sujets relatifs à la gestion et à la sécurité de Windows.

Dans cette première partie, je traiterai du nouveau format Windows Imaging (WIM). Si vous n'êtes pas encore familiarisé avec les détails de la création d'images, n'oubliez pas de lire la barre latérale "Le processus de création d'images type" pour avoir une vue d'ensemble. Ma prochaine rubrique traitera du kit d'installation automatisée (Windows AIK) — une nouvelle série d'outils qui comprend ImageX (l'outil à ligne de commande utilisé pour créer et manipuler les images WIM) et les services de déploiement Windows (WDS), ce qui remplace les services d'installation à distance (RIS) — en étudiant la façon dont ces outils facilitent les déploiements de système d'exploitation.

Le tournant

Année après année, l'équipe de déploiement Windows n'a cessé d'entendre les mêmes commentaires de la part des OEM et des entreprises clientes. Ceux-ci souhaitent une meilleure prise en charge de la création d'images et ils veulent que Microsoft leur fournisse des outils de création d'images unifiés. Ces utilisateurs ne veulent pas se charger du choix d'un fournisseur tiers et ne veulent pas non plus apprendre les subtilités de leur produit. En outre, nous avons par le passé fréquemment eu des plaintes, ces OEM et entreprises clientes estimant qu'ils ne devraient pas avoir à payer les outils de création d'images utilisés pour déployer Windows ; ils veulent au contraire que Microsoft leur fournisse ces outils.

À un stade précoce du développement de Windows Vista™, l'équipe de déploiement Windows a pris un très gros risque. Nous avons décidé d'abandonner complètement l'intégralité du moteur d'installation, dont de nombreux composants existaient depuis près de dix ans. L'installation avait toujours été délicate et comportait bien trop d'étapes. Nous souhaitions accélérer le processus, supprimer les étapes superflues et améliorer la fiabilité de l'installation Windows de façon globale. Pour ce faire, nous devions modifier le processus d'installation dans son intégralité en partant du moteur artisanal que nous avions utilisé pendant un certain temps et le remplacer par un processus d'installation entièrement basé sur les images.

Conception d'un nouveau format de création d'images

À un stade précoce du processus de reconception de l'installation, nous avons décidé de définir le type d'image à utiliser. Le débat classique opposait secteur et fichier. À savoir, fallait-il utiliser un format d'image qui stocke la copie d'un volume sous la forme d'une duplication secteur par secteur ou bien un format d'image qui stocke chaque fichier de façon individuelle ? L'avantage que la plupart des gens espèrent en retirer est la vitesse (avec une approche secteur) ou la compression (avec une approche basée sur les fichiers). Au final, nous avons opté pour un format que j'estime être un très bon compromis entre les deux. Il offre de très bonnes performances, mais permet également une grande compression.

Pour commencer, nous avons défini plusieurs objectifs clé que nous devions atteindre pour générer un format de création d'images qui réponde aux besoins des OEM et des entreprises clientes. Notre liste était fortement orientée vers une architecture basée sur les fichiers. Je pense que nous avons tous vu les avantages de cette approche et par conséquent nous nous sommes, dans un premier temps, lancés sur cette voie. Les fichiers WIM ont alors rapidement vu le jour. (Et au cas où vous vous poseriez la question, le "M" de WIM n'est pas là par hasard. Nous l'avons appelé WIM en nous basant sur les événements de l'équipe Windows qui se répètent lorsque se rapprochent les jalons de publication — et *.WI aurait été une abréviation un peu bizarre). Examinons donc l'ensemble des objectifs que nous avons défini pour le nouveau format d'image.

Neutralité vis à vis du format du système de fichiers Windows Le format d'image devait fonctionner dans les deux architectures de système de fichiers que Windows prend en charge. Bien que presque tous les systèmes utilisent NTFS lors de leur exécution, un grand nombre d'OEM et d'entreprises utilisent les systèmes de fichiers FAT comme palliatif leur permettant d'utiliser MS-DOS® pour déployer Windows. Ils effectuent par la suite la conversion NTFS. Nous devions continuer à prendre en charge ceci pour Windows Vista.

Neutralité vis à vis de la géométrie de volume Nous devions trouver une solution au problème historique qui consiste à capturer un grand volume et à l'appliquer à un plus petit. Même lorsque l'outil de création d'images peut résoudre ce problème via des astuces de manipulation de partition, l'opération n'est pas fiable. Dans une architecture basée sur les fichiers, l'image occupe le même espace que les fichiers qui la composent. Le système de fichiers étant restauré indépendamment, vous ne pouvez pas vous fier à la taille du volume.

Le processus de création d'images type

Lorsqu'un OEM copie un grand nombre de systèmes ou qu'un grand organisme a besoin de déployer Windows sur un grand nombre de machines, ils utilisent en général la technologie de création d'images. Le principe de départ consiste à prendre le système hôte, à le générer exactement comme vous le souhaitez, puis à le dupliquer sur les systèmes cibles. Dans le cas où vous ne seriez pas familiarisé avec le processus de création d'images, en voici une rapide vue d'ensemble.

1. L'administrateur installe Windows sur un système et le configure comme il le souhaite. Cela implique l'ajout ou la suppression de composants, l'installation d'applications couramment utilisées et le réglage de l'interface utilisateur et d'autres paramètres. Appelons ce système le système hôte.
2. L'administrateur exécute alors Sysprep (fourni par Microsoft sous la forme des outils de déploiement Windows), qui effectue la tâche du nettoyage des attributs qui rendent une installation de Windows unique (tels que le nom de l'ordinateur, l'identificateur de sécurité Windows (SID) et d'autres identificateurs uniques sur le système). Ils sont réinitialisés lors de l'exécution de la seconde moitié de Sysprep.
3. L'administrateur éteint ensuite l'ordinateur et le redémarre sous Windows PE, MS-DOS ou sous un autre système d'exploitation lui permettant d'exécuter l'application de création d'images.
4. L'administrateur exécute maintenant l'outil de création d'images, en créant une image du système de référence. Cette image est un fichier (ou un ensemble de fichiers) qui contient une réplique exacte du disque de référence ou de la partition.
5. Le système est éteint et l'administrateur archive l'image, qui peut être mise à jour (par l'ajout d'applications, de correctifs et de service packs) si nécessaire.
6. L'image est dupliquée sur un ou plusieurs ordinateurs et Sysprep finalise son travail, en exécutant une version d'installation abrégée (appelée Mini-installation ou Accueil de Windows, en fonction de la version de Windows sur laquelle vous exécutez Sysprep et de la façon dont Sysprep est configuré). Cette étape est possible grâce à un minuscule exécutable en mode natif appelé setupcl.exe.

Neutralité vis à vis de l'architecture du système L'architecture de l'image devait fonctionner avec toute architecture que Windows était susceptible de prendre en charge. À l'époque, cela revenait à prendre en charge les architectures x86 et IA64 (Intel Itanium), très différentes l'une de l'autre. Aujourd'hui, cela inclut aussi l'architecture x64 (AMD64 et EM64T).

Rapidité de capture et d'application requise L'image devait être capturée de façon relativement rapide, étant donnée la compression. Le point le plus critique étant cependant que l'opération devait être très rapide lors de l'application de l'image.

Prise en charge non-destructive de l'application de l'image Puisque nous remplacions l'option de mise à niveau (qui remplace Windows sans endommager les données ou les applications utilisateur) et que nous élaborions un outil qui pouvait être utilisé pour la récupération système, nous voulions qu'elle soit capable de reproduire l'image d'un système sans détruire tous les éléments déjà présents sur le volume. Sans un travail considérable, les formats basés sur les secteurs ne permettent pas à l'utilisateur de faire cela — en général, vous restaurez tout le volume ou rien du tout.

Prise en charge d'une compression importante Lorsque nous avons commencé à développer Windows Vista, nous pensions encore livrer sur CD-ROM. Compte tenu du fait qu'une image de Windows XP pèse presque 1Go, nous avons décidé qu'il était important de compresser l'image autant que possible. Il est possible d'utiliser certaines astuces avec une image basée sur les secteurs pour faire cela, mais nous étions préoccupés par les composants mobiles d'une telle implémentation. Beaucoup de formats basés sur les secteurs omettent les espaces blancs sur le disque pour économiser de l'espace. (Pourquoi enregistrer un 0 sur une image si ce 0 est constant ?) Cependant, grâce à l'approche basée sur les fichiers, nous avons traité cette question de manière intrinsèque, puisque nous ne captions pas d'espace blanc.

Prise en charge de l'instanciation unique de fichiers Même chose que pour le problème précédent. Windows est bien connu pour stocker plusieurs copies du même fichier dans différents emplacements. L'approche basée sur les fichiers permit de ne stocker qu'une seule instance de chaque fichier et d'utiliser le fichier selon besoin.

Prise en charge de la répartition sur des médias (disques) Même au début de WIM, lorsque nous pouvions faire tenir une image sur un seul CD-ROM, nous savions que nous devions prendre en charge plusieurs médias. Même si nous fournissions Windows sur un CD-ROM, une fois que les utilisateurs avaient ajouté les applications, les service packs, etc., leurs images avaient toutes les chances de dépasser la taille d'un seul CD-ROM ou DVD. Il nous fallait donc les laisser répartir leurs applications sur plusieurs médias pour leur propre installation et solutions de récupération.

Prise en charge de plusieurs images de volume dans un seul blob de fichiers Une image fonctionne rarement pour tout. Lorsque nous avons conçu l'"instanciation unique," nous avons également inclus la capacité de capter plus d'un volume — et la même compression et instanciation unique fonctionne sur chaque volume. Aussi, si vous sélectionnez une image de Windows XP Professionnel et que vous ajoutez une nouvelle image de Windows XP Édition Tablet PC (qui est un sur-ensemble de Windows XP Professionnel), l'image se trouvera augmentée des fichiers qui sont explicitement différents d'une version à l'autre et de ceux-là uniquement.

Par conséquent, un OEM ou un utilisateur d'entreprise peut ajouter plusieurs images dérivées les unes aux autres sans augmentation exponentielle de la taille. Cette capacité n'aurait été pas facilement réalisable avec des formats basés sur les fichiers.

Fonctionnement de WIM

Le format WIM a été conçu pour être le plus simple possible, tout en respectant nos principes généraux. L'approche basée sur les fichiers nous a permis d'y parvenir. Mais comment ceci fonctionne-t-il exactement ?

En résumé, vous pouvez considérer un fichier WIM comme étant un fichier CAB (semblable au format ZIP, mais Microsoft est le concepteur et le détenteur des droits du format CAB). En fait, une fois, j'ai entendu quelqu'un faire référence à WIM comme étant le "fils de CAB." La différence clé entre un fichier WIM et un fichier CAB est que, outre la capture et la compression du fichier lui-même, une image WIM stocke les métadonnées qui concernent les fichiers et répertoires qui constituent le volume capturé dans une image de volume donnée. C'est donc comme une sorte de fichier d'archive comportant toutes les méta-informations nécessaires pour restaurer le volume tel qu'il était lorsque l'image a été créée — listes de contrôle d'accès (ACL), noms de fichier courts/longs, attributs, etc.

Remarquez que les informations de partition (taille ou type) ne sont collectées à aucun moment du processus de capture. De même, le processus d'application ne partitionne pas le système. À la différence de la plupart des outils de création d'images, ImageX, étant neutre vis à vis de la partition, a besoin que la partition soit créée et formatée avant l'application. Afin d'automatiser le processus avant d'appliquer votre image, vous devez utiliser les outils à ligne de commande diskpart et format.

Rien ne limite ce qui peut être stocké dans une image de volume. Une image peut contenir deux volumes, le même volume capturé un mardi et un jeudi, une image comportant un service pack et une n'en comportant pas, ou tout autre élément correspondant à vos besoins. La principale chose à comprendre est que des fichiers identiques ne seront capturés qu'une fois. Moins les images de volume ont de choses en commun, plus elles utiliseront d'espace.

Je dois également signaler que rien dans la conception du format WIM ne l'empêche d'être utilisé avec des versions antérieures de Windows. Il fonctionnera aussi bien avec Windows 2000 qu'avec Windows Vista. Regardons maintenant de plus près ce qui se passe exactement lorsque des images sont capturées et appliquées.

Capture d'une image

Lorsque l'image d'un volume est capturée, les étapes suivantes sont effectuées :

Les métadonnées du volume sont capturées ImageX recueille les données correspondant aux noms de fichiers, aux ACL NTFS et d'autres attributs du système de fichiers du volume. (Vous pouvez choisir d'exclure certains fichiers à l'aide d'un fichier script.)

Les données de fichier sont capturées Le fichier est chargé par ImageX. Chaque fichier est chargé sur le volume et se prépare à collecter certaines des données s'y rapportant.

Le hachage de fichier est généré Un hachage cryptographique du fichier basé sur le fichier lui-même est généré. Ce hachage devient l'identificateur unique des fichiers de l'image.

Les doublons sont recherchés et supprimés Si un autre fichier avec le même hachage existe déjà dans l'image, on considère qu'il s'agit du même fichier et le nouveau fichier est référencé par pointage vers le fichier qui existe déjà.

Les données de fichier uniques sont compressées À la différence d'un CAB ou d'autres formats d'archive, chaque fichier d'un fichier WIM est compressé individuellement, plutôt que comme un ensemble de fichiers regroupés sous la forme d'un seul flux de données. Vous pouvez également choisir de ne pas tout compresser, auquel cas cette étape est sautée.

Les métadonnées du volume sont compressées et stockées Une fois la totalité des fichiers archivée, une entrée de métadonnées pour le volume est créée. Celle-ci répertorie chacun des fichiers qui ont été ajoutés à l'image pour le volume.

Les données de l'image XML sont générées et stockées Il s'agit d'une référence pour chaque image de volume capturée. Si vous exécutez ImageX /info, par exemple, ces données XML sont celles que vous verrez.

L'index des données WIM en mémoire cache est écrit Enfin, l'index principal des données (accompagné des données en mémoire cache) est écrit. Il s'agit de la table de fichiers principale pour la totalité du WIM ; elle comporte une entrée par hachage.

Comme vous pouvez le voir, un WIM est créé, fichier par fichier. En outre, vous disposez d'un fichier WIM, quel que soit le nombre de volumes que vous ajoutez à l'image.

Surcharge d'image

Plusieurs équipes développaient des solutions semblables lorsque nous avons commencé à travailler sur WIM. L'équipe des services automatisés de déploiement développait une solution de création d'images pour un segment de clientèle différent. Leur approche comprenait des détails d'implémentation de bas niveau très intéressants, mais leur moteur de création d'images, comme la plupart des moteurs de cette époque, était basé sur les secteurs. L'équipe Windows XP Embedded avait également généré un moteur de création d'images basé sur les secteurs pour permettre aux fabricants de matériel indépendant intégré (IHV) de déployer leurs propres images lors de la fabrication du système. Et lorsque l'équipe Virtual PC a été acquise par Microsoft en 2003, ils ont apporté avec eux un autre format de fichier pour les fichiers du disque dur virtuel (VHD).

Tous ces formats étaient essentiellement basés sur les secteurs. Ils correspondaient aux besoins de chacun des segments de leur clientèle, mais ces solutions n'auraient pas respecté nos instructions pour WIM. Par conséquent, nous avons poursuivi la construction du nouveau format WIM et de l'outil à ligne de commande ImageX pour la capture des images. En fin de compte, un certain nombre d'autres équipes a adopté notre format bien avant qu'il ne soit publiquement considéré comme faisant partie intégrante de Windows Vista bêta. L'équipe SMS, par exemple, a publié une implémentation anticipée de WIM dans leur Feature pack de déploiement du système d'exploitation.

Application d'une image

Intéressons-nous maintenant au processus de compteur : application d'une image.

Index des données WIM en mémoire cache chargé Cette étape est à mettre en corrélation avec la dernière étape de la procédure précédente. Puisqu'il s'agit de l'index principal, c'est le premier élément à charger à partir du WIM après avoir spécifié quelle image de volume appliquer.

Les métadonnées d'image sont récupérées et chargées ImageX charge les métadonnées propres à chaque image de volume.

La structure de répertoires est créée Afin de s'assurer que chaque fichier a un emplacement où être restauré, l'intégralité de l'arborescence de répertoire du volume est créée.

Les données de fichier sont extraites Les fichiers sont extraits à partir du WIM, suivant exactement le même ordre séquentiel dans lequel ils ont été archivés.

Les données de fichier sont appliquées Dans cette étape, les fichiers sont chargés, décompressés (si l'image de volume a été compressée dans le WIM) et copiés à chaque emplacement référencé. Enfin, toutes les métadonnées de chaque fichier sont appliquées.

Toutes les métadonnées de répertoire sont appliquées C'est important qu'il s'agisse de la dernière étape car il est possible qu'un ACL d'un répertoire empêche l'image d'être appliquée correctement.

Compression souple

L'un de nos objectifs clé avec le format de création d'images WIM était de fournir des options de compression souples. Nous avons donc donné la possibilité de capturer une image de volume avec compression lorsque nécessaire, tout en autorisant également la capture d'image sans compression. Cette dernière option est intéressante pour les scénarios où l'image n'a pas besoin d'être compressée de manière agressive ou lorsque la capture à vitesse élevée est critique.

Il existe quelques principes clé qu'il faut garder présents à l'esprit pour la compression. La compression prend toujours plus de temps que la décompression. Plus l'algorithme de compression est agressif, plus la compression d'un jeu de données défini sera longue. Et plus vous alimentez un algorithme de compression en données et mieux il effectuera la compression.

Les images WIM peuvent être compressées à l'aide de la compression XPress ou LZX — et bien sûr, aucune compression n'est optionnelle. XPress est un bon compromis lorsque vous avez besoin d'effectuer une certaine compression, mais que vous ne souhaitez pas consacrer trop de temps au processus de capture. LZX offre un taux de compression optimal — mais comme vous vous en doutez, cette méthode prend plus de temps.

Ne pas utiliser la compression permet de capturer l'image le plus rapidement, mais avec pour résultat l'image la plus grande. Le type de compression est une option propre au WIM. Une fois qu'une image de volume est capturée dans un WIM, toutes les images de volume suivantes doivent être capturées selon les mêmes paramètres de compression.

Remarquez qu'étant donné que les images WIM compressent fichier par fichier, la compression n'est pas aussi complète qu'elle pourrait l'être. Tout ceci participait d'une décision réfléchie — nous avons procédé de la sorte afin que l'image puisse être modifiée plus facilement. La possibilité de modifier les images après la capture est une option importante. Pour qu'un fichier soit modifié après capture de l'image, les données du fichier et ses métadonnées doivent être remplacées. Si vous aviez compressé l'intégralité du WIM en une seule fois, il eut été pour nous incroyablement compliqué de concevoir la prise en charge des fichiers modifiables (en supposant bien sûr que cela soit possible) et remplacer un fichier dans l'image prendrait un temps considérable. Grâce au compromis que nous avons établi, nous avons obtenu un format qui est correctement compressé et peut encore être modifié à l'aide de nos outils.

J'espère que ces explications vous permettent de bien comprendre la façon dont fonctionnent les capacités de création d'images que nous avons conçues pour Windows Vista. Dans ma prochaine rubrique, je traiterai de certains des outils que vous pouvez utiliser pour gérer et déployer des images WIM images, en m'intéressant de plus près à ImageX et aux services de déploiement Windows.

Wes Miller est responsable du développement chez Pluck (www.pluck.com) à Austin, au Texas. Par le passé, Wes 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. Wes souhaiterait remercier John Macintyre, l'actuel responsable du programme WIM/ImageX chez Microsoft pour sa collaboration à cette rubrique.

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