Just where the heck is all this Delegate information stored, anyway?

In this political season (in the USA at any rate), sometimes you need to "grabificate the bull by the horns and milkify that steer for all that he's worth." (No Dubya did not actually say this but work with me here, we're on a roll.)

So WHERE you might ask does all of this DELEGATE information actually live in Exchange?

The short answer is ALL OVER THE PLACE.

Here is the quick reference list:

1. Folder Security Descriptors
2. Active Directory
3. The (infamous) NON_IPM_SUBTREE
4. Server-side rules (for the special case of forwarding meeting invitations)

So to modify Delegate programmatically you need to take care of ALL of these.

Folder Security Descriptors

For Exchange 2000 and 2003, see Modifying Store Permissions in Exchange 2000 and 2003

For Exchange 2007 you use the Management Shell.

Every object (and a folder is an object with other objects potentially inside it) in the Exchange database has a security descriptor that determines who can access it. One of the main sources of confusion in all this is that from WebDAV Exchange can SEEM like it's a filesystem (remember the (in)famous M: drive?) but it never acts like one in any API. PFDAVAdmin does a great job at modifying access permissions for both Exchange 2003 and 2007.

Active Directory

Send-As permissions are kept in AD. The field publicdelegates contains the list of URLs of all users with access to the mailbox. Active Directory does a BIG favor here by maintaining backlinks in other users' publicDelegatesBL.

So by checking any user's publicDelegatesBL property, you can find out for whom they are a delegate. This was put to creative use in Listing Which Exchange Users Have or Are Delegates and Finding delegates in Active Directory (sic).

The perceptive among you will realize that if you are a delegate to someone and they have subsequently been removed from Active Directory you might still have some kind of zombie connection to them. Such is often indeed the case.

NON_IPM_SUBTREE

The file NON_IPM_SUBTREE/Freebusy Data/LocalFreebusy.EML which not surprisingly contains Free-Busy data (but be careful trying to read it) also contains three MAPI properties which define Delegates.

• x6844101F PR_DELEGATES_DISPLAY_NAMES
• x68451102 PR_DELEGATES_ENTRYIDS
• x686B1003 PR_DELEGATES_SEE_PRIVATE

Private items have PR_SENSITIVITY =2, Public items have PR_SENSITIVITY = 0. Confidential items have PR_SENSITIVITY =3, but Outlook does not do anything with Confidential items and the Exchange server does nothing to enforce Private items leaving this to the client (ever read me write that this was all designed and implemented by some committee somewhere?). So those of you looking to migrate this capability from Oracle Calendar Server where there is a client side distinction between Private and Confidential, you can migrate it, but it will do you no good.

BTW, Google has picked up on how useful it is to document MAPI tags.

Modifying the AD values has NO EFFECT on the values in the NON_IPM_SUBTREE. You have to take care of that separately. The incomparable Glen Scales blogged on how to in Accessing the NON_IPM_Subtree folders in Exchange Web Services .

Server-Side Rule

Like all SSRs this is in the INBOX for the user doing the forwarding (which means the client does not need to be running for it to be invoked, which is exactly what you want from an end-user perspective).

• x65EB001F PR_RULE_MSG_PROVIDER which should be "Schedule+ EMS Interface"

By way of comparison, PR_RULE_MSG_PROVIDER is

• "RuleOrganizer" for normal Outlook rules
• "Schedule+ EMS Interface" for delegation rule
• "MSFT:TDX OOF Rules" for OOF Wizard rule
• "MSFT:TDX Rules" for Public Folder rule
• "MSFT:MR" for Public Folder moderation rule

For managing rules in E2K7, check out http://msexchangeteam.com/archive/2008/04/14/448687.aspx and Glen has also already blogged on the topic.

I am hugely indebted to the work Ximian did in reverse-engineering all of this before it was absorbed by Novell.