In this post, I will cover the conditions under which the Intune Management Extension uses a proxy to communicate with the Intune backend service.The Intune Management Extension, also known as IME, is a component that supplements Windows device management and is responsible for managing app deployments and scripts. This agent is installed to Windows devices when an app or script is deployed via Intune. Before discussing the conditions under which IME uses a proxy, it’s important to note that there are some pre-requisites for installing the IME. While I won’t be covering those pre-requisites in this post, there are already great resources available online for learning about them. Once the IME is deployed, it runs as a Windows service:
To perform its assigned operations, the Intune Management Extension (IME) needs to connect with the Intune backend. This connection can go over whatever network path the operating system is using the Default Gateway or a proxy, which can be manually configured or through a PAC file.
When the IME service starts, it uses the WinHTTP Web Proxy-AutoDiscovery service to determine if a proxy should be used. If a proxy is detected, the IME service writes this information into its own proxy configuration registry key, which is used for automatic detection. An example of this value is written under AutoProxy.
In situations where no proxy is detected, both registry keys will exist, but will be empty.
However, despite the simplicity of this configuration, there are instances where the proxy value is present, yet the IME fails to send traffic over it. This raises the question of why this occurs.
After examining IME logs, it is evident that the IME agent bypasses the proxy altogether and performs a direct connection to the Intune backend service through the default gateway, as illustrated below:
<![LOG[Current proxy is https://fef.amsua0202.manage.microsoft.com/TrafficGateway/TrafficRoutingService/SideCar/StatelessSideCarGatewayService/SideCarGatewaySessions('8a6f03c5-059a-423a-a7e8-010730d91be2')%3Fapi-version=1.3]LOG]!><time="14:00:33.3090263" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="27" file="">
<![LOG[Sending network request... isRetryNeeded = False, total retryCount = 1, current iteration = 0]LOG]!><time="14:00:33.3090263" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="27" file="">
<![LOG[[Win32App] Got result with session id 8a6f03c5-059a-423a-a7e8-010730d91be2]LOG]!><time="14:00:33.8089193" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="5" file="">
When analyzing a network trace, it becomes evident that the IME performs two direct connections, through the default gateway, to the Intune backend.
This is interesting because there is no sign of proxy usage at all. Let’s now examine what happens when traffic through the default gateway is used. To replicate this scenario, I created a firewall rule that blocks traffic from being sent to the Intune backend through the default gateway (more on this later). I can see when the direct connection fails, the IME falls back to the proxy configuration.
<![LOG[Current proxy is https://fef.amsua0202.manage.microsoft.com/TrafficGateway/TrafficRoutingService/SideCar/StatelessSideCarGatewayService/SideCarGatewaySessions('0bd5a692-7eb1-4114-94d0-45c50ed58901')%3Fapi-version=1.3]LOG]!><time="17:16:45.6624196" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="31" file="">
<![LOG[Sending network request... isRetryNeeded = False, total retryCount = 1, current iteration = 0]LOG]!><time="17:16:45.6624196" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="31" file="">
<![LOG[[IsWebExceptionRetryable] web exception status = ConnectFailure]LOG]!><time="17:16:45.7094171" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="31" file="">
<![LOG[[ServiceBase] Web Exception occurs when sending network request. It's retryable. Delay= 120 seconds, and the exception is System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions 20.37.153.1:443
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
at Microsoft.Management.Services.IntuneWindowsAgent.AgentCommon.EmsServiceBase.<SendWebRequestInternal>d__17.MoveNext().]LOG]!><time="17:18:45.7099112" date="2-21-2023" component="IntuneManagementExtension" context="" type="3" thread="31" file="">
<![LOG[Raw static proxies = , first static proxy parsed = ; raw auto proxies = proxy1.xeneize.lab:8888, first auto proxy parsed = proxy1.xeneize.lab:8888]LOG]!><time="17:18:45.7099112" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="31" file="">
<![LOG[Loaded the web proxy from registry for current user. userName = DOMAIN_username, auto proxy = proxy1.xeneize.lab:8888, static proxy = ]LOG]!><time="17:18:45.7099112" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="31" file="">
<![LOG[SendWebRequest, client-request-id: ea9b6291-8f81-4949-a4a4-dca2462f71cf, Method: PUT]LOG]!><time="17:18:45.7099112" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="31" file="">
<![LOG[before change proxy, proxy is https://fef.amsua0202.manage.microsoft.com/TrafficGateway/TrafficRoutingService/SideCar/StatelessSideCarGatewayService/SideCarGatewaySessions('0bd5a692-7eb1-4114-94d0-45c50ed58901')%3Fapi-version=1.3]LOG]!><time="17:18:45.7099112" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="31" file="">
<![LOG[retry using web proxy proxy1.xeneize.lab:8888]LOG]!><time="17:18:45.7099112" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="31" file="">
<![LOG[Current proxy is http://proxy1.xeneize.lab:8888/]LOG]!><time="17:18:45.7099112" date="2-21-2023" component="IntuneManagementExtension" context="" type="1" thread="31" file="">
So, yeah, IME always tries to use the Default Gateway first. It doesn’t matter if a proxy is configured. This isn’t a problem for scenarios where traffic through the default gateway is blocked, but it can be painful if the traffic is allowed, but the requirement is that it should go through the proxy.
So, in that scenario, how can we force IME to use the proxy? There are different approaches available here. I’m sharing two of them, but you may have other ways to achieve it. Please leave your comments with other ways to do it, and I will update the article with your suggestions!
Here are mine:
Obviously, the first recommendation would be to block access through the Default Gateway from one of the network devices sitting in the way to reach the internet (for example, a corporate firewall).
If that’s not possible, an alternative is to deploy a Windows Defender firewall policy where access to the IME endpoints is blocked. This could be just a simple firewall rule to block outgoing traffic to the Intune backend. In my case, I am lazy, and I just blocked the traffic to this target: 20.37.153.1, which is the IP address of my endpoint, fef.amsua0202.manage.microsoft.com. Other approaches are totally valid, like including a range in case the IP address changes.
If you choose to use this approach, it’s important to create the rule specifically for the domain profile of your corporate network. This way, the block only applies when the device is connected to the corporate network. It will allow the user to access IME endpoints through the default gateway when they are connected to other networks, such as their home network (using private/public profiles).
Going the extra mile…
- Authenticated proxies are not supported, so make sure to exclude in the proxy the URLs IME uses to avoid authentication issues.
- While multiple proxies are supported as long as the IME agent version is 1.63.102.0 or above, note that the current implementation is to parse out the proxy from the list and only try to make a web call with the first proxy. So, if the first proxy is bad, expect your app/script deployment to fail.
- What is the StaticProxy registry key used for? Its behavior is uncertain. Tests have shown that any proxy value entered works for a short period of time (~20 minutes) before the IME service removes the value from the registry. It is unclear if this is an expected behavior for this key. However, if the device must use the default gateway and only IME traffic needs to be sent via a proxy, this could be achieved through the AutoProxy value using a PAC file.