Microsoft Security Tech Accelerator
Dec 06 2023, 07:00 AM - 12:00 PM (PST)
Microsoft Tech Community
Defender for Endpoint and disconnected environments. Which proxy configuration wins?
Published Feb 21 2023 11:32 AM 10.3K Views

This article is a follow-up to a previous one discussing conflicting proxy configurations and how Microsoft Defender for Endpoint behaves in these situations. The first article can be found in here.


As outlined in the documentation, Defender for Endpoint supports three different types of proxy configurations:

  1. A static proxy configuration pushed through GPO or registry changes,
  2. WinINET proxy through user sessions,
  3. WinHTTP proxy through the SYSTEM account.

However, when these configurations are mixed, it can cause confusion as to which proxy configuration is being used. To understand the path that Defender for Endpoint is taking, it is recommended to use the Client Analyzer script found here.


The setup

In order to test the different configurations, I’ve set up three different proxy servers and a Windows 11 workstation in a lab environment.

  1. WORKSTATION ( – Workstation for tests
  2. PROX01 ( – Receives WinHTTP configured traffic (SYSTEM)
  3. PROX02 ( – Receives WinINET configured traffic (User session, unauthenticated)
  4. PROX03 ( – Receives Static Proxy configured traffic (TelemetryProxyServer)
  5. As it’s unsupported to decrypt Defender for Endpoint traffic we’ll just be looking at which proxy server the endpoint is communicating with to determine the proxy server being chosen.
  6. All traffic for the workstation is blocked at the gateway except for that which uses the proxy servers above.
  7. The Client Analyzer will be executed between each of the tests.
  8. A live response session will be initiated from


Test – Only the WinHTTP Proxy is configured

Enabled outbound traffic via WinHTTP (PROX01) server on WORKSTATION. Test connectivity via a Live Response session and monitored traffic from PROX01 through gateway.

Live Response Session successful:



Validate incoming traffic over PROX01 in gateway:



MDE Client Analyzer Results:



When you’re initially deploying Defender for Endpoint in a disconnected environment, the client analyzer script is the best tool to help diagnose networking issues. As you can see from the screenshot above, the test results are positive. Let’s break them down:



Proxy config: Method=NamedWinHttp, address=

A WinHTTP proxy has been detected on the endpoint and configured with the address listed.

1 - Default proxy: Succeeded (200)

If at least one of the connectivity options returns status (200), then Defender for Endpoint sensor can properly communicate with the tested URL using this connectivity method.

2 - Proxy auto discovery (WPAD): Succeeded (200)

Same result as above

3 - Proxy disabled: Failed (12002: WinHttpSendRequest: 12002: The operation timed out)

The proxy is not disabled.

4 - Named proxy: Doesn't exist

The static proxy is not configured

5 - Command line proxy: Doesn't exist

Not configured


Test – Which one wins? WinINET or WinHTTP?

Now that we’ve confirmed we have an internet connection via WinHTTP proxy settings let’s add a separate WinINET configuration into the mix for our user account and see which proxy Defender for Endpoint will prefer for communication. We’ll leave our user logged in for this test.


We can see that Defender for Endpoint still prefers the WinHTTP proxy over the WinINET:



Our Live Response session initializes correctly and goes through the WinHTTP proxy connection. When we have both a WinHTTP and WinINET configuration it appears that the WinHTTP proxy takes precedence for Defender for Endpoint connections. This makes sense as the service is running as the SYSTEM account.


Test – WinINET proxy configuration only

As outlined in the article here, a WinINET proxy configuration without a logged an active user session will not allow Defender for Endpoint to connect. It will instead cache and upload signals once a when a user logs in and establishes a proxy connection via WinINET.


The following is a test of a live response session on the workstation while no user is logged in and monitoring traffic. The result is that no traffic from Defender for Endpoint is detected and the Live Response session times out as expected:



We can also confirm there is no communication by checking the timeline. The user was logged out at 11:50am as demonstrated below.




Once a user has logged in, we can validate the timeline and see that events start to get uploaded through the proxy as the cache is emptied.



Often in disconnected environments we’ll see a WinINET proxy for user session activities and a static proxy for specific services.


In this situation the only proxy currently configured on the computer is WinINET. Most of the Defender for Endpoint functionalities will be available. Live Response is the only one that will not work with the standalone WinINET configuration.


You’ll see a session timeout. However, when combined with a Static Proxy configuration (via GPO or Registry) all the services will work appropriately even when a user is not logged in. The specific proxy can be used for Defender for Endpoint services and no change is required on the user experience.


Live Response session timeout over WinINET:



You can see from the client analyzer results below that only some of the URL endpoints are reachable over a “WinINET only” proxy configuration:



In this case, we won’t get the complete experience out of Defender for Endpoint as only the SampleUpload and MdeConfigMgr service URLs are reachable.


Test – Static proxy configuration only

As you can imagine, this scenario will work fine for the workstation and Defender for Endpoint configuration/communications. As this is a static proxy assigned to both the Telemetry service (for Endpoint Detection & Response) and the Defender for Endpoint anti-virus, no other internet access will be available for the workstation. This is a great setup scenario for disconnected environments or servers as the users connecting to these endpoints should not have or do not require internet access.

After applying the static proxy settings and rebooting the workstation we can already start seeing inbound traffic on PROX03:



Live Response is functional as well:




The Defender for Endpoint configuration works as expected. Again this is a good use case in a scenario where nothing else on the machine has internet access, that includes Windows Update.


Test – WinINET, WinHTTP and Static Proxy configuration. Which one wins?

Let’s have some fun. Now we’ll configure the static proxy, the WinHTTP proxy, and the WinINET proxy and observe the traffic flow through the gateway to understand which proxy configuration will be preferred.


We can see that the Live Response session that’s initialized still uses the Static Proxy (to be expected):



User based services primarily using the WinINET proxy configuration:



And all other SYSTEM level services utilize the WinHTTP configuration:



Let’s look at the Client Analyzer results:




Ultimately, if you are looking for good user experience on a workstation in a disconnected environment and to provide full feature availability to your Security Operations Center (SOC) team, using a combination of WinINET and Static Proxy will offer the most feature-rich experience without impacting existing configurations in your environment. Hopefully, the tests above will help you gain a better understanding of what to expect from Microsoft Defender for Endpoint, given your configuration.



Disconnected environments, proxies and Microsoft Defender for Endpoint

Incident response at your fingertips with Microsoft Defender ATP live response - Microsoft Community...

Download the Microsoft Defender for Endpoint client analyzer | Microsoft Learn


Great article! Thanks for sharing this knowledge.

Copper Contributor

small remark, Microsoft Defender Antivirus will not use the static proxy to connect to Windows Update or Microsoft Update for downloading updates. Instead, it will use a system-wide proxy if configured to use Windows Update. 


It can be manually be set with Set-MpPreference ProxyServer.


@Kristof82, thanks for the comment. That makes sense as it's dependent on the definition of additional configurations on Defender Antivirus: Manage how and where Microsoft Defender Antivirus receives updates | Microsoft Learn



Great Article!


Very useful content! Thanks for putting it out, Brian! 


Brass Contributor

Great article. Does anyone have experience with DeviceIsolation for Devices behind a proxy? 

Iron Contributor

If you have a WinHTTP proxy configured via NetSh (proxy A) , and also have WPAD in place (proxy B), which one does MDE then use?

Brass Contributor

@PJR_CDF To be 100% sure run the MDEClientAnalyzer-Script. This one will give you the answer for your environment. 

Iron Contributor

@aexlz the mdeclientanalyzer.txt file just shows the success or failure status for various methods - if multiple methods are in use ie NamedProxy and WPAD, I see both succeed (200).


It doesnt tell me which is preferred.


I dont believe the Test/Results order in the txt file is indicative of the proxy priority of MDE?



Brass Contributor

@PJR_CDF It does in the very first line:


Proxy config: Method=AutoDetectWPAD,



Iron Contributor

@aexlz - I tested last week and configured my test device to use accidentally use a static proxy it couldnt reach (blocked by firewall). The report showed that static proxy as the proxy method (as you have shown above) but that all the URLs were reachable which wasnt technically possible in my case.


I reviewed the static proxy log and couldnt see the traffic and realised it was blocked by the firewall so was confused as to why the report showed successful connections.?


When I reviewed the clientanalyzer.txt file I could see the URLs were reachable via WPAD proxy (which was reachable) and the tests using my static proxy failed, yet in the HTML report the static proxy was listed as the configured proxy and the results showed all URLs as accessible?


From my testing the report seems to show what's configured as the proxy config method but that the URL results in the section below are not necessarily the results of using that method. Instead, the results reflect the results of testing whether the URLs can be reached by any of the possible methods (Default Proxy, Named Proxy, WPAD , Command Line Proxy etc).

Version history
Last update:
‎Feb 21 2023 11:32 AM
Updated by: