This post comes as a result to a recent issue that I encountered on a support incident with high production impact.
In my case, there was installed a new CAS role server in the Exchange 2010 organization, but still not added in the CasArray or Load Balancer and not even published on TMG.
Actually, more important than everything, on this new CAS there was enabled Outlook Anywhere feature with a different client authentication method than on the other existing CAS servers.
What really happened?
Even if the Outlook Anywhere Autodiscover requests didn’t arrive on the new server, as it was not reachable from outside (consulting IIS/TMG logs), Autodiscover service provided as authentication method the one that was set on the new CAS.
As a result 90% of the Outlook Anywhere clients weren’t any more able to authenticate.
So, I decided to blog this topic in order to explain in more details Micrososft Technet documentation regarding Outlook Anywhere’s configuration retrieval in multi-CAS environment.
Please follow the detailed Autodiscover White Paper for Exchange 2007 (http://technet.microsoft.com/en-us/library/bb332063(v=EXCHG.80).aspx) – which is applicable for Exchange 2010 too, and pay more attention to the 4th and 5th lines:
- Outlook 2007/2010 sends a Lightweight Directory Access Protocol (LDAP) query to Active Directory looking for all available SCP objects. Specifically, Outlook
initializes the LDAP connection using the ldap_init() function and passes a NULL value for the hostname. When a particular global catalog server name (or domain
name) is not specified, the operation searches for a global catalog server in the domain, based on the membership of the computer that is initializing the operation.
- Outlook 2007 sorts and enumerates the returned results based on the client’s Active Directory site by using the keyword attribute of the SCP record. One of two
lists is created, an in-site list or an out-of-site list. The in-site list provides the SCP records that have AutodiscoverSiteScope
information. AutodiscoverSiteScope is a parameter that is set on the Client Access server by using the Set-ClientAccessServer cmdlet. The parameter specifies the site for which the Autodiscover service is
authoritative. The AutodiscoverSiteScope information contained in the SCP records for the in-site list matches the Active Directory site for the Outlook
client. If there are no in-site records, an out-of-site SCP record list will be generated. The list is not sorted in any particular order. Therefore, the list
is approximately in the order of oldest SCP records (based on creation date) first.
- Outlook first tries to connect to each Autodiscover URL that it had previously generated from either an in-site list or an out-of-site list. If that doesn’t
work, Outlook will try to connect to the predefined URLs (for example, https://autodiscover.contoso.com/autodiscover/autodiscover.xml) by using DNS. If that fails also, Outlook will try the HTTP redirect method and,
failing that, Outlook will try to use the SRV record lookup method. If all lookup methods fail, Outlook will be unable to obtain Outlook Anywhere configuration and URL settings.
- The Autodiscover service queries Active Directory to obtain the connection settings and URLs for the Exchange services that have been configured.
- The Autodiscover service returns an HTTPS response with an XML file that includes the connection settings and URLs for the available Exchange services.
- Outlook uses the appropriate configuration information and connection settings to connect to your Exchange messaging environment
Actually, you might be thinking that if Autodiscover HTTP request arrives on a specific CAS,only that CAS Server alone will provide the information below, if
the features are enabled:
- the user’s display name
- separate connection settings for internal and external connectivity
- the location of the user’s Mailbox server
- the URLs for various Outlook features that govern functionality such as free/busy
information, Unified Messaging, and the offline address book
- Outlook Anywhere server settings
But, actually that’s not what happens!
Autodiscover, on whichever server gets the request, it enumerates all the CAS in the AD site for values and then randomly choses one, and then returns it.
We should never assume that any one CAS only looks at itself for values to return to users, because we’ll be wrong. Following this logic, we should never think
that is possible to manipulate the flow in order to have predictable behavior.
Actually, we have in the CAS code the algorithm it uses to pick a certain URL.
There should never be used inconsistent configuration for Outlook Anywhere, from CAS to CAS in the same site, even if you might be thinking that
Autodiscover service isn’t reachable from it, because Autodiscover service queries all the available CAS servers in the site, having the feature enabled.
For further investigation on Autodiscover behavior :