The legacyExchangeDN and why it’s a pain in my ***

After a recent Exchange migration project, I can say I officially find the legacyExchangeDN attribute to be a real pain in my ***.

I spent a lot of time troubleshooting and resolving issues in regards to mail delivery due to this little attribute which has caused me to do a small write-up on it’s importance, and what to do when you screw things up like I did.

Background

We are often tasked with migrating from one email system to another, especially in regards to Microsoft Exchange. This could also come in the form of migrating from one domain name to another such as when a business changes it’s name, or when a company acquires another company.

Co-Existence

In an effort to try and make co-existence work, there are several things to consider. For example:

  • Mail Contacts
  • Distribution Groups
  • Mail Users

Once I came up with my messy and convoluted scripting through the Exchange management console, I was able to successfully collect an NDR which contained a string that looked like a bunch of jumbled verbiage. Definitely not human readable.

But, thanks to the wonders of google, I was able to find a way to not only crack the code, but re-apply my lost x500 to my user objects!
*Obscure web ad logo goes here* “I used this one simple trick and techies hate me!”

Just kidding, here is the way I resolved my issue straight from: https://support.microsoft.com/en-us/kb/2807779

The one thing that seems to always come back to bite us is when these mail contacts or mail users are converted to a mailbox, is that all of a sudden users start seeing NDR’s in Outlook barking that a recipient has been deleted and is unavailable.

This is caused by Exchange, which uses an X500 address to route mail internally. Once the attributes have been removed from a user object or contact object in Exchange, and you create a new mailbox for that user or contact, Exchange will automatically create a new X500 address and apply it to the object.

With that said, collecting the legacyExchangeDN attribute from all objects is a must from any disabled or deleted contacts and mailbox users prior to disabling or deleting them.

I found out the hard way, that when you disable a contact in Exchange prior to collecting this attribute, Exchange will wipe all Exchange related attributes including the legacyExchangeDN.

Prior to Exchange 2010 SP1 Rollup 6, the legacyExchangeDN value was something that you could predict and delineate by viewing the syntax of an enabled user. However within newer version of Exchange and within Office 365, Exchange generates a 3 random hex character which it appends to the end of the attribute.

That means you are pretty much screwed in regards to migrating between organizations if you disabled a mail enabled user or contact without collecting this attribute prior.

Or are you?

Well you still could be, but there is a chance you could find it if you make a mistake like I did.

Solving this situation comes down to reporting in Exchange. If you don’t want to wait for users to report on NDR messages, you can search the transport logs for failed deliver messages. This can be accomplished by utilizing a PowerShell query to get the message tracking log.

To create an X500 proxy address for the old LegacyExchangeDN attribute for the user, make the following changes based on the recipient address in an NDR:

IMCEAEX-_O=EXCH_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FHSDHJF23GHYED+29_CN=RECIPIENTS_CN=RON+2EMayers@contoso.com

Convert all _ to /

/O=EXCH/OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FHSDHJF23GHYED+29/CN=RECIPIENTS/CN=RON+2EMayers@domain.com

Followed by….

/O=EXCH/OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FHSDHJF23GHYED+29/CN=RECIPIENTS/CN=RON+2EMayers@domain.com

  • Replace any underscore character (_) with a slash character (/)
  • Replace “+20” with a blank space
  • Replace “+28” with an opening parenthesis character
  • Replace “+29” with a closing parenthesis character
  • Replace “+2E” with a period
  • Delete “IMCEAEX-“
  • Delete “@domain.com”
  • Add “X500:” at the beginning.

X500:/O=EXCH/OU=EXCHANGE ADMINISTRATIVE GROUP (FHSDHJF23GHYED)/CN=RECIPIENTS/CN=RON.Mayers

IMCEAEX non-delivery report when you send email messages to an internal user in Office 365: http://support.microsoft.com/kb/2807779

1. Clear the auto-complete cache file
2. Create an X500 proxy address for the old LegacyExchangeDN attribute for the user

References

Mystery of adding X500’s – Seriously awesome article MSExchangeGuru.com: http://msexchangeguru.com/2012/03/15/x500/

Fixing IMCEAEX NDRs – Missing X500 Addresses: http://www.righthandedexchange.com/2013/02/fixing-imceaex-ndrs-missing-x500.html

All in all this totally saved my life, and definitely caused me to think about how I am going to go about my deleting of contact objects.