WSUS: Updates page times out while trying to view or approve updates

Hello, Joe Tindale here from the WSUS team to give you some tips on those timeout errors you may see when trying to view or approve updates.

This problem is prevalent on WSUS2 but it can happen on WSUS3 as well. It usually happens when a large number of updates or clients are on the server, client detection frequency is too frequent, hardware is below par and/or other factors are slowing down performance such that the SQL query times out mid operation.

With WSUS2 you may see a error similar to the following:

"Error connecting to the Windows Server Update Services database There was an error connecting to the Windows Server Update Services database.

Either the database is not available or you do not have the correct privileges to access the database."

clip_image002

With WSUS3 the error may be as follows:

An error occurred when trying to perform a database operation. This can happen if the database is very busy, if the database service is stopped, or if the connection to the database is lost.

clip_image004

If you copy the error to the clipboard it will reveal the following:

The WSUS administration console was unable to connect to the WSUS Server Database.

Verify that SQL server is running on the WSUS Server. If the problem persists, try restarting SQL.

System.Data.SqlClient.SqlException -- Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

There are a few things you can do to try and resolve this.

If using WSUS2:

If using WSUS2:

1.) Try some of the following database maintenance scripts:

a.) SUS20IndexManagement.sql - this will defragment the indexes for each WSUS table. At the end it will show the index statistics

b.) SUS20UpdateStatistics.sql - this forces an update of the statistics used by SQL to generate query plans for all the WSUS tables.

You can get them and brief instructions from here:

https://www.codeplex.com/WSUS/Release/ProjectReleases.aspx?ReleaseId=18473

2.) Use the WSUSUtil tool to delete unneeded revisions and updates for inactive languages. You can find wsusutil in program files\update services\tools.

a.) "wsusutil deleteunneededrevisions" - Purges the update metadata for unnecessary update revisions from the database. Stop the WSUSService before running this command.

b.) "wsusutil removeinactiveapprovals" - Removes approvals for updates that are in a permanently inactive state because of a change in WSUS server language settings.

3.) Make sure you are running WSUS2 SP1 as we included a fix in SP1 detailed here:
https://support.microsoft.com/default.aspx?scid=kb;EN-US;910847

To determine your version of WSUS look all the way at the bottom of the WSUS home page and you should see “Build Number: 2.0.0.2620” if you are running WSUS2 SP1.

4.) If the above cleanup does not work you may want to try and reduce the load on the server somehow.  First, try and make sure all your clients are setup for a once per day detection frequency.  The default is 22 hours and is controlled via group policy.

https://technet.microsoft.com/en-us/library/cc720539.aspx

WSUS2 can support a maximum of 15,000 clients given a once per day detection frequency but other hardware and performance related variables may cut into that:

https://technet.microsoft.com/en-us/library/cc720539.aspx

Next, try and separate other server roles from the WSUS server, especially if other instances of SQL are involved.  A server running WSUS, Sharepoint or anything else may be suffering from performance issues due to the server being ‘over-burdened’.

5.) If you cannot reduce the load consider improving the hardware.  Some of the SQL queries WSUS depends on can be rather performance hindering so things like memory and disk read/write access are important.

6.) If all else fails… rebuild. You can use WSUSMigrate from the API Samples and Tools to export computers, groups and
approvals and import those into the new server.

a.) Download the WSUS2 version of the tools from here:
https://download.microsoft.com/download/8/d/0/8d068114-bd66-4fde-a04c-aeaa9d1fe640/Update%20Services%20API%20Samples%20and%20Tools.EXE

b.) Follow the instructions in the tools installation directory, usually program files\Update Services 2.0 API Samples and Tools\WsusMigrate\. The instructions will tell you how to export the data, rebuild the server and then reimport the data.

Note: If at all possible upgrade to WSUS3 since WSUS2 is reaching its end of life (4/09 I believe). WSUS3 has a much better maintenance script as well as cleanup wizard. If upgrading to WSUS3 you will need to use this version of WSUSMigrate to import the data into WSUS3.

You can obtain the updated tool from here:

https://www.codeplex.com/WSUS/Release/ProjectReleases.aspx?ReleaseId=18460

If using WSUS3:

1.) Try the WSUS3 maintenance script from here:
https://technet2.microsoft.com/windowsserver/en/library/e787794b-4f09-4d01-ae4e-5983ea7634f91033.mspx

2.) Try the server cleanup wizard:
https://technet2.microsoft.com/windowsserver/en/library/dbc60cda-5bbc-495c-91ba-b6942f8b09af1033.mspx

Note: You can accomplish both 1 and 2 by running a cleanup tool I just wrote and uploaded here:

https://www.codeplex.com/WSUS/Release/ProjectReleases.aspx?ReleaseId=17612

3.) Make sure you are running WSUS3 SP1 as several performance improvements were made to SP1.  To determine your version of WSUS3 open the WSUS administrators console and go to help on the menu bar and choose “About Update Services”.  A dialog box will appear with the version information.  The version number for WSUS3 SP1 is 3.1.6001.65.

4.) If the above cleanup does not work you may want to try and reduce the load on the server somehow.  First, try and make sure all your clients are setup for a once per day detection frequency.  The default is 22 hours and is controlled via group policy:

https://technet.microsoft.com/en-us/library/cc708574.aspx

WSUS3 can support a maximum of 20,000 clients given a twice per day detection frequency but other hardware and performance related variables may cut into that:

https://technet.microsoft.com/en-us/library/cc708483.aspx

Next, try and separate other server roles from the WSUS server, especially if other instances of SQL are involved.  A server running WSUS, Sharepoint or anything else may be suffering from performance issues due to the server being ‘over-burdened’.

5.) If you cannot reduce the load consider improving the hardware.  Some of the SQL queries WSUS depends on can be rather performance hindering so things like memory and disk read/write access are important.

6.) If all else fails… rebuild. You can use WSUSMigrate from the API Samples and Tools to export approvals and import those into the new server.

a.) Download the WSUS3 version of the tool from here:
https://download.microsoft.com/download/5/d/c/5dc98401-bb01-44e7-8533-3e79ae0e0f97/Update%20Services%203.0%20API%20Samples%20and%20Tools.EXE

b.) follow the WSUSMigrate readme located in program files\Update Services 3.0 API Samples and Tools\WsusMigrate. PLEASE use the recompiled version of wsusmigrationimport from here as there was a bug in the original version.  Please see the following for more info on that bug:

https://support.microsoft.com/default.aspx?scid=kb;EN-US;945348

You can obtain the updated tool from here:

https://www.codeplex.com/WSUS/Release/ProjectReleases.aspx?ReleaseId=18460

Note: One issue that just popped up a while ago caused a large number of updates (drivers) to flow to WSUS servers. This was bad because 14,000 or so driver updates were added to the servers update count and can certainly lead to timeouts and other performance related issues. I blogged about that issue here:
https://blogs.technet.com/sus/archive/2008/08/20/a-large-number-of-driver-updates-showing-up-in-wsus.aspx ?

You can obtain the driver_decline tool from that blog here:
https://www.codeplex.com/WSUS/Release/ProjectReleases.aspx?ReleaseId=16459

- Joe Tindale