Netz-Weise Logo

Weisheiten - der Netz-Weise Blog

Hier finden Sie Tipps und Tricks für vor, während und nach der Schulung.

DHCP-Proxy, WDS-Server, DHCP-Option 60,66 und 67 und was das mit PXE-Boot zu tun hat

Über wenig Dinge liest man so viel falsches wie über den PXE-Netzwerkboot und wie man den DHCP-Server korrekt konfigurieren muss, um einen Computer aus dem Netzwerk zu starten. Für die ungeduldigen hier zuerst die Konfiguration, die Erklärung folgt danach.

Richten Sie einen DHCP-Server ein. Installieren Sie den WDS-Server auf dem DHCP-Server und lassen Sie den WDS-Server die Konfigurationsarbeit auf dem DHCP-Server erledigen. Der WDS-Server wird dann auf dem DHCP-Server selbständig die Option 60 (PXE-Client) setzen. Wenn Sie den WDS-Server auf einem separaten Server installieren, müssen Sie _NICHTS_ weiter tun. Sie müssen auf dem DHCP-Server weder die Option 60 setzen, noch die Option 66 (TFPT-Server) und 67 (Bootfile). Wenn der WDS-Server und die zu installierenden Clients sich nicht im gleichen Netz befinden, muß der WDS-Server allerdings wie ein DHCP-Server im DHCP-Relay-Agent oder bei Cisco als IP-Helper konfiguiert sein. Der Client findet den WDS-Server dann von selbst und bootet aus dem Netzwerk. Tut er das nicht, liegt es nicht an den DHCP-Optionen!

Was genau passiert beim DHCP-Boot?

Wenn Sie einen Computer über das Netzwerk booten möchten, benötigen Sie einen DHCP-Server und einen TFPT-Server. TFPT ist das Trivial File Transfer Protocol, das im Gegensatz zu FTP Daten per UDP überträgt und ohne Authentifizierung funktioniert. Wenn ein Client einen PXE-Boot initialisiert, schickt er einen DHCP-Request ins Netzwerk, zusammen mit der Information, dass er per PXE booten möchten. Der DHCP-Request wird, wenn er einen DHCP-Server erreicht, mit einem DHCP-Offer beantwortet. Die Antwort beinhaltet die angebotene IP-Adresse, sowie weitere DHCP-Optionen. Prinzipiell kann der DHCP-Server über die Option 66 und 67 dem Client auch einen Bootserver sowie ein Bootfile mitschicken, und das wird auch funktionieren, ist aber nicht notwendig und verursacht zusätzlichen Konfigurationsaufwand. Denn der WDS-Server fungiert als DHCP-Proxy. Das bedeutet, dass er die Anfrage des PXE-Clients ebenfalls beanwortet, allerdings schickt er keine IP-Adresse zurück, sondern nur die Option 66 und 67 mit den Bootfiles, die er zur Verfügung stellt. Das Bootfile ermittelt er selbständig aus seiner Konfiguration. Wichtig ist nur, dass der DHCP-Request beim WDS-Server ankommt. Da der DHCP-Request als Broadcast vom Client verschickt wird, muß die Anfrage also, sofern der WDS-Server nicht im gleichen Netzwerk steht wie der Client, ein DHCP-Weiterleitungsdienst wie der IP-Helper auf dem Router das Datenpaket per Unicast an den WDS-Server weiterleiten. Der WDS wird also genauso auf dem IP-Helper eingetragen wie der DHCP-Server selbst.
Die Option 60, die der WDS-Server bei einer gleichzeitigen Installation im IP-Scope des DHCP-Servers setzt, hat eine andere Funktion. Der DHCP-Proxy funktioniert nämlich wie der DHCP-Server und nutzt auch den gleichen Port ( UDP 67). Wenn der WDS und der DHCP auf dem gleichen Server laufen, muß der WDS-Server einen anderen Port verwenden. Er verwendet dann UDP-Port 4011. Damit der Client auch auf Port 4011 hört und die Konfiguration des DHCP-Proxys akzeptiert, wird die Option 60 vom DHCP-Server gesetzt.

Sollte Ihr Client trotz allem nicht vom WDS-Server booten, kann diese eine andere Ursache haben.  Lesen Sie dafür auch den Artikel "Der PXE-Client startet nicht von WDS-Server - No UEFI-compatible file system found"

Weiterlesen
Markiert in:
  34784 Aufrufe

Der PXE-Client startet nicht von WDS-Server - No UEFI-compatible file system found

Gestern bin ich auf ein merkwürdiges Phänomen gestossen. Nach der Installation eines WDS-Server (Windows Deployment Server) wollte der UEFI-PXE Boot nicht funktionieren. Das BIOS gab nur eine Meldung "TFTP-Error" und "No UEFI-compatible File system was found" aus. Der Boot per Legacy-Boot funktionerte aber einwandfrei. Nach einigem Hin- und her habe ich vor Verzweifelung Wireshark installiert. Untenstehend ein beispielhafter Mitschnitt:

 

Man sieht hier sehr schön, wie der Client eine IP-Adresse angeboten bekommt und auch annimmt (DHCP Ack). Danach startet der Client einen Read-Request per TFTP auf das Boot-File wdsmgfw.efi, das vom Server mit einer File Not Found Fehlermeldung beantwortet wird. Auf unserem Firmeneigenen WDS-Server ist das File vorhanden, wie ich nach kurzer Kontrolle feststellen konnte. Eine kurze Google-Recherche bestätigte dann die Vermutung - das File ist bei der Installation nicht in den Boot-Ordner kopiert worden, wo es aber hätte sein müssen. Ich habe das Phänomen noch nicht bis zum Ende verfolgt, aber ich vermute, der Fehler tritt bei einer Windows Server 2016 RTM-Installation auf.

Um das Problem zu lösen, müssen Sie nur die Datei wdsmgfw.efi in den Ordner "RemoteInstall\Boot\x64" Ihres WDS-Servers kopieren. Sie finden Sie unter %windir%\System32\RemInst\boot\x64\wdsmgfw.efi

Markiert in:
  10402 Aufrufe

MDT: Sysprep und Catpure zeigt das Register "Capture Image" nicht an und der Task schlägt fehl

Das Microsoft Deyployment Toolkit 2013 hat in der aktuellen Version 8443 einen Bug, der die Tasksequenz "Sysprep and Capture" funtionsunfähig macht. Leider hat Microsoft den Bug bisher nicht durch eine aktualisierte Version bereinigt. Man kann sich aber schnell selbst behelfen, denn es handelt sich um fehlerhaften VBS-Code in der Datei ZTIUtility.vbs im Ordner Scripts im Root des Deployment-Shares. Ersetzen Sie in Zeile 3327 den Code 

If (oTS.SelectSingleNode("//step[@type='BDD_InstallOS']") is nothing) and (oTS.SelectSingleNode("//step[@type='BDD_UpgradeOS']") is nothing) then

durch

if (oTS.SelectSingleNode("//step[@type='BDD_InstallOS' and @disable='false']") is nothing) and (oTS.SelectSingleNode("//step[@type='BDD_UpgradeOS' and @disable='false']") is nothing) then

Danach sollte die Tasksequenz problemlos durchlaufen.

Links
https://community.spiceworks.com/topic/1924854-mdt-8443-sysprep-capture-task-not-working

  4537 Aufrufe