Recently I have ran into an issue at a customer site where software update lists did not properly replicate down to child primary sites. Some of the latest update lists were either incomplete or not visible at all. As a result the customer could not properly advertise the latest software updates.
Initial investigation of the problem shows that the objmgr.box\INCOMING\ and objmgr.box\INCOMING\Retry folders on the child sites contained a lot of unprocessed CID and SDM files. Looking further into the objreplmgr.log errors like to one below are logged:
Processing replication file C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\objmgr.box\INCOMING\Retry\S00_73333.SDM in retry.
Successfully processed Object ScopeId_43C9B1DB-9FC7-4363-8027-36D0C5C24148/AuthList_14C762F6-811D-473F-941F-58B126C93CEF.3
SDM Package ScopeId_43C9B1DB-9FC7-4363-8027-36D0C5C24148/AuthList_14C762F6-811D-473F-941F-58B126C93CEF.3 does not exist in the DB, will insert it with the IsDeleted Flag Set.
SQL MESSAGE: sp_SetupSDMPackage – SDMPackage refers another SDMPackage that is not available yet
sp_SetupSDMPackage returns an error 2
Referenced SDMPackages are not available yet: http://schemas.microsoft.com/systemsmanagementserver/Site_43C9B1DB-9FC7-4363-8027-36D0C5C24148/SUM_cee535ab-0ae5-44e7-8fdf-0f698b27e6f9/1(0);
Failed to Delete Object ScopeId_43C9B1DB-9FC7-4363-8027-36D0C5C24148/AuthList_14C762F6-811D-473F-941F-58B126C93CEF.3. Will add the Replication File C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\objmgr.box\INCOMING\Retry\S00_73333.SDM to the Replication File Retry Queue.
Similar errors exists when the site is processing .CID files.
Interdependencies exists between the different items used for software updates. If the referenced objects are not available the new file will not be correctly processed. It seems that for this particular child site a hickup occured in the replication and the information on the child site is incomplete.
To resolve the issue I ran through the following steps:
1. Stop the SMSEXEC and SMS COMPONENT MANAGER services. This will bring all activity on the site to a standstill.
2. Rename the INCOMING folder to INCOMING_old and recreate an new empty folder structure (so INCOMING and all retry/bad subfolders).
This way we can monitor which files are replicating down and if they are properly being processed, and also see what is being moved into the retry and bad folders.
3. Run the following query on the child site database: Delete from CI_ConfigurationItems Where CIType_ID in (1, 6, 8);
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
4. Then run this query: Update CI_SDMPackages set IsDeleted = 1 where SourceSite = ‘XXX’;
Make sure to replace the XXX with the site code of the central site in the hierarchy.
5. And execute the following: Exec sp_DeleteOldSDMPackageData 0;
6. As a final step force a full replication by dropping a XXX.SHA file in the objmgr.box folder on the central site
Here XXX is to be replaced with the site code of the child site.
7. Restart the services stopped in the first step to bring the site back in operational mode.
Shortly after these steps you should see files appearing in the objmgr.box\INCOMING\ folder on the child site again. You can also see if they are being processed in the objreplmgr.log file. Do not be alarmed if initially some files are put in the retry folder again. They will eventually be processed when all dependencies are in place. A full replication can be time consuming: in my case it took over 12 hours for the procedure to complete. Eventually the end result was that the Update Lists showed up completely again.
Note: the above procedure includes making direct changes to the backend database. If you have a support contract I would highly recommend to involve a Microsoft Support representative to ensure you infrastructure remains supported.
