As of: 29 September 2026

Time required: approximately 30 minutes

Who this article is for: IT administrators of organisations running their own Exchange Server (Subscription Edition, 2019 or 2016) who are connecting their mailboxes to Captured Knowledge (CK). Exchange Online (Microsoft 365) has its own guide.

Expected results: Captured Knowledge accesses exactly the mailboxes you put into one group, through Exchange Web Services (EWS) with a dedicated service user — following the principle of least privilege.

The steps below can be done either in the Exchange Admin Center (EAC) or in the Exchange Management Shell. We give the commands for reference. Please note that they must be run in the Exchange Management Shell — a regular PowerShell session does not have the required Exchange cmdlets.

Overview:

The integration needs a mailbox that serves as the central collection point for emails Captured Knowledge should process. Usually this is an existing mailbox (for example a shared or functional mailbox) your team already uses for this purpose. Please decide together with your team which mailbox to use.

Below, [email protected] stands for this mailbox's email address.

If you wish, Captured Knowledge can also read further mailboxes, such as individual staff members' personal mailboxes — see steps 3 and 9.

The integration needs its own service user with an Exchange mailbox. This ensures the access is used only for its intended purpose and is clearly traceable.

Run the following command in the Exchange Management Shell. Replace captknowledge and yourdomain.com with the values for your environment.

New-Mailbox creates both the AD user and an Exchange mailbox in one step. The mailbox is not actively used — but Exchange requires a mailbox for the service user so that the ApplicationImpersonation role can be used.

Recommended hardening of the service user: since this user is intended only for programmatic EWS access, we recommend disabling unneeded access protocols and hiding the account from the address book:

For our service to access the intended mailboxes, the new service user needs the ApplicationImpersonation role. It lets the service user act on behalf of another mailbox without knowing its password.

We control access through a security group, so you can manage access simply by adding mailboxes to or removing them from the group.

Note: the scope covers only direct members of the group. Nested groups are not supported — every mailbox must be added as a direct member.

If your organisation wants Captured Knowledge to read further mailboxes as well (for example individual staff members' personal mailboxes), add them as further direct members of the same group — no extra credentials or configuration are needed. Captured Knowledge reads and tags such mailboxes and transfers relevant emails into the target mailbox; by default the original then goes to the mailbox owner's Deleted Items (on request it stays where it is, tagged, instead). Captured Knowledge sends no email from these mailboxes (the "Send As" permission in step 4 is independent and only relevant for addresses Captured Knowledge should send as).

Create the group and assign the permission: run the following commands in the Exchange Management Shell on your Exchange Server. Replace CK_Integration_Mailboxes with your preferred group name, [email protected] with the target mailbox from step 1 and captknowledge with the service user from step 2.

Captured Knowledge processes emails through the target mailbox (step 1) but sends replies with the sender address of the responsible user (for example a case handler). For this, the target mailbox needs the "Send As" permission for those users' mailboxes.

Background: the ApplicationImpersonation permission lets the service user access the target mailbox. Sending an email from there with a different sender address (another user) additionally requires "Send As".

Run the following command in the Exchange Management Shell for each mailbox that should receive this permission:

Note: replace [email protected] with the address of the user's mailbox and [email protected] with the target mailbox from step 1. Add-ADPermission -Identity does not accept an email address, so the mailbox is passed in with Get-Mailbox.

Our application needs the external EWS URL of your Exchange Server. It is usually https://mail.yourdomain.com/EWS/Exchange.asmx. You can check the exact URL in the Exchange Management Shell:

Please make sure the ExternalUrl is reachable from outside your network and has a valid SSL certificate. Our application uses this URL directly (without Autodiscover).

If your Exchange environment is behind a firewall, access to the EWS endpoint (HTTPS, port 443) must be allowed for our IP address. Our service connects from the Frankfurt data centre (Google Cloud, europe-west3) exclusively through the fixed IP address:

Please set up a firewall rule that allows incoming connections from this IP address to your Exchange Server's EWS endpoint. Some geolocation services wrongly place Google Cloud addresses in Frankfurt in the USA, so country-based blocking (geo-blocking) can block the connection.

By default Exchange limits the number of concurrent EWS connections and requests per user. For a service user that polls mailboxes regularly, the default throttling policy can cause occasional connection problems. We recommend a dedicated policy for the service user:

You can check that impersonation is set up correctly with these commands:

Once the configuration is complete, we need the following details to activate the integration. Please send them over an agreed, secure channel (for example encrypted email or a secure text-sharing service):

If you have questions or need help with the setup, write to us at [email protected].