Potential Autodiscover Issue During E-Mail Coexistence RRS feed

  • General discussion

  • Potential Autodiscover Issue

    Under some conditions your organization may experience Autodiscover issues while testing Microsoft Online or when establishing e-mail coexistence between your local Microsoft Exchange Server environment and Exchange Online Services.


    If your company is an Exchange Online customer and your e-mail environment meets the following conditions, you may encounter Autodiscover issues.

    1.       Your organization is using Microsoft Exchange Server 2007.

    2.       Your users are using Microsoft Outlook 2007.

    3.       Your users with Exchange Online mailboxes also have mailboxes on your on-premise Exchange Server, AND your Exchange Online user accounts have identical primary SMTP e-mail address in both systems.


    Autodiscover is a feature of Exchange 2007 that automatically connects your Outlook 2007 clients with the correct Exchange e-mail server without requiring the users to enter any Outlook configuration information.

    The Autodiscover feature keys off of the user’s primary SMTP address. For example, jim@contoso.com. If there is an SMTP address conflict, if the user’s computer is joined to an on-premise Active Directory domain, the connection to the on-premise Exchange Server will receive the highest priority.

    This situation is most likely to occur during the trial period or during an e-mail coexistence period before the users mailbox is fully migrated to the Exchange Online environment, and the on-premise mailbox is deleted.


    1.       Do not allow users with mailboxes on both systems. Delete the on-premise Exchange mailbox as quickly as possible after migrating mailbox content to Exchange Online.

    2.       Do not use the same primary SMTP address for Microsoft Online user accounts and on-premise Exchange mailboxes during the trial period.

    Work Around

    If you must have both mailboxes in use at the same time, and if you must use the same primary SMTP address for both mailboxes, use the following work-around:

    1. Install Outlook 2007 SP1.

    2. Install the Outlook 2007 hotfix described in KB KB948716.

    3. Modify the registry on each client computer:

    To modify the registry:

    1.       Click Start, click Run, and then type regedit.

    2.       Navigate to the following registry key:

    3.       Set the following values for the Value Names listed below:

    If you contact Microsoft Online Support, they can provide a .REG file to simplify this operation.

    How to Access Your E-Mail

    After on-premise Exchange Server mailboxes have been migrated to Exchange Online, the Outlook 2007 client will always connect to Exchange Online. If your on-premise mailboxes have not been deleted, you can use Microsoft Outlook Web Access to connect to your on-premise mailbox.

    How to Reverse the Work Around

    After deleting the on-premise Exchange Server mailbox, or if the user no longer has an Exchange Online mailbox, you should return the registry key to its original settings.

    To modify the registry:

    1.       Click Start, click Run, and then type regedit.

    2.       Navigate to the following registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover

    3.       Set the following values on the Value Names listed below:

    If you contact Microsoft Online Support, they can provide a .REG file to simplify this operation.


    Monday, July 21, 2008 4:19 AM

All replies

  • I have a scenario very similar to this.  Instead of my company using Exchange Online in conjunction with Exchange 2007, I am in the midst of a migration.  The source forest is Exchange 2003, the target forest is Exchange 2007.  The users being migrated are logging into their user accounts that are associated with their Exchange 2007 mailboxes.  The user accounts are pre-staged with Exchange 2007 mailboxes, because we are using Quest Migration Manager to handle the syncronization of mail data and migration.

    The specific issue that I've ran into is that it seems that when routine maintenance is being performed on the Exchange 2003 production mailbox servers, some of the users are seemingly miraculously having their outlook profiles directed at the Exchange 2007 mailboxes.  Our first thoughts were Autodiscover in the Exchange 2007 forest, so I defined an IP ACL in IIS to restrict everyone but the Exchange Administrators from having access to Autodiscover (we were the only people who were using the Exchange 2007 servers).  This did not prevent the issue of users' mailboxes being flipped.

    Anyways, I'm gonna give these registry edits a go at trying to prevent this from happening.  I'm going to use the following script I wrote as a login script.  When a user is migrated to the Exchange 2007 org they will be added to a group called "migrated" and the login script will reverse the work around.
    on error resume next
    Set objUser = CreateObject("ADSystemInfo")
    Set CurrentUser = GetObject("LDAP://" & objUser.UserName) 
    colGroups = CurrentUser.memberOf
    allowAutoDisco = "Migrated"
    inGroup = False
    'Retrieve user account group membership
    If not IsEmpty(colGroups) Then
    	for each objGroup in colGroups
    		If instr(objGroup, allowAutoDisco) Then
    			inGroup = True
    		End if 
    End If
    'Connect to the Registry
    Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
    Const HKCU = &H80000001
    strKey = "Software\Microsoft\Office\12.0\Outlook\AutoDiscover"
    DisableAutoStartup =          "DisableAutoStartup"
    PreferLocalXML =              "PreferLocalXML"
    ExcludeHttpRedirect =         "ExcludeHttpRedirect"
    ExcludeHttpsAutodiscoverDomain = "ExcludeHttpsAutodiscoverDomain"
    ExcludeHttpsRootDomain =      "ExcludeHttpsRootDomain"
    ExcludeScpLookup =            "ExcludeScpLookup"
    ExcludeSrvRecord =            "ExcludeSrvRecord"
    Disable = "00000001"
    Enable  = "00000000"
    'Determine if the registry key already exists
    KeyExists = RegKeyExists("HKCU\" & strKey)
    if KeyExists = False then
    	oReg.CreateKey HKCU, strKey
    end if 
    'Write the appropriate DWORD
    if inGroup = False Then
    	oReg.SetDWORDValue HKCU,strKey,DisableAutoStartup,Disable
       oReg.SetDWORDValue HKCU,strKey,PreferLocalXML,Disable
       oReg.SetDWORDValue HKCU,strKey,ExcludeHttpRedirect,Disable
       oReg.SetDWORDValue HKCU,strKey,ExcludeHttpsAutodiscoverDomain,Disable
       oReg.SetDWORDValue HKCU,strKey,ExcludeHttpsRootDomain,Disable
       oReg.SetDWORDValue HKCU,strKey,ExcludeScpLookup,Disable
       oReg.SetDWORDValue HKCU,strKey,ExcludeSrvRecord,Disable
    	'wscript.echo "Disabled"
    	oReg.SetDWORDValue HKCU,strKey,DisableAutoStartup,Enable
       oReg.SetDWORDValue HKCU,strKey,PreferLocalXML,Enable
       oReg.SetDWORDValue HKCU,strKey,ExcludeHttpRedirect,Enable
       oReg.SetDWORDValue HKCU,strKey,ExcludeHttpsAutodiscoverDomain,Enable
       oReg.SetDWORDValue HKCU,strKey,ExcludeHttpsRootDomain,Enable
       oReg.SetDWORDValue HKCU,strKey,ExcludeScpLookup,Enable
       oReg.SetDWORDValue HKCU,strKey,ExcludeSrvRecord,Enable
    	'wscript.echo "Enabled"
    End if 
    Function RegKeyExists(ByVal sRegKey)
        ' Returns True or False based on the existence of a registry key.
        Dim sDescription, oShell
        Set oShell = CreateObject("WScript.Shell")
        RegKeyExists = True
        sRegKey = Trim (sRegKey)
        If Not Right(sRegKey, 1) = "\" Then
          sRegKey = sRegKey & "\"
        End If
        On Error Resume Next
        oShell.RegRead "HKEYNotAKey\"
        sDescription = Replace(Err.Description, "HKEYNotAKey\", "")
        oShell.RegRead sRegKey
        RegKeyExists = sDescription <> Replace(Err.Description, sRegKey, "")
        On Error Goto 0
    End Function
    Friday, May 1, 2009 1:12 PM
  • I believe I may have isolated this issue to laptop users running Outlook 2007 who are not closing Outlook before putting their laptops into hibernation mode.  The next morning when they boot up, Outlook sees an issue with the network connection and for some reason queries the AD user account object (instead of autodiscover) to find it's mailbox.  When it queries the user object it finds the mail server and reconfigures the outlook profile.
    Friday, May 1, 2009 7:11 PM
  • Hello,

    This workaround has worked for the customers we have using Exchange Online in this scenario.  The migration process for us is typically to remove existing Outlook profiles, import the registry settings, then let the BPOS client auto-configure Outlook.  It then downloads the correct address book.

    Nathan Lasnoski
    Wednesday, May 20, 2009 4:11 AM
  • AirJunkie,

    Your post stole the words right out of my mouth. :)

    I am in the middle of a migration as well; exactly as you described with a sourceXch2003/targetXch2007 and using Quest tools.

    I believe we have the same problem. I tried "Workaround 3" from Quest Solution SOL51188. Basically, you create the source & target xml files locally on the client (%ProgramFiles%\Microsoft Office\Office12\OutlookAutoDiscover) and set the PreferLocalXML registry value. The results seemed initially promising, but a day later the migrated target user/wkstn (whose mailbox is still in sourceXch2003) Outlook 2007 client is once again configured to use the target mailbox--likely because of what  you just mentioned above.

    I have a question about your testing... Did your laptop users experience this issue even after you set the registry values with your script? I'm hoping not becuase this workaround might be perfect for me as well.
    Wednesday, June 17, 2009 9:55 PM
  • Same issue with Outlook 2010 and hosted exchange 2010 from Rackspace. Any updates on how to do this with a newer setup?


    Tuesday, October 30, 2012 9:28 PM
  • Has anyone had any success with Outlook 2010? Adding the registry keys above doesn't allow a profile to be created using AutoDiscover.


    Wednesday, May 1, 2013 4:18 PM