During the normal course of peer review during an app implementation, we suddenly found ourselves without any ability to make changes. The peer review engineer opened the app to check settings and was told he could not edit it because it was in use…by him!
“Cannot edit the object, which is in use by ‘<username>’ at Site ‘<configmgr site>’.”

This happened as the result of the ConfigMgr console crashing while he had the object open.
ConfigMgr 2012 handles editing of objects through something called “SEDO” or “Serialized Editing of Data Objects.” Object locks can be found in the SEDO_LockState table in the ConfigMgr database. You can locate the record in question by searching for LockStateID that’s not zero, or by the user ID that ConfigMgr says is editing the object (‘AssignedUser’). An example query would be:
select * from SEDO_LockState where LockStateID <> 0

Simply use the appropriate information to remove the record related to the object*. For example:
DELETE from SEDO_LockState where LockID = ‘<LockID of the record identified in the previous query>’

Once the record is removed, you should be able to modify the object.
*It should go without saying, but directly modifying the ConfigMgr database should only be done with great care.


Robert Wood: Ryan, you are saying the ping uses the FQDN?, because the only way it ...
Ryan Ephgrave: Are you talking about the WOL tool? I only check for the IP when I hav...
Robert Wood: Hi we have right click tools installed with SCCM 2012, I have noticed...
Garth Jones: Wow that is cool thanks!!...
Garth Jones: Wow that is cool thanks!!...