FYI - Exchange 2010 and Outlook refusing to connect to a mailbox due to LegacyExchangeDN - RESOLUTION. RRS feed

  • General discussion

  • We ran into a scenario where a user could continue to use OWA to connect to their mailbox after it had been migrated from Exchange 2007 to Exchange 2010, but Outlook and any MAPI client whatsoever (BlackBerry, MFCMAPI, etc.) refused to work.

    There are a number of posts out there troubleshooting this sort of thing, but none of them fit our scenario after going through them all. I randomly noticed the following error logged on one of our CASs repeatedly when we tried to open the mailbox ourselves:

    Log Name:      Application
    Source:        MSExchange Autodiscover
    Date:          9/30/2011 9:10:58 PM
    Event ID:      1
    Task Category: Web
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Unhandled Exception "Multiple objects with legacy DN /o=Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Joe.User were found."
    Stack trace:    at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientSession.FindByLegacyExchangeDN(String legacyExchangeDN)
       at Microsoft.Exchange.Autodiscover.Providers.Outlook.OutlookAutoDiscoverProvider.GetADRecipientForRequestedUser(ADRecipientSession adRecipientSession, ADRecipient callerRecipient)

    This led me the following blog post:

    Low and behold we had a Contact that had an X500 address for this user's mailbox. This was a result of part of a group migrating off of our email system, and a handful of users staying for whatever reason and no one removing the Contact.

    Exchange 2007 never cared because as far as I knew Exchange only looked for an X500 address during transport if it couldn't find a LegacyExchangeDN match. Apparently though having this lingering X500 address out there really upsets Exchange 2010 to the point where the MOMT access is broken but OWA isn't. Removing the offending X500 entry on the contact resolved the problem.

    We weren't sure where else we might have this problem and wanted to be proactive about finding and removing X500 entries duplicating existing mailbox LegacyExchangeDNs, so we wrote a script to find any Exchange recipient with an X500 address pointing to an existing mailbox. I tried to post this on the afore mentioned blog, but I couldn't get it to take so I thought it would post it here in case anyone else ever runs into this issue:

    # Gather all mailboxes.
    $AllMailboxes = Get-Mailbox -ResultSize:Unlimited
    # Check the LegacyExchangeDN of each mailbox.
    $AllMailboxes | Foreach {
     # Build the X500 address pattern match by pre-pending "X500:" in front of the mailbox LegacyExchangeDN.
     $X500Address = "X500:" + $_.LegacyExchangeDN
     # Perform a search for any recipient object with that X500 address. NOTE: This is not Exchange 2010 PowerShell remoting friendly.
     $X500Check = Get-Recipient -Filter {EmailAddresses -eq $X500Address}
     # If there was a match found, write it to the screen. This can be modified to be any type of desired output.
        If ($X500Check) {
      Write-Host $X500Check.PrimarySmtpAddress " - " $X500Address

    NOTE: the script will not run in the traditional Exchange 2010 EMS - PowerShell remoting (whose limitations floor my team) in Exchange 2010 doesn't like -Filter {EmailAddresses -eq $X500Address}, and you can't change it to -Filter "EmailAddresses -eq '$X500Address'" because names like "L'Tanya" make it error out. So run it either through a non-remoted Exchange 2010 powershell session, or if you have Exchange 2007 run it from that EMS.

    It really is unclear why Exchange 2010 is having a major problem with the extra X500, and quite frankly this could cause issues for future migrations down the road as we pre-create the contacts for users migrating off our system, as we won't be able to copy their mailbox LegacyExchangeDN to an X500 address proactively w/o breaking user mailbox access. We will probably open a bug on this at some point in the future.

    Saturday, October 1, 2011 3:56 PM

All replies