Exchange Hybrid Multi-namespace Autodiscover Configuration

I came across an interesting issue when using the Exchange Hybrid Configuration Wizard in a multi-namespace environment recently. Autodiscover was configured and working correctly for Outlook and EAS clients but the wizard would not complete successfully and would generate the following error: “Federation information could not be received from the external organization…” as seen below:

autodiscover

After some investigation, I discovered that this problem was related to Autodiscover. Typically in an on-premises Exchange 2010 deployment, there are a number of different ways to configure Autodiscover when using multiple namespaces. These are:

Option 1 - Single SSL Certificate that is valid for all DNS names (SAN Certificate)
Pros:

  • Requires only one certificate.
  • Requires only 1 public IP.

Cons:

  • Cost of additional DNS names in the SAN certificate could be expensive.

Option 2 - Single-name SSL Certificate with DNS SRV Lookup
Pros:

  • Requires only 1 public IP.
  • Requires 1 single-name SSL certificate.

Cons:

  • Not all DNS hosting providers support DNS SRV records.
  • Outlook users may be prompted.
  • Outlook 2007 required client-side hotfix.

Option 3 - Single-name SSL Certificate with HTTP redirect
Pros:

  • Requires 1 single-name SSL certificate.

Cons:

  • Requires 2 public IPs
  • Requires a second IIS site or ISA/TMG

While these will all work and have their pros and cons, I would usually always use ‘option 1’ listed above unless there is a good reason not to. In this particular instance, the Autodiscover was configured using ‘option 3’ and even though Autodiscover worked fine for clients, the Hybrid Configuration Wizard did not seem to like this configuration.

The Office 365 documentation does not go into a great amount of detail about multi-domain Autodiscover configuration and says: “Configure the Autodiscover public DNS records for your existing SMTP domains to point to an on-premises Exchange 2010 SP2 Client Access server” which is technically what had been done. The reason this caused a problem is because unlike Outlook or EAS clients, Office 365 does not use the Autodiscover discovery process and instead makes a direct connection to https://autodiscover.domain.com/autodiscover/autodiscover.svc/wssecurity for each domain being used and does not obey the web redirect that had previously been configured.

In order to solve this problem, we purchased a new SAN certificate and reconfigured Autodiscover as described in ‘option 1’. In short, this is the only way to configure Autodiscover if you plan to implement an Exchange Hybrid Deployment. Additionally, if you are not using split DNS and have an internal DNS zone that is different to your external DNS (eg. domain.local), you need to ensure that the relevant external Autodiscover records are resolvable internally as well.

As a side note, if you are using ISA/TMG to publish EWS/Autodiscover, you need to create a separate rule without authentication delegation for the following paths:

  • /ews/mrsproxy.svc
  • /ews/exchange.asmx/wssecurity
  • /autodiscover/autodiscover.svc/wssecurity
  • /autodiscover/autodiscover.svc