Autodiscover Issue - Untrusted Multi-Forest Sharing the Same Email Address Space
Hi everyone, I have an Auto Discover Service issue. In this organization, there are multiple untrusted forests but their email addresses are sharing the same DNS name. (Below, I will use two geographic sites to explain.) In the main site, the Exchange 2007 has Auto Discover Service enabled (for Outlook Anywhere auto-configuration purpose) but they are using Public Folder for Free/Busy information because they still have many Outlook 2003 users. Their email addresses are @thiscompany.com. In another small site, they are running Exchange 2003 and using Public Folder for Free/Busy information. Everyone in this site has two email addresses, @smallsite.thiscompany.com and @thiscompany.com (PrimarySMTP). All the incoming emails go through the main site. And because on Exchange 2007 server, the @thiscompany.com is defined as "Internal Relay" accepted domain and a send connector is configured to relay @thiscompany.com emails with unresolved addresses to the Exchange 2003, the email flow is working fine. And everything works fine at first because all users in the small site areusing Outlook 2003. But the issue starts happening after some upgraded or installed Outlook 2007 (all manualy configured). Everytime an Outlook 2007 user schedule a meeting and want to invite someone from the main site, an autodiscover prompt pops up asking for credential to autodiscover.thiscompany.com. Since the user at small sitedoes not have an AD account at the main site, the user has to select Cancel and after that a need password entry sits in the lower taskbar, with periodic balloon reminders... Does anyone know how to resolve this issue from the server side? I am thinking the Auto Discover Service can be and should be configured to provide the correct information ("the main site hasno Availability Service") to the Outlook 2007 clients that are connecting from outside your network. But I couldn't find any instructions of how to do so and don't know how this will affect the Outlook Anywhere and OWA 2007users at main site. Could anyone please let me know? Thanks in advance, Eric
December 6th, 2008 3:38am

I am working on a different but similar issue. Do you have any updates to share? My problem is that we've got a "rogue" domain sharing the same DNS space and their Outlook 2007 accounts get the pop-up you described. I think in my case however, it is not about their calendar service, as much as it is the auto configuration trying to update the Outlook profile.I'm considering informing the smaller group of users (via GPO) to use this registry setting: But I'm not sure it will completely disable the functionality. http://technet.microsoft.com/en-us/library/cc837949.aspx Disable Auto Account Setup process There is one registry setting that completely turns off the entire Auto Account Setup process. Key: HKCU\Software\Microsoft\Office\12.0\Outlook\AutoDiscover DWORD: DisableAutoStartup Values: 1 = disable the Auto Account Setup process 0 (or missing DWORD) = default Auto Account Setup process With DisableAutoStartup = 1, the auto account setup process is completely disabled and you have the same profile creation experience available in Outlook 2003. Note: You might find the following registry key on your Outlook client: HKCU\Software\Microsoft\Office\12.0\Outlook\AutoConfiguration This registry key is not in the Office Outlook 2007 source code so it is not placed there by Office Outlook 2007. This document was helpful as well: The Outlook Automatic Account Configuration (http://go.microsoft.com/fwlink/?LinkId=79065) whitepaper Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator
Free Windows Admin Tool Kit Click here and download it now
January 27th, 2009 10:22pm

wow, this is also what I've been looking for. Thanks,/* Support Engineer */
March 28th, 2009 3:46pm

Great, did it actually work for you?Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator
Free Windows Admin Tool Kit Click here and download it now
March 29th, 2009 4:34pm

we ended up putting a "bad" dns record in the rogue dns environment so that it couldnt find our services. i realize this wont work all of the time, but for us, it allowed us to move forward.Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator
March 29th, 2009 4:35pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics