When setting up the user for the connector you will get two options to give the User Delegate or Impersonation. Here you can find the explenation why we recommend to use Impersonation:
First thing are the throttling policies. The throttling policies can be changed on a local exchange installation(not recommended to do by microsoft) but on Office365 the throttling policies can not be modifyd.
One Subscription = One room to monitor. So when you want to use delegate we can only support up to 20 rooms.
Basic Explenation usage of the different settings.
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.
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.
Small artikel provided by Microsoft:
First, a point of clarification: Delegate access is geared to situations where an application needs access to mailbox items controlled by a user, and where it is likely that code will be run under the logged-on users permissions. Accordingly, Delegate access is a user-manager permission, as it presumes that the user/owner of the mailbox is explicitly granting access. Impersonation, on the other hand, has been designed to support enterprise applications, and is an administratively controlled access methodology that requires no intervention from the mailbox owner. One way to think of the differences is that Impersonation is access for applications, whereas Delegate access is access is for users.
In practice, applications using EWS Impersonation are more robust, as other applications or normal users cannot revoke permission settings on the fly as they can with Delegate settings. Furthermore, the setup and administration of Impersonation is significantly less complex and time consuming when dealing with large sets of users, as it can be set globally rather per mailbox.
From a security perspective, Impersonation is preferable to Delegate access for the following reasons:
- Access via EWS is not available to end-users, and EWS calls can (and should) be secured on the wire via SSL.
- Role-based access permissions to enable or disable Impersonation rights are provisioned on the account level, and can be set only via the Exchange administrator.
Note that both Impersonation and Impersonation activity can be logged by both IIS and EWS native logging functionality, providing a full audit trail.
To summarize some of the reasons why EWS Application Impersonation is considered the best approach to application-level mailbox access for server/service type applications:
- It is an administrator-managed, not user-managed permission, which means that a user or other application cannot change the permission settings.
- It is inherently designed for one-to-many mailbox access, which means there’s less configuration complexity and overhead for managing new users that need to be added to the application scope.
- It takes advantage of EWS features, such as Throttling, that are designed to help manage application access to user mailbox data. For example, impersonation accounts can have their own throttling budget (as of Exchange 2010 SP2), which means that applications using impersonation can’t inadvertently lock user’s out of their mailboxes for exceeding their budget.
- It can only be used through EWS, which means that users with access to an account with impersonation rights would need to write an EWS application to access a user’s mailbox and could not directly access the mailbox via a mailbox client such as OWA.
Whole Artikel can be found here: https://blogs.msdn.microsoft.com/webdav_101/2012/06/27/the-importance-of-ews-impersonation-while-using-an-application-account/
We need this for the connector. We make use of roomlists and we need to create update and delete these lists with remote powershell. But you can narrow down what we need. The following is essencial:
more information about impersonation, Delegate and Remote Powershell can be found here: