Nach einem Absturz der SCCM Konsole ist ein Objekt für die Bearbeitung durch den sogenannten SEDO-Lock gesperrt. In meinem Fall war dies heute eine Application (Anwendung):
Neben der früher angesprochenen (und bis heute nicht supporteten) Variante, den Lock direkt auf der Datenbank zu löschen, gibt es zwei Varianten die unterstützt werden (eigentlich drei – die dritte wäre, 30 Minuten zu warten):
PowerShell:
Die erste Alternative (und auch die erste Wahl ) ist die Verwendung der PowerShell:
Alternativ kann einfach der SMS Executive Dienst neugestartet werden, was die Wartezeit von 30 Minuten abkürzt, aber natürlich auch weitere Folgen für den Betrieb des SCCM hat.
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:
