SBS 2008/2011 — Configuring AutoDiscoverThe Autodiscover protocol uses a variety of techniques to fetch the information required to connect to a user's mailbox. Different email clients do not necessarily use all of the methods, or use them in the same order. For example, Microsoft Outlook uses the following methods in order:
For Microsoft Outlook, enabling or disabling these methods can be achieved using specific values under the HKCU\Software\Microsoft\Office\<version>\Outlook\AutoDiscover registry key. In a Microsoft Small Business Server (SBS) 2008/2011 environment, the server is given a DNS name used for internal and external resolution of the various services provided by the server — this is usually of the form remote.<domain> (but SBS 2011 allows the remote part to be modified), and a SCP record is added to Active Directory. This means that Outlook connects to on-premises Exchange automatically when logged in as a domain user. External users do not have access to Active Directory or their device (smartphone/tablet) may not support SCP. So the simplest and best-practice way to provide AutoDiscover services to these clients is simply to create a CNAME record in the domain's DNS which points autodiscover.<domain> → remote.<domain>. Thus these clients will use the third method above by polling https://autodiscover.<domain>/Autodiscover/Autodiscover.xml. Now, any SSL certificate installed on the server should support Subject Alternative Names (SAN) or wildcards so that it may include both aliases. If autodiscover.<domain> is not listed in the certificate, client devices will give certificate errors. And on-premises Outlook clients may continually prompt whether to accept it or not (despite the fact they should be using the URL returned by SCP). However, wildcard or SAN certificates are costly, in comparison to a certificate which only supports a single name, such as remote.<domain>. So instead of relying on AutoDiscover services on the default alias of autodiscover.<domain> and requiring this name to be included in the certificate, it is possible to redirect the AutoDiscover requests by on-premises Outlook clients to the alias already in the certificate. To do this, add a SRV record to your domain's DNS, with details as follows:
iOS, as an Exchange ActiveSync (EAS) client, does not support this method of AutoDiscovery, and consequently will prompt for additional details when adding a mailbox. So using the AutoDiscover DNS record is still required for those devices. But because Microsoft Outlook uses a variety of methods to determine the mailbox and the order they are checked is hard-coded, the presence of the autodiscover.<domain> record will cause Outlook to use that method, ignoring the SRV record, and consequently display certificate errors. In this situation, this method can be disabled in Outlook, ensuring it uses only the SCP/SRV methods:
reg add HKCU\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeHttpsAutoDiscoverDomain /d 1 /t REG_DWORD /f reg add HKCU\Software\Microsoft\Office\15.0\Outlook\AutoDiscover /v ExcludeHttpsAutoDiscoverDomain /d 1 /t REG_DWORD /f reg add HKCU\Software\Microsoft\Office\16.0\Outlook\AutoDiscover /v ExcludeHttpsAutoDiscoverDomain /d 1 /t REG_DWORD /f reg add HKCU\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeHttpsRootDomain /d 1 /t REG_DWORD /f reg add HKCU\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeHttpRedirect /d 1 /t REG_DWORD /f These settings can be pushed to clients very simply via a login script, and undone by changing the value from 1 to 0 if necessary. Or see How to control Outlook AutoDiscover by using Group Policy. Under this configuration, iOS devices can use the autodiscover.<domain> method of discovery, and Outlook clients can use the SCP/SRV methods. You can check connectivity via https://www.testexchangeconnectivity.com, but to simulate the environment, temporarily remove or rename autodiscover.<domain> from the DNS so the test falls back to using the SRV records. |