Every once in a while, we get a ticket complaining about meeting invites generating an NDR claiming that a mailbox (not belonging to any of the invitees) does not exist. Invariably, this turns out to be due to one of the invitees having a delegate whose mailbox has been deleted, and this can be a pesky problem to resolve.

Here is a summary of how the delegation process works under the hood, and how to deal with “dangling” delegations when mailboxes are deleted.

Suppose you have a mailbox for user A who wishes to make user B a delegate.  When the delegation is made the following takes place:

1. Appropriate sharing permissions are placed on the relevant folders in user A’s mailbox, depending upon the permissions set with the delegation tool.
2. If the checkbox for forwarding meeting requests is set, a special hidden forwarding rule is created in user A’s mailbox.
3. User B is added to user A’s publicDelegates attribute (the send-on-behalf-of field), and user A is added to the publicDelegatesBL attribute of user B. This does not always happen in recent versions of Outlook, especially when the person trying to set the delegation is not actually the owner of mailbox A. See this earlier posting for more information on this issue.

Unfortunately, if the mailbox for user B is deleted, their publicDelegatesBL entry in AD gets cleared out, so there is no direct way to track down who they might have been a delegate for. Even more problematic, when user B’s mailbox is deleted, the hidden forwarding rule in mailbox A does not get updated, which is why it is important to always remove someone as a delegate prior to their mailbox being deleted.

Assuming that we can narrow down whose mailbox has the orphaned delegation, we can manually fix this by using the MFCMAPI tool to delete the hidden forwarding rule (the instructions being contained in the README file accompanying MFCMAPI). Unfortunately, if there are other delegates to that mailbox, the forwarding for them would break as well, so all of those delegates would need to be removed and re-added, which requires logging directly into the mailbox in question.

If the owner of the problematic mailbox is okay with this, the Exchange administrators can go ahead and nuke that hidden rule from their mailboxe, but the mailbox owner will need to go in afterwards and redo their delegations, or the Exchange administrators could do that with their permission.

Exchange 2010 RTM bits have been made available for download. Weee!

Also, the Exchange 2010 Mailbox Server Role Requirements Calculator is out and I’m reading through the documentation on it now. (Now for a comparable tool for scaling CAS and HUB deployments and we’ll be all set.)

But wait, there is more. The Exchange Server 2010 Deployment Assistant has also been released. This is basically a wizard which asks questions about your environment, and creates deployment checklists. Very helpful, far more so than trying to wade through the mountains of TechNet docs to create such checklists (which I remember vividly doing for our transition to Exchange 2007). On the downside, the current release is only for transitions from Exchange 2003 to 2010. A version which includes transitioning from 2007 is slated for release in early 2010.

Of more immediate interest to the UT community, after I (along with our storage guru, Alex Barth) had spent most of last week cobbling together a preliminary plan for transitioning AEMS to Exchange 2010, we met with a Dell consultant for a whiteboard session to go over options for such a transition. Although there was not much depth to the session, the consultant did bring to our attention some ideas we had not really considered, so now we have more food for thought and testing to perform. My plan may very well undergo significant rewrites, but that’s okay. Actual deployment is a long way off, which gives us ample time to refine our plan so that, hopefully, it will go off with a minimum of problems.