ConfigMgr 2012 R2 – PXE-Flag-Bug!

Um von diesem Bug (der als solcher vom Microsoft-Support bestätigt worden ist) betroffen zu sein, müssen folgende Voraussetzungen erfüllt sein:

  • die Bereitstellung (Deployment) einer Task-Sequenz muss vom Typ “erforderlich” (required) sein
  • es ist eine CAS (Central Administration Site) und folglich auch mindestens eine Primary Site im Spiel
  • “unknown computer support” ist nicht aktiv, sondern es werden die entsprechenden Objekte (manual machine entries, d.h. Computername und MAC-Adresse) per “Computerinformationen importieren” (“Import Computer Information”) auf der CAS angelegt

Sollten diese Voraussetzungen nicht alle gleichzeitig zutreffen ist man von dem Bug nicht betroffen.

Vor der eigentlichen Problembeschreibung noch kurz ein paar Worte zum Thema “PXE-Flag”. Dieses kommt nur in’s Spiel, wenn es erforderliche Bereitstellungen (required deployments) von OSD-Tasksequenzen gibt. Dieses Flag wird in der Datenbank gesetzt (Tabelle LastPXEAdvertisement), sobald eine solche Tasksequenz erstmalig auf einem Client gestartet wird. Dies ist wichtig, denn ein Client wird während des Verlaufs einer Tasksequenz mehrmals neu starten. Sollte nun die Bootreihenfolge BIOS-seitig so eingestellt sein, dass PXE-Boot an erster Stelle steht, so würde der Client bei jedem Neustart die Tasksequenz erneut starten und somit in einer Schleife enden. Durch das automatische Setzen dieses Flags weiß nun der PXE-enabled Distribution Point, dass der Client (bzw. eine Ressource mit einer gegebenen MAC-Adresse) die Tasksequenz schon einmal gestartet hat und antwortet auf weitere PXE-Anfragen (von dieser MAC-Adresse) mit einem “abortpxe”, so daß der Client mit dem nächsten Gerät der BIOS-seitig eingestellten Bootreihenfolge fortfährt.
Dieses PXE-Flag bleibt für jeden Rechner bestehen, so lange es auch die Bereitstellung (Deployment) für diese Tasksequenz gibt. Soll ein Rechner tatsächlich neu installiert werden, so muß dieses PXE-Flag vorher gelöscht werden. Die Admin-Konsole bietet dazu die Option “Erforderliche PXE-Bereitstellungen löschen” (“Clear Required PXE Deployments”).

Fatal wäre natürlich, wenn diese PXE-Flags verschwinden würden. So würde jeder Rechner (der Netzwerkboot als erstes in der Bootreihenfolge eingestellt hat) die OSD-Tasksequenz erneut starten. Und genau dies passiert leider ab ConfigMgr 2012 R2 (SP1 ist davon nicht betroffen) – wenn die oben genannten Voraussetzungen erfüllt sind – und zwar direkt nach erfolgreicher Ausführung der Tasksequenz.

Was passiert nun genau?

  • Beim Importieren von Computerinformationen auf der CAS (manual machine entry) wird eine neue Resource in der ConfigMgr-Datenbank angelegt. Dieser erhält eine ResourceID aus dem “Nummernkreis” der CAS (z.B. Name0 = PXETEST, MAC-Adresse = 01:02:03:04:05:06, Itemkey = ResourceID = 1234). Dieser Datensatz muss folglich Mitglieder einer Collection sein oder werden, auf die es eine erforderliche Bereitstellung einer OSD-TS gibt.
  • dieser Datensatz wird per DRS (data replication service) auf die Primary Sites repliziert (und behält dabei logischerweise die ResourceID)
  • danach wird ein Client (MAC 01:02:03:04:05:06) gestartet, der PXE-enabled Distribution Point fragt nach verfügbaren Tasksequenzen und startet diese dann. Details zu dem Prozeß findet man hier http://www.mssccmfaq.de/2012/02/04/cm12-pxe-boot-szenarien/ (Szenario 4). Entsprechend wird auch sofort das PXE-Flag gesetzt (siehe SQL-Tabelle LastPXEAdvertisement).
  • die Task Sequenz läuft, bootet unterwegs mehrmals und installiert das Betriebssystem. Bis hierher gibt es auch noch kein Problem, da das PXE-Flag ja (noch) gesetzt ist.
  • nachdem die Tasksequenz erfolgreich durchlaufen ist registriert sich aber der SCCM-Client beim Management Point (MP) der Primary Site (MP Client Registration). Dabei wird aber der bestehende Datensatz (ResourceID=1234) nicht aktualisiert, sondern “decommissioned”.  Er erhält dabei eine ResourceID aus dem “Nummernkreis” der Primary Site (z.B. 16700001). In der Konsole fällt das auch nicht weiter auf (es sei denn, man blendet die Spalte “ResourceID” ein), denn decommissioned Resourcen werden in der Konsole nicht angezeigt.
  • Schaut man sich die Tabelle SYSTEM_DISC an, so finden sich dann zu Name0 zwei Einträge: 

    Name0 = PXETEST, ResourceID = 1234, Decommissioned0 = 1, Client0 = 0 und
    Name0 = PXETEST, ResourceID = 16.700.001, Decommissioned0 = 0, Client0 = 1

    Knackpunkt an dieser Stelle ist das Decommissioning der ResID 1234 (die durch die MP Client Registration ausgelöst wird). Dabei wird die SQL Stored Procedure spSystemDecommission ausgeführt.
    Diese enthält unter anderem folgenden Befehl:

    delete P from LastPXEAdvertisement P join System_MAC_Addres_ARR M on P.MAC_Addresses=M.MAC_Addresses0 where M.ItemKey=@OldItemKey

    Hier wird also in der System_MAC_Addres_ARR-Tabelle nach der MAC-Adresse der alten ResourceID geschaut und anschließend aus LastPXEAdvertisement gelöscht. LastPXEAdvertisement enthält aber (a) keine Spalte für die ResourceID (bzw. wird diese nicht verwendet) und (b) gibt es für das neue Objekt (ResID 16700001) dort sowieso keinen Eintrag. Der Eintrag für die alte ResourceID ResID 1234) wurde soeben gelöscht und für die neue ResID 16700001 gibt es keinen. Byebye PXE-Flag.

    Vergleicht man die genannte Stored Procedure von SP1 mit R2, so stellt man fest, dass das delete-Statement in der SP1-Version noch nicht vorhanden war.

Als Workaround können die manual machine entries auf der Primary Site angelegt werden. Dann tritt kein decommissioning auf und das PXE-Flag bleibt bestehen.

Ich werde den Artikel aktualisieren sobald es Neuigkeiten gibt.
PXE flag bug

 

2 Gedanken zu „ConfigMgr 2012 R2 – PXE-Flag-Bug!

  1. Daggi

    Hat sich geklärt, PXEFlag wurde wohl mal versehentlich gelöscht, SSD war defekt, daher kam als nächstes Boot Device LAN, Passwort wurde nicht eingegeben, aber da SSD defekt, ohnehin kein OS mehr – also keine Fehlkonfiguration am System…

  2. Daggi

    Hallo Torsten,
    vielen Dank für diesen wirklich in die Tiefe gehenden Beitrag zur PXE-Problematik.. darf ich hier auch eine Frage stellen… falls nicht, dann bitte nur meinen Dank entgegen nehmen und alles weitere ignorieren… 😉
    aktuell recherchiere ich, warum sich ein Rechner heute morgen dazu berufen gefühlt hat, einen PXE-Boot zu machen, 2 der genannten Voraussetzungen für diesen Bug treffen zu, allerdings haben wir eine kleine Umgebung mit nur einem SCCM-Server und kein CAS im Einsatz.
    PC wurde vor ca.einem Jahr mit einer heute nicht mehr genutzten Tasksequenz aufgesetzt, im log kann ich sehen, das PXE-Boot für diese MAC Adresse ausgelöst wurde, andere PC s in dieser Collection haben noch das PXEFlag- ein versehentliches Rücksetzen auf Collection Ebene kann ich ausschliessen.
    Des Weiteren haben wir die Einstellung, das eine LAN Boot mit Funktionstaste explicit ausgelöst werden muß- sofern diese nicht gedrückt wird, sollte also nichts passieren.
    Als 3. Punkt haben wir noch ein Passwort, was zu Beginn des Aufsetzens eingegeben werden muss- nach meinen Infos wurde das nicht eingegeben, trotzdem läuft der PC nicht mehr und verlang nach OS-Installation… eine Fehlbedienung vom Helpdesk/User/Admin in einer dieser 3 Schutzeinrichtung vor ungewolltem Aufsetzen kann durchaus denkbar sein, aber das alle 3 Hürden versagt haben, halte ich für unwahrscheinlich…wie kann ich herausfinden, was passiert ist um solche Fälle zukünftig zu vermeiden ? Für jede Hilfe schon mal herzlichen Dank vorab!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert