Sophos Mobile: från Exchange Server till Exchange Online

Vid övergång från en lokal Exchange Server till Exchange Online måste e-postkontokonfigurationen i berörda Sophos Mobile-policyer omprövas. Det är inte samma sak som att migrera postlådor: Sophos Mobile distribuerar inställningar till enheter, medan möjligheten för användare att logga in samt skicka och ta emot meddelanden även beror på e-postappen, autentiseringen, klientorganisationen och Exchange-miljön.

Viktigt: Den här artikeln ger stöd för planering, inte en instruktion för produktionsövergång. Sophos migreringsbeskrivning är från den 22 juni 2023. Den beskriver hur policyerna fungerar, men verifierar inte aktuell kompatibilitet från början till slut för den egna klientorganisationen. Ta inte bort gamla policyer eller e-postkonton enbart med stöd av den här artikeln.

Vad som behöver ändras i Sophos Mobile

Sophos beskriver två alternativ: uppdatera den befintliga policyn med en ny Email account-konfiguration eller ersätta den med en ny policy. Det dokumenterade exemplet utgår från att policyn ersätts. Beroende på befintlig miljö kan policyer för Android Enterprise-enheter och arbetsprofiler, äldre Android-enhetspolicyer, iOS-enhets- och användarpolicyer, macOS-användarpolicyer samt Windows-policyer beröras. Uppräkningen är ett stöd för inventering, inte en bekräftelse på att alla dessa klienter stöder Exchange Online med den valda inloggningsmetoden.

Förbered policyerna innan enheterna ställs om

Om det är enklare att uppdatera eller ersätta en policy beror på den befintliga policystrukturen. Om en delad policy innehåller ytterligare konfigurationer måste deras tillämpningsområde bevaras och kontrolleras vid båda alternativen; en ändring är inte begränsad till den valda pilotenheten. För exemplet med policybyte ska först en ny policy förberedas utan att tilldelas. Ett alternativ är att duplicera den policy som är tilldelad i dag; det är ingen obligatorisk metod. Kontrollera övertagna inställningar med avseende på konfigurationer som fortfarande behövs, gamla konton och rätt tillämpningsområde för användare och enheter. Upprepa förberedelserna för varje policyfamilj som faktiskt berörs i inventeringen ovan. Skicka ännu inget åtgärdspaket och ta inte bort någon gammal policy.

Koppla konto, moln och autentisering till rätt inställningar

Det allmänna migreringsexemplet anger outlook.office365.com för Microsoft 365:s globala moln i fältet Server name och %_EMAILADDRESS_% i fältet User. Sophos Mobile ersätter platshållaren med användarens e-postadress. Det garanterar inte att e-postadressen och det faktiska inloggningsnamnet är samma i den egna klientorganisationen. För ett annat moln ska motsvarande datauppsättning väljas i Microsofts löpande uppdaterade bibliotek Microsoft 365 URLs and IP address ranges: standardvyn är Worldwide (+GCC); 21Vianet, DoD och GCC High har egna datauppsättningar. Använd inte värdnamnet för det globala molnet utan kontroll.

OAuth-valet förutsätter att modern autentisering för Exchange Online är aktiverad i klientorganisationen. Kontrollera detta separat med Exchange-teamet. Därefter anger migreringsexemplet för Android Enterprise Authentication > Modern authentication, och för iOS och macOS Turn on OAuth 2.0. För Windows och äldre Android-policyer visar källan inget motsvarande OAuth-val. Varken valet av en inställning eller ett tidigare påstående om en standardinställning för klientorganisationen bevisar att den faktiska e-postklienten kan logga in. Aktivera SSL/TLS; en krypterad anslutning med korrekt certifikatkontroll måste ingå i godkännandet. En misslyckad inloggning ska inte åtgärdas genom att stänga av TLS-kontroller.

Aktuell iOS-enhetspolicy: automatisk sökning efter Exchange-värden med OAuth i stället för ett generellt servervärde. I Email account för Apple Mail lämnas Server name tomt med OAuth: Exchange-värden identifieras automatiskt. Ange OAuth authorization endpoint endast om autentiseringsleverantören kräver det; då används inte den automatiska sökningen och Server name måste innehålla rätt server-URL. Fyll även i OAuth token endpoint endast om leverantören kräver det. Den allmänna värdmappningen ovan är därför inte ett ovillkorligt konfigurationssteg för iOS med OAuth. För Exchange Online lämnas Domain tomt. %_EMAILADDRESS_% i User ersätts med adressen för den användare som är kopplad till enheten; för detta måste användarens Exchange Login och Email Address vara angivna i Sophos Fusion. Kontrollera användarkoppling, ersatta värden, automatisk sökning efter värden och faktisk inloggning var för sig i den auktoriserade piloten. Tillämpa inte automatiskt denna beskrivning av iOS-enhetspolicyer på iOS-användarpolicyer eller andra klienter.

Kontrollera övriga kontoinställningar per policytyp

Att byta värd ersätter inte en fullständig kontroll av Email account. Kontrollera före tilldelning befintligt visningsnamn för kontot, användarkoppling, inloggning, synkroniseringens omfattning, datadelning och eventuella certifikat för varje policytyp. I iOS-enhetspolicyer begränsar Synchronization period vilka e-postmeddelanden som synkroniseras lokalt. Allow move, Allow recent address syncing och Use in Mail only är separata beslut om byte mellan konton, adressynkronisering med iCloud och vilka appar som får skicka. Identity certificate samt S/MIME-signering och -kryptering kräver rätt certifikat i policyn; de följer inte av serverbytet. Bestäm medvetet hur e-post, kalendrar och kontakter ska synkroniseras och vilka ändringar användaren ska få göra, i stället för att okritiskt föra över inställningarna från den gamla profilen.

För separata plattformsuppgifter beskriver iPhone-/iPad-enhetspolicyn hanteringsläge, konton och policyns effekt. Android Enterprise-policyn för företagsenheter omfattar endast Full Device med Gmail, inklusive gammal Gmail-konfiguration, användarkoppling och kravet på Chrome för OAuth; den är ingen instruktion för Work Profile eller äldre Android-hantering. För macOS user policy beskriver macOS-policyn EWS-kontot och dess automatiska sökning efter värden med OAuth, inte EAS. För Windows ska först begränsningarna för konton och klienter klarläggas; de innebär inte att distribution av en aktuell e-postklient stöds. För Android-arbetsprofiler, äldre Android-policyer eller iOS-användarpolicyer ska de kontofält som faktiskt erbjuds och klientkraven kontrolleras separat. Så länge deras beteende inte är bekräftat ska inga värden från en annan policyfamilj tilldelas som en verifierad konfiguration.

Planera åtgärdspaket och framtida registreringar separat

I Sophos exempel på policybyte ingår ett åtgärdspaket med Assign policy för den nya policyn. Uninstall policy för den gamla policyn nämns bara för Android-enhets- och iOS-enhetspolicyer, medan Unassign iOS user policy bara nämns för iOS-användarpolicyer. Befintliga enheter och framtida självbetjäningsregistreringar är separata flöden: Åtgärdspaketet som skickas till befintliga enheter ersätter inte automatiskt registreringspaketet i en konfiguration i Self Service Portal. Om sådana konfigurationer används måste berörda registreringspaket där ersättas med paket som tilldelar den nya policyn; kontrollera varje berörd konfiguration och dess pakettilldelning före ytterligare registreringar. Det kombinerade åtgärdspaketet är ett dokumenterat exempel, inte en godkänd ordningsföljd för ett produktionsbyte. Att paketet har körts eller att en åtgärd rapporteras som slutförd bevisar varken fungerande inloggning, e-postflöde eller att den gamla profilen kan tas bort utan skada.

EAS-åtkomstkontroll är inte e-postens anslutningsväg

Om den befintliga miljön använder Sophos Mobiles EAS proxy för åtkomstkontroll skiljer Sophos mellan två driftlägen för Exchange Online: Enligt dokumentationen stöder Proxy mode Exchange Server, men inte Exchange Online. I PowerShell mode kommunicerar enheterna direkt med Exchange; Sophos-tjänsten styr åtkomstbeslut via Exchange-administrationsgränssnittet. E-postappen behöver fortfarande en egen fungerande väg för inloggning och dataöverföring. Enligt Sophos är PowerShell-baserad ActiveSync-åtkomstkontroll inte tillgänglig för Mac-datorer.

För Sophos-tjänstens autentisering finns en olöst fråga som behöver redas ut: Sophos beskrivning från januari 2026 anger att ett försök med Basic Authentication görs om modern inloggning misslyckas. Microsoft tillåter inte att Basic Authentication återaktiveras för Exchange Online EAS eller Remote PowerShell. Den beskrivna reservmetoden är därför ingen väg till återställning. Sophos beskriver separat Basic för sin tjänsts administrativa anslutning i PowerShell-läge till en lokal Exchange Server; det gäller varken EAS-klienters inloggning eller Exchange Online och ger inte rätt att aktivera Basic utan säkerhetsgodkännande. Dessutom anger Sophos installationsanvisning från september 2026 anslutnings-URI:n /powershell-liveid. Microsoft anger samma URI som standardvärde i den aktuella dokumentationen för Connect-ExchangeOnline-modulen, som beskriver moderna REST-anslutningar utan WinRM Basic. URI:n ensam bevisar varken att transporten är föråldrad eller att den aktuella Sophos-versionen är kompatibel; modul, inloggning och faktiskt anslutningsbeteende är fortfarande okontrollerade. Sophos PowerShell-anvisning från september 2026 listar fortfarande Exchange Server 2016 och 2019 som versioner som stöds; Microsofts supportöversikt anger den 14 oktober 2025 som slutdatum för båda. Separat anger Microsofts livscykeltabeller för Exchange Server 2016 och Exchange Server 2019 vardera den 15 oktober 2025 kl. 06:59:59 Pacific Time som sluttidpunkt för utökad support. Dessa primärkällor skiljer sig åt beträffande kalenderdagen och ingen förklarar avvikelsen. Dra ingen slutsats om en gemensam tidpunkt eller ytterligare en supportdag. Sophos lista innebär alltså inget godkännande av servrarnas livscykelstatus. Innan åtkomstkontroll tas i bruk måste versionen av proxykomponenten som stöds, modul, molnändpunkt, tjänstkonto, behörigheter och den faktiska OAuth-/REST-anslutningen samt supportstatus för den befintliga servermiljön klarläggas med Sophos och ansvarigt Exchange-team. Dra inte slutsatsen att Basic, WinRM Basic eller avstängd certifikatkontroll generellt är godkända.

PowerShell-konfiguration som en separat, villkorad uppgift

Detta alternativ behövs bara om EAS-åtkomstkontroll faktiskt ska användas. EAS-arkitekturbeslutet behandlar klientprotokoll, enhetsidentitet och karantän; förkontrollen inför installation behandlar värd, programversion, tjänstkonto och certifikatförtroende. Båda är förkontroller, inte godkända körinstruktioner för installation. För migreringsplaneringen kan konfigurationen delas upp i tre separata delar:

Administrationsmiljö och tjänstkonto: Få bekräftat att rätt PowerShell- och modulmiljö finns på den avsedda värden och att ett separat Exchange-administrationskonto har nödvändiga behörigheter och uppfyller klientorganisationens inloggningskrav. Förutsättningarna för Exchange Server och Exchange Online är inte utbytbara. Kommandon för att aktivera Basic i den lokala Exchange-PowerShell-katalogen hör inte hemma i en Exchange Online-ändring. Även ändringar av PowerShells körningspolicy är ett ingrepp på värden som kräver separat godkännande.
Instans och anslutning: Konfigurationsguiden beskriver på EAS Proxy instance setup valet Instance type > PowerShell Exchange/Office 365, ett valfritt Instance name, målet under Exchange server och Service account med Password. Detta är fält för förberedelser, inte redan bekräftade värden för den egna programversionen. För det globala molnet anger exemplet outlook.office365.com; guiden lägger själv till protokoll och sökväg. Kopiera inte okritiskt en fullständig URI till värdfältet och dra ingen slutsats om att transporten är godkänd i dag utifrån den tillagda sökvägen. Allow all certificates stänger av kontrollen av servercertifikatet och ska förbli avstängt i denna plan; åtgärda ett förtroendefel separat. Att administrationsinloggningen stöds måste verifieras oberoende av enheternas e-postanslutning.
Instansens förtroenderelation till Sophos Mobile: Certifikatet som skapas under konfigurationen för varje PowerShell-instans måste vara kopplat till rätt instans. Den dokumenterade uppladdningen finns under My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file, följt av Save. Det är inte samma certifikat som serverns TLS-certifikat eller ett klientcertifikat i e-postprofilen. Den efterföljande omstart av Windows-tjänsten EASProxy som beskrivs innebär ett driftavbrott och hör enbart hemma i en separat godkänd ändring med kontroll av start och återgång; genomför varken uppladdning eller omstart här.

Utan bekräftad programversion, inloggning, certifikatkoppling och återgångsväg stannar arbetet vid dessa förberedelser. Ett angivet konto, ett uppladdat certifikat eller en nåbar tjänst bevisar varken att ett åtkomstbeslut verkställs eller att det går att skicka och ta emot e-post. Utvärdera dessa tre anslutningsvägar var för sig först efter ett separat godkännande; använd inte bred Exchange-karantän som installationstest.

Klargör detta före ett beslut om produktionssättning

Berörda grupper: Inventera separat ägarförhållande och hanteringsläge, befintlig och planerad policy, enhet och operativsystem, e-postapp, kontotyp och använd autentisering. Dra inga slutsatser om OAuth-kompatibilitet för Windows eller äldre Android-klienter utifrån Sophos migreringslista.
Klientorganisation och behörigheter: Kontrollera Microsoft-moln, ändpunkt, Exchange Online-abonnemang och användarpostlådor. Tjänstkontot för åtkomstkontroll använder en annan inloggningsväg än användarens e-postkonto. Kontrollera behörigheter och krav på MFA och villkorlig åtkomst med Exchange-teamet i stället för att förutsätta omfattande administratörsbehörigheter eller en reservmetod med Basic Authentication.
Säker utvärdering: Börja på en auktoriserad pilotenhet med testpostlåda, utan att tilldela eller avinstallera någon policy: dokumentera målenhet, befintlig tilldelning, synkroniseringsstatus, e-postapp, postlådans tillstånd och befintliga e-postdata. Före varje pilotändring ska stödd inloggning, möjliga konsekvenser för profiler och data, en verifierbar säkerhetskopia av berörda data samt kriterier för avbrott och återgång klarläggas med Exchange-teamet. Om konsekvenserna eller återgångsvägen är okända, stanna här. Först därefter bör en separat godkänd policyändring, begränsad till pilotgruppen, planeras. Kontrollera att de nya kontoinställningarna träder i kraft, att faktisk inloggning, sändning och mottagning fungerar och – om EAS-åtkomstkontroll används – att avsett åtkomstbeslut fattas. Besluta om bred distribution eller borttagning av den gamla policyn först efter denna utvärdering. Förutsätt inte att gamla och nya profiler kan finnas samtidigt eller att Uninstall policy kan ångras. Kör inte avinstallationen som en enkel förkontroll i piloten. Vid avvikelser, undersök först klienten och inloggningen och därefter separat åtkomstkontrollens anslutning. Aktivera inte en bred spärr för okända enheter som diagnostiskt steg.
Återgång och godkännande: Dokumentera gamla och nya policyer samt åtgärdspaket för självbetjäning. Klargör ändringsfönster, avbrottskriterier, ansvar och möjligheten att återställa den faktiska postlåde- och servermiljön före övergången. Att tilldela den gamla Sophos-policyn igen återställer varken en postlåda som redan har flyttats eller en lokal Exchange Server som har stängts av.

Så länge dessa punkter inte har bekräftats för den aktuella miljön är policybeskrivningen endast ett planeringsunderlag. Här förespråkas varken en produktionsövergång eller en generell rollback, och ingen garanti ges för att övergången lyckas.