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“

 

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 )

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”

• Client LTI

[LaunchApps]
%SYSTEMROOT%\System32\bddrun.exe,/bootstrap

• Client LTI sans F8

[LaunchApps]
%SYSTEMROOT%\System32\bddrun.exe,/BootstrapNoSF8

• WinRE

[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe

• Image de Capture

[LaunchApps]
%SYSTEMROOT%\system32\wdscapture.exe

• Image de Découverte

[LaunchApps]
%SYSTEMDRIVE%\sources\setup.exe,"/wds /wdsdiscover /WdsServer:WDS.labo.local"

• DaRT

[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”.

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