Thursday, June 27, 2013

Object Replication Manager (objreplmgr) on child site failed to insert .CID and .SDM files


I was presented with an issue whereby software updates (configuration items) were not replicating from the central parent site down to a particular child primary site. The symptoms of this being that if a certain update list, update package, or update deployment contained one of the missing updates (CI_items) then the effected object(s) would not appear in the console, and therefore I cannot deploy the effected update(s) at the child site

In this scenario I found a backlog of .CID files in the inbox folder below, each .CID file representing an update which couldn't be processed.

\inboxes\objmgr.box\INCOMING\retry

The retry is attempted 100 times and then the .CID is place in the ‘bad’ folder
\inboxes\objmgr.box\INCOMING\retry\BAD

When SMS_OBJECT_REPLICATION_MANAGER attempts to process the effected CI’s the following is logged to the objreplmgr.log which indicates the failure:

Processing replication file d:\Microsoft Configuration Manager\inboxes\objmgr.box\INCOMING\RetryGL_42586.CID in retry.


Failed to insert Object 6298a02f-0a6a-4f34-b832-08059b682b63 from replication file d:\Microsoft Configuration Manager\inboxes\objmgr.box\INCOMING\RetryGL_48796.CID.

On to the resolution, I found that running the following 6 SQL queries on the effected child sites resolved the issue:

**Note that the ID’s may be different for each site. Run the query Select * from CI_Types to get the proper list. We need to delete the following types: SoftwareUpdate, SoftwareUpdateBundle and AuthorizationList.
Please do this before you run the first query in italic

Delete from CI_ConfigurationItems Where CIType_ID in (1, 6, 8);
Update CI_SDMPackages set IsDeleted = 1 where SourceSite = 'ZZZ';
Delete from CI_ComplianceHistory where isdetected = 1
Delete from CI_Compliancehistory where isdetected = 0
Delete from CI_SDMPackages where isdeleted =1 and sourcesite = 'ZZZ'
Exec sp_DeleteOldSDMPackageData 0;


* note: replace ZZZ with the site code of your central site (or the active SUP which is the furthest upstream’)
Running the above queries will purge Software Updates data from the effected child site.
You should then wait about 30 minutes and then restart the following services on the effected child site:

SMS_EXECUTIVE
SMS_COMPONENT_MANAGER

The final step is to initiate a full site replication, this can be done using the heirarchy maintenance tool (syncchild option) or by place a file called .SHA * in the objmgr.box on the parent site.

* .SHA – replace with the 3 digit site code of the desired child site you wish to replicate.

Allow up to 24 hours for the site replication to complete, when it finishes you should have a fully matching compliment of updates on the central site and child primary site.

You can monitor the objreplmgr.log for successful insertion of .CID and .SDM items, and you should also find that the folder \inboxes\objmgr.box\INCOMING\retry does not contain any items for retry.

No comments:

Post a Comment