Présentation de WinPE

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"

WPE01-img01
Schéma du processus d'amorçage

 

B. Structure de WinPE

La structure d'un noyau WinPE et plus globalement des éléments qui l'entourent est particulièrement complexe et un néophyte peut rapidement y perdre son latin. Afin de se repérer plus facilement, entre les composants, les pilotes de périphériques, les commandes internes et l'outillage de fabrication, j'ai imaginé le schéma suivant :

WPE01-img02

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 🙂 )

WPE01-img03
Schéma de principe d'une initialisation WinPE

Explications :

Le point d'entrée clé de WinPE est le programme d'initialisation "winpeshl.exe" situé dans le dossier "X:\Windows\System32". Celui-ci est référencé dans la clé de registre "HKEY_LOCAL_MACHINE\SYSTEM\Setup" au sein de la valeur "cmdline= winpeshl.exe"

Une fois ce programme lancé, vous bénéficiez de la séquence de touches [Maj] + [F10] pour ouvrir une invite de commande à tout instant.

Ce programme vérifie ensuite la présence d'un fichier "winpeshl.ini" situé dans le dossier "X:\Windows\System32". Si celui-ci existe, il exécute séquentiellement les commandes qu'il contient. On peut y trouver les rubriques suivantes

[LaunchApp]
AppPath =

Pour l'exécution d'un programme unique sans paramètre :

[LaunchApps]
Application1.exe, option1, option2
Application2.exe, option1

Pour l'exécution de un ou plusieurs programme(s) avec ou sans paramètre(s)

Voici quelques exemples typiques de fichier "winpeshl.ini"

  • 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".

WPE01-img04
Setup et WDS : Ecran d'accueil typiquement affiché

Si le fichier "X:\Setup.exe" n'existe pas, c'est alors le batch "Startnet.cmd" situé dans le dossier "X:\Windows\System32", qui est exécuté. Par défaut, ce fichier existe dans tous les noyaux WinPE et ne contient que la commande "wpeinit ".

Ce batch est modifiable, pour y inclure toute sorte de commandes dont vous auriez besoin. Il est toutefois important de relever que l'exécution de "wpeinit " permet d'exploiter le contenu d'un fichier "X:\unattend.xml", voire de stipuler un fichier de configuration spécifique "wpeinit /unattend:X:\CustomWinPE.xml".

Astuce : Pour initialiser uniquement les couches réseau, utilisez la commande "wpeutil InitializeNetwork"

La suppression du fichier "Startnet.cmd" engendre une erreur, mais dans tous les cas  l'exécution se termine sur une invite de commande.

Note: Pour le débogage, il est intéressant de savoir que l'exécution des programmes Winpeshl.exe et Wpeutil.exe génèrent leur journal respectif : "Winpeshl.log" et "Wpeutil.log"

La gestion et la création des fichiers de réponse .XML peut être réalisée via l'outil "Windows Image System Manager" (WISM) apporté par les kits WAIK ou ADK, mais l'usage peut s'avérer très vite déconcertant. Aussi, l'utilisation du bloc-notes à partir d'un modèle ou d'un exemple sera plus rapide à mettre en œuvre. J'attire toutefois votre attention sur le fait qu'il faut impérativement respecter l'architecture stipulée ("amd64" ou "x86"), sous peine que le fichier .xml ne soit pas traité.

Exemple de fichier .xml :

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="windowsPE">
        <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
            <Display>
                <ColorDepth>32</ColorDepth>
                <HorizontalResolution>1024</HorizontalResolution>
                <RefreshRate>60</RefreshRate>
                <VerticalResolution>768</VerticalResolution>
            </Display>
        </component>
    </settings>
</unattend>

 

V. Conclusion

Véritable pierre angulaire des solutions de déploiement, WinPE constitue un extraordinaire socle d'outils pour la maintenance et le déploiement Windows. Au fil de mes articles, vous découvrirez sa richesse et son extraordinaire potentiel.

Bien à vous

Christophe

A suivre : Personnalisation de WinPE

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Christophe Mandin

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

Nombre de posts de cet auteur : 32.Voir tous les posts

12 thoughts on “Présentation de WinPE

  • Bonjour,

    Je dois faire un script qui doit se lancer via startnet
    Ce script doit me permettre de poser des questions pour préparer un disque en mode intéractif (avec diskpart) pour ensuite proposer l’installation de plusieurs OS (WIN7/8/10). Toute ceci sur une machine virtuel sous VMware.

    Je ne sais pas comment m’y prendre avec Win PE 10. Mon Win PE doit se trouver sur une clé USB. Les ISO des OS sur cette même clé mais je vois pas comment lancer le choix de l’installation des OS après avoir préparer le HDD

    Tout doit se passer par Batch et non fichier xml

    Merci d’avance pour votre aide.

    Répondre
  • Bonjour,
    Il m’est difficile de répondre à cette question complexe sans m’éloigner du sujet de l’article. Si vous souhaitez utiliser du batch, via startnet, il faudra travailler sur les images WIM (pas d’iSO) à l’instar de ce que l’on trouve sur un DVD original. Soit « install.wim » pour les OS et « Boot.wim » pour l’amorce WinPE.
    L’usage de Diskpart supporte un fichier de réponse « /s » qui peut contenir les commandes et on peut envisager d’ajouter une commande du genre « DISKPART /s x:\diskprep.txt » dans startnet.cmd. Pour le choix de l’OS, c’est plus complexe car il faudra passer par des commandes du genre DISM ou Imagex /Apply … Normalement, le partitionnement et le choix d’OS sont dans le fichier unattend.xml, et on peut imaginer de faire des déclinaisons et lancer via un menu choice, différentes commandes « X:\Sources\Setup /unattend:fichierOS1.xml », etc…
    Bref, c’est loin d’être facile il y a bcp de travail de développement et de mise au point.
    A votre place, j’opterais pour la fabrication d’un « media LTI » via MDT qui me parait plus simple et évolutif, mais ce choix vous appartient 🙂 .
    Bon courage

    Répondre
  • Bonjour Christophe,

    Félicitation pour cet article très complet sur winpe. Je me pose cependant une question à laquelle tu pourras peut-être répondre, est-il possible lors du custom de l’image d’intégrer des programmes spécifique ? Je m’explique, je souhaiterais implémenter à l’image ces fichiers :
    Windows\System32\iscsicli.exe
    Windows\System32\iscsicpl.dll
    Windows\System32\iscsicpl.exe
    Windows\System32\iscsidsc.dll
    Windows\System32\iscsied.dll
    Windows\System32\iscsiexe.dll
    Windows\System32\iscsilog.dll
    Windows\System32\iscsium.dll
    Windows\System32\iscsiwmi.dll
    Windows\System32\en-us\iscsicli.exe.mui
    Windows\System32\en-us\iscsicpl.dll.mui
    Windows\System32\en-us\iscsicpl.exe.mui
    Windows\System32\en-us\iscsidsc.dll.mui
    Windows\System32\en-us\iscsiexe.dll.mui
    Windows\System32\en-us\iscsilog.dll.mui

    Pourrais-tu m’aiguiller sur leurs implémentations ?
    par avance merci

    Répondre
  • Bonjour,
    Pour intégrer des fichiers à une image WIM, typiquement un noyau WinPE, il suffit de « monter » l’image via DISM, copier les fichiers vers ce point d’ancrage puis démonter l’image en validant les modifications (/commit).
    Pour modifier un noyau WinPE/LTI, on peut également passer par le MDT, cf http://www.it-connect.fr/custpe-comment-installer-vos-propres-outils-dans-winpe/ en modifiant le template de fabrication ou plus globalement http://www.it-connect.fr/personnalisation-de-winpe/
    Je présente plusieurs techniques qui pourraient convenir, dans la série d’articles « Cust-PE ».
    Cordialement

    Répondre
  • Bonjour, lors du démarrage d’un poste sous Windows 10 je me retrouve avec le message d’erreur suivant : « Windows PE ne peut pas démarrer car le répertoire SYSTEMROOT réel (X:\windows) est différent du répertoire configuré (X:\$windows.~bt\Windows).
    Cette configuration peut s’effectuer à partir de dism.exe avec la commande /set-targetpath.
    Pour plus de détails, consultez la documentation. Appuyez sur le bouton OK ou fermez ce message pour redémarrer. »

    Je suis totalement bloqué dans mon projet et cela devient urgent.
    Je vous remercie par avance de votre aide.

    Répondre
    • Bonjour,
      Pour ce genre de question il vaudrait mieux passer par le forum.
      Ce symptôme fait suite à des manipulations particulières ? Est-ce que le poste fonctionnait avant ? Est-ce consécutif à une tentative de réparation ?
      A mon avis, il faudrait essayer de réparer l’amorçage en démarrant sur un WinPE (Clé usb ou CD), puis après avoir repéré les partitions, de taper bcdboot c:\Windows /s s: (mais il faut jouer un peu avec mountvol ou diskpart avant ? )
      Sinon, essaye de booter sur un CD Windows et d’utiliser les options de réparation (proposées au niveau de l’écran d’install…)

      Bon courage

      Répondre
  • Bonjour Christophe,

    Bien avancé dans mon serveur de déploiement, je cherche à connaitre en ligne de commande PE la façon de savoir sur quel partage de déploiement je suis connecté, j’ai appliqué la réplication DFS sur 7 sites distants avec les autorisations qui vont bien mais j’ai l’impression qu’un partage spécifique ne va pas au bon endroit d’où risque de blindage du réseau…
    Comment le connaitre au moment du WinPE pour être sûr que c’es le bon ? (En ligne de commande ou autre).

    Merci d’avance pour ta réponse, tes posts sont toujours de bons conseils.
    Dominique.

    Répondre
    • Bonjour Dominique,
      J’ignore les détails de la config DFS, peu utilisé avec MDT on utilise plutot des « Linked Deployment Shares » mais selon moi, le client DFS est intégré au client réseau du WinPE. Autrement dit, pour afficher les connexions dans le client LTI, il suffit d’ouvrir une invite via [F8] puis d’utiliser des commandes traditionnelles telles que « net use », « ipconfig »,  » tracert… », « ping -a … ».
      Pour rappel, la ressource de déploiement est définie dans la variable MDT %DEPLOYROOT% mais on peut aussi la voir via type x:\deploy\Scripts\Bootstrap.ini.
      Tout le MDT s’appuie sur cette racine, donc pas de raison d’aller ailleurs (du moins dans la logique MDT) – Il est possible d’ajouter une tache dans la TS pour afficher des variables MDT via un bout de code vbs comme par exemple
      Set env = CreateObject("Microsoft.SMS.TSEnvironment")
      ' Affiche la variable DEPLOYROOT
      WScript.Echo "DEPLOYROOT = " & env("DEPLOYROOT")
      ' Affiche TOUTES les variables
      'For each mdtvar in env.GetVariables
      'WScript.Echo mdtvar & " = " & env(mdtvar)
      'Next

      Sinon, pour pousser les diags plus loin, il faut installer Powershell ou des outils d’analyse réseau dans le noyau WinPE.
      Bonne continuation

      Répondre
      • Bonjour Christophe,
        Merci beaucoup pour ta réponse, j’ai utilisé ce tuto magique : « https://docs.microsoft.com/fr-fr/windows/deployment/deploy-windows-mdt/build-a-distributed-environment-for-windows-10-deployment » car les LDS ne se répliquent qu’a la demande, le DFS lui est répliqué en temps réel, les reconnaissances d’@IP sur les Gateway fonctionnent très bien, c’est juste que je cherche à indiquer lors du déploiement le site de partage pour contrôle au cas où.
        J’ai trouvé comment le faire en F8 PE avec une requête WMIC : wmic logicaldisk z: get providername fonctionne et me renvoi le chemin UNC du site, ok, je l’ai aussi intégré dans mes logs avec une boucle FOR qui me le met en variable, ca c’est OK, mais je bute sur comment le faire apparaitre dans le cheminement des fenêtres PE, genre dans le résumé, ce serait formidable.
        Voilà, c’est juste pour essayer de faire encore mieux, merci pour ton aide.
        Dominique.

        Répondre
      • Bonjour Christophe,
        Merci beaucoup pour ta réponse, j’ai utilisé ce tuto magique : « https://docs.microsoft.com/fr-fr/windows/deployment/deploy-windows-mdt/build-a-distributed-environment-for-windows-10-deployment » car les LDS ne se répliquent qu’a la demande, le DFS lui est répliqué en temps réel, les reconnaissances d’@IP sur les Gateway fonctionnent très bien, c’est juste que je cherche à indiquer lors du déploiement le site de partage pour contrôle au cas où.
        J’ai trouvé comment le faire en F8 PE avec une requête WMIC : wmic logicaldisk z: get providername fonctionne et me renvoi le chemin UNC du site, ok, je l’ai aussi intégré dans mes logs avec une boucle FOR qui me le met en variable, ca c’est OK, mais je bute sur comment le faire apparaitre dans le cheminement des fenêtres PE, genre dans le résumé ou un popup en powershell (bonne idée) indiquant le site d’installation, ce serait formidable.
        Voilà, c’est juste pour essayer de faire encore mieux, merci pour ton aide.
        Dominique.

        Répondre
        • Bonjour Dominique,
          Pour moi, il y a plusieurs approches possibles, dont ajouter une tache d’execution d’un script dans la TS (cscript.exe « %SCRIPTROOT%\MonScript.vbs ») pour afficher l’info dans un popup et éventuellement définir une variable.
          Exemple perfectible en vbs (affiche seul)

          On Error Resume Next
          strComputer = "."
          Set objWMIService = GetObject ("winmgmts:\\" & strComputer & "\root\cimv2")
          Set colItems = objWMIService.ExecQuery ("Select * from Win32_LogicalDisk")

          For Each objItem in colItems
          if objItem.Name="Z:" then strUNC = objItem.ProviderName
          Next
          if len(strUNC) > 0 then
          msgbox "Chemin UNC du lecteur Z: = " & strUNC, 64, "Information"
          else
          msgbox "Aucun lecteur Z: trouvE...", 16, "Erreur"
          end if

          exemple en Powershell 😉

          $SMSTSEnv = New-Object -ComObject Microsoft.SMS.TSEnvironment -ErrorAction SilentlyContinue
          try {
          $DeployrootProv = ( Get-WmiObject Win32_LogicalDisk | where { $_.Name -eq 'Z:' } ).Providername
          $SMSTSEnv.Value("UNCPath")=$DeployrootProv
          $popup = (New-Object -ComObject wscript.shell).Popup("Path Z = $DeployrootProv",5,"Info",64)
          }
          catch {
          $popup = (New-Object -ComObject wscript.shell).Popup("$_",5,"Erreur",16)
          }

          Bon je n’ai pas testé ces scripts faute de temps, mais en « théorie » ça devrait marcher 😀 …
          Bonne continuation

          Répondre
  • Bonjour Christophe,
    Merci beaucoup pour ta réponse, j’ai utilisé ce tuto magique : « https://docs.microsoft.com/fr-fr/windows/deployment/deploy-windows-mdt/build-a-distributed-environment-for-windows-10-deployment » car les LDS ne se répliquent qu’a la demande, le DFS lui est répliqué en temps réel, les reconnaissances d’@IP sur les Gateway fonctionnent très bien, c’est juste que je cherche à indiquer lors du déploiement le site de partage pour contrôle au cas où.
    J’ai trouvé comment le faire en F8 PE avec une requête WMIC : wmic logicaldisk z: get providername fonctionne et me renvoi le chemin UNC du site, ok, je l’ai aussi intégré dans mes logs avec une boucle FOR qui me le met en variable, ca c’est OK, mais je bute sur comment le faire apparaitre dans le cheminement des fenêtres PE, genre dans le résumé, ce serait formidable.
    Voilà, c’est juste pour essayer de faire encore mieux, merci pour ton aide.
    Dominique.

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.