Skip to main content
Version: 7.3

Hosted Exchange Server configration

This section describes how to configure the connection to a hosted 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 "Hosted Exchange". 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.

On hosted Exchange Server contentACCESS is using a Hosted Exchange authentication method which uses the configured Exchange Server to authenticate the user. Depending on the hoster configuration, it might require a different domain name for user logins. In this case configure the Override login domain and Login domain options. Enter either the NETBIOS domain name or the full qualified domain name as Login domain.

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). Please consult with your Exchange hoster. 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.

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 hosted Exchange Server it is recommended to configure the "Microsoft Exchange" login provider in contentACCESS. The users will use the Exchange authentication to log in to contentACCESS. The email archive will create the Exchange logins for the users and will synchronize the permissions based on these Exchange 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
info

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