The error code reveals nothing. Nothing useful in the event viewer either. But the log from WSUS does.

(Unable to Find Resource ) ReportingEvent. Client 181: Parameters: Feature update to Windows 10 (consumer editions), version 20H2, en-us x64

More specifically, the message “unable to find resource” indicates that the workstation can’t find and download the upgrade package from the WSUS server. Since the update package has an extension name .esd that is a supported MIME type on IIS server out of the box, adding the extension name should fix the whole thing.

Go to the server that runs WSUS service, open IIS manager, and select the server name on the left and open the MIME type on the right.

Click Add and add the following type to the server.

File name extension: .esd
MIME type: application/octet-stream

Now back to the workstations that failed the updates earlier and give another try. This time, Windows 10 20H2 upgrade should go through fine with no more errors.

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.

Open Command Prompt window, navigate to the following folder:

C:\Program Files\Update Services\Tools

And run the following command.

WsusUtil MoveContent new_location move_log

If you already copied the content folder you can use the SkipCopy switch to bypass the copying process.

The relocation process could take a while to finish but once it’s done, it’s all set and you can go ahead remove the old content folder.

Windows could not search for new updates

Errors found: Code 80244008

On Windows 10, the error message is slightly different.

There were some problems installing updates, but we’ll try again later…(0x8024401f)

What’s the cause?

I believe it’s this Windows update (KB4025336 – 2017-07 Security Monthly Quality Rollup for Windows Server 2012 R2 for x64-based Systems) that caused the issue. Basically, if your WSUS service is running on the default port 8530 you will likely have this issue on your network.

Solutions

Obviously, removing the troublesome KB4025336 should be able to rollback the WSUS server to the last working state.

But if that’s not the option, you can also run the following commands to reset WSUS’ IIS port.

wsusutil.exe usecustomwebsite true
wsusutil.exe usecustomwebsite false
iisreset /restart

Note that the command line wsusutil.exe is located in the following folder:

C:\Program Files\Update Services\Tools

Once IIS server restarted, try Windows Update again on a workstation. If it fails again with a different error message like below,

Windows could not search for new updates

Errors found: Code 80072EE2

Check the Group Policy setting and specify the port number in the following group setting.

Specify intranet Microsoft update service location

Now everything should be back to normal now.

The bad news is that there is no way to check download status for individual updates but the good news, you can see the overall status right from WSUS console.

Open WSUS console and click the server name.

In the Overview section, you will see a section called Download Status in where it lists how many update files are downloading, how much has been downloaded and how much in total that needs to be downloaded.

That’s actually enough for me.

If that happens, here is how you can import these updates into WSUS so you can distribute them automatically.

First of all, set Internet Explorer as the default browser on WSUS server.

Then, open WSUS console, right-click Updates under the Server name and choose Import Updates…

It opens Microsoft Update Catalog page in Internet Explorer. Type the KB number for the update you want to import in the search box and click the Search button.

The list of the target updates show up, click the Add button next to the one you want to import to add them to the basket.

The number next to the basket changes once the update was added. Click view basket link once done, and click Import button to start importing the updates into WSUS.

Then, find the newly imported update in WSUS and approve it so it can be downloaded and deployed.

Turns out, what’s caused this problem is that the server was configured to use WSUS instead of Microsoft Windows Update server. Because Windows needs to download the 3.5 installation files from Windows Update service, it couldn’t if it’s configured to use WSUS.

The fix is also pretty straightforward, just one Group Policy setting that needs to be changed. And you can do so through Local Group Policy so it doesn’t affect the Group Policies you have in place on a domain level.

Open Group Policy Editor, navigate to the following location:

Computer Configuration > Administrative Templates > System

Open “Specify settings for optional component installation and component repair” setting, select Enable and choose the “Contact Windows update directly to download repair content instead of Windows Server Update Service (WSUS)” checkbox.

Click OK.

.Net 3.5 feature got installed successfully after I tried again.

The reason why the error occurs is that the Application Pool that runs the WSUS service stopped.

Go to the WSUS server and open IIS Manager. Click Application Pools, select WsusPool, and click Start to restart the Application Pool.

Now, let’s try again on the workstation and see if the updates can go through.

The consequence of having this WsusPool application pool stopped is that you can’t access the WSUS dashboard on the WSUS server either, a Connection Error awaits you there instead.

If this happens often, it will delay your workstation/server update process. Better to address it now rather than later. As this post points out, to prevent WsusPool from being stopped, you will need to disable the Rapid-Fail Protection and increase the Private Memory Limit.

Where do I find these two settings?

Highlight the WsusPool in the IIS Application Pools window, and click the Advanced Settings… on the right side Actions pane.

Scroll down a bit towards the bottom of the list, change the Enabled setting for the Rapid-Fail Protection to False, and increase the Private Memory Limit to 3GB under the Recycling section.

Click OK to save the settings and restart the WsusPool.

After I successfully added WSUS as a service role to the server, I need to run the Post-installation process to complete the whole installation. And that’s where the issue started.

Fatal Error: Failed to start and configure the WSUS service

After looking at the log file indicated in the Notification window, here is what I found:

2016-12-21 10:06:27  CreateDefaultSubscription failed. Exception: System.InvalidOperationException: Client found response content type of 'text/html; charset=utf-8', but expected 'text/xml'.
The request failed with the error message:
--
<html>
    <head>
        <title>Could not load file or assembly 'Microsoft.UpdateServices.WebServices.ApiRemoting' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.</title>
        <style>
         body {font-family:"Verdana";font-weight:normal;font-size: .7em;color:black;} 
         p {font-family:"Verdana";font-weight:normal;color:black;margin-top: -5px}
         b {font-family:"Verdana";font-weight:bold;color:black;margin-top: -5px}
         H1 { font-family:"Verdana";font-weight:normal;font-size:18pt;color:red }
         H2 { font-family:"Verdana";font-weight:normal;font-size:14pt;color:maroon }
         pre {font-family:"Lucida Console";font-size: .9em}
         .marker {font-weight: bold; color: black;text-decoration: none;}
         .version {color: gray;}
         .error {margin-bottom: 10px;}
         .expandable { text-decoration:underline; font-weight:bold; color:navy; cursor:hand; }
        </style>
    </head>

It took me at least one hour to finally figure it out. It’s basically the setup in Application Pools in IIS that messed things up. To fix it up, open IIS Manager, head over to Application Pool, and set WsusPool to use .Net v4.0 instead of v2.0 in my case.

Once done, I started the Post-installation again and it went all the way to the end successfully without any further issues.

On another note, there is another different error that also causes post-installation to fail.

CreateDefaultSubscription failed. Exception: System.Net.WebException: The request failed with HTTP status 503: Service Unavailable.

If that’s the case for you, all you need to do is to remove WSUS Administration site in IIS and start the post-installation process again.

That’s about it. Hopefully, it helps.

There is a Group Policy setting that you can alter to bypass getting the updates through WSUS.

Open Group Policy Editor (local or in AD), go to Computer Configuration → Policies → Administrative Templates → System, and open a setting called Specify settings for optional component installation… on the right-side panel.

Then select Enabled, and check the option “Contact Windows Update directly to download repair content instead of WSUS”

Click OK and done. Run “gpupdate /force” to update the changes on the workstations to avoid the reboot.