Thursday, June 18, 2009 3:53 PM Brian S. Tucker

How to Resolve SW Update & Site Replication Issues with SCCM 2007 SP1 R2

While I have had some issues over the years on site to site replication (as we all have), normally the address is not configured right or the permission is not set between the sites or even someone forgets to add the primary above as the primary to the child. All these things are easy for mess up and or forget. However, I ran into a real issue on a site that I want to help explain what the issue was and how it was resolved. Issue: Primary to Child Primary replication replicated some collections, packages, adverts and some SW Updates. No errors were logged and the child could send all info up to the primary above, but the issue was not all objects were not coming down the pipe 100%. Resolution: SW Updates - The first thing we did was to clear out all the .CID files in the ..\Inboxes\Objmgr.box\INCOMING and also the subfolder \Retry. The .CID files are actually the individual SW Updates that you selected from the categories. The .CID files have code in them so that when they come in, they look to see if any files supersede them. If yes, then they go to the Retry folder and wait for the proper file to come down and then are processed soon after. I copied the files from both folders just in case to a neutral area. You know you have problems when the Objmgr.log spews error after error for the .CID files. 1. Open SQL and run the following query against your SCCM DB.2. On the child site sql database run the following query in SQL to remove the bad items:

*Warning run this query on the CHILD SITE where the issue is occurring, insure that the CENTRAL Site Code is manually entered as well*

Delete from CI_ConfigurationItems Where CIType_ID in (1, 6, 8);
Update CI_SDMPackages set IsDeleted = 1 where SourceSite = 'central site code';
Exec sp_DeleteOldSDMPackageData 0;

You should see a number of rows affected by this query and a lot for a larger hierarchy. 989 rows took 31 minutes… Wait 15 minutes or so after this completes. What's interesting about this .CID issue is that the .CID's come DIRECTLY from the Central Primary. They do not come from the Primary above no matter how big your hierarchy is. One would think that since the SW Updates / WSUS use the upper primary for WSUS replication, this is not the case when sending down .CID files.

3. Force a resync of the Patch data objects by dropping a <child_site_code>.sha file into the Central site's ..\SMS\inboxes\objmgr.box. This is just a empty .txt file renamed to XXX.SHA. If you did it right, you should see the file delete within a few seconds.Packages, Adverts & Collections - These are not as hard to force replication. From the Central Primary locate your SCCM install dir and in a command prompt run <X:\SCCM Location>\Bin\i386\00000409\Preinst.exe /syncchild XXX (where XXX is the site code). It will take some time, but you should get full replication. Preinst.exe has been around for some time as many of us know, but it pertains to the main subject. The real information on this post is how to fix replication for SW Updates which was very different in SMS.

 

Share this post:                                       
Filed under: , , ,

Comments

# re: How to Resolve SW Update & Site Replication Issues with SCCM 2007 SP1 R2

Monday, February 21, 2011 7:27 AM by villiam1001

Hi Brian,

Thanks for you article. I had a problem similar to this after an incident with the database and lost child/parent configuration. Advertisements, and package worked but WSUS integration was broken and removing the SUP role, and re-installing WSUS didn't help. Followed you guide which did the trick.

br

Lars