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:
Set-ExchangeServer -Identity CASServer -InternetWebProxy:http://proxy:portAfter setting the proxy for Exchange Server, we got an error:
(407) Proxy Authentication RequiredAt 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:
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 = ieI'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.