Share via

Mastering Autodiscover

  • Article

If you are an Exchange administrator, you may have already known “autodiscover”. If you don’t know what autodiscover is, I guess you’ve heard this word at least once from IT administrator or Microsoft support engineer. Autodisover was introduced when Exchange 2007 was shipped and it is more than a decade technology, However all versions of Exchange (from Exchange 2007) heavily rely on Autodiscover and it is crucial for all Exchange administrators to understand what it is, how it helps users and most importantly how to troubleshoot when it is not working. Surprisingly, there aren’t so many Microsoft’s published documents about this technology, so I decided to write must-know about Autodiscover. If you know all content covered in this blog, I expect you can configure autodiscover right and quickly solve autodicover related issues.

How Autodiscover works
Autodiscover is a feature which enables automatic client profile configuration and provides end point of Exchange Web Service (EWS) such that clients can utilize EWS related feature like getting free busy information. The following TechNet explains more about Autodiscover.

Autodiscover service
https://technet.microsoft.com/en-us/library/bb124251(v=exchg.160).aspx
 
When Outlook client attempts to autodiscover, Outlook tries to connect the following URLs.

1) URL defined in SCP (Service Connection Point) in On-premise Active Directory.
2) https://<SMTP-address-domain>/autodiscover/autodiscover.xml
3) https://autodisocver.<SMTP-address-domain>/autodiscover/autodiscover.xml
4) <SMTP-address-domain> defined in Local XML
5) https://autodisocver.<SMTP-address-domain>/autodiscover/autodiscover.xml
6) _Autodiscover._tcp. <SMTP-address-domain> (SRV Record)

Let me explain some key words and detail behaviors.
 
What is SCP ?
SCP is abbreviation for Service Connection Point, which means connection end points for Exchange related service. SCP is created for each CAS (in Exchange 2007/2010) or Mailbox server. SCP can be found at Active Directory Configuration partition by using ADSI Editor as follows.
 
[Configuration] – [CN=Configuration,DC=example,DC=local] – [CN=Services] – [CN=Microsoft Exchange] – [CN=<Organization Name>] – [CN=Administrative Groups] – [CN=Exchange Administrative Group (FYDIBOHF23SPDLT)] – [CN=Servers] – [CN=<CAS or Mailbox server name>] – [CN=Protocols] – [CN=Autodiscover] – [CN=<CAS or Mailbox server name>]
 

Outlook client gets the list of SCP from Active Directory (AD) and then finds URL to connect.
 
Which SCP does Outlook client access?
We should be aware of which AD site clients belong to.
Outlook looks at Keyword attribute in SCP from the SCP list. This Keyword attribute contains AD site name and Outlook checks if its AD site matches with the one defined in the Keyword attribute. If Outlook finds SCP whose Keyword attribute matches with its AD site, Outlook sends Autodiscover request to URL defined in ServiceBindingInformation attribute of that SCP.
If there aren’t any SCP which has client’s AD site, Outlook attempts to connect each SCP in the order of the SCP list obtained by LDAP query. There is no sort mechanism in SCP list so in general Outlook connects to SCP in random order. (As a rule of thumb, it is the order by the time SCP was created).

In other words, autodiscover access point is configurable by changing Keyword or ServiceBindingInformation attributes. Those attributes can be defined by Set-CleintAcessServer command and Keyword attribute corresponds to AutodiscoverSiteScope parameter and ServiceBindingInformation attribute to AutodiscoverServiceInternalUri parameter.
There is TechNet article which explains how to control target SCP by utilizing AutodiscoverSiteScope parameter.

Configure the Autodiscover Service to Use Site Affinity
https://technet.microsoft.com/en-us/library/aa998575(v=exchg.141).aspx
 
Non-domain joined Outlook client scenario
Non-domain joined or Workgroup clients cannot access SCP, so those clients start trying to connect from Step (2) explained above. It means we need DNS A record for autodiscover.<smtp-address-domainor> hosts file which has autodiscover.<smtp-address-domain> entry.
 
Resource/Account forest scenario
If you are running Exchange in resource/account forest topology, you have user accounts and clients reside in account forest and utilize “Linked mailbox” to connect to mailboxes which are in resource forest. In order for clients to successfully make autodiscover connection, you should either have SCPs in account forest or create DNS records (since SCP lookup fails).
There is an Exchange PowerShell command called Export-AutoDiscoverCnnfig to create SCP in account forest. You ran this command from Exchange in resource forest as follows.
Export-AutoDiscoverConfig -TargetForestDomainController <DC in account forest> -TargetForestCredential:(get-credential).

For more detail on Export-AutoDiscoverConfig, check up the following TechNet below.

Export-AutoDiscoverConfig
https://technet.microsoft.com/en-us/library/aa998832(v=exchg.160).aspx
 
SCP created in account forest has ServiceBindingInformation attribute pointing to LDAP URL of resource forest (Example: LDAP://example.com).
Outlook client attempts to connect DC in resource forest based on this LDAP URL and get ServiceBindingInformation attribute of SCP in resource forest.
How does Outlook client attempt to connect SCP if there are multiple SCPs in resource forest?
The behavior is the same as I explained previously. Outlook relies on Keyword attribute (AutodiscoverSiteScope). In other words, if SCP of CAS or Mailbox server set AutodiscoverSiteScope as AD site called “AccountForest01”, all clients in “AccountForest01” always attempt to connect AutodiscoverServiceInternalUri of the corresponding Exchange servers.
 
Hybrid Exchange scenario
If you are planning to migrate Onpremise Exchange to Exchange Online, you may need to configure Hybrid Exchange. I think the importance of Autodiscover is even greater in Hybrid Exchange scenario because Autodiscover helps user connect to mailbox in Exchange Online without any manual profile setting after migration. You may wonder how Outlook detect correct target Exchange server even if mailbox is moved from Onpremise Exchange to Exchange Online. The secret is remote mailbox in Onpremise Exchange. If you move mailbox to Exchange Online under Hybrid environment, moved mailbox turns into “Remote mailbox”, which is basically mail enabled user. This mailbox conversion process is a part of mailbox migration and is done automatically.
The process of finding Autodiscover end point does not rely on mailbox location (Onpremise or cloud) but is consistent as I explained earlier. Domain-joined client first looks up SCP and attempts to connect to Onpremise Exchange servers defined in SCP. If the mailbox is moved to Exchange Online or the mailbox becomes remote mailbox, Outlook client make another autodiscover request based on RemoteRoutingAddress parapeter of the remote mailbox.
Here is how Outlook attempts to make Autodiscover request.
 
//// User account
Primary SMTP address:User1@contoso.com
RemoteRoutingAddress;User1@contoso.mail.onmicrosoft.com
You can check RemoteRoutingAddres by the following command-let.

Get-RemoteMailbox <User Name> | FL RemoteRoutingAddress
 
1) Detect Autodiscover end point (URL) of SCP based on User’s primary SMTP address
(Example https://onpremEx01.contoso.com/Autodiscover/Autodiscover.xml)
Client may subsequently make autodiscover request based on contoso.com domain

2) Detect Autodiscover redirect (User1@contoso.mail.onmicrosoft.com)
3) Autodiscover to https://contoso.mail.onmicrosoft.com/autodiscover/autodiscover.xml
4) Autodiscover to https://autodiscover.contoso.mail.onmicrosoft.com/autodiscover/autodiscover.xml
5) Local autodiscover to contoso.mail.onmicrosoft.com
6) Redirect check to https://autodiscover.contoso.mail.onmicrosoft.com/autodiscover/autodiscover.xml
7) Autodiscover URL redirection to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
8) Autodiscover to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
9) Redirect check to https://autodiscover.contoso.mail.onmicrosoft.com/autodiscover/autodiscover.xml
 
If clients are domain-joined, Step1 is always performed and client attempts to connect to Onpremise Exchange servers.
If you enable AutoDiscover registry on Outlook Client, client skips looking up SCP even if it is domain-joined.
 
HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook version (Note)>\Outlook\AutoDiscover

Value Name: ExcludeScpLookup
Type : REG_DWORD
Value : 0x00000001 (1)

Note:
14.0 for Outlook 2010,15.0 for Outlook 2013 and 16.0 for Outlook 2016
 
Troubleshooting Autodiscover
So far, we covered a basic autodiscover behavior and how Outlook client makes autodiscover request under a few well-known scenarios.
Now I want to walk you through some troubleshooting steps so that you understand if autodiscover is working or what is going wrong.
 
Check with Test E-mail AUtoConfiguration
Test E-mail AutoConfiguration is your friend. Test E-mail AtoConfiguration helps you to check if Autodiscover succeeds or how far AUtodiscover process goes till it fails.
 
1) Start Outlook.
2) Logon to Outlook profile and then right click on Outlook icon in Task tray.

3) Click “Test E-mail AutoConfiguration”

4) Enter correct email address if needed and provide credential if asked.
5) Check only “Use Autodiscover”

6) Check “Results” tab if autodiscover succeeds and check “Log” tab to see where autodiscover fails.

Here is a sample.

7) If you are familiar with Autodiscover response (XML), checking “XML” tab helps you see if client receive expected response.

-------------- Additional tips -----------------
You can utilize Test E-mail AutoConfiguration even if you don’t have any Outlook profile.
Here are the steps.

1) Delete all profiles and start OUtlook
2) Enter Outlook profile name and click "OK".
3) Click "Cancel" and then "OK" for dailogue box not to create a profile.
4) Click "Next" for Profile creation wizard.
5) Click "No" and then click "Next"
6) Check "Use Outlook without an email account" and click "Finish"
------------------------------------------------
 
Test with browser access
You can use any browser to access Autodiscover endpoint. If it fails, you may have network issue or other causes that prevent you from accessing it.
If Outlook client is non-domain joined,AutoDiscover endpoint is most likely https://autodisocver.<SMTP-address-domain>/autodiscover/autodiscover.xml.
Open up any browser and try accessing that endpoint.
You will be asked for credential and if you provide correct credential and see the following response below, you can successfully access the endpoint. If not, you should troubleshoot further (It is most likely network related troubleshooting)
 
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response>
<Error Time="06:32:34.3818286" Id="413347856">
<ErrorCode>600</ErrorCode>
<Message>Invalid Request</Message>
<DebugData/>
</Error>
</Response>
</Autodiscover>
 
Test with ExRCA
Remote Connectivity Analyzer or ExRCA helps you diagnose Autodiscover, Outlook connectivity or EWS related issues.
Here are the steps
 
1) Access the following URL
https://testconnectivity.microsoft.com/

2) If you want to check Autodiscover connectivity, check “Outlook Autodiscover”.

3) Enter SMTP address and credential for the user you want to test, and then Click “Perform test”
4) If you see “Connectivity Test Successful” as a result, you have no issue. If not, you should expand each test phase and you can get detail error like below.


 
Closing
Thank you very much for reading through this long blog and I hope you understand some basics of Autodiscover and are equipped with troubleshooting tips. It would be great if this content benefits those who plan, deploy and manage Exchange Server infrastructure.