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.