When teams need the OX App Suite ActiveSync connector
If your organization needs mail, calendar and contacts on phones from OX App Suite, the Connector for Business Mobility over Exchange ActiveSync is the module to evaluate. It is a separately identified module: Open-Xchange may license and price modules beyond core mail, calendar, contacts and tasks separately, and the license agreement decides whether this connector is included in your entitlement. Confirm that entitlement with Open-Xchange before you plan a mobile rollout, because a technical fit does not establish that you are licensed to run it.
The rest of the platform is deployed as OX App Suite v8 on Kubernetes, with Helm charts referencing container images, and the connector runs on that same stack. That matters for planning. The connector's ingress, its session handling and its dependency on the shared data services sit inside the cluster you already operate or intend to build, so the question is less whether phones can connect and more whether your Kubernetes, ingress and identity design can carry mobile sync traffic from devices you do not fully control. Review the platform decisions in the requirements documentation before you commit to a topology.
Teams usually reach for this connector when they have a mix of device types, managed and personal phones, and users who expect native mail apps to behave the way they did on their previous platform. If your users already run IMAP, CalDAV and CardDAV clients successfully, the connector is worth evaluating only where native Exchange ActiveSync behavior, such as push-style delivery of mail and calendar changes or device policy handling, is a requirement. Write down which of those behaviors your users depend on. That list becomes the acceptance test for the module and the basis for comparing it against the protocol clients.
Before scoping work, ask Open-Xchange for three things in writing: whether the connector is included in your license or priced separately, the current documentation for the connector and the v8 release you intend to run, and any supported-version or compatibility limits for the mobile clients and device platforms your users carry. Do not assume limits from older material or from other OX products. Connector-specific limits and versions change between releases, so the figures in the vendor's current documentation govern, and your implementation plan should cite that documentation directly.
Plan for the risks that surface late in mobile projects. Device policy and remote wipe behavior depend on what your identity and access model allows, so align them with your single sign-on design before pilot users enroll. Certificate trust on phones, public endpoint exposure and the ingress path all need a test plan on real devices, not only in a lab. Finally, decide who owns the connector after go-live: your platform team, a partner under a support retainer, or Open-Xchange, and confirm how upgrades to the connector follow the platform's support commitment.
What the connector does according to the platform documentation
The connector brings OX App Suite mail, calendar and contacts to phones through Exchange ActiveSync. The cards separate what the platform documents from what you must confirm with the vendor and in your own pilot. Treat each item as a test case: the protocol sets the baseline, but device behavior and deployment settings decide what users actually experience.
Mail sync over Exchange ActiveSync
The connector synchronizes mailboxes from OX App Suite to phones over Exchange ActiveSync, which is the first function the platform documentation describes. Confirm which mail folders synchronize, how far back message history loads on a new device, and how attachments are downloaded to the handset. Test these with a sample mailbox on each device type you support, since mail behavior on phones often differs from the webmail client.
Calendar sync to native apps
Calendar events move to the device through the same protocol, so meetings, invitations and responses should appear in the phone's native calendar application. Confirm in the vendor documentation how recurring series, shared calendars and time zone changes are handled. In your pilot, create a recurring meeting, accept an invitation from the phone and check that the change appears in the web client.
Contacts sync to the phone
Personal contacts from OX App Suite synchronize to the phone's contacts application over the same protocol. Confirm which address books are included, whether distribution lists sync, and how the device handles duplicate entries. Also ask the vendor whether devices can search a global address list, since this is a separate capability that needs confirmation before you plan around it.
Push and sync timing
Whether changes reach the device immediately or on a schedule affects battery use, data consumption and how quickly users see new mail. Confirm the push behavior, the fallback polling interval and how the connector behaves on networks that limit long-lived connections. Measure delivery delay and battery impact on a test device over a full working day before you set expectations for users.
Device policy and access control
Exchange ActiveSync clients generally expect the server to enforce device policies such as passcode requirements, encryption and remote wipe. Confirm in the vendor documentation which policies the connector enforces, how they are assigned to users or groups, and how a lost device is wiped. Test each policy on a device and verify the result in the administration view.
Supported device platforms and clients
Phone operating systems and native mail clients implement the protocol to different degrees. Ask the vendor for the supported operating system versions and client applications, then confirm which versions your organization must support. Build a pilot matrix that covers your current fleet and any personally owned devices, and record which features work on each version.
Choosing between the ActiveSync connector, IMAP and CalDAV or CardDAV clients
This table compares the OX App Suite ActiveSync connector with IMAP and SMTP clients and with CalDAV and CardDAV clients on device support, licensing, remote wipe, scale and support effort. Read each row as a question to confirm with Open-Xchange and your device inventory, because the connector's device list and license terms set the answer. The main takeaway is that the connector is the option that brings server-side device control, and it adds licensing and a component to run.
| Decision | ActiveSync connector | IMAP and SMTP clients | CalDAV and CardDAV clients |
|---|---|---|---|
| Device platform support | Built for phones that use Exchange ActiveSync. Confirm each device platform and OS version against the connector's compatibility list. | Mail works on most mail apps. Calendar and contacts depend on the app, so confirm the client in use. | Calendar and contacts work on clients that implement these protocols. Confirm native support on each platform in your fleet. |
| Licensing | Licensed as a separate module. Confirm terms and any fees in the license agreement, since module-level packaging may apply. | Confirm with Open-Xchange whether IMAP and SMTP access is covered by your current license terms. | Confirm whether CalDAV and CardDAV access is included in your license or priced separately. |
| Device management and remote wipe | Designed around device policy and remote wipe. Confirm which policies and wipe actions the connector enforces on your devices. | Account revocation on the server is the main control. Confirm whether your MDM can enforce policy on these apps. | Account revocation on the server is the main control. Confirm whether your MDM can manage these apps and wipe their data. |
| Number of devices and users | Each phone keeps its own sync state, so device count drives connector load. Size from your device inventory and confirm limits with Open-Xchange. | Each client holds its own connection and cache. Load depends mainly on mail volume and folder count. | Each device adds calendar and contact collections. Confirm sync limits and collection counts before rollout. |
| Support effort | Adds a component to monitor, with device enrollment, policy profiles and sync troubleshooting to own over time. | Little added infrastructure for mail, but users reconfigure clients and support runs per app. | Support spans more client variants, since each calendar and contact app behaves differently. |
| When it fits | Fits when you need managed mobile sync with server-side device control, the device fleet is supported, and the license covers it. | Fits mail-first users on desktop or personal devices where remote wipe is not a requirement. | Fits standards-based calendar and contact sync across clients, with mail access handled separately. |
How the ActiveSync connector runs on the App Suite v8 stack
The connector runs on the App Suite v8 platform, so the decisions that affect phone sync are largely made before the connector is installed. App Suite v8 is delivered as Helm charts that reference container images on Kubernetes, and the documented requirement is Helm 3.17.0 or newer. Confirm with Open-Xchange whether the connector ships through the same chart set and image registry as the core release, and which chart version pairs with your App Suite release. Ask whether the connector adds Helm values, namespaces, secrets or custom resources that your change process will need to review before deployment.
Istio is the documented service mesh requirement for v8, and Open-Xchange supports the latest Istio release plus two prior versions. Where Istio cannot be used, a basic ingress-nginx option is documented. For mobile sync, this choice defines the path a phone takes to reach the server. The ActiveSync endpoint must be reachable from the networks where devices connect, terminate TLS with certificates the devices trust, and route sync requests to the correct middleware service. Decide the ingress early, because it determines certificate handling, mesh policy and how client addresses appear in logs. Confirm with Open-Xchange whether the connector needs specific timeout or request size settings on the chosen ingress.
App Suite v8 uses Redis 7.4.x for caching and session storage. The default deployment uses the littlered operator, and unmanaged or custom Redis setups can be configured. Session state affects whether a device's repeated sync cycles resume cleanly after a pod restart or a connection moves to another node. Treat Redis as a dependency of sign-in and sync, not as a disposable cache. Decide between the operator and an existing managed Redis service, and confirm with Open-Xchange which topology, persistence and eviction settings are supported for session data used by the connector.
MariaDB with the InnoDB storage engine is the primary data store for v8. Supported versions are 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported. Device sync state and PIM data depend on this database, so its backup and failover plan directly shapes recovery for mobile users. Ask Open-Xchange which schemas or tables the connector creates or writes, and whether it requires a dedicated database user or additional grants. Persistent data, including PIM attachments, must sit on a distributed file system: NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Device attachment retrieval depends on that storage, so test its latency under sync load. Finally, confirm in writing whether the connector adds any components, ports or external dependencies to this stack.
How the connector rollout runs, step by step
The sequence takes the connector from a licensing check to supported production use. Each step closes with a written artifact your team keeps, so the rollout stays traceable from the first contract review to handover.
Confirm licensing and module entitlement
Your legal and product owners review the license agreement with Open-Xchange to confirm that the connector is included in your entitlement. The operations guide notes that some modules may carry custom packaging, limitations or separate fees, so the device and user scope must be checked against the written terms. DeployOpen reviews the agreement with you and flags gaps for the vendor to answer. The step is done when a written entitlement note lists the modules, user counts and any device-related terms that apply.
Confirm the release and support window
Choose the release line before any build starts. Standard releases are supported for 12 weeks, ending with the availability of the third following release, while an LTS release is supported until the next LTS release plus six months. Compare the current LTS line and the newest release in the support commitment with your change calendar, then confirm the target version with Open-Xchange. The step is done when a signed release decision record names the target version and its end-of-support date.
Size the environment against platform requirements
The platform team checks the target cluster against the published requirements. That covers supported Kubernetes versions, Helm 3.17.0 or newer, Redis 7.4.x, a supported MariaDB line with InnoDB, and persistent storage for attachments on NFS or object storage suited to your scale. Confirm with the vendor how device session load translates into capacity, since that figure depends on your user count. The step produces a sizing sheet and bill of materials for each environment, and it is done when the staging cluster passes preflight checks.
Configure ingress, Istio routing and device TLS
Use Istio where your platform supports it, or the basic ingress-nginx option where Istio cannot be used. Mobile devices reach the sync endpoint over HTTPS, so hostnames, routing rules and the certificate chain are set and tested together. If devices must trust a private certificate authority, confirm how that root reaches managed devices before the pilot. The step produces routing manifests, the certificate chain and a test log showing successful connections from a test client on each network path.
Connect identity and test sign-in
Connect the platform to your identity provider using OpenID Connect, which App Suite supports for single sign-on, or the SAML login configuration documented for the middleware. Confirm with the vendor how device sign-in flows handle multi-factor prompts and password changes, since these vary by client. Test with dedicated accounts covering standard users, administrators, locked accounts and expired passwords. The step is done when a documented sign-in test matrix passes and the claim mapping is recorded.
Run a pilot with a small device set
Select a small group of users and the device types you support, such as iOS and Android handsets and any managed devices your policy requires. Verify mail, calendar and contact sync in both directions, push delivery, attachment handling, and recovery after a password change. Record each defect with its device model and operating system version. The step produces a pilot report with the open issues, the fixes applied and a documented go or no-go decision.
Roll out in phased user groups
Move users to the connector in waves, starting with IT staff and then moving through departments with different device mixes. Watch the sync logs, session behavior in Redis, and support tickets after each wave, and keep the rollback path to the previous access method ready until the wave is accepted. Update user guidance for each group before its move. The step is done when each wave has a sign-off record and the full user population is on the connector.
Hand over runbooks, configuration and support ownership
Transfer the operating knowledge to your team. The handover pack covers certificate renewal, upgrades, Redis and MariaDB operations, backup restore tests and the escalation path for device sync faults. Store the configuration in your own repository and name an owner for each runbook. If you want ongoing support, a retainer can be scoped separately. The step closes when your team signs the acceptance record, which lists the artifacts handed over and the named owners.
Data setup and moving existing phone sync into the connector
Before the connector goes live, the team needs a clear picture of which data it reads and where that data sits. The connector serves mailboxes, calendars and contacts that already live in OX App Suite, so it does not hold a separate copy of them. Primary data is stored in MariaDB, which App Suite v8 uses with the InnoDB storage engine. Supported MariaDB versions are 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported. Confirm with your DBA which of these versions and topology you will run, because the connector's sync state and the account data it relies on follow the same database platform as the rest of App Suite.
PIM attachments are stored outside the database on the distributed file system. For small to mid-size deployments this is typically NFS, and for larger ones object storage such as AWS S3, Ceph RadosGW or Scality RING. Phones pull attachments through the connector, so slow or unavailable file storage shows up on the device as missing or late attachments, not as a clear server error. Check that the file system or bucket that holds PIM attachments is sized, backed up and reachable from every node that will serve ActiveSync traffic, and that the same storage view applies to the App Suite nodes behind the connector.
The migration questions begin with the users who already sync a phone. Some will have an existing profile on a device, configured through another mechanism such as an IMAP account, a CalDAV or CardDAV client, or a profile pushed by a previous mobile management tool. Decide, per user group, whether they move to the connector in one cutover or in waves, and whether the old profile is removed by policy or by the user. Devices that enroll again need the new server settings and credentials, so plan a support path for users who cannot complete enrollment on their own and for shared or kiosk-style devices.
Cached data is the part teams most often underestimate. A phone that held a full mailbox under the old method keeps those messages, folders and contacts until it resyncs or the old account is removed. Removing the old account can delete local copies, which matters if users have unsynced drafts or local-only contacts. Ask Open-Xchange which import or cutover path applies to the connector and whether any tool exists to carry state from an existing profile. No migration tool for the connector is confirmed in the facts available to DeployOpen, so do not assume one, and do not promise users that history or local settings will move automatically until that answer is in writing.
Validation should happen on a pilot group before any wider rollout. For each test device, check that the folder tree matches what users expect, that calendars show the right events and time zones, that contacts resolve correctly in both directions, and that attachments open. Repeat the checks after a forced resync and after a password change. Record the results per device model and operating system version, because differences between phone platforms are common. Agree in advance who signs off on the pilot and what rollback looks like if folders or contacts are missing.
What drives implementation effort and how to keep it down
This table lists the factors that change how much work an Exchange ActiveSync connector deployment takes, and whether each one is paid once or keeps costing money. Read each row as a question to answer during scoping, with the reduction tactic beside it. The main takeaway is that device mix, the existing Kubernetes and Istio setup, and the security review of a mobile endpoint usually shape the schedule more than the connector itself.
| Driver | One-time or recurring | Why it changes effort | How to keep it down |
|---|---|---|---|
| Users, devices and platform mix | Recurring | Each device family (iOS, Android, other ActiveSync clients) behaves differently, so more platforms mean more test cases and support questions. | Confirm the device list and platform split early, and limit the first wave to the platforms your users actually run. |
| Licensing and entitlement checks | One-time, then recurring at renewal | The connector is a separately licensed component, so entitlement terms must be confirmed before build starts. Terms may vary by agreement. | Ask Open-Xchange in writing which modules and user counts the agreement covers, and confirm this before scoping the build. |
| Existing Kubernetes and Istio or ingress state | One-time | OX App Suite v8 is delivered as Helm charts on Kubernetes and requires Istio, with ingress-nginx as a basic alternative where Istio cannot be used. Gaps in the cluster add setup work. | Document the cluster version, Helm version and service mesh state before scoping, and check that the Kubernetes version falls within the supported N-1 or N-2 range. |
| Storage backend choice and sizing | One-time for design, recurring for growth | Attachments and Drive-related data must sit on a distributed file system such as NFS or object storage. Choosing and sizing this backend affects sync and backup design. | Size storage from the expected mailbox and attachment profile, and choose the backend against the scale and existing infrastructure you control. |
| Identity integration complexity | One-time, with recurring access reviews | Device sign-in must work with the identity provider that OX App Suite uses, whether OpenID Connect or SAML. Mixed directories and multiple sign-in paths add test and troubleshooting time. | Pick one identity source of truth, confirm which login method the connector will use, and test device sign-in with a small pilot group. |
| Device-management policies to test | Recurring | Each mobile policy you enforce (passcode, encryption, remote wipe, app restrictions) must be tested on every platform, and results change with OS updates. | Limit the policy set to what your security baseline requires and keep a repeatable test script for each platform release. |
| Migration from existing sync | One-time | Moving devices off an existing sync method or a previous mail client can duplicate items, break profiles or leave stale accounts behind. | Agree a cutover plan with a pilot group, confirm how existing devices are migrated, and plan a rollback window before the wider rollout. |
| Security review of exposing a mobile endpoint | One-time, with recurring review after changes | The connector creates a publicly reachable endpoint for mobile devices. The exposure, authentication, rate limits and logging need review before go-live. | Review the endpoint design with your security team early, reuse your existing gateway and access controls where possible, and keep evidence of the review for your assessors. |
How the connector connects to identity, storage and the rest of the platform
A working connector deployment depends on six connections: identity, ingress, data stores, file storage, sibling modules and the device controls around them. Each one is shared with the rest of App Suite, so decisions made here affect mail, calendar and contacts for every user, not only phone sync. Settle them during design, before cutover.
Single sign-on and identity provider
App Suite supports single sign-on through OpenID Connect, and Open-Xchange documents SAML login configuration for the middleware. Confirm with Open-Xchange which login path the connector and the devices it serves can use, and whether your identity provider, such as Keycloak or authentik, supports that flow. Check how device credentials, token lifetimes and account lockout behave when a user changes a password or loses a phone.
Istio and ingress routing
App Suite v8 requires Istio, and the supported Istio releases are the latest plus two prior versions. A basic ingress-nginx option exists only where Istio cannot be used, so confirm that path before choosing it. Device traffic enters through this routing, so plan hostnames, TLS termination, certificate renewal and timeouts for long-held sync connections, then test them from a mobile network outside your office.
Redis and MariaDB dependencies
App Suite v8 uses Redis 7.4.x for caching and session storage, deployed by default through the littlered operator, with unmanaged or custom Redis also configurable. MariaDB with the InnoDB engine is the primary data store, with supported versions 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported. Decide who operates each service, how backups and failover work, and confirm that your connector version and MariaDB release both appear on the supported lists.
Distributed file system for attachments
Persistent data, including OX Drive files and PIM attachments, must sit on a distributed file system. NFS suits small to mid-size deployments, while object storage such as AWS S3, Ceph RadosGW or Scality RING fits larger ones. Attachments that phones upload and download pass through this layer, so confirm size limits, latency under sync load, backup scope, and how storage is restored alongside the database so references stay consistent.
Sibling modules that shape mobile use
OX Drive, OX Documents and OX Guard affect what users see on a phone even though the connector handles mail, calendar and contacts. Drive links in messages, Documents editing and Guard encryption each change how a message or file behaves on a device. Confirm which modules you license, since the Operations Guide notes that some modules may carry separate fees or custom packaging set in the license agreement, and test each one on a test device.
Mobile device management controls
Your organization may already run a mobile device management product or policy set that controls which apps, accounts and encryption settings apply to phones. Confirm whether that control can enforce a passcode, wipe a device and restrict account configuration before you enable sync for staff. Ask who owns the policy, how it is tested against the connector, and what happens to synced data when a device is lost or an employee leaves.
Questions buyers ask before hiring help with the ActiveSync connector
How much does hiring help for the ActiveSync connector cost?
Cost follows from the written scope, and DeployOpen does not publish a price list. The main components are discovery of your identity, network and device policy, deployment of the connector into your Kubernetes environment, configuration of sync behavior, testing with a pilot group, and handover documentation. Most of the build and pilot work is one-time. Upgrades, monitoring and ongoing support recur and can be placed under a retainer. Cost rises with the number of mailboxes in scope, the variety of phones and mail clients you must support, the complexity of your directory and the number of systems the connector must touch. Ask any quote to separate one-time and recurring items, list exclusions, and state which module license fees, if any, sit outside the services price.
How long does an ActiveSync connector deployment take?
Duration depends on the conditions your team controls, so no timeline should be accepted before the scope is agreed in writing. The main drivers are whether OX App Suite v8 already runs on a supported Kubernetes cluster, how quickly identity and network access are confirmed, how many device types and policy profiles the pilot covers, and how many approval rounds your device policy owners need. Licensing confirmation can set the start date on its own. Change windows for mobile policy changes add further time. Ask for a schedule with named milestones, an owner for each dependency, and the acceptance criteria for the pilot before work begins.
What does the work need from our team before it starts?
Four ownership areas need named people before the build starts. The identity owner confirms directory accounts, the authentication path and how users are provisioned. The network owner confirms ingress, DNS, firewall rules and whether mobile devices can reach the service from outside your network. The device policy owner sets the rules for sync scope, password requirements, remote wipe and any mobile device management tool in use. The platform owner provides cluster access and change approval. You also need a pilot group of users across the device types you run, who can test mail, calendar and contacts and report results. Agree these roles and time commitments in the scope.
Can our internal team deploy the ActiveSync connector without a partner?
Yes, a team with Kubernetes and identity skills can do this alone, provided it checks licensing first. OX App Suite v8 is delivered as Helm charts that reference container images, and Helm 3.17.0 or newer is required, so the team needs working knowledge of Helm, cluster networking and ingress. Identity integration and mobile device policy are the areas where internal teams most often need extra time. Before building, confirm in the license agreement that the connector is included or that the fee is covered. If your team lacks experience with mobile sync or Exchange ActiveSync clients, a partner can take on the design and pilot while your staff learn the operation.
Is the ActiveSync connector included in our OX App Suite license?
Do not assume it is. Open-Xchange documents that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Check the agreement you hold with Open-Xchange or with the party that sold your license, and look for the module by name and for any usage limits, such as user counts or device counts. DeployOpen does not decide licensing terms. Resolve this before scoping, because an unlicensed module can change the architecture, the cost and the start date. Ask the seller to confirm the answer in writing and attach it to the quote.
What should a written quote for this work include?
A useful quote states the scope in plain terms, the environment it assumes, and the deliverables. It should name the OX App Suite version and the hosting model, list the identity and network integrations in scope, and state the pilot size and acceptance criteria. Ask for a list of exclusions, a statement of the licensing position, and a split between one-time build work and recurring support or upgrade work. It should also cover the change process if requirements move, the assumptions your team must meet, the milestones and any payment schedule. DeployOpen engagements are fixed scope and agreed in writing before work starts, so the quote should match that written scope exactly.
What usually goes wrong when phones sync with Exchange ActiveSync?
Most problems appear at the boundaries rather than in the core service. Common issues to check include reachability from mobile networks, certificate chains that some devices do not trust, identity mismatches between the directory and the mail profile, and conflicts between server-side sync rules and mobile device management policies. Sync scope, attachment handling and client behavior can also differ by phone make and operating system version, so the pilot should include the devices your users actually carry. Confirm each of these areas with your identity, network and device policy owners and test them with real user accounts before general rollout. Record the results so the operations team can reproduce any fault.
How DeployOpen scopes and delivers the ActiveSync connector implementation
DeployOpen starts with the device mix, account policies and mail backend your users depend on, then agrees a fixed written scope for the OX App Suite Exchange ActiveSync connector. The build runs in infrastructure you control, with testing on real devices, handover documentation and an optional retainer for ongoing support.
How we scope
- Inventory the phone platforms, mail clients and sync policies your users rely on today
- Confirm the OX App Suite version, Kubernetes target and mail backend the connector must reach
- Agree in writing which devices, accounts, mailboxes and sync data types are covered
- Confirm what your team provides, including network access, certificates and test accounts
How we build
- Deploy and configure the connector in your own cluster or data center, following your change process
- Set up TLS, certificate handling and access restrictions for the sync endpoint
- Test mail, calendar and contact sync on agreed device models and operating system versions
- Document parity gaps against IMAP, CalDAV and CardDAV clients so users know what to expect
How we hand over
- Provide configuration records, runbooks and a list of the test cases that were executed
- Walk your operations and service desk teams through enrollment, troubleshooting and rollback
- Record open issues, known device limitations and the items you must confirm with your vendor
- Agree the handover acceptance criteria in the written scope before work begins
How we support
- Engagements are fixed-scope, so changes to devices, policies or versions are quoted as new work
- Ongoing support, upgrades and periodic re-testing are available as a retainer
- Ask your vendor to confirm the connector's support and release terms for your OX version
- Plan regression tests before each OX App Suite upgrade that touches the sync path
