top of page
  • Writer's pictureWill Francillette

MDE: Windows disconnected environment - decision tree



It has always been challenging to deploy MDE in a disconnected environment i.e. behind a proxy. Thankfully, Microsoft and Brian Baldock have release a series of 3 blog posts on MDE connectivity in a Windows disconnected environment. In additional to that, I thought I would summarize it as a decision tree and share some notes from the field and additional related documentations.


Linux environments are more straight forward and use the traditional options to deploy a proxy (system-wide using the https_proxy variable or application wide by configuring the proxy on all required components)


Content


Decision Tree


  1. Disconnected Environment: Does your machine have direct access to the internet? If yes you do not need a proxy

  2. Live Response: Live Response requires WinHTTP or a direct internet connection.

  3. Server: Workstation will generally use WinInet as they would be managed and receive Windows updates from MECM or Intune. It is configured with internet explorer settings (inetcpl.cpl), Windows setting page or a PAC file.

  4. Offline/Local Windows Update: Do you have WSUS, MECM or a file share to manage your Windows Update? If yes, has this environment been optimised to support the frequent definition updates retrieval such as every 1-4 hours? If the answer is no, then use WinHTTP to retrieve updates from the Windows Update website.

  5. Offline Certificate Management: Do you have an offline solution to manage your Trusted Root CA certificate updates and revocation lists? If no, then use WinHTTP to prevent any TLS issue.

  6. Static Proxy: If the answer is yes to all questions then you can use the application/static/registry proxy.

Notes from the field

  1. Your proxy must NOT inspect SSL/TLS traffic for all MDE URL endpoints except for *.blob.core.windows.net

  2. Your proxy must be configured to bypass authentication for all MDE URL endpoints

  3. Ensure that TLS 1.2 is enabled in your environment.

  4. WinHTTP is configured using:

netsh winhttp set proxy [proxy-server=] ProxyServerName [bypass-list=] <HostsList>

  1. Do not omit to setup your bypass list to prevent any disruption to on-premises workload such as SQL database or web server.

  2. <local> in the bypass list only applies to non FQDN locations such as http://mylocation

  3. <local> does NOT mean that all local locations will not use the proxy. For instance, traffic to http://mylocation.domain.local will indeed be redirected to your proxy.

  4. To bypass proxy in your local environment, use *.domain.com including all your domains separated by a semi-colon for winhttp e.g. "*.domain.com;*.domain.local"

  5. AWS SSM agent does NOT support <local> variable in the bypass when WinHTTP is configured and will lose connectivity with the console. Do Not include it in the bypass list.

  6. Use the client analyser at the beginning of your deployment to identify any connectivity issue.

  7. If you use MECM and add MECM as a definition update source, MECM will overseed any order specified except if MECM retrieval fails:

If Configuration Manager is specified as one of the sources, then the other sources are used only if software updates fail to download the client updates.


Reference


Brian Baldock blog posts

Windows update offline/local solution

Certificate offline solution

Enable TLS 1.2


2,357 views2 comments

2 Comments


Martin Storek
Martin Storek
Sep 20, 2023

Hi Will, Brian stated that Live response works with static proxy only configuration but your desission tree and comment says only WinHTTP works?

Like
Will Francillette
Will Francillette
Sep 24, 2023
Replying to

Hi Martin,

I'll check this again and correct accordingly


Like
bottom of page