SEDO (Serialized Editing of Distributed Objects) ConfigMgr 2012

  • Makale

SEDO(Serialized Editing of Distributed Objects)

As global data is replicated everywhere, a user on a primary site could change an object at the same time as a user on the CAS or other primary servers. This is an unavoidable consequence of replicated data. SEDO provides a way to enforce that only a single user can edit an object at any point in time. SEDO does it by using a lock request and release mechanism.

The process goes like the below in a nutshell…..

SEDO Lock Acquisition \release Process

1. Administrator attempts to edit object in Admin Console
2. Admin Console attempts to open object from Provider for editing
3. Local site sends SEDO lock request to CAS using SQL Service Broker (SSB) SEDO queue
4. CAS forwards the SEDO lock request on to the owning site if it does not know who had the lock before. If it knows already, then it will forward SEDO to that site which had the previous lock request.
5. Owning site\Site which had the previous lock request assigned will issue a SEDO Lock and records it in the SEDO_LockableObjects table.
6. DRS replicates the change to the SEDO_LockableObjects
7. Provider reads the obtained lock and allows administrator to edit the object.
8. Now when finished editing, the site which has the lock releases the lock.

 

 

You can get the information of the objects in lockstate from this view vSEDO_LockState. If you are concerned about a particular object this is how you can get the information
For instance, we take a Task Sequence (TS) with ID as ‘PR100001’.

select Lockstate,Assignedsite,Assigneduser  from dbo.vSEDO_LockState where lockid in (
select lockid From dbo.SEDO_LockableObjects where objectid in(
select objectid from dbo.SEDO_LockableObjectCOmponents where componentid
 in( select SEDOcomponentID from SMSpackages where PKGID = 'PR100001')))
 
Or say if it is a CI item  like an application with Ci_uniqueid  'ScopeId_C83F5B89-111D-4EA7-A4E4-70539294E4D7/Application_7d2683d2-5c0b-4989-b834-d88e581fb9f6/2'

select Lockstate from dbo.vSEDO_LockState where lockid in (
select lockid From dbo.SEDO_LockableObjects where objectid in(
select objectid from dbo.SEDO_LockableObjectCOmponents where componentid
in( select SEDOcomponentID from CI_configurationitems where CI_uniqueid ='ScopeId_C83F5B89-111D-4EA7-A4E4-70539294E4D7/Application_7d2683d2-5c0b-4989-b834-d88e581fb9f6/2')))

Now let us go into details of how we can track the SEDO flow when the object ‘PR100001’ whose owner site is PR1 on the hierarchy (shown below) is opened for editing :-

We can use this query to track the flow from the Vlogs table. Some information will be also available in the SMSProv.log.

select * from vlogs where procedurename <> 'spDRSSendChangesForGroup' and logtime >= getdate()-1 order by logtime desc

Scenario 1:
Opened object PR100001 from PR1 server.You could see that PR1 server forwarding the request to Parent Site CAS, carried by SSB to CAS and CAS assigns the lock and information received back again using SSB.

 

 

Once we close the object in PR1, it will release the lock promptly as shown below.

 

 

 
Scenario 2:
Object opened in PR2 whereas the owner was PR1.

PR2 request CAS on lock request, goes to the CAS as SSB message, CAS receives and forwards the same to PR1 as it is not the owner of the object, again through SSB message. PR1 receives the request lock the object and send the information to CAS and CAS to the PR1 again through SSB messaging.

 

Scenario 3:

PR1 owned object opened by CAS with no lock obtained so far by any site.

In this flow if the last assigned site was PR2 and when CAS is trying to open, then SEDO request goes to PR2 and not PR1.

 

Scenario 4:

PR1 owned object opened by CAS which was already opened for editing in PR2

 

 

Since this was already opened for editing By PR2 you will find the following information in CAS

select Lockstate,Assignedsite,Assigneduser  from dbo.vSEDO_LockState where lockid in (

select lockid From dbo.SEDO_LockableObjects where objectid in(

select objectid from dbo.SEDO_LockableObjectCOmponents where componentid

 in( select SEDOcomponentID from SMSpackages where PKGID = 'PR100001')))

Now as CAS knows it was last assigned to PR2, it sends a request to PR2 to see if lock was released and then the PR2 will revert back telling the lock is not released and deny the request which make the CAS to open the object in read only mode.

 

 

Hope this helps in troubleshooting SEDO issues.

Sudheesh Narayanaswamy
Support Escalation Engineer
Microsoft System Center Support

Comments

  • Anonymous
    October 29, 2012
    That's an excellent article. Your blogs are commendable sir !

  • Anonymous
    October 29, 2012
    Excellent Blog !!!!!

  • Anonymous
    March 12, 2013
    Good one and you are as always consistant !!! Thanks