So you broke WSUS? How to fix the broken Windows 10 upgrade classification

• Author
• Recent Posts

Joseph Moody

Joseph Moody is a network admin for a public school system and helps manage 5,500 PCs. He is a Microsoft Most Valuable Professional (MVP) in Cloud and Datacenter Management and blogs at DeployHappiness.com.

Latest posts by Joseph Moody (see all)

• SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
• Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
• PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019

We can expect to see several major updates to Windows 10 each year. Keeping up with these updates can be very difficult depending on how they are treated. If you are like many IT administrators, you probably held off on the early releases and decided to let someone else sort through potential problems.

With another release on the horizon, you decided to catch up and enable the Upgrades classification. And that is where WSUS betrayed you.

The WSUS Upgrades button looks so innocent.

Without a bit of prep work, the WSUS environment doesn’t understand the components needed to download and deploy the Windows 10 upgrade. The upgrade has been downloaded but it has been saved to the WSUS database as a regular update.

This problem was preemptively fixed by installing the hotfix for KB 309511. Until recently, the instructions for remediating an environment without KB 309511 were not available. A few different methods of fixing this problem exist. The solution outlined below is the official response from the WSUS product team, with a bit more explanation.

The five steps steps below fix improper upgrades in WSUS below specifically show how to undo the damage caused by improper syncing of the Windows 10 1511 upgrade. You can modify these steps for future versions if needed.

Although you should do most steps in PowerShell, you can do some from the GUI if you prefer. The PowerShell commands use the UpdateServices module, and you should run them from an elevated PowerShell window on the WSUS server(s).

Step 1: Uncheck the Upgrades classification

The Upgrades classification will need to be disabled on your standalone WSUS server or your highest WSUS instance in your update hierarchy (the server that directly syncs with Windows Update). Simply uncheck the classification (as seen in the picture above) or run the following PowerShell command:

Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification -Disable

Step 2: Remove the improperly synced upgrade content

This next step involves deleting the actual Windows 10 upgrade files. You will need to use PowerShell for this step. You’ll need to repeat this step on every WSUS server in your environment. Start from the highest server and work down.

In the second line, note the version number that is being queried. If you are having issues due to an upgrade that is not version 1511, you will need to change this line.

$s = Get-WsusServer
$s.SearchUpdates(“version 1511, 10586”) | foreach { $s.DeleteUpdate($_.Id.UpdateId) }

Step 3: Install the hotfix for KB 3095113

You can download the hotfix from here: https://support.microsoft.com/en-us/kb/3095113 . If you haven’t read up on exactly what this hotfix does (and why it was released as a hotfix in the first place), read this explanation. As a precaution, reboot the WSUS server after applying this update.

Step 4: Enable the Upgrades classification

We are back to a supported WSUS state now, and the environment is ready to handle the new format for upgrades. Re-enable the Upgrades classification on your top WSUS server by using the GUI or the following PowerShell command:

Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification

Step 5: Sync your WSUS server

The final step is to perform a full sync on your top WSUS server. To do this, run the following PowerShell commands from that server:

$sub = $s.GetSubscription()
$sub.StartSynchronization()

 With that, your environment should be fully compliant and able to deploy the latest Windows 10 upgrade! If you have any issues (or improvements to this process), let us know in the comments below. You can read the original TechNet guidance here and here.