Sdílet prostřednictvím

  • Článek

Exchange Web Services and Delegate Access

Topic Last Modified: 2008-07-08

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 or FindFolder operations. 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:

Starting with Microsoft Exchange Server 2007 Service Pack 1, EWS provides the AddDelegate, GetDelegate, and RemoveDelegate operations to manage delegate users. For more information about how to grant delegate access by using EWS, see the following topics:

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 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:

  1. Requesting data for no more than 255 mailboxes in a single call.
  2. 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 (Exchange Web Services).

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 or 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.

The following table lists the results of an AcceptItem request when the different rights are granted..

Owner rights (secondary owner) Send-As rights AcceptItem and 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.