WDS boot problemen PXE-E55 error

[Toon-VA]

Hallo Iedereen,

Ik ben voor school bezig met WSUS en WDS op Windows Server 2008 R2 x64 binnen Vmware Workstation 9, maar het wil niet lukken en de deadline komt dichterbij.

De situatie is als volgt:

Server 1 - Windows Server 2008 R2 x64: AD, DHCP, DNS en WSUS
Server 2 - Windows Server 2008 R2 x64: WDS

De bedoeling is dat er via Server 2 nieuwe machines kunnen worden geïnstalleerd en deze worden dan door WSUS op Server 1 geüpdatet.

In Vmware staat de DHCP service uit, de range van Vmware zelf die daar wordt gebruikt ligt tussen 192.168.144.128 tot 192.168.144.140. De servers krijgen een static IP adres beginnende van 192.168.144.130 oplopende met 1 (.131 / .132 / ...). Er wordt ook gebruik gemaakt op alle NIC's van Vmnet8 (NAT).

Op Server 1 heb ik nu ook een range aangemaakt beginnende van 192.168.144.150 to 192.168.144.160. Deze zijn voor de clients die via WDS willen installeren.

Nu heb ik in de DHCP service de volgende opties aangemaakt:

• 006 IP adres DNS server (192.168.144.130)
• 015 Domein (toon.local)
• 060 PXEClient
• 066 IP adres WDS server (192.168.144.131)
• 067 \boot\x86\pxeboot.com

Op Server 2 heb ik de image en boot voor Windows Server 2008 R2 x64 al geselecteerd en toegevoegd.

Het is ook de bedoeling dat de computers die via WDS worden geïnstalleerd al in AD zitten, dus heb ik in de PXE properties binnen WDS de optie "Respond only to known client computers" gekozen.

Ik heb de GUI van de te installeren computer genoteerd en op Server 2 gebruikt via de command line en WDSUTIL.exe. De computer is toegevoegd en zichtbaar binnen de OU "Computers" in AD.

Het probleem:

Van zodra ik nu de computer opstart die ik wil laten installeren via WDS, dan krijg ik na het DHCP request deze foutmelding:

PXE-E55: ProxyDHCP service did not reply to request in port 4011

Ik ben nu in totaal al meer dan een dag aan het zoeken op een mogelijke oplossing maar tot nu heb ik nog niets gevonden. Op het internet heb ik meerdere oplossingen gevonden maar allemaal zonder succes.

Sommige zeggen dat het probleem bij pending devices ligt binnen WDS maar deze optie gebruik ik niet.

Ik heb de DHCP en WDS services al verwijderd en opnieuw geïnstalleerd maar niets lijkt te werken.

Het enige wat lijkt te werken is de DHCP service van Vmware in te schakelen en dan in de PXE properties alle computers toegang te geven.

Maar dit is niet de opgave die ik moet maken dus bij deze vraag ik aan jullie hulp zodat ik hopelijk dit probleem kan oplossen.

[Linke Loe]

DHCP optie 60 is in principe niet nodig als WDS op een andere server draait, dan de DHCP server. Wat gebeurt er als je deze weg laat?

[Toon-VA]

Als ik de optie 060 weglaat in DNS dan krijg ik de foutmelding PXE-E555 niet maar dan kom er een nieuw probleem:

"Windows Boot Manager 192.168.144.131"

Windows failed to start ....

File: \Boot\BCD
status: 0xc000000f
Info: An error occurred while attemping to read the boot configuration data.

[Linke Loe]

Probeer eens wdsnbp.com in plaats van pxeboot.com in optie 67...

[ Voor 10% gewijzigd door Linke Loe op 31-01-2013 20:50 ]

[Toon-VA]

Helaas krijg ik dezelfde foutmelding van Windows boot manager

Het booten duurde nu ook langer dan voordien

[Razwer]

alleen optie 66 mee geven, de rest niet (60 en 67).

[ Voor 12% gewijzigd door Razwer op 01-02-2013 11:51 ]

[Killah_Priest]

Razwer schreef op vrijdag 01 februari 2013 @ 11:50:
alleen optie 66 mee geven, de rest niet (60 en 67).

Optie 67 heb je ook nodig als je WDS op een andere server draait als je DHCP.
Optie 66 geeft je PXE server aan, 67 het pad naar de boot file.
Als je de DHCP op je WDS hebt draaien dan moet je alleen optie 60 gebruiken en in de eigenschappen van je WDS (in de WDS console) aangeven dat er niet geluisterd word op poort 66 en 67 (vinkje zetten bij die optie).

De optie om te responden op known cliëntsysteem kan je het beste uit zetten, hiervoor moet je namelijk een database file hebben met de GUIDs van de machines. Het neerzetten van een WDS zorgt er niet voor dat clients direct "known" zijn (als een client al een keer geboot heeft van de WDS dan is deze daarna wel "known, ongeacht of deze in het domein hangt of niet".

Overigens is WDS zonder MDT vrij kansloos en te beperkt, zelfs MS geeft dit min of meer toe in het boek van MS press van server 2012 (een compleet hoofdstuk over MDT waarin er mbt WDS alleen maar wordt aangegeven dat je het als PXE boot platform dient te gebruikten om litetouch en zerotouch boot images te kunnen booten.)

[Razwer]

Killah_Priest schreef op vrijdag 01 februari 2013 @ 21:19:
[...]

Optie 67 heb je ook nodig als je WDS op een andere server draait als je DHCP.

Dat zegt de theorie ja, maar bouw het maar eens na in een lab, is niet nodig

[Killah_Priest]

Razwer schreef op zaterdag 02 februari 2013 @ 00:08:
[...]

Dat zegt de theorie ja, maar bouw het maar eens na in een lab, is niet nodig

Op mijn werk kreeg ik het niet werkend zonder optie 67 (hoewel de WDS omgeving ooit door een oud collega was opgezet die nogal wat prutswerk geleverd had waardoor ik toch nog het plan heb om deze een keer volledig van scratch in te richten, dan probeer ik het ook wel zonder 67)

[Toon-VA]

Hoi Iedereen,

Na nog 2 uur prutsen met mijn leerkracht hebben we het eindelijk aan de praat gekregen.

De optie 060 PXEClient hebben we uit de DNS gesmeten, optie 066 en 067 hebben we behouden alleen hebben we de \boot\x86\pxeboot.com gewijzigd naar \boot\x64\wdsnbp.com.

Dan was er idd het probleem van "alleen gekende client's" die zich mogen aanmelden bij WDS.

Ik had op voorhand al een paar client's aangemaakt via WDSUTIL op basis van hun GUID, maar we zijn er achter gekomen dan binnen VMware de GUID wijzigd/niet klop waardoor er op de Client dus een Timeout ontstond.

Dat hebben we ontdekt door een wireshark trace al het netwerkverkeer van de client naar de WDS te capturen.

Nu om dit op te lossen heb ik alle aangemaakte client's gedeletet in AD en dan heb ik ze opnieuw aangemaakt via WDSUTIL maar nu op basis van hun MAC adres.

Hier moest wel dezelfde notatie worden gebruik als bij GUID: 00000000-0000-0000-0000-xxxxxxxx

En plots ging alles wel zonder problemen.

Moraal van het verhaal, alles had van in begin bijna kunnen werken als VMware geen veranderingen doet met de GUID.

Alvast ook allemaal bedankt voor de hulp en hopelijk is deze info later nog voor iemand nuttig