Learn More About Exchange Web Services (EWS) Impersonation
EMS offers two Exchange integration options to enable seamless room, resource, and attendance scheduling:
- EMS Integration to Exchange offers users the convenience of scheduling rooms, resources, and services, confirming attendee availability, and managing Outlook invitations via EMS Web App (our web-based reservation tool). See Also: Installation Overview.
- EMS for Outlook lets users find available rooms, review their details, reserve them and book any necessary resources (equipment, etc.) without ever leaving Microsoft® Outlook.
To achieve this seamless interaction between everyday users, Outlook hosts, and EMS administrators, an account with Exchange impersonation access to all mailboxes in your Exchange mailbox store is required.
Why is this account necessary?
Meetings created via EMS Integration for Exchange either 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. However, 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? (For example, remove CEO, Board of Directors, etc. from being impersonated.)
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 any 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 (so a 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, which allows you to programmatically search the folder for items that have the custom property. Once that custom property is created, then Editor will be enough. It is 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. Additionally, User1 would be able to change the rights, which would essentially disable the Exchange integration.
- This restricts access only to the calendar
By contrast, 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
The links below provide additional information 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.