Exchange Autodiscover logic and SCPs

If you want to thoroughly understand Exchange Autodiscover logic, and in particular how Outlook handles various SCP scenarios like cross-forest redirect (pointer) vs. same-forest SCP per-CAS, this is the place:

https://msdn.microsoft.com/en-us/library/ee332364(v=exchg.140).aspx

Here I will highlight the most important concepts which in particular helped me to design Autodiscover approach for the current customer’s migration.

1. Outlook is following certain Autodiscover URL resolution chain where SCP record lookup comes first, unless suppressed in the registry or local XML is enforced. SCP is always retrieved based on the user’s workstation domain membership.

2. SCP can be of the different types:

SCP pointers: Records that are used to support cross-forest Exchange deployments. SCP pointers are stamped with the following GUID under keywords attribute: 67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68. These normally contain LDAP:// redirect under serviceBindingInformation attribute and SCP resolution process is repeated again but now talking to the new LDAP provider naming context.

SCP URLs: Records that represent Autodiscover service URLs, scoped to Active Directory sites. SCP URLs are stamped with the following GUID under keywords attribute: 77378F46-2C66-4aa9-A6A6-3E7A48B19596 plus site name. These will contain actual Autodiscover URL in https:// format under serviceBindingInformation attribute.

3. SCP pointers that do not have a list of Domain=domain.com entries or Site= entries and only contain the corresponding GUID are called wildcard pointer. One example would be accounts forest with no Exchange and wildcard pointer containing just 67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68 GUID. It will redirect ALL client requests to Exchange resource forest containing user’s mailboxes and CAS servers hosting Autodiscover service.

Here is a little different look at the same logic – very useful to read both articles as they somewhat complement each other:

https://msdn.microsoft.com/en-us/library/exchange/jj900169(v=exchg.150).aspx

I. Client high level Autodiscover URL lookup logic.

The client application determines the starting URL for the SOAP Autodiscover service from the email address. For example, to find the Autodiscover endpoint for the email addressuser1@contoso.com, your application contacts the Autodiscover service for the contoso.com domain. In this example, the client application uses the following steps to determine the Autodiscover service endpoint:

1. The application finds the correct starting URL by trying URLs in the following order:

-Any URL returned by the SCP lookup process, as described later in this article.

-https://contoso.com/autodiscover/autodiscover.svc

-https://autodiscover.contoso.com/autodiscover/autodiscover.svc

If any of these attempts succeeds, the application processes the response, as described inProcessing a SOAP Autodiscover response.

2. If none of the URLs work, the application does a DNS query for an SRV record for _autodiscover._tpc.contoso.com. Although the query might return multiple records, the application should use only records that point to an SSL endpoint and that have the highest priority and weight. The application then proceeds as follows:

-If no SRV records are returned, the application cannot contact the Autodiscover service.

-If SRV records are returned, the application randomly chooses a record in the list and validates the endpoint that it points to by following the process described in Validating a potentially unsafe redirection URL. If the redirection URL is valid, the application tries the URL. If the redirection URL is not valid, the application cannot contact the Autodiscover service. If the attempt succeeds, the application processes the response, as described in Processing a SOAP Autodiscover response. If the attempt fails, the application cannot contact the Autodiscover service.

II. AD SCP lookup logic.

Client applications perform the following steps to look up SCP records in the Active Directory database:
1. The application reads the configurationNamingContext property of the Root DSE entry. For the current forest, the Root DSE entry is at LDAP://RootDSE. If the configurationNamingContext property cannot be found, the client abandons SCP record lookup and proceed with SOAP Autodiscover, as described earlier in this article.

2. The application searches for SCP records under the configurationNameContext entry,LDAP://<value of configurationNameContext> using the following filter:

(&(objectClass=serviceConnectionPoint)(|(keywords=67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68)(keywords=77378F46-2C66-4aa9-A6A6-3E7A48B19596)))

This returns a list of all SCP records, pointers, and URLs. If no records are returned, the client abandons SCP record lookup and proceeds with SOAP Autodiscover, as described earlier in this article.

3. The application looks for an SCP pointer that is scoped to the user’s domain. SCP pointer records may be stamped with the keyword Domain=<domain>. For example, if the user’s email address is user1@contoso.com, the application looks for an SCP pointer record with the keyword Domain=contoso.com.

-If the application finds a scoped SCP pointer record, it proceeds to step 5. (A.P. During my LAB testing even if no “Domain=” match is found with the user’s Email and it’s just a single SCP pointer – meaning no other SCP pointers found as a result of above LDAP query – containing some other “Domain=” non-matching entries, it will still be selected).

-If no scoped SCP pointer record is found, but at least one wildcard SCP pointer record with no scoping exists, the application does the following:

-Tries the SCP URLs, as described in step 4.

-If none of the SCP URL attempts are successful, it falls back to following one of the wildcard SCP pointers, as described in step 5.

4. To try an SCP URL, the application does the following:

-Determines the name of the AD Site to which the computer that is running the Autodiscover client belongs (A.P. Original article has a typo talking about CAS server here). We’ll call this value siteName.

-Each SCP URL may be scoped to a specific Active Directory site. The application tries the SCP URLs in the following order:

Priority 1 — Exact match: The SCP URL has at least one keyword that reads Site=siteName in its keyword property.

Priority 2 — Wildcard: The SCP URL record does not have any keywords that start with Site=.

Priority 3 — No match: The SCP URL contains at least one keyword that starts with Site= but none of these keywords contains Site=siteName.

5. An SCP pointer record indicates that an LDAP server in another forest is used to look up SCP URLs. The application reads the serviceBindingInformation property of the SCP pointer record and restarts the SCP record lookup process from step 1, this time using

LDAP://<value of serviceBindingInformation>/RoodDSE

and the Root DSE path.

6. (Added by me – A.P.) Once Autodiscover URL is found and communication is established to the CAS server, lookup for the user’s mailbox is performed. If user’s Email address is found to match the existing mailbox in the current Exchange org / forest served by this Autodiscover URL (it can match by either Primary SMTP or SECONDARY SMTP!) then lookup succeeds and all Autodiscover-related information like Availability URL, OOF and OAB URLs are set etc.