In working with a customer, I came across a challenging issue that had me baffled for a while. The customer had a very complex outbound proxy situation in that they had multiple proxies in play as they were very slowly transitioning from one solution to another. They had Windows 7 and Windows 10 devices that we wanted to use Hybrid AAD Join for trust with Azure Conditional Access. Windows 7 worked without issues, but Windows 10 couldn't complete the process.
Because the customer was using an outbound proxy, I made sure that the Windows 10 computer had the correct settings. This was using an automatic script to enable the proxy settings.
I originally assumed this would work as it worked fine with my Windows 7 computer. But, when I ran the join process it failed. I tried manually performing the join process (which needs to run under the computer context) but using PSExec to use a command prompt running as the SYSTEM account.
Note: To launch a command prompt using PSExec as SYSTEM, run the command psexec.exe -i -s cmd.exe.
Using the SYSTEM command prompt, I ran the join using the command dsregcmd.exe /join /debug which provides detailed information about what is actually happening. At the very bottom, you see that there is an error that simply says "Discover failed with error code 0x801c0021."
Performing a ton of searching, there really wasn't any helpful information relating to this error code. So, i reverted to looking at the Event Logs, where I saw several errors for the User Device Registration source including Event IDs 233, 201, 309 and 304. The main one that stood out to me was Event ID 309, which stated "Failed to discover the Azure AD DRS service."
This pointed me back to networking as the computer could discover the DRS URL for registration. My proxy settings were in place, but something that the customer had mentioned to me about their proxy was that any outbound non-HTTPS (meaning HTTP) traffic that bypasses the proxy settings is automatically dropped by their firewalls. I thought this couldn't possibly be the case, but I was wrong...
Recall that my Windows 7 devices registered without any issues and I was only having problems with Windows 10. The main difference between these is the context in which registration occurs. For Windows 7, this occurs under the user-context. For Windows 10, this occurs under the machine-context.
A little snippet from the Microsoft article Tutorial: Configure Hybrid Azure Active Directory Join for Federated Domains caught my eye in regards to outbound proxy. The very last paragraph in the Prerequisites section makes the following statement:
"If your organization requires access to the Internet via an authenticated outbound proxy, you must make sure that your Windows 10 computers can successfully authenticate to the outbound proxy. Because Windows 10 computers run device registration using machine context, it is necessary to configure outbound proxy authentication using machine context."
The customer was not actually using an authenticated outbound proxy, but that did highlight that communications on the computer's behalf are treated differently than communications on the user's behalf.
The proxy settings that you define in the Windows configuration (first screenshot above) and any settings you apply through Edge/Internet Explorer are for the user context only. These proxy settings do not apply to the computer context, and therefore my Windows 10 device was trying communicate without proxy settings. Recall the customer indicated that HTTP traffic bypassing the proxy was automatically dropped.
So doing a little more digging, you can set the machine proxy settings a couple of different ways. You can use Group Policy, but here I simply made a manual change on my test device using a simple command:
netsh winhttp set proxy proxy.com:80 "<local>"
Obviously replace "proxy.com" with the actual IP or DNS name of the proxy and use the correct port. Note that I am setting a direct proxy configuration here where as above my user configuration was done by script. This is because the WinHTTP settings do not support proxy configuration by script, so you have to explicitly define the proxy address.
After adding this setting, the Windows 10 device started using the outbound proxy under the computer context and the DRS service could be discovered. This told me that the discovery does use some HTTP request to initialize the communication which was originally being dropped by the network.
Once the proxy configuration was in place, hybrid join worked for my Windows 10 devices.
After Thought...
Note in my proxy configuration above I included "<local>". This sets an exclusion for the proxy to not apply to internal traffic. I originally did not have this in my WinHTTP proxy settings and because we are using AD FS for authentication, the device registration would fail because it could not obtain a valid token from AD FS. This was because the proxy was doing SSL Bridging, which AD FS does not like. By including the exclusion for local traffic, acquiring the AD FS token communications was not interfered by the proxy.