Synchronization is the process in which the WSUS server connects to Microsoft Update or to another WSUS server and downloads updates. During synchronization, WSUS determines if any new updates have been made available since the last time you synchronized. If it is your first time synchronizing WSUS, all updates are made available for approval. If synchronizations are failing, you can try the following procedures.
Check proxy-server settings by using the WSUS console
If your WSUS server is connected to Microsoft Update via a proxy server, you must use the WSUS console to allow WSUS to access the Internet. For basic instructions about setting up a proxy server, see at If your proxy server supports authentication, make sure you have the correct user name, password, and domain. Note that if you use the WSUS console option for Allow basic authentication (password in clear text), the password for the account is sent over the network in unencrypted text.
Check the name of the upstream WSUS server
If your WSUS uses another WSUS server as its update source, make sure you are using the correct name for the upstream WSUS server and that you have spelled it correctly. For basic instruction about synchronizing two WSUS servers, see at The name that you enter in the WSUS console on the downstream WSUS server must match the name of the upstream WSUS server.
To determine if there is a problem with network name resolution services, use the ping command from the downstream WSUS server that cannot synchronize. You should use the same naming convention that is used in the WSUS console. For example, if you used a NetBIOS name in WSUS console, use the NetBIOS name of the upstream server with the ping command. If you cannot ping the upstream server, you might have a problem with network name resolution services. To work around this type of issue, you could use a different name resolution service or the IP address of the upstream server.
To ping an upstream WSUS server by using the ping command-
Click Start, and then click Run
-
In the Open box, type cmd, and then click OK.
-
Type the following, and then press ENTER:
ping WSUSServerNname
where WSUS server name is the name of the upstream WSUS server you are trying to synchronize with.
Check update storage options
If you have multiple WSUS servers chained together in a hierarchy, the entire hierarchy must use the same update storage option or else synchronizations fail. For example, if the upstream WSUS server stores content locally, all the downstream WSUS servers must store content locally. Check that each WSUS server in the chain uses the same update storage option. For information about how to set WSUS update storage options, see at
Verify that users and the network service have Read permissions to the local update storage directory
If you store update files on your WSUS server, you need to ensure that the folder to which you download update files has at least Read permissions for the network service and for users. This is true whether the server you download the update files to is an upstream or downstream WSUS server. The folder where update files are stored if you have chosen to store them locally (as opposed to storing them on Microsoft Update servers) is %systemdrive%\Update Services\US content.
On a downstream WSUS server, check that the updates are available on the upstream WSUS server
There are number of situations where the updates on the upstream server no longer match the updates being requested at synchronization by the downstream server. Some of the following are examples of when this might occur:
- An upstream WSUS server is re-installed and the list of classifications and products the administrator selects is a reduced number than previously selected on the earlier installation of the WSUS upstream server. The downstream server(s) might then attempt to synchronize updates that the newly rebuilt upstream server has no knowledge of. Therefore the synchronization would fail for those updates that do not exist on the upstream server.
- If you configure a downstream server to get updates from a different upstream server with different products and classifications selected.
To troubleshoot this issue, on the downstream server, make a note of the title of the updates for which download failed. These will be visible on the Updates page, and marked with a red X. Then, check if these updates exist on the upstream server (look at the Updates page. If they do not match, do one of the following, depending on which updates you need:
- Specify the missing updates on the upstream server, and then synchronize from the update source.
- On the downstream server, cancel the updates that are not on the upstream server, if these updates are no longer needed. Then decline the old updates on the downstream server.
- If the missing updates (according to the downstream server) are actually available on the upstream server, then the error is transient, meaning the update might have been downloaded to the upstream server after it was requested by the downstream server. This issue will resolve itself the next time the downstream server synchronizes to the upstream server.
Restart the BITS service
If the BITS service was disabled during synchronization, synchronization will fail. To ensure that the BITS services is properly enabled, restart both the BITS service and restart the WSUS service.
To restart the BITS service and the WSUS service-
On the WSUS server, click Start, point to Administrative Tools, and then click Services.
-
Right-click Background Intelligent Transfer Service, and then click Restart, or click Start if the BITS service is not running or has been disabled.
-
Right-click Windows Update Service, and then click Restart.
-
Retry synchronization: in the WSUS console, click Options, click Synchronization Options, and then under Tasks, click Synchronize now.
If you are unable to download update files to your local WSUS server, your server might not support the necessary HTTP protocol
If synchronization of update files to your WSUS server fails, you might see the following message in the corresponding event log:
Content file download failed. Reason: The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header.Source File: /msdownload/update/v3-19990518/cabpool/windows2000-kb873339-x86-enu_500e4656b4f0ca3431565631989090bbeeb74bcc.exe Destination File: %drive%\wsus\WsusContent\WsusContent\CC\500E4656B4F0CA3431565631989090BBEEB74BCC.EXE.
This problem occurs if your proxy environment doesn’t support HTTP 1.1 Protocol. You can manually work around this by running the following commands at the command prompt to configure BITS.
To resolve this issue:-
Type: net stop WSUSService, and then press ENTER.
-
Type: "%programfiles%\Update Services\tools\osql\osql.exe" -S SQL_InstanceName -E -b -n –Q "USE SUSDB update tbConfigurationC set BitsDownloadPriorityForeground=1" and then press ENTER.
-
Type: net start WSUSService.
-
Close the command prompt window and retry synchronization: in the WSUS console, click Options, click Synchronization Options, and then under Tasks, click Synchronize now.
The number of updates that are approved on a parent upstream server does not match the number of approved updates on a replica server
This might occur if you have changed language settings on the parent upstream server after first synchronizing with the old language settings. For more information see "Listinactiveapprovals" in .