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.

Outil	x bits	Description	Equiv. MsDaRT
TBLauncherPStart NU2Menu BS Explorer	32/64 32 32 32	Utilitaire de lancement d’applications	DaRT Screen
NTPWEdit	32/64	Réactivation des comptes locaux et réinitialisation des mots de passe.	Locksmith
Regedit	32/64	Edition du registre	ERD Registry Editor
Explorer++A43 Q-Dir	32/6432 32/64	Explorateurs de fichiers	Explorer
PENetwork	32/64	Gestion d’adresse IP et connexion de lecteur réseau	TCP/IP Config
ClamWinStinger	32/64	AntivirusOutil de suppression des logiciels malveillants Microsoft® Windows® (KB890830)	Standalone System Sweeper
Ultra File Search	32	Recherche de fichiers	Search
Recuva	32/64	Récupération de fichiers effacés	File Restore
Eraser	32/64	Suppression définitive de contenu	Disk Wipe
N/A		Désinstallation de correctif	Hotfix Uninstall
N/A		Gestion de l’ordinateur	Computer Management
AOMEI Partition Assistant  DiskPartitioner	32/6432/?64	Gestion des volumes, formatage et partitionnement	Disk Commander
UltraVNC	32/64	Prise de main à distance (cf Mon article à paraître sur le sujet)	RemoteRecovery
7-Zip	32/64	Gestion d’archives	N/A
TestDisk.WIN	32/64	Récupération de données “bas niveau” – partitions/fichiers	N/A
SIW	32/(64)	Affichage d’information système sur le matériel et les logiciels	N/A
HD TuneCheckdisk	3232/64	Testeur/vérificateur de disque dur	N/A
Disk2VHD	32/64	Clonage d’un disque physique vers un fichier de disque virtuel .VHD (sysinternals)	N/A
HxD	32	Éditeur hexadécimal	N/A
LLFTool	32	Outil de formatage de disque bas niveau (HDDGuru).
GimageX	32/64	Outil de gestion des images WIM	N/A

 

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 :

Variable	Description
INSTALLDIR	Correspond au chemin d’installation de l’outillage MDT 32 ou 64 bits (ie  “C:\Program Files\Microsoft Deployment Toolkit”)
DEPLOYROOT	Correspond au chemin UNC du partage de déploiement, typiquement “\\SERVER\DeploymentShare$”
PLATFORM	Indique l’architecture “x86″ ou “x64″ de l’image en cours de génération
ARCHITECTURE	Indique l’architecture “x86″ ou “amd64″ de l’image en cours de génération. Ce “doublon” provient de la subtilité des indicateurs 64 bits, qui retournent les  “amd64″ ou “x64″ selon les contextes.
TEMPLATE	Permet d’indiquer le modèle de la fabrication, soit “LiteTouchPE.xml” pour les clients LiteTouch, ou “Generic.xml” pour les images génériques.
CONTENT	Permet de référencer le contenu de travail en cours. Durant la phase “WIM”, la variable pointe vers l’emplacement de montage de l’image WIM. Pour la phase “ISO”, elle pointe vers le dossier dans lequel l’image .ISO sera créée. Dans ces 2 premiers cas, il s’agit par défaut d’un dossier temporaire. Durant la dernière phase “POSTISO”, la variable pointe vers le fichier .ISO résultant.

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

La plupart des appareils sous Android rencontrent actuellement un sérieux problème de sécurité puisqu’un simple MMS permettrait d’exécuter du code arbitraire. 95% des utilisateurs Android seraient touchés, en se basant sur 1 milliard d’appareils ce qui en fait 950 millions de vulnérables.

La bibliothèque Android “Stagefright” développée en C++ contient la vulnérabilité et elle est appelée à chaque fois qu’un contenu multimédia pris en charge est détecté. Par exemple, un simple MMS sur un smartphone et la bibliothèque traite la photo ou la vidéo contenue, mais ça peut être aussi la lecture d’un contenu web…

Un code particulier présent au sein d’un cliché peut permettre d’exécuter du code sur l’appareil puisqu’il sera traité par Stagefright. Le pire c’est que l’on ne peut rien faire puisque Stagefright pourra préparer le travail en arrière-plan lors de la réception d’un MMS…

Toutes les versions d’Android à partir de la 2.2 sont concernées. Google a déjà développé un correctif de sécurité contre cette vulnérabilité, mais maintenant l’enjeu est de déployer ce correctif sur les appareils et on sait à quel point les mises à jour sur Android ne sont pas déployées en même temps. Chaque constructeur va à son rythme. Au niveau applicatif, Firefox 38 contient déjà un correctif pour cette faille (connue depuis plus de trois mois) et nous sommes aujourd’hui à la version 39.

Les appareils tels que les Nexus devraient bénéficier rapidement d’un correctif puisque c’est Google qui est derrière. Pour les partenaires de Google, ce sera pour « dans les prochaines semaines ou les prochains mois ». On peut imaginer que les appareils trop anciens ne soient pas mis à jour…

Pour mettre la pression sur les constructeurs, des détails supplémentaires seront dévoilés lors de deux conférences : le 5 août au Black Hat et le 7 août à la DEF CON.

Source

I. Présentation du produit

Prévu pour succéder au MX100 de la même marque, le Crucial MX200 est le disque SSD de 500 Go que j’ai testé pour vous ! Faisons rapidement un tour des caractéristiques principales (annoncées par Crucial) :

– Lecture séquentielle (Mo/s) : 555

– Écriture séquentielle (Mo/s) : 500

– Lecture aléatoire (IOPS) : 100 000

– Écriture aléatoire (IOPS) : 87 000

– Mémoire cache : 512 Mo

– Interface : SATA 3, rétrocompatible

– Poids : 51 grammes

Passons maintenant à la suite !

II. Boitier et design

Très léger en main, ce boitier en aluminium est joliment conçu, je trouve que l’autocollant apposé par Crucial donne un effet sympa d’autant plus qu’il est brillant. Après pour être franc, il s’agit d’un SSD destiné à être dans votre machine donc on ne le regarde pas tous les jours. Le fait que le boitier soit en aluminium et qu’il soit léger est plus important.

Au passage, voici une photo de la vue de dessous :

Il est à noter que dans la boîte du MX200, on trouve également un adaptateur pour augmenter l’épaisseur du SSD de 7 à 9,5 mm.

III. Sécurité

A. La technologie Rain

Par l’intermédiaire d’un bloc de parité, la technologie Rain de Crucial protège vos données si un bloc mémoire devenait à être défaillant. Cette technologie assimilable au RAID directement au niveau matériel permet la reconstruction des données en cas de défaillance.

Grâce à l’écriture des données en parallèle, les performances sont également accrues.

B. Chiffrement

Le Crucial MX200 est également pensé pour la protection des données sur l’aspect chiffrement, puisqu’il réalise du chiffrement matériel AES 256-bit et il est compatible avec :

– Microsoft eDrive

– IEEE-1667

– Trusted Computing Group Opal 2.0

IV. Les performances du MX200

Avant de passer au fameux graphes des performances, je tiens à préciser que le système de cache Crucial (Dynamic Write Acceleration) n’est pas présent sur cette version 256 Go. Pour être plus précis, Crucial l’intègre uniquement sur le MX200 256 Go.

Voici sans plus attendre, un résumé des perfs avec le logiciel CrystalDiskInfo que j’ai pour habitude d’utiliser :

Au niveau du taux d’endurance, il est de 160 To pour ce modèle 500 Go, ce qui représente 87 Go d’écriture par jour sur 5 ans (information de Crucial), un rythme d’écriture que l’on atteindra surement pas dans le cadre d’une utilisation classique, mais que l’on peut envisager lors de transferts de données répétés ou d’utilisation de logiciels gourmands. Le taux d’endurance étant très intéressant, on peut envisager une belle durée de vie pour ce disque SSD.

V. Le logiciel Storage Executive

Le logiciel Storage Executive de Crucial est disponible pour Windows 7 et Windows 8/8.1. Aujourd’hui en version 3.20, cette application a pour objectif principal d’optimiser votre SSD Crucial, voici quelques unes des fonctionnalités :

– Momentum Cache : utiliser la RAM disponible du PC pour créer un cache afin d’accélérer la vitesse de lecture (applications, données…)

– Mise à jour du firmware du SSD

– Etat de l’espace de stockage

– Température et intégrité du disque SSD

– Réinitialiser le mot de passe chiffré du SSD

De manière générale, les diverses fonctionnalités proposées permettent d’optimiser le disque SSD notamment pour prolonger sa durée de vie. Voici l’interface de l’application qui est accessible en mode web par un navigateur :

Le logiciel est capable de donner certaines informations quant à des SSD qui ne sont pas de marque Crucial, mais ne permets pas d’utiliser les fonctionnalités intéressantes de l’outil.

Plus d’infos

VI. Conclusion

Ce SSD m’a donné bonne impression, et il dispose de sérieux arguments pour vous séduire notamment car il intègre des fonctionnalités intéressantes, avec en supplément une licence du logiciel Acronis qui est très bon dans son domaine. De plus, les performances sont bonnes et l’endurance annoncée également, Crucial a fait du bon boulot sur ce MX200 !

Le fait qu’il soit léger est également un plus, notamment lors d’une installation dans un PC portable, plus particulièrement un ultrabook.

Finalement, ce Crucial MX200 intègre des fonctionnalités professionnelles tout en les mettant au profit du grand public, ce qui en fait un fait un modèle complet et performant. Si je devais mettre un bémol, ce serait pour la garantie qui est de 3 ans, certes c’est déjà bien mais certains concurrents vont plus loin en proposant 5 ans, voir même 10 ans sur certains modèles spécifiques.

Ce SSD est disponible sur de nombreuses boutiques en ligne, telle que Cdiscount, RueDuCommerce, Pixmania… Environ au prix de 208 euros pour la version 500 Go. A ce prix, il est à noter que Crucial fournit également une licence Acronis True Image HD 2014, un célèbre logiciel de sauvegarde et restauration.

Enfin, pour ceux qui recherchent ce modèle en une autre capacité, sachez qu’il est disponible en différentes capacité, à savoir 256 Go, 500 Go et même 1 To.

N’hésitez pas à consulter notre guide d’optimisation d’un disque SSD.

Conçu par les créateurs de KDE, Plasma Mobile a pour objectif de faciliter la transition vers le monde du libre mais aussi de protéger l’utilisateur. Le souhait est de limiter les différences entre l’utilisation sur un PC, une tablette ou un smartphone avec un OS libre et open source.

D’après les informations fournies, en plus des applications réservées à Linux, il serait capable d’ouvrir les applications Android sur Plasma Mobile. Cependant, il faudra voir comment Plasma Mobile gère les autorisations souhaitées par les applications Android qui sont pour certaines curieuses.

Basé sur la distribution Kubuntu (dérivée d’Ubuntu), Plasma Mobile utilise les drivers graphiques d’Android. Par ailleurs, il reprend des éléments du Shell Plasma disponible sur la version bureau de KDE. Comme tout système d’exploitation mobile, il dispose d’une panoplie d’applications dédiées aux usages courants : SMS, appels, notifications, gestion des contacts…

Voici une vidéo de présentation de Plasma Mobile :

I. Présentation

Ce petit tutoriel est destiné à vous expliquer comment installer un outil de prise de main à distance sur le système de déploiement WinPE. L’idée première de cet article est de proposer une alternative à l’outillage DaRT (Diagnosis And Repair Toolkit) fournit aux clients ayant souscrit le contrat Software Assurance MDOP (Microsoft Desktop Optimisation Pack). L’intégration d’une solution de prise de main à distance permet de surveiller le déploiement sur les différents postes de votre entreprise. Notez que l’outil DaRT précité, s’intègre facilement dans le MDT (Microsoft Deployment Toolkit)

Rappel : Le système de déploiement WinPE est minimaliste et ne supporte pas le mode WoW (Windows On Windows, et non World of Warcraft  ) contrairement aux systèmes d’exploitation dont il partage le noyau. Autrement dit, les outils que vous seriez amené à utiliser dans un environnement WinPE doivent impérativement correspondent à l’architecture retenue. Il va sans dire que les outils 32 bits sont plus répandus que leurs homologues 64 bits.

 

II. L’outil de prise de main à distance

Il existe de nombreux outils dans ce domaine, mais j’ai opté pour UltraVNC en raison de sa gratuité et sa disponibilité dans les 2 architectures 32 et 64 bits. (Vous pouvez télécharger les sources ici

A. Extraire les fichiers UltraVNC

Après avoir téléchargé les sources désirées, procédez à l’extraction du package .msi via la commande suivante :

msiexec /a D:\Downloads\UltraVnc_1205_X64.msi /qb TARGETDIR=D:\CustPE\UltraVNC\UltraVnc_1205_X64

Note : L’option “/a” permet de réaliser une installation dite “administrative”. C’est-à-dire d’extraire le contenu sur une ressource locale ou réseau, sans installer le produit. L’option “/qb” effectue l’opération avec l’interface graphique de base sans intervention de l’utilisateur (“quiet modes”) – Utilisez “msiexec /?” pour obtenir plus d’informations sur les commutateurs de la commande et au besoin sur mon article relatif à la “gestion des applications“

A l’issue de cette commande vous devriez obtenir un ensemble de fichiers dans le dossier cible (que vous devrez créer préalablement à l’exécution de la commande précitée) – Les fichiers utiles pour cette démonstration sont winvnc.exe et vnchooks.dll. L’exécutable vncviewer nous servira pour réaliser la connexion à distance.

Pour faire court, nous allons simplement générer via le bloc-notes un fichier d’initialisation (nouveau) nommé “UltraVNC.ini” avec le contenu suivant:

[Permissions]
[admin]
AuthRequired=0
HTTPConnect=0
[ultravnc]
[poll]
TurboMode=1
PollUnderCursor=0
PollForeground=1
PollFullScreen=0
OnlyPollConsole=0
OnlyPollOnEvent=1
MaxCpu=40
EnableDriver=0
EnableHook=1
EnableVirtual=0
SingleWindow=0
SingleWindowName=

Ce fichier d’exemple décrit une configuration minimaliste mais suffisante pour notre besoin. Notez toutefois, que cette méthode (AuthRequired=0) n’utilisera aucun mot de passe pour la connexion vers le poste sous WinPE. Si vous souhaitez ajouter des mots de passe pour la connexion et/ou la visualisation, il faudra les générer préalablement en exécutant une fois le programme sur un poste. En effet, les mots de passe sont encodés dans le fichier “UltraVNC.ini” et l’outil ne propose pas de méthode native pour les générer préalablement.

Note : La directive “SingleWindowName=” vide est “normale”. Je n’ai pas essayé de la supprimer car de nombreux exemples du site ultravnc, la contienne… et la documentation http://www.uvnc.com/docs/uvnc-server/69-Ultra%20VNCini.html indique ” Current not used”.

B. Personnalisation du noyau WinPE

Pour rappel, les images d’amorçage WinPE sont disponibles sur les sources ISO ou DVD des systèmes d’exploitation depuis Vista, ou sur le kit de déploiement Windows ADK (Assesment and Deployment Kit) – anciennement connu sous le nom WAIK pour Windows Automated Installation Kit. Ces kits sont d’ailleurs des prérequis à l’utilisation de l’atelier de déploiement (Deployment Workbench) du MDT.

Pour simplifier cet article, nous considérons que vous avez installé l’un de ces kit ainsi que le MDT 2010, 2012 ou 2013 sur un poste de travail (ou un serveur d’atelier technique). Les sources de WinPE (alias client LiteTouch) sont disponibles dans le dossier “Boot” du partage MDT, nommé par défaut “DeploymentShare”.

Note : Pour ceux qui débuteraient avec MDT, sans avoir consulter mes tutoriels précédents :-(, sachez qu’ il n’y a rien dans ce dossier tant que vous n’en avez pas lancé la fabrication. Pour y remédier, démarrez la console “Deployment Workbench“, sélectionnez le nom de votre MDT situé sous la rubrique “Deployement Shares” puis utilisez le choix “Update Deployment Share” via le menu contextuel. Dans l’assistant, cochez éventuellement l’option “Completly regenerate the boot images“

Cliquez 2 fois sur “Next” puis “Finish” (après quelques minutes d’attente…)

C. Modification de l’image WinPE

Là encore, il y a les débutants et les autres… Donc en quelques mots, un noyau WinPE est une image .WIM (plus exactement “\Sources\boot.wim” par défaut) dont le contenu peut être modifié en réalisant préalablement un “montage” vers un dossier vide. Nous allons réaliser cette opération de montage via l’outil DISM présent par défaut depuis Windows 7. Pour les plus allergiques à la ligne de commande, vous pouvez également recourir à l’excellent freeware “GImageX” qui vous pouvez télécharger ici.

Note : N’oubliez pas d’exécuter votre invite de commande ou console Powershell en tant qu’Administrateur.

Nous allons donc préparer une petite structure de travail, puis procéder à la modification du noyau d’un client LiteTouch en procédant comme suit (adaptez les chemins en fonction de votre environnement) :

md D:\CustPE\Mount

md D:\CustPE\Sources

copy \\localhost\DeploymentShare\Boot\LiteTouchPE_x64.wim D:\CustPE\Sources

dism /mount-wim /wimfile:D:\CustPE\Sources\LiteTouchPE_x64.wim /index:1 /mountdir:D:\CustPE\Mount

Résultat affiché :

Outil Gestion et maintenance des images de déploiement
Version : 6.3.9600.17031

Montage de l'image
[==========================100.0%==========================]
L'opération a réussi.

Une fois l’image “montée”, procédez à la copie des 2 binaires “winvnc.exe” et “vnchooks.dll” parmi les sources récupérées ainsi qu’au transfert du fichier “UltraVNC.ini” construit précédemment.

copy D:\CustPE\UltraVNC\UltraVnc_1205_X64\winvnc.exe D:\CustPE\Mount\Windows\System32

copy D:\CustPE\UltraVNC\UltraVnc_1205_X64\vnchooks.dll D:\CustPE\Mount\Windows\System32

copy D:\CustPE\UltraVNC\UltraVnc_1205_X64\ultraVNC.ini D:\CustPE\Mount\Windows\System32

Il existe plusieurs points d’entrée pour déclencher des actions automatiques sous WinPE ou pour un client LiteTouch. Au besoin, reportez-vous à mon article sur le sujet ici (“Présentation-de-WinPE“) . Pour cette démonstration, j’ai retenu la méthode consistant à modifier le fichier “unattend.xml” situé à la racine du noyau, soit “boot.wim“.

Note : Contrairement à un noyau WinPE générique, sur un client LiteTouch le fichier “unattend.xml” existe déjà. Si vous souhaitez exploiter cette fonctionnalité d’accès à distance sur un noyau générique, il faudra vous assurer que le processus d’initialisation interprète le contenu du ce fichier “unattend.xml” en exécutant la commande “wpeinit“.

Les commandes, relativement simples, dont nous avons besoin pourraient être exécutées via l’invite de commande mais l’usage d’un petit script vbs me paressait plus élégant. Je vous propose donc de créer un nouveau fichier de script comme suit :

Notepad D:\CustPE\Mount\LaunchVNC.vbs

Recopiez le contenu suivant :

Set oShell = CreateObject("Wscript.Shell")
oShell.Popup "Demonstration d'usage de VNC sous WinPE",3

' Demarrage de l'agent de service UltraVNC
oShell.Run("X:\windows\system32\winvnc.exe"),0,False

' Desactivation du pare-feu WINPE
oShell.Run("wpeutil disablefirewall"),0,True

' Message facultatif
Set oWMIService = GetObject("winmgmts:\\.")
Set oWMIAdapters = oWMIService.ExecQuery ("Select IPAddress from " &_
  "Win32_NetworkAdapterConfiguration Where IPEnabled = True")
For Each Adapter in oWMIAdapters 
        sIPAddr = Adapter.IPAddress(0)
Next
oShell.Popup "Controle à distance disponible via UltraVNC sur l'adresse " & sIPAddr ,3

Enregistrez les modifications puis quittez le bloc-notes

Note : Ce script affiche des popups de 3 secondes afin de ne pas bloquer le processus en votre absence.

Éditez le fichier d’initialisation “unattend.xml”

Notepad D:\CustPE\Mount\unattend.xml

Et renseignez-le comme suit : (en gras les modifications apportées comparativement à l’original)

<?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>
            <RunSynchronous>
                <RunSynchronousCommand wcm:action="add">
                    <Description>Lancement de VNC</Description>
                    <Order>1</Order>
                    <Path>wscript.exe X:\LaunchVNC.vbs</Path>
                </RunSynchronousCommand>
                <RunSynchronousCommand wcm:action="add">
                    <Description>Lite Touch PE</Description>
                    <Order>2</Order>
                    <Path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</Path>
                </RunSynchronousCommand>
            </RunSynchronous>
        </component>
    </settings>
</unattend>

Enregistrez les modifications puis quittez le bloc-notes

Note : Si vous créez un nouveau fichier, faites bien attention à l’architecture indiquée “amd64” ou “x86“. En effet, en cas de divergence avec le noyau, l’interprétation des directives est tout bonnement ignorée.

Procédez au “démontage de l’image WIM” via la commande suivante:

dism /unmount-wim /mountdir:D:\CustPE\Mount /commit

Résultat affiché :

Outil Gestion et maintenance des images de déploiement
Version : 6.3.9600.17031

Fichier image : C:\CustPE\Sources\LiteTouchPE_x64.wim
Index de l'image : 1
Enregistrement de l'image
[==========================100.0%==========================]
Démontage de l'image
[==========================100.0%==========================]
L'opération a réussi.

 

III. Utilisation du noyau WinPE modifié

Pour utiliser ce noyau WinPE modifié vous devez le réintégrer dans une structure d’amorçage WDS, ISO ou un DVD. En vous reportant à mes différents tutoriels, donc celui concernant la “Dématérialisation des vos supports avec WDS“, vous devriez vous en sortir

A. Via Windows Deployment Services

Exemple : Import d’une image de démarrage sous Windows Deployment Services :

B. Via un support amovible de type USB

Si vous n’avez pas d’infrastructure WDS et qu’une modeste clé USB (mini 512 Mo) sous la main, vous pouvez suivre la procédure suivante :

1. Formatage du support USB

Formatez la clé via “diskmgmt.msc” ou “diskpart” pour les plus aguerris

Diskpart

Diskpart> list Disk
Diskpart> select Disk 2
Diskpart> clean
Diskpart> create part primary
Diskpart> format fs=ntfs quick
Diskpart> active 
Diskpart> assign letter=K:
Diskpart> exit

Faites attention, ne vous trompez pas de cible ! – Lorsque vous taperez la commande “list disk“, vous obtiendrez un résultat du genre :

N° disque Statut Taille Libre Dyn GPT
--------- ------------- ------- ------- --- ---
Disque 0 En ligne 40 G octets 0 octets
Disque 1 En ligne 60 G octets 1024 K octets
Disque 2 En ligne 512 M octets 0 octets

Et il n’y guère d’information autre que la taille, pour vous permettre de localiser votre clé USB. Je vous ai bien dit que “diskpart” n’était pas pour les néophytes, donc si vous avez vraiment des doutes, utilisez la console graphique. Pour les aficionados de la ligne de commande, sachez qu’il y a toujours quelques commandes alambiquées pour identifier vos disques flash USB, comme par exemple sous Powershell :

gwmi -Class win32_logicaldisk | ? { $_.driveType -eq 2 }

ou encore

gwmi win32_diskdrive | ? {$_.interfacetype -eq "USB"}

2. Copie des fichiers d’amorçage

Copiez les fichiers d’amorçage du MDT vers cette clé (selon l’architecture).

xcopy \\localhost\DeploymentShare\Boot\x64\*.* k:\ /e /s

3. Copie du noyau modifié

Créez un dossier “\Sources” puis recopiez le noyau modifié :

md k:\Sources
copy D:\CustPE\Sources\LiteTouchPE_x64.wim k:\Sources\Boot.wim

A ce stade, votre support est prêt à l’emploi.

Note 1 : Pour la réussite de cette démonstration, vous devez disposer d’un environnement DHCP afin que le client obtienne une adresse IP valide.

Note 2 : Attention, vous perdrez ces modifications en cas de régénération des images LiteTouch (cf “Update Deployment Share“.

 

C. Tests du résultat

Pour faciliter l’identification des postes cibles, je vous conseille d’activer le mode “Monitoring” au sein de MDT (2012 et +). Pour cela, il suffit de démarrer la console “Deployment Workbench“, de sélectionner le nom de votre MDT situé sous la rubrique “Deployement Shares” et d’utiliser le menu contextuel “Propriétés“. Allez ensuite sous l’onglet “Monitoring” puis cochez la case “Enable monitoring for this deployement share” et cliquez sur “Appliquer” et “OK” pour valider ce changement.

Démarrez votre poste de test sur l’image LiteTouch modifiée. Vous devriez voir apparaitre furtivement les messages d’information du script puis l’écran d’accueil de l’assistant LiteTouch puis les séquences de taches (Variable selon votre configuration MDT).

A partir de votre machine MDT, lancez la console “Deployment Workbench” puis sélectionnez la rubrique “Monitoring” et appuyez sur [F5] afin d’actualiser l’affichage. Le(s) poste(s) en cours d’installation devrai(ent) apparaitre.

Maintenant, il vous suffit de démarrer le programme “vncviewer.exe” (téléchargé précédemment) puis d’entrer le nom du poste dans la zone “VNC Server”  et cliquez sur le bouton “Connect”

Patientez quelques secondes avant que la connexion soit établie.

Vous pouvez alors surveiller (ou interagir en ouvrant une invite de commande via [F8] par exemple) sur le poste tant qu’il exécute le noyau WinPE, c’est-à-dire jusqu’à ce qu’il effectue son premier redémarrage. (après il sera trop tard  , à moins que vous n’ayez activé le bureau à distance ou vnc sur le poste )

Il y existe assurément d’autres techniques pour parvenir à ce genre de résultat mais je vous assure que celle-ci est fonctionnelle et accessible à tous :-)…

Facultatif : L’un des petits défauts de cette méthode est la perte des modifications lors de la régénération des clients LiteTouch. Pour pallier cette contrainte, sur votre machine MDT, vous devrez remplacer le(s) fichier(s) de modèle de l’ADK ci-après par le fichier “unattend.xml” modifié (32 / 64 bits).

• “C:\Program Files\Microsoft Deployment Toolkit\Templates\Unattend_PE_x64.xml”
• “C:\Program Files\Microsoft Deployment Toolkit\Templates\Unattend_PE_x86.xml”

Vous trouverez des informations sur ce sujet dans le tutoriel “Maîtrise des images de démarrage LTI / WinPE“