Exchange and the LegacyExchangeDN Problem

KB ID 0001468


Why do we have the Exchange LegacyDN? It’s a throwback, from a time when we had our users, and our mail users in different databases. Below you can see the ExchangeLegacyDN for this Exchange on-premises user;

/O=First Organisation/OU=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn={something-user-specific}

Who cares? Well they are still important, if you send an internal email (to someone in the same Exchange Organisation). Exchange uses this address NOT the SMTP address which you would expect. Also Microsoft Outlook has a habit of caching this address and NOT the SMTP address. Normally this is not a problem, UNTILL you migrate your mail somewhere else, then the internal cached ExchangeLegacyDN addresses are now incorrect. (See error message below).

How Does Migrating To Office 365 Handle This?

If you do a Hybrid Exchange Migration with Azure AD sync, this is all ‘fixed’ in the background for you, When you first get your AD user ‘synced’ (i.e before you migrate the mailbox) you get an X500 address that’s just used in O365.

Then once the mailbox is migrated the users gets the ExchangeLegacyDN copied across as an additional X500 Address.

In fact if you repeat the command we did at the very start, you will see the on-prem user no longer has an ExchangeLegacyDN

Note: As pointed out, (below) you can run ‘Get-Remotemailbox “Pete Long” |  FL LegacyExchangeDN‘ to locate mailboxes not hosted on the mail server you are working on.

LegacyExchangeDN Problems

You will see problems ‘Post Migration‘ to another domain, to a newer version of Exchange, or if you use a third party tool, to migrate your users to Office 365, (which is just another domain to be honest).

If your users attempt to send an email to a ‘cached’ address, they will get an error that looks like this;

More Info for Email Admins
Status code: 550 5.1.11

The recipient email address is a LegacyExchangeDN address, which isn’t used by the Office 365 service. You might see this error if you’ve migrated your organization’s email from on-premises to the cloud, or if your organization has a hybrid configuration and you synchronize your on-premises directory with Office 365. If clearing the recipient Auto-Complete List from the user’s Outlook or Outlook on the web doesn’t solve the problem, try to clear the related LegacyExchangeDN address from your on-premises Active Directory. Then synchronize the directory again.

For more information, see Fix email delivery issues for error code 5.1.11 in Office 365.

Original Message Details

Created Date:     06/09/2018 15:37:37

Sender Address:

Recipient Address:            IMCEAEX-_O=PNL_OU=First+20Administrative+20Group_cn=Recipients_cn=Bob+2EGSmith@GBRP265.PROD.OUTLOOK.COM

Subject: CRS Update

Error Details

Reported error:  550 5.1.11 RESOLVER.ADR.ExRecipNotFound; Recipient not found

You can either tell your users to run (within Outlook) File > Options > Mail > Send Messages > Empty Auto-Complete List.

Or try fighting with your users NK2 Files, (if you are on older versions of Outlook).

Outlook Autocomplete / Nickname / Nk2 file

Or you can export all the ExchangeLegacyDN addresses from your source domain, (in x400 format), convert them to x500 format and import them into your new domain as an additional ProxyAddress, that will get replicated to Office 365, or understood by your newer version of Exchange. (NOTE: If you are running AzureAD Sync you import them into the on-prem domain and let the changes synchronise to Office 365.)

Export LegacyExchangeDN Addresses (Source Domain)

On a DC or a machine that you have imported the Active Directory module;

Get-ADUser -SearchBase “DC=YOUR-DOMAIN,DC=COM” -Filter * -Properties SamAccountName,legacyExchangeDN | Select-Object SamAccountName,legacyExchangeDN | Export-CSV C:\Temp\Exported-LegacyDN.csv -NoTypeInformation

Import LegacyExchangeDN Addresses (Target Domain)

Save the following as Import.ps1 then run the script;

Import-Module ActiveDirectory
$Input = Import-CSV C:\Temp\Exported-LegacyDN.csv
ForEach ($ADUser in $Input){
if ($ADUser.legacyExchangeDN){
Set-ADUser -Identity $ADUser.SamAccountName -add @{proxyAddresses=”X500:$($ADUser.legacyExchangeDN)”}

Related Articles, References, Credits, or External Links


Author: PeteLong

Share This Post On


  1. I just wanted to let you know that the time you put in to your content is helping others. Thank you for your explanation of the issue. I had a user receiving these NDRs, and he was getting frustrated because he couldn’t seem to determine when the emails would get delivered and when they wouldn’t. Thanks to this article I understand what’s happening behind the autocomplete entry, and I was able to give my end user an effective work around.

    Post a Reply
    • Thanks Patrick: Feedback like this, makes it all worthwhile 🙂


      Post a Reply
  2. Thank you so much Pete, this is very very helpful. Appreciate your efforts, this helps at least one person like me .

    Post a Reply
  3. Your solution worked, very good article.
    You answered my questions before I could ask them.

    Post a Reply
  4. Thanks for the article. One correction, your get-mailbox command failed to find you because it’s no longer hosted by that mail system. If you run

    get-remotemailbox “Pete Long” | fl legacyexchangedn

    it should find it.

    Post a Reply
  5. I got migrated users which don‘t have access to the on-prem public folders anymore. When I copy the online-value of LegacyExchangeDN to the AD-proxyaddresses as new X500-address AND (sometimes) create a new Outlook-profile (after waiting for replication), the users get access to the public folders.

    I have no idea where this new values for LegacyExchangeDN comes from. The original value from the proxyaddresses (when they were still on-prem) wasn‘t sychronized – obviously. And – this new value isn‘t the value of the „stand-Alone“-attribute LegacyExchangeDN.
    I will give your script a try…

    Post a Reply
  6. I have 1000 users.

    I am migrating via Hybrid only 300 hundred of them. Will the existing 700 users receive an NDR when they respond to old emails?
    It seems we are updating the x500 on exchange, but how will that work on old emails?

    Post a Reply
    • NDRs with Office365 migrations tend to happen if you use third party migration tools, if you migrate them as per my hybrid migration guide you wont have any problems.

      Post a Reply
  7. Very nice article. It workss for me. Thanks a lot for the solution.

    Post a Reply

Submit a Comment

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