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:

• “0x80070005-0x0004dc-0x000524” error when a user sends updates to Calendar items that were created before Exchange Online migration
• IMCEAEX non-delivery report when you send email messages to an internal user in Office 365 dedicated
• Inbox rules are disabled after migration to Office 365 Dedicated/ITAR (vNext)

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:

Name	PropertyID
CalendarOriginatorId	0x83FD
ResponsibleUserName	0x8375
PR_SENDER_EMAIL_ADDRESS	0x0C1F
PR_SENT_REPRESENTING_EMAIL_ADDRESS	0x065

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!