Understanding and Setting Up AutoDiscover for Exchange 2010 / 2013

Confusion and myths run around the IT world about Exchange AutoDiscover, and here I am to bust them all up into tiny little pieces. The primary purpose of this is to show how the internal and external (using RPC/HTTPS, aka Outlook Anywhere) clients connect using AutoDiscover and setting it up so you don't get those dreaded "certificate" errors.
 

How an internal, domain joined (which has Active Directory access) looks up the AutoDiscover record

1. Outlook opens, and queries Active Directory for the Service Connection Point on an Exchange server for the AutoDiscover URI / URL (I will explain more about this below)
2. Active Directory returns the URI / URL to the Outlook client, which then looks it up within DNS
3. Outlook connects to Exchange using the AutoDiscover URL over TCP 135 (RPC Endpoint Mapper) to Authenticate, pulls a ton of Exchange attributes from the mailbox (mainly find the mailbox using the homeMDB attribute along with the version of Exchange the user is on using the msExchangeVersion attribute), pulls the proper TCP ports (RPC Client Access, Address Book Service, Public Folders) and also pulls the Outlook provider record (e.g: EXPR: which gives the EWS InternalURL)
4. Outlook then negotiates its connection and connects into Exchange

 

How an external, non-domain joined client (or domain joined clients who are out of the office) looks up AutoDiscover

1. Outlook will try to contact the local active directory domain but fails, thus falling back to URLs
2. Outlook will then attempt to query the https://domain.com/autodiscover/autodiscover.xml, but most likely fails. It falls back to http://domain.com/autodiscover/autodiscover.xml which will also most likely fail
3. Outlook then tries to connect using https://autodiscover.domain.com/autodiscover/autodiscover.xml, and if this fails it will try over HTTP using http://autodiscover.domain.com/autodiscover/autodiscover.xml
4. If this fails it will try to locate an SRV record for AutoDiscover (which I won't cover, since I rarely see them utilized in enterprise or medium-small business environments)
5. If everything fails it will most likely return a HTTP 500 error (service not found)

Eventually Autodiscover will connect over HTTPS if configured properly (e.g: SSL certificates and all) and also make its connection over Outlook Anywhere (RPC/HTTPS). Exchange will return the EXCH Outlook provider record that will contain the ExternalURL for EWS (for things such as Availability service, OOF, ect)

Service Connection Point Object, AutoDiscover InternalURL and ExternalURL and what is REALLY used

Let’s debunk the biggest myth around AutoDiscover of all time: the AutoDiscover InternalURL and ExternalURL are never used... ever. I promise. The reason they exist is due to the way the AutoDiscover virtual directory is created, and the underlying schema requires that an ExternalURL and InternalURL exist for a Virtual Directory in Exchange.

So now onto the service connection point, and what it really is. Within Active Directory each server within the Administrative Group for Exchange has its own container. The AutoDiscover Service Connection Point is actually located below:

1. Open Active Directory Sites and Services
2. Right Click "Active Directory Sites and Services [DC FQDN here]" and select View > View Service Node
3. Drill down the path of Service > Microsoft Exchange > Exchange Organization Name (my case its exchangelab) > Administrative Groups > (Select Exchange Administrative Group that is proper) > Servers > Server Name (CAS or Multiple Role Server) > Protocols > AutoDiscover > Servername
4. Once you get down the golden brick road, you can right click the server name and click on the "Attribute Editor" tab, which will then contain an attribute called "serviceBindingInformation" that has the AutoDiscoverServiceInternalUri that the internal, domain joined Outlook client looks for:

Too much to go through right? Luckily enough you can view the same information within Exchange Management Shell by running the following command:

Get-ClientAccessServer | Select Identity, AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope


By doing this you will reveal what the SCP object is set to (which is the URL Outlook clients internally will be pulling) along with the site scope which is important. The reason this is important because the Outlook client will look locally within its Active Directory site prior to reaching out to others, which is the reason for the site scope. If it cannot find a CAS with a valid SCP object within its own site of origin utilizing the AD Access 2915 information (which shows which active directory services are available) it will look up out of site. Outlook clients will not pull two SCP objects, so it’s either within site (local - preferred) or out of site.
 

Namespace, SSL Certificate and DNS planning

I am a firm believer of not reinventing the wheel. I will gloss over this but there are some awesome references from our own EE Simon Butler below along with Paul Cunningham, who is a MVP for Exchange along with a MCM/MCSM on these topics.
You should have the following namespace setup within your environment using split DNS (it simplifies everything):
 

• Mail.company.com which is applied to the OWA/ECP, Exchange ActiveSync, Exchange Web Services, OAB Web Distribution, Outlook Anywhere and (if you want) SMTP/POP3/IMAP4
• Autodiscover.company.com that goes directory to Autodiscover

That’s it. If you have the need for different authentication methods for OWA / Outlook Anywhere and are using a reverse proxy you may need a separate namespace for Outlook Anywhere (outlook.company.com is what I typically use).
If you are doing split DNS (which I am hoping you are, and you probably should – read Simon’s article below for more information on setup) then you should have your ExternalURL and InternalURL matching. The only time this would not apply is you are doing an active / passive setup, and the DR namespace (which cannot be the same as your primary site's namespace) would need only the InternalURL setup and configured.

If you are doing active / active it’s the same theory, but instead you would need two namespaces, most likely webmail.company.com and mail.company.com. Autodiscover can point to the same place.

Split DNS by Simon Butler (Expert Exchange – Simbee)
Namespace and Certificate Planning by Paul Cunningham

NOTE: if you don’t want to read the URLs, there are two takeaways here:

• Set up split DNS (same external hostname as internal) as you will prevent a headache later
• You must have the namespace applied to the client access virtual directories along with the AutoDiscover Service Connection Point within the SSL certificate or this will not work

 

Configuring AutoDiscover for Internal clients (domain joined with AD access)

Now you know the basics on AutoDiscover lets actually get this configured.

Single site or Active / Passive setup
 

1. Open Exchange Management Shell
2. Run the following command

Get-ClientAccessServer | Set-ClientAccessServer –AutoDiscoverServiceInternalUri https://autodiscover.company.com/autodiscover/autodiscover.xml
 

1. Verify by running the following

Get-ClientAccessServer | Select AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope

Looks good? You are done! As long as you have an A record pointing to your RPC endpoint (it can be a single CAS if that’s all you have, or the Virtual IP of a load balancer) along with a valid third party SSL certificate with the autodiscover namespace within it then you are basically done.

Active / Active setup

In this case we will most likely have two autodiscover namespaces, so when I lookup the Autodiscover URI in DNS I am pointed to the CAS local to my site.
 

1. Open Exchange Management Shell
2. Run the following command to set the AutoDiscover SCP for one of the sites

 
Get-ClientAccessServer | ? {$_.AutoDiscoverSiteScope –eq “AD Site Name” } | Set-ClientAccessServer –AutoDiscoverServiceInternalUri https://autodiscover.company.com/autodiscover/autodiscover.xml 

1. Verify that the site you just configured for the AutoDiscover SCP is proper

Get-ClientAccessServer | Select AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope
 

1. All looks good, let’s set the other site

Get-ClientAccessServer | ? {$_.AutoDiscoverSiteScope –eq “AD Site Name” } | Set-ClientAccessServer –AutoDiscoverServiceInternalUri https://nyautodiscover.company.com/autodiscover/autodiscover.xml
 

1. Confirm again by using the command above in step #3

 
The two AutoDiscover namespaces allow me to setup two DNS A records for each site, so when users are in their appropriate site the users are sent to the proper CAS instead of having their AutoDiscover request sent (proxy) across site. This can cause latency and excess cross site traffic that can be avoided.
 

Configuring AutoDiscover for External clients (domain joined without AD access or home users / users who are using non-domain joined machines)

This is also pretty simple..

1. Create a DNS A record for autodiscover.company.com (this is used by default within Outlook and cannot be changed when the SCP object cannot be found)
2. Open TCP 443 to the CAS or Virtual IP of the load balancer hosting Exchange (if one exists)
3. Enjoy

 

I am still getting certificate errors, why?

A few things to check:

• Run the Check E-Mail AutoConfiguration test within Outlook (shift – right click the Outlook icon and select the item that says “Test E-Mail AutoConfiguration”). The main thing to look at is to see what URLs are returned.. are these correct and within the SSL certificate that is assigned to the IIS service?
• Is your AutoDiscover SCP set properly?

Get-ClientAccessServer | Select Identity, AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope
 

• Did you change the namespace on the EWS virtual directory and forget to reset the IIS virtual directory? (protip: IISRESET /NOFORCE will restart the restart IIS for you)