Exchange Server for IT administrators

A user in your organisation wants to connect the calendars in their Exchange mailbox to Calendox. They sign in with their mailbox address and Exchange password from the Exchange Server card — the user steps are in Connect Exchange Server Calendar. This page lists what Calendox needs from your environment, how it signs in, how to allow or audit it, and what happens when a mailbox moves.

Calendox reaches Exchange Server through Exchange Web Services (EWS) — the same interface Outlook for Mac, Outlook mobile and most third-party calendar tools use. Exchange Server continues to provide EWS; the announced EWS retirement concerns Exchange Online only.

What does Calendox need from your environment?

How does Calendox sign in?

Calendox signs in to EWS with the user's mailbox address (or DOMAIN\user) and Exchange password over Basic or NTLM authentication. Microsoft sign-in to an on-premises server is not currently offered, so a server that accepts only Negotiate/Kerberos, or only Microsoft sign-in, cannot be connected.

To enable password sign-in on the EWS virtual directory:

Set-WebServicesVirtualDirectory -Identity "<server>\EWS (Default Web Site)" -BasicAuthentication $true

or, for NTLM:

Set-WebServicesVirtualDirectory -Identity "<server>\EWS (Default Web Site)" -WindowsAuthentication $true

Security note. Basic and NTLM sign-in to EWS do not go through multi-factor authentication, and a pre-authentication proxy in front of EWS (ADFS, Entra Application Proxy, an MFA gateway) blocks password sign-in for cloud apps. If password sign-in to EWS is not acceptable for your organisation, do not enable it — Calendox then cannot connect to your server. The password is stored encrypted by Calendox, used only against the EWS endpoint recorded at connect time, and deleted when the user disconnects the calendar or deletes their account.

How can changes reach Calendox sooner?

Nothing further is required for sync: Calendox checks each connected calendar on its own, and changes reach it within about 5 minutes. Optionally, allow your Exchange server outbound HTTPS to https://calendox.com/api/calendar/exchange/notifications/ — then the server can tell Calendox about a change as it happens, and changes arrive sooner. If that address stays blocked, nothing breaks and there is nothing to configure; the user's account card simply notes "Your server isn’t reaching Calendox yet — changes sync every 5 minutes."

How do I allow or audit Calendox?

Calendox identifies itself on every request with the user agent Calendox/1 (+https://calendox.com/docs/integrations/exchange-on-premises), so you can allow or audit it by user agent; the entry Calendox/* matches it. EWS access is set for each mailbox and for the whole organisation, so check both, then change only what blocks Calendox:

Get-OrganizationConfig | Format-List EwsEnabled,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockList
Get-CASMailbox <user> | Format-List EwsEnabled,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockList

# Only if the mailbox shows EwsEnabled False:
Set-CASMailbox <user> -EwsEnabled $true

# Only if the mailbox shows EnforceAllowList (adds; existing entries stay):
Set-CASMailbox <user> -EwsAllowList @{Add="Calendox/*"}
# Only if the organisation shows EnforceAllowList (adds; existing entries stay):
Set-OrganizationConfig -EwsAllowList @{Add="Calendox/*"}

# Only if the mailbox shows EnforceBlockList and an EwsBlockList entry matches Calendox (removes that entry only):
Set-CASMailbox <user> -EwsBlockList @{Remove="<matching entry>"}
# Only if the organisation shows EnforceBlockList and an EwsBlockList entry matches Calendox (removes that entry only):
Set-OrganizationConfig -EwsBlockList @{Remove="<matching entry>"}

EwsEnabled False on the organisation turns EWS off for every mailbox, whatever the mailbox setting says: no mailbox or allow-list change helps, and Calendox cannot connect until the organisation setting is True or blank — an organisation-wide decision. Use the @{Add=…} and @{Remove=…} forms shown: a plain list such as -EwsAllowList "Calendox/*" replaces every entry already on the list. If the block-list entry that matches Calendox is a wildcard that also matches other apps, removing it unblocks them too; to keep them blocked, first add narrower entries for them with @{Add=…}, then remove it. Calendox never needs EwsApplicationAccessPolicy itself changed. A change may not apply immediately.

Calendox reads only the user's own calendar folders and reads and writes calendar items in them. It never reads mail, contacts or other mailboxes, and it never stores event titles, descriptions or locations — only timing and a content fingerprint.

How do I check the setup before users try?

1. Run the Microsoft Remote Connectivity Analyzer's Exchange Web Services check against the external EWS name — it verifies publishing, the certificate chain and authentication in one pass.
2. Open https://autodiscover.example.com/autodiscover/autodiscover.json/v1.0/alex.winters@example.org?Protocol=EWS (with your own domain and a real mailbox) from outside your network; a JSON answer with the EWS URL means users can connect by address alone.
3. Open https://mail.example.com/EWS/Exchange.asmx from outside your network; a sign-in prompt is the expected result.

How do I revoke a user's access?

The cleanest way is for the user to remove the calendar in Calendox: that deletes the copies Calendox made in the mailbox, then the stored username and password. From your side, changing the user's password makes the next request fail and Calendox asks the user to update the stored password. Disabling EWS for the mailbox (Set-CASMailbox <user> -EwsEnabled $false) makes every request fail from then on and the user's syncs stop receiving and sending changes. Calendox then tells the user once — by email, in-app and on the account card (Access limited) — and offers them a message for you: for a calendar that is the source of an active sync, after about an hour without a working connection; for any other calendar, when a booking page or the Unified Calendar next meets the refusal, the user deletes an event in Calendox that has a copy there or a sync can't copy an event into it, and a second request is refused too, never within an hour of the user connecting it, updating its password or changing its syncs. Calendox also can no longer delete the copies it made in that mailbox: until the user has been told, removing a calendar that holds such copies fails, and afterwards the user can remove it only by confirming that those copies stay in the mailbox. To have the copies deleted, ask the user to remove the calendar first.

What happens when you move a mailbox?

Calendox's connection stays with the external EWS name it was set up on. Moving a mailbox between databases or servers inside your organisation, behind that same name, usually needs nothing from the user while the name still reaches the mailbox — Exchange routes Calendox's requests to the mailbox's new server; changes may pause while the move completes. The connection doesn't follow a mailbox to Microsoft 365 or to another organisation's Exchange server, and doesn't survive that name being retired: after such a move, the user removes the account, connects the mailbox again where it now lives and re-creates their syncs — see What if my mailbox moves or becomes unavailable?. Copies Calendox placed in the mailbox move with it and stay there; the user can delete them in Outlook.

For a calendar that is the source of an active sync, Calendox tells the user once — by email, in-app and on the account card (Mailbox unavailable) — when nothing has worked for 24 hours and a second check agrees: the server answers that the mailbox isn't there, can't be reached or keeps failing, or a move is still in progress. Any other calendar gets the same message only for the server's answer that the mailbox isn't there, when a booking page or the Unified Calendar next meets it, the user deletes an event in Calendox that has a copy there or a sync can't copy an event into it, and a second check agrees — never within 24 hours of the user connecting it, updating its password or changing its syncs. The user can send you the card's message, which lists what to check (mailbox_unavailable below). Right after that, Calendox asks your organisation's own Autodiscover once where the mailbox lives now — the addresses of the user's own email domain (for example autodiscover.example.com, then example.com), without signing in and without following a redirect to another domain. If it answers with Microsoft 365, the card says the mailbox appears to have moved to Microsoft 365; the email doesn't change. Either way the user first checks with you where the mailbox lives now, and if it didn't move, Update password on the card resumes the connection once Exchange opens the mailbox again. Calendox asks the same once when Microsoft 365 stops serving a work or school mailbox connected through the Outlook Calendar card: if your server then answers with its own Exchange Web Services address, that card says the mailbox appears to have moved to your Exchange Server, and the user connects it from the Exchange Server card once you confirm the move.

Which messages may users send me?

A user whose sign-in was blocked can send you a message straight from the connect dialog. When a calendar that was already connected stops working and the fix is yours, they can send it from its account card or from the email Calendox sent them; that message opens "Hi — my Exchange calendar was connected to Calendox and stopped working.", and the email's copy leaves out the server name. A work or school mailbox connected through the Outlook Calendar card that appears to have moved to your Exchange Server offers one too, on its account card only; it opens "Hi — my Microsoft 365 calendar was connected to Calendox and stopped working." Each carries one of these codes — what it means and what to do:

Next steps

• Connect Exchange Server Calendar — the user's steps, what works, and the messages they may see
• Sync status — every sync status value and how to get a sync back to Active
• OAuth permissions — what Calendox accesses for every provider