Histoires de BureauRécupération d'ordinateur avec Windows PE

Wes Miller

Dans les chroniques précédentes, j'ai évoqué le fait que notre vision initiale de Windows PE était d’en faire un environnement de déploiement. Mais comme tout bon produit, Windows PE a évolué bien au-delà de cette vision. Les clients (OEM, au départ) souhaitaient vivement pouvoir créer une solution unique pour la production et la récupération automatique utilisateur ; ainsi plusieurs entreprises ont créé

des solutions Windows® PE qui fonctionnent dans les deux cas.

La plupart des outils de récupération qui existent aujourd’hui reposent sur la mise en miroir du processus de déploiement pour la remise en état d’un système dans un état correct connu. Windows Vista® facilite considérablement la récupération par rapport à Windows XP et propose une prise en charge intégrée de la création d’image (consultez à ce propos l’article de Christine Fok sur les technologies de sauvegarde de Windows Vista dans ce numéro de TechNet Magazine).

Dans la chronique de ce mois-ci, j’expliquerai comment créer votre propre solution de récupération avec Windows PE. Windows PE 2.0 est disponible gratuitement en tant que composant du Kit d’installation automatisée (Windows AIK) pour tous les détenteurs d’une licence Windows. Cette licence s’applique non seulement au déploiement, mais également à l’utilisation de Windows PE pour la récupération et le dépannage.

De toute évidence, vous devrez tenir compte de vos propres personnalisations et mises au point, mais je traiterai ici des points généraux que vous devez connaître, que vous déployiez Windows XP ou Windows Vista. Si vous êtes familier de la capture d’image, vous en saurez déjà beaucoup à ce sujet.

Les composants clés de toute solution de récupération Windows PE sont :

• Windows PE
• Un utilitaire de création d'image
• Un script de liaison (ou une application formelle) pour maintenir le tout

Vous voudrez peut-être aussi inclure la prise en charge SQL et ADSI (Active Directory® Service Interfaces). Avec la connectivité SQL, vous pouvez créer indirectement une solution qui permet à vos systèmes d’avoir une sorte de « nomenclature » qui définit les éléments nécessaires à l’installation. De même, une connexion à Active Directory peut s'avérer pratique pour la gestion des propriétés d'objet de compte par ordinateur (MAO).

Notez que Microsoft n'assure pas le support pour l’inclusion d'ADSI dans Windows PE, mais plusieurs articles en ligne expliquent comment s’y prendre (et lorsque c’est fait correctement, cela fonctionne plutôt bien). Si vous ne souhaitez pas vous lancer dans cette entreprise, vous pouvez ajouter la prise en charge SQL et y incorporer le flux de travail pour votre outil de récupération Windows PE. Si vous avez besoin de propriétés ADSI, vous pouvez configurer sur un système serveur une tâche planifiée pour interroger SQL Server™ puis Active Directory via ADSI (fonctionnant essentiellement en tant qu'intermédiaire d'intercommunication).

Cette solution n'est pas parfaite, et elle nécessite la création de scripts ou autre mécanisme d'automatisation, mais cette conception vous permettra d’interagir avec Active Directory à partir de Windows PE.

Notez que vous pouvez également utiliser l’utilitaire LDIFDE pour lire les informations Active Directory depuis Windows PE (pour plus d’informations, consultez l’article de la Base de connaissances à ce sujet à l’adresse support.microsoft.com/kb/237677). Vous pouvez par exemple utiliser la commande suivante :

ldifde -m -f x:\output.ldf -b <username> <domain netbiosname> <accountPassword> -s 
<DC or domain name> -d "DC=contoso,DC=com" -r "(&(objectclass=<computerclassname>)
(netbuisname=<mycomputername>))" - l "<attributename>"

En entrant cette commande, vous récupérez un attribut à partir de l’objet Ordinateur spécifié dans x:\output.ldf, où le résultat peut ensuite être analysé.

Références SKU, bits et langues

Vous devez prendre en compte les versions, architectures et langues de Windows que vous avez à déployer. Dans une petite entreprise à paramètres régionaux spécifiques, vous ne devez probablement déployer qu'un seul système d’exploitation (Windows XP ou Windows Vista) ou vous utilisez ce qui est déjà installé sur vos nouveaux ordinateurs. Vous déployez probablement peu de systèmes Windows x64 pour l’instant, voire aucun. Et il y a de fortes chances que vous ne deviez prendre en charge qu'une seule langue. Cependant, plus votre entreprise est grande et internationale, plus vous êtes susceptible d'être confronté à diverses architectures, versions et configurations.

Dans une chronique précédente, j'ai expliqué que vous pouvez stocker des images de volume x64 et x86 dans le même fichier Windows Imaging Format (WIM). Cela ne vous fera toutefois pas gagner de place. Si vous créez une solution de récupération et que vous devez tenir compte des deux architectures, il est recommandé de stocker chacune d’elle dans un WIM distinct. De même, si vous assurez le déploiement et le support de Windows XP et Windows Vista, vous ne gagnerez pas de place en stockant les deux systèmes d’exploitation sur la même image. En fait, vous ne gagnerez de la place que si vous incluez de nombreuses instances des mêmes applications (par exemple Microsoft® Office System 2007) dans les deux déploiements. Les fichiers d’application ne doivent alors pas être stockés plusieurs fois, mais même dans ce cas, il est peu probable que cela entraîne des gains de place significatifs.

Méthodes de démarrage de Windows PE

Windows PE 1.6

Démarrage PXE à partir de l’installation à distance

Service (RIS) (sans RAMDisk)

Lecteur de disque dur

Lecteur Flash USB

PXE avec RAMDisk

CD-ROM/DVD avec RAMDisk

Lecteur Flash USB avec RAMDisk

Lecteur de disque dur avec RAMDisk

Windows PE 2.0

PXE avec RAMDisk

CD-ROM/DVD avec RAMDisk

Lecteur Flash USB avec RAMDisk

Lecteur de disque dur avec RAMDisk

Le démarrage PXE à partir des services d'installation à distance est optimal si vous avez besoin du PXE, mais il est important de noter que cette méthode met plus de temps à démarrer et consomme davantage de ressources réseau qu’un RAMDisk avec PXE.

Le lecteur de disque dur utilise une quantité minimale de mémoire mais verrouille le lecteur. Cette méthode est idéale si vous utilisez un scénario de récupération en bascule à double partition.

Le lecteur Flash USB facilite le démarrage. Cependant, que ce soit pour les scénarios avec ou sans RAMDisk, le démarrage UFD (lecteur flash USB) est aléatoire si l’OEM n’a pas vérifié que les systèmes de démarrage peuvent démarrer avec UFD et que ceux-ci ne portent pas le logo Windows Vista Capable (la prise en charge du démarrage UFD est une condition requise du logo). Le démarrage UFD nécessite un lecteur flash hautes performances (pour la lecture et l’écriture), ainsi que la prise en charge du format USB haut débit à partir du contrôleur USB et du BIOS.

Le démarrage RAMDisk (dans toutes ses versions) nécessite davantage de mémoire, mais assure des performances optimales et maintient Windows PE à l’écart en le plaçant dans un RAMDisk en mémoire. Le démarrage RAMDisk de Windows PE 1.6 doit de façon générale uniquement être utilisé sur les systèmes d’au moins 256 Mo de RAM. Windows PE 2.0 (qui est toujours un démarrage WIM avec RAMDisk) doit en général n’être exécuté qu’avec des systèmes disposant d'au moins 384 Mo de RAM.

Notez, cependant, que vous pouvez gagner beaucoup de place en stockant plusieurs SKU d’une version particulière de Windows dans le même WIM. Par exemple, supposons que vous combiniez Windows XP Professionnel à Windows XP Tablet PC Edition ou Windows Vista Édition Entreprise à Windows Vista Édition Intégrale (ces combinaisons occupent l’espace de manière efficace puisque deux SKU de la même version et du même niveau de service pack partagent le même code et les mêmes fichiers).

Pour terminer, la langue entre en jeu. Plus une entreprise est grande, plus le nombre de langues à prendre en compte est important. Avec Windows XP, vous pouvez choisir d’utiliser des versions localisées ou une interface utilisateur multilingue (MUI). Dans les versions de Windows XP entièrement localisées, presque toutes les petites chaînes ont été localisées dans la langue de destination. Dans MUI, en revanche, la langue de base est l’anglais et les modules linguistiques de MUI (et ultérieurement, les packs linguistiques LIP [Language Interface Pack]) ont modifié autant de chaînes de langue que possible. (MUI offrait des résultats satisfaisants dans Windows 2000 et de bien meilleurs résultats dans Windows XP et Windows Server 2003.)

Si votre entreprise utilise MUI, vous obtenez d’assez bons résultats en combinant diverses versions linguistiques dans le même WIM. Ceci s’explique par le fait qu’elles utilisent toutes des binaires anglais à la base. Ce n’est cependant pas le cas pour les versions localisées qui sont antérieures à Windows Vista. Puisque les binaires eux-mêmes sont localisés, le même binaire ne trouvera pas de correspondance entre les langues, ce qui signifie que vous devez stocker presque l’intégralité du système d’exploitation (et toutes les applications localisées) pour chaque langue.

Avec Windows Vista, vous pouvez considérer les versions localisées (localisées en tant qu'élément d’un seul binaire qui contient des ressources) comme obsolètes. Windows Vista utilise des fichiers de ressource .mui pour chaque langue (y compris l’anglais). Pour l'essentiel, l'architecture Windows Vista est dépourvue de langue, presque toutes les informations de langue résidant dans des fichiers MUI. Ainsi le stockage de plusieurs versions linguistiques de Windows Vista dans le même WIM entraînera un gain de place significatif. Le stockage de deux, quatre ou davantage de langues sous un seul WIM n'entraîne pas d'augmentation spectaculaire de la taille de l’image (et vous pouvez modifier ou ajouter des langues par la suite en fonction de vos besoins).

En bref, lorsque vous créez votre solution, vous devez savoir quelles versions de Windows et quelles versions d’autres applications partagent des binaires identiques, permettant ainsi le stockage d'une instance unique des fichiers. Ceci vous aidera à déterminer le nombre de fichiers WIM dont vous avez besoin pour toute l’entreprise.

Scénarios utilisateur

De façon générale, plus une entreprise grandit, plus elle devient complexe. La taille n’est pas la seule responsable, l’introduction de toute une série de variables est également en cause (davantage d’utilisateurs et de divisions, avec des besoins plus spécifiques).

Je me souviens d’une certaine entreprise multinationale qui possédait des dizaines de milliers d’utilisateurs et avait mis en place un processus de déploiement géré à partir d’un seul emplacement, tant au niveau géographique et qu'organisationnel. La personne qui dirigeait cette entreprise soulevait toujours des questions très difficiles. Par exemple, elle s’inquiétait à propos de certains de ses utilisateurs distants situés dans des régions d’Afrique qui n’avaient souvent pas une bonne connexion réseau (en fait, nombre d’entre eux se trouvaient à des centaines de kilomètres d’une ligne téléphonique). Cette personne souhaitait savoir comment ces utilisateurs pourraient récupérer leurs propres systèmes sans être déconnectés pendant des jours et sans devoir parcourir de grandes distances.

Lorsque vous développez un produit (et dans ce sens, vous devriez considérer votre solution de récupération comme un produit) vous devez penser à vos utilisateurs. Pensez aux besoins spécifiques de l’entreprise, mais également aux diverses complexités associées aux différentes catégories d’utilisateurs. Vous devez incorporer des cas d’utilisation, à l'aide de courtes descriptions, pour décrire chaque type d’utilisateur final que vous devez prendre en charge. Ces cas d'utilisation peuvent vous aider à identifier tout utilisateur accidentellement écarté de votre solution de récupération et garantir que vous prenez en compte les besoins de chaque type d’utilisateur.

La bonne version de Windows PE

Une autre décision importante consiste à déterminer quelle version de Windows PE correspond le mieux à vos besoins. Les articles précédents de cette chronique peuvent vous y aider, mais je vais essayer de rendre cette décision plus claire ici. Si l’une des affirmations suivantes est vraie, vous devez utiliser Windows PE 1.6 :

• Vous récupérez uniquement Windows XP (ou Windows Server 2003)
• Vous récupérez des systèmes qui ne sont pas compatibles ACPI (Advanced Configuration and Power Interface)
• Vous récupérez des systèmes qui disposent de moins de 512 Mo de RAM
• Vous récupérez des systèmes qui doivent démarrer en mode PXE (Pre-boot eXecution Environment) avec moins de 256 Mo de RAM

Si l’une des affirmations suivantes est vraie, vous devez utiliser Windows PE 2.0 :

• Vous récupérez uniquement Windows Vista (ou Windows Server 2008)
• Vous récupérez Windows Vista et Windows XP
• Vous utilisez BitLocker™

Notez qu'ImageX (voir la section « Création, mise à jour et stockage ») et la plupart des solutions de création d’image tierces fonctionnent correctement avec les deux versions de Windows PE.

Démarrage de Windows PE

Il faut ensuite tenir compte de la manière dont Windows PE démarrera. Les scénarios utilisateur jouent ici un rôle clé. Est-il réaliste pour vos utilisateurs de transporter des CD-ROM ou des DVD pour la récupération ? Pourront-ils les installer sur un ordinateur portable lorsqu’ils seront en déplacement ? Et comment mettrez-vous ce support de récupération à jour ? Les images de récupération sur support amovible peuvent très rapidement devenir obsolètes.

Le scénario le plus courant auquel j’ai assisté est celui de la partition de disque dur secondaire. Le démarrage PXE constitue une autre solution. Vous pourriez également envisager l’utilisation de lecteurs USB externes ou même de lecteurs Flash USB (UFD) (mais vous devez garder à l'esprit que le matériel en question doit explicitement prendre en charge le démarrage à partir d’un périphérique UFD).

L'encadré « Méthodes de démarrage de Windows PE » décrit les méthodes prises en charge pour démarrer chaque version de Windows PE et propose des considérations importantes sur chaque méthode.

En termes de démarrage de Windows PE, votre objectif doit être de démarrer le processus de récupération tout en remplissant certains critères :

• Interaction utilisateur réduite au maximum
• Nombre d'éléments amovibles (supports ou périphériques) réduit au maximum
• L'ordinateur ne dispose peut-être pas de connexion réseau
• L'ordinateur peut ne pas être capable de démarrer localement (Windows ne démarre pas)

Les administrateurs considèrent souvent que mettre Windows PE (tel quel ou dans un RAMDisk) sur le disque dur n’est pas une solution viable en raison d’inquiétudes quant à une éventuelle défaillance du lecteur. Mais il s’agit en réalité d’une option tout à fait viable étant donné la fiabilité des disques actuels, et que si le lecteur physique connaît effectivement une défaillance, l’utilisateur ne pourra de toute façon pas récupérer lui-même son système.

Je préfère créer une partition secondaire et y stocker l’image de récupération. Je ne crois pas au masquage de la partition (cela ne fait que mystifier les utilisateurs). L’utilisation d’une liste de contrôle d’accès (ACL) par-dessus n’est pas viable non plus (à moins que vos utilisateurs ne soient pas des administrateurs locaux.

En réduisant la partition utilisée pour Windows (voir l'encadré « Création d'une partition de récupération »), vous pourrez peut-être libérer suffisamment de place pour enregistrer Windows PE et votre image de récupération. Pour placer Windows PE sur la partition secondaire, il vous suffit de créer le secteur d’amorçage approprié sur la partition de récupération et de placer Windows PE sur cette partition (les documents inclus dans Windows AIK et les versions précédentes de Windows PE expliquent ce processus, donc je ne m’étendrai pas ici). Il convient toutefois de se rappeler que la partition utilisée pour le démarrage est fonction de la partition marquée comme active. Diskpart possède un indicateur actif et un indicateur inactif tout aussi important. Pour démarrer la partition de récupération depuis Windows (ou depuis une copie de Windows PE), utilisez diskpart pour basculer entre les partitions actives (voir la figure 1). Vous trouverez ci-dessous un exemple de script diskpart (utilisez diskpart /s nameofscript.txt) utilisé pour basculer un système à deux partitions sur disque unique :

SEL DIS 0 
SEL PAR 1 
INACTIVE
SEL PAR 2
ACTIVE
EXIT 

Figure 1** Diskpart modifiant la partition active **(Cliquer sur l'image pour l'agrandir)

Il s'agit du processus que de nombreux outils de récupération grand public utilisent pour basculer les partitions (ce qui peut uniquement être effectué depuis Windows PE pour certains types de partitions, tels que les partitions OEM masquées). Parfois ces outils démasquent également un type de partition OEM masquée.

Création, mise à jour et stockage

Création d'une partition de récupération

Le processus de création d'une partition de récupération sans modification de Windows est simple, une fois que vous connaissez les étapes que cela implique. Voici une description rapide de ce que vous devez faire. Notez que ce processus nécessite Windows PE 2.0. Vous n’utilisez peut-être pas Windows PE 2.0 pour le déploiement ou la récupération, mais vous devez utiliser la version 2.0 pour cette tâche. Ce processus peut également être utilisé lors du déploiement de Windows Vista et pour créer une partition de démarrage à utiliser pour les fichiers de démarrage BitLocker, puisque BitLocker nécessite au moins deux partitions (une pour les fichiers de démarrage et l’autre pour le reste du système Windows).

1. Défragmentez votre disque (ceci peut contribuer à accélérer le processus de réduction, qui prend énormément de temps)
2. Démarrez sur Windows PE 2.0
3. Exécutez diskpart (si vous le souhaitez, vous pouvez créer un script pour les étapes 4 à 9 et transmettre à diskpart l’argument suivant : /s nom_de_votre_script
4. SEL VOL 1 (ou le volume que vous voulez réduire)
5. SHRINK DESIRED=N MIN=N (indiqué en mégaoctets, DESIRED est l’objectif et MIN est le minimum absolu dont vous avez besoin)
6. Lorsque la réduction est terminée, exécutez SEL DIS 0
7. CRE PAR PRI (vous pouvez spécifier SIZE=N si vous voulez indiquer une autre taille que celle du reste de disque)
8. ASSIGN LETTER=N: (cette lettre est uniquement utilisée dans Windows PE)
9. Quittez diskpart
10. FORMAT N: /Q /Y /FS:NTFS (NTFS formate la nouvelle partition)
11. Exécutez bootsect N: /nt60 pour 2.0, /nt52 pour 1.x)
12. Copiez les fichiers Windows PE souhaités sur la partition de récupération
13. Arrêtez le système

ImageX est une solution disponible gratuitement, mais vous utilisez peut-être déjà un autre outil de création d’image depuis longtemps. Vous pouvez utiliser l’outil avec lequel vous êtes le plus à l’aise. Si vous envisagez d'utiliser ImageX, il y a plusieurs choses qui valent la peine d’être notées que j’apprécie beaucoup (outre son prix). En particulier, ImageX est agressif en termes de compression. Autre aspect attrayant : il est relativement facile d’ajouter des éléments à une image et de la modifier.

J’apprécie également le fait qu'ImageX permet de mettre en image un ou plusieurs volumes de façon non-destructive, ce qui vous permet de conserver les données utilisateur simplement en les déplaçant. En d’autres termes, lorsque vous récupérez Windows, vous n’avez pas à effacer le volume tout entier.

Ensuite, bien sûr, vous devez décider où stocker l’image. En supposant que votre solution utilise une partition de récupération, vous pouvez y stocker un fichier WIM ou un autre fichier de création d’image. Vous pouvez même envisager d'utiliser des Services de déploiement Windows (WDS), de créer une image de système d’exploitation standard et de la stocker sur le réseau. Ceci permet de jouir d'une solution de récupération commune disponible dans l’ensemble de votre infrastructure. Bien sûr, si vous avez des utilisateurs sur le terrain (tels que les employés cités plus haut qui travaillent dans des parties reculées du monde), vous devrez veiller à ce qu’ils aient leur propre solution disponible lorsqu’ils ne peuvent pas se connecter au réseau.

J’ai mentionné plus haut la possibilité d’utiliser des supports, tels que les DVD, mais je ne suis personnellement pas favorable à cette solution pour une utilisation générale pour différentes raisons. Par exemple, la taille d’une image peut rapidement augmenter et dépasser celle d’un DVD, et ce genre de disque peut difficilement être mis à jour. Cela ne veut pas dire que les supports optiques n’ont pas leur place ; vous devez simplement tenir compte du meilleur scénario pour un type donné d’utilisateurs. Ma préférence, si vous ne l’avez pas encore deviné, va au stockage de l’image sur une partition de récupération, un disque dur USB ou un lecteur flash, ou, lorsque c’est faisable, sur le réseau à l’aide de WDS.

WDS est une option attrayante du fait qu’une image centralisée peut facilement être mise à jour. Vous savez certainement que des mises à jour de Windows sont publiées tous les mois et que ces mises à jour sont généralement critiques. Planifiez votre solution de sorte que l’image de récupération soit la plus à jour possible. Avec WDS, vous pouvez mettre l’image à jour sur chaque serveur et l’image est complète.

Inquiétudes sur les données utilisateur et les paramètres

Lorsque vous planifiez une solution de récupération, vous devez garder certains problèmes à l’esprit. L'un des aspects essentiels de la planification d'une solution de récupération consiste à garantir que les données utilisateur sont également sécurisées. Il faut éviter qu’un utilisateur sur le terrain exécutant une récupération découvre qu’il a perdu toutes ses données importantes au cours de celle-ci. Dans l’idéal, il est préférable de stocker les données utilisateur ailleurs que sur la partition C: à moins de faire très attention à la façon dont la récupération du système est gérée.

J’ai mentionné plus haut qu’ImageX vous permet de restaurer un disque de manière non destructive. Il déplace par exemple l’arborescence du répertoire Documents and Settings (ou Users) vers un autre répertoire pour qu’un utilisateur ou un script puissent récupérer manuellement les fichiers une fois la récupération terminée. Les utilisateurs qui stockent tous leurs fichiers sous leur profil ou qui utilisent des profils itinérants doivent, dans la plupart des cas, pouvoir récupérer un système sans perdre de données utilisateur. Mais il est important de se rappeler qu’à moins de concevoir soigneusement votre solution de récupération ou d’avoir une solution de sauvegarde parfaite, vous pouvez encore perdre une certaine quantité de données utilisateur.

Souvenez-vous que malgré toute votre planification, certains utilisateurs stockeront des informations à d’autres endroits que dans leur profil. Vous devez vous assurer que votre solution tient compte du fait qu’elle écrasera peut-être des données utilisateur par accident et avertir les utilisateurs avant de le faire.

Si vous utilisez le système de fichiers EFS, assurez-vous que votre plan de récupération principal est exécuté (pour éviter de perdre des données en raison d’un chiffrement irrécupérable). De même, si vous utilisez BitLocker, soyez prêt à récupérer les volumes qui ont été chiffrés avec lui. Ceci implique l’utilisation de Windows PE 2.0 (1.x ne peut pas interagir avec BitLocker). Pour plus d’informations sur la récupération BitLocker, consultez le blog à l'adresse blogs.msdn.com/si_team.

Enfin, préparez-vous au fait que certains utilisateurs seront contrariés lorsqu’une partie de leurs personnalisations ou applications auront disparu. Les personnalisations (pour les applications et Windows lui-même) sont stockées à certains endroits aléatoires, et pas uniquement dans le profil utilisateur. En restaurant l’intégralité de la partition du système d’exploitation, certains utilisateurs demanderont « où est passé x ? » ou « pourquoi est-ce que Word n’affiche plus y ? ». Préparez les utilisateurs afin qu’ils sachent que l’environnement ne sera peut-être pas exactement identique à celui de la veille.

La création de votre propre solution de récupération avec Windows PE prend du temps, et vous devez penser à vos utilisateurs lorsque vous planifiez et organisez la solution. Une solution de récupération ne doit pas nécessairement être très complexe, elle doit simplement permettre à votre utilisateur de pouvoir redevenir opérationnel en un minimum de temps et avec un minimum de support technique.

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.