When a console crashes and you are editing a task sequence, allow sedo unlock if user name matches yours
It happened to me yesterday with SCCM 1602 CB, I was editing two task sequences at the same time, trying to copy a section from one into the other when the console crashed. I needed the work done and this didn't help as as soon as I started the console again I got the familiar message shown below. The problem is you have to wait 30 minutes for the sedo lock to be removed or use PowerShell cmdlets to try and remove the lock.
I don't think that is necessary at all as there is already a retry button on the popup, and what it should do is 'check what username is logged on, if that username matches the one editing the task sequence (or object), then when they click retry, remove the sedo lock.
That's my idea, please vote for it !
and applications too please -_-
David Stein commented
I just hit this again. It's 2018. :(
John Tracy commented
I have only found one way to alleviate this problem - Close the console and keep it closed for 15 minutes while you play Solitaire. This bug is really making me look bad. The console WILL crash, so let me unlock the task sequence. I AM THE ADMINISTRATOR.
yeah learn how to write software microsoft. That is embarrassing.
Scott Williams commented
I'd like to see a node (under monitoring?) that lists *all* current locked objects and allows them to be cleared. It's amazing how many locked objects are years old and obviously never even noticed.
1702 is affected too
The retry never seems to work to work for me. Just sits there for a long time and I usually have to get the sql DB to kill it off.
Starting with 1610, you can now use Unlock-CMObject -Force to unlock any SEDO object that you have previously owned (in the past, you could not unlock an object that was owned by another SEDO session).
While this doesn't solve the issue in an in-console manner, it does allow you to quickly get unblocked if you run into a situation where the console exits in such a way that any locked SEDO objects are not automatically unlocked.
Cmdlet will now fail if attempting to unlock an object that is locked by a different SMS Provider session. In previous releases, this would silently fail.+
Added Force parameter to attempt to unlock objects that may be locked by a different SMS Provider session. This can be used to recover from a scenario where an object was locked by an administrator console that unexpectedly quit without releasing the object lock.
I have wanted this since starting to learn SCCM. Microsoft, make this happen!