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 |
Das eine Tasksequenz gesperrt ist, wird auch beim Versuch, diese zu bearbeiten angezeigt:
Um nun eine Entsperrung zu erzwingen, ist folgendes SQL-Statement geeignet:
1 2 3 4 5 6 7 8 9 | UPDATE [CM_LPZ].[dbo].[SEDO_LockState] SET [LockStateID] = 0 ,[AssignedUser] = NULL ,[AssignedObjectLockContext] = NULL ,[AssignedMachine] = NULL ,[AssignmentTime] = NULL WHERE [LockStateID] = '1' GO |
(das „LPZ“ in „CM_LPZ“ ist durch den Sitecode zu ersetzen)
Aber Achtung: Microsoft unterstützt das manuelle Ändern der SQL-Datenbank nicht – ihr solltet also genau wissen, was ihr da tut!
