Поделиться через

Controlling Outlook Autodiscover behavior

  • Статья

It has come to my attention recently that there is still a lot of confusion around Autodiscover, Outlook, and the way the two interact with one another. I'd like to try to clear some of that up by consolidating some of the information that I recently used to assist some of my own customers. Hopefully it will help you as well.

By now, everyone SHOULD be familiar with Autodiscover and what it does. Essentially, Autodiscover does the following:

  • Configures profile settings for Outlook 2007 and above clients as well as for various types of mobile devices
  • Provides Outlook clients with the URL's they need to access Exchange Web Services and the OAB download URL. EWS provides free/busy and Out of Office services.

Autodiscover is a function of EXCHANGE. Outlook 2007 and above clients are coded in such a way that they can take advantage of Autodiscover. It all works together (or it should). For Outlook to take advantage of the new Autodiscover features in Exchange 2007 and above, Outlook must be told where to go, or who to talk to if you will, to get all those fancy new features. That's where the Outlook logic comes into play in these scenarios. The order of logic that Outlook uses when trying to figure out where to get that information from is as follows:

  • SCP lookup - Outlook will get Autodiscover information from Active Directory. If that fails, Outlook begins it's "non-domain" connected logic (as I like to call it), and will go in order down this list
  • HTTPS root domain query - Outlook, if not domain joined, uses the RIGHT HAND SIDE of the users SMTP address to do this query. So using the domain from my example, it will search for https://wingtiptoys.com/autodiscover/autodiscover.xml
  • HTTPS Autodiscover domain query - If the above search yields no response, the next URL Outlook will try is https://autodiscover.wingtiptoys.com/autodiscover/autodiscover.xml
  • HTTP redirect method
  • SRV record query
  • Local XML file
  • cached URL in the Outlook profile (new for Outlook 2013)

There are some important points to remember so that you can determine what behavior to expect form Outlook. The first thing you need to know is:

  • Is the Outlook client domain joined AND can it currently CONTACT a DC in the domain!

The highlighted portion of that statement is an important distinction. If you are running Outlook on a laptop and you disconnect the network cable from said laptop and then try to configure a new Outlook profile, for example, your Outlook client will use it's NON domain joined logic at that point, because it CANNOT CONTACT ACTIVE DIRECTORY!

Where this becomes important is what I'd call "one off", or "unusal" circumstances, such as the absorption of one company by another. I ran across two such scenarios recently which is what prompted me to create this blog post. In these types of cases, it may be necessary to more fully control or tweak the Outlook to Exchange Autodiscover connection logic so that users will have a more robust experience, at least until the are fully absorbed into their new environment.

In both recent cases, the client computers were connected to Domain A (the "old" company) but needed to connect to Exchange servers in Domain B (the "new" company). One case was complicated further by the presence of Exchange 2007 in BOTH Domain A AND Domain B. And we needed to "test" connecting users in Domain B back to mailboxes created for them in Domain A WITHOUT making any modifications to either environment.

Since my client (meaning the actual computer I'm testing this with) is domain joined, and I am logged in with a domain account, Outlook automatically fills in my Name and E-mail address. If I just click next, Outlook will begin is logic and first try to locate Autodiscover settings via SCP. If my domain joined client can currently contact AD, it will get Autodiscover settings from AD and proceed with trying to configure the profile to connect to my mailbox (assuming I have a mailbox in that domain, assuming Exchange is installed and properly configured in the WingTipToys domain, etc).

The problem in the scenarios I referenced earlier, is that the customer wanted the Outlook client to connect to a mailbox in a completely different forest/domain. While you can certainly use the "Manually configure server" option, there are a few other things you could do.

At minimum, we must change the email address that has been autopopulated for us to the one that has been assigned to us from the "other" domain. For example purposes, I'll be using kris@corkandale.com.

For my customer, we decided to use a local autodiscover.xml file to override Outlook's default behavior, so that we could test some things without having to modify anything in either forest/domain. Think of this as a type of "hosts" file for Outlook. What you will do is create a file called autodiscover.xml that will look like this:

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns=" https://schemas.microsoft.com/exchange/autodiscover/responseschema/2006" >
<Response xmlns=" https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a" >
<Account>
<AccountType>email</AccountType>
<Action>redirectUrl</Action>
<RedirectUrl> https://autodiscover.corkandale.com/autodiscover/autodiscover.xml </RedirectUrl>
</Account>
</Response>
</Autodiscover>

Then you need to configure the client machine to query that XML file by adding the following registry key:

Tell Outlook to use a local xml file:

  • for Outlook 2007:

HKCU\Software\Microsoft\Office\12.0\Outlook\Autodiscover

  • for Outlook 2010:

HKCU\Software\Microsoft\Office\14.0\Outlook\Autodiscover

 STRING_value <your_namespace> = path to XML file

Or 15.0 for Outlook 2013

Where <your namespace> would be the namespace that Outlook will be querying for (corkandale.com in my example), and path to xml is the path to file.

NOTE: My client will STILL have to be able to resolve autodiscover.corkandale.com to an IP address. So, be sure that DNS is properly configured!

Even with the xml file in place, we still found that there was a pretty significant delay in both profile autoconfiguration AND in free/busy lookups. Using information from https://support.microsoft.com/kb/2612922 we excluded the following per the article:

  • SCP lookup
  • HTTPS root domain query

Once this had been done, we found things moved along much more quickly. This allowed my customer to do some more testing before fully integrating clients from Forest B into their own Forest.

Comments

  • Anonymous
    January 01, 2003
    Nice explanation, thanks for sharing!

  • Anonymous
    October 28, 2013
    How do you force outlook to use the local XML autodiscover file?

  • Anonymous
    October 29, 2013
    With the PreferLocalXML key, as noted here: support.microsoft.com/.../2212902