Skip to main content

Connecting Microsoft Exchange On-Premises (EWS) to Zeeg

Learn how to connect your on-premises Microsoft Exchange server to Zeeg to sync calendar availability and manage bookings — without exposing credentials or granting administrative access.

J
Written by Julika Templin

Zeeg connects to your Exchange server as a standard EWS client over HTTPS. There are two ways to connect — directly with a user's own Exchange credentials, or via a dedicated service account that acts on behalf of multiple users. You control the network exposure, the account permissions, and can revoke access at any time.

Microsoft Exchange integration is available on all paid plans (Professional, Business, Scale, and Enterprise).

For our general data-protection and infrastructure stance, see also: GDPR Compliance and our Privacy Policy.


How the integration works

Zeeg acts as a regular EWS (Exchange Web Services) client. Zeeg connects outbound to your Exchange server's EWS endpoint (typically https://mail.yourcompany.com/EWS/Exchange.asmx) over HTTPS and uses standard EWS operations to read availability and create, update, or cancel calendar events.

  • Protocol: EWS over HTTPS. (No ActiveSync, no IMAP/SMTP, no MAPI).

  • Direction: Outbound from Zeeg to your Exchange server. (No inbound connection into your network, no agent to install).

  • Authentication: Basic and NTLM (negotiated automatically). For Microsoft 365 / Exchange Online, please use Zeeg's dedicated Microsoft 365 integration instead, which uses OAuth via Microsoft Graph.

  • Data scope: Calendar only. Zeeg does not read mail, contacts, tasks, or any other Exchange folder.


Two ways to connect: personal credentials or a service account

Option 1 — Personal Exchange account (per user)

The simplest setup. Each user connects their own Exchange account from Zeeg's Calendars settings by providing:

  • Email address

  • Username (UPN, DOMAIN\username, or SAM account name — all accepted)

  • Password

  • EWS server hostname (or full URL)

  • Optional: domain (for NetBIOS-style logins)

Zeeg uses those credentials only to access that user's own calendar. No impersonation, no delegation.

Use this when: you only need a few users connected, or your security policy doesn't require a shared service account.

Option 2 — Service account with impersonation (recommended for organisations)

For organisation-wide rollouts, we strongly recommend a dedicated service account with the ApplicationImpersonation RBAC role on Exchange. Your organisation administrator connects the service account once in Zeeg, then enrols the users who should be able to use the integration. Zeeg uses the service account credentials, together with the standard EWS impersonation header, to act on behalf of each enrolled user.

Why it's better:

  • One set of credentials, centrally managed by your IT team.

  • No personal passwords for the enrolled users are stored anywhere in Zeeg.

  • You can scope the service account to specific OUs or AD groups (see below).

  • Revoking access for everyone is a single operation on your side.


Setting up a service account on Exchange On-Premises

These steps run on your Exchange server (Exchange Management Shell). They follow Microsoft's standard ApplicationImpersonation pattern.

1. Create a dedicated service account

Create a normal, mailbox-enabled Active Directory user dedicated to the Zeeg integration — for example svc-zeeg@yourcompany.com. Don't reuse a personal account.

Recommendations:

  • Strong, machine-generated password.

  • Password set to never expire — or document your rotation procedure (you must reconnect in Zeeg whenever it rotates).

  • Not a member of any privileged group (Domain Admins, Exchange Admins, etc.).

  • Mailbox-enabled (required for impersonation to work).

2. Grant ApplicationImpersonation — organisation-wide

If you want the service account to be able to act on behalf of every mailbox in the organisation:

New-ManagementRoleAssignment `

-Name "ZeegImpersonation" `

-Role "ApplicationImpersonation" `

3. Grant ApplicationImpersonation — scoped (recommended)

To limit which mailboxes the service account can touch (least privilege), create a management scope first:

New-ManagementScope `

-Name "ZeegScope" `

-RecipientRestrictionFilter "MemberOfGroup -eq 'CN=Zeeg Users,OU=Groups,DC=yourcompany,DC=com'"

New-ManagementRoleAssignment `

-Name "ZeegImpersonation" `

-Role "ApplicationImpersonation" `

-CustomRecipientWriteScope "ZeegScope"

Only users in the Zeeg Users AD group can then be acted on through this service account — everyone else is unreachable through it, even if someone tried.

4. Verify the assignment

Get-ManagementRoleAssignment -Role ApplicationImpersonation

5. Confirm EWS is reachable

  • EWS must be enabled for the service account.

  • Any reverse proxy in front of OWA/EWS must allow EWS through without breaking NTLM or Basic authentication.

  • Make sure Exchange throttling policies (EWSMaxConcurrency, EWSPercentTimeInAD, etc.) aren't aggressive enough to block normal scheduling activity.

6. Connect in Zeeg

In Zeeg, navigate to your organisation's Integrations → Microsoft Exchange (Service Account) and enter:

Then enroll the users who should be able to use the integration. Each enrolled user will see their calendar in Zeeg without needing to enter any credentials.


Network requirements

Requirement

Detail

Protocol

HTTPS (TCP/443) to your EWS endpoint

Direction

Outbound from Zeeg → your Exchange server

Access to internal systems

None — Zeeg does not connect to Active Directory or any other internal service

Inbound to Zeeg

None — Zeeg never opens a connection into your network


Firewall allowlisting

If your EWS endpoint isn't reachable from the public internet (recommended), you can allow inbound traffic from Zeeg's outbound IP address(es). Contact us at support@zeeg.me and we'll share the current value(s) for your firewall team to add to your allowlist.

This is the recommended setup for enterprise customers: keep EWS off the open internet and allow it only from Zeeg's known source addresses (plus any other clients you legitimately need).


Security — what Zeeg does, what you do

Zeeg's responsibility

  • Encryption in transit. All connections to your EWS endpoint are made over HTTPS. The connection terminates at your Exchange / reverse proxy, so the effective TLS configuration (versions, ciphers, certificate) is whatever your endpoint presents — see "your responsibility" below for the hardening we recommend.

  • Encryption at rest. Service account and user credentials are stored encrypted. They are never written to disk or logs in clear text.

  • Least privilege by design. The integration uses Exchange calendar functionality only. Mail, contacts, tasks, and other folders are out of scope.

  • Easy disconnect. Administrators or end users can disconnect the integration at any time from Zeeg's settings. Once disconnected, the stored credentials are deleted. (Note: disconnecting in Zeeg does not invalidate the password on your Exchange — disable the account or rotate the password on your side if you need a hard revocation.)

  • Infrastructure. All Zeeg data is processed in Germany on the Open Telekom Cloud (ISO 27001, ISO 27017, ISO 27018, BSI C5). See GDPR Compliance for the full picture.

Your responsibility (as the on-premises operator)

  • TLS hardening of the EWS endpoint — valid certificate from a trusted CA, modern TLS versions only, strong cipher suites.

  • Network exposure — ideally, restrict EWS to Zeeg's source addresses (and any other clients you need), rather than exposing it to the open internet.

  • Service account hardening — dedicated mailbox-enabled account, scoped ApplicationImpersonation, strong password, no membership in privileged groups.

  • Logging & monitoring — enable EWS access logging on Exchange / your reverse proxy, and review it as part of your normal SIEM workflow.

  • Account lifecycle — your standard procedure for disabling the service account, rotating its password, and removing the role assignment when you stop using Zeeg.

In short: Zeeg behaves as a well-behaved EWS client. The hardening of the EWS endpoint, the network controls, and the configuration of the service account stay in your hands — which is exactly how on-premises Exchange is designed to work.


FAQ

Which Exchange versions are supported?

Exchange 2013 and later on-premises versions that expose EWS over HTTPS with Basic or NTLM authentication. (Exchange Online / Microsoft 365 customers should use the dedicated Microsoft 365 calendar integration, which uses OAuth via Microsoft Graph instead.)

Does Zeeg need access to Active Directory?

No. Zeeg talks only to your EWS endpoint over HTTPS.

Does Zeeg need administrative rights on Exchange?

No. The only role needed is ApplicationImpersonation (for the service account flow) — scoped as tightly as you like. No Exchange admin role, no Domain Admin, nothing else.

What if Autodiscover doesn't work?

Provide the full EWS URL directly in the connection form, e.g. https://mail.yourcompany.com/EWS/Exchange.asmx. Zeeg will use it as-is.

What data does Zeeg actually read?

For each enrolled user: calendar items in the user's primary mailbox calendar (and any secondary calendars they choose to enable in Zeeg). Specifically, busy/free times and the fields needed to create, update, and cancel events. Zeeg does not read mail, contacts, tasks, or any other folder.

What address(es) will Zeeg connect from, so we can allowlist them?

Email support@zeeg.me and we'll share the current value(s) with your IT/security team.

How do I fully revoke Zeeg's access?

Two options, on your side or ours:

1. On Exchange (recommended for a hard cut-off): disable the service account, rotate its password, or remove the management role assignment

Remove-ManagementRoleAssignment -Identity "ZeegImpersonation"

2. In Zeeg: disconnect the integration from your organisation settings. The stored credentials are deleted.

What if the service account stopped working after a password change?

Reconnect the integration in Zeeg with the new password. Password changes on your side are not picked up automatically.

Can I limit which users the service account can act on?

Yes — use the scoped New-ManagementScope + New-ManagementRoleAssignment pattern shown above. Only users matching the scope will be reachable.

Still have questions? Reach out at support@zeeg.me.

Did this answer your question?