A recent conversation with a colleague reminded me of an issue I’ve faced a number of times (and forgotten to blog about) when running the Exchange Hybrid Configuration Wizard (HCW) on Exchange 2010 or 2013 in an environment where Web Proxy Autodiscovery Protocol (WPAD) is used.
The Problem
The most common scenario where I’ve seen this come into play is along the lines of this:
- WPAD is used to distribute Proxy.PAC to client machines
- Customer permits direct connection from Exchange servers to Internet
- From an elevated command prompt, run “netsh winhttp reset proxy” to ensure a direct connection
- Change Internet Options settings from “Automatically detect settings” to “Disabled”
- Browse to a site restricted by the proxy to confirm proxy bypass is working
- Can connect to Exchange Online using Remote PowerShell
- Run the HCW but it fails with the following error in the logs:
ERROR : System.Management.Automation.RemoteException: Federation information could not be received from the external organization.
ERROR : Subtask NeedsConfiguration execution failed: Configure Organization Relationship Exchange was unable to communicate with the autodiscover endpoint for your Office 365 tenant. This is typically an outbound http access configuration issue. If you are using a proxy server for outbound communication, verify that Exchange is configured to use it via the “Get-ExchangeServer –InternetWebProxy” cmdlet. Use the “Set-ExchangeServer –InternetWebProxy” cmdlet to configure if needed.
At this point, you’d probably be scratching your head wondering where it’s going wrong. I certainly was. It can be difficult to troubleshoot issues with the HCW as it is over 50 configuration steps all wrapped up in a ‘friendly’ GUI. The first error gives a good indication of where to look: Federation information could not be received from the external organization.
Check whether federation information can be retrieved from Office 365 by running the cmdlet from your Exchange server:
[code language=”powershell”]
Get-FederationInformation –DomainName YourTenant.mail.onmicrosoft.com – BypassAdditionalDomainValidation: $true -Verbose
[/code]
In my case it failed and I found this little gem in the verbose output:
Exception=The remote server returned an error: (407) Proxy Authentication Required
So where is it getting this proxy configuration from? As it turns out, the HCW (and the individual cmdlets) actually run in the user context of the Local System account, rather than the current user. The default configuration for Internet Options is for “Automatically Detect Settings” to be enabled on a per-user basis, which also applies to the Local System account. This default setting combined with WPAD and client’s PAC file is directing the HCW out through the proxy server, which is always going to fail given that Local System is not a credential that the proxy server will validate.
The Workarounds
There are a few ways to address this, although the first two may be harder to implement if it’s a larger organisation:
- Permit the server to use the proxy without authentication
- Modify the PAC file settings being distributed by WPAD
Alternatively it is possible to change the default Internet Options settings within the Local System profile:
- In your own profile, configure the default Internet Option setting from “Automatically Detect Settings” to “Disabled” and export the registry key from HKCU. Import this key into the “Local System” (HKEY_USERS\.DEFAULT) hive. Always remember to back up your registry before making changes.
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections - Use PsExec to launch Internet Explorer as “Local System”, disable the setting and save the changes
psexec.exe -i -s -d “C:\Program Files\Internet Explorer\iexplore.exe”