WSUS Server Cleanup Wizard hangs at “Deleting unused updates” stage

September 16, 2013 3 Comments

Last week i was checking some of my replica WSUS servers, and I discovered that some of them hadn’t synchronised with the upstream WSUS server for a few weeks. When looking in the synchronisation log I was presented with the following error message:

An error occurred with the server’s data store.

And when I clicked on “Details”, this message was displayed:

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

As some of the WSUS servers had been synching OK with the upstream server I ruled out any corruption at that end. Apparently this error can occur if the server cleanup wizard has been run on the Master WSUS server, but not on the replica. As a result I decided to run the WSUS server cleanup wizard on each of the replica WSUS servers that were having problems synchronising with the master server. Most of these ran through fine, but a couple of the replica WSUS servers hung on the “Deleting unsused updates stage” and therefore the server cleanup wizard could not complete. I had seen this issue before while dealing with a different problem previously, and knew that it could be resolved by running the server cleanup wizard elements in a specific order, which is as follows:

Pass one:

Select option 2 only “Computers not contacting the server”

Pass two:

Select option 4 only “Expired updates”

Pass three:

Select option 5 only “Superseded updates”

Pass four:

Select option 3 only “Unneeded update files”

Pass 5:

Select option 1 only “Unused updates and update revisions”

Running the cleanup wizard with the options above fixed the issue and subsequently the replica servers happily synchronised with the master server once again. Please note even running the server cleanup wizard in this way, pass five can still take a considerable amount of time to run, but it has always succesfully completed for me. On one of the servers I even had to leave this running over night.

Advertisement

Filed under Windows, WSUS Tagged with , , , , , , , ,

svchost.exe using 100% CPU on Windows XP when scanning for Windows updates against WSUS

January 30, 2012 Leave a comment

I thought I had seen the last of this issue several years ago, but we still have a couple of legacy single core CPU Windows XP boxes knocking around, and last week this problem reared its ugly head once more on a couple of machines. The symptom of this problem is that shortly after login, the automatic updates service runs to check for new updates against WSUS. While this scan occurs if you look in Task Manager the process svchost.exe is consuming 100 % of CPU resources making the machine pretty much unusable. You can verify whether wuauclt (the Windows update client) is the culprit in your case by running Process Explorer, and seeing if wuauclt is running under the svchost process. This issue always used to affect single core machines with relatively small amounts of RAM by todays standards. At the time this issue was fixed in the majority of cases by installing an updated version of the Windows Update agent which can be found here.

Anyway, back to the present, and after releasing a handful of windows updates for XP in the WSUS console a few days ago I found that a couple of legacy XP machines had become unusable after login as svchost.exe was consuming 100% CPU. The client machines would stay like this indefinitely and never seemingly finished their scan for updates against WSUS. Straight away I looked in the C:\Windows\windowsupdate.log to check the client version and to see if anything else unusual was occurring. The update agent was up to date (version 7.4.7600.226) so this didn’t appear to be the old problem.

As the first part of the fix, I ran the WSUS ‘Server Cleanup Wizard’ on the server that the client was checking for updates against. I selected all the options as shown below to make sure the client wasn’t checking for any unecessary or superceded updates.

WSUS Server Cleanup Wizard Options

 

Secondly, I followed method 1 of this technet tutorial:

1.Click Start, click Run, type cmd in the Open box, and then click OK.

2.At the command prompt, type net stop wuauserv, and then press ENTER.

3.Click Start, click Run, type regedit in the Open box, and then click OK.

4.Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate

5.In the details pane of Registry Editor, delete the following registry entries:

  • PingID
  • AccountDomainSid
  • SusClientId
  • SusClientIDValidation

Note Windows Update Agent 3.0 adds the SusClientIDValidation value. This value was released in May 2007. The other registry entries exist in both Windows Update Agent 2.0 and in Windows Update Agent 3.0.

6.Exit Registry Editor.

7.At the command prompt, type net start wuauserv, and then press ENTER.

8.At the command prompt, type wuauclt.exe /resetauthorization /detectnow, and then press ENTER.

9.Wait 10 minutes for a detection cycle to finish. 10.Start the WSUS console to make sure that the clients appear in the WSUS console.

After carrying out the above steps, the XP client machine completed the update scan within a few minutes and the CPU usage returned to normal.

Filed under Windows, WSUS Tagged with , , ,

Set deadline for windows update installation in WSUS

January 25, 2012 5 Comments

In certain circumstances, when using WSUS (Windows Server Update Services) in your environment, you may wish to deploy a critical Windows update sooner than your scheduled installation window. Personally, I would excercise extreme caution using this setting due to the gotchas outlined at the end of this post.  However, this can easily be achieved by setting a deadline for installation when you approve the update or updates. In the WSUS console simply select the update or updates, and then right click them and choose ‘Approve …’ as shown.

Approving an update in the WSUS console

Once the ‘Approve Updates’ screen opens, choose which group of computers you want to approve the update for. In this case I have chosen ‘All Computers’, and then  ‘Approved for Install’. Next right click the ‘All Computers’ group again and choose ‘Deadline’ and then ‘Custom’ as shown:

Set a custom deadline for installation of an update in the WSUS console

The ‘Choose Deadline’ screen opens. Choose the date and time that you want the update or updates to be installed at, as shown:

Choose the date and time for your deadline

Thats it, your update will now be installed at the time that you have set. There are a couple gotchas using this setting that it is worth being aware of. Firstly if the update with the deadline requires a restart, the computer will reboot after installation regardless of what the user is doing at the time. It is therefore probably best to avoid deadline times in the middle of the working day when users may suddenly find their computers reboot with little or no warning causing them to lose work. Secondly, a deadline will override the ‘No auto-restart with logged on users for scheduled automatic updates installations’ Group Policy setting, so again be careful if you have this GPO setting enabled, as you may not expect your computers to reboot, but they will in this case.

References:

http://technet.microsoft.com/en-us/library/dd939923(WS.10).aspx

Filed under Deployment, Windows, WSUS Tagged with , , , ,