Hallo,
nachdem ich jetzt schon in zwei unterschiedlichen Umgebungen (plus zwei LABS) das Problem habe, dass unter „SCCM 2012 – PXE“ der Client kein „abort PXE“ bekommt hat mir das keine Ruhe gelassen:
Szenario1:
– Lokaler DP mit PXE Rolle (alle im selben Netz)
– Client ist in SCCM vorhanden
– Client hat kein aktives Deployment
– Keine DHCP Optionen 66/67
Ergebnis:
Der Client bekommt „PXE-E35: No boot file received“
Szenario2:
– Lokaler DP mit PXE Rolle (alle im selben Netz)
– Client ist in SCCM vorhanden
– Client hat kein aktives Deployment
– DHCP Optionen 66/67 gesetzt
Ergebnis:
Der Client bekommt “PXE Boot Aborted. Boot on ext device….”
Unter SCCM 2007 hätte der Client auch im Szenario1 ein „PXE Boot Aborted ….“ bekommen.
Ob es sich dabei wirklich um ein gewolltes Verhalten handelt (denn so könnten mehrere PXE Server parallel existieren ohne, dass der Client von irgendeinem ein „Abort“ bekommt) oder ob es ein Bug ist der mit SP1 behoben wird ist unklar.
Ein Test mit SP1 Beta bringt das gleiche Ergebnis wie ohne also kein „Abort“. Ist aber auch Beta … .
Zitat aus unten stehendem Forum:
„I opened a case with PSS on this a couple of weeks ago and after two escalations was just told today that it is a known issue that is being investigated, not a design change. The additional detail that the engineer provided (which doesn’t apply to my scenario, but it is worth sharing with others) is that if WDS and DHCP are on the same SCCM server it will send abortpxe like 2007 whether or not a task sequence is assigned even if you aren’t using DHCP options 66/67.”
“I received confirmation yesterday that this issue has been confirmed as a bug and is to be fixed in SP1.”
Das Ganze habe ich mir auch mit Wireshark und Verbose Logging angeschaut, SCCM erkennt bei Szenario2, dass der Client vorher eine IP vom DHCP bekommen hat und antwortet dann mit „PXE Abortet….“
Hier kommt die erste Anfrage des Clients als Broadcast und der DHCP hat noch nicht geantwortet:
Nachdem der DHCP geantwortet hat, sieht das Ganze so aus:
Ok, die Wireshark traces erspare ich Euch ….. .
Ich habe auch keinen RegKey gefunden, der das Verhalten ändert ….. .
Das Ganze habe ich auch mit einem Client in einem eigenen Subnetzt ausprobiert (IPHelper-DHCPRelay und DHCP Optionen), das Ergebnis unterscheidet sich nicht von dem beschriebenen.
Also warten wir mal was SP1 bringt …. .
Ergänzung zu SP1:
Mit SCCM SP1 ist das „Problem“ behoben, es werden zusätzlich weitere Infos geliefert :-).
SystemCenterBlog 