WSUS Timeout Errors - When? and Why? - Eliminating and avoiding


We’re up to Part 4 now, and we’re going to look at defragmenting the database for WSUS. To recap in Part 2 we talked about removing unnecessary update approvals, and in Part 3 we talked about having too many synchronized updates in general. Update management is a

necessary part of this process before optimizing the filesystem or database. In most of the situations I’ve seen and discussed with other WSUS administrators, it was the volume of data that was the primary culprit–-not the inefficiencies in the organization of that data within the database.


Defragmenting a disk drive can have a significant impact on disk performance; defragmenting a database file can have similar impacts on database performance. In the early days of Windows, defragmentation was something almost every Windows user, and certainly every system administrator, came to know and hate. The need hasn’t gone away, but Microsoft’s built-in defragmentation software did get better (actually, they licensed the software from one of those remaining vendors). Starting with Windows Vista, the defrag task is automatically created in the Task Scheduler to run at 1:00 a.m. every Wednesday morning. However, this task is disabled by default in Windows Server.  This is no great loss, though; a scheduled defrag task is totally useless for a database-based application anyway, because the database engine has a permanent file lock on the database files.


For a WSUS server using the Windows Internal Database, we need to take a slightly more direct approach. After completing all of the requisite update maintenance previously described in Parts 2 and 3 of this series:

  1. Stop the WSUS service. This is the “Update Services” service if you’re using the services MMC., or you can stop it from the command line using net stop wuauserv.
  2. Stop the database service.  Since we’re assuming a local database, that would be the Windows Internal Database service if you’re using the console, or net stop MSSQL$MICROSOFT##SSEE. (Note: If you’re using WSUS v6 on Windows Server 2012, the name of the WID service has changed to MSSQL$MICROSOFT##WID.)
  3. Defragment the drive containing the WSUS database. Navigate to Start -> All Programs -> Accessories -> System Tools and launch Disk Defragmenter. You can also launch from the command line using DEFRAG.EXE.
  4. Restart the database service.
  5. Restart the WSUS service.


It’s also worthy of note that the pretty graphical feedback that exists in Windows Server 2003, does not exist in Windows Server 2008 or Windows Server 2008 R2. In Windows Server 2008 R2, there is a progress indicator, but in Windows Server 2008 there is no active feedback at all. Of course, if you have an alternate disk defragmentation utility to use, that will work as well.


You can also script and schedule this task to run automated and unattended, and defragmenting a hundred gigabyte disk drive may take a long time–-even longer if it’s never been done. (This is another good reason to script and schedule it, so you’re disinclined to watch the progress state and get bored-–or depressed.)


By the way, if the database and content store are on different drives, it’s also worthwhile to defragment the volume with the content store too.


WSUS Timeout Errors - WSUS Database Maintenance