How to get a list of every WSUS update using PowerShell

Recently I needed to get a list of every update on my WSUS server, due to a bug in System Center Essentials which leaves orphaned folders on the server even when locally-published updates have been removed using the console (the Server Cleanup tool doesn’t get rid of these files either – see this post on TechNet.

The folders in question were all in the WSUS\UpdateServicesPackages directory, and are named according to the GUID of the update in WSUS. The WSUS console doesn’t provide any way to get a list of GUIDs that are valid updates, but you can do it using the WSUS .NET API, which is accessible via PowerShell.

Update: If you’re only interested in which folders to delete, without any additional information, you can run wsusutil listunreferencedpackagefolders from the %Program Files%\Update Services\Tools directory. This command is mysteriously missing from any online documentation from MS.

Here’s a sample script to get the GUIDs. You’ll need to customise line 2 to reflect the FQDN of your WSUS server, along with whether to use SSL and the port number. You’ll either need to run the script using an account with admin rights to WSUS, either on the WSUS server itself, or on a workstation with the WSUS console installed.

[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer('updates.angrytech.internal',$False,80)
#Get all updates
$updates = $wsus.GetUpdates()
#Iterate every update and output some basic info about it
ForEach ($update in $updates) {
New-Object PSObject -Property @{
Id = $update.Id.UpdateId.ToString()
Title = $update.Title
Source = $update.UpdateSource.ToString()
}
}

(With thanks to Boe Prox’s excellent series of articles on managing WSUS with PowerShell)

This will spit out a (very long) list of every update update GUID on the server, the source of the update (either MicrosoftUpdate or Other for local packages), and its Title (which will probably be truncated).

How you then use this list is up to you, but I went with importing it into Excel, then using VLOOKUP with a list of folders that were on the server and seeing which folders matched up to updates and which didn’t. If I had taken the time I could have automated the whole thing, but I chose not to because I wanted to manually check the contents of each folder anyway before deleting it. Whatever method you choose, do so at your own risk.

In all, I found more than 8GB of orphaned files spread across more than 70 packages that I had previously removed from the SCE console over the last year. That amounted to nearly 20% of the total space used by WSUS, so we’re not talking about small amounts of wastage here.

The TechNet post I mentioned above is from nearly 3 years ago, and originally referred to SCE 2007. That this bug hasn’t been fixed after 3 years and a whole major version later is frankly pitiful.