none
WSUS Downstream server not synchronizing - SQL Timeout RRS feed

  • Question

  • I'm running into problems synching a downstream WSUS server with the parent server. The first few times that the server synch'd it ran fine, then it just stopped working. The Windows Firewall is disabled and there is no proxy. I've checked all the permissions for IIS and all required services are running. I've also tried an IISRESET, uninstall WSUS, re-installed, ran wsusutil.exe reset and checkhealth, rebooted many times. Ran the DB Cleanup Wizard on both servers. Any help woul be appreciated.

    WSUS Parent Server: Windows Server 2003 R2 SP2

    WSUS Downstream Server: Windows Server 2003 R2 SP2

    WSUS Failed Error Message:

    SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
       at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
       at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
       at System.Data.SqlClient.SqlDataReader.ReadInternal(Boolean setTimeout)
       at System.Data.SqlClient.SqlDataReader.Read()
       at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ReadOneRow()
       at Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlUpdateIds)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid[] hiddenUpdates)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
       at Microsoft.UpdateServic

    Thank You

    Tuesday, June 1, 2010 1:04 AM

Answers

  • Thank you for the info. One of the requisites of a replica server environment is that both the upstream server and replica servers have identical configurations, so my interest here was to see if I could identify any inconsistencies in their configurations. The challenge, however, with this process is that the output of the WSUSDebugTool/GetConfiguration is not publicly documented, so the best I can do is speculate on what appears to be the most logical conclusions based on the information provided.

    I found two items of interest

    UPSTREAM SERVER:

     IIsDynamicCompression:0

    <NewDataSet>
      <Table>
        <ServerTargeting>false</ServerTargeting>
      </Table>
    </NewDataSet>

    DOWNSTREAM SERVER:

     IIsDynamicCompression:-1

    <NewDataSet>
      <Table>
        <ServerTargeting>true</ServerTargeting>
      </Table>
    </NewDataSet>

    The first item is that the value IIsDynamicCompression is different on the two servers. Presuming the standard tradition of '0 = False' and 'Not 0 = True', it appears that Dynamic Compression may be disabled on your upstream server. Dynamic Compression is not enabled by default on Windows Server 2008/IIS7, and as documented in the WSUS installation guides, must be explicitly enabled in IIS7. Dynamic Compression is enabled by default on Windows Server 2003/IIS6; however, it would appear in this case that your upstream Win2003R2/SP2 server may have had Dynamic Compression explicitly disabled.

    The second thing I observed is that the servers have disparate settings as to "ServerTargeting", which I believe is the tag for the Options | Computers setting that configures the choice between server-side targeting and client-side targeting. On an autonomous downstream server these values can be different; however, on a replica they must be the same as the upstream server. In the instant case it appears that the upstream server is using client-side targeting, but the replica server is using server-side targeting (and if you did not explicitly check this setting when you installed the test server, this is not unexpected). I'm still pondering the ramifications of these settings, and it may not even be impacting the synchronization. I suspect that your production servers do have client-side targeting enabled, and this particular instance is a red herring.

    I think the real issue is the question of compression and the sync failures are a manifestation of the downsteam replica servers compressing content during the reporting rollup cycle that the upstream server doesn't know what to do with because it has compression disabled. (Note also that the SoftwareDistribution logs suggest that the replicas did acquire the update metadata, but I don't recall seeing any log entries regarding computer status information going upstream.)


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, June 3, 2010 1:09 AM
    Moderator

All replies

  • SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

    There are generally two scenarios in which you'll see SQL Timeout errors during a server synchronization; but the first key is to determine where the timeout is occuring -- it is the replica server trying to communicate with its own database, or is it the upstream server trying to communicate with the upstream database.

    If you could provide some additional detail as to how the databases of these two servers are implemented, as well as the type of data communications link that exists between them, I can speculate a bit more on where the likely cause of the timeouts are occuring. For example, remote databases are a high probability target for this type of issue, particularly if the database is across a WAN connection.

    One diagnostic you can try is to reconfigure the downstream server to see if it can synchronize with Microsoft. If it can, that would suggest that the downstream server is not the culprit. You should also review the system logs of the upstream server and ensure there are no other issues with that server, independent of the presence of the downstream server.

     


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, June 1, 2010 2:56 PM
    Moderator
  • "If you could provide some additional detail as to how the databases of these two servers are implemented"

    I'm using the Windows Internal Database and the downstream server is scheduled to sync with the upstream server across the WAN. The Parent server is the only server with a connection out to the Internet. I did notice that if I turn off the "Replication" settings on the downstream server and just point the downstream server to the upstream server, it will synchronize successfully. Once I turn the replication settings back on, the synchronization fails every time. Also, I have 6 downstream servers and they are all failing, so I don't think the downstream server is the culprit.

    I've also reviewed the event logs and system logs on the upstream server and I don't see anything out of the normal. They show that the upstream server is synchronizing without any errors.

    Thank you

    Tuesday, June 1, 2010 3:31 PM
  • Also, I have 6 downstream servers and they are all failing, so I don't think the downstream server is the culprit.

    Are the downstream servers synchronizing simultaneously? or are their scheduled staggered?

    How many clients are assigned to the upstream server? What is the detection interval of the clients assigned to the upstream server?

    I'm intrigued that enabling/disabling Replica mode would introduce this issue. The difference between the two modes is that the replica server also synchronizes update approvals, whereas autonomous mode only synchronizes the metadata.

    To that consideration: How long has the upstream server been in service? When is the last time the upstream server had the Server Cleanup Wizard executed? How many languages are configured on the upstream server? the replica servers? What is the physical size of the SUSDB.mdf on the upstream server?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, June 1, 2010 7:06 PM
    Moderator
  • "Are the downstream servers synchronizing simultaneously? or are their scheduled staggered?"

    The schedules are staggered, 1 every 2 hours. The upstream server synch's at 6PM and the downstream servers start at 7PM. I've also monitored the bandwidth between the locations and the pipe looks fine.

    "How many clients are assigned to the upstream server? What is the detection interval of the clients assigned to the upstream server?"

    There are 300 clients assigned to the upstream server and the detection interval is the default 22 hours.

    "To that consideration: How long has the upstream server been in service?"

    1 month

    "When is the last time the upstream server had the Server Cleanup Wizard executed?"

    Yesterday

    "How many languages are configured on the upstream server? the replica servers?"

    English

    "What is the physical size of the SUSDB.mdf on the upstream server?"

    2.9GB

    I was able to take one of the downstream servers and connect it directly to the internet and it was able to sync with Microsoft. Then I changed the settings back to the upstream server and replica and the sync failed. I should also mention that I've disabled the Windows Firewall to see if it was a port issue, but that doesn't seem to be the case. All servers are fully patched and running IIS 6.0 and IE7. I did have to remove the Internet Enhanced Security Settings from the "Add/Remove" Windows components because it was blocking me from installing anything on my servers.

    Thanks for your help! Look forward to your response :) 

    Tuesday, June 1, 2010 9:00 PM
  • Hmmm.... there is nothing in that scenario that should impact the performance of a replica server synchronization.

    I suspect, however, the key lies in this statement. The statement strongly suggests that "something changed", and the answer may well be in identifying What Changed?

    > The first few times that the server synch'd it ran fine, then it just stopped working.

    Is there anything notable about the time at which it stopped working. Do your network or security guys have any information on any system configuration changes that occurred at that time? Were any configuration changes made to the WSUS server(s) at that time?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, June 1, 2010 10:11 PM
    Moderator
  • I've checked with everyone and nobody is aware of any changes in AD or any security policies. The only thing that I did was approve the latest round of updates and soon after the synchronizations started failing. That's when I ran the Cleanup Wizard on all of the servers. Could one of the updates be corrupt?

    Another thought is that we're using WAN Accelerators at the different locations. Could those be causing an issue?

    I'm going to setup a test WSUS server at our parent location where the upstream server is location and see if it will synch across the LAN. If that works then it must be something in our WAN configuration.

     

    Wednesday, June 2, 2010 1:21 PM
  • Another thought is that we're using WAN Accelerators at the different locations. Could those be causing an issue?

    I'm going to setup a test WSUS server at our parent location where the upstream server is location and see if it will synch across the LAN. If that works then it must be something in our WAN configuration.


    Could be. Good diagnostic step. Let us know the results.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, June 2, 2010 2:53 PM
    Moderator
  • We setup a test server for WSUS on the same LAN as the upstream server and the initial sych still failed. However there is a new message in the "SoftwareDistribution.log" file:

    2010-06-02 19:47:05.595 UTC Info w3wp.39 RevisionIdCache.UpdateCategoryCache Refreshing the category cache
    2010-06-02 19:47:05.595 UTC Info w3wp.39 RevisionIdCache.UpdateRevisionCache Refreshing the revision cache
    2010-06-02 19:51:36.867 UTC Info w3wp.40 DependencyCache.RefreshThreadStart read 104846 UpdateIDs from DB in 1296 ms
    2010-06-02 19:58:34.219 UTC Info w3wp.29 ThreadEntry PipelineRuntime.ProcessRequestNotification
    2010-06-02 19:58:34.234 UTC Warning w3wp.29 DBConnection.OnReceivingInfoMessage  The join order has been enforced because a local join hint is used.
    2010-06-02 19:58:34.234 UTC Warning w3wp.29 DBConnection.OnReceivingInfoMessage  The join order has been enforced because a local join hint is used.

    And idea's on what that warning message means?

    Wednesday, June 2, 2010 8:12 PM
  • 2010-06-02 19:58:34.234 UTC Warning w3wp.29 DBConnection.OnReceivingInfoMessage  The join order has been enforced because a local join hint is used.
    2010-06-02 19:58:34.234 UTC Warning w3wp.29 DBConnection.OnReceivingInfoMessage  The join order has been enforced because a local join hint is used.

    And idea's on what that warning message means?

    It's "internal SQL" notes commenting on how the data retrieval was implemented, and likely has no real bearing on your situation.

     


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, June 2, 2010 8:55 PM
    Moderator
  • We setup a test server for WSUS on the same LAN as the upstream server and the initial sych still failed.

    Did you synchronize both as replica and autonomous downstream server?

    If so, did both syncs fail, or only the sync of the replica server (as was observed with the other servers)?

    Can you run the WSUSDebugTool /Tool:GetConfiguration utility on both of these servers and post the results?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, June 2, 2010 8:57 PM
    Moderator
  • Sure, here are the log files. Thank you!

    UPSTREAM SERVER:

    Running... GetConfiguration
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup
     :
     Version:3
     InstallLanguage:ENU
     ProxyPassword:
     SmtpUserPassword:
     VersionString:3.2.7600.226
     ConfigurationSource:0
     ServicePackLevel:2
     TargetDir:C:\Program Files\Update Services\
     InstallType:1
     EnableRemoting:1
     WsusAdministratorsSid:S-1-5-21-163115894-1154025269-1635805901-1010
     WSUSReportersSid:S-1-5-21-163115894-1154025269-1635805901-1009
     SqlServerName:WSUSDAL\MICROSOFT##SSEE
     SqlAuthenticationMode:WindowsAuthentication
     SqlDatabaseName:SUSDB
     SqlUserName:
     SqlEncryptedPassword:
     SqlInstanceIsRemote:0
     wYukonInstalled:1
     ContentDir:E:\WSUS
     PortNumber:8530
     IISTargetWebSiteIndex:625045861
     IISTargetWebSiteCreated:True
     IISUninstallConfigFilePath:C:\Program Files\Update Services\setup\UninstallSettings.xml
     IISPreviousInstallRevision:
     IISInstallRevision:3.2.7600.226
     IIsDynamicCompression:0
     EncryptionParam:System.Byte[]
     EncryptionKey:System.Byte[]
    <NewDataSet>
      <Table>
        <ConfigurationID>1</ConfigurationID>
        <LastConfigChange>2010-05-30T21:19:36.8700000-05:00</LastConfigChange>
        <DssAnonymousTargeting>false</DssAnonymousTargeting>
        <IsRegistrationRequired>true</IsRegistrationRequired>
        <MaxDeltaSyncPeriod>30</MaxDeltaSyncPeriod>
        <ReportingServiceUrl>https://stats.update.microsoft.com</ReportingServiceUrl>
        <ServerID>c48b3181-a77e-4a88-8986-3dd6bf07c291</ServerID>
        <AnonymousCookieExpirationTime>10080</AnonymousCookieExpirationTime>
        <SimpleTargetingCookieExpirationTime>60</SimpleTargetingCookieExpirationTime>
        <MaximumServerCookieExpirationTime>10080</MaximumServerCookieExpirationTime>
        <DssTargetingCookieExpirationTime>240</DssTargetingCookieExpirationTime>
        <EncryptionKey>dE3WZ7GGMBOpG/ftJuzo7lDLHBFVT7VR</EncryptionKey>
        <ServerTargeting>false</ServerTargeting>
        <SyncToMU>true</SyncToMU>
        <UpstreamServerName>SUSDal</UpstreamServerName>
        <ServerPortNumber>8530</ServerPortNumber>
        <UpstreamServerUseSSL>false</UpstreamServerUseSSL>
        <UseProxy>false</UseProxy>
        <ProxyName />
        <ProxyServerPort>80</ProxyServerPort>
        <AnonymousProxyAccess>true</AnonymousProxyAccess>
        <ProxyUserName />
        <HostOnMu>false</HostOnMu>
        <LocalContentCacheLocation>e:\WSUS\WsusContent\</LocalContentCacheLocation>
        <ServerSupportsAllLanguages>false</ServerSupportsAllLanguages>
        <LogLevel>0</LogLevel>
        <LogPath />
        <SubscriptionFailureNumberOfRetries>3</SubscriptionFailureNumberOfRetries>
        <SubscriptionFailureWaitBetweenRetriesTime>15</SubscriptionFailureWaitBetweenRetriesTime>
        <DispatchManagerPollingInterval>5</DispatchManagerPollingInterval>
        <StateMachineTransitionLoggingEnabled>false</StateMachineTransitionLoggingEnabled>
        <StateMachineTransitionErrorCaptureLength>600</StateMachineTransitionErrorCaptureLength>
        <MaxSimultaneousFileDownloads>10</MaxSimultaneousFileDownloads>
        <MUUrl>https://www.update.microsoft.com/v6</MUUrl>
        <EventLogFloodProtectTime>10</EventLogFloodProtectTime>
        <HandshakeAnchor>13270510,2010-06-02 21:12:31.056</HandshakeAnchor>
        <StatsDotNetWebServiceUri>http://localhost</StatsDotNetWebServiceUri>
        <QueueFlushTimeInMS>3000</QueueFlushTimeInMS>
        <QueueFlushCount>100</QueueFlushCount>
        <QueueRejectCount>500</QueueRejectCount>
        <SleepTimeAfterErrorInMS>30000</SleepTimeAfterErrorInMS>
        <LogDestinations>0</LogDestinations>
        <AutoRefreshDeployments>true</AutoRefreshDeployments>
        <RedirectorChangeNumber>0</RedirectorChangeNumber>
        <ImportLocalPath />
        <UseCookieValidation>true</UseCookieValidation>
        <AutoPurgeClientEventAgeThreshold>15</AutoPurgeClientEventAgeThreshold>
        <AutoPurgeServerEventAgeThreshold>90</AutoPurgeServerEventAgeThreshold>
        <AutoPurgeDetectionPeriod>12</AutoPurgeDetectionPeriod>
        <DoReportingDataValidation>true</DoReportingDataValidation>
        <DoReportingSummarization>true</DoReportingSummarization>
        <MaxNumberOfIdsToRequestDataFromUss>100</MaxNumberOfIdsToRequestDataFromUss>
        <MaxCoreUpdatesPerRequest>30</MaxCoreUpdatesPerRequest>
        <MaxExtendedUpdatesPerRequest>50</MaxExtendedUpdatesPerRequest>
        <DownloadRegulationUrl />
        <AllowProxyCredentialsOverNonSsl>false</AllowProxyCredentialsOverNonSsl>
        <LazySync>true</LazySync>
        <DownloadExpressPackages>false</DownloadExpressPackages>
        <DoServerSyncCompression>true</DoServerSyncCompression>
        <ProxyUserDomain />
        <BitsHealthScanningInterval>3600000</BitsHealthScanningInterval>
        <BitsDownloadPriorityForeground>false</BitsDownloadPriorityForeground>
        <MaxXmlPerRequest>5242880</MaxXmlPerRequest>
        <MaxXmlPerRequestInServerSync>2000000</MaxXmlPerRequestInServerSync>
        <MaxTargetComputers>30000</MaxTargetComputers>
        <MaxEventInstances>2000000</MaxEventInstances>
        <LogRolloverFileSizeInBytes>0</LogRolloverFileSizeInBytes>
        <WUSInstallType>0</WUSInstallType>
        <ReplicaMode>false</ReplicaMode>
        <AutoDeployMandatory>true</AutoDeployMandatory>
        <DeploymentChangeDeferral>30</DeploymentChangeDeferral>
        <RevisionDeletionTimeThreshold>30</RevisionDeletionTimeThreshold>
        <RevisionDeletionSizeThreshold>1024</RevisionDeletionSizeThreshold>
        <CollectClientInventory>false</CollectClientInventory>
        <DoDetailedRollup>true</DoDetailedRollup>
        <RollupResetGuid>83340a0d-4624-4cb9-bc30-db197c999bc8</RollupResetGuid>
        <UssSupportsAllLanguages>false</UssSupportsAllLanguages>
        <GetContentFromMU>false</GetContentFromMU>
        <HmDetectIntervalInSeconds>600</HmDetectIntervalInSeconds>
        <HmRefreshIntervalInSeconds>21600</HmRefreshIntervalInSeconds>
        <HmCoreDiskSpaceGreenMegabytes>500</HmCoreDiskSpaceGreenMegabytes>
        <HmCoreDiskSpaceRedMegabytes>200</HmCoreDiskSpaceRedMegabytes>
        <HmCoreCatalogSyncIntervalInDays>1</HmCoreCatalogSyncIntervalInDays>
        <HmClientsInstallUpdatesGreenPercent>10</HmClientsInstallUpdatesGreenPercent>
        <HmClientsInstallUpdatesRedPercent>25</HmClientsInstallUpdatesRedPercent>
        <HmClientsInventoryGreenPercent>2</HmClientsInventoryGreenPercent>
        <HmClientsInventoryRedPercent>5</HmClientsInventoryRedPercent>
        <HmClientsInventoryScanDiffInHours>30</HmClientsInventoryScanDiffInHours>
        <HmClientsSilentGreenPercent>10</HmClientsSilentGreenPercent>
        <HmClientsSilentRedPercent>25</HmClientsSilentRedPercent>
        <HmClientsSilentDays>30</HmClientsSilentDays>
        <DssRollupChunkSize>5000</DssRollupChunkSize>
        <MURollupOptin>False</MURollupOptin>
        <AutoRefreshDeploymentsDeclineExpired>true</AutoRefreshDeploymentsDeclineExpired>
        <ServerString>Default</ServerString>
        <HmCoreFlags>-1</HmCoreFlags>
        <HmClientsFlags>-1</HmClientsFlags>
        <HmDatabaseFlags>-1</HmDatabaseFlags>
        <HmWebServicesFlags>-1</HmWebServicesFlags>
        <ClientReportingLevel>2</ClientReportingLevel>
        <LocalPublishingMaxCabSize>384</LocalPublishingMaxCabSize>
        <DownloadRegulationWebServiceUrl />
        <LoadOdfLocally>false</LoadOdfLocally>
        <OdfFilePath />
        <HmClientsTooManyGreenPercent>80</HmClientsTooManyGreenPercent>
        <HmClientsTooManyRedPercent>90</HmClientsTooManyRedPercent>
        <ComputerDeletionTimeThreshold>30</ComputerDeletionTimeThreshold>
        <ConfigurationChangeNumber>137118</ConfigurationChangeNumber>
        <UseSeparateProxyForSsl>false</UseSeparateProxyForSsl>
        <SslProxyName />
        <SslProxyServerPort>443</SslProxyServerPort>
        <ServerSupportsAllAvailableLanguages>false</ServerSupportsAllAvailableLanguages>
      </Table>
    </NewDataSet>

    DOWNSTREAM SERVER:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup
     :
     Version:3
     InstallLanguage:ENU
     ProxyPassword:
     SmtpUserPassword:
     VersionString:3.2.7600.226
     ConfigurationSource:0
     ServicePackLevel:2
     TargetDir:C:\Program Files\Update Services\
     InstallType:1
     EnableRemoting:1
     WsusAdministratorsSid:S-1-5-21-2105027866-1443240842-1445603992-20366
     WSUSReportersSid:S-1-5-21-2105027866-1443240842-1445603992-19384
     SqlServerName:SUSFTW\MICROSOFT##SSEE
     SqlAuthenticationMode:WindowsAuthentication
     SqlDatabaseName:SUSDB
     SqlUserName:
     SqlEncryptedPassword:
     SqlInstanceIsRemote:0
     wYukonInstalled:1
     ContentDir:D:\WSUS
     PortNumber:8530
     IISTargetWebSiteIndex:602037408
     IISTargetWebSiteCreated:True
     IISUninstallConfigFilePath:C:\Program Files\Update Services\setup\UninstallSettings.xml
     IISPreviousInstallRevision:
     IISInstallRevision:3.2.7600.226
     IIsDynamicCompression:-1
     EncryptionParam:System.Byte[]
     EncryptionKey:System.Byte[]
    <NewDataSet>
      <Table>
        <ConfigurationID>1</ConfigurationID>
        <LastConfigChange>2010-06-02T00:00:35.0200000-05:00</LastConfigChange>
        <DssAnonymousTargeting>false</DssAnonymousTargeting>
        <IsRegistrationRequired>true</IsRegistrationRequired>
        <MaxDeltaSyncPeriod>30</MaxDeltaSyncPeriod>
        <ReportingServiceUrl>https://stats.update.microsoft.com</ReportingServiceUrl>
        <ServerID>dac8845b-855c-4899-ab19-8bf7a750514f</ServerID>
        <AnonymousCookieExpirationTime>10080</AnonymousCookieExpirationTime>
        <SimpleTargetingCookieExpirationTime>60</SimpleTargetingCookieExpirationTime>
        <MaximumServerCookieExpirationTime>10080</MaximumServerCookieExpirationTime>
        <DssTargetingCookieExpirationTime>240</DssTargetingCookieExpirationTime>
        <EncryptionKey>VoxRFFCoICrJYoTjr5WL1aOzfX1CSL9m</EncryptionKey>
        <ServerTargeting>true</ServerTargeting>
        <SyncToMU>false</SyncToMU>
        <UpstreamServerName>WSUSDAL</UpstreamServerName>
        <ServerPortNumber>8530</ServerPortNumber>
        <UpstreamServerUseSSL>false</UpstreamServerUseSSL>
        <UseProxy>false</UseProxy>
        <ProxyName />
        <ProxyServerPort>80</ProxyServerPort>
        <AnonymousProxyAccess>true</AnonymousProxyAccess>
        <ProxyUserName />
        <HostOnMu>false</HostOnMu>
        <LocalContentCacheLocation>d:\WSUS\WsusContent\</LocalContentCacheLocation>
        <ServerSupportsAllLanguages>false</ServerSupportsAllLanguages>
        <LogLevel>0</LogLevel>
        <LogPath />
        <SubscriptionFailureNumberOfRetries>3</SubscriptionFailureNumberOfRetries>
        <SubscriptionFailureWaitBetweenRetriesTime>15</SubscriptionFailureWaitBetweenRetriesTime>
        <DispatchManagerPollingInterval>5</DispatchManagerPollingInterval>
        <StateMachineTransitionLoggingEnabled>false</StateMachineTransitionLoggingEnabled>
        <StateMachineTransitionErrorCaptureLength>600</StateMachineTransitionErrorCaptureLength>
        <MaxSimultaneousFileDownloads>10</MaxSimultaneousFileDownloads>
        <MUUrl>https://www.update.microsoft.com/v6</MUUrl>
        <EventLogFloodProtectTime>10</EventLogFloodProtectTime>
        <HandshakeAnchor>136861,2010-06-02 00:00:34.112</HandshakeAnchor>
        <StatsDotNetWebServiceUri>http://localhost</StatsDotNetWebServiceUri>
        <QueueFlushTimeInMS>3000</QueueFlushTimeInMS>
        <QueueFlushCount>100</QueueFlushCount>
        <QueueRejectCount>500</QueueRejectCount>
        <SleepTimeAfterErrorInMS>30000</SleepTimeAfterErrorInMS>
        <LogDestinations>0</LogDestinations>
        <AutoRefreshDeployments>true</AutoRefreshDeployments>
        <RedirectorChangeNumber>0</RedirectorChangeNumber>
        <ImportLocalPath />
        <UseCookieValidation>true</UseCookieValidation>
        <AutoPurgeClientEventAgeThreshold>15</AutoPurgeClientEventAgeThreshold>
        <AutoPurgeServerEventAgeThreshold>90</AutoPurgeServerEventAgeThreshold>
        <AutoPurgeDetectionPeriod>12</AutoPurgeDetectionPeriod>
        <DoReportingDataValidation>true</DoReportingDataValidation>
        <DoReportingSummarization>true</DoReportingSummarization>
        <MaxNumberOfIdsToRequestDataFromUss>100</MaxNumberOfIdsToRequestDataFromUss>
        <MaxCoreUpdatesPerRequest>30</MaxCoreUpdatesPerRequest>
        <MaxExtendedUpdatesPerRequest>50</MaxExtendedUpdatesPerRequest>
        <DownloadRegulationUrl />
        <AllowProxyCredentialsOverNonSsl>false</AllowProxyCredentialsOverNonSsl>
        <LazySync>true</LazySync>
        <DownloadExpressPackages>false</DownloadExpressPackages>
        <DoServerSyncCompression>true</DoServerSyncCompression>
        <ProxyUserDomain />
        <BitsHealthScanningInterval>3600000</BitsHealthScanningInterval>
        <BitsDownloadPriorityForeground>false</BitsDownloadPriorityForeground>
        <MaxXmlPerRequest>5242880</MaxXmlPerRequest>
        <MaxXmlPerRequestInServerSync>2000000</MaxXmlPerRequestInServerSync>
        <MaxTargetComputers>30000</MaxTargetComputers>
        <MaxEventInstances>2000000</MaxEventInstances>
        <LogRolloverFileSizeInBytes>0</LogRolloverFileSizeInBytes>
        <WUSInstallType>0</WUSInstallType>
        <ReplicaMode>true</ReplicaMode>
        <AutoDeployMandatory>true</AutoDeployMandatory>
        <DeploymentChangeDeferral>30</DeploymentChangeDeferral>
        <RevisionDeletionTimeThreshold>30</RevisionDeletionTimeThreshold>
        <RevisionDeletionSizeThreshold>1024</RevisionDeletionSizeThreshold>
        <CollectClientInventory>false</CollectClientInventory>
        <DoDetailedRollup>true</DoDetailedRollup>
        <RollupResetGuid>83340a0d-4624-4cb9-bc30-db197c999bc8</RollupResetGuid>
        <UssSupportsAllLanguages>false</UssSupportsAllLanguages>
        <GetContentFromMU>false</GetContentFromMU>
        <HmDetectIntervalInSeconds>600</HmDetectIntervalInSeconds>
        <HmRefreshIntervalInSeconds>21600</HmRefreshIntervalInSeconds>
        <HmCoreDiskSpaceGreenMegabytes>500</HmCoreDiskSpaceGreenMegabytes>
        <HmCoreDiskSpaceRedMegabytes>200</HmCoreDiskSpaceRedMegabytes>
        <HmCoreCatalogSyncIntervalInDays>1</HmCoreCatalogSyncIntervalInDays>
        <HmClientsInstallUpdatesGreenPercent>10</HmClientsInstallUpdatesGreenPercent>
        <HmClientsInstallUpdatesRedPercent>25</HmClientsInstallUpdatesRedPercent>
        <HmClientsInventoryGreenPercent>2</HmClientsInventoryGreenPercent>
        <HmClientsInventoryRedPercent>5</HmClientsInventoryRedPercent>
        <HmClientsInventoryScanDiffInHours>30</HmClientsInventoryScanDiffInHours>
        <HmClientsSilentGreenPercent>10</HmClientsSilentGreenPercent>
        <HmClientsSilentRedPercent>25</HmClientsSilentRedPercent>
        <HmClientsSilentDays>30</HmClientsSilentDays>
        <DssRollupChunkSize>5000</DssRollupChunkSize>
        <MURollupOptin>False</MURollupOptin>
        <AutoRefreshDeploymentsDeclineExpired>true</AutoRefreshDeploymentsDeclineExpired>
        <ServerString>Default</ServerString>
        <HmCoreFlags>-1</HmCoreFlags>
        <HmClientsFlags>-1</HmClientsFlags>
        <HmDatabaseFlags>-1</HmDatabaseFlags>
        <HmWebServicesFlags>-1</HmWebServicesFlags>
        <ClientReportingLevel>2</ClientReportingLevel>
        <LocalPublishingMaxCabSize>384</LocalPublishingMaxCabSize>
        <DownloadRegulationWebServiceUrl />
        <LoadOdfLocally>false</LoadOdfLocally>
        <OdfFilePath />
        <HmClientsTooManyGreenPercent>80</HmClientsTooManyGreenPercent>
        <HmClientsTooManyRedPercent>90</HmClientsTooManyRedPercent>
        <ComputerDeletionTimeThreshold>30</ComputerDeletionTimeThreshold>
        <ConfigurationChangeNumber>76409</ConfigurationChangeNumber>
        <UseSeparateProxyForSsl>false</UseSeparateProxyForSsl>
        <SslProxyName />
        <SslProxyServerPort>443</SslProxyServerPort>
        <ServerSupportsAllAvailableLanguages>false</ServerSupportsAllAvailableLanguages>
      </Table>
    </NewDataSet>

    Wednesday, June 2, 2010 10:02 PM
  • Thank you for the info. One of the requisites of a replica server environment is that both the upstream server and replica servers have identical configurations, so my interest here was to see if I could identify any inconsistencies in their configurations. The challenge, however, with this process is that the output of the WSUSDebugTool/GetConfiguration is not publicly documented, so the best I can do is speculate on what appears to be the most logical conclusions based on the information provided.

    I found two items of interest

    UPSTREAM SERVER:

     IIsDynamicCompression:0

    <NewDataSet>
      <Table>
        <ServerTargeting>false</ServerTargeting>
      </Table>
    </NewDataSet>

    DOWNSTREAM SERVER:

     IIsDynamicCompression:-1

    <NewDataSet>
      <Table>
        <ServerTargeting>true</ServerTargeting>
      </Table>
    </NewDataSet>

    The first item is that the value IIsDynamicCompression is different on the two servers. Presuming the standard tradition of '0 = False' and 'Not 0 = True', it appears that Dynamic Compression may be disabled on your upstream server. Dynamic Compression is not enabled by default on Windows Server 2008/IIS7, and as documented in the WSUS installation guides, must be explicitly enabled in IIS7. Dynamic Compression is enabled by default on Windows Server 2003/IIS6; however, it would appear in this case that your upstream Win2003R2/SP2 server may have had Dynamic Compression explicitly disabled.

    The second thing I observed is that the servers have disparate settings as to "ServerTargeting", which I believe is the tag for the Options | Computers setting that configures the choice between server-side targeting and client-side targeting. On an autonomous downstream server these values can be different; however, on a replica they must be the same as the upstream server. In the instant case it appears that the upstream server is using client-side targeting, but the replica server is using server-side targeting (and if you did not explicitly check this setting when you installed the test server, this is not unexpected). I'm still pondering the ramifications of these settings, and it may not even be impacting the synchronization. I suspect that your production servers do have client-side targeting enabled, and this particular instance is a red herring.

    I think the real issue is the question of compression and the sync failures are a manifestation of the downsteam replica servers compressing content during the reporting rollup cycle that the upstream server doesn't know what to do with because it has compression disabled. (Note also that the SoftwareDistribution logs suggest that the replicas did acquire the update metadata, but I don't recall seeing any log entries regarding computer status information going upstream.)


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, June 3, 2010 1:09 AM
    Moderator
  • Lawrence,

    You might be on to something. When I first installed WSUS 3.0 SP2 (upgraded from WSUS 2.0) on the upstream server (Server A) the installation failed and corrupted the database. I then took a downstream server (Server B), pointed it to Microsoft, upgraded it from WSUS 2.0 to WSUS 3.0 SP2 and promoted it to an upstream server. I then demoted the old upstream server (Server A) to a downstream server and synched it with the new upstream server (Server B). So now Server B was the upstream server and Server A was the downstream server. Once Server B replicated with Server A, I switched them back to their original configurations - Server A Upstream, Server B Downstream.

    It's also important to note that when we upgraded from WSUS 2.0 t0 WSUS 3.0 SP2, we changed from using server-side targeting to client-side targeting. That might explain why there is a difference in the configurations. As for the log files, the logs that I posted were from production servers at different locations. Considering my explanation from above, that would explain why the upstream server is using server-side targeting while the downstream servers are using client-side.

    As for the IISDynamicCompression, it's really hard to say why the configurations are different. And at this point, starting over with the upstream server sounds like my best option.

    I'll rebuild the upstream server tonight and let you know the results.

    Thank you

     

    Thursday, June 3, 2010 1:45 AM
  • Lawrence,

    I re-built the upstream server and was able to synch across the LAN with the test WSUS machine. Will see tonight if the production downstream server will synch across the WAN.

    Thank you

    Thursday, June 3, 2010 10:00 PM
  • Lawrence,

     

    The re-build of the upstream server resolved the synchronization issue with all of the downstream servers. Thank you for your assistance!

    Friday, June 4, 2010 2:37 PM
  • Lawrence,

     

    The re-build of the upstream server resolved the synchronization issue with all of the downstream servers. Thank you for your assistance!


    And how did you rebuild the upstream server??

    I'm facing the same problem...!

    Thanks!


    Att,
    lpozatti
    --------
    CompTIA Security+
    CobIT Foundation
    MCP
    Monday, June 6, 2011 4:07 PM
  • Hello Lawrence and lpozatti,

    same issue in my office. Could you describe the re-build process.

     

    Thanks,

    ronny.h

    Thursday, June 16, 2011 8:18 AM
  • same issue in my office. Could you describe the re-build process.
    Uhhh... Uninstall. Reboot. Install. :-)
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, June 17, 2011 1:17 AM
    Moderator
  • Hi Lawrence it seems I am having the similar issue where when I synch my downstream server directly to MS it synchs fine. It also synchs fine with upstream server when I uncheck replica mode but whenever I check replica mode I continue to get datastore sql exception that states:

     

    SqlException: Transaction (Process ID 71) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
    at Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e)
       at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteCommandNoResult()
       at Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlUpdateIds)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid[] hiddenUpdates)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)

     

    But my symptoms are very similar to what rkymtnbaby123 has been stating above.

     

    IN order to rebuild the upstream primary parent server, how can I keep the same groups that I already have on my primary console? Uninstall, reboot, install seems fairly simple but I want to make sure I can import the groups and clients back into the server once it is rebuilt? Please assist.

     

    Thanks

     

    Wednesday, January 11, 2012 3:14 AM
  • ...when I uncheck replica mode but whenever I check replica mode I continue to get datastore sql exception that states:

    SqlException: Transaction (Process ID 71) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

    Is this exception thrown on the replica server, or the upstream server? If at the replica server, then it is the replica server you should rebuild, not the upstream server.
    IN order to rebuild the upstream primary parent server, how can I keep the same groups that I already have on my primary console?
    Install the new upstream server as a replica of one of your existing working replica servers, replicate the groups, updates, approvals, and content, and then reconfigure it as the upstream server.
    but I want to make sure I can import the groups and clients back into the server once it is rebuilt? Please assist.
    How complex is your group structure?
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    Thursday, January 12, 2012 10:04 PM
    Moderator
  • Thanks for the reply Lawrence.

    The above stated exception was showing on the replica server Which I ended up rebuilding but was still getting data store and deadlock errors. I then ran the clean up wizard on the primary parent server which resolved the syching issue and now my sychs are successful. But at the same time there is another issues that have been introduced where my replica server is unable to download updates from parent server. Updates show they are downloading but then they fail. When I set the console server to get updates directly from MS updates download fine without any issue. I see alot of 364 event IDs on my replica server.

    I wanted to see if i can purge /delete uneeded content using WsusDebugTool and WSusutil.exe using these commands and i noticed that deleteunneededrevisions does not even exist with wsusutil version that i have. Not sure how to run it or do I have to update the version of tool that I have?

    Also I believe I would have to run WSUSDEBUG purgeUnneededFiles on my SQL box right? I have a dedicated SQL server. I am not sure if this needs to be run on the SQL box or on the WSUS console server? Can you pleaes clarify this?

     

    • WSUSDebug PurgeUnneededFiles
    • WSUSUTIL.exe Deleteunneededrevisions
    • WSUSUTIL.exe Reset
    • WSUSUTIL.exe Removeinactiveapprovals

     

    Event Type: Error
    Event Source: Windows Server Update Services
    Event Category: Synchronization
    Event ID: 364
    Date:  1/12/2012
    Time:  7:27:56 PM
    User:  N/A
    Computer: USAOAAPWP158
    Description:
    Content file download failed. Reason: CRC verification failure. Source File: /Content/68/27C268EE84F0B69A6B9EFD63BC0989F0D9E3C968.exe Destination File: e:\WSUS\WsusContent\68\27C268EE84F0B69A6B9EFD63BC0989F0D9E3C968.exe.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Friday, January 13, 2012 1:41 AM
  • Updates show they are downloading but then they fail.
    What is the message associated with the failure(s)?
    When I set the console server to get updates directly from MS updates download fine without any issue.
    Suggesting that the problem is not in the replica server, but rather something on the upstream server.
    I see alot of 364 event IDs on my replica server.
    CRC Verification Errors can be caused because the source file is defective, or because something in the pathway between the source location and the destination location is messing with the files, either by caching a defective file (as a proxy server would do), or modifying it. Please verify that your AV/AM software on both systems has excluded the %windir%\SoftwareDistribution folder.
    I wanted to see if i can purge /delete uneeded content using WsusDebugTool and WSusutil.exe using these commands and i noticed that deleteunneededrevisions does not even exist with wsusutil version that i have. Not sure how to run it or do I have to update the version of tool that I have?
    1. You cannot purge content that does not exist. If you completely rebuilt the replica server, and it cannot download anything -- then there's no content to purge.
    2. The WSUSDebugTool is a WSUS v2 tool; it is not intended for use with WSUS v3, and in fact, all of the functionality that was in the unsupported WSUSDebugTool, is now baked directly into WSUS v3. If you need to delete files from the replica server, the correct tool to use is the Server Cleanup Wizard.
    3. The WSUSUTIL tool was rewritten for WSUS v3, and those actions you specify are also found in the Server Cleanup Wizard.
    Also I believe I would have to run WSUSDEBUG purgeUnneededFiles on my SQL box right?

    No. Not then, and certainly not now. Truly, it seems to me that part of the challenge here may be not understanding the fundamentals of how WSUS works. I would suggest investing some effort in learning the basic product might help significantly with trying to troubleshoot it's operation in an advanced environment.

    But, now that you've mentioned that the upstream server has a Remote SQL database, and I consider these behaviors, I must then ask you: Where is the database for the replica server?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    Saturday, January 14, 2012 9:34 PM
    Moderator
  • Dear Lawrence,

    please how can I get configuration on Windows 2008 R2 Server? wsusdebugtool is only for x86 version :(

    Thank you,

    Lukas

    Friday, October 19, 2012 12:44 PM
  • please how can I get configuration on Windows 2008 R2 Server? wsusdebugtool is only for x86 version :(

    What exactly are you trying to do? (Generally speaking, the answer for 'WSUSDebugTool' question is: Use the Server Cleanup Wizard.)

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, October 25, 2012 3:42 AM
    Moderator
  • I am trying check configuration using WSUSDebugTool/GetConfiguration 

    I want compare replica and upstream server configuration

    Lukas

    Friday, October 26, 2012 11:01 AM
  • I am trying check configuration using WSUSDebugTool/GetConfiguration 

    I want compare replica and upstream server configuration

    Lukas

    Not possible with that tool. WSUSDebugTool.exe is x86 only as far as I know.

    The source code is in the WSUS API Samples and Tools Kit, so theoretically you could recompile the source as an x64 utility if that's the issue.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin


    Tuesday, October 30, 2012 1:24 AM
    Moderator
  • I had the same problem when installing a new downstream replica, main server in Europe, replica in Asia 250-2000 ms away, latency depending on the time of day.

    The replica failed synchronization because of SQL timeout. Symptoms were that synchronization counted to 99%, then the SQL process (as seen in Task Manager) went to 100% CPU on one CPU-core (seen as constant 50% cpu on a two-core machine) for a long time, at last it failed with SQL timeout.

    I reinstalled WSUS, but same problem right away.

    I found out that the problem is caused by a high number of "Unapproved updates", as seen under "Server Statistics" at the replica server.

    The main server showed:
    Unapproved updates: 1
    Approved updates: 4188
    Declined updates: 6698

    The replica's number of approved updates was exactly the same, and the sum of unapproved and declined updates were exactly the same as at the main server. But it had over 4000 unapproved updates, and corresponding less declined updates.

    So I invented the following workaround:
    1 - Options / Update Source and Proxy Server: disabled "This server is a replica"
    2 - Updates / All Updates / Unapproved / Any: selected all with crtl-A and clicked Decline
    3 - Then I used search to locate the single update which was unapproved at the main server, and removed the decline status from it at the replica server. Now the three updates-counters showed exactly the same figures at the main and replica server.
    4 - Options / Update Source and Proxy Server: enabled "This server is a replica"
    5 - Then I clicked Synchronize Now, and the synchronization ran without error, and has done so since then.

    Remember to run WSUS cleanup from time to time. It can be set to run on a schedule, e.g. once a week or month with the command line utility, which even re-indexes the database: http://wsus.codeplex.com/releases/view/17612


    Peter :-)

    Thursday, November 22, 2012 3:09 PM
  • I found out that the problem is caused by a high number of "Unapproved updates", as seen under "Server Statistics" at the replica server.

    The main server showed:
    Unapproved updates: 1
    Approved updates: 4188
    Declined updates: 6698

    In this case, not just the high number of "Approved" updates, itself, but also complicated by the high number of "Total" updates -- 11,000+ updates is a lot of updates for a WSUS server.

    So I invented the following workaround:
    1 - Options / Update Source and Proxy Server: disabled "This server is a replica"
    2 - Updates / All Updates / Unapproved / Any: selected all with crtl-A and clicked Decline
    3 - Then I used search to locate the single update which was unapproved at the main server, and removed the decline status from it at the replica server. Now the three updates-counters showed exactly the same figures at the main and replica server.
    4 - Options / Update Source and Proxy Server: enabled "This server is a replica"
    5 - Then I clicked Synchronize Now, and the synchronization ran without error, and has done so since then.

    So... you're saying that even though the sync went to 99%, you did have all of the updates on the replica server?

    Remember to run WSUS cleanup from time to time.

    While absolutely good advice, it's important to note that the Server Cleanup Wizard will not remove those excessive number of update approvals. I would estimate that you probably have a couple of thousand approvals that could be removed, some that perhaps still need to be declined, other that perhaps should have never been approved to begin with. I note this particularly in light of the fact that you only have =1= UNAPPROVED update on the upstream server -- a highly unusual state of affairs.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Friday, November 23, 2012 9:33 PM
    Moderator
  • Peter,

    Thank you! I searched for a long time to resolve this issue. 2 out of the 3 Downstream servers were not synchronizing. After running the WSUS Cleanup on all servers (Down/Upstream), the next morning they all had multiple successful syncs.

    Thank you again


    • Edited by Antony C Friday, February 20, 2015 3:47 PM typo
    Friday, February 20, 2015 3:47 PM