Sophos Mobile EAS-Zugriff: Proxy- und PowerShell-Modus unterscheiden

Der Name Sophos Mobile EAS-Proxy bezeichnet zwei unterschiedliche Wege zur Kontrolle von Exchange ActiveSync (EAS), also dem mobilen Synchronisationsprotokoll für Mail. Im Proxy-Modus laufen EAS-Anfragen der entsprechend eingerichteten Geräte durch den separat installierten Sophos-Proxy zum Mailserver. Im PowerShell-Modus verbinden sich die Geräte direkt mit Exchange; der Sophos-Dienst steuert den Gerätezugriff über eine separate Verwaltungsverbindung. Wer die beiden Wege verwechselt, plant möglicherweise die falschen Netzpfade oder übersieht eine Änderung am Exchange-Zugriff. Dies ist eine Entscheidungshilfe, keine Einrichtungs-, Migrations- oder Reparaturanleitung.

Stopp vor einer organisationsweiten Quarantäne oder einem produktiven Wechsel: Der Wechsel der Exchange-Standardzugriffsstufe von „Allow“ auf „Quarantine“ kann bereits verbundene EAS-Geräte sofort betreffen, sofern keine Gerätezugriffsregel oder individuelle Allow-/Block-Entscheidung greift. Ohne erfasste Ausgangslage, geprüfte Geräte- und Compliance-Zustände, nachgewiesene Anmeldung und genehmigten Rückweg keine Umschaltung; das ist kein Schalter für ein einzelnes Pilotgerät.

Entscheidungspfad: Zuerst Ziel-Maildienst und tatsächliche EAS-Mail-Apps bestimmen. Für Exchange Server kommt der Proxy-Modus als Mailpfad infrage; für Exchange Online nennt Sophos nur den PowerShell-Modus mit direktem Gerätezugriff. IBM Traveler ist ein eigenes Proxy-Ziel. Nur für das jeweilige Ziel die Modi vergleichen. Wenn Geräteidentität, Client-Anmeldung, Verwaltungsanmeldung oder Zielserver-Support nicht nachweisbar sind, hier stoppen statt aus der Moduswahl eine Freigabe abzuleiten.

Eine Migration oder Umsetzung ist gesondert zu planen und freizugeben; für Störungen siehe EAS-Fehlersuche.

Lizenz- und Plattformgrenze: Diese EAS-Hinweise betreffen die Geräteverwaltung mit Sophos Mobile, nicht eine alleinige Sophos-Mobile-Threat-Defense-Lizenz. Vor der Moduswahl die tatsächliche Sophos-Mobile- oder Sophos-Mobile-Device-Management-Berechtigung des Tenants, Enrollment und Compliance-Meldung jedes vorgesehenen Android- oder iPhone-/iPad-Geräts sowie dessen konkrete Mail-App und Protokoll prüfen. Ein von Sophos genanntes Microsoft-365-Exchange-Online-Abonnement ist eine Voraussetzung für den Maildienst, kein Nachweis der Mobile-Berechtigung oder dafür, dass EAS-Kontrollen die native Outlook-Synchronisierung erfassen. Keine Abdeckung für Macs oder andere Nicht-EAS-Clients ableiten.

Wo verläuft der mobile Mailverkehr?

Datenschutzgrenze: Im Proxy-Modus läuft der Mailverkehr durch den separat betriebenen Proxy; im PowerShell-Modus umgeht er ihn, Sophos verarbeitet für Zugriffsentscheidungen aber weiterhin Geräteidentität und Compliance-Status. Aus keinem der Mailpfade lässt sich ableiten, welche Inhalte oder Metadaten protokolliert, gespeichert oder aufbewahrt werden. Vor einer Freigabe Protokollierung, Zugriff und Aufbewahrung in der konkreten Umgebung prüfen.

• Proxy-Modus: Gerät → Sophos Mobile EAS-Proxy → unterstützter Mailserver (für Exchange: lokaler Exchange Server; Sophos nennt auch IBM Traveler). Auf den Geräten muss der Proxy als EAS-Mailserver für eingehende und ausgehende Mail eingerichtet sein; daraus folgt keine separate SMTP-Konfiguration. Über eine HTTPS-Webschnittstelle verbindet sich der Proxy mit Sophos Mobile, gleicht Geräteidentität und erforderlichen Richtlinienstatus ab und leitet passende EAS-Anfragen weiter. Zusätzlich lässt sich der Proxy so konfigurieren, dass er bestimmte Geräte sperrt; das ist von der Compliance-Prüfung und individuellen Exchange-ABQ-Einträgen zu unterscheiden. Der eigentliche Mailserver muss für diesen Proxy-Mailpfad nicht direkt aus dem Internet erreichbar sein. Das ist keine Garantie, dass jede Anfrage geprüft wird: Die unten beschriebene Traveler-Ausnahme bleibt bestehen. Der Proxy liegt hier im Mailpfad: Ausfall und Durchsatz des Proxys sind für die Erreichbarkeit der mobilen Mail relevant.
• PowerShell-Modus: Gerät → Exchange direkt; getrennt davon Sophos-Mobile-EAS-Dienst → Exchange-Verwaltungsschnittstelle. Zusätzlich verbindet sich der Sophos-Dienst über eine HTTPS-Webschnittstelle mit Sophos Mobile. Der Mailverkehr fliesst nicht durch den Sophos-Proxy; auf dessen Host braucht es deshalb keinen Firewall-Port für eingehende Mail. Die Erreichbarkeit von Exchange sowie die Verwaltungs- und Kontrollverbindungen müssen trotzdem geplant werden. Als Ziele nennt Sophos Exchange Server 2016/2019 und Microsoft 365 mit Exchange-Online-Plan. Diese Produktangabe ist noch kein Nachweis, dass die vorhandene Proxy-Version, der konkrete Client, dessen Anmeldung und der Tenant heute zusammen funktionieren. Die Dimensionierung des Mail-Relays aus dem Proxy-Modus lässt sich nicht auf diesen Modus übertragen.

Netzpfade im datierten Client-Zertifikatsbeispiel: Das Sophos-Architekturdiagramm (englische Seite vom 12. April 2023, deutsche Seite vom 27. April 2023) zeigt Sophos Mobile, EAS-Proxy und Exchange innerhalb einer gestrichelten, mit „Customer“ bezeichneten Kundenumgebung; die Geräte stehen ausserhalb. Das ist eine dargestellte kundenseitig betriebene Topologie, keine universelle Vorgabe für Sophos-Mobile-Deployments und kein Nachweis einer Firewall- oder DMZ-Grenze. Neben dem EAS-Mailpfad gibt es einen separaten MDM-Pfad Gerät → Sophos Mobile über HTTPS; dieser Geräteverwaltungspfad führt im Diagramm nicht durch den EAS-Proxy. Davon getrennt ist die bereits beschriebene HTTPS-Kontrollverbindung EAS-Proxy → Sophos Mobile.

Die Endpunkttabelle dieses Diagramms nennt ausschliesslich schematische Beispielwerte, keine zu übernehmenden Betriebsendpunkte oder pauschalen Firewall-Freigaben:

Die Namen smc.company.com und eas.company.com sowie die Zielports gehören zu diesem Beispiel. Der Pfeil EAS-Proxy → Exchange trägt dagegen nur die Beschriftung http/s; ein Backend-Port ist nicht angegeben. Das bewahrt die schematische HTTP-/HTTPS-Darstellung, verlangt aber weder unverschlüsselten Backend-Verkehr noch gibt es ihn pauschal frei. Daraus folgen auch keine Aussagen über TLS-Terminierung oder Zertifikatsvertrauen. Tatsächliche Endpunkte, Ports und die abgesicherte Backend-Verbindung sind für die eigene Umgebung separat zu prüfen und freizugeben; die Pfeilrichtungen schliessen Antwortverkehr nicht aus. Das Diagramm erweitert weder die unten genannten Produkt- und Versionsgrenzen noch die unterstützte Mailservermatrix.

Central-Beispiel mit getrennter Kundenumgebung: Eine andere archivierte Architektur zeigt Sophos Mobile in Central innerhalb des Bereichs Sophos Central, während EAS proxy und Exchange im Bereich Customer stehen. Die Geräte befinden sich ausserhalb beider Bereiche. Ihr separater MDM-Pfad führt über HTTPS zu Sophos Mobile in Central; der Textkasten nennt dafür central.sophos.com. Der ActiveSync-Mailpfad führt dagegen über HTTPS zu eas.company.com beim kundenseitigen EAS-Proxy und von dort über http/s zu Exchange. Zusätzlich zeigt ein eigener HTTPS-Pfeil vom EAS-Proxy zu Sophos Mobile in Central die Kontrollverbindung über die dargestellte Kunden-/Central-Grenze hinweg. MDM, Mail und Proxy-Kontrolle sind somit drei getrennte Pfade, nicht ein gemeinsamer Weg durch Central.

Die Endpunkttabelle dieses Central-Beispiels enthält genau eine Zuordnung: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → EAS Proxy:443. Sie nennt weder einen Central-MDM-Zielport noch einen Exchange-Backend-Port. Auch hier sind die Hostnamen schematische Archivbeispiele, keine Betriebsendpunkte des eigenen Tenants. Die gestrichelten Bereiche belegen keine Firewall- oder DMZ-Anordnung; aus http/s folgen weder eine Freigabe für unverschlüsselten Verkehr noch Angaben zur TLS-Terminierung.

Für den Proxy-Modus beschreibt Sophos mehrere unterstützte Exchange- oder Traveler-Mailserver mit einer EAS-Proxy-Instanz je Mailserver.

Davon getrennt ist die Skalierung eines Mailpfads: Dafür können Instanzen auf mehreren Computern hinter einem Load Balancer betrieben werden. Auch Client-Zertifikate sind vorgesehen: Man wählt ein Zertifikat einer Zertifizierungsstelle (CA); die Client-Zertifikate müssen von dieser CA abgeleitet sein. Im von Sophos dargestellten Client-Zertifikatsmodus (Architekturbeispiel vom 12. April 2023) prüft der EAS-Proxy die vorgelegten Client-Zertifikate gegen das ausgewählte CA-Zertifikat und sperrt Clients ohne Client-Zertifikat ebenso wie Clients mit einem ungültigen Client-Zertifikat. Diese dokumentierte Sperrbedingung betrifft nur den dargestellten Client-Zertifikatsmodus; sie belegt weder die Durchsetzung im eigenen Build noch bestimmte Ungültigkeits- oder Widerrufsprüfungen. Diese Client-Authentifizierung ist von den später zu Sophos Mobile hochgeladenen PowerShell-Verbindungszertifikaten zu trennen. Instanzen, Lastverteilung und Zertifikatsvertrauen müssen zur konkreten Umgebung geplant und getestet werden.

Konkrete Lastverteilung im archivierten Beispiel: Das Load-Balancer-Diagramm zeigt Sophos Mobile, einen Load Balancer, zwei EAS-Proxys und Exchange innerhalb von Customer, die Geräte ausserhalb. Der MDM-Gerätepfad führt über HTTPS direkt zu Sophos Mobile (smc.company.com), der ActiveSync-Gerätepfad über HTTPS zum Load Balancer (eas.company.com). Vom Load Balancer gehen zwei eigene, gemeinsam mit http/s beschriftete Pfeile zu den beiden Proxys. Jeder Proxy hat eine eigene HTTPS-Kontrollverbindung zu Sophos Mobile und einen eigenen http/s-Mailpfad zu Exchange. Die Kontrolle läuft in dieser Darstellung also nicht vom Load Balancer zu Sophos Mobile.

Die vollständigen Zuordnungen der Bildtabelle lassen sich ohne breite Tabelle lesen:

• MDM: https://smc.company.com/* → HTTPS → SMC Server:443; beide nachgelagerten Tabellenfelder sind -. Das Sternchen gehört zum dargestellten URL-Beispiel.
• ActiveSync, Proxy 1: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → Load balancer:443 → http/s → EAS Proxy 1:81.
• ActiveSync, Proxy 2: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → Load balancer:443 → http/s → EAS Proxy 2:81.

Port 81 bezeichnet hier die Proxy-Ziele hinter dem Load Balancer, nicht Exchange. Für Exchange enthält das Bild keinen Backend-Port. Diese schematische Archivdarstellung ist weder eine pauschale Firewall-Freigabe noch ein Nachweis für TLS-Offloading, Zertifikatsweitergabe, Sitzungsbindung, Health Checks, einen bestimmten Lastverteilungsalgorithmus oder garantierte Hochverfügbarkeit. Die Frontend-/Proxy-Portzuordnung ersetzt nicht die Planung und Freigabe der tatsächlichen Verbindungen.

PowerShell-Bild und Textbeleg auseinanderhalten: Das archivierte Central-PowerShell-Bild zeigt den EAS Proxy im Bereich Company, Sophos Mobile im getrennten Bereich Sophos Central und darunter einen eigenen, nicht sichtbar benannten Bereich mit Office 365 Exchange Online und outlook.office365.com. Zwischen Company und Sophos Central stehen die Beschriftungen https und Query device compliance list. Beim EAS-Proxy steht Needs PowerShell 3.0 or higher. Das ist eine historische Bildangabe, kein heute gültiger Mindeststand oder Supportnachweis; massgeblich bleibt die unten geforderte Prüfung des konkreten Builds und PowerShell-Hosts. In diesen archivierten Pixeln sind verbindende Pfeile nicht zuverlässig erkennbar. Die oben beschriebene Trennung von direktem Geräte-Mailpfad und separater Exchange-Verwaltungsverbindung ist deshalb eine dokumentierte Textaussage, keine aus diesem Bild abgelesene Pfeilrichtung. Das Bild liefert auch keine numerischen Ports oder Endpunkttabelle; die Hostbeschriftung belegt keinen aktuellen Exchange-Online-Anmelde- oder Transportpfad.

Datierten Dimensionierungshinweis einordnen: Sophos beschreibt in den Sizing Considerations vom 14. April 2022 einen geringen CPU- und Speicherbedarf des EAS-Proxys, nennt die Bandbreite als wesentliche Begrenzung und empfiehlt 1 CPU und 2 GB Arbeitsspeicher. Für grosse Installationen empfiehlt diese Quelle mehrere EAS-Proxy-Instanzen hinter einem Load Balancer; für den PowerShell-Modus ist diese Mail-Relay-Anordnung nicht erforderlich. Das ist eine datierte dokumentarische Empfehlung, kein Benchmark, kein nachgewiesenes aktuelles Minimum und keine Kapazitätszusage. Den konkreten Build, die Maillast und die verfügbaren Netzpfade mit dem Betriebsteam prüfen und die Dimensionierung vor einer Freigabe in einer autorisierten Umgebung validieren; aus diesen Werten allein folgt keine Produktionsfreigabe.

Vor der Einrichtung die Netzwerkintegration mit dem Betriebsteam klären: Geräte-Mailpfad, Sophos-Mobile-HTTPS-Kontrollverbindung und gegebenenfalls Exchange-Verwaltungsverbindung getrennt erfassen. Die unterstützten Mailserver führt Sophos im Abschnitt Requirements der Mobile-Release-Notes auf. Für die Übergabe müssen die zum vorgesehenen Build geltende Mailservermatrix, Ziel-Build und Lifecycle bestätigt sein; eine allgemeine Produktliste genügt nicht. Host-, Netz- und Installationsvoraussetzungen gehören zur separaten EAS-Installationsvorprüfung, nicht zu einer stillschweigenden Freigabe aus dieser Moduswahl.

Beide Varianten kontrollieren EAS, nicht beliebige mobile Mailprotokolle. Sophos schliesst Macs für diesen Kontrollweg aus und begründet dies mit fehlender ActiveSync-Unterstützung in macOS; das ist keine Aussage über jeden möglichen Drittanbieter-Mailclient auf einem Mac. Bei IBM Traveler können Anfragen von Nicht-iOS-Geräten ohne Geräte-ID durchgereicht werden, ohne dass der Proxy deren Berechtigung prüfen kann.

Im Proxy-Modus kann Outlook auf Android/iOS an der Zuordnung von Benutzer und ActiveSync-ID scheitern, etwa bei mehreren noch unbekannten Geräten oder wenn eine Neuinstallation der App eine neue ActiveSync-ID erzeugt und diese nicht zum gespeicherten Eintrag passt. Nicht jede Neuinstallation muss diesen Fehler auslösen; ein identischer Fehler im PowerShell-Modus ist damit nicht belegt. Laut Sophos tritt dieses konkrete Zuordnungsproblem bei Gmail auf Android und Mail auf iOS nicht auf, weil Sophos Mobile deren ActiveSync-ID beim Enrollment erhält. Andere Mailfehler sind damit nicht ausgeschlossen. Die tatsächlich verwendeten Mail-Apps, Protokolle und Geräte-IDs in beiden Modi prüfen. Bei failed to resolve active sync id zunächst die EAS-Fehlersuche zur lesenden Eingrenzung nutzen. Ein Zuordnungsfehler gibt weder einen ID-Reset noch eine geänderte Benutzerzuordnung frei; einen nötigen Reparaturschritt erst nach eindeutiger Gerätezuordnung und eigener Freigabe mit dem Betriebsteam klären.

Separate Ausnahme für Exchange Online, Outlook und Conditional Access: Wenn sich ein Benutzer in Outlook für iOS oder Android anmeldet, werden laut Microsoft die Exchange-Online-Gerätezugriffsregeln Allow/Block/Quarantine (ABQ) übersprungen, sofern eine für diesen Benutzer geltende Microsoft-Entra-Conditional-Access-Richtlinie Exchange Online oder Office 365 als Cloud-App, iOS und/oder Android als Geräteplattform, „Mobile apps and desktop client“ als Client-Apps und mindestens eine Zugriffsgewährung umfasst: konformes Gerät, genehmigte Client-App oder App-Schutzrichtlinie erforderlich. Das gilt nicht für jede Outlook-Nutzung oder jede Conditional-Access-Richtlinie; Conditional Access kann weiterhin den Zugriff beschränken. Microsoft warnt, dass ABQ allein keine Sicherheitsgarantie bietet: Ein Client mit gefälschtem DeviceType-Header kann eine Sperre für einen bestimmten Gerätetyp möglicherweise umgehen. Für Exchange Online auch Richtlinien und Zugriffsregeln von Basic Mobility and Security prüfen: Nach der Registrierung dort haben sie für das Gerät Vorrang vor Exchange-Richtlinien für mobile Gerätepostfächer und Gerätezugriffsregeln. Weder eine ABQ-Entscheidung noch das Fehlen dieser speziellen Conditional-Access-Ausnahme als Sicherheitsgrenze behandeln. Sie unterscheidet sich vom oben genannten ActiveSync-ID-Zuordnungsproblem im Proxy-Modus. Für Exchange Online beschreibt Microsoft für Outlook auf iOS und Android die native Synchronisierung statt EAS; vor einer Aussage über EAS-Zugriffskontrollen das tatsächlich verwendete Client-Protokoll prüfen. Die folgenden EAS-Anmeldeprüfungen gelten nur bei tatsächlicher EAS-Nutzung; sonst die Anmeldung und den Datenpfad der wirklichen Mail-App testen. Für diesen betroffenen Pfad ist nicht davon auszugehen, dass Sophos-gestützte Exchange-ABQ-Entscheidungen oder Quarantäne den Zugriff durchsetzen, nur weil die PowerShell-Verwaltungsverbindung funktioniert. Vor einer Architekturempfehlung im Ziel-Tenant die tatsächlich betroffene Benutzeridentität, Mail-App, geltenden Conditional-Access-Bedingungen für Cloud-App/Plattform/Client-App/Zugriffsgewährung und die Exchange-Gerätezugriffsentscheidung prüfen; für repräsentative Geräte tatsächliche Anmeldung, Senden, Empfangen und Synchronisation in autorisierten Tests verifizieren.

Exchange Online und Server-Lebenszyklus getrennt beurteilen

Exchange Online – kein Basic-Rückweg: Microsoft hat Basic Authentication für EAS-Clientanmeldungen und für Remote PowerShell in allen Tenants abgeschaltet; sie lässt sich dafür nicht wieder aktivieren. Ein Basic-Fallback wäre deshalb weder eine Reparatur der Verwaltungsanmeldung noch einer EAS-Mail-App mit Basic-Anmeldung. Die Sophos-Setupanleitung vom 9. September 2026 beschreibt keinen Ablauf „moderne Authentifizierung, bei Fehlschlag Basic“; aus dessen Fehlen lässt sich aber auch kein anderer Anmeldeablauf des Dienstes ableiten. Der Sophos-Setuptext nennt noch /powershell-liveid; Microsoft unterstützt für Exchange Online PowerShell REST-Verbindungen. Ob ein konkreter Sophos-Build diesen Pfad nutzt, ist damit nicht geklärt. Die Sophos-Anweisung zu Basic am lokalen Exchange-PowerShell-Verzeichnis ist keine Exchange-Online-Anleitung. Basic oder WinRM Basic nicht als Abhilfe für Exchange Online aktivieren.

Exchange Online – TLS und Anmeldung getrennt prüfen: Die Sophos-Option „Allow all certificates“ schaltet die Prüfung des Serverzertifikats ab und schwächt die Sicherheit der Verbindung; sie ist kein Nachweis eines unterstützten TLS- oder REST-Verwaltungspfads und keine Lösung für Basic-Abschaltung. Zertifikatsvertrauen und TLS-Verbindung prüfen, nicht die Zertifikatsprüfung umgehen. Für die eigene Umgebung die Freigabe des konkreten Proxy-Builds, der Version des ExchangeOnlineManagement-Moduls, des vom Dienst tatsächlich verwendeten PowerShell-Hosts samt Version, der Windows-Version und der .NET-Framework- beziehungsweise .NET-Version gemäss Microsofts Modul-/Host-/OS-Matrix, der Cloud, des OAuth-/REST-Verwaltungspfads, der Konto-Berechtigungen sowie von MFA und Conditional Access bei Sophos einholen; weder eine Modulinstallation noch eine passende Host-Version belegt, welchen Transport der Sophos-Dienst tatsächlich nutzt oder ob seine Anmeldung funktioniert. In einem autorisierten Test-Tenant sind zwei getrennte Prüfungen nötig: Kann der Dienst Exchange verwalten (Verbindung und Berechtigung), und können die vorgesehenen Geräte mit ihrer tatsächlichen Mail-App EAS anmelden und synchronisieren? Ein erfolgreicher Verwaltungskontakt beweist keinen Mailzugriff.

Lokaler Exchange Server: Die Sophos-Setupanleitung fordert für den lokalen Exchange-PowerShell-Verzeichnispfad die Aktivierung von BasicAuthentication. Das belegt nicht, dass jede lokale Verwaltungsverbindung stets Basic verwendet; es betrifft weder die EAS-Clientanmeldung noch Exchange Online und ist keine pauschale Freigabe, Basic lokal zu aktivieren. Lokale Authentisierung und Härtung bedürfen einer eigenen Sicherheitsfreigabe. Sophos nennt Exchange 2016/2019; Microsofts regulärer Support für beide endete am 14. Oktober 2025. Exchange Server Subscription Edition (SE) ist in dieser Sophos-Angabe nicht enthalten. Eine Microsoft-Migrationsoption ist keine Sophos-Zertifizierung. Server-Build, Lifecycle beziehungsweise mögliche Sondervereinbarungen und Sophos-Freigabe für genau dieses Ziel separat einholen, statt aus einem Architekturdiagramm eine Produktionsfreigabe abzuleiten.

Was zur freigegebenen PowerShell-Einrichtung gehört

Die PowerShell-Einrichtung umfasst Hostvorbereitung, ein dediziertes Exchange-Dienstkonto, die Instanzverbindung und deren Zertifikatszuordnung. Die folgenden dokumentierten Schritte und Felder helfen bei der Übergabe an das Betriebsteam; sie ersetzen weder die Prüfung des konkreten Builds und Anmeldepfads noch einen genehmigten Change. Die separate EAS-Installationsvorprüfung übernimmt die Host-, Dienstkonto- und Installationsabklärung, ist aber ebenfalls kein freigegebenes Setup-Runbook. Ausführungsrichtlinien, lokale Basic-Einstellungen, systemweite Proxy-Einstellungen und Dienstneustarts nicht allein aufgrund dieses Artikels ändern. Ausgangszustand, Auswirkungen und Rückweg dafür separat dokumentieren und freigeben.

Host, lokaler Exchange und Dienstkonto

• Auf dem EAS-Host: Sophos nennt bei Bedarf die Installation von Windows PowerShell. Dessen Version und Eignung sind vor einer Installation mit dem Betriebsteam für den konkreten Build abzugleichen. Danach beschreibt die Anleitung in einer als Administrator geöffneten PowerShell die Änderung der Ausführungsrichtlinie auf RemoteSigned. Diese Vorbereitung belegt noch nicht, welchen PowerShell-Host der Sophos-Dienst verwendet oder ob er damit kompatibel ist.
• Nur bei lokalem Exchange Server: In der Exchange Management Shell beschreibt Sophos einen eigenen RemoteSigned-Schritt und anschliessend die Ermittlung des tatsächlichen PowerShell-Verzeichnisses mit Get-PowerShellVirtualDirectory -Server <server name>. Der Platzhalter steht für den Computernamen des Exchange Servers, nicht für den EAS-Host oder den Instanznamen. Nur bei einer Standardinstallation nennt Sophos PowerShell (Default Web Site) als Verzeichnis. Erst nach dieser Ermittlung folgt in der offiziellen Anleitung die Aktivierung von BasicAuthentication für das betreffende virtuelle Verzeichnis. Diese Änderung bleibt dem separat genehmigten lokalen Setup vorbehalten; sie gehört ausdrücklich nicht in eine Exchange-Online-Einrichtung.
• Dienstkonto: Sophos verwendet ein dediziertes Benutzerkonto auf dem Exchange-Mailserver, um PowerShell-Befehle auszuführen. Die Erstellung unterscheidet sich zwischen Exchange Server und Exchange Online; Kontoerstellung, Berechtigungen und Anmeldeverfahren sind mit dem Exchange-Team im Rahmen der EAS-Installationsvorprüfung für das konkrete Ziel zu klären. Ein Passwortfeld reicht dafür nicht; hier weder ein Konto noch Rollen anlegen.

Verbindungsassistent und Abschluss

Die Verbindung wird im Installationsassistenten vorbereitet; dessen Ausführung bleibt dem separat genehmigten Installations-Change vorbehalten. Auf EAS Proxy instance setup sind folgende Felder dokumentiert:

• Instance type: PowerShell Exchange/Office 365.
• Instance name: Ein selbst gewählter Name zur eindeutigen Identifikation der Instanz.
• Exchange server: Bei lokalem Exchange der Servername oder dessen IP-Adresse; für den globalen Microsoft-365-Dienst nennt Sophos outlook.office365.com. Für andere Clouds ist der passende Verbindungsendpunkt separat mit dem Exchange-Team zu bestätigen; Sophos nennt dafür die -ConnectionUri-Zuordnung von Connect-ExchangeOnline. Laut Sophos werden https:// und /powershell-liveid nicht in dieses Feld eingetragen, weil der Assistent sie ergänzt. Das dokumentiert das Feldverhalten, keinen für 2026 verifizierten Exchange-Online-Transport. Keinen Ersatz-Endpunkt raten; die oben geforderte Build-, Cloud- und Anmeldeprüfung bleibt nötig.
• Service account und Password: Name und Passwort des zuvor erstellten Dienstkontos. Zugangsdaten nicht in Audit-Dateien, Beispiele oder Tickets übernehmen; die Felder allein belegen keine Authentifizierungsmethode.

Mit Add kommt die Verbindung in die Liste Instances. Für weitere Exchange-Server-Instanzen beschreibt Sophos die Wiederholung dieser Konfiguration und danach den Abschluss des Assistenten. Die Option Allow all certificates bleibt trotz dieser Feldübersicht keine empfohlene Abkürzung: Zertifikatsvertrauen prüfen, statt die Serverprüfung auszuschalten.

Optionaler ausgehender Verbindungsproxy: Muss der EAS-Host Exchange Server oder Exchange Online über einen Netzwerkproxy erreichen, beschreibt Sophos dafür einen WinHTTP-Schritt auf dem EAS-Host in einer Eingabeaufforderung mit Run as administrator. Die konkrete WinHTTP-Konfiguration bleibt dem Betriebsteam und dem dafür genehmigten Installations-Change vorbehalten; sie ist kein Proxy-Modus für Geräte-Mail. Die Einstellung wirkt systemweit und kann andere Programme auf dem Windows-Host betreffen. Vor einer solchen Änderung brauchen auch diese Abhängigkeiten einen dokumentierten Ausgangszustand und einen freigegebenen Rückweg; daraus folgt kein allgemeiner Proxy-Fix für Anmeldefehler.

Zum Abschluss beschreibt Sophos den Upload des bei der Konfiguration erzeugten PowerShell-Verbindungszertifikats unter My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file. Bei mehreren Instanzen werden alle Instanzzertifikate hochgeladen, danach folgt Save und ein genehmigter Neustart von EASProxy im Windows-Dialog Services. Dafür Wartungsfenster, Dienstzustand und Rückweg mit dem Betriebsteam klären. Gespeicherte Zertifikate oder ein neuer Last active-Wert beweisen weder erfolgreiche Geräteanmeldung noch Mailzustellung: Anmeldung, Senden, Empfangen und Sync sind weiterhin pro betroffenem Gerät vor und nach dem Change zu prüfen.

Vor jeder Änderung am EAS-Zugriff

Mit einer bereits eingerichteten und geprüften PowerShell-Kontrollverbindung lässt sich Exchange so konfigurieren, dass Geräte ohne Enrollment in Sophos Mobile in Quarantäne kommen und keinen Mailzugriff erhalten. Das gilt nur, wo die oben beschriebenen Protokoll- und ABQ-Grenzen diese Kontrolle zulassen. Die Sperre nicht eingeschriebener Geräte ist eine separate organisationsweite Zugriffsänderung für das Exchange-/Mobile-Betriebsteam, kein Abschluss der Installation. Ihre Architektur- und Sicherheitsvorprüfung folgt hier; die Einrichtung der Kontrollverbindung gehört zur separaten EAS-Installationsvorprüfung. Sophos beschreibt dabei eine Exchange-Benachrichtigung, die Benutzer zum Enrollment auffordert. Im dokumentierten Beispiel setzt Set-ActiveSyncOrganizationSettings mit -DefaultAccessLevel quarantine den organisationsweiten Standard; -UserMailInsert ergänzt die Quarantäne-Mail um einen anpassbaren Enrollment-Hinweis. Dieser Artikel empfiehlt nicht, den Befehl auszuführen. Die Voraussetzungen, Auswirkungen und der genehmigte Rückweg müssen zuerst geklärt sein.

Der Administrationskontext unterscheidet sich: Für lokalen Exchange Server ist die Exchange Management Shell vorgesehen, für die Cloud eine separat geprüfte Exchange-Online-PowerShell-Verbindung mit passendem Konto und unterstütztem Anmelde-/Transportpfad. Eine lokale Shell oder deren Basic-Einstellung ersetzt keine geprüfte Cloud-Verbindung.

Eine organisationsweite Exchange-Quarantäne ist kein Pilot-Schalter für ein einzelnes Testgerät. Wo Exchange ABQ tatsächlich durchgesetzt wird, kann der Wechsel der Exchange-Standardzugriffsstufe von „Allow“ auf „Quarantine“ bereits verbundene EAS-Geräte sofort betreffen, nicht nur unbekannte oder neue Geräte, sofern keine Gerätezugriffsregel oder individuelle Allow-/Block-Entscheidung greift. Für den oben beschriebenen qualifizierenden Exchange-Online-Outlook-/Conditional-Access-Pfad gilt diese Wirkung nicht: Exchange-ABQ-Regeln werden dort übersprungen. Im PowerShell-Modus können auch bereits enrollte Geräte in Quarantäne geraten, wenn deren Compliance-Status nach ausbleibender Synchronisation oder bei gestörter Verbindung zu Sophos Mobile unbekannt ist, sofern ABQ für ihren Pfad gilt. Automatische Freigabe nach erfolgreichem Enrollment setzt eine funktionierende Kontrollstrecke voraus; sie ist keine garantierte Entstörung.

Vor einem freigegebenen Change den bisherigen Exchange-DefaultAccessLevel, den Benachrichtigungstext, bestehende Gerätezugriffsregeln und individuelle Allow-/Block-Einträge sowie Geräte- und Mail-App-Inventar, aktuellen Sync- und Compliance-Status, Zertifikatsvertrauen und Verantwortliche festhalten. Für Testpostfächer erlaubte, unbekannte und vorübergehend nicht beurteilbare Geräte beobachten; verfügbare Sophos-, Exchange- und Entra-Ereignisse auf Entscheidungen und Verbindungsfehler prüfen und ihre Zuordnung zum jeweiligen Gerät im Ziel-Tenant verifizieren. Vor der Änderung mit vereinbarten Testpostfächern pro betroffenem Gerät tatsächliche EAS-Anmeldung, Senden, Empfangen und Sync prüfen; Ereignisse allein belegen die Auswirkung nicht. Im Sophos-Menü My Products > Mobile > Setup > Sophos setup > EAS proxy zeigt unter External > Last active der Wert je Proxy-Instanz nur deren letzten Kontakt mit Sophos Mobile, nicht eine erfolgreiche Anmeldung, Zustellung oder Freigabe jedes Geräts.

Der genehmigte Rückweg muss die Wiederherstellung der dokumentierten Standardzugriffsstufe, Regeln, individuellen Entscheidungen und des Benachrichtigungstexts samt Zuständigkeit und Abbruchkriterien abdecken. Nur den Default zurückzustellen reicht nicht als Nachweis der Wiederherstellung: Geräte können weiter in einem unerwarteten Zustand bleiben; nach dem Rückweg mit den vereinbarten Testpostfächern tatsächliche EAS-Anmeldung, Senden, Empfangen und Sync der betroffenen Geräte einzeln prüfen, auch nach veraltetem Compliance-Status oder Ausfall der Sophos-Kontrollverbindung. Bis Authentifizierung, Mailpfad und Rückweg nachgewiesen und der Change genehmigt sind, empfiehlt dieser Artikel weder Installation noch Quarantäne-Umschaltung oder Migration.