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.

Migrating from Office 365 to Outlook 2010 – Outlook Profiles Cutover

Not many people are migrating OUT of Office 365. In fact it is just the opposite, everyone is migrating INTO Office 365.

I have had the pleasure of working on an interesting project recently. I have been working with a company that has an on-premise Exchange 2010 environment who recently acquired a company that has user mailboxes completely in Office 365. Their end goal: Move everyone out of Office 365 and into an on-premise Exchange 2010 environment.

One of the major drawbacks associated with performing a cut-over migration from both on-premise into the cloud, and from the cloud back to on-premise is the end user outlook profile.

Each Outlook profile at some point will need to be recreated to connect to Office 365 or your on-premise environment.

If this is to be done manually on every migrated user in the company, you could imagine that this could be a very time consuming process, as you would have to:

1. Create a new profile
2. Set it as the default
3. Configure it for the user

I found a way to automate this process using Group Policy to run a script to create a new, blank Outlook profile and set it as the default profile. The end user will be presented with the first time profile setup screen when opening Outlook and should be able to use Autodiscover to automatically find their new Outlook 2010 on-premise profile settings:

I created a PowerShell script  to do the dirty work:

 

This script will create a new profile called “Outlook2010” and set it as the default profile.

Outlook 2010 Registry Settings

Outlook 2013 Registry Setting

A new Group Policy Object will need to be created via Group Policy Preferences to run the PowerShell script.Leaving the GPO in place is safe to do for a few days as it will not overwrite or remove existing profiles. This will allow for people who are to be migrated over time to or are out of office during migrations to see these results.

This is beneficial because if you are like me, you don’t migrate all of your users in a “Big Bang” fashion.