The Attribute, the Myth, the legacyExchangeDN

Exchange 2010 LogoAfter some recent Exchange troubleshooting I decided to do a small write-up on an attribute most people working with Exchange know about, the infamous exchangeLegacyDN.

History
In the early days of Exchange, the NT world was flat. Exchange utilized its own hierarchical X.400 directory service and to uniquely identify objects it used an attribute called obj-Dist-Name. It contained a constructed value using elements like organization, containers and the canonical name to construct the entry, e.g. /o=Contoso/ou=EMEA/cn=Recipients/cn=User.

Then came the introduction of Active Directory with the release of Windows Server 2000. In AD, while you could refer to object using obj-Dist-Name’s counterpart distinguishedName, objects are primarily identified using their static Global Unique Identifier (GUID). The distinguishedName is constructed using relative names like the OU and CN, e.g. CN=User,OU=EMEA,DC=contoso,DC=com. Because it’s dynamic, the distinguishedName will change when you move or rename the object.

For backward compatibility with older versions of Exchange, clients or 3rd party tooling the legacyExchangeDN attribute was introduced which was to provide a unique key for the Exchange object. A process called Recipient Update Service (RUS) was responsible for populating the legacyExchangeDN value using the current location in conjunction with the given name (CN). Since Exchange 2007, legacyExchangeDN is set at creation time or can be updated manually using the Update-Recipient cmdlet. When a conflicts are detected, a unique value was constructed by adding a GUID-like series of hex characters.

When public folders are used for publishing Free/Busy information, the legacyExchangeDN was used to determine in which public folder the information was published. More information on this in an earlier blog here.

Typical values for the legacyExchangeDN attribute are:

  • Pre-Exchange 2007:
    • /o=Contoso/ou=First Administrative Group/cn=Recipients/cn=UserA
  • Exchange 2007 and later:
    • /o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA

Until Exchange 2010 SP1 Rollup 6 the legacyExchangeDN value was predictable, but as of this Rollup (and Exchange 2013), 3 random hex characters are added for uniqueness.

Exchange Internal Addressing
While SMTP addressing is the de facto e-mail addressing standard, Exchange internally still uses an X.500 addressing scheme. Using X.500 implies that an X.500 is required, which is why mail objects in an Exchange organization such as mailboxes, require a properly populated legacyExchangeDN.

The most encountered symptom of not having properly populated or unpopulated legacyExchangeDN attributes is failure of e-mail delivery or transport, which I’ll elaborate on a bit below. I’ll mention it again: legacyExchangeDN is required, unlike some Exchange admins I overheard a while ago when they were looking for the cause of several NDRs discussing SMTP was used so it should be ‘no problem’.

IMCEA and IMCEAEX
When sending a message, the sender and recipient are checked against the Global Address List (GAL). When it can’t find a match in the GAL, IMCEA encapsulation is used which stands for Internet Mail Connector Encapsulated Addressing. An IMCEA encapsulated address looks like:

IMCEAEX-_O=CONTOSO_OU=First+20Administrative+20Group_cn=Recipients_cn=philip@contoso.com

A trailing “EX” at the end of IMCEAEX indicates that a non-SMTP address was encapsulated. The used SMTP domain “contoso.local”  is taken from the GAL object unless the lookup failed; in that case the forest DN is used.

Migrations and Co-existence Issues
Clients like Outlook cache information like the legacyExchangeDN for name lookups (the infamous name cache or .nk2 files). It will also store the legacyExchangeDN (PR_EMAIL_ADDRESS) with e-mail item. This is used when replying to old e-mail and which is why you’ll see X.500 addresses when you open the e-mail outside of the organization.

While using the legacyExchangeDN makes your client insensitive to e-mail address changes, name changes etc. it will provide a (small) challenge when for example a mailbox is moved to a different forest (or to or from Office 365 for that matter) as it will get a new legacyExchangeDN value.

To attach those old legacyExchangeDN addresses to an object in the new environment, add an X.500 entry to the proxy addresses (X.500 refers to the protocols built on the X.400 standard), e.g. X500:/o=Contoso/ou=First Administrative Group/cn=Recipients/cn=UserA.

When the target environment already contains a mail-enabled contact, ideally you want to preserve the current legacyExchangeDN as x500 address on the mailbox object (depending on if the solution transforms the contact of creates a new object). This way, users in the target environment won’t be getting NDRs because their legacyExchangeDN became invalid by the move, e.g.

Delivery has failed to these recipients or groups:
Philip Mortimer
The e-mail address you entered couldn’t be found. Please check the recipient’s e-mail address and try to resend the message. If the problem continues, please contact your helpdesk
Diagnostic Information for administrators:
Generating Server: L13L14EX1.fabrikam.local
IMCEAEX-_O=CONTOSO_OU=First+20Administrative+20Group_cn=Recipients_cn=philip@contoso.com

In this case, the user tried to reply using the X.500 address /O=Contoso/OU=First Administrative Group/cn=Recipients/cn=philip. contoso.local (later more on address conversion).

If preserving the contact’s legacyExchangeDN isn’t possible, you could collect existing legacyExchangeDN values and stamp them as X500 address on the mailbox before or after moving it.

Unpopulated legacyExchangeDN
As explained earlier, the legacyExchangeDN is required for mail-enabled Exchange objects, including mail-enabled contacts. I’ve seen contacts with unpopulated legacyExchangeDN attributes in situations where the GAL Sync tool was misconfigured.

Sending an e-mail to such a contact will also result in an NDR:

Delivery has failed to these recipients or groups:
Francis Blake
The e-mail address you entered couldn’t be found. Please check the recipient’s e-mail address and try to resend the message. If the problem continues, please contact your helpdesk
Diagnostic Information for administrators:
Generating Server: L13L14EX1.fabrikam.local
IMCEAEX-_O=NT5_ou=00000000000000000000000000000000_cn=4D182F9E133B564F88CA6A86830D4314@contoso.local
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

Solving this situation depends on the solution used. Basically, GAL Sync or Identity Management products directly manipulate AD objects, bypassing the regular process like provisioning Exchange attributes. Therefor, they should call “Update-Recipient” to provision Exchange attributes like the legacyExchangeDN or any e-mail addresses to be set via E-Mail Address Policies.

Microsoft’s Identity Management product, ForeFront Identity Manager’s, contains a GAL agent which has a setting which will trigger the provisioning of Exchange attributes. Make sure this setting is enabled and you provided a valid URI:

image

Reporting
Instead of waiting for users to report on (internal) NDR messages, you can consult the transport logs for failed delivery messages. For example, to report on all NDR messages of the last 7 days on all transport servers, you can run the following cmdlet from the Exchange Management Shell:

Get-TransportServer | Get-MessageTrackinglog -EventID FAIL -Start (Get-Date).AddDays(-7) -ResultSize Unlimited | Where {$_.Recipients -match "^IMCEAEX*"}

NDRReportReconstructing legacyExchangeDN
If for some reason you need to reconstruct the X.500 address using the information from the NDR message, support article KB2807779 contains a short instruction or utilize the small interactive script below to convert the reported IMCEAEX address to an X500 entry:

$Addr= Read-Host "Enter full IMCEAEX address:"
$Repl= @(@("_","/"), @("\+20"," "), @("\+28","("), @("\+29",")"), @("\+2C",","), @("\+3F","?"), @("\+5F", "_" ), @("\+40", "@" ), @("\+2E", "." )) 
$Repl | ForEach { $Addr= $Addr -replace $_[0], $_[1] } 
$Addr= "X500:$Addr" -replace "IMCEAEX-","" -replace "@.*$", "" 
Write-Host $Addr

Feedback
Feedback is welcomed through the comments. If you got scripting suggestions or questions, do not hesitate using the contact form.

29 thoughts on “The Attribute, the Myth, the legacyExchangeDN

  1. On my very first migration from Exchange 2000 on-premises, to Office 365 about 1 and half year ago, I run into similar issue 🙂 … I didn’t use dirsync (not supported from Ex2000) nor used migration tool provided by Office 365, so I just recreated 20 mailboxes on the tenant, and decided to migrate old content by just copying and pasting messages from on premises mailbox to cloud mailbox with both mailboxes on the same outlook profile. The result: no-one could reply to old email sent from colleagues because on cloud mailboxes x500 attribute was not created on proxy addresses. Solution was adding x500 proxy address to each mailbox (manually!) 🙂

  2. Pingback: NeWay Technologies – Weekly Newsletter #55 – August 8, 2013 | NeWay

  3. Pingback: Info about legacyExchangeDN and related trouble | ril3y

  4. Pingback: Notes on X.400, X.500, IMCEA, and Exchange « prgmr.io

  5. Pingback: legacyExchangeDN Woes |

  6. Good summary. You think any change to the script may be required with the current (Exchange 2013) addition of the GUID to the legacyExchangeDN?

  7. Pingback: EighTwOne 2014 Stats | EighTwOne (821)

  8. Can you suggest a fix, outside of deleting everyone’s auto-complete/cached email address’s, where an external Exchange GAL Contact e.g. ‘Contoso1’ with email address contoso1@outlook.com was renamed and also given a completely different email address i.e. ‘Contoso’2 and contoso2@outlook.com and a new Contact was created for Contoso1, that would fix an issue where a users cache looks correct and is showing Contoso1 but emails are still ending up with Contoso2? If that makes sense. Problem is Contoso1 is very very widely used and should never have been changed.

    Exchange 2010/Outlook 2010 environment.

  9. Good. Write-up. Does anyone know how to fix an issue when mailboxes are migrated to Office 365 from Exchange 2010. Hybrid enviroment, DirSync (FIM) etc. The mailbox objects in 365 contain the LEDN of the migrated mailbox from on-premise, however when doing a reply to all from an email received prior to the migration, the senders email address is included (reply all includes self). I think this is connected to the LEDN / X500 stamping but cannot find a fix.

  10. Hi Michel , this article is very useful and great, but As I am new with exchange stuff, I need your help, we have a mixed environment where some users are in our on-premise exchange 2010 and some of them are in the Rackspace hosted solution, when I move the users from Rackspace to on premise then the users can’t send replies to my old emails and it is surely due to exchangelegacyDN , how can I solve these issues with my users. Thank you,

    • If possible, extract the LegacyExchangeDN from Rackspace environment and apply as x500 to your on-prem environment. If not possible, extract the legacyExchangeDN from the messagetrackinglogs, NDR or other means (see article for how to ‘convert’), and apply as x500 to your on-prem environment.

  11. I do not understand this topic at all. where does a beginning exchange administrator who has to do a forest migration find answers for how to fix? I’ve been trying to perform forest to forest migration for a week now without any success of any kind.
    The critical property ‘LegacyExchangeDN’ is missing in the UserMailbox object ‘Mailtest4’.

  12. Can someone tell me which service in Exchange 2013 updates the legacylegacyExchangeDN . I know there is command to update it , however i want to know which service in Exchange 2013 automatcically updates it

  13. Please confirm what is the CN value for legacyexchangeDN as i have noticed it is not matching with CN value of the object for most of the user objects

    /o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=????

    • Those values used to match, but since Ex2010SP1RU6, a 3-character hex suffix is added (to make the legacyExchangeDN ‘unique’). Note that only applies to objects created after migrating to this version in your environment, so you may have a mix as your environment went from version to version.

      • Thanks Michael , we are facing issue in getting this populated automatically and i believe in exchange 2013 there is no separate service which runs and populates the field , It is done using the update-recipient command only . We were thinking to forcefully update the field based on the attribute format of legacyexchangeDN. do you know any other way to populate the value automatically .

        • Not in a supported way, yet you may perhaps adjust the provisioning process (e.g. Cmdlet Extension Agent for New-Mailbox, Enable-Mailbox) to post-configure legacyExchangeDN. Do check on its uniqueness though.

          • I agree however we use FIM to bring in objects and as you might be knowing FIM works on attributes values rather than running powershell commands .

            • It helps if you add details like this 🙂 You can do the same for Update-Recipient, which is called by agents like the GalSync MA, or custom (code) the MA to prepopulate this attribute. Again, note you might be walking the unsupported path. Why do you want to align the legacyExchangeDN CN part with the CN in the first place? To have it look ‘proper’?
              On another note, and perhaps more supported, is you could schedule a script to detect unmatched CN’s, configure the legacyExchangeDN the way you want, preserving the old one as an x500 proxy address. Most desirable option depends on the requirements of the organization, of course.

  14. Pingback: Что такое IMCEA и IMCEAEX, а также x.400 и x.500 — rusmandalay

  15. Pingback: Приключения с переключением ящика | Булдаков.ru | Записки сисадмина

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s