<

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x

NDRs and the legacyExchangeDN

Published on
62,211 Points
36,811 Views
24 Endorsements
Last Modified:
Approved
Everyone is familiar with the standard SMTP email address format (user@domain.com). SMTP is a standard that allows e-mail to be exchanged between e-mail servers of different types and vendors, across the internet. What you may not know is that Exchange doesn’t use SMTP addresses to route e-mail internally. Instead, Exchange relies on an address type called X500 to route messages. When Exchange receives a message addressed to an SMTP address, one of the first things it does is lookup that address in the directory and resolve it to an X500 address. This use of X500 addresses in Exchange is important to understand as it can lead to unexpected NDRs if you are not aware of how it works.

X500 History


The use of X500 addresses in Exchange dates back to the pre-Exchange 2000 days when Exchange had its own directory. In Exchange 5.5 and previous versions, Exchange used the X400 protocol. X400 uses the Distinguished Name of an object in the LDAP directory. The problem with using a Distinguished Name is that if the object is renamed or moved in the directory tree (for example to a different server), the Distinguished Name changes and this would break mail flow as the old X400 address would no longer be valid. To get around this, Exchange relied on X500 addresses to act as aliases and hold the old X400 address. This allowed mail to be routed properly even after objects were moved or renamed.

legacyExchangeDN


Starting with Exchange 2000, Exchange was switched to using Active Directory instead of having its own directory. For backward compatibility with previous versions of Exchange, Exchange 2000 and subsequent versions of Exchange (up to 2010 as of this writing) continue to use the X500 address format for message routing. An attribute was created in Active Directory called “legacyExchangeDN” to hold an address in X500 format that Exchange 5.5 could understand. This is the “master” address on all mail-enabled objects in Exchange. Like in Exchange 5.5, it allows mail to be delivered to the proper location even if the object is moved, renamed, or even if the SMTP address is changed.

The format of the legacyExchangeDN is:
 /o=Organization/ou=Exchange Administrative group/cn=Recipients/cn=user

Open in new window


Outlook and legacyExchangeDN


Since the legacyExchangeDN is the “master” address on all mail-enabled objects in Exchange, Outlook actually addresses internal messages using the legacyExchangeDN. You will notice that when sending internal e-mails, Outlook will resolve the object from the global address book and show the display name of the object. Behind the scenes, Outlook is actually looking up the legacyExchangeDN and using that to address the message. Even if you put the SMTP address of the object in the ”To” field, Outlook will resolve that to the legacyExchangeDN before sending. When you send an email, Outlook adds the recipients to the Outlook cache, which is used for the auto-complete as you start typing an address. The cached copy of internal recipients contains the legacyExchangeDN value as the object’s address. When you reply to any messages in your Inbox, which were sent from an internal mailbox, you are replying to the legacyExchageDN value.

How legacyExchangeDN causes NDRs


NDRs are caused by the legacyExchangeDN because a lot of administrators assume that Exchange uses SMTP for internal routing and thus assume that as they move SMTP addresses from object to object, mail delivery will work correctly. There are two common scenarios where this occurs. The first is when a mail-enabled object is deleted from Active Directory and a new object is created with the intention to take its place. An example of when this might occur is if a contact exists to route email to an external mailbox and that mailbox is now being brought into Exchange. The administrator deletes the contact, creates the new mailbox with the same display name and ensures SMTP addresses that were on the contact are added to the new mailbox. Not long after, users start complaining about receiving the following NDR:
Delivery has failed to these recipients or distribution lists:

jjmck
The recipient's e-mail address was not found in the recipient's e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.
  _____  

Sent by Microsoft Exchange Server 2007

Diagnostic information for administrators:

Generating server: exchange01.domain.local

IMCEAEX-_O=COMPANY_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=jjmck@domain.local
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

The problem is that Outlook has the old object cached. When users start typing the name of the recipient, Outlook auto-completes the recipient from the cache.  Since the cache contains the legacyExchangeDN of the old contact and the legacyExchangeDN of the new mailbox is different, Exchange will not be able to find the recipient and generates an NDR as a result.

The second common scenario is when you do a mail migration between organizations and you are not using migration tools that either automatically add the old legacyExchangeDN from the source mailbox to the destination mailbox as an X500 address, or rewrites the recipient addresses as SMTP during the migration of mail. A migration method where this commonly occurs is when PST exports are used to migrate mail from one organization to another. When users reply to mail migrated in this manner, it will cause an NDR as Outlook is using the legacyExchangeDN as the recipient’s address and the legacyExchangeDNs from the source organization do not exist in the target organization.

How to Prevent legacyExchangeDN NDRs


NDRs can be prevented by adding the legacyExchangeDN value of the original directory object as an X500 address on the new object. If you are planning on deleting an object and replacing it with another object, such as the example of replacing a contact with a mailbox discussed above, you would first need to get the legacyExchangeDN of the contact. You can do that by running the following Powershell command:

Get-MailContact “John Smith” | fl legacyExchangeDN

Open in new window


You would then take the value of the legacyExchangeDN and add it to the new mailbox as an X500 address. You can do this in EMC by adding a Custom address on the email addresses tab or you can run the following Powershell script:

# Enter user’s email address below
$UserEmail = 

# Enter legacyExchangeDN below
$legacyExchangeDN =

$ProxyAddresses = (Get-Mailbox $User.Email).emailadddresses)
$ProxyAddresses += [Microsoft.Exchange.Data.CustomProxyAddress]("X500:$($LegacyDN)")
Set-Mailbox $UserEmail –EmailAddresses $ProxyAddresses

Open in new window


If you are unsure of legacyExchnageDN value of the original object, you can reconstruct it from the information in the NDR:

IMCEAEX-_O=Company_OU=Exchange+20Administrative+20Group_cn=Recipients_cn=user@company.com

Would translate to a legacyExchangeDN of
/o=Company/OU=Exchange Administrative Group/cn=Recipients/cn=user

You can also use MFCMAPI to open messages in Exchange mailboxes and view the PR_SENDER_EMAIL_ADDRESS property for the legacyExchangeDN value of recipients.
Once you have added the legacyExchangeDN of the old object to the new object, mail will be delivered to the new object when Outlook users reply to emails sent from the old object or use the cached object when creating new messages.

Conclusion


Hopefully this article has given you a better understanding on how Exchange routes e-mail internally and the importance the legacyExchangeDN attribute plays in message delivery. By better understanding this concept, you can plan for changes in your address book during migrations and deletion and recreation of objects. If you ensure you maintain the legacyExchangeDN value as an X500 alias when you migrate from old to new mail-enabled objects, you will ensure message delivery stays consistent and eliminate annoying NDR messages.
24
Comment
11 Comments
LVL 37

Author Comment

by:Jamie McKillop
Hello,

Thanks for your feedback on my article. I've made the suggested changes.

JJ
0

Expert Comment

by:lebourreau
JJ,

From your error message above would the resulting X500 address be:

/o=COMPANY/OU=EXCHANGE ADMINISTRATIVE GROUP 28FYDIBOHF23SPDLT/cn=Recipients/cn=jjmck@domain.local

or would it be

/o=COMPANY/OU=EXCHANGE ADMINISTRATIVE GROUP 28FYDIBOHF23SPDLT/cn=Recipients/cn=jjmck

Just to clarify.  

Thanks,
Ben
0
LVL 37

Author Comment

by:Jamie McKillop
Hello Ben,

It would be /o=COMPANY/OU=EXCHANGE ADMINISTRATIVE GROUP 28FYDIBOHF23SPDLT/cn=Recipients/cn=jjmck

That is assuming your admin group is called "EXCHANGE ADMINISTRATIVE GROUP 28FYDIBOHF23SPDLT" and not just "28FYDIBOHF23SPDLT"

JJ
0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

LVL 76

Expert Comment

by:Alan Hardisty
Great article - long overdue for someone to write.

Yes vote from me.

Alan
0

Expert Comment

by:Klaus_Thorn
To prevent misunderstandings:

the following string in a NDR (error Mail)...

_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29
... would translate to...
/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)
Because +28 and +29 translate to ( and ), as confirmed by Microsoft in...
http://support.microsoft.com/kb/2807779/en-us
0
LVL 37

Author Comment

by:Jamie McKillop
Yes, that is correct. Thanks for point that out.

JJ
0

Expert Comment

by:mstevens625
Great post! Clear and concise explanation regarding the legacyExchangeDN attribute and how it affects the auto-complete cache in Outlook. Nice job.

Thank you,
Geo
0
LVL 5

Expert Comment

by:Addy Nadia
Awsume Artcile..I didt knew abut this..

thanks so much for sharing such a knowledge base article..you are a Champ !!

cheers !!
0

Expert Comment

by:Sleezed
Thanks for the article, very well written.

I'm having the same exact problem mentioned in this article, and yes after a PST migration to a new mailbox.

I've added the address of the NDR (converted) as an X500 alias as mentioned here...but the issue keeps occurring...and only from one specific user to another specific user internally. I removed the auto-complete cache and NK2 file to no avail...

I'm stuck and it's driving me crazy...this fix seems to work for everyone else. Any ideas?
0
LVL 37

Author Comment

by:Jamie McKillop
Can you post the text of the NDR as well as the x500 address you added? You can change the details to hide identifying info, just make sure you change it consistently.

-JJ
0

Expert Comment

by:Sleezed
Actually I posted a new topic on it here:

Exchange NDR X500 issue
0

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Join & Write a Comment

There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…
In this video I will demonstrate how to set up Nine, which I now consider the best alternative email app to Touchdown.

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month