Skip to content
Avanet

Sophos Mobile EAS Proxy: Troubleshoot connection and ActiveSync ID errors

Sophos Mobile

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, open PowerShell as an administrator on the affected EAS/Exchange administration host, as specified in the troubleshooting guide. This means the host with the module installation being checked, not the Sophos Firewall console or the mobile device. Query the installed module inventory with the following read-only command; there are no placeholders to replace:

Get-InstalledModule ExchangeOnlineManagement | Format-List Name,Version

The output shows the module name under Name and the installed version under Version. It is an inventory check, not proof of a successful Exchange connection or a compatible proxy configuration. The command changes no configuration and does not install or update a module. If the query fails or returns no module inventory, pass the finding, host details, and PowerShell context to the responsible administrators; this does not automatically authorize installation or an update. The command is taken from the vendor documentation but has not been tested in an EAS/Exchange lab for this guide.

To interpret this version, 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.

Separate reset of the stored ActiveSync ID

The Sophos function Actions > Reset ActiveSync ID (German: Aktionen > ActiveSync-ID zurücksetzen) is restricted to Android devices, iPhones, and iPads. Depending on the selection, it resets the device property stored in Sophos Mobile for the native app or Outlook. The documentation describes a reset, not its technical implementation as deleting or clearing the stored value. 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.

Sophos describes the following procedure for the existing affected device:

  1. Open Devices (German: Geräte), click the down arrow next to this device, and select Show (German: Anzeigen).
  2. On Show device (German: Gerät anzeigen), open Actions > Reset ActiveSync ID (German: Aktionen > ActiveSync-ID zurücksetzen).
  3. Under Device property to reset (German: Zurückzusetzende Geräteeigenschaft), select the option for the affected mail app:
    • ActiveSync ID for Gmail on Android or Mail on iOS.
    • ActiveSync ID Outlook for Microsoft Outlook. The native-app reset option is called ActiveSync ID, not ActiveSync ID reported, which is the display field under Device properties mentioned above.
  4. Select OK to reset the selected device property.

When this mail app next contacts the Sophos Mobile EAS Proxy, Sophos Mobile stores the new ActiveSync ID. A reset does not automatically change the app’s ID and guarantees neither renewed contact nor mail delivery. After an approved reset, compare the stored value again with the ID sent by this app in easproxy.log; continue to check user mapping, compliance, and mail flow separately. The documented procedure concerns the selected property on the existing device. Deleting or reenrolling devices, recreating accounts, changing user assignments, or setting up the proxy again are not steps in this procedure and must not be tried as substitutes.

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, the Sophos Mobile Control procedure at the time searched for a device to match an as-yet unknown ActiveSync ID: the device’s internal sAMAccountName property had to match the username reported by the mail client, and its ActiveSync ID property had to be empty. This was how it searched for a device with the associated user. With no match, mail synchronization failed; with exactly one match, the ID was assigned to that device, and the synchronization request could be forwarded only if mail access was allowed. Multiple matches were a separate error case in which mail synchronization also failed. This historical description of the internal search key is not an instruction to edit the properties and provides no guarantee for a current tenant. 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.

For iOS, the Sophos Mobile Control configuration at the time followed a different procedure: iOS automatically reported the ActiveSync ID of the built-in Mail app; the mapping of an as-yet unknown Android app ID described above was not used for this. For another iOS mail app, the original troubleshooting guide describes synchronization failing in that specific historical SMC configuration. It gives no version range for iOS or SMC. This establishes neither a general failure of current iOS mail apps nor their current compatibility. The possible first-contact fallback for Outlook on Android and iOS described above is separate; the historical iOS description 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.