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).
- 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, you need an account with Exchange impersonation access to all mailboxes in your Exchange mailbox store.
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).