Controlling the behavior of Outlook AutoDiscover using the registry is not a new idea. Indeed, it has been around almost as long as AutoDiscover itself—perhaps longer.

Robert Pearman

Robert is a small business specialist from the UK and currently works as a system administrator for IT Authority. He has been a Microsoft MVP for seven years and has worked as a technical reviewer for Microsoft Press. You can follow Robert in his blog.

If you are unfamiliar with the technique, essentially what we can do is tell Outlook to ignore, or only use, a certain part of the AutoDiscover process. We can use this to good effect in Active Directory environments where an on-premises Exchange environment still exists, but where you may wish to configure an email profile outside of that.

AutoDiscover can use something called Service Connection Point (SCP), which can interrupt or take precedence over externally published DNS information. This is especially true when an organization may be switching from a local Exchange environment to Office 365.

In addition to this, which you can have a relative amount of control over, another situation may arise that requires you to override the AutoDiscover process manually. I speak of course of the externally hosted website.

This situation is relevant for at least two of my clients, one using Office 365, the other still using an Exchange 2010 environment, and I have no reason to think I am alone in this.

The scenario is that the web server a client has their public website running on also accepts IMAP connections. When this is true, and you attempt to AutoDiscover an Outlook account to your Exchange Server, AutoDiscover will find the IMAP service at the root of the domain. It will then attempt to configure Outlook to talk to that instead of moving on to talk to your Exchange Server.

The solution for this is to use the registry to control Outlook's behavior, and the method I have used is to set the PreferLocalXML DWORD entry. Configuring this requires setting at least two registry entries and creating an XML file, which has to contain the AutoDiscover URL for that specific domain.

For example if your domain was using Office 365, your XML may look like this:

Or for another domain name, it may look like this:

Never one to shy away from the chance to automate something, I created a small script to do this for me. The script takes input in the form of a domain name, configures the PreferLocalXML DWORD, the REG_SZ (string) for the domain name, and sets up the XML file.

It also then sets up the other registry entries and disables the ones we do not want to use, leaving only PreferLocalXML, HTTPRedirect, and HTTPSAutoDiscoverDomain enabled.

Configure AutoDiscover in the registry

Configure AutoDiscover in the registry

This script runs in the logged-on user's context and is per user. If you have multiple people sharing the same computer, you would need to run it for all of them. However, it will not recreate the XML file if it is already present.

The last thing to mention is the path where these registry edits occur. This relates to the version of Office installed on your computer.

Using a query, we can determine all the versions installed based on their version number. Then we select the newest version and make our AutoDiscover edits for that version only.

Of course, making a few registry edits is trivial, and even creating an XML file would take a few seconds. But using this script allows me to set up the settings quickly and correctly each time with minimal effort.

Win the monthly 4sysops member prize for IT pros


Related Posts


Leave a reply

Your email address will not be published. Required fields are marked *



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2017

Log in with your credentials


Forgot your details?

Create Account