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:
- Appropriate sharing permissions are placed on the relevant folders in user A’s mailbox, depending upon the permissions set with the delegation tool.
- If the checkbox for forwarding meeting requests is set, a special hidden forwarding rule is created in user A’s mailbox.
- 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.
OK, so I’m a little late getting around to commenting on this. So sue me… 🙂
So I’m assuming that the correct thing to do is check for the existence of publicDelegatesBL before deleting a mailbox, and then undo those delegations on behalf of those users, correct? I’m surprised that it doesn’t work this way already (or not, this is Microsoft after all).
Failing that, why not just look up “(publicDelegates=B)” in AD and see what turns up?
Is MFCMAPI’s inability to delete individual delegate rules just a limitation in MFCMAPI, or something beyond its control? Outlook must be able to do it, but maybe it does something kludgey like read the entire rule, delete it, and write it back out with the proper delegates removed. Seems like if Outlook does it, then some other program could be written to do it (assuming it’s documented).
Regarding checking the publicDelegatesBL attribute prior to mailbox deletion, this is ideally what should happen, but does not. The problem with trying to do this with our provisioning/de-provisioning tools is that there is no programmatic mechanism for removing a delegation short of logging into the mailbox AS that user. (Well, it could be done by using Exchange Impersonation with Exchange Web Services, but that will not work with Resource Mailboxes since their underlying accounts are disabled.)
The problem with looking up the presence of an account in everybody’s publicDelegates attribute is that it is a time-consuming process (which can be problematic with web-based tools), and again we are back to the issue of removing the delegation via our de-provisioning program.
The hidden delegate forwarding rules are contained in a binary blog in a MAPI property. The MFCMAPI tool simply does not know how to parse and rewrite this blob.
> [T]here is no programmatic mechanism for removing a delegation short of logging into the mailbox AS that user.
>
>The hidden delegate forwarding rules are contained in a binary blog [sic] in a MAPI property. The MFCMAPI tool simply does not know how to parse and rewrite this blob.
So the only API that does know how to parse this blob is only available while logged in to the mailbox as its owner? Is there some method to forcibly reset the password of a soon-to-be-deleted user so that you can log in and delete the delegation that way? If so, can the original password be saved and restored?