Synchronization

If yous are having issues with the synchronization of updates, look at the some of the following rough patches for some help:

■ Cheque proxy server settings from the WSUS console. If your proxy server supports hallmark, brand sure you accept the correct user name, password, and domain. Too be aware that by using basic hallmark, you are sending your credential data in plaintext over the wire.

■ Verify the name of the upstream WSUS server. This must be spelled exactly. If you suspect other advice or proper noun resolution problems, try pinging the upstream server from the downstream WSUS server that is having the problems. But brand sure when pinging that y'all are using the same naming convention used in the WSUS console.

■ Check the update storage options y'all have configured. If you are using a chain of WSUS servers together in a bureaucracy, the entire bureaucracy must employ the same update storage option; otherwise, the synchronizations fail. Consequently, if the upstream server stores content locally, each of the downstream WSUS servers must store content locally as well. Make certain that each WSUS server in the chain uses the aforementioned option for update storage.

■ Verify permissions on the update storage directory. Check to see that the binder where you download update files has "Read" permissions for NETWORK SERVICE and for Authenticated Users, whether or not the server you download the update files to is an upstream or downstream automobile. The directory is c:\Update Services\UScontent. (See Figure 11.1)

Figure 11.1 Verifying Permissions

Make sure the upstream WSUS server actually has updates available. In that location are a couple of scenarios where there might be a mismatch in update availability. In the beginning scenario, an upstream server is reinstalled; thus, the list of classifications and updates that the administrator selects changes. A future synchronization will fail when a downstream server asks for updates that do not be on the upstream server. In the second scenario, yous might configure a downstream server to retrieve updates from a different upstream server with some other prepare of products and classifications selected. Either of these scenarios would upshot in mismatched update numbers.There are a few means to fix this: (1.) Specify the missing updates on the upstream server and then synchronize from the update source; (two.) make sure you cancel the updates that are non on the upstream server and decline the old updates on the downstream server; or (3.) if the missing updates are bachelor on the upstream server, and so the error is transient, and things will eventually fix themselves.

Try restarting the Background Intelligent Transfer Service (Bits) service.Yous can practice this from the Services Microsoft Management Console (MMC) under Administrative Tools in the Commencement menu (see Figure 11.2).

Figure xi.2 Restarting $.25

Figure eleven.two Restarting Bits

■ Try restarting the WSUS service. Again, this can exist done from the Services MMC console under Administrative Tools in the Start carte du jour. Attempt to synchronize again.

■ Make certain your environs supports Hypertext Transfer Protocol (HTTP) v1.ane. If yous are receiving errors regarding the Range protocol being unsupported, y'all must change a setting from the command line. Terminate the WSUS service and issue the following command: "%programfiles%\Update Services\tools\osql\osql.exe" -S SQL_InstanceName -Due east -b -n -Q "USE SUSDB update tbConfigurationC ready

BitsDownloadPriorityForeground=1". Replace the SQL_instanceName as appropriate. Then, restart the WSUS service and perform the synchronization again.

Some Independent Advice_

We have institute that a lot of WSUS problems are solved past the timeless Windows ready: reboot. If you exercise non desire to accept down the whole machine, simply restart the BITS service and the WSUS service and endeavour again.

Keep reading hither: Console Access Bug

Was this commodity helpful?