CustPE : Comment installer vos propres outils dans WinPE ?

I. Présentation

Comme évoqué dans mes précédents tutoriels, la console MDT permet d'ajouter un dossier au sein des images WinPE personnalisées. Rappelez-vous, sous l'onglet "Windows PE" … "Extra directory to add". Cette faculté est intéressante et simple à mettre en œuvre, mais risque d'alourdir le noyau (ie "Ramdrive") dès lors que le volume de votre outillage devient significatif.

En fait, ce choix d'intégrer des outils additionnels au sein même du noyau WinPE est généralement motivé par la simplicité de "référencement" à ces programmes parce que la lettre affectée est toujours "X:"

Avant de vous lancer dans l'ajout d'un outillage complémentaire, gardez à l'esprit que les programmes doivent être autonomes - c'est à dire de simples binaires exécutables , ou ensemble de fichiers qui ne requièrent aucun processus d'installation, ni dépendance avec des composants Windows) - Depuis WinPE 4, il est toutefois possible d'ajouter une version limitée du framework .NET.

II. Comment connaitre la lettre du média WinPE ?

À mon avis, le stockage sur le média WinPE, est plus intéressant, surtout dans le cas d'outils volumineux ou utilisés très ponctuellement. Cependant, la lettre du média est variable et il peut s'avérer nécessaire d'employer un script pour localiser la bonne lettre d'unité.

Exemple de batch GetPEMedia.cmd

@ECHO OFF
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W Y Z) DO IF EXIST %%i:\SOURCES\Boot.wim SET MEDIAPE=%%i:
ECHO MediaPE = %MEDIAPE%

Exemple de script GetPEMedia.vbs

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set colDrives = objFSO.Drives
sFile = "\Sources\boot.wim"
bFound = False
For Each objDrive in colDrives
    sFind = objDrive.DriveLetter & ":" & sFile
    If objFSO.FileExists(sFind) Then
       bFound = True
       Wscript.Echo "Le fichier " & sFile & " a été trouvé sur le lecteur " & objDrive.DriveLetter & ":"
    End If
Next

If bFound = False Then Wscript.Echo "Le fichier " & sFile & " n'a été trouvé sur aucun lecteur."

Exemple de script GetPEMedia.ps1

$File = "\Sources\boot.wim" 
$Found = $False
$Drives = Get-WmiObject -Query "SELECT * from win32_logicaldisk"
ForEach ($Drive in $Drives) {
 if (Test-Path ("$($Drive.DeviceID)$Root$File")) { 
 $Found = $True
 Echo "Le fichier [$File] a été trouvé sur le lecteur $($Drive.DeviceID)"
 }
}
if ($Found -eq $False) { Echo "Le fichier [$File] n'a été trouvé sur aucun lecteur." }

Cette technique n'est toutefois valable que lorsque l'image du noyau WinPE est chargée à partir d'un support amovible. En effet, dès lors que l'on utilise un démarrage PXE, le média n'existe plus en tant que tel. Dans ce cas, bien que le réseau ait servi de support d'amorçage, il n'y a aucun lecteur réseau au sens propre.

III. Constitution de notre boite à outils

A. Avant-propos

Avant de m'engager sur un terrain pour le moins délicat, je rappelle que l'usage de programme au sein de Windows PE est régi par le respect d'un cadre technique, mais aussi légal. C'est ce qu'on désigne par le "contrat de licence d'utilisateur final", propre à chaque produit composant la solution.

Note : Pour respecter le cadre d'utilisation de WinPE qui n'inclut aucune licence au sens "utilisateur" et les contraintes légales d'utilisation des logiciels, je vous conseille de rester "sage" et de rester dans les limites des outils liés diagnostics, de réparation ou de déploiement d'un système.

Pour information, dans le cadre d'une souscription à un contrat "Software Assurance" ou "MSDN", vous pouvez prétendre au "Microsoft Desktop Optimization Pack", incluant le "Microsoft Diagnostics and Recovery Toolset". Ce produit particulier consiste à inclure une véritable boite à outils techniques construite à partir d'un socle WinPE.

Le résultat s'inscrit dans un écran "WinRE" sensiblement modifié, incluant un nouveau lien vers la boite à outils de Microsoft.

Ce qui donnera pour Windows 7 :

Et si on rentre à l'intérieur, on obtient :

...Et pour Windows 8 :

De la même manière, si l'on regarde ce qui se trouve à l'intérieur :

Je limiterais donc ma démonstration à quelques propositions, mais je ne vous encourage aucunement à en faire l'usage dans un cadre professionnel. Pour la forme, et lever toute ambiguïté,  j'ajouterais donc la formule bateau "je décline toute responsabilité sur les conséquences d'usage et d'application de ces informations, livrées à titre purement indicatif." 🙂

Vous pouvez également consulter cet excellent article d'Alex Dujakovic sur l'implémentation d'un outillage graphique sur un noyau WinPE 5. Pour constituer votre boite à outils, dont le choix et la pertinence vous incombent, vous pouvez consulter des sites spécialisés tels que :

• http://www.portablefreeware.com/
• http://windowsmatters.com/tag/winpe/
• http://www.snapfiles.com/features/ed_usb_software.html
• http://www.pendriveapps.com/

Toutefois, vous remarquerez certainement que les outils libres et gratuits en version 64 bits sont beaucoup moins nombreux que leurs homologues 32 bits. À titre d'exemple, je vous propose un petit tableau d'équivalence approximative susceptible de constituer votre propre boite à outils.

IV. Mise en pratique

Pour réaliser cette personnalisation, il nous faut récupérer un noyau WinPE (~boot.wim) à modifier. Pour cela, nous avons de nombreuses possibilités, telles que :

• Récupérer un noyau existant à partir d'un DVD original de distribution Windows NT6.x (*)
• Générer une image de démarrage MDT, noyau générique ou client LiteTouch
• Générer un nouveau noyau à partir du kit ADK (ou WAIK)

(*) Les noyaux présents sur les DVD contiennent 2 images, la première étant générique " Microsoft Windows PE (x64|x86)"et la seconde, plus riche, contenant les programmes d'installation " Microsoft Windows Setup (x64|x86)"

En fonction de vos objectifs, les opérations devront être déclinées sur chacun des noyaux 32 et/ou 64 bits.

À la lecture de mes différents articles sur le sujet, vous aurez certainement compris que je fais manifestement partie des inconditionnels de MDT. Donc plutôt que de tout fabriquer via la ligne de commande d'un ADK , je vous propose donc construire cet atelier à partir des images génériques que nous avons déjà évoquées précédemment.

A. Constituer la boite à outils

Pour la démonstration, je vais donc m'inspirer partiellement de la solution proposée par "Terabyte" expliqué ici  et qui contient un lanceur graphique de programmes "TBLaunch", ainsi que plusieurs petites fonctions très pratiques, que nous détaillerons plus tard.

- Commençons par télécharger ce kit ici

- Ajoutons l'explorateur de fichier "Explorer++" dont vous trouverez les sources 32 et 64 bits ici

- Ajoutons l'outil "NTPWEdit" pour la réactivation des comptes locaux et réinitialisation des mots de passe dont vous trouverez les sources 32 et 64 bits ici

- Ajoutons l'outil "PE Network" pour la gestion du réseau dont vous trouverez les sources 32 et 64 bits ici : Ces packages sont au format .7z - Au besoin téléchargez également l'excellent outil gratuit "7-Zip"

Note : J'ai remarqué que l'outil "PE Network" à une forte dépendance avec l'initialisation des couches réseaux via wpeinit et ne fonctionne donc pas avec un client Litetouch, qui exploite un processus alternatif "bbdrun /bootstrap"

N'oubliez pas de "débloquer" les fichiers provenant de sources téléchargées à partir d'Internet.

B. Ventilation de l'outillage

Pour ne pas trop surcharger la liste déjà conséquente des explications, voici la structure dans laquelle j'ai ventilé les différents outils. La structure distingue volontairement les outils à intégrer dans le noyau de ceux destinés à rester sur le média. Toutefois, en raison de la taille relativement faible de ces outils, j'ai opté pour l'intégration totale dans le noyau.

Structure de travail :

Les fichiers en rouge dans le schéma sont à créer ou à modifier selon les explications qui vont suivre. Vous constaterez que je n'ai pas copié l'intégralité des sources et que pour certains programmes, j'ai rajouté le suffixe "*64.exe" pour distinguer les binaires 64 bits.

C. Préparation des fichiers nécessaires à la fabrication

1. Création du menu TBLaucher

En premier lieu, j'ai modifié, un peu violemment certes, le fichier "TBLauncher.ini" comme suit:

[Options]
Mode=WinPE
RunWpeinit=0
DisableFirewall=0
BackgroundInit=1
FindBootDrive=0
MaxSearchTime=8
UpdatePrograms=0

[Menu]
ItemCount=10

[Menu_Item_1]
Name=Explorer++
Path=%systemdrive%\Tools\Explorer++.exe
Path64=%systemdrive%\Tools\Explorer++64.exe

[Menu_Item_2]
Name=Show SuperHidden Files
Path=%systemdrive%\Scripts\ShowSuperHidden.vbs

[Menu_Item_3]
Name=Set French Keyboard Layout
Path=%SystemRoot%\System32\wpeutil.exe
Parameters=SetKeyboardLayout 040c:0000040c

[Menu_Item_4]
Name=Command Prompt
Path=%SystemRoot%\System32\cmd.exe

[Menu_Item_5]
Name=Powershell
Path=%SystemRoot%\System32\WindowsPowershell\v1.0\Powershell.exe

[Menu_Item_6]
Name=PE Network
Path=%systemdrive%\Tools\PENetwork.exe
Path64=%systemdrive%\Tools\PENetwork64.exe

[Menu_Item_7]
Name=Unlock Accounts
Path=%systemdrive%\Tools\ntpwedit.exe
Path64=%systemdrive%\Tools\ntpwedit64.exe

[Menu_Item_8]
Name=Regedit
Path=%systemroot%\System32\regedt32.exe

[Menu_Item_9]
Name=Notepad
Path=%SystemRoot%\System32\notepad.exe

[Menu_Item_10]
Name=Task Manager
Path=%SystemRoot%\System32\taskmgr.exe

Durant la fabrication, ce fichier sera stocké sous "[Z:\CustPE]\Kernel\Tools\TBLauncher.ini"

2. Facultatif : Script pour afficher les fichiers protégés

Cette astuce est liée à l'usage d'explorateurs graphiques tel que Explorer++, A43…, qui n'affichent pas les "fichiers et dossiers protégés du système" car ils s'appuient sur des clés de registre ("SuperHidden") absentes du noyau WinPE.

Pour pallier cette particularité, il est possible de modifier le registre HKLM par défaut de WinPE, sous réserve d'effectuer le montage du noyau. Pour simplifier, j'ai donc ajouté le script suivant "ShowSuperHidden.vbs" qu'il suffira d'exécuter pour afficher les fichiers protégés sous WinPE.

Hidden = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden"
SHidden = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ShowSuperHidden"
Set oShell =  CreateObject("WScript.Shell")
oShell.RegWrite Hidden, 0, "REG_DWORD"
oShell.RegWrite SHidden, 1, "REG_DWORD"
oShell.Popup "L'affichage des fichiers protégés est maintenant activé",3,"Information",vbInformation

Durant la fabrication, ce fichier sera stocké sous "[Z:\CustPE]\Kernel\Scripts\ShowSuperHidden.vbs"

Note : Si vous suivez intégralement cette procédure, ce script n'aura pas d'utilité du fait que j'ai finalement décidé d'ajouter cette modification du registre dans le script de personnalisation du noyau.

3. Script pour la détection du média WinPE

Le batch suivant "Launcher.cmd" est destiné à déclarer les variables de l'architecture et du média WinPE et démarrer le lanceur d'application.

@ECHO OFF
IF "%PROCESSOR_ARCHITECTURE%"=="AMD64" SET CPU=64
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W Y Z) DO IF EXIST %%i:\SOURCES\Boot.wim SET MEDIAPE=%%i:
IF "%MEDIAPE%"=="" SET MEDIAPE=PXE
ECHO MediaPE = %MEDIAPE%
%systemdrive%\Tools\TBLauncher%CPU%.exe

Dans cette démonstration, nous n'exploiterons pas le cas du démarrage de WinPE via WDS ou PXE, mais en l'absence de support amovible, la variable "MediaPE" sera positionnée sur "PXE". (Pour éventuellement déclencher un script ou des actions spécifiques par la suite…)

Durant la fabrication, ce fichier sera stocké sous "[Z:\CustPE]\Kernel\Scripts\Launcher.cmd"

4. Choisir une image de fond (facultatif)

Vous pouvez préparer une image de fond d'écran pour WinPE. Par défaut, le MDT propose l'image située sous "C:\Program Files\Microsoft Deployment Toolkit\Samples\Background.bmp".

Pour l'exemple, j'ai arbitrairement choisi une autre image "Wallpaper_windows_logo.bmp", mais pour une meilleure compatibilité des différents noyaux, nous opterons pour le format bitmap moins optimisé.

Durant la fabrication, ce fichier sera stocké sous "[Z:\CustPE]\Wallpaper_windows_logo.bmp"

Note : Il peut être plus simple de remplacer le fichier d'exemple "C:\Program Files\Microsoft Deployment Toolkit\Samples\Background.bmp" par votre image préférée. Ce fichier sera automatiquement intégré dans le noyau WinPE, sous le nom "X:\Windows\System32\WinPE.bmp".

5. Présélection des composants intégrés aux images génériques

Bien que l'on puisse effectuer ces réglages au niveau de l'interface de la console MDT, j'ai opté pour la modification du fichier "C:\Program Files\Microsoft Deployment Toolkit\Templates\Generic.xml"

<Definition>
  <WindowsPE>
	
	<!-- Settings -->
	<Version />
	<Source />
	<ScratchSpace>128</ScratchSpace>
	<ImageName />
	<ImageDescription />

	<!-- Components -->
	<Components>
      <Component>winpe-hta</Component>
      <Component>winpe-scripting</Component>
      <Component>winpe-wmi</Component>
      <Component>winpe-mdac</Component>
      <Component>winpe-netfx</Component>
      <Component>winpe-powershell</Component>
	</Components>
	
	<!-- Driver and packages -->
	<Drivers />
	<Packages />
	
	<!-- Content -->
	<Content>

	</Content>

	<!-- Exits -->
	<Exits>
	  <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit>
	</Exits>
	
  </WindowsPE>
</Definition>

Remarque : Il est inutile de modifier les fichiers "Generic_*.xml" et "LiteTouch_*.xml" présents dans le dossier "Boot" du partage de déploiement. En fait, ils sont construits à partir des modèles et des réglages effectués dans la console MDT.

6. Préparation du lanceur d'application

Pour exécuter automatiquement le lanceur d'application aussitôt après du chargement du noyau, il nous faut créer un fichier "winpeshl.ini", comme suit :

[LaunchApps]
%SYSTEMDRIVE%\Scripts\Launcher.cmd

Durant la fabrication, ce fichier sera stocké sous "[Z:\CustPE]\winpeshl.ini"

D. Les phases de fabrication

La préparation est pratiquement terminée et il ne nous reste plus qu'à assembler tout cela. Il existe plusieurs moyens pour y parvenir, dont l'usage du kit ADK (ou WAIK) en ligne de commande, mais je souhaitais profiter de cette occasion pour aborder un aspect méconnu du MDT. Personnellement, je suis régulièrement surpris par les possibilités de cet outil, et la suite peut s'avérer intéressante pour répondre à certains besoins de personnalisation supplémentaires.

1. Explications

En regardant de plus près les modèles de fabrication des images de démarrage MDT, LiteTouchPE.xml et Generic.xml que nous avons déjà évoqués, vous avez pu relever la présence d'une portion dédiée à la finalisation des traitements, qui doit ressembler à ceci :

<!-- Exits --> 
<Exits> 
 <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit> 
</Exits>

En fait, lors de l'exécution du processus "Update Deployment Share", ce script de sortie "UpdateExit.vbs" est appelé plusieurs fois durant les différentes phases du processus de fabrication, et permet ainsi d'ajouter librement des actions de personnalisation.

Contenu du script d'exemple par défaut :

' // ***************************************************************************
' // 
' // Copyright (c) Microsoft Corporation.  All rights reserved.
' // 
' // Microsoft Deployment Toolkit Solution Accelerator
' //
' // File:      UpdateExit.vbs
' // 
' // Version:   <VERSION>
' // 
' // Purpose:   Sample "Update Deployment Share" exit script
' // 
' // ***************************************************************************


Option Explicit

Dim oShell, oEnv


' Write out each of the passed-in environment variable values

Set oShell = CreateObject("WScript.Shell")
Set oEnv = oShell.Environment("PROCESS")

WScript.Echo "INSTALLDIR = " & oEnv("INSTALLDIR")
WScript.Echo "DEPLOYROOT = " & oEnv("DEPLOYROOT")
WScript.Echo "PLATFORM = " & oEnv("PLATFORM")
WScript.Echo "ARCHITECTURE = " & oEnv("ARCHITECTURE")
WScript.Echo "TEMPLATE = " & oEnv("TEMPLATE")
WScript.Echo "STAGE = " & oEnv("STAGE")
WScript.Echo "CONTENT = " & oEnv("CONTENT")


' Do any desired WIM customizations (right before the WIM changes are committed)

If oEnv("STAGE") = "WIM" then

    ' CONTENT environment variable contains the path to the mounted WIM

End if


' Do any desired ISO customizations (right before a new ISO is captured)

If oEnv("STAGE") = "ISO" then

    ' CONTENT environment variable contains the path to the directory that
    ' will be used to create the ISO.

End if


' Do any steps needed after the ISO has been generated

If oEnv("STAGE") = "POSTISO" then

    ' CONTENT environment variable contains the path to the locally-captured
        ' ISO file (after it has been copied to the network).

End if

Attardons-nous maintenant sur les variables positionnées durant ce processus et sur l'intérêt de ce script particulier.

On peut distinguer 3 phases durant lesquelles la variable "STAGE" prendra les valeurs suivantes :

• "WIM" . Durant cette phase, l'image WIM est montée et personnalisée, mais les modifications ne sont pas encore appliquées (commit). À ce stade, vous pouvez manipuler librement le contenu du noyau comme par exemple, copier des fichiers, créer des dossiers, monter/modifier le registre, et tout ce que vous voulez.

• "ISO" . Cette phase se manifeste juste avant l'opération de création de l'image ISO. Cela permet typiquement d'ajouter des fichiers sur le média et non dans le noyau, mais vous pouvez également en profiter pour copier l'image du noyau modifié, actuellement situé sous "oEnv("CONTENT") & "\Sources\Boot.wim" vers un serveur WDS par exemple.

• "POSTISO". Cette dernière phase survient une fois que le fichier ISO a été créé et avant qu'il ne soit copié vers le partage de déploiement. Vous pouvez par exemple, copier l'ISO automatiquement sur un partage public, le graver sur un CD, etc.

De plus, durant ces phases de fabrication, il est possible d'exploiter les variables suivantes :

Vous voilà donc en mesure de réaliser toute sorte de personnalisation avec précision. Comme par exemple, ajouter des outils supplémentaires sur le média sans avoir à surcharger le noyau.

' Copiez vos outils dans un dossier racine , par exemple "Z:\CustPE\"
' Placez les binaires 64 bits dans un sous-dossier "MediaTools_x64"
' Placez les binaires 32 bits dans un sous-dossier "MediaTools_x86"

Const sCustRoot = "Z:\CustPE\"

If oEnv("STAGE") = "ISO" then
  Set oFSO = CreateObject ("Scripting.FileSystemObject")
  If oFSO.FolderExists(sCustRoot) Then  
    Const OverwriteExisting = TRUE
    sRep = oEnv("CONTENT") & "\Tools_" & oEnv("PLATFORM")
    oFSO.CreateFolder(sRep)
    oFSO.CopyFile "MediaTools_" & oEnv("PLATFORM") & "\*.*" , _
        sRep & "\" , OverwriteExisting
  Else
    WScript.Echo "Erreur: Le dossier " & sCustRoot a " est introuvable."
  End If

WScript.Quit 1
End if

Voici un exemple de script que je vous propose d'essayer. Celui-ci ne se charge pas de copier les outils sur le média comme le précédent, mais effectue une modification du registre du noyau, la copie du fond d'écran ainsi que les différents outils de cette démonstration. En matière de code, ce n'est pas forcément un modèle du genre, mais je souhaitais vous montrer également l'usage de commandes externes, telles que reg, copy, xcopy…

Set oShell = CreateObject("WScript.Shell")
Set oEnv = oShell.Environment("PROCESS")

WScript.Echo "INSTALLDIR = " & oEnv("INSTALLDIR")
WScript.Echo "DEPLOYROOT = " & oEnv("DEPLOYROOT")
WScript.Echo "PLATFORM = " & oEnv("PLATFORM")
WScript.Echo "ARCHITECTURE = " & oEnv("ARCHITECTURE")
WScript.Echo "TEMPLATE = " & oEnv("TEMPLATE")
WScript.Echo "STAGE = " & oEnv("STAGE")
WScript.Echo "CONTENT = " & oEnv("CONTENT")

Const sCustRoot = "Z:\CustPE\"

If oEnv("STAGE") = "WIM" And oEnv("TEMPLATE") = "Generic" then
    sMountHive = oEnv("CONTENT") & "\Windows\System32\config\DEFAULT"
    sTempHive = "HKLM\WinPE"
    ' Load Temp Hive WinPE
    sCmd = "%COMSPEC% /c reg load " & sTempHive & " " & Chr(34) & _ 
      sMountHive & Chr(34)
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)
    WScript.Echo "Load Return code : " & rc
        
    ' Modify Temp Hive WinPE
    Hidden = sTempHive & "\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden"
    SHidden = sTempHive & "\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ShowSuperHidden"
    oShell.RegWrite Hidden, 0, "REG_DWORD"
    oShell.RegWrite SHidden, 1, "REG_DWORD"
    
    ' Unload Temp Hive WinPE
    sCmd = "%COMSPEC% /c reg unload " & sTempHive
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)
    WScript.Echo "Unload Return code : " & rc

    '  copy autolauncher (winpeshl.ini) 
    sCmd = "%COMSPEC% /c copy " &  sCustRoot & "\winpeshl.ini " & _
       oEnv("CONTENT") & "\Windows\System32\winpeshl.ini"
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)

    '  copy kernel tools x86 and x64 and scripts
    sCmd = "%COMSPEC% /c xcopy " &  sCustRoot & "\Kernel\*.* " & _ 
       oEnv("CONTENT") & " /e /s"
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)
 
    '  copy wallpaper
    sCmd = "%COMSPEC% /c copy " &  sCustRoot & "\*.bmp " & _
       oEnv("CONTENT") & "\Windows\System32\winpe.bmp"
    WScript.Echo "Execute : " & sCmd
    rc = oShell.Run(sCmd, 0, true)

    WScript.Quit 1

End if

Important : J'ignore pourquoi (no bug, it's a feature !), mais le script de sortie n'est pas pris en compte lorsqu'il ne contient pas la directive "WScript.Quit 1". Si cette directive est présente, le script sera exécuté et les instructions "wscript.echo" seront affichés dans la fenêtre de résultat de la console MDT.

Exemple d'affichage dans la console:

Après avoir renommé le fichier existant, il suffit d'enregistrer ce script en lieu et place de ce dernier sous "C:\Program Files\Microsoft Deployment Toolkit\Samples\UpdateExit.vbs".

Il est également possible de modifier le nom et l'emplacement de ce script, en le stipulant dans le fichier du modèle "Generic.xml" comme suit :

<Exits> 
 <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit>
 <Exit>cscript.exe "Z:\Scripts\CustomUpdateExit.vbs"</Exit> 
</Exits>

2. Génération des images

À partir de la console MDT, sélectionnons notre partage de déploiement préféré afin d'afficher les "propriétés" puis rendons-nous sous l'onglet "Windows PE" sans oublier de vérifier l'architecture "Platform" = "x86|x64"

Sous le sous-onglet "General", il nous faut supprimer le fond d'écran personnalisé "Custom background bitmap file"  ainsi que "Extra directory to add" du fait qu'ils sont traités par le script.

Notez que ces réglages (copie de fichiers), peuvent également être définis dans les fichiers de modèles "C:\Program Files\Microsoft Deployment Toolkit\Templates\Generic.xml" et/ou "LiteTouch.xml" entre au niveau de la balise "<Content>"..

En fait, je pense que le principal inconvénient lié à l'interface graphique MDT est que l'image et le dossier additionnel sont appliqués aux 2 images LTI et générique.

Nous cocherons également les 2 cases "Generate a generic Windows PE WIM file" et "Generate a generic bootable ISO image" en indiquant éventuellement un nom de notre choix pour ces fichiers.

Normalement, il n'y a rien à faire au niveau du sous-onglet "Features" du fait que les composants optionnels ont été configurés dans le fichier "Generic.xml".

Après avoir validé ces choix par "OK", il suffit d'utiliser le menu "Update Deployment Share" pour procéder à la génération.

Vous pouvez maintenant aller tranquillement déguster un bon café ou plusieurs, vous l'avez mérité.:-)

Après quelques longues minutes de patience, nous retrouvons les fichiers .WIM et .ISO dans le dossier "\Boot" du partage de déploiement.

V. Tests et Résultats

En démarrant une machine virtuelle à partir de l'image .ISO obtenue par cet atelier, nous pourrons constater ce genre de résultat.

La lettre du média WinPE est affichée dans une invite de commande qu'il faut conserver ouverte afin de ne pas redémarrer le système, et le lanceur d'application "TBLauncher" est automatiquement lancé.

Aperçu du résultat :

Je reconnais volontiers que cette démonstration est plutôt ardue et pour vous faciliter la tâche, je vous propose de télécharger la structure des fichiers utilisés pour cet atelier ici. (CustPE.zip - 3 679 587 octets )

À vous de jouer 🙂

Christophe Mandin Consultant - Formateur indépendant

Consultant/Formateur indépendant en quête de solutions et de moyens alliant efficacement la théorie et la pratique. Fort d’une expérience de plusieurs dizaines années dans l’informatique, j’ai pu apprécier de nombreuses problématiques, développer des qualités rédactionnelles et un esprit de synthèse, tout en me forgeant de solides fondamentaux théoriques, indispensables à toute analyse et mise en œuvre fonctionnelle. Malgré toutes ces années, je ne me lasse pas du plaisir de transmettre mes connaissances en misant sur 3 critères que sont les fondamentaux, la simplicité et le pragmatisme. Bien à vous. Retrouvez-moi sur LinkedIn : Christophe Mandin

See Full Bio