none
WSUS 3.2 replica server synchronization failed '...when trying to import updates into the data store...'

    Frage

  • Hi,

    for this issue I have already found the thread "http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/2408f2ab-06a8-497e-bf55-a6a0b88d2d15" in this forum but the answer those not corresponds to my case.

    My there replica servers which I rebuild new cannot synchronize with the upstream server successfully. According to the logfile there are four updates which are causing this problem. My other replica servers have no problem with these four updates.

    The four updates can be found on the upstream server but not on the replica downstream servers.

    Upstream server: 3.2.7600.251

    Downstream replica servers: 3.2.7600.251

    The there downstream replica servers are been rebuild new.

    Declining these updates on the upstream server did not help.


    2013-01-27 13:08:43.561 UTC Error WsusService.12 CatalogSyncAgentCore.ExecuteSyncProtocol 4 update(s) could not be imported into the local db even with retry
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.CatalogSyncThreadProcess()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.runTryCode(Object userData)
       at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
    2013-01-27 13:08:43.561 UTC Error WsusService.12 CatalogSyncAgentCore.ExecuteSyncProtocol Bad Update Revision #0: 78b86d45-2b71-447d-ae7b-cedf21e63416/103
    ..
    2013-01-27 13:08:43.561 UTC Error WsusService.12 CatalogSyncAgentCore.ExecuteSyncProtocol Bad Update Revision #1: f3a49632-6c6f-4bed-8698-81490e759510/103

    2013-01-27 13:08:43.561 UTC Error WsusService.12 CatalogSyncAgentCore.ExecuteSyncProtocol Bad Update Revision #2: 6f605520-7281-49ba-821b-8e87610f8aaa/103

    2013-01-27 13:08:43.577 UTC Error WsusService.12 CatalogSyncAgentCore.ExecuteSyncProtocol Bad Update Revision #3: 5092f51e-64b8-4ad4-a169-df0843cc0e4d/103

    2013-01-27 13:10:56.217 UTC Info WsusService.12 EventLogEventReporter.ReportEvent EventId=386,Type=Error,Category=Synchronization,Message=Synchronization failed. Reason: System.Data.SqlClient.SqlException: Cannot insert the value NULL into column 'RevisionID', table '@BundleAll'; column does not allow nulls. INSERT fails.
    Error loading information from upd:BundledUpdates/upd:UpdateIdentity for update 78B86D45-2B71-447D-AE7B-CEDF21E63416\103. Some update revisions in bundle information are not already present in the database.
    The statement has been terminated.

    Thanks for any help.

    kailar

    Montag, 28. Januar 2013 11:31

Antworten

  • So now did workaround and solved the issue finally.

    My last "Import Updates" in January having no effect was done on the upstream server where are locating the four corrupt updates.

    Now I did import the four updates via "Import Updates" on EACH downstream server. Synchronization failure is finally gone.

    Thanks Lawrence,

    Best Regards,

    kailar

    • Als Antwort markiert kailar Dienstag, 28. Mai 2013 13:00
    Dienstag, 28. Mai 2013 12:59

Alle Antworten

  • Any idea?
    Donnerstag, 31. Januar 2013 12:55
  • 2013-01-27 13:08:43.561 UTC Error WsusService.12 CatalogSyncAgentCore.ExecuteSyncProtocol Bad Update Revision #0: 78b86d45-2b71-447d-ae7b-cedf21e63416/103
    2013-01-27 13:08:43.561 UTC Error WsusService.12 CatalogSyncAgentCore.ExecuteSyncProtocol Bad Update Revision #1: f3a49632-6c6f-4bed-8698-81490e759510/103
    2013-01-27 13:08:43.561 UTC Error WsusService.12 CatalogSyncAgentCore.ExecuteSyncProtocol Bad Update Revision #2: 6f605520-7281-49ba-821b-8e87610f8aaa/103
    2013-01-27 13:08:43.577 UTC Error WsusService.12 CatalogSyncAgentCore.ExecuteSyncProtocol Bad Update Revision #3: 5092f51e-64b8-4ad4-a169-df0843cc0e4d/103

    These first three update revisions are all associated with KB968389 which is a valid (but ancient) Windows 2003 Critical Update from October 2009 related to an identified weakness in the authentication system.

    • 78b86d45-2b71-447d-ae7b-cedf21e63416/103 is the Update for Windows Server 2003 (KB968389)
    • f3a49632-6c6f-4bed-8698-81490e759510/103 is the Update for Windows Server 2003 for Itanium-based Systems (KB968389)
    • 6f605520-7281-49ba-821b-8e87610f8aaa/103 is the Update for Windows Server 2003 x64 Edition (KB968389)

    I'm unable to identify the fourth update -- it does not exist in my WSUS server's database.

    2013-01-27 13:10:56.217 UTC Info WsusService.12 EventLogEventReporter.ReportEvent EventId=386,Type=Error,Category=Synchronization,Message=Synchronization failed. Reason: System.Data.SqlClient.SqlException: Cannot insert the value NULL into column 'RevisionID', table '@BundleAll'; column does not allow nulls. INSERT fails.

    The error appears to be happening because the database on the upstream server is showing signs of corruption (maybe a torn page) -- which, btw, could have happened as a result of the installation of KB2720211. The fact that RevisionID has a NULL value is a critical database consistency defect because, as I recently learned, RevisionID is actually the internal key that links many tables together that store the update metadata, so NULL is absolutely an invalid value.

    Best option is to restore the upstream server from backups prior to the appearance of this defect - which, as noted, may be concurrent with the installation of KB2720211.

    Lacking backups, it would amount to rebuilding the upstream server, although you may be able to successfully export update approvals which would likely save a fair amount of rebuild work.

    Another possibility is that if you feel comfortable mucking in the database... and fully understanding that it's totally unsupported and if anything goes wrong at all, then reinstalling will be your only option .. you may be able to identify and repair that NULL value in whichever instance of RevisionID is kicking this sync failure.

    As a starting point you can see if any NULL values for RevisionID show up in these key tables:

    select count(*) from dbo.tbRevision where RevisionID IS NULL

    select count(*) from dbo.tbRevisionInCategory where RevisionID IS NULL

    select count(*) from dbo.tbRevisionLanguage where RevisionID IS NULL

    select count(*) from dbo.tbRevisionExtendedLanguageMask where RevisionID IS NULL

    select count(*) from dbo.tbRevisionExtendedProperty where RevisionID IS NULL

    select count(*) from dbo.tbRevisionSupersedesUpdate where RevisionID IS NULL

    select count(*) from dbo.tb.XML where RevisionID IS NULL

    The correct RevisionID for those three updates are:

    • 78b86d45-2b71-447d-ae7b-cedf21e63416/103 is 43425
    • f3a49632-6c6f-4bed-8698-81490e759510/103 is 43430
    • 6f605520-7281-49ba-821b-8e87610f8aaa/103 is 43442


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.


    Samstag, 2. Februar 2013 01:59
  • Hi Lawrence,

    Thanks for your reply.

    All four updates have the KB968389.
    5092f51e-64b8-4ad4-a169-df0843cc0e4d is the “Update for Windows XP x64 Edition (KB968389)”. RevisionID?

    Your queries found no NULL values at all, so they seem to be clean.

    Further searches like below see the result:

    select * from dbo.tbRevision where RevisionID = 43430 or revisionid= 43425 or revisionid=43442
     result: found only RevisionID 43442
    select * from dbo.tbRevisionInCategory where RevisionID = 43430 or revisionid= 43425 or revisionid=43442
     result: found only RevisionID 43442
    select * from dbo.tbRevisionLanguage where RevisionID = 43430 or revisionid= 43425 or revisionid=43442
     result: found only RevisionID 43442
    select * from dbo.tbRevisionExtendedLanguageMask where RevisionID = 43430 or revisionid= 43425 or revisionid=43442
     result: no such RevisionID’s
    select * from dbo.tbRevisionExtendedProperty where RevisionID = 43430 or revisionid= 43425 or revisionid=43442
     result: no such RevisionID’s
    select * from dbo.tbRevisionSupersedesUpdate where RevisionID = 43430 or revisionid= 43425 or revisionid=43442
     result: no such RevisionID’s
    select * from dbo.tbXML where RevisionID = 43430 or revisionid= 43425 or revisionid=43442
     result: found only RevisionID 43442
    select * from dbo.tbBundleAll where RevisionID = 43430 or revisionid= 43425 or revisionid=43442
     result: no such RevisionID’s

    I have no old backup of the DB, which could solve this problem.
    I hoped it might be possible to muck in the DB, but I could not found any NULL values.

    My other downstream replica servers which are not installed new, do not have this problem. Only the server which I had to install new (due to my last issue)have got this error.

     

    Montag, 4. Februar 2013 16:33
  • All four updates have the KB968389.
    5092f51e-64b8-4ad4-a169-df0843cc0e4d is the “Update for Windows XP x64 Edition (KB968389)”. RevisionID?

    Aha! I don't have XP x64 content synchronized, so that update was likely never in my system.

    Your queries found no NULL values at all, so they seem to be clean.

    Hmmm... well, my queries are not comprehensive, so the lack of a failure is not necessarily conclusive.

    Further searches like below see the result:

    select * from dbo.tbRevision where RevisionID = 43430 or revisionid= 43425 or revisionid=43442
     result: found only RevisionID 43442

    Now that may be significant -- and, in the bigger scheme of things could generate a NULL value from RevisionID in those tables, when a join is done from the tbUpdate table through tbRevision and there's no revision data present.

    Another possible 'fix' would be to use the "Import Updates" functionality, and go get those four updates from the online catalog. This may be sufficient to replace the missing rows in the revision* tables for 43425, 43430, and whatever the RevisionID is for the XP x64 update. To get the RevisionID for the XP x64 update, use this query:

    declare @updateID char(36)
    
    set @updateID = '5092f51e-64b8-4ad4-a169-df0843cc0e4d'
    
    select r.RevisionID
    from dbo.tbUpdate u
    join dbo.tbRevision r on r.LocalUpdateID = u.LocalUpdateID
    where u.UpdateID = @updateID


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.


    Montag, 4. Februar 2013 23:56
  • Hi Lawrence,

    the RevisionID for the '5092f51e-64b8-4ad4-a169-df0843cc0e4d' is the 59943.


    The only RevisionID's found in upstream DB were the 43442 and 59943.


    On downstream replica server found all four RevisionID's in these tables:

    select * from dbo.tbRevision where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943
    select * from dbo.tbRevisionInCategory where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943
    select * from dbo.tbRevisionLanguage where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943
    select * from dbo.tbXML where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943
    select * from tbbundleatleastone where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943

    No such RevisionID' found in these tables on downstream server.

    select * from dbo.tbRevisionExtendedLanguageMask where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943
    select * from dbo.tbRevisionExtendedProperty where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943
    select * from dbo.tbRevisionSupersedesUpdate where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943
    select * from tbbundleall where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943
    select * from tbbundledependency where RevisionID = 43430 or revisionid= 43425 or revisionid=43442 or revisionid=59943


    have done the "Import Updates" function without failure but the error with synch. is not solved jet.

    I saw no changes at DB file time stamp (so no changes?). I am not sure whether that is accomplished. (but the result by importing shows successful)

    kailar
    Dienstag, 5. Februar 2013 16:53
  • Have tried again the "Import Update" function. Selected 8 x KB968389 updates (size 33,4 MB) to import.

    The transaction takes about 25 seconds and tells successful. This seems not to be normal according to that short downloading time. The database gets no new time stamp. So I think there is going to get no changes during that update downloading or importing.

    -I tested to rename one of the mentioned update files, due to mark it as not existing and tried import update, but all the same without any changes. The process goes very fast as successful without any download. The renamed update was not redownloaded.

    -set all KB968389 updates as declined

    -set all KB968389 updates as not approved

    -set all KB968389 updates as approved

    by every step tried to sycnchronize the replica server, error does not disappears.

    Thanks for further help?

    Freitag, 8. Februar 2013 13:12
  • Have tried again the "Import Update" function. Selected 8 x KB968389 updates (size 33,4 MB) to import.

    The transaction takes about 25 seconds and tells successful. This seems not to be normal according to that short downloading time.

    It is absolutely normal, because the Import Update function only imports the update definition, not the binaries. Think in terms of about 5k of XML data coming across the wire (if even that much!).

    The database gets no new time stamp.

    Not unusual. The database *file* would get a new time stamp when the BUFFER is actually flushed to disk.

    -I tested to rename one of the mentioned update files, due to mark it as not existing and tried import update, but all the same without any changes.

    I'm not sure what you think you did, but you cannot delete updates from the console. If the above was an attempt to delete-and-reimport then it won't produce any functional work.

    -set all KB968389 updates as declined

    -set all KB968389 updates as not approved

    -set all KB968389 updates as approved

    by every step tried to sycnchronize the replica server, error does not disappears.

    While totally unsupported .... the last resort option may be to use SQL Server Management Studio to purge all existence of those several RevisionIDs from the various tables in which they exist (the problem with this being that I doubt that list of tables is exhaustive). Most likely since the core entry for those updates still existed, the import had no real work to do (and thus the subordinate tables remain corrupted). Failing to comprehensively purge all referenes to those RevisionIDs may not provide any successful results when attempting to reimport.

    Of course, the other relevant question here is this: Do you need to DEPLOY any of these updates? Do your systems show these updates as 100% Installed/NotApplicable? If so, then I'd just say DECLINE the four updates on the upstream server, put the downstream servers in autonomous mode, DECLINE the four updates there as well, and put them back in replica mode. Run the Server Cleanup Wizard on all servers to delete the files associated with those four updates.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Dienstag, 21. Mai 2013 21:09
  • Hi Lawrence,

    Of course, the other relevant question here is this: Do you need to DEPLOY any of these updates? Do your systems show these updates as 100% Installed/NotApplicable? If so, then I'd just say DECLINE the four updates on the upstream server, put the downstream servers in autonomous mode, DECLINE the four updates there as well, and put them back in replica mode. Run the Server Cleanup Wizard on all servers to delete the files associated with those four updates.

    This issue is existing of all replica downstream servers which I had to rebuild them in last January. The rest other replica downstream servers don't have this problem (these have already the four updates in their DB)

    The case is that, these four KB968389 elements do not exist on the issued downstream servers at all, so no way to decline them.

    In my opinion the only way to solve this issue would be to get rid of these updates on the master UPSTREAM server anyway. But how?

    Best Regards,

    kailar

    Mittwoch, 22. Mai 2013 14:39
  • The four problem updates are already declined on upstream server and I have run the cleanup wizard several times. They are still existing on upstream server.

    Update for Windows Server 2003 x64 Edition (KB968389)                            Critical Updates    968389    13.10.2009    Declined
    Update for Windows XP x64 Edition (KB968389)                                           Critical Updates    968389    13.10.2009    Declined
    Update for Windows Server 2003 for Itanium-based Systems (KB968389)   Critical Updates    968389    13.10.2009    Declined
    Update for Windows Server 2003 (KB968389)                                              Critical Updates    968389    13.10.2009    Declined

    9 of the downstream servers which where rebuild in Jan., have this issue by trying to import these in their DB.

    13 rest downstream servers which are NOT rebuild and have already the above updates in their DB, don't have this issue.

    Every time the same error in the logfile as in my first statement above:

    ...

    Info    WsusService.11    EventLogEventReporter.ReportEvent    EventId=386,Type=Error,Category=Synchronization,Message=Synchronization failed. Reason: System.Data.SqlClient.SqlException: Cannot insert the value NULL into column 'RevisionID', table '@BundleAll'; column does not allow nulls. INSERT fails.
    Error loading information from upd:BundledUpdates/upd:UpdateIdentity for update 78B86D45-2B71-447D-AE7B-CEDF21E63416\103. Some update revisions in bundle information are not already present in the database.
    The statement has been terminated.

    ...

    kailar

    Montag, 27. Mai 2013 11:49
  • The four problem updates are already declined on upstream server and I have run the cleanup wizard several times. They are still existing on upstream server.

    Correct. You cannot DELETE updates. They will continue to exist forever, as they should.

    Every time the same error in the logfile as in my first statement above:

    ...

    Info    WsusService.11    EventLogEventReporter.ReportEvent    EventId=386,Type=Error,Category=Synchronization,Message=Synchronization failed. Reason: System.Data.SqlClient.SqlException: Cannot insert the value NULL into column 'RevisionID', table '@BundleAll'; column does not allow nulls. INSERT fails.

    I think the only valid conclusion to draw here is that you have a corrupted database, and rebuilding the WSUS server(s) with a new database is the only way to resolve this issue beyond declining and ignoring the updates -- which isn't going to solve your synchronization failures -- and that's a critical operational issue that would seem to need to be resolved.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Als Antwort markiert kailar Dienstag, 28. Mai 2013 12:59
    • Tag als Antwort aufgehoben kailar Dienstag, 28. Mai 2013 13:00
    Montag, 27. Mai 2013 21:35
  • So now did workaround and solved the issue finally.

    My last "Import Updates" in January having no effect was done on the upstream server where are locating the four corrupt updates.

    Now I did import the four updates via "Import Updates" on EACH downstream server. Synchronization failure is finally gone.

    Thanks Lawrence,

    Best Regards,

    kailar

    • Als Antwort markiert kailar Dienstag, 28. Mai 2013 13:00
    Dienstag, 28. Mai 2013 12:59
  • Now I did import the four updates via "Import Updates" on EACH downstream server. Synchronization failure is finally gone.

    Interesting that they would import to the replica server, but not sync to the replica server. I never even though of trying to import them to the downstream server. Good call. It worked!

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Donnerstag, 30. Mai 2013 02:12