(This posting is based upon a message I recently sent to a customer, and is essentially an expanded version of this posting.)

From time to time, it is necessary to grant certain users “Full Access” permissions to log into mailboxes that are not their own in order to allow those individuals the ability to set up delegates and/or sharing permissions, especially in the case of Exchange 2007 resource mailboxes, since the underlying AD accounts for such mailboxes are disabled by default.  However, over the years, there have been difficulties with this.

There is an issue with folks who have Full Access to a mailbox being able to set delegations, which somewhat breaks our model for managing room resources and role-based mailboxes (the latter are referred to as “shared mailboxes” in Exchange 2007 parlance).  We should revisit how we farm out this ability, perhaps via a script which not only sets the “Full Access” right, but also manipulates the appropriate AD permissions. Research is in order, but here is a brief overview of the history of the problem:

Creating Delegations in Exchange consists of several elements: 1) creating a special hidden forwarding rule for delegates who should receive copies of meeting requests, 2) granting the delegate sharing permissions on the appropriate mailbox objects, and 3) adding the delegate to the publicDelegates AD attribute (the send-on-behalf-of-list).

At some point (I’ve not been able to nail down exactly when), Microsoft changed their Exchange security model such that granting “Full Access” to a different mailbox does not give the Full Access user rights to modify the publicDelegates AD attribute, thus preventing them from adding delegates. After this change, such Full Access users were seemingly able to create delegates on mailboxes that were not their own, but the delegates would encounter the following error:

“You do not have the permission to send this message on behalf of the specified user.”

What was actually happening under the hood is that the delegation was only partially being created.  The publicDelegates attribute was not being updated, but no error was generated in the process of trying to create the delegation. Microsoft’s first stab at a solution was an Outlook 2003 post-SP2 hotfix, KB913696, which prevented these partial delegations from being created at all, instead generating the following error:

“The Delegates settings were not saved correctly. Unable to activate send-on-behalf-of list. You do not have sufficient permission to perform this operation on this object.”

This error caused much confusion, complaints, wailing, and gnashing of teeth, so Microsoft tried again with another hotfix (for Outlook 2003: KB946207, explained in KB945208. For Outlook 2007: KB950485, explained in KB950794), which, in conjunction with a registry modification on the client, essentially reverted Outlook to the earlier semi-broken behavior: delegates can be added, but the publicDelegates attribute does not get populated.

As far as I can determine, Microsoft’s reasoning on this odd behavior is as follows: the user of a given mailbox will assign their own delegations (in this respect, Microsoft’s perception is clearly out of sync with the real world), and since they can modify their own publicDelegates attribute, this isn’t a problem. As for resource mailboxes, who would want to send on behalf of a room?  As for role-based (shared) mailboxes – oops….

The workaround for this all along has been for the Exchange administrators to go in and populate the publicDelegates attribute, then for whoever manages the mailboxes to go in and configure the delegate permissions and settings. Of course, this is cumbersome.  What we need is a better way of doling out the ability to create delegates, perhaps in the form of a script which, in addition to granting “Full Access” permissions to a specified user or group, also grants that user or group permission to modify the publicDelegates attribute. Even now, I am scheming and tinkering to find a way to fix this, including going back through all existing “Full Access” permissions on resource mailboxes and making sure that the appropriate permissions get applied on the publicDelegates attribute.

Update: In the midst of testing, it is starting to appear that granting WriteProperties permission on the publicDelegates attribute may not be sufficient. Still working on it….

Update 2: It seems that for calendar-related operations, delegates do not need to appear in the publicDelegates attribute in order to be able to send-on-behalf-of….

References:

http://msexchangeteam.com/archive/2007/04/09/437620.aspx

http://msexchangeteam.com/archive/2008/01/24/447928.aspx

(Note that these MSExchange Team Blog articles incorrectly assert that this problem only manifests in multi-domain environments. We have this issue in our single-domain, single-forest environment.)

http://support.microsoft.com/kb/913696 – original post SP2 hotfix for Outlook 2003

http://support.microsoft.com/kb/946207 –  Outlook 2003 post-SP3 hotfix

http://support.microsoft.com/kb/946208 – explanation of Outlook 2003 post-SP3 hotfix, with registry instructions

http://support.microsoft.com/kb/950485 – Outlook 2007 hotfix

http://support.microsoft.com/kb/950794 – explanation of Outlook 2007 hotfix, with registry instructions