Software Updates/WSUS Sync Error 6703, Event ID 364 & “Value does not fall within the expected range”

2017-12-11T11:07:06+00:00 April 2nd, 2013|Windows|

Hi all,

Recently encountered the above issue at a customer site.

 

SCCM 2012 SP1 with WSUS installed on same server.

The SUP had successfully been synchronising with WSUS for a couple of weeks.

Required Proxy Server and credentials had been set within Site System Properties and Proxy and Account settings set within Software Update Point properties.

In Component Status, SMS_WSUS_SYNC_MANAGER started showing as critical.

 

Checking “Show Messages” for this component revealed a number of Message ID 6703:

“WSUS Synchronization Failed. Message: Failed to sync some of the updates. Source: Microsoft.Systems.ManagementServer.SoftwareUpdatesManagemert.WSUSSyncAction.WSyncAction.SyncUpdates”.

 

WCM.log looked clear.

 

Wsyncmgr.log showed a number of the following type of error:

“Failed to sync update 054ee1db-db4b-4bfe-9a08-10ce84627542. Error: The Microsoft Software License Terms have not been completely downloaded and cannot be accepted. Source: Microsoft.UpdateServices.Internal.BaseApi.SoapExceptionProcessor.DeserializeandThrow”

 

A further error within the log states:

“Sync failed: Failed to sync some of the updates. Source: Microsoft.Systems.ManagementServer.SoftwareUpdatesManagemert.WSUSSyncAction.WSyncAction”.

 

WSUS Console states last synchronization as Succeeded.

 

Application Log of the server shows repeats of the 6703 error from SMS_WSUS_SYNC_MANAGER, along with “The operating system reported error 2148734208”.

Additionally, the following error is logged two minutes prior to each of the 6703’s.

Event ID 364:

Source: Windows Server Update Services

General: “Content file download failed. Reason: Value does not fall within the expected range. Source File: /msdownload/update/v5/eula/use%20terms_retail_windows%20internet%20explorer%209%20supp_0.0_english_unicode-2bdf0ddc-2897-4252-8b63-5aee30ae9947.txt Destination File: F:WSUSWsusContent862057F9A9878799A92846947E7F8CB15BA7F8F086.txt”.

 

SoftwareDistribution.log shows similar errors to the Application log.

 

Permissions on the WSUS, and WSUSContent subfolder were correct (NETWORK SERVICE has Full Control) and temporarily increasing the permissions to Everyone, Full Control didn’t solve the issue, so not a permissions problem for the folders.

Confirmed WSUS was set to “Store update files locally on this server”.

The proxy showed nothing being blocked, though there wasn’t much traffic from the SCCM server.

 

Removed and reinstalled Software Update Point role from site server, confirming that this took place by checking SUPSetup.log.

Kicked off sync of Software Updates – same errors logged.

Therefore, reinstallation of SUP has not fixed issue.

 

Overnight WSUS Sync picked up 24 new updates, and reports as successful.

These extra updated show within SCCM Console, “All Software Updates”.

However, 6703 errors still being listed.

 

Continuing to think along the lines of permissions problems, I tried the following:

Within the Site system Properties, unchecked “Use credentials to connect to the proxy server”.

Ran another sync, monitoring the SoftwareDistribution.log:

 

Saw a multitude of events of the following type:

“WSUSService4.ContentSyncAgent.DownloadItem:<itemid> has been submitted to BITS for Download”

 

Followed by:

“WSUSService4.EventLogEventReporter.ReportEventEventID=366,Type=Information,Category=Synchronization,Message=Content file download succeeded. Digest: Source File: /msdownload/update/v5/eula… Destination File: F:WSUSWsusContent6f…”

 

Wsyncmgr.log no longer shows any of the previous errors, just a couple noting

“Update <updateid> not synced due to pending EULA download” and summarises this at the end of the log.

 

Application Event Log shows Event ID 6708: “WSUS synchronization complete, with pending license terms downloads”.

 

Software Update Point Synchronization status shows as “Completed, with pending EULA downloads”.

Once these final EULA’s had downloaded the status changed to “Completed”.

 

Bit of an unusual issue.

Further investigation seems to indicate that this is a known bug.