As I discussed previously, proxy servers are a pain.  I wish they could be wiped from the face of the earth.  But since that’s about as likely as everyone being off of Windows 7 by January 14, 2020 (didn’t you people learn from Windows XP?), we have to deal with them.

If you are setting up for doing Windows Autopilot user-driven Hybrid Azure AD Join deployments, you know that you need to install the Intune Connector for Active Directory (I’ll call it the ODJ Connector for short), as it’s responsible for creating the AD computer objects for each computer that is being deployed.  The installation instructions include a link to a Work with existing on-premises proxy servers, but for some reason that article talks about “bypassing outbound proxies” using the installed .config files for the .NET executables that are installed by the ODJ Connector.  I guess at some point we worked with a customer that couldn’t exempt their proxy configuration from user authentication, so they just wanted to poke a hole in the firewall for that one server instead.  Interesting, but probably not what you’re looking for.

But it does at least provide some clues as to what is possible.  The .NET Framework supports a declarative mechanism for all .NET executables to specify whatever proxy settings you care to configure.  All of those are described in the Proxy configuration documentation.

Of course another customer asked for more details on how to do this.  Rather than pointing them at some reference docs, I knew what they were trying to do, so I tried it out (a fun Memorial Day weekend activity).  Of course to try it out I needed an actual proxy server.  (I miss Microsoft Proxy Server.)  I initially tried the open-source Squid proxy and decided that I really don’t like it (hence my comments about proxies that do SSL inspection in my previous blog post).  So I switched to one that’s much easier to use, WinGate.  It’s free for up to 10 users, and in my test environment I only have one (me) so that works well.  So I disconnected my test environment, set up a new Windows Server 2019 VM, connected it to my test environment and the internet, and then installed WinGate to proxy between those two networks.  It worked well with Microsoft Edge, so the next task was to get it to work with the ODJ Connector.

Going back to the previous Intune documentation, it points to two different configuration files:

• C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorSvc\ODJConnectorSvc.exe.config.  This is used by the ODJ Connector.  It’s fairly likely that you’ll have to edit this one (unless you are using WPAD), as I couldn’t find any other way (e.g. winhttp) to make this work, and since this service runs as LocalSystem, it doesn’t discover the browser proxy.
• C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorUI\ODJConnectorUI.exe.config.  This is used by the wizard that sets up the ODJ Connector.  It has a better chance of discovering the proxy from the browser, so you might not need to edit this one.  But it certainly won’t hurt either.

In both cases, the edits that need to be made to the .config files are the same.  At the top of the file you’ll see these two lines:

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>

Right below those lines, you can add the needed proxy configuration.  In my case, the proxy server was named “contoso-proxy” and it was listening on port 3128.  So I needed these additional lines:

  <system.net>
<defaultProxy>
<proxy usesystemdefault=”false” proxyaddress=”http://contoso-proxy:3128&#8243; />
</defaultProxy>
</system.net>

Put in the name and port of your proxy server in place of mine above, save the file, and you should be set.  (Restart the ODJ Connector service if it was running.)  To troubleshoot, you can check the proxy server logs (did it get there) and the ODJ Connector event log (did it log any communication errors).  (See this blog post for more troubleshooting suggestions.)

One of these days I’ll get around to fixing the Intune doc…