How To Create Autodiscover Dns Record

The Issue

Ever since Outlook 2016 was released, Autodiscover has been a necessity, rather than an option.

Autodiscover allows any Mail Client that connects to Exchange server to configure the appropriate settings for communication so you don't have to input everything manually. It's very handy, but can cause certificate errors if not configured correctly. One issue you may run into occurs most often with Exchange Organizations with non public DNS domains like domain.local. The same problem exists when organizations use a public domain that they don't own. 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 or newer 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 use unsecured HTTP when your Exchange Server certificate is determined to be invalid for modern Exchange deployments). With Exchange 2007 and 2010, you will get a Certificate error every time you open Outlook. This error will state that the name on the certificate is not valid. If you need a primer on Digital Certificates and validity.

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. The Active Directory SCP will be picked up first, then a lookup against https://domain.com/autodiscover/autodiscover.xml occurs (Domain.com matches the email domain for this situation)

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 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

IMPORTANT NOTE: This particular solution only applies to computers on your network that are *not* added to the domain. Domain-joined computers have a different issue to work with. Please read my article on resetting the Active Directory SCP for resolving Autodiscover issues like this on domain-joined computers. Additional problems and solutions can be found here.

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 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.

Open the DNS manager on one of your Domain Controllers.
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.
Once no autodiscover A records exist, right click the Zone name and select Other New Records.
Select Service Location (SRV) from the list.
Enter the settings as shown below:
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.

Other Nifty Stuff

There are some additional benefits to utilizing the Service Locator record for Autodiscover rather than an Autodiscover A or CNAME 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 up to three times more for SANs or wildcards than they do for Single Name SSL certs, you can save a bit of money (you may need to change your Internal and External Web Services URLs in Exchange to match the name you have configured).

Another Problem the SRV record Fixes

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 Server Environment. If you have users that are not assigned a Primary or secondary SMTP address that matches the domain name listed on the 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. user@domain1.com can't see user@domain2.com'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.

More Info on Autodiscover

The following posts and sites will help you learn more about Autodiscover and how to work with it:

Configure Exchange Autodiscover
Exchange Autodiscover – The Active Directory SCP
Configuring Autodiscover for Internal DNS
QuickPost: What do Exchange Virtual Directories Do?
Configuring Exchange Virtual Directories
Fixing Outlook Certificate Errors
Controlling Autodiscover with Registry or GPO
Autodiscover – Microsoft Docs