Answered by:

Clients failing to connect to WSUS - 80244008

Question

Was working OK yesterday, 28 June 2017.
This morning, 29th June, large number of clients (possibly all) are failing to communicate correctly, eg when attempting to do a manual "Check for Updates". Windows 7 (x86) and Server 2008r2 come up with 80244008. A windows 10 client (x64) and 2012r2
gave error 8024401f. The WSUS management console opens without any issues.

Last status report of any client into WSUS is 630am this morning, which appears to be about 10 minutes after a restart of the WSUS Server to install 2 MS Updates this morning. 4022720 (preview of monthly rollup) and 4037282 (update for Internet explorer).

I suspect one of those updates is the issue. I've checked the details of 4022720 and can't see anything obvious that would affect IIS or WSUS, nor guidance to run any post install steps. If necessary I can uninstall, but would prefer not to, as that would
only delay the issue until middle of next month when the general release of what is in 4022720 is pushed out. I have, though re-run the steps from the update that came out a year ago.

Our server is configured to use port 80, so no SSL involved, but I'm wondering if something in one of the above updates has done something to affect this.

There are a few messages in Application log and other logs that may prove useful...

Exception: System.ServiceModel.ServiceActivationException: The service '/ClientWebService/client.asmx' cannot be activated due to an exception during compilation. The exception message is: Could not find a base address that matches scheme https for
the endpoint with binding BasicHttpBinding. Registered base address schemes are [http].. ---> System.InvalidOperationException: Could not find a base address that matches scheme https for the endpoint with binding BasicHttpBinding. Registered base address
schemes are [http].

Thanks for feeding back the information, we'll keep eyes on this topic and try to report this behavior to our Product Team for further confirmation. If there is any news, we'll feedback as soon as possible.

Best Regards,

Anne

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.

I had this problem but today it has been solved by changing the WSUS port to 8530 (default port for WSUS in Windows server 2012) and also I changed the port in GP, to be deployed on clients. The details are written in this link

Seriously Microsoft do you even test updates any more? We patch our environments religiously but it seems every month since late last year the quality of Microsoft updates has taken a huge dive. Something or the other breaks every month.

This month Wsus broke and we are lucky to have a semi production Wsus environment.

June 27, 2017—KB4022720 (Preview of Monthly Rollup)

Seriously Microsoft do you even test updates any more? We patch our environments religiously but it seems every month since late last year the quality of Microsoft updates has taken a huge dive. Something or the other breaks every month.

This month Wsus broke and we are lucky to have a semi production Wsus environment.

If you're installing the same patch, why are you installing PREVIEW patches? These are known to have issues and are not the final CU.

1. Remove all Drivers from the WSUS Database.
2. Shrink your WSUSContent folder's size by declining superseded updates.
3. Remove declined updates from the WSUS Database.
4. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
5. Compress Update Revisions.
6. Remove Obsolete Updates.
7. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
8. Application Pool Memory Configuration to display the current private memory limit and easily increase it by any configurable amount.
9. Run the Recommended SQL database Maintenance script on the actual SQL database.
10. Run the Server Cleanup Wizard.

It will email the report out to you or save it to a file, or both.

Although the script is lengthy, it has been made to be super easy to setup and use. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment, simply run:

.\Clean-WSUS.ps1 -FirstRun

and then

.\Clean-WSUS.ps1 -InstallTask

If you wish to view or increase the Application Pool Memory Configuration, you must run it with the required switch. See Get-Help .\Clean-WSUS.ps1 -Examples

If you're having trouble, there's also a -HelpMe option that will create a log so you can send it to me for support.

This script may be a good solution to optimized WSUS and save space but it's not solving the big problem the lastest Microsoft update give to us...

We are still waiting for a patch or a solution from Microsoft before tomorrow... The next monthly update is tomorrow ! What are you doing Microsoft !?

Maybe not, but the bigger question you haven't answered is why are you installing preview updates that are KNOWN to have issues - they are preview to the next CU. It's easier to place the blame somewhere else, but unless you have a SPECIFIC reason to install
a preview update (I've had 1 since they started releasing them, and it did fix my issue), you should be denying all preview updates.

I install this preview update because Microsoft tag it like critical. And if the problem is present in the preview update, i'm pretty sure that the "final update" of tommorow are going to have the same problem...

I install this preview update because Microsoft tag it like critical. And if the problem is present in the preview update, i'm pretty sure that the "final update" of tommorow are going to have the same problem...

Microsoft tagged it as an "Update" - NOT a "Critical Update" or a "Security Update", but just a plain old "Update". If you have auto-approvals on, make sure it's not approving everything that comes through for "Updates".
Only Critical and Security Updates should be auto-approved, if you're going to use auto-approvals.

KB4025336 is now available. This update is the final version of the Preview update KB4022720 who is giving us problem with WSUS. I first install the preview update KB4022720, detect the WSUS problem, uninstall KB4022720, problem solve.

I just install KB4025336 without reinstalling KB4022720 on my WSUS Server. I test WSUS after the installation and i have the same problem : 8024401F error code on all client when trying to search for new update from WSUS Server!

Just come into work this morning, and found that my WSUS server is broken (again) after it installed 4025336 & 4025333 last night automatically.

In response to people asking why install "preview" updates... someone has to, otherwise issues like this don't get spotted in time. Now that the proper update is out, I've going to have 2 broken WSUS Servers now, rather than just the 1 for when
the preview came out.

Hi! For me the same: after installing KB4025336 WSUS is broken. Clients doesn't connect to wsus - no recent reports can be transfered from clients to WSUS.

Many Errors in Application Log:

Source: System.ServiceModel 4.0.0.0
Event-ID: 3
Description: WebHost could not process a requirement. Service '/ClientWebService/client.asmx' could not be activated due an exception while compiling. There is no basic adress that fits with scheme "https" for endpoint with binding "BasicHttpBinding".
(translated from german)

So its not one of the security updates but one of the additional features you get in the Security Quality Monthly Rollup causing the issue. I had only mentioned both, as both had installed overnight onto our server.

We have the same issue - installing KB4025336 prevents clients from reconnecting to our WSUS server (uninstall fixes it again). So we cannot install the July roll-up, and presumable won't be able to install any subsequent roll ups until this is fixed :-(

We have had the same issue with the latest batch of updates. I tried updating the patches in different orders, but KB4025336 always causes the clients to fail. All other patches are installed, so it's still working. Hopefully, MS will have a fix for this
fix out pretty soon.

Adam, Microsoft can be happy, that people are willing to install the Preview Updates, to have them find possible issues early. It is a shame that MS didn't react on the early complaints with the Preview Updates and released the final Monthly Rollups
with the same glitches. Even today they do not even acknowledge the issue, see both KB4025331 (Server 2012) and KB4025336 (Server 2012 R2), not mentioning anything about WSUS trouble. Wondering if, how and when they will deal with that issue...

I DO use SSL as it's a Microsoft Best Practice. My cert is one from my Internal CA.

I follow a really smart guy named Emin Atac (he was the one who helped me develop part of my WSUS Script) and he posted something that was enlightening in all regards with regards to WSUS and MITM attacks and how relatively easy it would be to compromise
a network.

Adam, i want to use SSL with my WSUS but i have a error after trying to switch from port 8530 non-ssl to port 8531 SSL : I have a error message telling me that the ssl certificat of this server can't be validated when im trying to open my WSUS console.

I also have Code 80072F8F when trying to search for Update with clients.

I would like to return to the original subject of the thread which was issues introduced by KB4022720 & KB4025336. After doing a fair amount of testing I have come to the conclusion that Microsoft have incorporated KB3159706 into the July 2017
rollup for 2012 R2 with one major exception; they have added the updates to the ClientWebService web.config listed at item 3 in the article into the rollup. This is borne by the fact that the file information for the web.config contained in each update
has a different date (KB3159706 has a modification date of 8-Mar-2016 whereas KB4025336 by comparison is 10-May-2017).

I discovered this by accident when I applied KB4025336 to a WSUS server which I'd forgotten to apply KB3159706 to. In order to get WSUS working again I had to run the postinstall /servicing and enable .NET4.5 WCF HTTP Activation.

My research also leads me to believe that if you have previously installed KB3159706 to your WSUS server and are using the custom website WSUS will continue to function without any issues after the application of KB4025336 regardless of whether you use SSL
or not. This is because a https binding to 8531 looks to be automatically created for the WSUS website in this scenario. If you run WSUS using the default website and do not use SSL WSUS will run into issues. This is because the changes to
the web.config add support for SSL, but the default website does not appear to have a binding for https to port 443 by default. This can be fixed in 1 of 3 ways:

Remove the SSL entries from the web.config as originally posted by R S Thomas on Friday (see higher up the thread). My concern with this solution is that the next rollup might reapply the updated web.config

Add https binding for 443 manually as also posted by R S Thomas on Friday

Run wsusutil.exe usecustomwebsite true followed by wsusutil usecustomwebsite false. This also adds the required https binding to the default website.

Seriously Microsoft do you even test updates any more? We patch our environments religiously but it seems every month since late last year the quality of Microsoft updates has taken a huge dive. Something or the other breaks every month.

This month Wsus broke and we are lucky to have a semi production Wsus environment.

If you're installing the same patch, why are you installing PREVIEW patches? These are known to have issues and are not the final CU.

Yes, i create a domain certificat with my WSUS serveur Who is also CA.

I now use WSUS on SSL port 8531 with my own Domain certificat on Windows Server 2012 R2. Evrything is working great until i install KB4025336. After that, i can open my WSUS console but all my client can't connect anymore to check for update. Evrything is
going back to normal after i unstall KB4025336...

I try all the solutions proposed on this page and nothing work for me.

Yes, i create a domain certificat with my WSUS serveur Who is also CA.

I now use WSUS on SSL port 8531 with my own Domain certificat on Windows Server 2012 R2. Evrything is working great until i install KB4025336. After that, i can open my WSUS console but all my client can't connect anymore to check for update. Evrything is
going back to normal after i unstall KB4025336...

I try all the solutions proposed on this page and nothing work for me.

Have you previously installed KB3159706? If not then you will also need to install WCF HTTP Activation for .Net45 and run wsusutil postinstall /servicing after the KB4025336 has been installed. Both of these steps are documented within KB3159706,
but not in KB4025336. I had similar issues with one of my WSUS servers after installing KB4025336; clients could detect patches and download them, but they were unable to report their status to WSUS. I am not using SSL so the symptoms could be
different on a system with SSL implemented.

Just another observation that may be helpful to someone reading this thread. I also encountered the issue in an environment that I support and uninstalled the update to resolve. However, I had a downstream/replica WSUS server that could no longer
service its clients after I had resolved the issue on the primary.

I tried iisreset and did some research into the errors that I was seeing. Before trying more advanced repairs, I ended up requesting a maintenance period on the machine just to perform a simple REBOOT and that resolved the issue.

So, if you have a bunch of downstream servers that exhibit issues after you fix this botched update on your primary, reboot your downstream servers.

But because it would be difficult to change it on all clients (infrastructure fragmented and not possible to do this via GPO) I had to change it back to 5830:

WSUSutil usecustomwebsite true

And magic: It is still working on the old port 5830! All clients get their updates now.

So it looks like the update broke something with the binding of the IIS Website which could be simply be fixed by switching to the default website and back to the custom website (which is the default by installation under Windows Server 2012 and above).