I’m not going post about anything new in this post. We’ve loads of posts about SCCM ConfigMgr Software Update replication issues when you have a large environment with 3 tier hierarchy and lot of child primary servers. I’ve seen lots of issues like latest Software Update packages (A.K.A SCCM patch packages) and software update lists which are created at central server are not visible on child primary server console. Hence the SCCM ConfigMgr administrators at regional locations are not able to deploy the latest patches to their workstations. This will get highlighted very soon with in the organization as this is security issue 🙂
One of the very detailed deep dive blog about this issue is Michael Wiles ! Read his full post http://blogs.technet.com/b/mwiles/archive/2011/06/24/troubleshooting-failed-to-insert-object-error-message.aspx . There are so many other blogs which tells you about various ways to resolve this issue. I must warn you most of the resolution steps includes “Editing Database” and directly editing is not supported Microsoft unless you’re a Microsoft CSS engineer 🙂
In the troubleshooting process of SCCM ConfigMgr Software Update Package and Software Update Update list replication issue, the best friend is ObjReplMgr.log. What we need to do resolve Software Update or Patch package replication issues (not visible issue)?
I won’t recommend to do the SQL database edit or to run the SQL query to fix the issue. Rather I would suggest to drop <3 digit Child Site Code>.SHA (3 digit site code) file in the folder “<SCCM Installation Folder>\inboxes\objmgr.box” at your Central site. .SHA file is nothing but a blank file with extension .SHA. When you make blank file using notepad, by default the extension of the file will be .SHA.TXT then make sure to remove the extension to .TXT .
For example : When I’ve a SCCM child primary site with SITE CODE = ACN and in that primary server SCCM console, I’m not able to see the latest software update packages. In this case I need to place ACN.SHA file in inboxes\objmgr.box folder.
Note that, this will initiate the full replication of all the objects between SCCM child primary site and SCCM Central primary server. This could be bandwidth intensive, if you don’t good network bandwidth between both SCCM servers then perform this during off peak hours.
As mentioned above monitor the ObjReplMgr.log log file at central and child primary SCCM sites to more details about progress. When SCCM finishes it’s object replication, the ACN.SHA file will get deleted (disappear) from the Inboxes\ObjMgr.box. Look for the following entry “Deleted site attachment file D:\SCCM\inboxes\objmgr.box\G02.SHA” in Objreplmgr.log. After finishing this process also, we should allow SCCM to update all the tables and entries related to these objects so it may take another 3-4 hours to complete the entire process.
I’ve seen by following this method, we can resolve 90 % of SCCM software Update related replication issues without taking the risk of editing Database.
If the above mentioned step doesn’t resolve your replication issue the best troubleshooting steps which are documented by Sharad Singh here.
Sample ObjReplMgr.log entries
~Successfully replicated Object - ID= 4dd19ecb-f551-4241-8a9a-031696f310b1 - Name= $$<sms_object_replication_manager><thread=4908 (0x132c)=""> ~Successfully replicated SMS Object b9a4a30a-e494-4eaf-8094-2c1d92323108, ReplVarFileName:D:\SCCM\inboxes\objmgr.box\mannj1t7.TMP $$<sms_object_replication_manager><thread=4908 (0x132c)=""> ~Successfully replicated Object - ID= b9a4a30a-e494-4eaf-8094-2c1d92323108 - Name= $$<sms_object_replication_manager><thread=4908 (0x132c)=""> ~Successfully replicated SMS Object 82625326-e038-4b34-b4ce-8980489c4b6e, Deleted site attachment file D:\SCCM\inboxes\objmgr.box\G02.SHA $$<sms_object_replication_manager><thread=4908 (<span="" class="hiddenSpellError" pre="">0x132c)