Learn More About Exchange Web Services (EWS) Impersonation

Why is this account necessary?

Meetings created via EMS Integration for Exchange on EMS Web App or EMS for Outlook are owned by the host and associated with a specific Exchange account. That Exchange user can move, update, or cancel the event. These meetings can also be moved, changed, or canceled by IT admins and expert users in EMS Desktop Client.

When a reservation is moved, changed, or canceled in the client, EMS must be able to update the record on the host’s Exchange account. Co-ownership of events between the meeting host and the EMS administrators necessitates an account that can read and write to all Exchange accounts being used for booking.

Can we exclude people from impersonation?

Microsoft Exchange Server supports a CustomRecipientScope parameter when defining the impersonation role. You can define a scope of included users by implementing this parameter.

Is there a way that we could use a delegation feature (like allowing office admins delegate rights) instead of impersonation to notify hosts of updates/changes?

Delegation is possible, here are some things you should know:

• The account needs Editor w/Folder owner (custom rights set).
• Custom rights, at least through exchange 2010, are not scriptable. This means the delegation account will get set to owner, which is the only built in (read scriptable) option that has all the necessary permissions.
• EMS for Outlook creates a custom property on the Calendar folder, to programmatically search the folder for items that have the custom property. Once that custom property is created, then Editor will be enough. It's the creation of the custom property at the folder level that requires owner permission.  
• While you can use PowerShell to script the permissions and loop through the users and set the permissions (owner), you would need to make sure that the script got applied to any new users and reapplied to any users that have changed the permissions of the delegation account.
• Rights are granted to ANY mail client (Outlook, OWA, etc):  when using the impersonation account, rights are only granted to Exchange Web Services, so nobody could type in the service account into Outlook and gain the same permissions.
• These rights are visible to the end user. For example, if an account, "EMSExchangeAccount", has been granted, delegation rights (any level) to User1’s calendar, and User1 goes to the Permissions tab of his calendar, he will see the EMSExchangeAccount and the rights it is assigned. Also, User1 would be able to change the rights, which would disable the Exchange integration.
• This restricts access only to the calendar.

EWS impersonation provides the following alternatives to delegation:

• Allows access ONLY through Exchange Web Services
• Does grant permission to do anything the impersonated user could do (assuming it is available as part of EWS)
• End users do not see and cannot change the permissions

Learn more from Microsoft^® about Exchange Web Services (EWS).

• The Importance of EWS Impersonation
• Authentication and EWS in Exchange
• Impersonation and EWS in Exchange 

  With Impersonation, a service account has full access to a defined set of mailboxes. What it can access in those mailboxes (such as specific folders) cannot be filtered or defined. Only an Exchange Admin can configure an EWS Impersonation account for impersonation and configure its mailboxes to allow the impersonation.

• Delegate Access and EWS in Exchange

  Delegate access allows a user to access certain folders in another user’s mailbox  Delegate permissions can be set by a mailbox owner or administrator using an app or other app code.