So You Want To Block Exchange 2010 Autodiscover. Why Would Anyone Do That?
Summary: Shamsher Dhanoa , a Microsoft Senior Premier Field Engineer based in the US , tells us why you would want to block the ever-valuable Exchange Autodiscover feature, along with detailed steps and options on how to do it.
Microsoft Exchange Administrators may well remember setting up Outlook profiles and the “Check Names” button, and then came Autodiscover which simplified the Outlook profile creation process. It also does other things like tell Outlook where to go for useful stuff including Free/Busy, Out of Office, and Offline Address Book information. In the screenshot below you can see the result of the Outlook “Test E-Mail AutoConfiguration” task (names have been redacted to protect a corporation that specializes in the procurement of weapons-grade hardware for needy coyotes).
Why would you want to block autodiscover?
So why would anyone want to block all this Autodiscover goodness? I didn’t know but recently found out. It looks like there are a fair number of cross Organization Exchange migrations being done via non-Microsoft migration tools that have a legacy Exchange 2003 mailbox and a new Exchange 2010 mailbox coexisting. An example of this is the Quest Migration Manager for Exchange.
Typically, the legacy and new Exchange Org will be linked by dedicated non-internet routable namespace connectors. For example: @Exchange2010.local and @Exchange2003.local. Every Exchange 2003 mailbox gets an extra e-mail address @Exchange2003.local and, correspondingly, every Exchange 2010 mailbox gets an extra @Exchange2010.local address.
At the start of the migration – Exchange 2010 is populated with pre-created empty mailboxes for everybody - this is the Directory Synchronization phase. The empty mailboxes have their targetAddress attribute populated with the users @Exchange2003.local SMTP address. This means if a message hits Jon’s empty Exchange 2010 mailbox it bounces off to the Exchange 2003 mailbox specified in the targetAddress (Jon@Exchange2003.local). Jon of course has Outlook configured to open his non-migrated Exchange 2003 mailbox.
At any time during the coexistence period there are 2 mailboxes for each user. Non-Migrated users on Exchange 2003 look at the Exchange 2003 Address Book. Migrated users on Exchange 2010 look at the Exchange 2010 Address Book.
When Jon is migrated the targetAddress attribute on Exchange 2010 is cleared and targetAddress on his OLD Exchange 2003 mailbox is populated with Jon@Exchange2010.local. This means when his buddies on Exchange 2003 email him, the message is automatically forwarded through the SMTP connector to his spanking new Exchange 2010 mailbox. If Jon wants to email a non-migrated user he sends mail to the Exchange 2010 mailbox he sees in his Address Book and it redirects via targetAddress to the non-migrated 2003 mailbox.
So what does this have to do with Autodiscover? Nothing yet, but remember there are 2 mailboxes for every user. And Outlook 2010 is pulling towards Exchange 2010 like a beagle to bacon. In 2003 the spacecraft “Beagle 2” was sent to find life on Mars – appropriately it got lost. I had 2 beagles which I also frequently lost. But nevermind, Autodiscover has nothing to do with beagles. However, what if you as an Exchange administrator strolled into the office one Monday morning to find that 10,000 Outlook clients had reconfigured themselves to point to Exchange 2010 and everyone was wondering why their mailboxes were empty? 
How to Block Autodiscover
Now we’ve established that sometimes blocking Autodiscover may be a good thing in order to prevent the Monday morning Exchange admin blues, how do we go about blocking it?
Fellow Premier Field Engineer Rhoderick Milne wrote an excellent article on how Autodiscover works here: What Everyone Should Know About Microsoft Exchange Autodiscover.
From this, we see that Outlook will try to use:
1. the SCP record for Autodiscover
2. the standard DNS namespaces:
- https://<smtpdomain>/Autodiscover/Autodiscover.xml
- https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
- https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
3. SRV record query for _autodiscover._tcp.<smtpdomain>
We can block this default behavior by deploying the below regkeys:
- HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeSCPLookup = 1
- HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeHttpRedirect = 1
- HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeHttpsAutodiscoverDomain = 1
- HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeHttpsRootDomain = 1
- HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\ExcludeSrvRecord = 1
This works great and you can see the results in the Outlook AutoConfiguration test screenshot below.
Registry keys can also be pushed out via GPO, however some environments may not have an established or mature GPO infrastructure, so another solution recommended by some vendors is to place a DENY on the SCP objects in AD and just not publish the DNS records until the migration coexistence is complete. As shown below, this is possible via ADSIEdit (once again please disregard the reference to secretive corporations dedicated to the apprehension of remarkably rapid roadrunners).
An LDAP query as a blocked user will show no Exchange SCP objects returned.
Remember: this is not a Microsoft recommendation but it does appear to work – results may vary, Caveat emptor, contents may settle during shipment, if symptoms persist … and so on.
Now Autodiscover is disabled by all known methods to prevent non migrated clients from flipping their profiles to 2010. But what about migrated Outlook clients?
Migration tools from vendors other than Microsoft typically have a client side agent that will automatically trigger and update the Outlook profile to the new migrated mailbox so that part is good – but what about Autodiscover? Without Autodiscover they may find that Out of Office, free/busy and MailTips are mysteriously malfunctioning, so we need to undo the Autodiscover blockers as soon as users are migrated. Hopefully we have GPOs and can just remove migrated users from a policy to achieve this.
One last note - even with the blockers above in place, a way for Outlook to switch to the new mailbox is the value of the users msExchHomeServerName attribute. Consider the scenario below where an old AD/Exchange 2003 forest is being decommissioned. If Jon’s Exchange 2003 server becomes unavailable at any time, Outlook may try to repair the profile, check the msExchHomeServerName attribute and switch to Exchange 2010.
This can be prevented by using the PreferLocalXML registry key to point to an XML file that in turn hardcodes Outlook to look at Exchange 2003.
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover\PreferLocalXML = 1
There is more information on deploying PreferLocalXML on Rhoderick Milne’s blog. There are a few options for blocking Autodiscover. For my particular situation the PreferLocalXML regkey in addition to the regular recommendations of ExcludeSCPLookup, ExcludeHttpsRootDomain, ExcludeHttpsAutoDiscoverDomain, ExcludeHttpRedirect, and ExcludeSrvRecord were necessary.
Written by Shamsher Dhanoa ; Posted by Frank Battiston , MSPFE Editor
Comments
Anonymous
May 02, 2013
Nice article Shamsher!Anonymous
June 10, 2013
Nice write-up, looks familiar. :)Anonymous
September 05, 2013
Very interesting, come across this with Quest before, though the autodiscovery was still enabled and causing all sorts of issues with shared mailbox / calenders as we had a influx of users reporting "empty" inboxes and duplicated email accounts appearing then nothing working. We came up with a work around to refer users affected to webmail where they were still on the migrating servers until the process was completed. Useful thing to know - thanks.