WSUS – Hitting the Reset Button

My WSUS server was hitting a point where it’s got so big that not only does it take huge amount of space but it can hardly finish any tasks. The total size of the WSUS folder hit a whooping 3 TB with a database almost over 20 GB.

Time to hit the reset button.

Here is the steps to take to completely wipe out the WSUS on your server.

Step 1 – Uninstall WSUS role and WID (Windows Internal Database) feature and restart the server.

You can do so either follow the GUI wizard or run the following PowerShell cmdlet.

Uninstall-WindowsFeature -Name UpdateServices,Windows-Internal-Database -Restart

Step 2 – Delete WSUS folder and Remove WID database

Removing the WSUS role and WID feature doesn’t automatically remove the actual WSUS content folder and WID database. You need to manually delete the WSUS folder and the susdb.mdf WID database file. If WSUS is the only one using WID, you can delete everything from that folder. The database file is located in the following place:

%windir%\WID\data\

Step 3 – Install WSUS and WID

Now reinstalling WSUS role and WID feature will result in a fresh new installation. You should have no problem going through the post-configuration process and have a clean new WSUS.

Step 4 – Decline all the superseded updates

To avoid the size of the WSUS content folder goes crazy again, I found this PowerShell script that runs through all the updates from selected categories and declines all of those that are superseded so they won’t be downloaded again once turning on the Auto-Approval policy.

#Change server name and port number and $True if it is on SSL

$Computer = $env:COMPUTERNAME
$Domain = $env:USERDNSDOMAIN
$FQDN = "$Computer" + "." + "$Domain"
[String]$updateServer1 = $FQDN
[Boolean]$useSecureConnection = $False
[Int32]$portNumber = 8530

# Load .NET assembly

[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")

$count = 0

# Connect to WSUS Server

$updateServer = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($updateServer1,$useSecureConnection,$portNumber)

write-host "<<<Connected sucessfully >>>" -foregroundcolor "yellow"

$updatescope = New-Object Microsoft.UpdateServices.Administration.UpdateScope

$u=$updateServer.GetUpdates($updatescope )

foreach ($u1 in $u )
{
if ($u1.IsSuperseded -eq 'True')
{

write-host Decline Update : $u1.Title

$u1.Decline()

$count=$count + 1

}

}

write-host Total Declined Updates: $count

trap

{
write-host "Error Occurred"
write-host "Exception Message: "
write-host $_.Exception.Message
write-host $_.Exception.StackTrace
exit
}
# EOF

Here is how many of them being declined, 2818 updates out of 4110 have been declined.

Step – 5 – Turn on Automatic Approval Rule (optional)

If this is what’s planned, go right ahead and enable the rule and run it.

Lastly, note that this procedure is still for Windows Server 2012 R2 so the procedure may be a bit different for the later versions.