Sophos Mobile: Exchange Server to Exchange Online

When moving from an on-premises Exchange Server to Exchange Online, reassess the email account configuration in the affected Sophos Mobile policies. This is not the same as migrating mailboxes: Sophos Mobile distributes settings to devices; whether users can sign in and send and receive messages also depends on the mail app, authentication, tenant, and Exchange environment.

Important: This article provides planning guidance, not a procedure for a production cutover. Sophos’s migration guidance dates from June 22, 2023. It documents policy mechanics, not currently verified end-to-end compatibility for your tenant. Do not remove old policies or mail accounts on the strength of this article alone.

What needs to change in Sophos Mobile

Sophos describes two approaches: update the existing policy with a new Email account configuration, or replace it with a new policy. The documented example replaces the policy. Depending on your deployment, Android Enterprise device and work profile policies, older Android device policies, iOS device and user policies, macOS user policies, and Windows policies may be affected. This list is an inventory aid, not confirmation that each of those clients supports Exchange Online with the chosen sign-in method.

Prepare policies before switching devices

Whether updating or replacing a policy is simpler depends on the existing policy structure. If a shared policy contains other configurations, their scope must be preserved and checked with either approach; a change to them is not limited to the selected pilot device. For the replacement example, first prepare a new policy that has not yet been assigned. One option is to duplicate the currently assigned policy; this is not a required method. Check inherited settings for payloads that are still needed, old accounts, and the correct user/device scope. Repeat this preparation for every actually affected policy family in the inventory above. Do not send a task bundle or remove an old policy yet.

Map the account, cloud, and authentication

The general migration example maps outlook.office365.com to Server name for the global Microsoft 365 cloud, and %_EMAILADDRESS_% to User. Sophos Mobile replaces the placeholder with the user’s email address. This does not guarantee that the email address matches the actual sign-in name in your tenant. For another cloud, select the matching dataset in Microsoft’s continuously maintained Microsoft 365 URLs and IP address ranges library: The default view is Worldwide (+GCC); 21Vianet, DoD, and GCC High have separate datasets. Do not adopt the worldwide host without checking it.

Selecting OAuth requires modern authentication for Exchange Online to be enabled in the tenant. Check this state separately with the Exchange team. For Android Enterprise, the guidance describes selecting Authentication > Modern authentication; for iOS and macOS, Turn on OAuth 2.0. For Windows and older Android policies, this source does not show an equivalent OAuth setting. Neither selecting an option nor an earlier statement about a tenant default proves that the actual mail client can sign in. Enable SSL/TLS. An encrypted connection with valid certificate verification is part of acceptance; a failed sign-in is not remedied by disabling TLS checks.

Current iOS device policy: OAuth host discovery rather than a blanket server value. In Email account for Apple Mail, leave Server name empty with OAuth: The Exchange host is discovered automatically. Enter an OAuth authorization endpoint only if the authentication provider requires one; this disables host discovery, and Server name must contain the appropriate server URL. Populate OAuth token endpoint only if the provider requires it as well. The general host mapping above is therefore not an unconditional configuration step for iOS with OAuth. For Exchange Online, leave Domain empty. %_EMAILADDRESS_% in User inserts the address of the user assigned to the device; that user’s Exchange Login and Email Address must be maintained in Sophos Fusion. Check user assignment, resolved values, host discovery, and actual sign-in separately in the authorized pilot. Do not automatically apply this iOS device description to iOS user policies or other clients.

Check remaining account settings by policy type

Changing the host alone does not replace a complete Email account review. Before assignment, compare the existing account display, user assignment, sign-in, synchronization scope, data sharing, and, where applicable, certificates for each policy type. In iOS device policies, Synchronization period limits the email synchronized locally. Allow move, Allow recent address syncing, and Use in Mail only are separate decisions about switching accounts, iCloud address syncing, and sending apps. Identity certificate and S/MIME signing and encryption require the appropriate certificates in the policy; they do not follow from changing the server. Deliberately specify mail, calendar, and contact synchronization and the changes users are allowed to make, rather than blindly copying them from the old profile.

For separate platform tasks, the iPhone/iPad device policy covers management mode, accounts, and policy effects. The Android Enterprise corporate device policy covers only Full Device with Gmail, including the old Gmail configuration, user assignment, and the Chrome prerequisite for OAuth; it is not a recipe for Work Profile or legacy Android. For macOS user policy, the macOS policy explains the EWS account and its OAuth host discovery, not EAS. For Windows, first clarify the account and client limitations; this does not establish supported deployment of a current mail client. For Android work profiles, older Android policies, or iOS user policies, compare the specific account fields offered and client prerequisites separately. Until their behavior is confirmed, do not assign values from another policy family as a verified configuration.

Plan task bundles and future enrollments separately

For policy replacement, the Sophos example specifies a task bundle with Assign policy for the new policy; it specifies Uninstall policy for the old policy only for Android device and iOS device policies, and Unassign iOS user policy only for iOS user policies. Existing devices and future self-service enrollments follow separate paths: The task bundle sent to existing devices does not automatically replace the enrollment task bundle of a configuration in the Self Service Portal. If such configurations are in use, replace the affected enrollment task bundles there with bundles that assign the new policy; check each affected configuration and its bundle assignment before further enrollments. The combined task bundle is a documented example, not an approved sequence for production replacement. Its execution or a successful task status proves neither sign-in nor mail flow nor that removing the old profile is harmless.

EAS access control is not the mail path

If the existing environment uses the Sophos Mobile EAS proxy for access control, Sophos distinguishes two modes for Exchange Online: According to its documentation, Proxy mode supports Exchange Server, not Exchange Online. In PowerShell mode, devices communicate directly with Exchange; the Sophos service controls access decisions through the Exchange management interface. The mail app still needs its own working sign-in and data path. According to Sophos, PowerShell-based ActiveSync access control is not available for Macs.

There is an unresolved point to reconcile regarding authentication by the Sophos service: Sophos’s January 2026 description says that, after a failed modern authentication attempt, it tries Basic Authentication. Microsoft does not allow Basic Authentication to be re-enabled for Exchange Online EAS or Remote PowerShell. The described fallback is therefore not a recovery path. Sophos separately describes Basic for its PowerShell-mode management connection to an on-premises Exchange Server; this is not a claim about EAS client sign-in or Exchange Online, nor permission to enable Basic without security approval. In addition, Sophos’s September 2026 setup instructions specify a /powershell-liveid connection URI. Microsoft also lists that URI as the default in its current Connect-ExchangeOnline module documentation, which describes modern REST connections without WinRM Basic. The URI alone proves neither that the transport is obsolete nor that a particular Sophos build is compatible; its module, authentication, and actual connection behavior remain unverified. Sophos’s September 2026 PowerShell guidance still lists Exchange Server 2016 and 2019 as supported versions; Microsoft’s end-of-support roadmap says support for both ended on October 14, 2025. Separately, Microsoft’s Exchange Server 2016 and Exchange Server 2019 lifecycle product tables each give October 15, 2025 at 6:59:59 a.m. Pacific Time as the extended-support end. These primary notices differ by calendar date; neither explains the difference. Do not infer a common timestamp or an additional day of support. The Sophos list therefore does not establish that those server versions remain within their support lifecycle. Before relying on access control, clarify the supported proxy build, module, cloud endpoint, service account, permissions, and actual OAuth/REST connection, as well as the support status of the existing server environment, with Sophos and the responsible Exchange team. Do not infer blanket approval for Basic, WinRM Basic, or disabled certificate verification.

PowerShell setup as a separate, conditional task

This branch is needed only if EAS access control is actually intended to be used. The EAS architecture decision covers client protocol, device identity, and quarantine; the installation precheck covers the host, build, service account, and certificate trust. Both are prechecks, not approved setup runbooks. For migration planning, setup can be divided into three separate parts:

Management environment and service account: Have the appropriate PowerShell/module environment on the intended host and a dedicated Exchange management account confirmed, including the required permissions and tenant sign-in requirements. Exchange Server and Exchange Online prerequisites are not interchangeable. Commands to enable Basic on the on-premises Exchange PowerShell directory do not belong in an Exchange Online change. Changes to the PowerShell execution policy are also a host intervention requiring separate approval.
Instance and connection: On EAS Proxy instance setup, the setup wizard describes Instance type > PowerShell Exchange/Office 365, an Instance name of your choice, the target under Exchange server, and Service account with Password. These are fields for preparation, not values already confirmed for your build. For the global cloud, the example specifies outlook.office365.com; the wizard adds the protocol and path itself. Do not blindly enter a complete URI in the host field or infer current transport approval from the added path. Allow all certificates disables server certificate verification and remains off for this plan; resolve a trust error separately. Supported management sign-in must be demonstrated independently of the device mail path.
Instance trust with Sophos Mobile: The certificate generated during configuration for each PowerShell instance must be associated with the correct instance. The documented upload is under My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file, followed by Save. It is not the same as the server TLS certificate or a client certificate in the mail profile. The subsequent restart of the Windows service EASProxy described in the documentation is a service interruption and belongs only in a separately approved change with startup and rollback checks; do not trigger an upload or restart here.

Without a confirmed build, sign-in, certificate association, and rollback path, stop at this preparation. An entered account, uploaded certificate, or reachable service proves neither an enforced access decision nor successful sending and receiving. Only after separate approval, perform acceptance checks on these three paths separately; do not use broad Exchange quarantine as a setup test.

Resolve before a production decision

Affected cohorts: Record ownership and management mode, existing and planned policy, device and operating system, mail app, account type, and authentication method separately. Do not infer OAuth compatibility for Windows or older Android clients from Sophos’s migration list.
Tenant and permissions: Check the Microsoft cloud, endpoint, Exchange Online plan, and user mailboxes; the service account for access control uses a different sign-in path from the user’s mail account. Review permissions and MFA/Conditional Access requirements with the Exchange team instead of assuming broad administrator privileges or a Basic fallback.
Safe acceptance: First, without assigning or uninstalling a policy, record the target device, existing assignment, synchronization status, mail app, mailbox state, and existing mail data on an authorized pilot device with a test mailbox. Before any pilot change, clarify the supported sign-in method, possible consequences for profiles and data, a verifiable backup of affected data, and stop and rollback criteria with the Exchange team; if the impact or the way back is unknown, stop here. Only then plan a separately authorized policy change limited to the pilot cohort, and observe the effective new account settings, actual sign-in, sending, receiving, and—if used—the intended EAS access decision. Decide on broad deployment or removal of the old policy only after that acceptance. Do not assume that old and new profiles can coexist or that Uninstall policy is reversible; do not trigger an uninstall as a mere pilot precheck. If results differ from expectations, investigate the client/sign-in and, separately, the access-control connection first; do not enable broad blocking of unknown devices as a diagnostic step.
Rollback and approval: Document old and new policies and self-service task bundles; establish the change window, stop criteria, ownership, and recoverability of the actual mailbox and server environment before making the change. Reassigning the old Sophos policy does not restore a mailbox that has already been moved or an on-premises Exchange Server that has been shut down.

Until these points have been confirmed for the specific environment, the policy description is only a planning basis. This article does not recommend a production cutover, guarantee success, or promise a universal rollback.