Saturday, January 05, 2008 7:07 AM
I have the Central Site configured to get updates from Microsoft. Works fine. I have one child primary configured to use an upstream server which also works fine. I have another child primary of the Central site which is configured identically to the working primary to use an upstream server. But on this server, no updates show in the update repository and no update lists from above appear. The wsyncmgr.log on this server looks normal and it looks like it is successfully syncronizing updates. Both Primary child sites are peers reporting to the same Primary which is the Central site. Launching WSUS 3.0 also seems to show success from synchronization an it shows that updates are present. The wsyncmgr.log on both the good and bad servers are identical. On syncronization they both show success and generate the same messages. Just can't figure out why updates don't show in SCCM console. One odd thing I am seeing is that from the central site, I selected this primary site as a DP for the deployment package on the central site. It fails to install to this DP with the errors below in distmgr.log. Standard SWD Packages install with no problem.
Distribution Manager will not update the StoredPkgVersion in the Database as Despooler will. SMS_DISTRIBUTION_MANAGER 1/5/2008 8:03:23 AM 7448 (0x1D18)
Adding these contents to the package C0100006 version 6. SMS_DISTRIBUTION_MANAGER 1/5/2008 8:03:23 AM 7448 (0x1D18)
Failed to insert SMS Package C0100006 because SDM Type Content 85c65c96-918a-48a7-8463-8cda94af4c4f is not present in the CI_Contents table. Will try later. SMS_DISTRIBUTION_MANAGER 1/5/2008 8:03:23 AM 7448 (0x1D18)
Cannot update the package C0100006 in the package source, error = 3 SMS_DISTRIBUTION_MANAGER 1/5/2008 8:03:23 AM 7448 (0x1D18)
Another odd item is that on the bad server, the CI_Contents table appears empty which probably explains the above error . The good server has many rows in the CI_Contents table. Seems like something got out of sync along the way or perhaps there is some replication issue I am not seeing. I have removed SUP and WSUS and reinstalled several times. The ports are correct. I am not configuring WSUS as directed in the docs and all over these forums. I let SUP handle that and it seems to succeed.
More info which could be related. We initially had secure exchange between sites selected. For several reasons we cannot publish these sites to AD at this time and so nothing was replicating from the central to this primary. So I followed directions to manually install key using preinst. I since turned off secure exchange between sites. Replication did begin to occur, all collections have replicated from above successfully. I wonder if the initial replication and secure key issues played a role early on.
Monday, January 07, 2008 4:05 AM
As a follow up, I am noticing a backlog of *.CID and *.SDM files in objmgr.box/incoming/retry. the objreplmgr.log has messages for each .CID file similar to:
Processing replication file D:\SCCM\inboxes\objmgr.box\INCOMING\Retry\C01_13613.CID in retry. SMS_OBJECT_REPLICATION_MANAGER 1/7/2008 4:33:09 AM 5368 (0x14F8)
SDM Package Name Site_DCB88AD5-8F75-4D39-93A3-3A34C0AAA6CA/SUM_22c70886-3576-4dd4-a269-a183fdfa8e94 Version 1 has not arrived yet. Will retry SMS_OBJECT_REPLICATION_MANAGER 1/7/2008 4:33:09 AM 5368 (0x14F8)
Failed to insert Object 22c70886-3576-4dd4-a269-a183fdfa8e94 from replication file D:\SCCM\inboxes\objmgr.box\INCOMING\Retry\C01_13613.CID. SMS_OBJECT_REPLICATION_MANAGER 1/7/2008 4:33:09 AM 5368 (0x14F8)
This backlog remains and never gets processed. There is not much info on objmgr.box or objreplmgr.log so I am not sure where to look. I could see that the software update info I am missing is here in this inbox.
Wednesday, January 09, 2008 4:28 PM
I have the same exact thing too, with no luck
Please let me know if you find a solution.
Processing replication file d:\SMS\inboxes\objmgr.box\INCOMING\Retry\TST_12217.CID in retry.
Failed to insert Object a3fcdeb7-f2e4-4908-82e6-bc6f351ff11e from replication file d:\SMS\inboxes\objmgr.box\INCOMING\Retry\TST_12901.CID.
Monday, January 14, 2008 7:03 PMThe cause of this ended up being a very unexpected one. We have a new team building our SQL servers and this was a new server. They incorrectly chose a case-sensitive Collation sequence on SQL causing many internal queries to fail. We noticed this in troubleshooting when we ran some basic queries against the DB and they were failing. We then noticed the case sensitivity issue. So unfortunately we had to re-install the server but we are lucky it was very new.
Thursday, June 26, 2008 11:18 AM
Not sure whether this will help but I saw almost identical symptoms as you describe and was resolved by creating a .SHA file in the objreplmgr inbox of the parent site(s) for the child site.
Thursday, August 28, 2008 3:33 PMWe have had sites that have had similar problems, and even put a support call in with Microsoft. When the preinst.exe /syncchild didn't work, and manually creating the .sha file mentioned above, they had us disconnect the child site from the parent (for 3-4 hours, until the objreplmgr.log died down), and then connect it back to the parent site. Generally after another 3-4 hours it seems to be OK, and we aren't getting the same errors. The downside is that you then have to readd packages to distribution points.
Tuesday, October 28, 2008 2:38 PMI had this same issue, but it self corrected and is not re-occurring 8 hours later after the errors being reported.
Monday, November 03, 2008 9:40 AM
We have the same problem and on some driver package also.
We have tried to take the disconnect the site and connected it again, still same error.
We hve diffrent collations on our Central SQL cluster and child SQL.
i have a case to Microsoft on it (but they have no answer yet).
But wonders if anyone ave found a solutions that i do not need toi reinstall sql server.
Monday, November 10, 2008 11:42 AM
I had this issue, what it turned out to be was updates at the parent level being expiered but for some reason not tombstoning them.
So it kept trying to update the child site with the expired updates which wouldnt accept them.
What I done was delete all my Software Update packages and lists from the Parent site and then stop the SMS Exec service on the child site.
I then deleted all the files in objmgr.box including retry, then I restarted the service.
Monitoring the log file objreplmrg.log the server tried to process all the files in the retry box which were not there once this had finished the server returned to normal.
This solved my issue on the child sites and it is no longer trying to process 8000 odd files from the inbox.
- Proposed As Answer by DavidMcKee Monday, June 13, 2011 7:18 PM
Saturday, November 22, 2008 7:02 PM
I wanted to add something here. the work around Neil provided worked for me, but i have another veriable in place which i believe also assisted the situation. I removed the distribution point before performing the actions Neil describe. I actually did this before finding Neil's feed back. But after applying Neil's work around, i re added the distribution point, and things are not back to normal.
Richard (XBox ID "Tek Nah Lah G")
Saturday, November 22, 2008 7:04 PM
Oh, i forgot to mention, i did not delete the software update packages. I only removed the latest Update list added. I left the update list that i new that has been there for a while.
Richard (XBox ID "Tek Nah Lah G")
Wednesday, February 25, 2009 7:42 AMThis could be a really daft question but when you have parent and child primary sites using different SQL databases, does the SQL collation need to be identical for both databases?
I haven't seen anything in the documentation to say that they need to be....
Thursday, April 21, 2011 12:49 PM
I had this same issue as well. I tried clearing all my .cid fils from objmgr.box\incoming as well as the retry folder. stopping the smsexec, rebooting my servers and ran the script below from from another posting.
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;
I still received the error. After multiple attempts I ran a full backup of our site database and deleted all the software update deployments from the primary site database dbo.CI_AssignmentsCRCs and dbo.CI_CIAssignments after doing this I reran the script above and from the central site used the preinst.exe /syncchild xxx command to push a full synch to my problem primary site. After about 12 hours I am back to normal finally.
I hope this helps and delete your records at your own risk.