Sophos Mobile: Exchange Server zu Exchange Online

Beim Wechsel von einem lokalen Exchange Server zu Exchange Online muss die E-Mail-Kontokonfiguration der betroffenen Sophos-Mobile-Richtlinien neu beurteilt werden. Das ist nicht dasselbe wie eine Postfachmigration: Sophos Mobile verteilt Einstellungen an Geräte; ob Benutzer sich anmelden und Nachrichten senden und empfangen können, hängt zusätzlich von Mail-App, Authentifizierung, Tenant und Exchange-Umgebung ab.

Wichtig: Dieser Artikel dient als Orientierung zur Planung, nicht als Anleitung für einen produktiven Cutover. Die Sophos-Migrationsbeschreibung stammt vom 22. Juni 2023. Sie dokumentiert Richtlinienmechanik, aber keine heute verifizierte Ende-zu-Ende-Kompatibilität für den eigenen Tenant. Alte Richtlinien oder Mailkonten nicht allein aufgrund dieses Artikels entfernen.

Was an Sophos Mobile angepasst werden muss

Sophos beschreibt zwei Wege: die vorhandene Richtlinie mit einer neuen Email account-Konfiguration aktualisieren oder sie durch eine neue Richtlinie ersetzen. Die dokumentierte Beispielvariante ersetzt die Richtlinie. Je nach Bestand können Android-Enterprise-Geräte- und Arbeitsprofilrichtlinien, ältere Android-Geräterichtlinien, iOS-Geräte- und Benutzerrichtlinien, macOS-Benutzerrichtlinien sowie Windows-Richtlinien betroffen sein. Diese Aufzählung ist eine Inventurhilfe, keine Bestätigung, dass jeder dieser Clients Exchange Online mit der gewählten Anmeldung unterstützt.

Richtlinien vorbereiten, bevor Geräte umgestellt werden

Ob eine Aktualisierung oder ein Ersatz einfacher ist, hängt von der vorhandenen Richtlinienstruktur ab. Enthält eine gemeinsam genutzte Richtlinie weitere Konfigurationen, muss deren Geltungsbereich bei beiden Wegen erhalten und geprüft werden; eine Änderung daran ist nicht auf das ausgewählte Pilotgerät begrenzt. Für das Ersatzbeispiel zunächst eine neue, noch nicht zugewiesene Richtlinie vorbereiten. Eine Möglichkeit ist, die aktuell zugewiesene Richtlinie zu duplizieren; das ist keine vorgeschriebene Methode. Übernommene Einstellungen auf weiterhin benötigte Payloads, alte Konten und den richtigen Benutzer-/Gerätescope prüfen. Diese Vorbereitung für jede tatsächlich betroffene Richtlinienfamilie aus der obigen Inventur wiederholen. Noch kein Aufgabenpaket übertragen und keine alte Richtlinie entfernen.

Konto, Cloud und Authentifizierung zuordnen

Das allgemeine Migrationsbeispiel ordnet outlook.office365.com für die weltweite Microsoft-365-Cloud dem Feld Server name und %_EMAILADDRESS_% dem Feld User zu. Sophos Mobile ersetzt den Platzhalter mit der E-Mail-Adresse des Benutzers. Das ist keine Zusage, dass E-Mail-Adresse und tatsächlicher Anmeldename im eigenen Tenant übereinstimmen. Für eine andere Cloud den passenden Datensatz in Microsofts laufend gepflegter Bibliothek Microsoft 365 URLs and IP address ranges auswählen: Die Standardansicht ist Worldwide (+GCC); 21Vianet, DoD und GCC High haben eigene Datensätze. Den weltweit verwendeten Host nicht ungeprüft übernehmen.

Die OAuth-Auswahl setzt voraus, dass moderne Authentifizierung für Exchange Online im Tenant eingeschaltet ist. Diesen Zustand mit dem Exchange-Team separat prüfen. Dann nennt das Migrationsbeispiel für Android Enterprise Authentication > Modern authentication, für iOS und macOS Turn on OAuth 2.0. Für Windows und ältere Android-Richtlinien zeigt diese Quelle keine entsprechende OAuth-Auswahl. Weder das Setzen einer Option noch die frühere Aussage über einen Tenant-Default belegt eine erfolgreiche Anmeldung des tatsächlichen Mail-Clients. SSL/TLS einschalten; eine verschlüsselte Verbindung mit gültiger Zertifikatsprüfung gehört zur Freigabe. Fehlgeschlagene Anmeldung wird nicht durch Abschalten von TLS-Prüfungen behoben.

Aktuelle iOS-Geräterichtlinie: OAuth-Hostsuche statt pauschalem Serverwert. Bei Email account für Apple Mail bleibt Server name mit OAuth leer: Der Exchange-Host wird automatisch ermittelt. Nur wenn der Authentifizierungsanbieter einen OAuth authorization endpoint verlangt, diesen eintragen; damit entfällt die Hostsuche und Server name muss die passende Server-URL enthalten. Auch OAuth token endpoint nur bei einer Anbietervorgabe befüllen. Die allgemeine Hostzuordnung oben ist daher kein unbedingter Konfigurationsschritt für iOS mit OAuth. Für Exchange Online bleibt Domain leer. %_EMAILADDRESS_% in User setzt die Adresse des dem Gerät zugeordneten Benutzers ein; dafür müssen Exchange Login und Email Address dieses Benutzers in Sophos Fusion gepflegt sein. Benutzerzuordnung, aufgelöste Werte, Hostsuche und tatsächliche Anmeldung im autorisierten Pilot getrennt prüfen. Diese iOS-Gerätebeschreibung nicht automatisch auf iOS-Benutzerrichtlinien oder andere Clients übertragen.

Übrige Kontoeinstellungen nach Richtlinientyp prüfen

Der Wechsel des Hosts allein ersetzt keine vollständige Email account-Prüfung. Vor der Zuweisung bestehende Kontoanzeige, Benutzerzuordnung, Anmeldung, Synchronisationsumfang, Datenweitergabe und gegebenenfalls Zertifikate je Richtlinientyp abgleichen. Bei iOS-Geräterichtlinien begrenzt Synchronization period die lokal synchronisierten Mails. Allow move, Allow recent address syncing und Use in Mail only sind getrennte Entscheidungen über Kontenwechsel, iCloud-Adressabgleich und sendende Apps. Identity certificate sowie S/MIME-Signatur und -Verschlüsselung benötigen die passenden Zertifikate der Richtlinie; sie ergeben sich nicht aus dem Serverwechsel. Mail-, Kalender- und Kontaktsynchronisation samt erlaubter Benutzeränderungen bewusst festlegen, nicht blind aus dem alten Profil übernehmen.

Für eigenständige Plattformaufgaben führt die iPhone-/iPad-Geräterichtlinie durch Verwaltungsmodus, Konten und Policy-Wirkung. Die Android-Enterprise-Firmengeräterichtlinie behandelt nur Full Device mit Gmail, einschliesslich alter Gmail-Konfiguration, Benutzerzuordnung und Chrome-Voraussetzung für OAuth; sie ist kein Work-Profile- oder Legacy-Android-Rezept. Für macOS user policy erklärt die macOS-Richtlinie das EWS-Konto und dessen OAuth-Hostsuche, nicht EAS. Bei Windows zuerst die Konten- und Clientgrenzen klären; daraus folgt keine unterstützte Bereitstellung eines aktuellen Mailclients. Bei Android-Arbeitsprofilen, älteren Android-Richtlinien oder iOS-Benutzerrichtlinien die konkret angebotenen Kontofelder und Clientvoraussetzungen separat abgleichen. Solange deren Verhalten nicht bestätigt ist, keine Werte aus einer anderen Richtlinienfamilie als geprüfte Konfiguration zuweisen.

Aufgabenpakete und künftige Registrierungen getrennt planen

Das Sophos-Beispiel nennt für den Richtlinienersatz ein Aufgabenpaket mit Assign policy für die neue Richtlinie; Uninstall policy für die alte Richtlinie nennt es nur bei Android-Geräte- und iOS-Geräterichtlinien, Unassign iOS user policy nur bei iOS-Benutzerrichtlinien. Bestehende Geräte und künftige Self-Service-Registrierungen sind getrennte Pfade: Das an bestehende Geräte übertragene Aufgabenpaket ersetzt nicht automatisch das Registrierungs-Aufgabenpaket einer Konfiguration im Self Service Portal. Falls solche Konfigurationen verwendet werden, die betroffenen Registrierungs-Aufgabenpakete dort durch Pakete ersetzen, die die neue Richtlinie zuweisen; vor weiteren Registrierungen jede betroffene Konfiguration und deren Paketzuteilung prüfen. Das kombinierte Aufgabenpaket ist ein dokumentiertes Beispiel, keine freigegebene Reihenfolge für eine produktive Ablösung. Seine Abarbeitung oder ein erfolgreicher Taskstatus belegt weder eine Anmeldung noch Mailfluss oder eine schadlose Entfernung des alten Profils.

EAS-Zugriffskontrolle ist nicht der Mailweg

Wenn die bisherige Umgebung den Sophos-Mobile-EAS proxy zur Zugriffskontrolle verwendet, trennt Sophos für Exchange Online zwei Betriebsarten: Proxy mode unterstützt nach seiner Dokumentation Exchange Server, nicht Exchange Online. Im PowerShell mode kommunizieren Geräte direkt mit Exchange; der Sophos-Dienst steuert Zugriffsentscheidungen über die Exchange-Verwaltungsschnittstelle. Die Mail-App benötigt weiterhin einen eigenen funktionierenden Anmelde- und Datenpfad. Für Macs ist laut Sophos eine PowerShell-basierte ActiveSync-Zugriffskontrolle nicht verfügbar.

Bei der Authentifizierung des Sophos-Dienstes besteht ein offener Abgleich: Die Sophos-Beschreibung von Januar 2026 nennt nach fehlgeschlagener moderner Anmeldung einen Versuch mit Basic Authentication. Microsoft lässt Basic Authentication für Exchange Online EAS und Remote PowerShell nicht wieder einschalten. Der beschriebene Fallback ist deshalb kein Wiederherstellungsweg. Sophos beschreibt Basic gesondert für die Verwaltungsverbindung seines Dienstes im PowerShell-Modus zu einem lokalen Exchange Server; das betrifft weder die EAS-Clientanmeldung noch Exchange Online und ist keine Freigabe, Basic ohne Sicherheitsprüfung zu aktivieren. Zudem nennt die Sophos-Einrichtung vom September 2026 eine /powershell-liveid-Verbindungs-URI. Microsoft führt diese URI auch in der aktuellen Connect-ExchangeOnline-Moduldokumentation als Standardwert auf; dort sind moderne REST-Verbindungen ohne WinRM Basic dokumentiert. Die URI allein belegt weder einen veralteten Transport noch die Kompatibilität des konkreten Sophos-Builds; dessen Modul, Anmeldung und tatsächliches Verbindungsverhalten bleiben ungeprüft. Die Sophos-PowerShell-Anleitung vom September 2026 führt noch Exchange Server 2016 und 2019 als unterstützte Versionen auf; Microsofts Support-Roadmap nennt für beide den 14. Oktober 2025 als Supportende. Getrennt davon nennen die Microsoft-Lebenszyklustabellen für Exchange Server 2016 und Exchange Server 2019 jeweils den 15. Oktober 2025 um 06:59:59 Uhr Pacific Time als Endzeitpunkt des erweiterten Supports. Diese beiden Primärangaben weichen beim Kalendertag voneinander ab; keine erklärt die Abweichung. Weder einen gemeinsamen Zeitpunkt noch einen weiteren Supporttag daraus ableiten. Die Sophos-Liste ist daher keine Freigabe des Server-Lebenszyklus. Vor einer Zugriffssteuerung müssen unterstützter Proxy-Build, Modul, Cloud-Endpunkt, Dienstkonto, Rechte und tatsächliche OAuth-/REST-Verbindung sowie der Supportstatus der bisherigen Serverumgebung mit Sophos und dem zuständigen Exchange-Team geklärt werden. Keine generische Freigabe für Basic, WinRM Basic oder deaktivierte Zertifikatsprüfung ableiten.

PowerShell-Einrichtung als separate, bedingte Aufgabe

Dieser Zweig ist nur nötig, wenn EAS-Zugriffskontrolle tatsächlich eingesetzt werden soll. Die EAS-Architekturentscheidung behandelt Clientprotokoll, Geräteidentität und Quarantäne; die Installationsvorprüfung behandelt Host, Build, Dienstkonto und Zertifikatsvertrauen. Beide sind Vorprüfungen, keine freigegebenen Setup-Runbooks. Für die Migrationsplanung lässt sich die Einrichtung in drei getrennte Teile zerlegen:

Verwaltungsumgebung und Dienstkonto: Passende PowerShell-/Modulumgebung auf dem vorgesehenen Host und ein eigenes Exchange-Verwaltungskonto samt benötigten Rechten und Tenant-Anmeldevorgaben bestätigen lassen. Die Voraussetzungen für Exchange Server und Exchange Online sind nicht austauschbar. Befehle zur Basic-Aktivierung am lokalen Exchange-PowerShell-Verzeichnis gehören nicht in einen Exchange-Online-Change. Auch Änderungen der PowerShell-Ausführungsrichtlinie sind ein gesondert freizugebender Host-Eingriff.
Instanz und Verbindung: Der Einrichtungsassistent beschreibt auf EAS Proxy instance setup den Instance type > PowerShell Exchange/Office 365, einen frei gewählten Instance name, das Ziel unter Exchange server und Service account samt Password. Das sind Felder zur Vorbereitung, keine bereits bestätigten Werte für den eigenen Build. Für die globale Cloud nennt das Beispiel outlook.office365.com; der Assistent ergänzt Protokoll und Pfad selbst. Keine vollständige URI blind in das Hostfeld übernehmen und aus dem ergänzten Pfad keine aktuelle Transportfreigabe ableiten. Allow all certificates deaktiviert die Serverzertifikatsprüfung und bleibt für diesen Plan ausgeschaltet; einen Vertrauensfehler separat beheben. Die unterstützte Verwaltungsanmeldung muss unabhängig vom Geräte-Mailpfad nachgewiesen werden.
Instanzvertrauen zu Sophos Mobile: Das während der Konfiguration erzeugte Zertifikat jeder PowerShell-Instanz muss der richtigen Instanz zugeordnet sein. Der dokumentierte Upload liegt unter My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file, anschliessend Save. Er ist nicht dasselbe wie das Server-TLS-Zertifikat oder ein Clientzertifikat im Mailprofil. Der danach beschriebene Neustart des Windows-Dienstes EASProxy ist ein Betriebsunterbruch und gehört ausschliesslich in einen separat genehmigten Change mit Start-/Rückwegprüfung; hier weder Upload noch Neustart auslösen.

Ohne bestätigten Build, Anmeldung, Zertifikatszuordnung und Rückweg bleibt es bei dieser Vorbereitung. Ein eingetragenes Konto, hochgeladenes Zertifikat oder erreichbarer Dienst belegt weder eine durchgesetzte Zugriffsentscheidung noch erfolgreiches Senden und Empfangen. Erst nach eigener Freigabe diese drei Strecken getrennt abnehmen; keine breite Exchange-Quarantäne als Setup-Test verwenden.

Vor einer produktiven Entscheidung klären

Betroffene Kohorten: Besitz und Verwaltungsmodus, bisherige und geplante Richtlinie, Gerät und Betriebssystem, Mail-App, Kontoart und verwendete Authentifizierung getrennt erfassen. Für Windows und ältere Android-Clients keine OAuth-Kompatibilität aus der Sophos-Migrationsliste folgern.
Tenant und Berechtigungen: Microsoft-Cloud, Endpoint, Exchange-Online-Plan und Benutzerpostfächer prüfen; das Dienstkonto für die Zugriffskontrolle ist ein anderer Anmeldeweg als das Benutzer-Mailkonto. Berechtigungen und MFA-/Conditional-Access-Vorgaben mit dem Exchange-Team prüfen, statt umfassende Administratorrechte oder einen Basic-Fallback vorauszusetzen.
Sichere Abnahme: Zuerst ohne Richtlinienzuweisung oder Deinstallation auf einem autorisierten Pilotgerät mit Testpostfach Zielgerät, bisherige Zuweisung, Synchronisationsstatus, Mail-App, Postfachzustand und vorhandene Maildaten erfassen. Vor jeder Pilotänderung mit dem Exchange-Team die unterstützte Anmeldung, mögliche Profil- und Datenfolgen, eine überprüfbare Sicherung betroffener Daten sowie Abbruch- und Rückwegkriterien klären; falls Auswirkungen oder Rückweg unbekannt sind, hier stoppen. Erst dann eine separat autorisierte, auf die Pilotkohorte begrenzte Richtlinienänderung planen und wirksame neue Kontoeinstellungen, tatsächliche Anmeldung, Senden, Empfangen und – falls eingesetzt – die beabsichtigte EAS-Zugriffsentscheidung beobachten. Erst nach dieser Abnahme über eine breite Verteilung oder Entfernung der alten Richtlinie entscheiden. Nicht voraussetzen, dass alte und neue Profile gleichzeitig bestehen können oder dass Uninstall policy reversibel ist; keine Deinstallation als blossen Pilot-Vorcheck auslösen. Bei Abweichungen zunächst Client/Anmeldung und getrennt die Verbindung der Zugriffskontrolle untersuchen; keine breite Sperre unbekannter Geräte als Diagnoseschritt aktivieren.
Rückweg und Freigabe: Alte und neue Richtlinien sowie Self-Service-Aufgabenpakete dokumentieren; Change-Fenster, Abbruchkriterien, Zuständigkeit und Wiederherstellbarkeit der wirklichen Postfach- und Serverumgebung vor einer Umstellung klären. Eine Rückzuweisung der alten Sophos-Richtlinie stellt ein bereits verschobenes Postfach oder einen abgeschalteten lokalen Exchange Server nicht wieder her.

Solange diese Punkte nicht für die konkrete Umgebung bestätigt sind, ist die Richtlinienbeschreibung nur eine Planungsgrundlage. Ein produktiver Cutover, eine Erfolgsgarantie oder ein pauschaler Rollback werden hier nicht empfohlen.