The Issue
By now, anyone who has managed, deployed, or worked with an Exchange 2007 or later
environment should be familiar with Autodiscover. If you aren’t yet, I’ll give a short
Explanation of what it is and how it works.
Autodiscover is a feature that allows any Mail Client that supports Autodiscover to configure
the appropriate server settings for communication so you don’t have to input everything
manually. It’s very handy. Unfortunately, you can end up with a lot of headaches related to
Autodiscover when you start having to deal with Certificates. The issues you may run into are
specifically limited to Exchange Organizations that have a Domain Name that uses a nonpublic
TLD like domain.local, or a public domain name that they don’t actually own and can’t
use externally as well. On an unrelated note, this is one of the reasons that Microsoft has
started recommending the use of Public domain names for Active Directory domains.
If you have a domain that isn’t publicly useable on your Exchange AD environment, you will
run into certificate errors when mail clients use Autodiscover. This becomes particularly
problematic when you use Exchange 2013 and try to use HTTPS for Outlook Anywhere. This is
because Microsoft is now enforcing certificate validity with Exchange 2013’s Autodiscover
features (Note, though, that Outlook Anywhere will be configured to use HTTP only when
your Exchange Server certificate is determined to be invalid in Exchange 2013). With Exchange
The Cause
To solve the issue with certificates, you need to configure your environment so it enforces the
appropriate action with Autodiscover. By default, Autodiscover will attempt to communicate
with a number of URLs based on the Client’s email address (for external users) or domain
name (for internal users). It will take the following pattern when checking for Autodiscover
services:
1. Autodiscover will attempt to find the Autodiscover configuration XML file at the domain
name of the SMTP address used in configuration (because internal domain computers
configure themselves automatically by default, this matches the Internal Domain. For example,
the first place autodiscover looks is https://domain.com/Autodiscover/autodiscover.xml for
external addresses. Change domain.com with domain.local for what Exchange looks for on
Internal clients.
2. If the autodiscover record is not found at domain.com/domain.local, the server will attempt
to connect to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml (replace
domain.com with domain.local for internal). This is why the typical recommendation for
having an A Record for Autodiscover in your DNS that points to the mail server exists. In
addition, you would need to have autodiscover.domain.com as a SAN on the SSL certificate
installed on the Exchange server for it to be valid when attempting to connect to autodiscover
using this step.
3. If autodiscover information cannot be found in either of the first two steps, Exchange will
attempt to use a Service Locator record in DNS to determine the appropriate location of the
configuration files. This record points the Autodiscover service to a specific location for getting
the configuration it needs.
Because of the way this works, there is some configuration necessary to get Autodiscover
working correctly. This usually involves adding Subject Alternate Names to the SSL certificate
you use for your Exchange Server to allow the many host names used to be authenticated with
the certificate.
The problem lately, though, is that many Third Party Certificate Authorities that provide SSL
certificates are beginning to deny requests for Subject Alternate Names that aren’t publicly
available (There are valid security reasons for this that I won’t go in to in this post, but maybe
later). As a result, you won’t be able to get a valid SSL certificate that allows domain.local as a
SAN. This means that the automated steps Exchange uses for Autodiscover configuration will
always fail on an Internal domain with a name that is not publicly accessible or not owned.
The Solution
There are actually two ways to solve the certificate issues, here. The first would be to prevent
Outlook from automatically entering a user’s information when they create their profile. This
will result in more work for you and your users, so I don’t recommend it. The other solution is
to leverage that last step of the Autodiscover configuration search to force it to look at a host
to leverage that last step of the Autodiscover configuration search to force it to look at a host
name that is listed on the certificate. This is actually fairly simple to do. Follow these steps to
configure the Service Locator record in your internal domain.
1. Open the DNS manager on one of your Domain Controllers.
2. Expand out the management tree until you can see your Internal Domain’s Forward
Lookup Zone. Click on it, and make sure there are no A records for
autodiscover.domain.local in the zone.
3. Once no autodiscover A records exist, right click the Zone name and select Other New
Records.
4. Select Service Location (SRV) from the list.
5. Enter the settings as shown below:
6. Hit OK to finish adding the record.
Once the SRV record is added to the internal DNS zone, Outlook and other autodiscover clients
that attempt to configure themselves with a domain.local SMTP address will work properly
without the Certificate errors on all versions of Exchange.
Good to know
There are some additional benefits to utilizing the Service Locator record for Autodiscover
rather than an Autodiscover A record, even in your public domain. When you use a SRV
record, you can also point public clients to communicate with mail.domain.com or
outlook.domain.com, or whatever you have configured your external server name to be. This
means you can get away with having a single host name on your SSL certificate, since you
wouldn’t need autodiscover.domain.com to get autodiscover working. Since most Third Party
CAs charge a bit more for SANs than they do for Single Name SSL certs, you can save a bit of
money (for this to work, though, you may need to change your Internal and External Web
Services URLs in Exchange to match the name you have configured).
There are also some other issues you may run into that are easily fixed by adding a SRV record.
One of the most common is the use of multiple Email Domains in a single Exchange
Environment. If you have users that are not assigned a Primary or secondary SMTP address
that matches the domain name listed on your SSL certificate, you’ll discover that those users
and the rest of your users will not be able to share calendar data between their mailboxes. You
can fix this by adding an Autodiscover SRV record to the DNS zone that manages the
additional mail domains. For example, you have domain1.com and domain2.com on the same
Exchange Server. [email protected] can’t see [email protected]’s calendar. The fix for this is
to add the SRV record to the domain2.com DNS zone and point it to the public host name for
domain1.com’s mail server. Once that’s done the services that operate the calendar sharing
functions will be properly configured and both users will be able to share calendars.