Why X500 addresses are so important

There are many posts and a few KB articles related to legacyExchangeDN and X500 addresses. Here some a few examples:

These are only a few examples. But there is even more: Calendar items and especially recurring meetings are highly depending on legacyExchangeDN.

In a recent M&A scenario the decision was made to perform a cleanup of X500 addresses, which definitely caused quiet a number of tickets.

Symptom

After a Merge & Acquisition project, we saw an increase of incoming tickets related to meeting series. The main complains where the followings:

  • users receives an error: “The user account which was used to submit this request does not have the right to send mail on behalf of the specified sending account.
  • user cannot edit a meeting request at all. The user seemed not to be the organizer even Outlook showed so.
  • delegates couldn’t response to updates of meeting series

All cases had the same in common: As part of a M&A scenario users where migrated cross-forest and their accounts using mS-DS-ConsistencyGUID as sourceAnchor, which is meanwhile the default of AAD Connect. Read more about AAD Connect design concepts here. During the migration the old X500 addresses where not synced to the user objects in the new forest and therefore also deleted from the corresponding object in Azure AD.

Background deep dive

There are a view MAPI properties, which are crucial for this. Here is the list I’m using:

NamePropertyID
CalendarOriginatorId0x83FD
ResponsibleUserName0x8375
PR_SENDER_EMAIL_ADDRESS0x0C1F
PR_SENT_REPRESENTING_EMAIL_ADDRESS0x065

Note: The names of the properties coming from myself. There is no official documentation with the names (at least I couldn’t find it!), but looking at the names of the Cmdlet Get-CalendarDiagnosticObjects output, I thought it’s a good idea. These properties are either Extended or CalendarAssistant MAPI properties.

CalendarOriginatorId contains the Exchange GUID and the SMTP or EntryID (which is usually the legacyExchangeDN and within an Exchange org the used one). As you can already imagine that EntryID is always referring to the current address book object of the user.

Let me explain what exactly happened:

  • A user created a recurring meeting and Exchange stamped the values with the EntryID of the user at creation date
  • Now the user got migrated and only the Exchange GUID,  primary SMTP address and legacyExchangeDN (as X500) was copied
  • No old X500 have been copied

On the first glance everything should work correct? Sadly not. There is one thing we didn’t care about it:

Just a view month ago, before we migrated the users, the company, we acquired, bought another company and migrated them. At that time all
legacyExchangeDN have been copied as X500 addresses and everything was good. But now as we didn’t copied these old addresses, everything was broken for these users.

Lessons learned

Looking into volume of tickets, which have been created related to the decision not to copy old X500 and even more the end-user experience, I highly recommend to preserve these addresses for any project.

If you run into a similar issue and need to reconstruct the old X500 address, you can either use MFCMAPI or my script Get-CalendarItems, which returns since then these properties as well.

Don’t let old X500 addresses bite you!

Advertisements

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s