An diesem Problem habe ich eine lange Zeit geknobelt, bis ich die eigentlich triviale Lösung gefunden habe.
Die selbstgestellte Aufgabenstellung war, dass der firmeninterne MDT-Server zur Installation der Kunden-PCs auch UEFI und Secure Boot bedient.
Die BIOS-Variante hat schon klaglos seinen Dienst versehen.
Mit ein wenig Recherche kam ich letztendlich auf diesen Eintrag, der über Herstellerklassen und Richtlinien auf dem DHCP-Server die Steuerung übernehmen sollte.
Gesagt, getan.
Es tut nicht
Das interne Netz und das Werkstattnetz sind bei uns getrennt. Bei Letzterem kamen die IP-Adressen per DCHP vom Router. Da dieser keine Herstellerklassen bereitstellen kann, wurde an einem ruhigen Freitag Nachmittag der DHCP-Server zusätzlich zur WDS-Rolle auf dem MDT-Server installiert.
Danach wurde der DHCP-Server noch für das Active Directory authorisiert.
Die Einrichtung der Herstellerklassen sowie der Richtlinien war relativ schnell erledigt.
Da gerade ein Rechner für einen Kunden installiert werden sollte, hatte ich just einen Test-Rechner zur Verfügung.
Bedauerlicherweise hatte der Rechner alles im Sinn, nur nicht UEFI und Secure Boot.
Am DHCP-Server konnte man anhand der MAC-Adresse sehen, dass der PC sehr wohl mit dem DHCP-Server kommunizierte und eine IP-Adresse zugewiesen bekam.
Das war schon mal die halbe Miete.
In der nächsten Zeit suchte ich dann immer wieder mal den Fehler, wenn ein entsprechender Client zur Installation anstand und ich Zeit dafür hatte.
Zunächst entdeckte ich Tippfehler in den Richtlinien, deren Behebung keine Besserung brachten.
Ich legte mich mit Wireshark und dem Process Monitor auf die Lauer ohne zu einem brauchbaren Ergebnis zu kommen.
An jeder Einstellung, die halbwegs sinnvoll war, habe ich herumprobiert, aber nie war ein Erfolg zu melden.
Dann schlug ich einen anderen Weg ein.
Zwei alternative Ansätze
Ich installierte mir eine Test-Umgebung zuhause auf meinem PC. Zum Testen, wegen der Schnelligkeit und aus Bequemlichkeit habe ich alles auf eine einzige virtuelle Maschine gepackt.
Das Ergebnis war auch hier das Gleiche: Der Client bekam eine IP-Adresse, aber danach hagelte es Abbrüche und Fehlermeldungen.
Im Urlaub habe ich dann meinen alten Server wieder reaktiviert und einen Windows Server 2016 Datacenter mit der Hyper-V-Rolle installiert.
Darauf liess ich dann einen virtuellen DC mit DHCP-Rolle und einen eigenen MDT-WDS-Server mit WDS-Rolle laufen.
Bevor ich mich an den WDS machte, setzte ich hier einen Checkpoint.
Die WDS-Rolle konfigurierte ich dann als „Standalone“.
Die Einrichtung des DHCPs erfolgte wieder nach der o.a. Webseite.
Den ersten Test machte ich mit mit einer VM der Generation 2. Sie bootete ohne Umscheife über UEFI und nach 10 min war die VM mit Windows 10 erfolgreich installiert.
Im zweiten Test erstellte ich eine VM der Generation 1. Ich fügte die „Ältere Netzwerkkarte“ hinzu und auch hier war nach 10 min die VM erfolgreich fertig.
Als Nächstes setzte ich den MDT-Server zum früheren Checkpoint zurück und installierte den WDS als „Active Directoy-integrated“.
Eine halbe Stunde später hatte ich zwei neue VMs. Einmal mit UEFI und einmal mit BIOS.
Um ganz sicher zu gehen, zog ich den DHCP-Server auf den MDT-Server um, änderte die Einstellungen am WDS und führte meine Tests fort.
Wie ich es letztendlich erwartet habe, zeigte sich das eingangs erwähnte Verhalten. Der Client bezog eine IP-Adresse, aber anschließend scheiterte die weitere Kommunikation mit WDS und MDT-Server.
Die Lösung
Nach dem Umzug des DHCP-Server zurück zum DC lief alles wieder wie geschmiert.
Die triviale Lösung ist somit den DHCP-Server nicht am MDT-/ WDS-Server zu betreiben, sondern auf einem anderen Server laufen zu lassen.