Intune Management Extension Proxy Problems

Intune Management Extension doesn't really like proxies in general. It also doesn't like to talk to a proxy as detailed the below fine artice by Martin Kirtchayan.

By the looks of it, it detects the logged on user's proxy, stores it in the registry, but if you also have a system context proxy set, you naturally would expect IME to use the system context proxy.

I am sharing here my findings based on Martin's article, and some further troubleshooting that finally brought success, but I don't yet know what other implications these changes might have, so consider this a warning and also do please comment if I seem to be breaking my setup with the tampering I am about to showcase below.

Proxy settings in Windows

Seems that there are a couple of way to set proxy for different 'use cases' within Windows itself. User context proxy can be set with either an environment variable or with a .pac file, or in the internet options panel.

Regarding system-wide settings, after extensive googling every article I found pointed me to netsh command to set a system-wide proxy. So that is what I used.

netsh winhttp show proxy indeed returns the server, port and the local exceptions that I would expect to be used.

So far so good. Yet when opening IME logs, along with analyzing traffic with WireShark, I can clearly see communication directly to the default gateway and the DNS server returned by ipconfig /all just as Martin described.

TcpView shows no direct communication from IME itself. It seems that IME relies on WinHTTP Web Proxy Auto-Discovery Service.

IME runs as Local System. The WinHTTP service runs as Local Service.

Some more search returned a few articles referencing another utility that can specifically set proxy for such services. Namely, LOCALSYSTEM, LOCALSERVICE and NETWORKSERVICE. This is the bitsadmin utility. Querying the settings for LOCALSYSTEM:

C:\>bitsadmin /util /getieproxy localsystem

BITSADMIN version 3.0
BITS administration utility.
(C) Copyright Microsoft Corp.

Current Internet proxy settings for account localsystem:
(connection = default)

Proxy usage:  AUTODETECT

C:\>

Ok, so when anything running as LOCALSYSTEM wants to access the network - it should automatically detect whatever is set in the system context settings. This would be the expected behavior, however, IME still ignores the proxy.

I forced LOCALSYSTEM, LOCALSERVICE and NETWORKSERVICE to use explicit settings. I stopped the IME service, deleted the logs, also removed all the subkeys under \HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Proxies as well as deleted c:\windows\temp files, as IME notoriously caches here a txt file that contains the user proxy settings, and it quickly picks that up instead of re-discovering it after a restart.

I ran the above 3 times replacing the account for each run.

Opened IME log with cmtrace and started the IME service. It started to work! It also used the proxy just fine. It still detected user context settings, so the Proxies registry path was re-populated, but it seems to be cosmetics.

You might have different network routing based on your users' whereabouts.

On the office network
On a remote office network
On public/home Wi-Fi with VPN on
On public/home Wi-Fi without VPN

One this is certain: when the devices are either co-managed or cloud-native, you need to make sure that IME can talk to the Intune Backend, otherwise you will run into updates not being delivered, Company Portal failing to install apps, configuration profiles being not applied, etc.

In any case, this was just a quick test and, I hope this sheds some light on the IME v.s Proxy problem in general. Let me know your thoughts.

Useful links

The official Intune network requirements

There is a fresh post from Maurice and Bruce here on some more considerations around Delivery Optimization, which again, needs certain white listing to be applied