Speeding up WSUS-client detection of new updates

We’re using WSUS 3.0 to update our environment with the latest Windows Updates. Overall usage is fairly simple… however…

I found that sometimes when a lot of updates had to be installed on a server, not all approved updates were downloaded to the server. The majority was downloaded and after rebooting the server when these updates were installed, windows update failed to detect and download the rest of the required updates within a reasonable amount of time. Restarting Windows update services didn’t help, and neither did the command ‘wuauclt /detectnow’.

When using WSUS there are a few thing you need to take into account. Consider the process:

1. A computer reports it’s status to the WSUS server
2. WSUS checks this status against the updates available since the last synchronization (once a day)
3. Required updates are marked as ‘needed‘ in the WSUS console
4. Needed updates are approved and downloaded(*) to the WSUS server
5. The computer checks for updates and downloads them as needed
6. Updates are installed

There is a difference between ‘reporting status‘ and ‘detection‘ of new updates.

In the first step the computer reports it’s status to the WSUS server. By default this is being done every 22 hours unless you change the setting in group policy. After reporting status to the WSUS-server the computer stores the information in a cookie and will not report it’s status untill these 22 hours have passed. This means that if your server has reported status and detected 13 updates that it can install in a first run, while you have approved 22 updates for this server in WSUS, the server will download and install these first 13 updates and probably ask you to reboot afterward.

When you check the logfile (C:WindowsWindowsUpdate.log) after the reboot you will find that the other 9 updates are not detected after the reboot. Furthermore, when you open a command prompt and execute the command ‘wuauclt /detectnow’ you will probably find the log to state ‘0 updates detected’. The reason for this is that the server has not reported status back to the WSUS-server(as mentioned in step 1 above) between detection and installation of the first 13 updates (step 6) and the last detection after the reboot and since this is the case, the WSUS server will think these 13 updates have not been installed yet and will not offer the last 9 updates. The server will not report status untill 22 hours later unless the cached cookie is deleted and the server is forced to report status to the WSUS-server…

Very, very annoying…

 So can we do this?… Yes we can…

Open up a command prompt and execute the following command:

• wuauclt /detectnow /resetauthorization

The commandline option resetauthorization tells windows update to get rid of the cached cookie. The log will still tell you ‘0 updates detected’ because this command does not tell windows update to report status.

After having performed this command open up services.msc and restart Windows Update Service.

After restarting the service open up C:WindowsWindowsUpdate.log and wait untill you see something like this in the log:

2009-10-28 11:05:50:358  820 13b8 Report Uploading 2 events using cached cookie, reporting URL = http://wsus.server.fqdn/ReportingWebService/ReportingWebService.asmx
2009-10-28 11:05:50:358  820 13b8 Report Reporter successfully uploaded 2 events.

This means  the server has contacted WSUS and reported its status back. It can take up to 10-15 minutes for the server to report these entries in the log and unfortunately does not always succeed. If after 10 -15 minutes these entries are not logged, repeat these steps one more time.

Share this