Most of the time when we configure hybrid mode, the CAS servers have unrestricted access to the Internet. However, not all organizations allow this. I recently ran into a couple of proxy configuration issues when setting up hybrid mode for a client.
The first errors we got were during the setup of hybrid mode creating the federation trust. However, we would have had ongoing issues because the CAS servers in the on-premises Exchange installation need to communicate with O365 servers to perform tasks such as free busy lookups. I had been assuming the CAS servers had direct Internet access but forgot to confirm with the client.
When creating the federation trust initially we ran into the following:
Unable to access the Federation Metadata document from the federation partner. Detailed information: "Unable to connect to the remote server."
The good news is that error instantly makes you think network connectivity. This error is generated when the the CAS server cannot communicate with the following URL:
- https://nexus.microsoftonline-p.com/FederationMetadata/2006-12/FederationMetadata.xml
In this case the client uses a proxy server for all outbound http/https traffic. Exchange server will not use the proxy configured in Internet Explorer/Windows. Instead you need to manually configure the proxy server used by Exchange server with the following cmdlet:
Set-ExchangeServer -Identity CASServer -InternetWebProxy:http://proxy:port
After setting the proxy for Exchange Server, we got an error:
(407) Proxy Authentication Required
At this point, there really is nothing we can do because there is no way for Exchange Server to provide authentication to the proxy server. So, we worked with the network team to modify the proxy configuration to not require authentication for the CAS servers. They configured those exceptions based on the IP address of the CAS servers.
For this particular organization, the other alternative would be allowing the CAS servers to communicate directly out, but only to the specific servers required. Microsoft provides a list of Exchange Online and Federation Proxy server IP Addresses to restrict outbound communication if required, but this is a large list and there is the possibility of change over time. This blog post has the links to the IP addresses:
Based on my research, another issue that can occur related to proxy settings is the use of WPAD (Web Proxy Autodiscovery Protocol). Apparently Exchange Server will use this if it's available, even if you have manually set the the proxy with Set-ExchangeServer. So, you may need to disable that if it's in use. Fortunately, this is an easy one, just stop and disable the
WinHTTP Web Proxy Auto-Discovery Service.
Our second issue with the proxy server occured when we were adding Exchange Online as a forest in the Exchange Management console.I neglected to get the exact error message, but it was similar to this:
The attempt to connect to https://ps.outlook.com/PowerShell/PowerShell.htm using "Basic" authentication failed. Connecting to the remote server failed with the following error message: The WinRM client is unable to connect.
The good part about this error message is that it tells us what software in unable to connect. Seeing that it's the WinRM client gave us an indication that this is likely the same type of proxy issue that we had with the Federation Trust. However, since the WinRM client is not part of Exchange Server the Set-ExchangeServer cmdlet we used earlier had no effect. Instead we used netsh to import the proxy settings from IE for use by all windows services.
netsh winhttp> import proxy source = ie
I'm not sure whether the WinRM client runs with the security credentials of the user or not. We ran this command on the CAS servers so there were no issues with authentication to the proxy because the proxy already allowed the CAS servers directly out without authentication.