Changes to improve security for Windows devices scanning WSUS

Published Sep 08 2020 11:44 AM 72.7K Views

With the September 2020 cumulative update for Windows 10, we introduced changes that help improve the security of devices that scan Windows Server Update Services (WSUS) for their updates. This post will describe those changes, outline the actions you need to take to ensure your devices continue to scan for updates, and offer basic recommendations to help you better secure the devices in you organization.

Secure by default

First, beginning with the September 2020 cumulative update, HTTP-based intranet servers will be secure by default. To ensure that your devices remain inherently secure, we are no longer allowing HTTP-based intranet servers to leverage user proxy by default to detect updates. If you have a WSUS environment not secured with TLS protocol/HTTPS and a device requires a proxy in order to successfully connect to intranet WSUS Servers—and that proxy is only configured for users (not devices)—then your software update scans against WSUS will start to fail after your device successfully takes the September 2020 cumulative update.

Recommendations for greater security

To help ensure the security of your WSUS infrastructure, Microsoft recommends using the TLS/SSL protocol between your devices and your WSUS servers. The Microsoft Update system (including WSUS) relies on two types of content: update payloads and update metadata. Update payloads are the data files that contain the software update components that make up the update. Update metadata is all the information that the Microsoft Update system needs to know about the updates, including which updates are available, which devices each update can be applied to, and where to retrieve the payloads for each update. Both types of content are crucial and they both need to be protected to help keep your computers secure and up to date.

Update payloads are protected against modification by multiple means, including digital signature checks and cryptographic hash verifications. HTTPS provides a proper chain of custody which the client uses to prove the data is trusted.

When a device receives updates directly from Microsoft Update, that device receives update metadata directly from Microsoft servers. This metadata is always transmitted via HTTPS to prevent tampering. When you use WSUS or Configuration Manager to manage your organization's updates, the update metadata travels from Microsoft servers to your devices via a chain of connections. Each one of these connections needs to be protected against malicious attacks.

Your WSUS server connects with Windows Update servers and receives update metadata. This connection always uses HTTPS, and the HTTPS security features guard the metadata against tampering. If you have multiple WSUS servers arranged in a hierarchy, the downstream servers receive metadata from the upstream servers. Here, you have a choice: you can use HTTP or HTTPS for these metadata connections. Using HTTP; however, can be very dangerous as it breaks the chain of trust and can leave you vulnerable to attack. Using HTTPS enables the WSUS server to prove that it trusts the metadata it receives from the upstream WSUS server.

In order to maintain the chain of trust and prevent attacks on your client computers, you must ensure that all metadata connections within your organizations – the connections between upstream and downstream WSUS servers, and the connections between the WSUS servers and your client computers – are defended against attacks. To do so, we highly recommend that you configure your WSUS network to protect these connections using HTTPS. To learn more, see Michael Cureton’s post Security best practices for Windows Server Update Services (WSUS).

Even with HTTPS configured, it is still very important that you utilize a system-based proxy rather than a user-based proxy if a proxy is needed. When using a user-based proxy, a user, even one without elevated privileges, could intercept and manipulate the data being exchanged between the update client and the update server.

Recommendations for those who absolutely need user proxy

If you do need to leverage a user-based proxy to detect updates while using an HTTP-based intranet server, despite the vulnerabilities it presents, make sure to configure the proxy behavior to "Allow user proxy to be used as a fallback if detection using system proxy fails."

Group Policy path: Windows Components>Windows Update>Specify intranet Microsoft update service location

Configuration Service Provider path: Update/ SetProxyBehaviorForUpdateDetection


Next steps

If you are an IT administrator who currently manages an HTTP-configured WSUS environment and relies on user-based proxy for client scans, please consider taking one of the following actions as soon as possible. If none of these actions are taken your devices will stop successfully scanning for software updates after the September 2020 security update.

Options to ensure that devices in your environment can continue to successfully scan for updates:

  • Secure your WSUS environment with TLS/SSL protocol (configure servers with HTTPS).
  • Set up system-based proxy for detecting updates if needed.
  • Enable the “Allow user proxy to be used as a fallback if detection using system proxy fails” policy.



Frequent Contributor

Thanks @Aria Carley great write up.

What's the minimum ADMX / OS build level needed for this setting to exist / work?



Senior Member

Oh, another lovely post about about securing WSUS traffic with TLS. And, as always, we have this:

When you use WSUS or Configuration Manager to manage your organization's updates, the update metadata travels from Microsoft servers to your devices via a chain of connections. Each one of these connections needs to be protected against malicious attacks.

And as always, here I am, asking you these question: What malicious attacks? From where do they originate? What is their attack vector? What's your threat model? And – to quote Microsoft's engineer Raymond Chen – does it not involve being on the other side of the airtight hatchway?


Frequent Visitor

The “Allow user proxy to be used as a fallback if detection using system proxy fails” policy does not exist in 1909 or 2004 ADMX's or am i wrong?


How can this be configured as a Registry key only?

Occasional Visitor

Hey Aria,


Can you provide some more details regarding the policy-setting? As stated by Richard, this doesn't seem to be included within the ADMX's.


Additionally, the GPO being referred to is one also being managed through Configuration/EndPoint Manager.. Setting the GPO 'll cause 2 management systems in trying to define the setting on the managed workstation/device.


Last but not least: The link provided ( does not refer to any sub-section "Update/ SetProxyBehaviorForUpdateDetection

Can you provide an updated location, that includes the "SetProxyBehaviourForUpdateDetection"?




Occasional Contributor

@Aria Carley There seems to be some confusion about exact what a user proxy is versus a system/device proxy.  Which is to say: people don't clearly know if they are impacted by this or not.  I read 'user proxy' as one defined in 'Internet Options' either by the user themselves or via Group Policy and 'system' proxy as one configured using 'netsh winhttp' commands. 

If an organization legitimately needs a proxy to reach their WSUS server how do they configure (or verify that they are using) a system proxy?

Occasional Contributor

I am not sure if this affects me as we have SCCM server (wsus incorporated) and our clients use proxy app to allow internet out?

is there a better way to make sure?

@K_Wester-Ebbinghaus this policy will be available on Windows 7+ (including Vista and all versions of Windows 10) once devices take the September security update. Note, without taking the security update released on the 8th of September, you will not be able to leverage this policy. 



@RichardSheath this policy should appear in the group policy ADMX file once the September security update is taken. It is typically not recommended to set the registry key directly, given that it could then be easily overwritten if the policy is set (either locally or by a management tool).



@bdam55 The key difference when we are taking about user, system proxy is that a user proxy can be configured per logged on user (and hence modified by a non-admin), whereas a system proxy is configured for the entire machine (can’t be modified by a low privileged user). The online Microsoft docs, as well as external sources, can provide more information on both types of proxies

You can configure system proxy using netsh command-line utility from an elevated cmd.
- Check if system proxy is already set: netsh winhttp show proxy
- Set a new system proxy: netsh winhttp set proxy <proxy:port>


@Dolinhas that would depend on what your proxy app is doing. That said, you can determine if there is a system proxy already in place by using the netsh command-line utility as an administrator and running netsh winhttp show proxy. I hope this helps! 

Occasional Contributor

@Aria Carley Thanks for the clarification although it sort of confirms the confusion.  I've been told the opposite by a MS PFE whom I know and have reason to trust: that this is about how the proxy authenticates, not the mechanism by which it is configured.  And yet your description is the one that makes sense to me.  The exploit is that a user-space proxy can be altered by a non-privileged user and thus spoofed ... how that proxy authenticates is irrelevant. 

I looked for official docs on system vs user proxies and didn't come up with anything other than 'how to configure a proxy with GPO' and the like.  So if you have docs handy to help clarify that'd be great.

In short, I don't think the terms 'system proxy' or 'user proxy' have any universally agreed upon definition and it would be wise to further clarify how you are using those terms in the post. I'm seeing wide amounts of confusion surrounding how to know if your org is going to be impacted or not.  There's both an incredible amount of organizations using non-HTTPS WSUS (it's always been the default) and using proxies (almost universal in large orgs).

Frequent Visitor

@Aria Carley Thanks for the response but I'm not sure you are correct with regards to the policy info.


Yes you are correct in that the setting only appears after the update is applied , but it is a local policy and not controlled by GPO so how can an ADMX file be modified by a client side patch being installed when these files reside on a Domain Controller?


Surely to take advantage of this setting we'd need an updated ADMX pack with the modified Windows Update.admx?

Frequent Contributor

The ADMX for 2004 have been updated again on the downloads page check if is is contained @RichardSheath 


@RichardSheath Sorry, to clarify: the local group policy files will be updated once you take the September patch. From there you can copy the updated ADMX/L files to your central store and use them to set the policy on your organization's devices. You are correct that the online files will not be automatically updated. 


@N3rdy77  The local ADMX will update with the new policy once the September patch is taken. You should then be able to grab the ADMX/L files from such a device. As for your second point, I fully understand your concern. ConfigMgr is currently unable to manage the new proxy behavior setting. So in the case of managed environments where user proxy is needed, for the short term, you will need to set the desired proxy behavior via the registry directly. We hope to make this a more seamless process in future.


- Value 0 – Only use system proxy
- Value 1 – Allow user proxy as fallback…


@RichardSheath as you asked for the Regkey as well. 

Occasional Visitor

@Aria Carley Tnx for the info ;) 

The worries are a bit smaller now. Now let's see whether the "fail-fast"-principle is needed or not :D


Occasional Visitor

Signing binaries only is not enough is halfway protection. Update metadata should be signed by Microsoft as well. SSL/TLS protection can be easily bypassed by any intermediate rogue WSU that uses legitimate SSL/TLS certificates (e.g. from StartSSL). As it is now, any Windows client can be fooled to run legitimate MS-signed binaries with rogue command line parameters. As it is now WSUS seems like a trojan horse, and can be used to hijack in a massive way all of its clients through their update channel.

Occasional Visitor
Senior Member

@Aria Carley 






FYI, the change affects not only Windows 10, but also Windows 8.1, Windows 8/8.1 Embedded, Windows Server 2012, and Windows Server 2012 R2. The following are links to related Sept 2020 update articles, and an excerpt from them:


September 8, 2020—KB4577038 (Monthly Rollup) -- Windows Server 2012 & Windows Embedded 8 Standard


September 8, 2020—KB4577066 (Monthly Rollup) -- Windows 8.1, Windows Server 2012 R2 & Windows Embedded 8.1


Addresses a security vulnerability issue with user proxies and HTTP-based intranet servers. After you install this update, HTTP-based intranet servers cannot leverage a user proxy to detect updates by default. Scans that use these servers will fail if the clients do not have a configured system proxy. If you must leverage a user proxy, you must configure the behavior by using the Windows Update policy “Allow user proxy to be used as a fallback if detection using system proxy fails.” This change does not affect customers who secure their Windows Server Update Services (WSUS) servers that use the Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocols. For more information, see Improving security for devices receiving updates via WSUS.

Occasional Visitor

Por el momento no tengo problemas, solo un poco lento el inicio

Occasional Visitor


Occasional Visitor

Post installing September patches , SUP component in SCCM Stopped working. i am getting below error continue in  WSUScontrol.log is this something related to this, 

i am not using ssl in WSUS its HTTP 

System.InvalidOperationException: Client found response content type of 'text/html; charset=utf-8', but expected 'text/xml'.~~The request failed with the error message:~~--~~<!DOCTYPE html>~~<html>~~ <head>~~ <title>Compilation Error</title>~~ <meta name="viewport" content="width=device-width" />~~ <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:"Consolas","Lucida Console",Monospace;font-size:11pt;margin:0;padding:0.5em;line-height:14pt}~~ .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:pointer; }~~ @media screen and (max-width: 639px) {~~ pre { width: 440px; overflow: auto; white-space: pre-wrap; word-wrap: break-word; }~~ }~~ @media screen and (max-width: 479px) {~~ pre { width: 280px; }~~ }~~ </style>~~ </head>~~~~ <body bgcolor="white">~~~~ <span><H1>Server Error in '/ApiRemoting30' Application.<hr width=100% size=1 color=silver></H1>~~~~ <h2> <i>Compilation Error</i> </h2></span>~~~~ <font face="Arial, Helvetica, Geneva, SunSans-Regular, sans-serif ">~~~~ <b> Description: </b>An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.~~ <br><br>~~~~ <b> Compiler Error Message: </b>CS0016: Could not write to output file 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\apiremoting30\5e299e68\3118677a\App_global.asax.vcv9wuo1.dll' -- 'Access is denied. '<br><br>~~<b>Source Error:</b><br><br>~~ <table width=100% bgcolor="#ffffcc">~~ <tr><td>~~ </td></tr>~~ <tr>~~ <td>~~ <code><pre>~~~~[No relevant source lines]</pre></code>~~~~ </td>~~ </tr>~~ </table>~~~~ <br>~~~~ <b>Source File:</b> ~~    <b>Line:</b> 0~~ <br><br>~~<br><div class="expandable" onclick="OnToggleTOCLevel1('compilerOutputDiv')">Show Detailed Compiler Output:</div>~~<div id="compilerOutputDiv" style="display: none;">~~ <br> <table width=100% bgcolor="#ffffcc">~~ <tr>~~ <td>~~ <code><pre>c:\windows\system32\inetsrv> "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /t:library /utf8output /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.DynamicData\v4.0_4.0.0.0__31bf3856ad364e35\System.Web.DynamicData.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel.Activities\v4.0_4.0.0.0__31bf3856ad364e35\System.ServiceModel.Activities.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel.Web\v4.0_4.0.0.0__31bf3856ad364e35\System.ServiceModel.Web.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Drawing\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.IdentityModel\v4.0_4.0.0.0__b77a5c561934e089\System.IdentityModel.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_64\System.Web\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Activities\v4.0_4.0.0.0__31bf3856ad364e35\System.Activities.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.Services\v4.0_4.0 SMS_WSUS_CONTROL_MANAGER 10/3/2020 10:14:59 AM 6500 (0x1964)
Failed to set WSUS Local Configuration. Will retry configuration in 1 minutes SMS_WSUS_CONTROL_MANAGER 10/3/2020 10:14:59 AM 6500 (0x1964)

Occasional Visitor

Since we started patching by September 2020 patches some servers with Windows 2016 "autodiscovered" (obsolete) Proxy by DNS entry and attempt connect to instead of internal WSUS over http.

As workaround (looks like working) restart on client wuauserv few times until connection to Proxy is not opened.

Occasional Visitor

Hi Aria,

Since 2020-09 update KB4570333 is deploy, we have many W10 devices in SCCM Software Updates report with "Scan failed with error = 0x80244019" in file log SCCM  wuahandler.log ... and with "*FAILED* [80244019] Web service call" in windowsupdate.log local file.

All devices have a proxy .pac file configured in IE settings and some devices also have o proxy system level with a "netsh winhttp set ..." command (with no bypass list).


For the moment we want to keep using HTTP with WSUS server (installed on SCCM primary site).

Setting manually on a W10 device the option to use "Allow Proxy user..." with GPETID.msc or setting the key "SetProxyBehaviorForUpdateDetection" to "1" dont't resolve the error. 

Any idea please ?



@NagayyaP  and @LuisO78  please file a bug with logs in Feedback Hub, contact your support / account manager, or if not possible directly message me. 





with up-to-date ADMX on central store, still cant find the new (important!!) options under the policy of "Specify intranet Microsoft update service location"

its just not there ...

looks like a real scandal!

The updates were released in the ninth month! we are nearing the end of the tenth.

and the latest ADMX package does not include the all-important add-on presented in this article.

(Administrative Templates (.admx) for Windows 10 May 2020 Update. MSI)


what the hell?

or what am I missing here ??





Hello @jobab2455, are you using the latest 20H2 GP ADMX file ( 




@Aria Carley 

many thanks. 20H2 Package include this! 


i have to ask, this limit will effect my endpoints if im using proxy based on PAC File, but only for WAN traffic ?

intranet traffic is bypassed proxy.


@jobab2455 glad to help! :)


PAC file is just a configuration, so if the WinInet (user) proxy config is using PAC files then the same rules apply. We do not use PAC file from user proxy by-default for HTTP scans against WSUS. 
Senior Member


I was able to deploy all October patches without any SSL configured. How is that possible? Is something has changed later?


@RSA111 You are certainly able to still deploy patches without any SSL configured. The only devices we are blocking are devices who have not configured an SSL, are leveraging user proxy, and have not utilized the policy to allow user proxy. Assuming your devices leverage no proxy or system proxy then you can continue scanning without SSL configured with no problems. 

Frequent Contributor

Hi @Aria Carley I hope this is ok to be posted here. There are at least 2 uservoices stating that it is becoming a big issue for users that 1903 / 1909 / 2004 / 2004 (and soon 20H1) so basically all that allow a enablement package show the same version in WSUS

this is not helpful for reporting it is not like this cannot be fixed.

Add build number to WSUS – Windows Server (


Why I know this and this is not a "by design" issue: AJtek WAM script from AdamJ does fix this by altering the database string based on the OS build.

I really hope, that you can convince the team to update WSUS database.

Frequent Contributor

@K_Wester-Ebbinghaus Thanks for reporting! Looking into it now. Would recommend for faster attention that people leverage support or their account teams rather than just submitting to user voice in the case of a bug/issue that would block a deployment for them. That said, we will look into this. :)

Senior Member

WSUS needs to able to import patches without having to go and enable TLS 1.0. Pretty big oversight in my opinion.

Frequent Contributor

@SAPacker I am not sure if this is still the case, has been a while since I have tested it. But next Patchday for customers will come and there are new updates to import (of Importance) e.g. Intel Microcode. While one can import Updates while using a WSUS MMC on a remote computer, it still demands to set the default browser to IE (temporarily please). 

Please try this. Set your default browser to IE, WSUS MMC > Import Updates 

Can you please check if the TLS settings in IE (internet options are set to disable TLS 1.0 / TLS 1.1, not yet the default and only enable TLS 1.2) thanks for reporting back if this works for you. 


If you like, you can also use PowerShell. here is a german blogpost from Wolfgang Sommergut, a very good expert. The new Edge Browser should help you to translate this live from german into your language.


Senior Member

@SAPacker"Big oversight" is an apt designation. Why would WSUS need HTTPS in the first place when its updates are exposed over SMB anyway? I've asked several questions about the use cases of HTTPS for which I am yet to receive an answer. (See above.)

Occasional Contributor

@The_Smart_One: True but that's because WUA doesn't trust the update binaries it downloads over SMB.  It verifies their digital signature and their hash using the info from the metadata.  Which is why you want HTTPS: to make sure the metadata that you verify the content with isn't itself tampered with.

Occasional Contributor

@Aria Carley Hi! I don't know if this is the right channel. But a lot of people are facing problems when searching for updates using WSUS on Windows Server 2008 / 2008 R2, SSL enabled or not.

We are getting 404 errors.

Have tried everything and nothing seems to work.

Is there an official statement from Microsoft saying that those servers will not synch WSUS anymore?

Frequent Contributor

@Vandrey Trindade are you sure to have


- installed the latest Service Stack updates on the old servers?

- have year 1 and year 2 ESU keys installed and activated, best effort with VAMT 3. You will get the latest VAMT in the ADK 2004


Please read the comments

Despite my PR on this doc it is not yet public. Replace 1903 with 2004 ADK


Senior Member


WUA doesn't trust the update binaries it downloads over SMB

WUA doesn't use SMB at all. (I wonder why.) And not trusting SMB is extremely foolish to begin with, since its version 3 is more secure than HTTPS.


Which is why you want HTTPS: to make sure the metadata that you verify the content with isn't itself tampered with.

Tampered in my intranet? By whom? And how? How comes the transport-layer security didn't stop them but HTTPS can? What's your threat model? And – to quote Microsoft's engineer Raymond Chen – does it not involve being on the other side of the airtight hatchway?


And please cite your sources if you decide to answer.

Occasional Contributor


Hi, thanks for replying!

It was a problem that affected a lot of people:

WSUS Sync failure - Microsoft Q&A


But it seems that Microsoft fixed it, because it is working now.

@Aria Carley no need to check anymore!

Thanks once again to everyone!


@SAPacker  Sorry for the delayed response. Our services using TLS 1.0 is no longer permitted per Microsoft policy (nothing to do with the above). Anything below TLS 1.2 poses a security risk to client machines, which is why it is no longer permitted. 


That said, a client machine or WSUS server connecting to server sync, may be configured to use TLS 1.0 but our (Microsoft's) services should be requiring TLS1.2. If the client machine does not support TLS1.2 then the connection should fail. In no way should a client machine be required to use TLS 1.2. Note, if you are referring to clients talking to your WSUS server, it is totally up to the admin to decide if the server supports 1.2, 1.1, 1.0 or whatever.


If you have found this to not be the case it is likely a service config problem and I ask you to report it.  :) 

Occasional Visitor

Dépannage récent One Drive par assistance obtenu fortuitement après vaines tentatives de résolution de ce problème spécifique pourtant prévu ayant apparemment pour origine une compatibilité de navigateur (dont le changement n'avait rien apporté) et dont le rapport avec Java Script demeurait inexpliqué depuis quelques années alors que les données restaurées sont désormais accessibles grâce à la persévérance d'écoute de patients assistants Microsoft.

Senior Member

Hi guys looks the issue is still.. the powershell method works good, but not sure everyone PowerShell no how out there. Here are some references of what I was referring to and have experienced myself. I have since upgraded to a newer version Windows sever.

Managing WSUS: TLSv1.0 needed to import from the Windows Update Catalogue (


Does WSUS on Windows Server 2012 R2 requires TLS 1.0 enabled (


Again is just importing patches. Case in point this months printer issues required importing in WSUS for mass patching.


Guess at the end of day 2012 R2 is sunsetting 


Version history
Last update:
‎Sep 08 2020 04:16 PM
Updated by: