Action1 5 Blog 5 A Complete Guide to WSUS Maintenance

A Complete Guide to WSUS Maintenance



Published:

July 29, 2026



Last Updated:

July 29, 2026

By Aleksandar Petrunov

First 200 endpoints free, no feature limits.

No credit card required, full access to all features.

TL;DR

WSUS maintenance is essential for maintaining a healthy patch management environment by removing obsolete updates, cleaning expired revisions, reindexing the SUSDB database, deleting inactive computer records, and preventing database bloat that degrades performance.
The guide recommends performing maintenance at least monthly, ideally after Microsoft’s Patch Tuesday, while neglected WSUS servers should undergo a full cleanup before being placed on a regular maintenance schedule.
A complete WSUS maintenance routine includes declining superseded updates, running the Server Cleanup Wizard, reindexing the SUSDB database, optimizing indexes, removing obsolete content, verifying synchronization health, and monitoring overall server performance.
Regular maintenance improves console responsiveness, synchronization speed, client scan performance, database efficiency, storage utilization, and overall Windows update reliability while reducing update failures and administrative overhead.
The article discusses automation and maintenance best practices, including PowerShell scripting, scheduled cleanup tasks, database monitoring, backup procedures, and ongoing health checks to keep WSUS operating efficiently over time.
Modern alternatives discussed include Action1, Microsoft Intune, Windows Autopatch, Microsoft Configuration Manager (MECM/SCCM), NinjaOne, ManageEngine Endpoint Central, Automox, Atera, and Ivanti Neurons, which reduce or eliminate much of the manual maintenance required by traditional WSUS deployments.
Organizations managing hybrid or remote environments should evaluate cloud-native endpoint management platforms that provide automated patching, third-party application updates, vulnerability remediation, compliance reporting, and centralized management without requiring ongoing WSUS infrastructure maintenance.

What is WSUS Maintenance?

Windows Server Update Services (WSUS) maintenance refers to cleanup tasks that involve running the WSUS server cleanup wizard, performing the reindexing of the SUSDB database, cleaning up obsolete updates and expired revisions, removing unused client computers or servers, and updating revisions. Not performing maintenance regularly will not just break the WSUS immediately but introduce failures over the period of months or years, depending on the size of the device fleet, applications, and frequency of the updates. Because every update, revision, and client status record is kept, it significantly grows the SUSDB and causes bloat, slowing down nearly every operation related to the database, including the WSUS console itself. As the database grows, console performance and sync degrade, causing the timeouts. When the server-side database is huge and not optimized, client scan requests also time out, may return incomplete results, or fail to detect or download patches. An example would be a WSUS server that never had cleanup:

Will build up tens of thousands of updates
Increasing SUSDB size to 100s of GBs where it should have only 20 to 30 GB.
A WSUS content sync used to take 10 minutes, may take over an hour, or may fail.
Helpdesk could be overwhelmed with tickets related to Windows updates stuck on dozens of client machines.

How often should WSUS maintenance be performed?

WSUS server maintenance should be performed at least monthly for actively used servers; this should align with Microsoft’s Patch Tuesday cycle, which occurs on the second Tuesday of each month. Running maintenance right after the patch cycle ensures that new updates arrive monthly and old ones are cleaned up simultaneously, preventing the database from accumulating bloat. On the other hand, a WSUS server with no maintenance history should be cleaned up immediately before adding it to the monthly cycle, given years of accumulated superseded updates, bloated indexes, or orphaned files, which can take hours to clean up.

How long does WSUS maintenance take

The first-time cleanup on a neglected WSUS server with over 200,000 updates may take 2-4 hours considering the cleanup wizard has to process and decline volume of updates, revisions and files built over the years. Reindexing heavily bloated SUSDB adds more time to the top of cleanup. Once the backlog is cleared and regular maintenance is established, monthly maintenance cycle must only process recent months’ superseded updates and database re-indexing and can take only 15-30 minutes.

What are Core Steps to Perform WSUS Maintenance?

Performing WSUS Maintenance process in a correct order is essential in order to achieve the best results and prevent database corruption, it must move from software metadata layer to underlying database engine, which ensures that you are not shrinking data or re-indexing which is already marked for deletion.

Decline superseded updates

Admins must run the decline superseded updates step before running the cleanup wizard, because it cuts the wizard’s processing time in nearly half to process smaller patch backlog. Microsoft provides Decline-SupersededUpdatesWithExclusionPeriod.ps1 script which automates the identification of large volume of superseded updates, which is not practical doing manually. It scans the update metadata, declines superseded updates, leaving only those which are defined in exclusion parameter. Admins run this script with important parameter -ExclusionPeriod with their desired number of days, usually 30 days, which means that script will decline all superseded updates which are older than 30 days, while keeping last month’s superseded updates as backup for rollback, in case any newer update causes problems.

Run the WSUS Server Cleanup Wizard

Server clean up wizard is available in Windows Update Services console; it removes obsolete content, records and update files, reduces database size, decreases synchronization overhead and improves console responsiveness. There is an equivalent PowerShell cmdlet Invoke-WsusServerCleanup also available for admins who want to use Windows Task schedule for cleanup automation.

GUI Path

WSUS Console → Options → Server Cleanup Wizard

PowerShell Command

Invoke-WsusServerCleanup -CleanupObsoleteComputers -CleanupUnneededContentFiles -DeclineSupersededUpdates -DeclineExpiredUpdates -CompressUpdates

Each checkbox in cleanup wizard aims for a distinct category of database garbage; details are as follows.

Unused updates and update revisions: Delete expired and older updates and revisions in 30 days or more and are no longer needed.
Computers not contacting the server: Remove records for client machines that have not contacted the server in 30 days or more.
Unneeded update files: Deletes content files from disk which aren’t needed by updates or downstream servers.
Expired updates: Removes updates that aren’t approved, or Microsoft has formally retired.
Superseded updates: Decline unapproved updates for 30 days or more, not currently needed by any clients or are superseded by approved updates.

Reindex and defragment the SUSDB database

When cleanup wizard runs, it removes massive amounts of data from the database. Every query for removal of distinct updates makes the indexes more fragmented on top of every new patch data inserted. Which causes WSUS console unresponsiveness from time to time and can cause next cleanup wizard timeouts. This is why reindexing and defragmentation of the SUSDB should be a critical third step after each cleanup wizard runs.

If SUSDB was installed on WID (Windows Internal Database)

When Windows Internal Database (WID) is used for hosting SUSDB, SQL Server Management Studio (SSMS) cannot connect to it; admins must use command line SQLCMD utility with the below command to open a session directly against WSUS database.

sqlcmd -S \\.\pipe\MICROSOFT##WID\tsql\query

Once connected, the same script used for reindexing full SQL Server Database can be executed.

If SUSDB was installed on SQL Server

SQL Server enables direct database connection via SSMS, making it more convenient for automated maintenance, SSMS interface is more familiar to admins, they can schedule the reindexing script using SQL Agent Job. Confirming SQL type prevents unexpected troubleshooting time, though WSUS console itself shows database information under Options, but the following registry key gives a definitive answer.

HKLM:\SOFTWARE\Microsoft\Update Services\Server\Setup\SqlServerName

Query the database to check the update count first

Administrators should not rely solely on cleanup wizard success results; they should run a count query on the SUSDB before and after the cleanup, which gives them proof that cleanup actually worked. A simple row count can confirm the assumption, executing the SELECT COUNT(*) FROM tbUpdate on the updates table before cleanup wizard will show for example 225,000 rows, and the same query after cleanup wizard may show 50,000 rows. This check is also useful to determine WSUS servers which require cleanup with shorter exclusion period, e.g. row count only shows 5% drop after cleanup, so admins can reduce the exclusion period from 30 days to 15 days.

Create custom indexes for SQL performance

As the WSUS database grows larger with hundreds of thousands of update records, default database indexes are not sufficient for faster querying during cleanup process and client sync process. Both processes can become slow enough to trigger time outs even after reindexing. Creating custom indexes will address this issue. Microsoft offers specific T-SQL scripts for these custom indexes; these scripts are useful to fix very large WSUS databases where standard maintenance is not sufficient.

Shrink database files

SQL Server does not automatically free up space after cleanup operations delete rows, it just marks the space within same file to be reused, explicit database shrink is required to reclaim the space, WID databases also reclaim very little space without this step. DBCC SHRINKDATABASE (SUSDB) is the command most admins are looking for after performing maintenance, physically reduces the file size by reorganizing it and releasing the unused space back to the file system.

Clean up sync history

Sync history database tables contain log entry for every scheduled sync between your WSUS upstream server and Microsoft Update servers, even though the ones do not get any new updates. These logs keep successful syncs, failed syncs, status information, and timestamps. These tables grow steadily over months or years on active servers, contributing to overall SUSDB size. Cleaning up the sync history is 5^th step in Microsoft Maintenance Script, keeping only the most recent sync history is enough to troubleshoot; this script removes the older entries and reduces database bloat.

How to Automate WSUS Maintenance?

The Microsoft WSUS database maintenance script

Manual maintenance can be prone to errors; waste of admins time and admins can perform steps out of order which can lead to SUSDB in half-cleaned state. To address this issue, Microsoft published an official 12 step SQL maintenance script to put together entire process into a single procedure with correct order, though all those steps have their own separate scripts for the admins who want to still perform manual maintenance. We have covered the main steps already in detail in above section, we will provide a summary below of each step for what it does.

Update spDeleteUpdate procedure: This part of the script modifies a core stored procedure in SUSDB, which perform poorly when records in large databases are being deleted in later steps in the procedure. The slow performance is caused due to a primary key not set on a temporary table created by spDeleteUpdate, running the script in this step on SUSDB on every WSUS server sets the primary key for that temporary table.
Shrink SUSDB Files: This step shrinks the SUSDB files to reduce their size using DBCC SHRINKFILE command, specifically SUSDB.mdf and SUSDB.ldf.
Shrink SUSDB Database: This step in the script attempts to shrink the overall database including every file simultaneously within the database, using DBCC SHRINKDATABASE
Reindex and Update Statistics: This step rebuilds fragmented database indexes and updates statistics to ensure later steps; specifically superseded updates cleanup process would run faster rather than slower on fragmented indexes.
Cleanup Sync History: This step in script removes synchronization log records from multiple history tables of each WSUS database, ensuring that update cleanup steps run smoothly.
Cleanup Superseded Updates Older than x Days: provides the option to set the number of days in script for superseded updates to keep and decline, and prepares them for removal, some organizations have longer period such as 90 days, but most organizations keep the 30 days updates for rollback purpose.
Cleanup Obsolete Updates: Deletes expired updates and retired marked updates by Microsoft, most of these updates are already separated by the previous decline update removal step.
WSUS Cleanup Wizard: This part of the script invokes the equivalent of the cleanup wizard already covered in earlier section; at this point the wizard works on a much smaller and cleaner dataset and completes faster, it deletes the actual installation files for updates which were declined in previous steps.
Cleanup Declined: Physically deletes the metadata and content for marked declined updates, finalizing the deletions.
Shrink SUSDB Files: This second file shrink claims the freed up files space after the cleanup wizard, most importantly the ldf transaction log, which expanded massively after the processing of deletion by cleanup wizard.
Shrink SUSDB database: This second database shrink claims the unused space for whole database after the deletion of thousands of updates records in cleanup process.
Final Reindex: This step re-indexes the whole SUSDB database again for any fragmentation caused by the deletion of thousands of records in steps 5 to 9, ensuring that WSUS console responds quickly to user queries from next business day.

Running all maintenance steps sequentially (end-to-end workflow)

Though all the steps in script are listed in an order and can be executed manually from within the script using step number, Microsoft maintenance script also provides the option “Run All” which executes all 12 steps in sequence automatically, which removes the risk of human error. As synchronization and maintenance process put heavy load on SUSDB, it is recommended to execute this workflow outside of scheduled upstream sync window to avoid resources consumption. Total runtime of the script depends on the database size, whether it is regularly maintained or a first run on a long neglected WSUS server, it typically takes 30 to 90 minutes to complete for maintained server, and several hours for a first run.

Setting up the WSUS cleanup task in Task Scheduler

Even the script automates most of the cleanup task, but then again someone has to remember to run it manually, windows task scheduler address this part of automation, admins can schedule the script to run on a specific day such as second Saturday of every month, aligning with Microsoft’s patch Tuesday. Below is a small PowerShell script which can be used to create scheduled tasks on every WSUS server.

$action = New-ScheduledTaskAction -Execute “PowerShell.exe” -Argument “-File C:\Scripts\WSUSMaintenance.ps1”

$trigger = New-ScheduledTaskTrigger -Weekly -WeeksInterval 4 -DaysOfWeek Saturday -At 4am

Register-ScheduledTask -TaskName “WSUS Monthly Maintenance” -Action $action -Trigger $trigger -RunLevel Highest

The above script is an illustration of how you can create schedule tasks based on your desired frequency, though one thing New-ScheduledTaskTrigger cmdlet lacks is the parameter for creating monthly basis tasks exactly, which GUI provides extensively. But there are other ways to accomplish that, simplest is to use the below command using the native “Schtasks.exe” utility, you can run this command in CMD or directly in PowerShell, it creates a schedule to run WSUS maintenance script on every second Saturday of every month.

schtasks.exe /Create /TN “WSUS Monthly Maintenance” /TR “PowerShell.exe -NoProfile -WindowStyle Hidden -File C:\Scripts\WSUSMaintenance.ps1” /SC MONTHLY /MO SECOND /D SAT /ST 04:00 /RL HIGHEST /RU “NT AUTHORITY\SYSTEM”

Setting up the SUSDB reindex for WID via SQLCMD and Task Scheduler

Though Microsoft maintenance script explicitly checks the SQL type e.g. full SQL or WID using registry and performs reindexing on SUSDB, but some admins may want to know the exact SQLCMD command to run that part of the script using T-SQL. Below is the exact command you can run on command prompt or PowerShell.

sqlcmd -S \\.\pipe\MICROSOFT##WID\tsql\query -i “C:\Scripts\ReindexSUSDB.sql”

They can create a schedule using the below XML file, you can just copy and paste it into a notepad file and rename its extension to .XML. This specific xml creates trigger as every Saturday of second week of every month. Then you can import this xml in Task Scheduler console using Import Task option from Action pane on right hand side.

<?xml version=”1.0″ encoding=”UTF-16″?>

<Author>SYSTEM</Author>

<Description>Monthly WID Reindex on the second Saturday of every month.</Description>

</RegistrationInfo>

<Weeks>

</Weeks>

</DaysOfWeek>

<May />

</Months>

</ScheduleByMonthDayOfWeek>

</CalendarTrigger>

</Triggers>

<RunLevel>HighestAvailable</RunLevel>

</Principal>

</Principals>

<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>

<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>

<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>

<StartWhenAvailable>false</StartWhenAvailable>

<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>

<RestartOnIdle>false</RestartOnIdle>

</IdleSettings>

<Hidden>false</Hidden>

<RunOnlyIfIdle>false</RunOnlyIfIdle>

<WakeToRun>false</WakeToRun>

</Settings>

<Exec>

<Command>sqlcmd</Command>

<Arguments>-S np:\\.\pipe\MICROSOFT##WID\tsql\query -i “C:\Scripts\ReindexSUSDB.sql”</Arguments>

</Exec>

</Actions>

</Task>

If you do not like to open the Task Scheduler window and want to import the xml using command prompt or PowerShell, use the below commands.

Task Scheduler Command line utility

schtasks /create /xml “C:\Scripts\ReindexSUSDB.xml” /tn “WID Maintenance Reindex”

PowerShell cmdlet

Prerequisites Before Starting WSUS Maintenance

You must thoroughly prepare your update infrastructure before running any intensive database or script operations, negligence can result in database corruption, corrupt metadata deployment or disrupted replication cycles across your WSUS infrastructure.

Back up the WSUS database

Performing SUSDB backup is crucial before performing cleanup, if anything in cleanup process goes wrong such as declining wrong updates or a reindex failure, a backup is the only reliable way to recover without standing up a WSUS server from scratch. Admins can take SUSDB backup using T-SQL command or via SSMS GUI, both processes are mentioned below.

SSMS GUI

Right click on SUSDB in Object ExplorerèSelect TaskèSelect BackupèSelect DiskèBrowse and add the location where you want to backup the database. You can also select many options such as Full back up or Differential.

T-SQL Command

T-SQL approach can be used for both SQL instance and WID.

BACKUP DATABASE SUSDB TO DISK = ‘C:\backup\SUSDB.bak’ WITH INIT, STATS = 10;

Disable synchronizations before running maintenance

Automated synchronization should be disabled before performing maintenance, as both processes use the same resources on SUSDB, an active sync can pose risk of corrupting data or failure of both processes. This synchronization disable requirement applies to all WSUS servers in hierarchy, not just the one on which maintenance process is being performed, leaving sync active anywhere in network topology can damage the data in the SUSDB where the cleanup operation is being performed.

Below are the steps to disable synchronization schedule via WSUS console and PowerShell.

WSUS GUI

WSUS ConsoleèOptionsèSynchronization ScheduleèSelect the radio button “Synchronize Manually”.

PowerShell Script

Using PowerShell on WSUS Server

$Sub = (Get-WsusServer).GetSubscription()

$Sub.SynchronizeAutomatically = $false

$Sub.Save()

Using PowerShell for Remote WSUS Server

$WsusServer = Get-WsusServer -Name “YourWSUSServerName” -PortNumber 8530

$Sub = $WsusServer.GetSubscription()

$Sub.SynchronizeAutomatically = $false

$Sub.Save()

Understanding WSUS hierarchy: upstream and downstream servers

Upstream WSUS server is the first point of contact for new updates before their distribution across other WSUS servers, it synchronizes directly with Microsoft Update Server or a local update repository. Downstream layered structure is common in large organizations; they synchronize from the upstream server instead of directly connecting to Microsoft Update Server. This multiple WSUS server topology determines the maintenance order, it should always be from upstream level down to downstream level, maintaining servers out of order can introduce inconsistencies.

Replica vs autonomous downstream servers

Replica downstream WSUS servers are the mirrors of the upstream server with respect to approval decisions and configuration, coming form upstream server, that is why there is no need to run the decline script on them, it is sufficient to run only on upstream server. Autonomous downstream WSUS servers maintain their own approval decision, which is separate from upstream server, meaning each autonomous server can have its own unique superseded updates and needed to run the decline script because upstream decline update script does not touch them. An example would be a branch office autonomous server set up for different set of updates that the head office server, branch office WSUS admins run the decline script locally rather than relying on upstream.

Maintenance Order for WSUS Hierarchies

Top-down rule: run approvals and declines from upstream first

Imagine if decline and approval status on a downstream server doesn’t match with what is on upstream server, performing decline on downstream server creates a mismatch, it will be overwritten in next sync due to approvals and decline decisions replicating downwards. So, the upstream server must be the first place to run declines, sync downstream, then proceed, never the other way around. This ordering makes sure that every downstream server inherits an already finalized decline decisions instead of their own copy of declines.

Bottom-up rule: run deletions and cleanup from downstream first

Unlike approvals and declines, deletion and cleanup do not replicate, suppose if the upstream server deletes the update files in cleanup process which downstream servers did not finish synchronizing yet, and request them but those files are no longer available on upstream server. Deletion and cleanup process must be started at the lowest level downstream server, climbing upward to upstream server preventing missing files sync errors. This way, every downstream server has already finished requesting update content it needed, removing it on upstream server will not create dependency conflict.

Running the full hierarchy end-to-end

The maintenance run on a one upstream server and two downstream replicas follows a six step checklist, which also follows both top-down and bottom-up rules correctly, preventing sync errors, mismatch approvals and decline status. Below is the six step checklist.

Sync both downstream replicas with upstream server.
Disable automatic sync on all three servers.
Backup SUSDB on all three servers.
Run decline script on upstream serverèsync manually to downstream replicas.
Run full cleanup on downstream replicas first, then on upstream server.
Re-enable automatic synchronization schedule on all three servers.

Troubleshooting WSUS Maintenance

Cleanup wizard keeps timing out on a neglected WSUS server

Problem

A WSUS server which have not been maintained for months or years, its SUSDB database may contain hundreds of thousands of updates, excessive metadata and fragmented indexes which are causing the cleanup wizard to frequently time out.

Solution

Run the T-SQL database reindexing step first as part of SUSDB maintenance, then run the cleanup wizard again, rebuilding the fragmented indexes optimize query performance, making it the most affective resolution for cleanup timeouts. If the GUI-based Cleanup Wizard continuously fails, you can try Invoke-WsusServerCleanup via PowerShell, which generally handles large database clean up more reliably than the GUI.

Decline script times out or returns a 401 error

Problem

Superseded updates decline script times out or failing with http 401 errors when attempting to communicate with WSUS server using PowerShell remoting.

Solution

A http 401 error typically indicates un-authorization, authentication or permission issue, confirm that account running the script is member of the WSUS Administrators group and is local administrator, verify that WinRM is also enabled on the target server. Timeout error may also indicate processing workload e.g. hundreds of thousands of updates, try with reduced number of updates with each run by increasing the exclusion period from 30 days to 60 or 90 days. Below is the sample script run command.

.\Decline-SupersededUpdatesWithExclusionPeriod.ps1 -ExclusionPeriod 60

Run the script again with reducing the exclusion period e.g. 30 days again, the first run have processed the smaller chunk with 60 days exclusion, and second run will process the remaining updates.

Recovering an update you accidentally declined

Problem

Occasionally, admins accidentally decline an update that may be a dependency for another update and want to recover it now.

Solution

Declined updates can be directly restored from WSUS console by navigating to UpdatesèAll UpdatesèChange Approval filter to DeclinedèClick RefreshèIn the list of all declined updates, right click on desired update and select Approve.

Note: At least one synchronization cycle is needed to complete before the update is visible to client computers.

Discover our complete WSUS Setup Guides

Topic	Short Description
WSUS Alternatives	Compares seven leading WSUS replacements based on cross-platform and third-party patching, automation, reporting, remote endpoint support, deployment model, and suitability for different IT environments
WSUS Patch Management Guide	Explains how WSUS centrally synchronizes, approves, deploys, and monitors Microsoft updates, along with its benefits, limitations, and alternatives
WSUS EOL	Explains what Microsoft’s WSUS deprecation means, how long WSUS will remain supported, and which migration paths and modern alternatives organizations should consider.
WSUS vs SCCM	Compares WSUS with SCCM across patching, software deployment, device management, reporting, complexity, cost, and suitable deployment environments
WSUS Windows 11 Update Guide	Provides a practical guide to configuring WSUS to approve, deploy, monitor, and troubleshoot Windows 11 updates across managed devices
Managing Third-Party Apps with WSUS	Explains how third-party applications can be patched through WSUS using external catalogs and publishing tools, including setup, signing, deployment, and reporting
WSUS Ports Setup	Details the network ports, firewall rules, SSL, proxy, DNS, and routing configurations required for reliable WSUS synchronization and client communication
WSUS Offline Update	Explains how to download and deploy Microsoft updates in offline or air-gapped environments using local repositories and removable installation media
WSUS Registry Settings	Documents the key Windows Update and WSUS registry values used to control update sources, schedules, reboots, device groups, and deployment behavior
How to Disable WSUS Registry	Provides step-by-step instructions for removing WSUS registry configuration so Windows clients can reconnect directly to Microsoft Update.
WSUS Server Cleanup Wizard	Explains how to run and automate the WSUS Cleanup Wizard to remove obsolete updates, inactive devices, expired metadata, and unnecessary files
WSUS Synchronization Failed Fix	Troubleshoots common WSUS synchronization failures caused by TLS, IIS, firewall, proxy, operating-system compatibility, and SUSDB database issues.
Intune vs WSUS	Compares cloud-based Intune with on-premises WSUS across update control, supported devices, infrastructure, security, costs, and migration considerations.