The Exchange Developer Documentation team is happy to announce the release of the Exchange 2010 Beta SDKs. That's right, I said SDKs -- as in, more than one! For earlier product releases, all Exchange developer documentation is included in a single SDK. For Exchange 2010, documentation for each technology area is published in a separate SDK, making it quicker and easier for you to find information that you need. The following SDKs are available online for Exchange 2010 Beta:
The Exchange Web Services Managed API 1.0 SDK is also available online, and contains information that can help you use EWS to develop applications for Exchange 2007 SP1 or Exchange 2010.
To learn more about the new features for developers in Exchange 2010 Beta and the new SDKs, check out Thom Randolph's article Introducing the Exchange 2010 Beta SDKs. Also, be sure to review the Guide to Exchange 2010 Development Technologies, which explains the organization of the SDKs and contains information about the development technologies that are supported in Exchange 2010. Get going today and take advantage of the many cool new features available in Exchange 2010 Beta!
There has been some confusion about the different methods that can be used to access a mailbox. Developers are asking: What method should I use? When should I use it? What are the differences between the different methods? This post will give you a quick comparison of the two most common ways, other than a direct log on, to access a mailbox: Exchange Impersonation and delegate access.
Exchange Impersonation vs. Delegate Access
Exchange Impersonation is used in scenarios in which a single account needs to access many accounts. Line-of-business applications that work with mail typically use Exchange Impersonation. An application can be written to display mailbox data such as number of unread items, calendar, and so on. The application can use a dedicated service account to access multiple users’ mailboxes to display their respective data.
Exchange Impersonation is different than Windows Impersonation. Windows Impersonation is an operating system concept that requires you to set Kerberos constrained delegation. Exchange Impersonation is a simpler authorization mechanism that is designed for use only within Exchange Web Services (EWS). For more information about Windows Impersonation, see Client Impersonation on MSDN.
Delegate access is used in scenarios in which there needs to be a one-to-one relationship between users. One common application of delegate access is the sharing of calendars between users, such as when an admin manages an executive’s calendar, or a when handful of individuals working on a project need to coordinate calendars.
Another example of delegate access is resource mailbox management. Resources, such as conference rooms, can be managed by one or more people. Resources are represented by mailboxes, but not in the traditional sense. Resource mailboxes do not have owners; therefore, they can only be accessed by mail-enabled users to whom delegate access is granted.
The following table lists the differences between Exchange Impersonation and delegate access.
Exchange Web Services
Any mailbox client
Per shared mailbox
New account creation
Can be automated
An administrator is able to configure impersonation on behalf of a service account, and grant that service account impersonation rights over many mailboxes. Individual users cannot manage who does or does not have impersonation rights over their mailboxes.
Individual users can grant and remove delegate access to their own mailboxes through several mailbox clients, such as Microsoft Outlook, Outlook Web Access, or Exchange Web Services-based clients. A mailbox owner does not need administrator rights to grant another user delegate access to their mailbox.
There is no true auditing for either Exchange Impersonation or delegate access. Any mail that is modified by using impersonation will appear to the mailbox as if it was modified by the user who was impersonated. No log is left behind of the impersonation access.
†For delegate access, there is partial auditing, in that any mail that is sent by a delegate on behalf of the mailbox owner is displayed as “Sent on behalf of.”
Exchange Impersonation can only be used through Exchange Web Services. The caller (authenticated user) indicates which user they want to impersonate in the SOAP header. For more information about how to use Exchange Impersonation, see Using Exchange Impersonation on MSDN.
Delegate access can be used through any mailbox client, including Outlook and Exchange Web Services-based clients. For more information about delegate access, see Exchange Web Services and Delegate Access on MSDN.
A user or account that has been granted impersonation rights will have the same rights as the user whom they are impersonating. Typically, service accounts are given the ability to impersonate the mailbox owner. In that case, the impersonating account has full mailbox rights, just as the mailbox owner does.
With delegate access, the delegate can be granted more granular rights, up to and including full mailbox access. Delegate access can also be configured per folder, or per mailbox. For example, a user can grant the delegate read-only access to the Inbox, read-write access to a calendar folder, and so on.
Exchange Impersonation is generally configured as one-to-many: one service account to many user accounts. You can configure an account to impersonate a broad set of users, such as an entire mailbox database. For more information about how to configure impersonation, see Configuring Exchange Impersonation on MSDN.
For delegate access, there is no option to set up a single delegate for multiple mailboxes. A relationship must be established for each user who needs to access a given mailbox.
You can configure Exchange Impersonation to allow new accounts that are created to automatically be impersonated by service accounts. Setting up accounts to impersonate any user within a mailbox database can reduce your configuration overhead.
You must explicitly grant delegate access for any new users who are added.