WDS - Fehler: Kein Bootfile

[Chreaterdeluxe 0]

Gerät:

Produkt-ID: Fujitsu Esprimo P910  Model-ID:M15W

 

Habe grade das gleiche an einem andren Rechner (HP ProDesk) versucht, leider auch kein Erfolg...

 

Windows-Updates habe ich die Wichtigen installiert, die optionalen ergänz ich gerade.

 

Eine Boot.wim aus einem WIN10 Image ist als Startabbild hinterlegt.

 

EDIT

vor 1 Stunde schrieb MurdocX:

Nächste vorgeschlagenen Schritte:

- WDS - Rolle entfernen, Installationsreste entfernen und wieder hinzufügen

- Troubleshooting auf Paketbasis

Kannst du mir sagen welche Installationsreste und wie ich Troubelshooting auf Paketbasis mache?

 

Updates haben keine Veränderung gebracht.

VG

bearbeitet 27. September 2019 von Chreaterdeluxe

[MurdocX 949]

vor 45 Minuten schrieb Chreaterdeluxe:

Kannst du mir sagen welche Installationsreste und wie ich Troubelshooting auf Paketbasis mache?

Den Ordner RemoteInstall der bei der Konfiguration erstellt wird.

 

Troubleshooting auf Paketbasis wird ein bisschen mehr arbeit. Versuchen wir es erst mal mit einigen bekannten Workarounds. 

bearbeitet 27. September 2019 von MurdocX

[Chreaterdeluxe 0]

OK, mach ich direkt, ich melde mich wenn ich den Dienst neu aufgesetzt habe.

 

VG

Also Dienst ist neu aufgesetzt. Hab die Einstellungen vom TFTP ebenfalls wieder übernommen.

Beide Rechner neu gestartet, keine Veränderung...

 

VG

 

[MurdocX 949]

Ich habe die Installation bei mir nachgestellt. Dabei kam raus, das der Ordner C:\Windows\System32\RemInst\boot einen anderen Inhalt hat, als der erstelle Ordner von der Installation. Das ist ein Fehler.

 

Kopiere den Inhalt von C:\Windows\System32\RemInst\boot in dein RemoteInstall Verzeichnis und ersetze die Dateien.

[Chreaterdeluxe 0]

Habe den Ordner rüber kopiert und den Dienst neu gestartet, keine Veränderung.

[MurdocX 949]

Lade und installiere auf dem WDS-Server das Tool "Microsoft Message Analyser" herunter. Starte über "Start Local Trace" eine Sitzung. Lasse den Client in den Fehler rennen und beende die Session. Danach kannst du über den Filter "*address=<IpDesClients>" Filtern. Wichtig ist hierbei auf das Protokoll "TFTP" zu achten. Schick bitte mal ein Screenshot der Ergebnisse hier ins Forum.

[Chreaterdeluxe 0]

vor 37 Minuten schrieb MurdocX:

Lade und installiere auf dem WDS-Server das Tool "Microsoft Message Analyser" herunter. Starte über "Start Local Trace" eine Sitzung. Lasse den Client in den Fehler rennen und beende die Session. Danach kannst du über den Filter "*address=<IpDesClients>" Filtern. Wichtig ist hierbei auf das Protokoll "TFTP" zu achten. Schick bitte mal ein Screenshot der Ergebnisse hier ins Forum.

Kurze Frage zum Tool, wenn ich eine neue Session starte, nehme ich als Source Live Trace oder Event logs? Und welche Optionen jeweils?

[MurdocX 949]

vor 1 Minute schrieb Chreaterdeluxe:

Kurze Frage zum Tool, wenn ich eine neue Session starte, nehme ich als Source Live Trace oder Event logs? Und welche Optionen jeweils?

Live trace, denn in den Logs werden wir nichts finden  

 

Hier interessieren die zwei ersten UDP-Pakete und die ersten TFTP-Pakete. Als Filter kann man übrigens folgendes eingeben:

address == <ClientIP> and address == <ServerIP>

Damit reduzierst du die Paketanzahl sehr.

bearbeitet 27. September 2019 von MurdocX

[Chreaterdeluxe 0]

Okay, und welche System Providers nehme ich da mit? Nur Micosoft-Windows-Deploment-Service-Diagnostics? 

[MurdocX 949]

vor 1 Minute schrieb Chreaterdeluxe:

Okay, und welche System Providers nehme ich da mit? Nur Micosoft-Windows-Deploment-Service-Diagnostics? 

Eigentlich reicht einfach auf "Play" oben zu drücken.

 

Es ist auch möglich eine neue "Session" anzulegen. Oben links auf "New Session" > "Live Trace" > "Select Scenario" > "Local Network Interface (Win8 and erlier)" > Start.

[Chreaterdeluxe 0]

Habs hinbekommen.

 

 

 

 

Hoffentlich kannst du da was rauslesen.

bearbeitet 27. September 2019 von Chreaterdeluxe

[MurdocX 949]

 

Hier kann mann die Problematik im Vergleich sehr gut sehen. Im UDP-Paket, welche vorher ausgetauscht wurden, steht die wdsmgfw.efi im Payload als Bootfile drin, weshalb auch die TFTP-Verbindung den Pfad boot\x64\wdsmgfw.efi unter File enthält. Leider ist der Pfad bei Dir leer. Das erklärt auch, warum nicht gebootet werden kann.

 

Wie sieht denn die Payload der beiden UDP-Pakete davor aus?

 

Nachtrag:

- Habt Ihr zufällig auf euren Switchen die Funktion "DHCP-SNOOPING" aktiv oder ähnliches? Diese verhindert quasi einen zweiten DHCP-Server.

- Wird ein Windows DHCP verwendet?

bearbeitet 27. September 2019 von MurdocX

[Chreaterdeluxe 0]

Also ich hab die Session jetzt noch 2mal laufen lassen, bei mir erzeugt er keine UDP-Pakete am Anfang, keine Ahnung wieso..

3Session sieht jetzt so aus:

 

Das Boot.file gibt es jedenfalls nicht mit, wird mir so aber ja auch aufm Screen angezeigt... 

 

Zitat

Nachtrag:

- Habt Ihr zufällig auf euren Switchen die Funktion "DHCP-SNOOPING" aktiv oder ähnliches? Diese verhindert quasi einen zweiten DHCP-Server.

- Wird ein Windows DHCP verwendet?

 

Pu, wegen Switch muss ich schauen, kann ich aber leider erst am Montag abklären (hab kein Zugriff).

 

Wir benutzen einen ganz normalen Windows Server 2016 wo unser AD und DHCP drauf läuft...

bearbeitet 27. September 2019 von Chreaterdeluxe

[MurdocX 949]

vor 25 Minuten schrieb Chreaterdeluxe:

Pu, wegen Switch muss ich schauen, kann ich aber leider erst am Montag abklären (hab kein Zugriff).

Das wäre gut. Die UDP-Pakete benötigst du, denn in denen wird, wie oben geschrieben, die Info übergeben was der Client vom Server laden soll. Wenn die nicht ankommen, dann haben wir genau das Problem.

 

Mein UDP-Payload mit der benötigten Information:

.....ÝYz.......P............È[vá............TEST-SRV2012....................................................boot\x64\wdsmgfw.efi............................................................................................................c.Sc6.....a..Là.;.#².¨\×yQ.B!<.PXEClient5..ü7\Tmp\x64uefi{2FAF9885-4C67-474E-B3E5-7C3B4A756E22}.bcd.ú...........p..................ÿÿ

 

Noch zu klären:

- Habt Ihr mehrere Netze die der DHCP versorgt? Dann könnte IPHelper noch ein Thema für euch sein.

- Wichtig hier auch die Thematik mit DHCP-Snooping, also dem schlucken der Pakete durch den Server

- Welche MTU-Size hat der Netzwerkadapter? -> Powershell: -> unter 1500? Dann bitte auf 1500 stellen.

Get-NetAdapter | Select-Object Name,MtuSize

 

bearbeitet 27. September 2019 von MurdocX

[Chreaterdeluxe 0]

Hallo Jan,

 

ich habe den Fehler gefunden.

 

Auf unserem DHCP war Option 60 etc. an....

 

Ich hab es rausgenommen und zack wurde die bootdatei mit übermittelt!

 

Ich danke dir Vielmals für deine Hilfe!

 

LG