Skip to content
Avanet

Sophos Mobile EAS Proxy: Troubleshoot connection and ActiveSync ID errors

In brief: First establish the operating mode and mail path. Then compare three separate observations: the proxy instance’s Last active connection to Sophos Mobile, startup/Exchange connection errors from the proxy service, and—only if the mail app actually connects through the EAS Proxy—the affected device’s ActiveSync ID, user mapping, and compliance status. An old timestamp or the log message failed to resolve active sync id alone establishes neither the cause nor an appropriate reset.

This guide is limited to reading and interpreting the available information. Before changing the mail flow, certificates, service, Exchange module, or device mapping, you need an operating mode confirmed for your environment, authorized test devices, a maintenance window, and a rollback plan.

Identify the mail path first

In proxy mode, the client’s mail traffic passes through the Sophos Mobile EAS Proxy to the mail server. Mapping the ActiveSync ID sent by the mail app to a managed device may matter here. In PowerShell mode, the proxy controls Exchange device access; clients connect directly to Exchange for mail. An ActiveSync ID check in the proxy log is therefore not a universal test for Exchange Online or PowerShell mode. According to Sophos, Exchange Online is supported for this access control only in PowerShell mode; for Exchange targets, proxy mode supports on-premises Exchange Server, not Exchange Online. The ActiveSync ID checks below for a mail path actually routed through the proxy to an on-premises Exchange Server are therefore not Exchange Online troubleshooting. Record the operating mode, mail server, affected client, managed device, and time of the error before troubleshooting. If the mode is unclear, make no ID or Exchange changes.

Check last contact and service errors separately

  1. In the English Sophos Mobile interface, open Setup > Sophos setup > EAS proxy > External (German interface: Einrichtung > Sophos-Einrichtung > EAS-Proxy > Extern). In the Last active column (German: Zuletzt aktiv), check the affected instance and the time of its last connection to Sophos Mobile. Roughly one day is a typical reference point, not a fixed outage threshold. A much older timestamp may indicate, for example, uninstalled proxy-server software, a stopped service, a powered-off host, a removed instance, a new certificate that has not yet been uploaded, or a blocked connection to Sophos Mobile. It does not establish whether the Exchange connection or mail delivery works.
  2. If the service stops immediately after starting, have the responsible operations team review the relevant proxy logs for the startup time. An unrecoverable startup error is one possible class of failure; this implies neither a universally applicable log path nor a restart fix. Capture the service state and specific error before anyone changes the configuration.
  3. If a previously working PowerShell instance can no longer reach Exchange Online, document the connection and error separately from service startup. An unsupported version of ExchangeOnlineManagement is a possible cause. Check the version, proxy build, host runtime, authentication, and permissions together; blindly updating the module is neither a diagnosis nor a guaranteed repair. Basic authentication for Exchange Online (including EAS and Remote PowerShell) cannot be re-enabled as a workaround. Authentication for on-premises Exchange Server is a separate, environment-specific matter; this read-only guide does not direct any configuration change. Do not weaken TLS verification or system-wide network settings as a shortcut.

For the version check in step 3, the Sophos troubleshooting guide dated 8 November 2023 gives two distinct thresholds:

  • 3.0.0 and later: The guide at that time lists these versions of the ExchangeOnlineManagement module as supported. This is not a compatibility guarantee for 2026 or for every newer module version. The responsible Exchange/Mobile administrators must separately check current vendor requirements and compatibility with the deployed proxy build, host runtime, and authentication.
  • 2.0.5 or earlier: The same source describes a separate update case for these versions. If you find such a version, record it as an outdated module version and refer it to the responsible Exchange/Mobile administrators for compatibility and change review. This read-only check does not update the module. The source describes no separate repair procedure for versions between the two thresholds; do not infer one.

For problems installing the Exchange Online PowerShell module, the responsible administrators can also consult Microsoft’s module installation troubleshooting guide. It covers installation problems, not the entire mail flow. Installation, dependencies, permissions, and changes remain part of a separate, approved administrative procedure; the link is neither an instruction to update blindly nor an assurance that connectivity will work afterwards.

A migration to Exchange Online is also a separate project: changes to email accounts, policies, and task bundles are outside this read-only troubleshooting check.

Compare ActiveSync IDs in proxy mode

For Android devices, iPhones, and iPads with a mail client behind the EAS Proxy, distinguish two mapping paths: If the ActiveSync ID sent by the mail client is already stored for that app on a device, the ID and app username are checked against the device user. If no match exists for the sent ID at first contact, Outlook on Android and iOS may fall back to the username and a device with no stored Outlook ID; only an unambiguous match permits mapping and storage of the ID. An existing ID match is therefore not an absolute prerequisite for first contact. Older Android configurations also searched by user and an empty stored ID; that does not establish the same behavior for every current client. Whether mapped mail traffic is allowed or blocked depends separately on the applicable policies and compliance status. A mail app can change its ActiveSync ID without warning. If Sophos Mobile cannot map the new ID to the device, it blocks mail traffic; this can also cause a previously mapped client to fail. This is distinct from the possible first-contact fallback and does not establish that a reset is needed. Narrow down a possible ID conflict without making changes:

  1. In the English interface, open the specific device under Devices > Show > Device properties (German: Geräte > Anzeigen > Geräteeigenschaften). For the native mail app (Gmail on Android or Mail on iOS), check ActiveSync ID reported; for Microsoft Outlook, check ActiveSync ID Outlook. Only if an Android user has used Change Exchange email app (German: Exchange-E-Mail-App ändern) in Sophos Mobile Control should you also consider the additional Gmail property ActiveSync ID under Custom properties (German: Benutzerdefinierte Eigenschaften). Do not confuse these fields.
  2. Have authorized admins find the ID sent by the affected mail client at the relevant time in easproxy.log and compare it with the corresponding device entry. A message such as failed to resolve active sync id or could not find a matching device is a clue for investigation, not proof that a particular repair is needed. Check user mapping, device mode, and compliance separately. Share IDs, usernames, and mail data in tickets only through protected channels and only to the extent needed.
  3. If no unambiguous match is possible, escalate the observations, timestamp, operating mode, affected app, and a redacted log excerpt to Mobile/Exchange support. Do not delete devices, detach users, or reset stored ID values as a test.

The Sophos function Actions > Reset ActiveSync ID (German: Aktionen > ActiveSync-ID zurücksetzen) is restricted to Android devices, iPhones, and iPads. It deletes the stored value for the native app or Outlook, depending on the selection; a new value can only be stored when the app next contacts the proxy. This is a separate intervention requiring approval, not a step in this read-only check: First establish the actual ID conflict, the exact app/device mapping, the user, compliance status, and a traceable mail-flow baseline, and agree on a test and rollback plan. A reset does not automatically change the app’s ID and guarantees neither renewed contact nor mail delivery.

This is distinct from Change Exchange email app (German: Exchange-E-Mail-App ändern) in Sophos Mobile Control: This Android user action can reset the ActiveSync ID sent by Gmail, not just the stored console value. If it has already been used, the additional Gmail property ActiveSync ID under Custom properties mentioned above must therefore be considered. This action is also not a step in the read-only check and must not be triggered as a test; any intervention requires the same approval, established conflict, test, and rollback plan.

Interpret historical Android cases carefully

In older Android configurations using the EAS proxy mail path, an as-yet unknown ActiveSync ID could be mapped using the associated user and a device without a stored ID. No matching device and multiple possible devices were distinct error cases. In these older Android configurations, each mail app had its own ActiveSync ID; switching apps could therefore also trigger the mapping errors described. The app ID was not an Android operating-system property and could not be retrieved through Sophos Mobile Control synchronization. This explains why the specific mail app is compared with the proxy log, but does not establish the same behavior for every current management mode. The distinction made at the time for the built-in iOS Mail app does not establish the same behavior for every current Android client or current management mode. For Outlook on Android and iOS, the possible first-contact fallback described above applies; the historical iOS distinction does not override it.

Another historical special case involved multiple Android devices belonging to the same user without assigned ActiveSync IDs and a log line containing found 2 matching devices, but should be exactly one. An intervention described at the time temporarily removed and then restored a user assignment with mail synchronization. Do not reproduce that as a fix here: Even a similar-looking log line does not replace confirmation of the two correct devices or a review of the current mail path, compliance, and the consequences of changing the assignment. If the case really applies, first clarify with Sophos Support and the mail administrators whether the procedure is still valid for the deployed proxy build and affected devices, and agree on a test and rollback plan. No general restoration of mail delivery has been established by that procedure.