In several conversations during the past year I’ve observed an increasing number of occurrences of “Timeout Errors” with regard to Microsoft WSUS installations which seems to add complexity to WSUS patching.

 

When? and Why? Timeout Errors Occur

So typically in microsoft WSUS patch management, these timeout errors manifest in one of three ways:

 

Using the console to retrieve data for display

If a large number of updates is required to satisfy the query, or the complexities of the relationships between updates, approvals, target groups, and computer update status result in extra execution time, the console gets tired of waiting on the database.

 

Using the Server Cleanup Wizard

This issue manifests as a result of the “Delete Unneeded Updates” task, and typically is seen on servers that have been operational for a long period of time where the Server Cleanup Wizard has never been used.  It can also manifest on WSUS servers that just have too much data. Deleting data from a table in SQL Server is a fairly ‘expensive’ operation all to itself, and because there are constraints on whether updates can be deleted by this task, those constraints must be validated for each update identified as a candidate for deletion. The amount of execution effort required to validate these constraints can also be time consuming. Fundamentally this is a result of ‘too much work to do’.

 

Synchronizing from a replica server

Synchronizing updates from one WSUS server to another is a fairly simple process, but in the case of the replica server, it’s also necessary to synchronize approvals and declines. However, the WSUS server does not synchronize state data, but rather synchronizes events. Synchronizing an approval is a per-group event (number of updates approved x number of groups affected). Declining an update is the inverse of the approval (number of update approvals removed x number of groups affected PLUS the actual decline event). There are two very specific scenarios in which replica timeouts are being observed.

  • The first is caused because the upstream server simply has too many updates approved. Typically this scenario manifests when the replica server is first installed, as a result of the initial synchronization.
  • The second is caused because the upstream server has too many approval events to synchronize. Typically this scenario manifests when a large number of updates have been mass declined on the upstream server.

 

Eliminating and Avoiding Timeout Errors

As seen, the specific internal behaviors of the WSUS database that contribute to these scenarios are somewhat different in each case; but in every case, preventing these timeout errors can almost always be achieved by engaging in four maintenance “best practices” on your WSUS server.

  • Removing unnecessary approvals
  • Removing excessive updates
  • Defragmenting the filesystem hosting the WSUS database
  • Using the WSUS DB Maintenance script

 

Over the course of the next four weeks we’re going to dive into greater detail on patch management on each of these four highly recommended maintenance practices, and talk specifically about WSUS patch management and what each practice provides to the WSUS environment to avoid timeout errors, and how to ensure these tasks are performed correctly.

 

WSUS Timeout Errors - Removing unneeded update approvals

WSUS Timeout Errors - Too many updates

WSUS Timeout Errors - Defragment the filesystem

WSUS Timeout Errors - WSUS Database Maintenance