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.|
Set-Mailbox -Identity Cheryl -GrantSendOnBehalfTo NataleeAnd 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 FullAccessNo go there either. How about delegate permissions?
Add-MailboxFolderPermission -Identity Cheryl:\Calendar -User Natalee -AccessRights EditorNope.
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|
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|