On-premises Exchange Server configration
This section describes how to configure the connection to an on-premises Exchange Server. Before you begin with the configuration, make sure to select or create a user account with valid mailbox license. This account will be used as "superuser" to access emails. The permissions required for this account are also described in this section.
Select the Exchange server type as "On-premises". Select the Exchange server interface version corresponding to your Exchange Server version. Since older Exchange Servers have already reached end-of-life, the recommended version is Exchange 2016 or higher.
An access to on-premises Exchange Server always uses EWS (Exchange Web Services) with Basic authentication. Enter the EWS url. The url is in format: https://servername/EWS/Exchange.asmx. The EWS authentication mode is fixed at "Basic" authentication. The option Use impersonation allows to choose how permissions on mailboxes are managed in your organization:
- delegation (without impersonation) requires to explicitly grant Full access permissions on all archived mailboxes
- impersonation requires an account with the role ApplicationImpersonation It is recommended to use impersonation. For more details see the superuser permissions.
Configure PowerShell access: Select the PowerShell authentication from the available options. It is recommended to use the same Basic authentication as used for EWS. Please note that Basic authentication for PowerShell might not be enabled by default and needs to be enabled on the Exchange Server (by configuring the virtual directory PowerShell). Enter the PowerShell url in format: https://servername/PowerShell By setting the Max connection count you can limit the number of concurrent connections made by contentACCESS to PowerShell. The recommended value is 3. Use the option Ignore SSL errors only if you have a self-signed certificate for the Exchange Server. If you have a valid certificate, this option can be unchecked. Make sure to test the connection to find out whether you have certificate errors. The option Keep connection alive allows contentACCESS to reuse existing connections instead of creating a new connection when it is needed. Even though keeping the connection alive might have performance benefits, it might cause issues especially if a load balancer is used. It is recommended to turn off Keep connection alive when using load balanced Exchange Server.
Both the EWS connection and the PowerShell connection are using the same account which is configured under Username and Password. It is recommended to use Use explicit credentials to specify the account. If an explicit acocunt is not selected, the contentACCESS must be configured to run under a specific Active Directory account. For more information see the Installation section and the superuser configuration. When entering the explicit account, you can enter the user in DOMAIN\user format or in the upn format: user@domain. Use the format which is accepted by your Exchange Server.
It is recommended to test the connection after each change. Both the EWS and PowerShell connections are tested and the result of the test is displayed.
Portal access contentACCESS can provide access to the archived data for users using the Portal access - user logins. When working with on-premises Exchange Server it is recommended to configure the Active Directory connection in System settings. The users can use Windows authentication to log in to contentACCESS. The email archive will create the Windows logins for the users and will synchronize the permissions based on these Windows logins.
Superuser permissions The superuser account has to be an active account with a valid mailbox license. The account requires the following Exchange roles:
- ApplicationImpersonation (for impersonation)
- View-Only Organization Management or Organization Management
- Org Custom Apps
- Org Marketplace Apps
- User Options
The roles "Org Custom Apps", "Org Marketplace Apps" and "User Options" are required for the installation and usage of contentACCESS MailApp.
Impersonation Impersonation allows the superuser to impersonate any account in the organization and access mailbox data. Configuring impersonation is simple: grant the ApplicationImpersonation Exchange management role to the account.
Benefits:
- the impersonating account has access to all mailboxes in the organization
- new users are automatically granted permission, no further action is needed
- throttling is less likely to happen
Drawbacks:
- to restrict the permissions to certain users, an additional Management scope needs to be created
The following script creates a dedicated role assignment in Exchange and grants ApplicationImpersonation role for the superuser:
New-ManagementRoleAssignment -name:contentACCESSImpersonation -Role:ApplicationImpersonation -User:superuser
More information about impersonation
Delegation To access the accounts in the organization, the superuser should be granted as delegate user on each account indivdually. The superuser is granted Full mailbox access on all accounts. This can be done either on Mailbox database level (for all Exchange Mailbox databases) or on user level using Exchange Management Shell. Configuring delegation is more complicated and requires that the administrator sets the permissions on newly created mailboxes regularly.
Benefits:
- useful if only certain users are archived
Drawbacks:
- complicated configuration, maintenance needed
More information: this