Auf Anregung einiger Teilnehmer habe ich heute ein Video erstellt, das zeigt, wie man die OSD-Komponenten des System Center Configuration Manager 2012 R2 nutzt, um Betriebssysteme zu verteilen. Das Operating System Deployment stützt sich dabei auf WDS/PXE und DHCP.
SEDO (Serialized Editing of Distributed Objects) soll im SCCM2012-Umfeld möglich machen, dass mehrere Admins gleichzeitig arbeiten, ohne sich gegenseitig in die Quere zu kommen. Wenn unter SCCM2007 ein Admin eine Tasksequenz bearbeitet hat, die noch bei einem anderen Admin zur Bearbeitung geöffnet war, dann „gewann“ derjenige, der zuletzt gespeichert hat, was mitunter sehr ärgerlich war.
Unter SCCM 2012 werden nun Tasksequenzen, die zum Bearbeiten geöffnet sind, gesperrt. Diese an sich sehr nützlich Funktion kann aber auch zu einem Problem werden. Die Sperre sollte nach 30 Minuten „Inaktivität“ automatisch aufgehoben werden. Da dies aber ein Vorgang ist, den die SCCM-Konsole durchführt, kann es passieren, das eine gesperrte Tasksequenz dauerhaft gesperrt bleibt, wenn z.B. die Konsole abgestürzt ist.
Für die Sperrung ist die SQL-Tabelle SEDO_LockState zuständig.
Gesperrte Tasksequenzen kann man z.B. mit folgendem SQL-Statement abfragen:
1
SELECT*FROM SEDO_LockState WHERE LockStateID !=0
Select * FROM SEDO_LockState WHERE LockStateID != 0
Das eine Tasksequenz gesperrt ist, wird auch beim Versuch, diese zu bearbeiten angezeigt:
Um nun eine Entsperrung zu erzwingen, ist folgendes SQL-Statement geeignet:
Mal wieder ein Fehler, den ich hier festhalten möchte, obwohl diesmal recht trivial.
Während einer PXE-gestützten Betriebssysteminstallation (OSD) trat nach der Partitionierung und Formatierung der Festplatte der Fehler 0x80070002 auf:
Ein Blick in das Log-File war leider nur mäßig hilfreich:
Da der nächste Schritt, der nun also nicht erfolgreich bearbeitet wurde, das Kopieren der WIM-Datei gewesen wäre, vermutete ich ein Problem beim Zugriff auf dem DP, und meine Vermutung fand ihre Bestätigung:
Es war einfach kein Network Access Account (Netzwerkzugriffskonto) angegeben!
Dies lässt sich recht einfach erreichen, ich denke die Bilder sind aussagekräftig genug:
UPDATE: Ich habe eben festgestellt, dass dieser Fehler auch trotz korrekt konfiguriertem NAA auftreten kann. In meinem Fall war die Fehlerursache dann auch eine ganz andere: Es fehlte einer Bedingungen für Distribution Points, nämlich die „Windows-Authentifizierung“ des IIS!