PXE sur Linux, Windows, et pourquoi pas les deux ?

I. Présentation

L'idée de ce tutoriel est de vous présenter différentes techniques de mise en œuvre de l'amorçage réseau PXE (Pre-boot eXecution Environment). Pour ne léser personne, j'ai opté pour 2 implémentations distinctes, l'une consistant à installer un PXE sur un NAS de type Busybox (Linux) et l'autre chargé de modifier le mécanisme d'amorçage WDS en y injectant un syslinux.

L'intérêt principal de PXE réside dans le fait qu'il vous affranchit des médias de type CD ou autres clés USB. Toutefois, il peut également engendrer une augmentation significative du trafic réseau et doit donc être implémenté avec parcimonie dans votre environnement. Notez également qu'il n'est pas obligatoire d'implémenter un serveur PXE sur chaque sous-réseau. En effet, pour bénéficier des services PXE dans plusieurs sous-réseaux, il suffit d'agir sur l'option DHCP 66 sur laquelle je reviendrais plus tard.

A. Rappels sur PXE (WDS)

Pour garantir un mécanisme d'amorçage PXE, il est nécessaire d'offrir un adressage IP dynamique aux clients via un serveur BOOTP ou DHCP. Les clients peuvent ensuite télécharger un système d'amorçage via un serveur Trivial FTP (alias TFTP). Le schéma ci-après symbolise les principales étapes de ce processus.

PXE01-img01
Mécanisme d'amorçage PXE sous WDS

Notez que les serveurs DHCP et PXE (dérivé de BOOTP) sont techniquement très proches et utilisent les mêmes ports de communication réseau.(D’où la nécessiter de désactiver l'option d'écoute lorsque le DHCP est présent sur le serveur WDS lui-même).  En présence d'Active Directory, les serveurs WDS doivent être "autorisés" au même titre que les serveurs DHCP.

Concernant PXE, les 2 options DHCP les plus intéressantes sont :

Option 66 : Nom d'hôte du serveur de démarrage - C’est-à-dire l'adresse IP ou le nom du serveur chargé de fournir un système d'amorçage à la machine cliente.

Option 67 : Nom du fichier de démarrage - permet de stipuler le nom du fichier d'amorçage (précédé du chemin éventuel, relatif à la racine TFTP du serveur). - Ne confondez pas l'option 67 avec le port 67, ça n'a rien à voir  🙂

 

II. Mise en œuvre de WinPE/PXE sur un NAS Synology

Si comme moi, vous disposez d'un petit serveur NAS, de type Synology et d'une FreeBox (ou autre boitier d'accès Internet) chargée de distribuer les  adresses IP sur votre réseau local, vous pouvez envisager la solution suivante.

A. Activation du service NFS sur le NAS

Commencez par activer le service NFS sur votre NAS, via le panneau de configuration Synology (DSM4.3) en cliquant sur l'icône ci-dessous :

PXE01-img02
Configuration des partages sur Synology

 

Sélectionnez l'onglet "Service NFS", puis cochez la case "Activez NFS" puis par la même occasion cochez la case "Activer la prise en charge de NFS 4".

PXE01-img03
Configuration de NFS sur Synology

Laissez les autres valeurs par défaut puis cliquez sur le bouton "Appliquer". Acceptez le message vous indiquant que les services réseau vont redémarrer, puis fermez cette page.

 

B. Création d'un partage SMB (Windows) et NFS (Unix)

À partir de l'icône "File Station", créez un nouveau dossier partagé, comme par exemple "PXEBOOT"

PXE01-img04
Nouveau dossier partagé

Cliquez sur le bouton "OK". Cette action doit vous amener sur l'écran de "configuration des privilèges".

PXE01-img05
Configuration des privilèges

Pour simplifier les copies et l'administration par la suite, cochez la case "Lecture/écriture" pour le compte "Admin", puis cliquez sur le bouton "OK".

De retour dans la fenêtre "Panneau de configuration … Dossier partagé", votre nouveau partage doit être sélectionné. Cliquez alors sur le bouton "Privilèges … Privilèges NFS", puis sur le bouton "Créer"

PXE01-img06
Privilèges NFS

Sous la fenêtre "Créer une règle NFS", entrez la/les machine(s) qui auront accès au partage NFS dans le champ "Nom d’hôte ou IP*"

Note : Comme indiqué *, plusieurs syntaxes sont autorisées. Ici, nous avons opté pour la notation CIDR (Classless Inter-Domain Routing), soit le réseau 192.168.0.0 avec un masque de classe C par défaut (255.255.255.0) donc /24

 

Sélectionnez ensuite "Lecture seule" dans la liste du champ "Privilège" et la valeur "Mapper vers guest" dans le champ "Root squash" *

Note : Cette option (de sécurité linux) a pour but d'empêcher un client de devenir root sur le système de fichiers NFS stockés sur le serveur

Cliquez 2 fois sur les boutons "OK" pour valider cette configuration.

 

C. Installation du PXE sur le NAS Synology

Pour cela, il faut procéder au téléchargement puis à la configuration d'un syslinux  (Modules PXE sous Linux). Vous pouvez trouver différents tutoriels sur la toile, comme par exemple en français ici et les sources de syslinux  ici

En gros, il vous faudra principalement modifier le fichier "PXEBOOT\pxelinux.cfg\default" afin qu'il ressemble à ceci :

DEFAULT menu.c32
MENU TITLE PXE Boot Menu de demo
PROMPT 0
TIMEOUT 100
ONTIMEOUT chainlocal

LABEL chainlocal
	MENU LABEL Demarrage sur le disque local
    MENU DEFAULT
	KERNEL chain.c32
	APPEND hd0

LABEL Demarrage sur WinPE generique
   LINUX memdisk
   INITRD ISO/Generic_x86.iso
   APPEND iso raw
  
LABEL Demarrage de CloneZilla
   LINUX memdisk
   INITRD ISO/clonezilla-live-2.4.2-10-i686-pae.iso
   APPEND iso   

Je vous conseille d'effectuer la modification de ce fichier sans extension avec Notepad++ afin d'éviter les effets de bords et de format liés à l'utilisation du Bloc-notes Windows.

 

Et stocker vos images .iso sous le dossier "PXEBOOT\ISO", comme par exemple une image de client LiteTouch ou générique de MDT, une image WinPE de votre cru, une image de réparation WinRE et pourquoi pas une image du logiciel libre Clonezilla - Pour peu que cela soit des images amorçables au format .ISO, ou (WinImage) libre à vous de choisir 🙂

Si vous ne voulez vraiment pas vous casser la tête, vous pouvez télécharger mon exemple prêt à l'emploi :

 

  • Pour la version sans les .ISO, c'est ici (~110Ko)
PXE01-img07
Créer un ISO de WinPE générique avec MDT

Pour CloneZilla, vous trouverez les sources ici, sans oublier de choisir le format ".iso" au niveau de "File Type"

Copiez tous ces fichiers dans le fameux dossier "PXEBOOT" du NAS, créé précédemment.

Dans le panneau de configuration du NAS, cliquez sur l'icône "FTP", puis sélectionnez l'onglet "TFTP / PXE".

PXE01-img08
Configuration de TFTP/PXE et du DHCP

Cochez la case "Activer le service TFTP" puis cliquez sur le premier bouton "Selectionnez" afin de choisir le dossier racine "PXEBOOT".

Cochez la case "Configurer le service DHCP sur ce serveur pour PXE"

A ce moment, il est possible que l'interface vous demande d'installer DHCP Server s'il n'est pas déjà installé. Laissez vous guider par l'assistant Synology, il va très bien s'en charger pour peu que l'accès Internet soit valide.

Cliquez sur le second bouton "Selectionnez" afin de choisir le fichier du chargeur de démarrage, soit "pxelinux.0"

La particularité de cette configuration réside dans la présence de 2 serveurs DHCP sur un même réseau. En effet, dans mon cas, la Freebox assure la distribution standard des adresses IP alors que le NAS fournira le chargeur de démarrage (option DHCP 67).

Dans le champ "Serveur DNS" et "Passerelle" entrez l'adresse de la box. Pour le reste, entrez une petite plage d'adresse IP (celles-ci ne seront pas retenues par le client DHCP)

Ça marche plutôt très bien, mais malgré mon analyse je n'ai pas encore d'explication claire sur ce comportement et j'aurais préféré stipuler explicitement l'option 66 sur le serveur DHCP (Freebox) afin d'indiquer le serveur PXE (NAS). - N'hésitez pas à commenter cet article si vous avez  des informations pertinentes sur le sujet 🙂 

Ensuite cliquez sur le bouton "Appliquer".

D. Test du résultat

À partir d'une machine virtuelle ou physique, démarrer l'ordinateur sur l'amorçage PXE (généralement via [F12]). Après quelques secondes, vous devriez voir apparaître le menu suivant:

PXE01-img09

Voilà, c'est fini pour cet exemple, mais cela devrait marcher pour la plupart des NAS de type Busybox et pour les moins fortunés, je vous conseille la lecture d'un excellent article de Julien Darakdjian sur "Déployer Windows avec un Raspberry Pi". Je vous concède que c'est un peu geek sur les bords, mais j'avoue que pour l'avoir testé, avoir un MDT complet dans le creux de la main pour une petite trentaine d'euros, c'était plutôt plaisant ( kifant pour les plus jeunes 😉 )

 

III. Mise en œuvre de syslinux sur WDS

Pour de nombreuses sociétés, universités ou centres de formation, la solution de déploiement ne se cantonne pas toujours à des machines sous Windows et peut conduire à des choix difficiles. Dans le cadre d'une complémentarité  avec les systèmes d'exploitation tels que Linux, que naturellement Windows Deployment Services ne prend pas en charge, je vous propose une approche alternative,  prétexte à une analyse plus approfondie des mécanismes du chargeur de démarrage WDS ("bootstrap loader").

A. Rappels et précisions sur WDS

Au besoin, reportez-vous à mon tutoriel sur WDS.

En premier lieu, il convient de présenter la structure des dossiers retenue par Microsoft pour son serveur WDS. La racine, dénommée "TFTP Root", est située dans le dossier défini lors de l'installation (ie. "E:\RemoteInstall\" ), mais les clients ont un droit de lecture par défaut uniquement sur les sous-dossiers "boot" et "tmp". Ces réglages sont respectivement stipulés sous la clé de registre  suivante :

"HKLM:\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP"

  • Pour l'emplacement de la racine TFTP via l'entrée [REG_SZ] "RootFolder" =  "E:\RemoteInstall"
  • Pour les droits de lecture des clients PXE via l'entrée [REG_MULTI_SZ] "ReadFilter" = "\boot\* \tmp\* boot\* tmp\*".

Au niveau de la racine TFTP, on distinguera 2 dossiers essentiels :

  • "Boot" : Contient la structure composée principalement des fichiers liés à l'amorçage (Bootstrap Loaders) et des images .WIM de démarrage (Autrement dit, les images système WinPE).
  • "Images" : Contient les images .WIM d'installation (Autrement dit, les distributions Windows préparées avec "sysprep")

 

Dans la structure de dossier "Boot",  il semblerait que Microsoft ait choisi d'utiliser un sous-répertoire propre à chaque plateforme (x86, x64, IA64,arm …), dans lesquels sont stockés les fichiers  d'amorçage (tels que bootmgr.exe , default.bcd, pxeboot.com, wdsnbp.com …)  et un sous-dossier "Images" dans lequel sont placés les images .WIM de WinPE ainsi qu'un fichier ".WIM.bcd" associé.

Sur le plan pratique, il apparait que les fichiers situés dans les dossiers x86 et x64 sont identiques et le répertoire  x86x64 ne contient que le fichier de configuration d'amorçage. En focalisant les actions uniquement sur le dossier x86, je n'ai pas relevé de soucis notables avec des machines x64. Réciproquement, si vous travaillez sur le dossier x64, et adaptez les réglages en conséquence, les résultats devraient être sensiblement les mêmes.

PXE01-img10

Le premier chargeur d'amorçage PXE, nommé "wdsnbp.com" commence par valider l'architecture processeur du client puis, initialise l'amorçage correspondant. En fonction des réglages du serveur la machine peut attendre une confirmation (cf  périphériques en attente)  ou initialiser le chargeur par défaut "pxeboot.com"(son équivalent, le fichier "pxeboot.n12" évite la confirmation du chargement via un second appui sur la touche [F12]). En fonction des images de démarrage disponibles, un éventuel menu est ensuite affiché puis le chargement du noyau WinPE est effectué.

Ce processus peut être modifié au niveau des propriétés du serveur sous l'onglet "Démarrer".

PXE01-img11
Aperçu de l'onglet "Démarrer" sur WDS2012R2

En résumé, sous WDS, le principe d'amorçage standard PXE pourrait schématiquement être représenté comme suit :

PXE01-img12
Enchaînement de l'amorçage sous WDS

 

Note : Sous WDS, les fichiers portant l'extension ".n12" sont équivalents à leurs homologues ".com"  à la différence qu'ils ne demandent pas de confirmation via l'appui de la touche [F12].

B. Mise en œuvre d'un chainage PXE Linux sur WDS

Dans cette démonstration ostensiblement marginale, je souhaitais simplement démontrer qu'il était possible de substituer ce système d'amorçage par un chargeur Linux ayant la possibilité de rendre la main au chargeur WDS initial en cas de besoin.

1. Récupérer un noyau syslinux

Pour modifier le processus d'amorçage précédemment décrit, vous devez préalablement télécharger un noyau "syslinux" tel que la version 4.07 à l'adresse suivante  http://www.kernel.org/pub/linux/utils/boot/syslinux/

Sachant que certains de ces fichiers spéciaux ne portent pas d'extension, pensez à démasquer les extensions de fichiers connus afin d'éviter les confusions, surtout si vous effectuez ces manipulations via l'interface graphique de Windows.

Choisissez l'un des packages proposés,  portant idéalement une extension ".zip" afin de le gérer au sein de l'explorateur Windows. Vous devrez ensuite extraire de cette archive  les 3 fichiers suivants vers le dossier "Boot\x86"  situé sous la racine TFTP du serveur WDS, soit "\RemoteInstall".

  • modules/pxechain.com
  • core/pxelinux.0
  • com32/menu/menu.c32

 

2. Facultatif : Récupérer une distribution Linux

Téléchargez ensuite un noyau d'amorçage réseau Linux comme par exemple celui d'une distribution Ubuntu.

Enregistrez les 2 fichiers "vmlinuz" et "initrd.gz" dans le même dossier "boot\x86" situé sous la racine TFTP du serveur WDS.

Note : Faites bien attention à respecter les extensions. En effet, lors du téléchargement d'un fichier spécial tel que "vmlinuz" une extension ".txt" peut être ajoutée à votre insu via l'explorateur Windows.

 

3. Facultatif : Ajouter un outil de test mémoire

Pour compléter cet exemple, je vous propose d'ajouter le célèbre outil de test mémoire "Memtest86" que vous pouvez télécharger à l'adresse suivante : http://www.memtest.org/download/5.01/memtest86+-5.01.bin

Si vous avez récupéré un fichier au format ".gz", ouvrez cette archive avec "7-Zip" et faites une extraction de l'unique fichier dans ce même dossier "boot/x86" sous la racine TFTP du serveur WDS, puis renommez ce fichier "memtest86" sans extension.

 

4. Préparer les amorces PXE

À partir de l'explorateur Windows ou en ligne de commande, au niveau du sous-dossier "Boot\x86", créez une copie du fichier "pxeboot.n12" et renommez-la en "pxeboot.0". Faites de même pour le fichier "abortpxe.com" que vous renommerez en "abortpxe.0"

Au regard du schéma précédent sur WDS, vous pourriez me reprocher de ne pas prendre en considération le fichier "wdsnbp.com". Ceci est lié au comportement de ce "pré-chargeur" qui redemande une confirmation via [F12] et tourne en boucle sur le menu.

Créez un sous-dossier nommé "pxelinux.cfg" : Un fichier de configuration nommé "Default." (sans extension) doit être stocké dans ce dossier. Tapez les commandes suivantes :

mkdir E:\RemoteInstall\Boot\pxelinux.cfg
echo "" > E:\RemoteInstall\Boot\pxelinux.cfg\default.

Ajoutez le contenu suivant dans ce fichier en prenant garde à ne pas ajouter d'extension erronée.

#
# Fichier de configuration PXE
#
default menu.c32
prompt 0

menu title Demarrage PXE / Installation

label WDS (Services d'installation Windows)
	menu default
	kernel pxeboot.0
	
label Test memoire
	kernel memtest86

label Installation Ubuntu
	kernel vmlinuz
	append initrd=initrd.gz vga=788

label Demarrage sur disque local
	localboot 0

label Linux PXE
  menu label Linux PXE server...
 	kernel pxechain.com
	append 192.168.100.201::pxelinux.0
	# Entrez l'adresse IP du serveur PXE Linux
# append 192.168.100.201::\boot\x86\wdsnbp.com
  	# ou d'un autre serveur WDS "standard"

Label Annuler le boot PXE
	kernel abortpxe.0

A ce stade, le dossier "boot/x86" doit contenir les dossiers/fichiers suivants (surlignés)

PXE01-img13
Nouveau contenu du dossier .\boot\x86

Pour activer la nouvelle amorce sur le noyau PXE linux, entrez les commandes suivantes dans une invite de commande sur le serveur WDS.

 

wdsutil /set-server /bootprogram:boot\x64\pxelinux.0 /architecture:x64
wdsutil /set-server /N12bootprogram:boot\x64\pxelinux.0 /architecture:x64
wdsutil /set-server /bootprogram:boot\x64\pxelinux.0 /architecture:x86
wdsutil /set-server /N12bootprogram:boot\x64\pxelinux.0 /architecture:x86

 

5. Stipuler le fichier de démarrage au niveau des options DHCP

Il ne reste plus qu'à modifier l'option DHCP  stipulant le  fichier d'amorçage. Au niveau de la console du serveur DHCP (sous Windows), développez l'arborescence afin de sélectionner "DHCP … NomDuServeur … IPv4 … Etendue [Nom d'étendue] … Options d'étendue"

Si vous n'avez pas déjà configuré cette option, utilisez le menu "Action … Configurer les options" ou le menu contextuel.  Cochez la case "067  Nom du fichier de démarrage", puis entrez la valeur "Boot\x86\pxelinux.0" dans le champ "Valeur de chaine". Dans le cas contraire, éditez simplement l'option existante afin d'en modifier la valeur.

PXE01-img14
Options d'étendue DHCP (N° 66 et 67)

Pour les accrocs de la ligne de commande, vous pouvez configurer ces options d'étendue sur un DHCP  Windows via les commandes suivantes

 

netsh dhcp server scope 192.168.100.0 set optionvalue 066 STRING 192.168.100.201
netsh dhcp server scope 192.168.100.0 set optionvalue 067 STRING boot\x86\pxelinux.0

Ou via le module DHCP de Powershell depuis Windows Server 2012 😀

Set-DhcpServerv4OptionValue -ScopeId 192.168.100.0 -OptionId 66 -Value "192.168.100.201"
Set-DhcpServerv4OptionValue -ScopeId 192.168.100.0 -OptionId 67 -Value "boot\x86\pxelinux.0"

 

C. Test du résultat

À partir d'une machine virtuelle ou physique, démarrer l'ordinateur sur l'amorçage PXE (généralement via [F12]).

Le résultat devrait ressembler à ceci :

PXE01-img15
Exemple de résultat PXE Linux avec lien vers WDS

Le premier choix aura pour conséquence de poursuivre l'initialisation de l'amorce WDS classique, comme par exemple :

PXE01-img16
Exemple d’enchaînement vers un menu traditionnel de WDS

Voilà, c'est tout pour cette fois. Si vous avez des questions, des remarques ou même des critiques à formuler sur cet article, n'hésitez pas à utiliser les commentaires : cette démarche d'échange est généralement plutôt constructive.

Bien à vous

Christophe


 

IV. Annexe : Mon complément sur les mécanismes DHCP et PXE

1. Démarrage du poste client

2. Le BIOS de la carte réseau initialise le processus PXE et envoie une diffusion générale (broadcast DHCP-Discover) avec l'option #60 (Client Class IDentifier) définie sur "PXEClient"

Note : Si cette option est aussi définie au niveau du serveur DHCP, cela indique que le serveur assure également un service PXE. L'usage de l'option #43 (Vendor Specific) est similaire, mais déconseillé en raison de sa complexité de mise en œuvre.

3. La carte réseau obtient une ou plusieurs propositions d'adresse IP (DHCP_Offer) et choisit celle qui répond à l'option #60 ou à défaut celle du DHCP le plus rapide.

4a. Si ces trames de retour contiennent les options DHCP #66 et #67, la carte réseau utilise directement le contenu de ces options pour communiquer avec le serveur PXE.

4b. Si les options DHCP #66 et #67 ne sont pas spécifiées, alors la carte réseau envoie une nouvelle diffusion générale afin trouver un serveur PXE. Si le serveur PXE n'est pas sur le sous-réseau local, un agent relai (ou iphelper) peut transmettre la demande vers autre serveur DHCP/PXE. Une fois le serveur PXE est contacté, il renvoie l'information au client afin que le client puisse communiquer directement avec le serveur PXE.

5. Si le serveur PXE a pu être contacté, il délivre le bootstrap (NBP) au client

6. La carte réseau charge l'image d'amorçage via TFTP à partir du serveur PXE.

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

22 thoughts on “PXE sur Linux, Windows, et pourquoi pas les deux ?

  • Vraiment très cool cher administrateur.ton site est vraiment très ouvert et génial.Merci a toi!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    Répondre
  • Merci pour cette procédure très claire et précise.

    Juste une question le bootloader on le récupère sur le FTP de Synology ?

    Merci encore pour la qualité de vos tutoriaux.

    Répondre
    • je réponds à ma question : c’est une possibilité parmi d’autres 🙂

      Répondre
  • Perso pour le PXE avec le synology je préfère utilisé Ipxe que PXElinux.

    Car le serveur TFTP de synology ne gère pas la différence entre le / et le \.
    Ce qui oblige à mettre des iso de Winpe plutôt que des version éclaté.

    Merci encore pour le tuto tres sympa
    Et encore plus merci pour le site

    Répondre
  • Salut,

    Bon tuto mais comment gères-tu la problématique du boot UEFI?

    Merci.

    Répondre
  • Bonjour,
    Effectivement, cette solution n’est pas compatible avec UEFI. En fait, l’outil pxechain.com et dérivés ne supporte que les systèmes de type BIOS traditionnels et des outils tels que Syslinux.efi sont incapables (à ma connaissance) de chainer des loader EFI tel que bootmgfw.efi de WinPE/WDS.

    Il existe peut être une solution (autre que pousser des ISO via TFTP) mais je n’ai pas encore eu l’occasion de creuser…
    Donc, le sujet (ou le challenge) reste ouvert à toute proposition 😀
    Bonne chance

    Répondre
  • Pardon juste une erreur dans mon dernier commentaire.
    Je voulais dire comment configurer un WinPE générique pour ensuite pouvoir le mettre sur le miroire et enfin donner le chemin dans le fichier PXE ?

    Répondre
  • Bonjour LRak007,
    Je ne comprend pas ce commentaire (Je ne trouve pas non plus le « dernier commentaire » cité). Une confusion entre 2 article peut être ?
    Merci d’avance pour les éventuels compléments sur cette question.

    Répondre
  • Bonjour,
    Je suis navrée de commenter un article 2015.
    Je cherche à mettre en place un boot PXE dont le menu serait de lancer une session TSE directement sans passer par la session « locale » quand j’allume le pc.
    Mes connaissances sont limitées dans l’écriture d’un tel fichier de configuration en revanche avec les diverses explication jai réussi à mettre en place mon boot PXE, il ne me resterait uniquement à trouver le bon menu pour lancer directement mon bureau à distance.

    Je vous remercie par avance,

    Répondre
    • Bonjour Laetitia,
      Il n’est jamais trop tard pour poster un commentaire (sur mes articles 🙂 ) – En revanche, la question m’interpelle quelque peu et je ne suis pas sur d’avoir compris la finalité (quoique j’en ai une vague idée 🙂 ).
      Bien, c’est plutôt hors sujet et « borderline » en terme de solution, mais ça ne m’apparait pas impossible. (cf mes articles sur WinPE – « CustPE » et https://www.it-connect.fr/presentation-de-winpe/)
      Personnellement, je procéderais comme suit :
      En 1er, modifier un noyau WinPE en lui ajoutant MSTSC.exe et mstscax.dll et leur déclinaisons de langue .mui (récupérés à partir d’un OS de même version et architecture CPU) et un Winpeshl.ini pour automatiser le lancement (cf Exemple en anglais sur http://www.iammacgyver.com/2011/02/easy-rdp-60-from-winpe-30-simple-boot.html)
      Ensuite, il suffit d’ajouter ce noyau WinPE modifié dans les images de démarrage d’un serveur WDS.
      Ca marche avec un WinPE3 sous Windows 7, mais sous Windows 10 ça semble être plus compliqué … Cela étant dit, dans ce cas, c’est le client RDP qui importe.
      Bonne continuation

      Répondre
  • Bonjour,
    Je débutes donc veuillez m’excuser et je vous remercie de vos éclaircissements par avance.

    Situation :
    J’ai un server DHCP sous Debian qui est très bien fonctionnel.
    J’ai actuellement mise en place un serveur de déploiement sous sccm v1710 avec tous les configurations adéquate réalisé de façon pro (débutant). Il me reste que cette configuration au sujet des options de renseignements d’amorçage PXE sur le server dhcp pour mes clients lors d’un éventuel requête PXE.
    J’ai pas envie d’avoir un second server DHCP test sous Windows (on ne cède pas à la facilité quand on peut faire compliqué).

    Questions:
    Est-il possible de configuré les options (060, 066, 067 : le client pxe, le server de point de distribution pxe ainsi que le répertoire des images de démarrage) pour l’amorçage du boot PXE dans mon dhcp actuel ?
    Si oui, comment se déclarent-ils ces options dans mon étendue dhcp sous linux ?
    Sinon, autres suggestions svp sans ayant recours à windob. merci

    Répondre
  • Bonsoir,
    Désolé pour la réponse tardive, un peu surbooké en ce moment 🙁
    Coté Linux, je ne suis pas vraiment spécialisé mais de mémoire, il n’y a rien à préciser si le DHCP Linux et le WDS sont sur le même réseau. (le protocole DHCP s’en charge, ce que j’ai « tenté » d’expliquer dans l’annexe de cet article). Il faut simplement cocher l’option pour que le WDS n’écoute pas sur le port 67 (attention je parle du port, pas de l’option 67 🙂 ) et lui déclarer l’option 060.
    En revanche, s’il y a un agent relai DHCP et que les serveurs DHCP Linux et le WDS sont sur des réseaux différents, ce sera surement plus « touchy ».
    Perso, j’ajouterais les options 66 et 67 dans le /etc/dhcp/dhcpd.conf mais la question est peut être à soumettre sur le forum ?
    Bon courage

    Répondre
  • Bonjour,
    Merci beaucoup pour ce tuto.
    Mais je n’arrive pas à le faire fonctionner. Quand je choisir le WDS, comme sur l’image de la partie C « test du résultat », ça mouline quelques secondes et après j’ai un écran d’erreur concernant \boot\BCD…
    Pouvez-vous m’aider?
    Pour info, j’avais déjà mon WDS fonctionnel pour faire booter séparément mes linux ou windows, que ce soit en bios ou uefi.
    Merci

    Répondre
  • bonjour,
    Avez-vous une solution pour le même système en uefi?
    Merci d’avance!

    Répondre
    • Bonjour Max,
      L’article date un peu mais surtout je ne suis pas sur d’avoir compris les questions (dixit « j’avais déjà mon WDS fonctionnel … soit en bios ou uefi.) – En fait, il existe probablement plusieurs moyens de « détourner » un amorçage PXE pour lequel il convient de distinguer le fournisseur de service (au sens DHCP) de celui du chargeur (au sens TFTP / Fichier Bootstrap) – Sous WDS, c’est le fichier wdsnbp.com (Bootstrap BIOS) qui détecte l’architecture et charge ensuite l’amorce la plus appropriée. Dans cet exemple, le fait de substituer ce fichier par un noyau PXELinux.0 implique qu’il n’y a plus cette distinction (Architecture CPU, ni BIOS/UEFI).
      Je pense qu’il est possible d’agir sur l’option DHCP 67 afin de définir un chargeur à utiliser (x86|x64\wdsmgfw.efi, x86|x64\wdsnbp) mais je n’ai pas la solution pour proposer ce genre de menu avec de tels choix. S’il n’y a pas de besoin d’installer d’autres plateformes que Windows, il est préférable de conserver / ou ajuster les mécanismes Microsoft.
      Exemple Config DHCP UEFI
      Bonne continuation

      Répondre
      • bonjour je voulais savoir si c’etait possible d’avoir un nouveau lien pour télécharger le cd winpe déja fait tout compiler le lien one drive est mort merci d’avance pour votre réponse.

        Amicalement ,

        Kevin

        Répondre
        • Bonjour Kevin,
          J’ai mis à jour les liens OneDrive, ça devrait fonctionner
          Bonne continuation

          Répondre
  • bonjour ,
    Je suis debutant , et voila je ne suis pas sur d’avoir bien compris le but du tutoriel . Je m’explique je pensais que grace a votre tutoriel nous allions pouvoir déploiyer une image linux par notre serveur wds . Je me suis tromper ? Est ce possible de faire ceci ? j’ai un doute car a un moment donner on renseigne l’adresse ip de notre serveur linux , alors que moi je ne veux pas avoir de serveur linux . Part ailleur on renseigne aussi a un moment dans un invit de cmd plusieurs ligne de commande en donnant le chemin vers /x64 alors que la plupart des manip precedante ce font dans le dossier /X86 . Est ce une erreur ? Je suis désoler pour les multiples fautes d’ortographe .Le tuto est tres bien rédiger je pense que c de mon coter que je n’ai pas du bien comprendre
    cordialement

    Répondre
  • Pour ceux qui font des test ne pas oublier de faire un backup avant de modifier le démarrage

    wdsutil /get-server /Show:All > backup.wds.txt

    Répondre

Répondre à max Annuler la réponse

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.