I. Présentation
L’idée de cet article consiste à rassembler l’ensemble des informations utiles pour une exploitation maîtrisée et efficace de l’environnement WinPE. Pour les rares lecteurs qui ne le sauraient pas encore, “Windows Pre-execution Environment“, alias “WinPE“, est un système autonome basé sur un noyau Windows minimaliste destiné aux opérations d’installation, de déploiement et de maintenance. La notion de client “LiteTouch” que nous allons régulièrement évoquer est en fait une version adaptée de WinPE pour un usage avec la solution de déploiement gratuite “Microsoft Deployment Toolkit“, plus connue sous le nom de “MDT“.
II. Les grandes lignes
A. Où peut-on trouver WinPE ?
J’aurais tendance à vous dire “pratiquement partout”, dès lors que vous avez procédé à une installation de Windows depuis Vista. Il est gratuit et ouvert à de nombreuses personnalisations sous réserve de ne pas le détourner de son usage de maintenance. Vous pouvez donc trouver WinPE :
- Sur un DVD d’installation de génération Windows NT6 (Y compris les versions d’évaluation)
- Le générer à partir d’un kit WAIK ou ADK
- Le générer à partir de MDT afin d’obtenir un client LiteTouch et/ou WinPE générique
B. Ouvrir l’invite de commande WinPE
Nous reviendrons plus en détail sur cette notion, mais sachez que sous WinPE, il est pratiquement toujours possible d’ouvrir une invite de commande en cas de besoin. Il y a toutefois une petite nuance en fonction de l’image utilisée :
- Démarrage à partir d’un DVD ou d’un noyau générique
Utilisez [Maj] + [F10]
- Démarrage à partir d’un client LiteTouch
Utilisez [F8] (Depuis MDT2012, cette faculté peut être inhibée)
C. Les versions
Les versions de WinPE ne sont pas vraiment évidentes à définir, surtout lorsque certains articles de Microsoft s’emmêlent les pinceaux : C’est pourquoi je préfère m’appuyer sur la version des noyaux système. Voici un tableau de synthèse, certes perfectible, qui résume la situation constatée selon la valeur du registre (depuis WinPE 3) :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinPE.
Depuis la génération NT6, le “x” correspond au numéro du “service pack” :
| Systèmes d’exploitation |
Versions Noyaux |
WinPE |
Origine |
| Windows 2000 / Windows XP / Windows Server 2003 |
NT 5.0 / 5.1 / 5.2 |
WinPE 1.x ? |
SA |
| Windows Vista / Windows Server 2008 |
NT 6.0.600x |
WinPE 2.x ? |
WAIK 1.0 |
| Windows 7 / Windows Server 2008 R2 |
NT 6.1.760x |
WinPE 3.x |
WAIK 2.0 |
| Windows 8.0 / Windows Server 2012 |
NT 6.2.920x |
WinPE 4.0 |
ADK 8.0 |
| Windows 8.1 / Windows Server 2012 |
NT 6.3.960x |
WinPE 5.0 |
ADK 8.1 |
| Windows 10 |
NT 6.4?? |
WinPE 10 |
ADK 10 |
Plus d’info sur : What’s New in Windows PE
III. Utiliser WinPE
A. Commandes utiles
Voici une liste non exhaustive des commandes pouvant vous être utiles dans cet environnement minimaliste. Avant toute chose, je vous précise quelques points de détail qui pourraient s’avérer importants pour la suite :
- Sous WinPE, il n’y a aucune notion de session, d’où la nécessité de stipuler des identifiants pour des connexions réseau par exemple.
- Sous WinPE, il n’y a pas de bureau, ni d’explorateur, ni de console d’administration. Vous disposez toutefois de quelques outils graphiques tels que regedit, notepad, intl.cpl…
- Sous WinPE, il n’y a pas de sous-système (“WindowsOnWindows“), ce qui implique que les binaires exécutés doivent correspondre à l’architecture du noyau utilisé 32 ou 64 bits.
- Certaines commandes, telles que WMIC, Setup, PowerShell… nécessitent que les composants (features) correspondants soient activés dans le noyau concerné.
J’espère donc que vous n’êtes pas trop allergique à la ligne de commande… 
| Commande |
Utilité |
| VER |
Permet de connaître la version du système et d’en déduire la version WinPE (cf tableau) |
| SET PROC |
Affiche l’architecture CPU (x86 | amd64) – Rappel, les binaires 32 bits ne fonctionnent pas sur un WinPEx64 |
| Mountvol |
Permet d’afficher les points de montage, donc les lecteurs disponibles |
| Diskpart |
Permet de gérer les disques et partitions |
| WMIC LOGICALDISK GET Name, Description |
Permet d’énumérer les lecteurs et leur type |
| WMIC BIOS GET VERSIONWMIC CSPRODUCT GET UUID |
Collecter des infos sur le matériel tel que la version du BIOS ou le numéro de série de la carte mère. |
| Ipconfig /all |
Pour connaitre l’adresse IP, l’adresse MAC et le reste J |
| Drvload |
Bien pratique pour charger / tester un pilote. Il faudra toutefois les sources au format .inf (via une clé USB) |
| Startnet.cmd WpeinitWpeutil InitializeNetwork |
Réinitialise les couches réseaux, à utiliser typiquement après un ajout de pilote ou un problème de connectivité. |
| Wpeutil shutdown | reboot |
Outil spécial WinPE, avec plein d’options bien pratiques telles qu’un arrêt ou un redémarrage |
| wpeutil SetKeyboardLayout 040C:0000040C |
Définir le clavier AZERTY Français |
| wpeutil DisableFirewall |
Permet de désactiver le pare-feu – Utile si vous utilisez un outil de prise de main à distance. |
| netsh |
Réservé aux experts, mais pleinement fonctionnel |
| NET USE Z: \\MDT\Tools /USER:Demo Pa$$w0rd |
Rappel, il n’y a pas de session sous WinPE, il faut donc indiquer le nom et mot de passe pour établir la connexion |
| Sources\Setup.exe |
Si vous être sur un DVD d’installation original, cette commande permet de relancer l’installation |
| Sources\Setup /unattend:z:\autounattend.xml |
permet également de stipuler / tester un fichier de réponse ponctuellement |
| Sources\Setup /wds /wdsdiscover /wdsserver:WDS.labs.local |
Ou bien de « Raccrocher » un serveur WDS en l’absence de démarrage natif sous PXE |
| WDSCapture |
Permet de démarrer la capture d’un système “préparé” via “sysprep” afin d’en générer une image WIM (localement , puis export éventuel vers un serveur WDS) |
| Sources\Recovery\Recenv.exe |
Permet de démarrer l’outil de réparation de Windows, alias “WinRE” |
| Imagex | DISM |
Manipulation des images au format .WIM |
| Powershell.exe |
On ne le présente plus. Il s’agit toutefois d’un composant optionnel disponible au sein des noyaux WinPE 4 et + |
B. Exemple d’outils complémentaires
Comme indiqué précédemment, l’ajout d’outils au sein de WinPE peut vous être utile, surtout lorsque la ligne de commande vous rebute un peu. Voici donc quelques outils que je trouve personnellement bien pratiques, mais là encore, la liste est loin d’être achevée.
| Commande |
Utilité |
32 bits |
64 bits |
| Explorer++ |
Explorateur graphique de dossier et fichiers. Il en existe d’autres tels que A43, ou Q-Dir, mais ils ne sont pas tous disponibles pour les 2 architectures |
Oui |
Oui |
| 7-Zip |
Gestionnaire d’archives. Disponible en version 32 et 64 bits. |
Oui |
Oui |
| GImageX |
Alternative graphique à l’outil en ligne de “imagex”(Note : 7-Zip est en mesure d’explorer les .WIM) |
Oui |
Oui |
Diskpart  |
Présent par défaut : Je n’ai pas d’équivalent graphique et gratuit à vous proposer… hormis l’outil PowerShell http://www.alexcomputerbubble.com/category/diskpart/ En dépannage vous pouvez utiliser les premiers écrans du programme d’installation “\Sources\Setup.exe”, adaptés au partitionnement et formatage des disques |
|
|
| |
Au besoin, recherchez les applications gratuites dites “portables” (sans installation) puis testez-les dans cet environnement. N’oubliez pas de rester dans un cadre de maintenance |
|
|
IV. WinPE en profondeur
Pour les plus curieux d’entre-vous, je propose de pousser cette étude un peu plus loin afin de découvrir quelques aspects intrinsèques de WinPE.
A. Le processus d’amorçage de WinPE
Sans trop entrer dans les détails, il convient de préciser que le processus d’amorçage de WinPE est sensiblement différent en fonction du média utilisé au démarrage.
Parmi ces médias, on trouve :
- Le réseau PXE (Pour Microsoft, ce service est offert au travers de WDS) – Le processus particulier d’amorçage ou bootstrap, n’est pas détaillé ici.
- Le disque dur ou la clé USB exploitent le secteur d’amorçage principal (MBR) à partir d’une partition principale active, sauf en cas d’UEFI ou le mécanisme est sensiblement différent.
- Le support CD ou DVD contient une amorce spécifique de type “el-torito” – La présence du fichier “\boot\bootfix.bin” engendre un message de confirmation
Le chargement du noyau est initialisé par le programme “Bootmgr” à partir des informations contenues dans le magasin d’amorçage “\boot\BCD”
Note : Comparativement aux versions antérieures de Windows NT, on peut approximativement considérer que “Bootmgr” correspond à “NTLDR” et “BCD” est équivalent à “boot.ini“
Schéma du processus d’amorçage
B. Structure de WinPE
La structure d’un noyau WinPE et plus globalement des éléments qui l’entourent est particulièrement complexe et un néophyte peut rapidement y perdre son latin. Afin de se repérer plus facilement, entre les composants, les pilotes de périphériques, les commandes internes et l’outillage de fabrication, j’ai imaginé le schéma suivant :
Explications :
Au centre de l’illustration, on trouve le noyau à proprement parler, alias “boot.wim“. C’est le système Windows chargé en mémoire et portant toujours la lettre “X:”. Pour visualiser ou modifier un contenu de noyau, il faut effectuer un montage via la commande DISM /Mount-WIM …
A l’intérieur du noyau, on peut principalement distinguer un nombre variable de pilotes (Drivers) et de fonctionnalités (Features), ainsi que des packages linguistiques. Vous pouvez en obtenir la liste via la commande DISM /Get-… La plupart des fonctionnalités sont déjà intégrées au sein des distributions originales Microsoft, mais vous les trouverez aussi dans les kits de déploiement WAIK ou ADK pour un ajout à la demande.
Ensuite, pour qu’un noyau “boot.wim” soit exploitable, il faut le déposer sur un média et lui associer un chargeur “bootmgr” ainsi qu’une configuration d’amorçage définit dans le fichier “\Boot\BCD“. L’outil de gestion par excellence est “BCDEDIT“, mais pour régénérer simplement une amorce de base, je vous conseille l’outil “BCDBOOT“. Ces 2 outils sont présents par défaut sur tous les systèmes Windows NT6.x
L’utilisation d’un média de type CD/DVD nécessite l’ajout d’une amorce particulière dénommée “El-Torito” et définie dans le fichier “ETFSBOOT.com“. Pour associer cette amorce et générer l’image .ISO, il suffit d’utiliser l’outil “OSCDIMG” fournit dans les kits de déploiement WAIK ou ADK.
C. Lancements automatiques “Autorun”
Lors du chargement d’un noyau WinPE, il est particulièrement intéressant de remarquer qu’il existe plusieurs points d’entrée permettant d’exécuter automatiquement des commandes, des scripts ou tout autre type de programme.
En analysant le processus d’amorçage d’un noyau WinPE, (ie “\Sources\boot.wim“) on peut constater que l’enchaînement dépend en fait de la présence des certains fichiers :
| Fichier |
Utilité |
| X:\Setup.exe |
Programme “d’accueil” typiquement présent sur une distribution originale, telle qu’un DVD Windows 7. Si ce programme (ou tout autre portant ce nom) est présent au niveau de la racine X:\, il est exécuté. |
| X:\Windows\System32\winpeshl.ini |
Désigne un programme [LaunchApp] ou une liste de programmes [LaunchApps] à exécuter.Ajoutez “wpeinit” ou “wpeutil InitializeNetwork” si vos programmes requièrent les couches réseauCf Exemples ci-après |
| X:\Windows\System32\startnet.cmd |
Batch par défaut, chargé d’initialiser les couches réseau. Par défaut, ce fichier contient uniquement la commande “wpeinit“ |
| X:\Unattend.xml |
Fichier d’initialisation du noyau WinPE – Si ce fichier est présent au niveau de la racine X:\, les différentes directives qu’il contient sont interprétées lors de l’exécution de “wpeinit” – Les blocs “RunSynchronousCommand” décrivent les commandes à exécuter séquentiellement. Typiquement présent sur les clients LiteTouch. |
| X:\Windows\System32\BDDRun.exe |
Programme de lancement spécifique aux clients LiteTouch. Exécuté avec l’option /BootStrap, ce programme résident a principalement la charge de lancer wpeinit et surveiller l’appui de [F8] |
D. Organigramme des processus
Le processus de démarrage de WinPE est variable selon le type de noyau analysé. J’ai donc essayé de représenter un schéma décrivant les enchainements des noyaux courants que vous pourriez trouver sur une distribution originale Microsoft, un client LiteTouch et quelques déclinaisons WDS :
L’illustration étant déjà suffisamment riche en l’état, je commencerais donc mes explications après le chargement initial du chargeur “bootmgr”. (Il vous faut donc commencer la lecture ou le déchiffrage de ce “workflow” en haut à gauche )
Schéma de principe d’une initialisation WinPE
Explications :
Le point d’entrée clé de WinPE est le programme d’initialisation “winpeshl.exe” situé dans le dossier “X:\Windows\System32“. Celui-ci est référencé dans la clé de registre “HKEY_LOCAL_MACHINE\SYSTEM\Setup” au sein de la valeur “cmdline= winpeshl.exe”
Une fois ce programme lancé, vous bénéficiez de la séquence de touches [Maj] + [F10] pour ouvrir une invite de commande à tout instant.
Ce programme vérifie ensuite la présence d’un fichier “winpeshl.ini” situé dans le dossier “X:\Windows\System32“. Si celui-ci existe, il exécute séquentiellement les commandes qu’il contient. On peut y trouver les rubriques suivantes
[LaunchApp]
AppPath =
Pour l’exécution d’un programme unique sans paramètre :
[LaunchApps]
Application1.exe, option1, option2
Application2.exe, option1
Pour l’exécution de un ou plusieurs programme(s) avec ou sans paramètre(s)
Voici quelques exemples typiques de fichier “winpeshl.ini”
[LaunchApps]
%SYSTEMROOT%\System32\bddrun.exe,/bootstrap
[LaunchApps]
%SYSTEMROOT%\System32\bddrun.exe,/BootstrapNoSF8
[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe
[LaunchApps]
%SYSTEMROOT%\system32\wdscapture.exe
[LaunchApps]
%SYSTEMDRIVE%\sources\setup.exe,"/wds /wdsdiscover /WdsServer:WDS.labo.local"
[LaunchApps]
%windir%\system32\netstart.exe,-prompt
%SYSTEMDRIVE%\sources\recovery\recenv.exe
Par défaut, la fermeture du dernier programme lancé engendre un redémarrage de WinPE. Vous pouvez contrôler ce comportement en ajoutant le lancement d’une invite de commande, puis éventuellement solliciter un redémarrage via la commande “wpeutil reboot“.
Remarque : La particularité d’un client LiteTouch réside dans l’exécution de “bddrun.exe” dont le commutateur “/Bootstrap” déclenche l’exécution du programme “wpeinit.exe” qui va lui-même tester la présence d’un fichier “X:\unattend.xml” et le cas échéant, traiter les informations qu’il contient. L’appel de l’invite de commande s’effectue alors via [F8].
Si le fichier “winpeshl.ini” n’existe pas, le processus teste la présence à la racine (X:\) du fichier “Setup.exe“. C’est typiquement le programme d’accueil d’une distribution d’installation Windows, à ne pas confondre avec “X:\Sources\Setup.exe” qui correspond au programme d’installation. Bien que déconseillé, sachez qu’en remplaçant “X:\Setup.exe” par un exécutable quelconque, tel qu’un navigateur de fichiers comme “Explorer++”, ce dernier sera exécuté.
Par défaut, cet écran d’accueil vous propose l’installation ou la réparation d’un système. Dans le premier cas, l’installation recherche un fichier “Autounattend.xml” sur la racine de tous les médias accessibles, et le cas échéant, traite les informations qu’il contient.
Particularité : Lors d’un démarrage via PXE /WDS, le processus d’accueil “X:\Setup.exe” passe directement à l’exécution du programme d’installation “X:\Sources\Setup.exe“, qui affiche alors cet écran spécifique aux “Services de déploiement Windows”.
Setup et WDS : Ecran d’accueil typiquement affiché
Si le fichier “X:\Setup.exe” n’existe pas, c’est alors le batch “Startnet.cmd” situé dans le dossier “X:\Windows\System32“, qui est exécuté. Par défaut, ce fichier existe dans tous les noyaux WinPE et ne contient que la commande “wpeinit “.
Ce batch est modifiable, pour y inclure toute sorte de commandes dont vous auriez besoin. Il est toutefois important de relever que l’exécution de “wpeinit ” permet d’exploiter le contenu d’un fichier “X:\unattend.xml“, voire de stipuler un fichier de configuration spécifique “wpeinit /unattend:X:\CustomWinPE.xml“.
Astuce : Pour initialiser uniquement les couches réseau, utilisez la commande “wpeutil InitializeNetwork”
La suppression du fichier “Startnet.cmd” engendre une erreur, mais dans tous les cas l’exécution se termine sur une invite de commande.
Note: Pour le débogage, il est intéressant de savoir que l’exécution des programmes Winpeshl.exe et Wpeutil.exe génèrent leur journal respectif : “Winpeshl.log” et “Wpeutil.log“
La gestion et la création des fichiers de réponse .XML peut être réalisée via l’outil “Windows Image System Manager” (WISM) apporté par les kits WAIK ou ADK, mais l’usage peut s’avérer très vite déconcertant. Aussi, l’utilisation du bloc-notes à partir d’un modèle ou d’un exemple sera plus rapide à mettre en œuvre. J’attire toutefois votre attention sur le fait qu’il faut impérativement respecter l’architecture stipulée (“amd64″ ou “x86″), sous peine que le fichier .xml ne soit pas traité.
Exemple de fichier .xml :
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
<Display>
<ColorDepth>32</ColorDepth>
<HorizontalResolution>1024</HorizontalResolution>
<RefreshRate>60</RefreshRate>
<VerticalResolution>768</VerticalResolution>
</Display>
</component>
</settings>
</unattend>
V. Conclusion
Véritable pierre angulaire des solutions de déploiement, WinPE constitue un extraordinaire socle d’outils pour la maintenance et le déploiement Windows. Au fil de mes articles, vous découvrirez sa richesse et son extraordinaire potentiel.
Bien à vous
Christophe
A suivre : Personnalisation de WinPE
