Revenge of the LegacyExchDN

After using the PST migration method to divest an Exchange deployment, we discovered that a user couldn't act as a delegate for old items in another user's calendar.

Instead, we received this pleasant message from Microsoft:

No, it's not helpful, Microsoft.

Invoking the following didn't achieve the desired results:

Set-Mailbox -Identity Cheryl -GrantSendOnBehalfTo Natalee

And neither did:

Set-MailboxPermissions -Identity Cheryl -User Natalee -AccessRights SendAs

(Of course on Exchange 2010, you'll need to set the equivalent via AD Cmt-lets)

Set-MailboxPermissions -Identity Cheryl -User Natalee -AccessRights FullAccess

No go there either.  How about delegate permissions?

Add-MailboxFolderPermission -Identity Cheryl:\Calendar -User Natalee -AccessRights Editor

Nope.

So what's wrong and how do we go about finding out?  Being a datahead, I grabbed the latest MFCMAPI build and deployed in on a machine with Outlook installed.  With the proper permissions temporarily in place, I drilled into the user's information store, down to the calendar, then enumerated contents.

Object DN resolution failure

There I located the troubled appointment by Subject, and found that the following properties were pointing at the legacy domain's DN.

• PR_SENT_REPRESENTING_NAME_W
• PR_SENT_REPRESENTING_EMAIL_ADDRESS_W

I had heard rumors of a solution leveraging X500 addresses, a relic from long, long ago.  Updating X500s would allow the metadata to resolve off of my modern Exchange 2010 deployment.

Leveraging ADModify as perscribed in the article resolved the issue.  Now, if you didn't get your mailNickname property identical between domains, you'll have to modify users individually.  Or if the old domain isn't available for reference, you'll need to use MFCMAPI to track down troublesome messages to find the exact DN that can't resolve off of the new AD deployment.

Digging up legacy DNs on known bad calendar objects