# Microsoft Exchange / Outlook Integration — ContactManager Module Manual

# Table of Contents

Overview
Setup
How the connection is chosen
Contact Synchronisation
Appointment and Task Synchronisation
Sending E-mail via Exchange
Known Limitations
Configuration Reference
URL Reference
CM Configuration Changes
Field Mapping Reference
Related documents

# Overview

The Exchange module keeps Outlook contacts, appointments, and tasks in sync with ContactManager (CM), and can send CM-generated e-mail through the user's own mailbox. It supports two ways of talking to Exchange Online:

Microsoft Graph — the modern API, required going forward: Microsoft is retiring Exchange Web Services (EWS) on 1 October 2026, and has already retired application impersonation (the permission model the older connection relies on for acting on behalf of a user).
Exchange Web Services (EWS) — the classic connection this module has always used, for mailboxes not yet configured for Microsoft Graph. Its app registration needs different API permissions than the Graph one — registered separately, see ews.md. Once Microsoft Graph is configured for a mailbox, ContactManager relies on it exclusively: a Graph connection or sync failure is reported as an error rather than silently continuing over EWS, since EWS is being retired and can't be relied on as a permanent safety net.

1 October 2026 is not full EWS retirement — that's 1 April 2027. 1 October 2026 only starts a phased, tenant-controlled disablement: Microsoft flips the tenant's EwsEnabled setting from its default ($null) to $false on that date for any tenant that hasn't explicitly opted in. A tenant admin can keep EWS working past 1 October 2026 (up to the hard 1 April 2027 cutoff) by running, in Exchange Online PowerShell:

Set-OrganizationConfig -EwsEnabled:$true

Setting this before end of August 2026 avoids Microsoft's automatic switch to $false on 1 October 2026; it can also be run after 1 October 2026 to re-enable EWS (brief service interruption while it takes effect), still only until 1 April 2027. To restrict this to just ContactManager's own app registration rather than reopening EWS tenant-wide, pair it with an allow list keyed to this module's OAuth2 ClientId (see Registering an app):

Set-OrganizationConfig -EwsEnabled:$true -EwsAllowedAppIDs "<OAuth2 ClientId>"

This buys time, it doesn't avoid the migration — treat it as a runway extension to finish the Microsoft Graph setup above, not a permanent fix. Source: Exchange Online EWS: your time is almost up (opens new window), and Microsoft's Deprecation of Exchange Web Services in Exchange Online (opens new window) reference.

Both outbound sync (CM → Outlook: contacts, appointments, tasks, e-mail) and inbound sync (reading new/changed contacts from an Outlook folder back into CM, and the Mark as Skipped action) work over whichever connection is active, so the module keeps working end-to-end once a mailbox only has Microsoft Graph configured.

# Setup

# Registering an app in Microsoft Entra ID

In the Microsoft Entra admin center, register a new application (or reuse an existing one dedicated to ContactManager).

Under API permissions, add the following Application (not delegated) permissions for Microsoft Graph, and have an administrator grant admin consent:

Permission	Why it's needed
`Contacts.ReadWrite`	Reads and writes Outlook contacts — both directions of Contact Synchronisation (create/update/delete a mailbox's contacts, and read new/changed ones back into CM).
`Calendars.ReadWrite`	Creates and updates calendar events for Appointment Synchronisation.
`Tasks.ReadWrite.All`	Creates and updates entries in the mailbox's Microsoft To Do list for Task Synchronisation — Microsoft Graph has no application-permission equivalent scoped to a single mailbox's tasks, so this is the narrowest permission Microsoft offers for this.
`Mail.Send`	Sends e-mail from the user's own mailbox when Send e-mail via Exchange is enabled.
`User.Read.All`	Looks up a mailbox by its e-mail address (used by the Test Outlook/Verify action, and to resolve the sending mailbox for e-mail) — application permissions have no per-mailbox equivalent, so this grants read access to directory profile info for every user in the tenant, not just synced mailboxes.

Every permission above is an Application permission, which by default grants access to every mailbox/user in the tenant rather than just the ones ContactManager syncs. Contacts.ReadWrite, Calendars.ReadWrite, and Mail.Send can be scoped down: create an Exchange Online application access policy (opens new window) (New-ApplicationAccessPolicy in Exchange Online PowerShell, or its newer replacement, role-based access control for applications (opens new window)) against a mail-enabled security group containing only the mailboxes ContactManager should reach — same idea as EWS application impersonation with a scoped management role. Tasks.ReadWrite.All (Microsoft To Do isn't an Exchange mailbox resource) and User.Read.All (a directory-wide permission by nature) cannot be scoped this way and stay tenant-wide regardless.

Note the Application (client) ID and the Directory (tenant) ID — both are entered in ContactManager (see Configuration Reference).

# Certificate authentication (recommended)

Important — ContactManager runs on an older .NET version that can only sign with a "legacy" (CryptoAPI/CSP) private key, not a "CNG"/"KSP" one. A CNG-based certificate (the default from most certificate tools and CAs today, and from the Windows Certificate Export Wizard) makes authentication fail with an error mentioning "CNG" or "KSP" in the CM event log, even though the certificate itself is otherwise valid. Generate the certificate as legacy from the start, as below, to avoid this — this applies regardless of which of the two options below is used.

# No added risk from using a legacy certificate

"Legacy" here only means which Windows API manages the key, not a weaker algorithm — the certificate is still RSA-2048 signed with SHA-256, identical either way. A newer CNG-based certificate has two extra protections a legacy one doesn't: the private key can be isolated from the calling process entirely, and (with a TPM) made truly non-exportable in hardware. Neither is actually available here regardless of the legacy requirement: a certificate-store certificate on a legacy CSP can still be marked non-exportable (see Certificate store below) — the OS still refuses to let anyone extract the key, it's simply enforced by the older CSP mechanism instead of CNG's. The gap only matters for a PFX file, where the private key is exportable by definition (that's what makes it a portable file) — but that's the same PFX-vs-store tradeoff described below, unrelated to legacy-vs-CNG.

Microsoft's own guidance calls legacy CSPs "strongly discouraged" for building new PKI/CA infrastructure — that's about the API being an old, frozen surface that Microsoft no longer develops further, not a known weakness in what it already does. There's no CVE or attack specific to using a legacy CSP for the RSA-SHA256 signing this module needs.

# Certificate store (recommended), or a PFX file?

Certificate Path / Thumbprint on the MS Exchange Configuration screen accepts either a certificate-store thumbprint or a PFX file path:

	Certificate store (recommended)	PFX file
Setup access needed	LocalMachine store: local admin rights on the server. CurrentUser store: no admin rights, only rights to import into one's own profile	None — just a file the application pool identity can read; works for a non-admin CM operator with no server-admin rights
Private key exportable?	Can be marked non-exportable: the OS enforces that nobody (not even an administrator) can extract it, only use it in place	Always — the PFX file is the private key, protected only by its password
What's the actual secret	Whichever account can use the store entry — no password/file to leak, but a compromised account still has full access	`certificate.pfx` + its password, together — either alone is useless
Renewing/rotating	Import/generate the replacement in the store, update Certificate Path / Thumbprint to the new thumbprint	Copy a new file over, update Certificate Password if it changed
Best fit	Hardened production setups, especially a LocalSystem application pool (needs no extra permission setup at all — see Which store, and which account? below)	Quick setup; portable; fine when the server itself is already access-controlled

Both are fully supported. Neither changes the RSA-2048/SHA-256 signature strength itself — the legacy/CSP requirement above is about the key type, not the algorithm.

One thing that's the same regardless of option: since this is a self-signed certificate, there's no Certificate Authority revocation process to fall back on if it's compromised — response is manual: delete/replace the certificate on the app registration (Certificates & secrets) immediately, then generate and configure a new one.

# 1. Generate the certificate

App-only Graph authentication only needs the app registration to trust the certificate's public key — a self-signed certificate is standard practice for this and doesn't need a Certificate Authority.

Recommended — directly into the certificate store, non-exportable, on the legacy/SHA-256-capable provider (requires local admin rights on the server; run as Administrator):

$cert = New-SelfSignedCertificate -Subject "CN=ContactManager Exchange Sync" `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -KeyExportPolicy NonExportable -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256 `
    -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" `
    -NotAfter (Get-Date).AddYears(2)

Export-Certificate -Cert $cert -FilePath certificate.cer
$cert.Thumbprint

The -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" is what makes the key legacy/CSP instead of the cmdlet's CNG default (Microsoft Software Key Storage Provider) — this is the step most guides skip, since it's normally not needed for modern (.NET 4.6+ / non-Windows) applications. -KeyExportPolicy NonExportable is what makes the private key non-exportable. Note the printed thumbprint; there's no PFX or password to keep track of afterwards. No server-admin rights? Swap Cert:\LocalMachine\My for Cert:\CurrentUser\My — works the same way, just private to whichever account runs the script (see Which store, and which account? below).

Alternative — a portable PFX file instead of the store, e.g. when store access isn't available or a certificate needs to move between environments:

$cert = New-SelfSignedCertificate -Subject "CN=ContactManager Exchange Sync" `
    -CertStoreLocation "Cert:\CurrentUser\My" `
    -KeyExportPolicy Exportable -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256 `
    -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" `
    -NotAfter (Get-Date).AddYears(2)

$pfxPassword = Read-Host -AsSecureString -Prompt "PFX password"
Export-PfxCertificate -Cert $cert -FilePath certificate.pfx -Password $pfxPassword
Export-Certificate -Cert $cert -FilePath certificate.cer
Remove-Item "Cert:\CurrentUser\My\$($cert.Thumbprint)"

Same idea as the store script above, except -KeyExportPolicy Exportable, then exported to a file and the store copy removed — New-SelfSignedCertificate always writes to a store while it works (no parameter to skip that), so the last line cleans up the now-redundant copy; the application pool wouldn't be able to use it anyway even if left behind, since it typically runs as a different identity than whichever account ran this script. Already have a PFX from elsewhere? Import it into a store instead of using it as a file directly: Import-PfxCertificate -FilePath certificate.pfx -CertStoreLocation Cert:\CurrentUser\My -Password $pfxPassword (add -Exportable:$false when importing into Cert:\LocalMachine\My for a non-exportable copy there).

Not on Windows, or prefer OpenSSL? openssl req -x509 -newkey rsa:2048 -legacy -keyout private.key -out certificate.crt -days 730 -nodes -subj "/CN=ContactManager Exchange Sync" followed by openssl pkcs12 -export -legacy -out certificate.pfx -inkey private.key -in certificate.crt produces an equivalent PFX (the -legacy flag on both commands is what makes the key CSP-based instead of CNG). Or, to generate a PFX without ever touching a certificate store at all — not even briefly — use .NET's lower-level CertificateRequest class directly: $cspParams = New-Object System.Security.Cryptography.CspParameters(24, "Microsoft Enhanced RSA and AES Cryptographic Provider"); $rsa = New-Object System.Security.Cryptography.RSACryptoServiceProvider(2048, $cspParams); $request = New-Object System.Security.Cryptography.X509Certificates.CertificateRequest((New-Object System.Security.Cryptography.X509Certificates.X500DistinguishedName("CN=ContactManager Exchange Sync")), $rsa, [System.Security.Cryptography.HashAlgorithmName]::SHA256, [System.Security.Cryptography.RSASignaturePadding]::Pkcs1); $cert = $request.CreateSelfSigned([DateTimeOffset]::Now, [DateTimeOffset]::Now.AddYears(2)) — then export $cert with .Export(...) the same way as above; needs .NET Framework 4.7.2+ on the generating machine (where CertificateRequest comes from), and works without admin elevation since CspParameters without a KeyContainerName makes the RSA key ephemeral (never persisted anywhere).

Either path above produces certificate.cer (the public key, uploaded next — safe to share, contains no secret), plus either a certificate-store thumbprint or a certificate.pfx file (password-protected — keep confidential).

# 2. Upload the public key to the app registration

In the Microsoft Entra admin center, open the app registration (see Registering an app) → Certificates & secrets → Certificates tab → Upload certificate.
Select certificate.cer (never upload the .pfx, which contains the private key) and confirm.
The certificate now appears in the list with its thumbprint and expiry date; note the expiry so it can be renewed before then (repeat steps 1–3 with a new certificate, then update Certificate Path / Thumbprint/Certificate Password in ContactManager to point at the new one).

# 3. Configure ContactManager

Using the certificate store:

LocalMachine only: grant the ContactManager application pool identity read access to the certificate's private key: open certlm.msc on the server → Personal → Certificates, right-click the certificate → All Tasks → Manage Private Keys... → add the application pool's identity with Read access. (Not needed for CurrentUser — importing/generating under the right account already grants that account access — and not needed if the application pool identity is LocalSystem, see below.)
On the MS Exchange Configuration screen, fill in Certificate Path / Thumbprint with the thumbprint (spaces are ignored, so pasting it directly from the certificate's Details tab works) — not a file path — and leave Certificate Password empty.

A non-exportable/store certificate only works for signing because it's generated on a SHA-256-capable CSP, same as above. Signing doesn't require exporting the private key (that's the point of a non-exportable key: the CSP performs the RSA operation internally and only hands back the signature) — ContactManager tries that direct signing path first, and only falls back to the export-based workaround (which a non-exportable key would refuse) for an older PFX-sourced certificate whose CSP container doesn't support SHA-256 natively.

Using a PFX file:

Copy certificate.pfx to the ContactManager server (a location the application pool identity can read, outside the web-accessible content folders).
On the MS Exchange Configuration screen, fill in Certificate Path / Thumbprint with the full path to certificate.pfx on the server, and Certificate Password with the password chosen when it was generated.

certificate.pfx and its password are the actual secret — anyone who obtains both can authenticate as this app registration (subject to whatever mailboxes it's scoped to, see permission scoping above) until the certificate is revoked or expires. Restrict the file's permissions on the ContactManager server to the application pool identity and server administrators only, the same as any other credential file.

Either way, leave OAuth2 Client Secret empty.

# Which store, and which account?

LocalMachine\My — shared by the whole server; any process needs an explicit grant (Manage Private Keys, above) to use the private key, except one running as LocalSystem or as a member of local Administrators, both of which already have implicit access to every LocalMachine private key by default — no extra grant needed if the ContactManager application pool identity is LocalSystem specifically.
CurrentUser\My — private to one Windows account; only usable by a process actually running as that account, and only if that account's Windows user profile is loaded. For a custom or low-privilege application pool identity, check the application pool's Advanced Settings → Load User Profile is True (it's the IIS default for most identity types, but confirm for a legacy/custom account) — without a loaded profile, CurrentUser\My is effectively empty for that process even though the certificate was imported successfully.
Either store works from a LocalSystem application pool identity, but LocalMachine is the natural fit — LocalSystem doesn't have a meaningful separate "current user" profile the way a named account does.

# Converting an existing (CNG) certificate instead

If a suitable certificate already exists but was issued/exported as CNG (the Windows Certificate Export Wizard, certmgr.msc → right-click a certificate → All Tasks → Export, has no option to choose legacy vs. CNG — it always exports whichever key type the certificate already has), convert it rather than generating a new one:

From an existing CNG certificate already installed on the server: re-import it under a legacy provider with certutil -importPFX -csp "Microsoft Enhanced RSA and AES Cryptographic Provider" certificate.pfx, then export that copy with certutil -exportPFX -csp "Microsoft Enhanced RSA and AES Cryptographic Provider" <certificate-thumbprint> certificate.pfx (not the Export Wizard).
From an existing CNG PFX file, using OpenSSL: openssl pkcs12 -in certificate.pfx -out certificate.pem -nodes followed by openssl pkcs12 -export -legacy -out certificate-legacy.pfx -in certificate.pem.

The public key doesn't need re-uploading in either case — converting only changes how the private key is stored in the PFX, not the certificate itself, so the copy already on the app registration (step 2 above) still matches.

# Client secret authentication

Only use this if certificate authentication isn't an option. Under Certificates & secrets, create a client secret and enter it in OAuth2 Client Secret. Note that Microsoft is moving away from client-secret app authentication for Exchange Online, so certificate authentication is preferred for new setups.

Either way, fill in the OAuth2 ClientId field and the Domain / Tenant Name field (used as the Entra ID tenant for Graph/OAuth2 sign-in). OAuth2 ClientId and OAuth2 Client Secret are also used, separately, to set up modern OAuth2 authentication for the EWS connection (with impersonation) — see How the connection is chosen for how ContactManager tells the two uses apart.

# How the connection is chosen

If Certificate Path / Thumbprint is filled in, ContactManager connects via Microsoft Graph — a certificate is only ever used for Graph.
Otherwise, if both OAuth2 ClientId and OAuth2 Client Secret are filled in and Outlook WebAccess URL is left empty, ContactManager connects via Microsoft Graph.
If both OAuth2 ClientId and OAuth2 Client Secret are filled in and Outlook WebAccess URL is also filled in, ContactManager connects via EWS using OAuth2/impersonation instead — Outlook WebAccess URL is required for EWS and unused by Graph, so filling it in signals that the OAuth2 ClientId/Client Secret pair is for EWS, not Graph.
If none of the above are filled in, ContactManager connects via EWS using the configured mailbox Domain / Tenant Name/Username/Password.
Once Microsoft Graph is selected for a mailbox, a Graph connection or sync failure is reported as an error and is not silently retried over EWS — Microsoft is retiring EWS, so it can no longer be relied on as an automatic safety net. Fix the underlying Graph issue (see Registering an app and Known Limitations) rather than expecting sync to keep running over EWS in the background.

The EWS connection reads the same OAuth2 ClientId and OAuth2 Client Secret fields as Graph, but the app registration behind them needs different API permissions and manifest entries — see ews.md. They are not the Microsoft Graph permissions in Setup above.

To connect via Microsoft Graph using a client secret, Outlook WebAccess URL must be left empty. To keep an existing EWS connection working while adding OAuth2/impersonation, fill in Outlook WebAccess URL alongside OAuth2 ClientId/Client Secret.

Use the Test Outlook button on the MS Exchange Configuration screen to verify which connection succeeds for a given mailbox.

# Contact Synchronisation

Contacts, companies, and employees are pushed to the mailbox's contacts folder (or a named subfolder, created automatically if missing) whenever a synced field changes in CM. A contact created by CM can be found again by either connection — the link between a CM record and its Outlook contact is stored the same way on both.

Contacts marked in Outlook as "skip further updates" (via the Mark as Skipped action, reached from the "new contact found in Outlook" notification e-mail) stop receiving updates from CM until unmarked.

New or changed contacts found directly in Outlook are read back into CM the same way over either connection: an exact or fuzzy match (by e-mail, mobile, or business/home phone) updates the matching CM record; no confident match sends the "new contact found" notification e-mail with links to create the contact in CM or mark it as skipped. Over Microsoft Graph, a private/personal/confidential Outlook contact is not excluded from this the way it is over EWS, since Microsoft Graph's contact model has no such marking; fax numbers and a contact's gender are also not read back over Microsoft Graph, for the same reason they don't sync outbound (see Known Limitations).

# Appointment and Task Synchronisation

Appointments (calendar reminders) sync to the mailbox's calendar the same way over either connection.
Tasks sync to the mailbox's Outlook Tasks folder over EWS. Over Microsoft Graph, tasks instead sync to a Microsoft To Do list named "ContactManager" in the mailbox, since Microsoft Graph no longer exposes the classic Outlook Tasks folder. The task's start date is not carried over on the Graph/To Do path (To Do only has a due date and a completion date).

# Sending E-mail via Exchange

When Send e-mail via Exchange is enabled, CM-generated e-mail (activity reminders, notifications) is sent from the relevant user's own mailbox rather than through the ContactManager application mailbox, using whichever connection (Graph or EWS) is currently active.

# Known Limitations

Fax numbers, a secondary home phone, "other phone", and pager numbers sync to Outlook contacts (in both directions) only over EWS. Microsoft Graph's contact model does not have these fields.
A contact's gender is not synced over the Microsoft Graph connection, in either direction.
Over Microsoft Graph, a contact marked Private/Personal/Confidential in Outlook is still read back into CM by the inbound sync — over EWS such contacts are skipped, since Microsoft Graph's contact model has no equivalent marking to check.
A PFX with a CNG/KSP private key (see Certificate authentication) is not usable for Graph sign-in and causes a connection error rather than a working Microsoft Graph connection. The same applies to a certificate-store thumbprint pointing at a CNG-keyed certificate. Re-export or regenerate the certificate on a legacy CSP provider as described there.

# Configuration Reference

Settings on the MS Exchange Configuration screen, in the order they appear:

# Domain / Tenant Name

Using OAuth2 (Client ID + Client Secret) or certificate authentication — the connection uses Microsoft Graph (or, over legacy EWS, still authenticates as the app registration): enter the Entra ID tenant (directory) ID, or the tenant's fully qualified domain name. This can be the tenant's default *.onmicrosoft.com domain (for example contoso.onmicrosoft.com) or any other domain verified on that tenant (for example contoso.com) — just not the bare prefix (contoso on its own does not work).
Using basic authentication with only a mailbox Username/Password (no OAuth2 or certificate configured): enter the Windows domain of that mailbox account instead.

# Username / Password

Mailbox account used for EWS basic authentication. Not needed when using OAuth2 client secret or certificate authentication with impersonation.

# Outlook WebAccess URL

Base URL of the Exchange server (EWS endpoint). Use AutoDiscover Url to resolve this automatically from a mailbox address. Required for EWS; leave empty together with OAuth2 ClientId/OAuth2 Client Secret to connect via Microsoft Graph instead (not needed when Certificate Path / Thumbprint is set, which always uses Graph) — see How the connection is chosen.

# OAuth2 ClientId

Application (client) ID of the Entra ID app registration used for OAuth2/certificate authentication.

# OAuth2 Client Secret

Client secret for the app registration. Leave empty when using certificate authentication.

# Certificate Path / Thumbprint

Either a file path (on the ContactManager server) to the PFX certificate file used for certificate-based authentication against Microsoft Graph, or — if it doesn't end in .pfx — a certificate thumbprint to look up in the server's LocalMachine\My or CurrentUser\My certificate store instead. See Certificate store (recommended), or a PFX file? for a comparison and setup steps.

# Certificate Password

Password protecting the PFX file above (stored encrypted). Not used when Certificate Path / Thumbprint is a certificate store thumbprint.

# Interval

Minutes between checks for new/removed CM contacts to push to Outlook.

# Sync Changes From Outlook Timespan

Times of day (e.g. 8:00;12:30;17:30) at which changes made directly in Outlook are pulled back into CM.

# Exchange Version

Exchange server version. Automatically set to a Microsoft 365/Exchange Online value when the configured URL contains .office365..

# Enable Synchronization

Turns Exchange synchronisation on or off, independently of whether a connection is configured below — useful to pause sync temporarily (for example in a test environment) without clearing the Outlook WebAccess URL, OAuth2, or certificate settings. Enabled by default.

# Use Form Based Authentication / Use Impersonation

EWS connection options; impersonation is used automatically once an OAuth2 ClientId is filled in.

# Export Date

Read-only. Date/time up to which CM contact changes have already been pushed to Outlook.

# Send e-mail via Exchange

Sends CM-generated e-mail from the recipient's own mailbox instead of the application mailbox.

# Sync Birth Date

Includes a person's birth date in the synced Outlook contact.

# Use Home Address for Second Address

Uses the home/visitor address instead of the "other" address slot for a contact's second address.

Prefix added when syncing an employee's internal phone number to the Outlook Pager field. EWS only (see Known Limitations).

# Full Name Format / File As Format

Display name formats used for the Outlook contact's Full Name and "File As" fields.

# URL Reference

Action	Description
MsExchangeConfiguration.aspx/Details	Shows the MS Exchange Configuration screen.
MsExchangeConfiguration.aspx/Save	Saves configuration changes.
MsExchangeConfiguration.aspx/AutoDiscover	Resolves the EWS URL from the configured mailbox address.
MsExchangeConfiguration.aspx/Execute	Runs the outbound sync job once, immediately.
MsExchangeConfiguration.aspx/Verify	Test Outlook: connects to a mailbox and reports the result.
MsExchangeConfiguration.aspx/SyncMailbox	Sync Mailbox: pulls new/changed contacts from a user's Outlook folder into CM.
MsExchangeConfiguration.aspx/SendEmail	Test Email: sends a test e-mail to a given address.
MsExchange.aspx/Sync	Test Outlook connection for a given mailbox.
MsExchange.aspx/MarkAsSkipped	Marks an Outlook contact as skipped for further updates. Restricted to the calling user's own mailbox (or an administrator).

# CM Configuration Changes

Exchange synchronisation is enabled as soon as any of Outlook WebAccess URL, Certificate Path / Thumbprint, or both OAuth2 ClientId and OAuth2 Client Secret are filled in. A mailbox fully migrated to Microsoft Graph via a certificate no longer needs a vestigial Outlook WebAccess URL just to keep sync running; a mailbox using Microsoft Graph via a client secret must leave Outlook WebAccess URL empty (see How the connection is chosen) rather than just leaving it there unused. Unchecking Enable Synchronization turns sync off regardless of what's configured below it.
Setting a URL containing .office365. automatically switches Exchange Version to the Microsoft 365 setting.
Filling in OAuth2 ClientId automatically enables impersonation.

# Field Mapping Reference

# Person to Outlook Contact

CM field	Outlook contact field
Full name / File As (formatted)	Full Name / File As
Last name, prefix, initials, first name	Surname, Middle Name, Initials, Given Name
Birth date (if enabled)	Birthday
Phone number	Home Phone
E-mail address	E-mail 1
Mobile number	Mobile Phone
Notes (if enabled)	Notes/Body
Visitor address	Home Address
Postal address	Business Address or Other Address (depending on configuration)
Photo	Contact Picture

# Company to Outlook Contact

CM field	Outlook contact field
Name	Company Name
Website	Business Home Page
Phone number	Business Phone
Mobile number	Mobile Phone
E-mail address	E-mail 1
Notes (if enabled)	Notes/Body
Postal address	Business Address
Visitor address	Home Address or Other Address (depending on configuration)

# Employee to Outlook Contact

CM field	Outlook contact field
Job title	Job Title
Department	Department
Company name, website	Company Name, Business Home Page
Phone number	Business Phone
Mobile number (or the person's, if not set)	Mobile Phone
E-mail address	E-mail 1
Room number	Office Location
Spouse, secretary information	Spouse Name, Assistant Name

# Activity to Outlook Appointment or Task

CM field	Outlook field
Activity name / matter	Subject
Description	Body
Follow-up date, reminder	Due Date / Reminder
Completed	Task status (EWS) / Completion (Graph, via To Do status)
Start/end time (appointments)	Start/End
Location (appointments)	Location

ews.md — app registration for the legacy Exchange Web Services (EWS) connection, which Microsoft no longer develops and is retiring. Needed only while a mailbox still connects over EWS.