Delegate Access in Exchange 2010
Last modified: January 27, 2010
Applies to: Exchange Server 2007 | Exchange Server 2010
In this article
Delegate Access
Delegate Management
Remarks
Exchange Web Services provides delegate access to users' mailboxes. Users who have been granted delegate access permissions can use Exchange Web Services (EWS) client applications to access other users' mailboxes.
Delegate Access
Delegate access is provided by a combination of explicit and implicit mechanisms. The explicit mechanism initiates delegate access, and subsequent delegate access occurs by implicit mechanisms.
Explicit Delegate Access
Explicit delegate access is used to allow a delegate to access a principal's mailbox for the first time. You can initiate delegate access by using either the FindItem Operation or the FindFolder Operation. These operations provide the option to use the DistinguishedFolderId element to identify the container to search. The DistinguishedFolderId element has a single optional child element, the Mailbox element. The Mailbox element, in the context of being used as a child of the DistinguishedFolderId element, is used to explicitly specify the mailbox for the delegate to access. If the calling user has permission to access the principal's mailbox, the response will contain a collection of identifiers to items or folders in that mailbox. The item and folder identifiers that are returned in the response can be used for implicit delegate access.
Implicit Delegate Access
Implicit delegate access is used after a delegate user has an identifier for an item or folder in the principal's mailbox. Each item and folder is associated with a particular mailbox. A delegate can use the item or folder identifier to make subsequent calls against a principal's mailbox. For example, when a delegate client has the identifier of a folder in the principal's mailbox, the delegate can perform a FindItem operation on the principal's mailbox by using the folder identifier without explicitly identifying the principal's mailbox. At that point, the delegate can perform operations on the principal's mailbox by using the identifiers that are retrieved in the responses.
Delegate Management
You can manage delegates by using the Exchange Management Shell. For information about how to grant delegate access by using the Exchange Management Shell, see the following topics:
EWS provides the AddDelegate Operation, the GetDelegate Operation, and the RemoveDelegate Operation to manage delegate users. Delegates can also be managed by using Microsoft Office Outlook.
Remarks
Domain administrators who try to access a principal's mailbox by using the GetFolder Operation when they do not have delegate access permissions will get a transient internal server error. This is caused by the Exchange Business Logic layer, which throws a transient connection failure that indicates that the action cannot be logged for the mailbox.
By default, a single EWS delegate access call can access a maximum of 255 different mailboxes. Attempts to access more than 255 mailboxes will result in an error. You can avoid this error by doing either of the following:
Requesting data for no more than 255 mailboxes in a single call.
Changing the ConnectionPoolSize property in the EWS web.config file to a new maximum number of mailboxes that a single request can access.
Note
You can also use Exchange Impersonation to access another user's mailbox. For more information about Exchange Impersonation, see Using Exchange Impersonation in Exchange 2010.
Granting owner rights by using the Add-MailboxPermission cmdlet does not imply Send-As rights. Send-As rights are explicitly set by using the Add-ADPermission cmdlet. Send-As rights may not take effect until both the Mailbox store and Internet Information Services (IIS) have been restarted. The following table lists the results of a CreateItem Operation or a SendItem Operation when the different rights are granted.
Owner rights (secondary owner) |
Send-As rights |
CreateItem/SendItem operation results |
|---|---|---|
Yes |
No |
Operation fails because the user does not have the rights to Send On Behalf Of the mailbox owner. |
Yes |
Yes |
Operation succeeds. If the From field includes the principal's SMTP address, the message will appear to have been sent by the principal. |
No |
Yes |
Operation succeeds. |
No |
No |
Operation fails. |
The following table lists the results of accepting an item by using the CreateItem operation when the different rights are granted.
Owner rights (secondary owner) |
Send-As rights |
Calendar item state (principal's mailbox) |
Meeting response received by third party after a meeting invite has been accepted |
|---|---|---|---|
Yes |
No |
Can accept meeting messages in the principal's mailbox without specifying the principal's SMTP address in the From field. |
The meeting response will state that it is sent by the secondary owner on behalf of the mailbox owner. |
Yes |
Yes |
Can accept meeting messages in principal's mailbox without specifying the principal's SMTP address in the From field. |
The meeting response will state that the meeting was accepted by the principal. |
No |
Yes |
Response returns an ErrorAccessDenied error code. |
No response is received because the calendar item is not accepted. |
Important
A user does not have the rights to make another user an Owner of their mailbox. Only members of the Exchange Administrators group can make another user an Owner of another user's mailbox.
See Also