Sophos Mobile: migracja z Exchange Server do Exchange Online

Przy przejściu z lokalnego serwera Exchange do Exchange Online trzeba ponownie ocenić konfigurację kont e-mail w zasadach Sophos Mobile dotyczących objętych zmianą urządzeń. Nie jest to to samo co migracja skrzynek pocztowych: Sophos Mobile dostarcza ustawienia na urządzenia; możliwość zalogowania się użytkowników oraz wysyłania i odbierania wiadomości zależy ponadto od aplikacji pocztowej, uwierzytelniania, tenanta i środowiska Exchange.

Ważne: Ten artykuł służy do planowania, nie jest instrukcją przełączenia produkcyjnego. Opis migracji Sophos pochodzi z 22 czerwca 2023 r. Dokumentuje mechanizm działania zasad, ale nie potwierdza aktualnej zgodności całego rozwiązania w danym tenancie. Nie usuwać starych zasad ani kont pocztowych wyłącznie na podstawie tego artykułu.

Co trzeba dostosować w Sophos Mobile

Sophos opisuje dwie możliwości: zaktualizować istniejącą zasadę o nową konfigurację Email account albo zastąpić ją nową zasadą. Udokumentowany przykład pokazuje zastąpienie zasady. W zależności od istniejącej konfiguracji zmiana może dotyczyć zasad urządzeń i profili służbowych Android Enterprise, starszych zasad urządzeń z Androidem, zasad urządzeń i użytkowników iOS, zasad użytkowników macOS oraz zasad Windows. To zestawienie pomaga w inwentaryzacji; nie potwierdza, że każdy z tych klientów obsługuje Exchange Online z wybraną metodą logowania.

Przygotować zasady przed zmianą konfiguracji urządzeń

To, czy łatwiej zaktualizować zasadę, czy ją zastąpić, zależy od istniejącej struktury zasad. Jeśli współdzielona zasada zawiera inne konfiguracje, w obu wariantach trzeba zachować i sprawdzić ich zakres; zmiana takiej zasady nie ogranicza się do wybranego urządzenia pilotażowego. W wariancie zastąpienia najpierw przygotować nową, jeszcze nieprzypisaną zasadę. Jedną z możliwości jest zduplikowanie obecnie przypisanej zasady; nie jest to wymagana metoda. Sprawdzić przejęte ustawienia pod kątem nadal potrzebnych konfiguracji, starych kont i właściwego zakresu użytkowników i urządzeń. Powtórzyć te przygotowania dla każdej rodziny zasad faktycznie objętej zmianą z powyższej inwentaryzacji. Nie wysyłać jeszcze pakietu zadań ani nie usuwać starej zasady.

Dopasować konto, chmurę i uwierzytelnianie

Ogólny przykład migracji przypisuje outlook.office365.com dla globalnej chmury Microsoft 365 do pola Server name, a %_EMAILADDRESS_% do pola User. Sophos Mobile zastępuje symbol zastępczy adresem e-mail użytkownika. Nie gwarantuje to, że adres e-mail i rzeczywista nazwa logowania w danym tenancie są takie same. Dla innej chmury wybrać odpowiedni zestaw danych w aktualizowanej na bieżąco bibliotece Microsoft 365 URLs and IP address ranges: widok domyślny to Worldwide (+GCC); 21Vianet, DoD i GCC High mają osobne zestawy danych. Nie przejmować bez sprawdzenia hosta używanego w chmurze globalnej.

Wybór OAuth wymaga włączenia nowoczesnego uwierzytelniania dla Exchange Online w tenancie. Sprawdzić ten stan osobno z zespołem Exchange. Przykład migracji wskazuje następnie dla Android Enterprise Authentication > Modern authentication, a dla iOS i macOS Turn on OAuth 2.0. Dla Windows i starszych zasad Androida źródło to nie pokazuje odpowiedniej opcji OAuth. Ani włączenie opcji, ani wcześniejsza informacja o domyślnym ustawieniu tenanta nie dowodzą, że rzeczywisty klient pocztowy zdoła się zalogować. Włączyć SSL/TLS. Warunkiem dopuszczenia jest szyfrowane połączenie z prawidłową weryfikacją certyfikatu; błędów logowania nie należy rozwiązywać przez wyłączenie kontroli TLS.

Aktualna zasada urządzeń iOS: wykrywanie hosta OAuth zamiast uniwersalnej wartości serwera. W konfiguracji Email account dla Apple Mail z OAuth pole Server name pozostaje puste: host Exchange jest wykrywany automatycznie. Wypełnić OAuth authorization endpoint tylko wtedy, gdy wymaga tego dostawca uwierzytelniania; wyłącza to wykrywanie hosta i wymaga podania odpowiedniego adresu URL serwera w Server name. Pole OAuth token endpoint również wypełnić tylko na wymaganie dostawcy. Ogólne przypisanie hosta opisane powyżej nie jest więc bezwarunkowym krokiem konfiguracji iOS z OAuth. Dla Exchange Online pole Domain pozostaje puste. %_EMAILADDRESS_% w User wstawia adres użytkownika przypisanego do urządzenia; wymaga to uzupełnienia Exchange Login i Email Address tego użytkownika w Sophos Fusion. W zatwierdzonym pilotażu osobno sprawdzić przypisanie użytkownika, wartości po zastąpieniu symboli zastępczych, wykrywanie hosta i rzeczywiste logowanie. Nie przenosić automatycznie tego opisu urządzeń iOS na zasady użytkowników iOS ani innych klientów.

Sprawdzić pozostałe ustawienia konta według typu zasady

Sama zmiana hosta nie zastępuje pełnej weryfikacji Email account. Przed przypisaniem porównać dla każdego typu zasady dotychczasową nazwę wyświetlaną konta, przypisanie użytkownika, logowanie, zakres synchronizacji, udostępnianie danych i ewentualne certyfikaty. W zasadach urządzeń iOS Synchronization period ogranicza wiadomości synchronizowane lokalnie. Allow move, Allow recent address syncing i Use in Mail only wymagają osobnych decyzji dotyczących korzystania z innych kont, synchronizacji adresów z iCloud i aplikacji wysyłających pocztę. Identity certificate oraz podpisywanie i szyfrowanie S/MIME wymagają odpowiednich certyfikatów w zasadzie; nie wynikają ze zmiany serwera. Świadomie ustalić synchronizację poczty, kalendarza i kontaktów oraz dozwolone zmiany wprowadzane przez użytkownika, zamiast bez sprawdzenia przejmować je ze starego profilu.

W osobnych zadaniach platformowych zasada urządzeń iPhone/iPad opisuje tryb zarządzania, konta i działanie zasady. Zasada firmowych urządzeń Android Enterprise dotyczy wyłącznie Full Device z Gmail, w tym starej konfiguracji Gmail, przypisania użytkownika i wymogu Chrome dla OAuth; nie jest instrukcją dla Work Profile ani starszych zasad Androida. Dla macOS user policy zasada macOS wyjaśnia konto EWS i wykrywanie jego hosta przy OAuth, a nie EAS. W przypadku Windows najpierw ustalić ograniczenia kont i klientów; nie wynika z nich obsługiwany sposób wdrożenia aktualnego klienta pocztowego. Dla profili służbowych Androida, starszych zasad Androida i zasad użytkowników iOS osobno porównać faktycznie dostępne pola konta oraz wymagania klienta. Dopóki ich działanie nie zostanie potwierdzone, nie przypisywać wartości z innej rodziny zasad jako sprawdzonej konfiguracji.

Osobno zaplanować pakiety zadań i przyszłe rejestracje

W przykładzie zastąpienia zasady Sophos wskazuje pakiet zadań z Assign policy dla nowej zasady; Uninstall policy dla starej zasady wymienia tylko w przypadku zasad urządzeń Android i iOS, a Unassign iOS user policy tylko w przypadku zasad użytkowników iOS. Istniejące urządzenia i przyszłe rejestracje samoobsługowe to odrębne ścieżki: pakiet zadań wysłany na istniejące urządzenia nie zastępuje automatycznie pakietu zadań rejestracji w konfiguracji Self Service Portal. Jeśli używane są takie konfiguracje, należy zastąpić w nich odpowiednie pakiety rejestracyjne pakietami przypisującymi nową zasadę; przed kolejnymi rejestracjami sprawdzić każdą konfigurację objętą zmianą i przypisane do niej pakiety. Łączony pakiet zadań jest udokumentowanym przykładem, a nie zatwierdzoną kolejnością działań przy zastępowaniu zasady w środowisku produkcyjnym. Wykonanie pakietu lub pomyślny status zadania nie dowodzi ani udanego logowania, ani przepływu poczty, ani tego, że usunięcie starego profilu nie spowoduje szkód.

Kontrola dostępu EAS nie jest ścieżką poczty

Jeżeli dotychczasowe środowisko używa EAS proxy Sophos Mobile do kontroli dostępu, Sophos rozróżnia dla Exchange Online dwa tryby: zgodnie z jego dokumentacją Proxy mode obsługuje Exchange Server, ale nie Exchange Online. W trybie PowerShell mode urządzenia łączą się bezpośrednio z Exchange, a usługa Sophos steruje decyzjami o dostępie przez interfejs administracyjny Exchange. Aplikacja pocztowa nadal potrzebuje własnej, działającej ścieżki logowania i przesyłania danych. Według Sophos kontrola dostępu ActiveSync oparta na PowerShell nie jest dostępna dla komputerów Mac.

Sposób uwierzytelniania usługi Sophos wymaga dodatkowego wyjaśnienia: opis Sophos ze stycznia 2026 r. wspomina o próbie użycia Basic Authentication po nieudanym nowoczesnym logowaniu. Microsoft nie pozwala ponownie włączyć Basic Authentication dla EAS ani Remote PowerShell w Exchange Online. Opisany mechanizm awaryjny nie jest więc sposobem przywrócenia działania. Sophos osobno opisuje Basic dla połączenia administracyjnego swojej usługi w trybie PowerShell z lokalnym Exchange Server; nie dotyczy to logowania klientów EAS ani Exchange Online i nie upoważnia do włączenia Basic bez akceptacji bezpieczeństwa. Ponadto instrukcja konfiguracji Sophos z września 2026 r. podaje adres URI połączenia /powershell-liveid. Microsoft podaje ten URI również jako wartość domyślną w aktualnej dokumentacji modułu Connect-ExchangeOnline, opisującej nowoczesne połączenia REST bez WinRM Basic. Sam URI nie dowodzi ani użycia przestarzałego transportu, ani zgodności konkretnej wersji Sophos; jej moduł, uwierzytelnianie i rzeczywiste zachowanie połączenia pozostają niesprawdzone. Instrukcja Sophos dotycząca PowerShell z września 2026 r. nadal wymienia Exchange Server 2016 i 2019 jako obsługiwane wersje; plan zakończenia wsparcia Microsoftu podaje dla obu datę 14 października 2025 r. Osobno tabele cyklu życia Microsoftu dla Exchange Server 2016 i Exchange Server 2019 podają dla każdego z tych produktów 15 października 2025 r. o godz. 06:59:59 czasu pacyficznego jako koniec wsparcia rozszerzonego. Te źródła pierwotne różnią się datą kalendarzową i żadne nie wyjaśnia rozbieżności. Nie należy wnioskować, że chodzi o ten sam moment ani o dodatkowy dzień wsparcia. Lista zgodności Sophos nie oznacza więc, że te wersje serwera nadal są objęte wsparciem Microsoftu. Przed uruchomieniem kontroli dostępu trzeba wyjaśnić z Sophos i właściwym zespołem Exchange, czy dana wersja proxy, moduł i punkt końcowy chmury są obsługiwane, zweryfikować konto usługi, jego uprawnienia i rzeczywiste połączenie OAuth/REST oraz ustalić status wsparcia dotychczasowego środowiska serwerowego. Nie należy wywodzić stąd ogólnego przyzwolenia na Basic, WinRM Basic ani wyłączenie weryfikacji certyfikatów.

Konfiguracja PowerShell jako osobne zadanie warunkowe

Ta ścieżka jest potrzebna tylko wtedy, gdy kontrola dostępu EAS ma być faktycznie używana. Decyzja o architekturze EAS obejmuje protokół klienta, tożsamość urządzenia i kwarantannę; weryfikacja przed instalacją obejmuje host, wersję oprogramowania, konto usługi i zaufanie do certyfikatów. Oba artykuły służą do wstępnej weryfikacji, nie są zatwierdzonymi instrukcjami wykonawczymi konfiguracji. Na potrzeby planowania migracji konfigurację można podzielić na trzy odrębne części:

Środowisko administracyjne i konto usługi: Uzyskać potwierdzenie właściwego środowiska PowerShell i modułów na planowanym hoście oraz osobnego konta administracyjnego Exchange z wymaganymi uprawnieniami i zgodnością z wymaganiami logowania tenanta. Wymagania dla Exchange Server i Exchange Online nie są zamienne. Polecenia włączające Basic w lokalnym katalogu Exchange PowerShell nie należą do zmiany dotyczącej Exchange Online. Zmiany zasad wykonywania skryptów PowerShell również wymagają osobnego zatwierdzenia jako ingerencja w host.
Instancja i połączenie: Kreator konfiguracji na ekranie EAS Proxy instance setup opisuje Instance type > PowerShell Exchange/Office 365, dowolnie wybraną nazwę Instance name, cel w Exchange server oraz Service account wraz z Password. Są to pola do przygotowania, a nie wartości już potwierdzone dla używanej wersji oprogramowania. Dla chmury globalnej przykład podaje outlook.office365.com; kreator sam dodaje protokół i ścieżkę. Nie wpisywać bez sprawdzenia pełnego URI w pole hosta ani nie uznawać dodanej ścieżki za potwierdzenie aktualnej obsługi transportu. Allow all certificates wyłącza weryfikację certyfikatu serwera i w tym planie pozostaje wyłączone; błąd zaufania rozwiązać osobno. Obsługiwane logowanie administracyjne trzeba potwierdzić niezależnie od ścieżki poczty urządzenia.
Zaufanie między instancją a Sophos Mobile: Certyfikat wygenerowany podczas konfiguracji każdej instancji PowerShell musi być przyporządkowany właściwej instancji. Udokumentowana ścieżka przesyłania to My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file, a następnie Save. Nie jest to certyfikat TLS serwera ani certyfikat klienta w profilu pocztowym. Opisany później restart usługi Windows EASProxy powoduje przerwę w działaniu i może być wykonany wyłącznie w ramach osobno zatwierdzonej zmiany ze sprawdzeniem uruchomienia i możliwości powrotu; na tym etapie nie przesyłać certyfikatu ani nie uruchamiać restartu.

Bez potwierdzenia wersji oprogramowania, logowania, przyporządkowania certyfikatów i możliwości powrotu należy poprzestać na przygotowaniach. Wpisane konto, przesłany certyfikat lub dostępna usługa nie dowodzą ani egzekwowania decyzji o dostępie, ani skutecznego wysyłania i odbierania poczty. Dopiero po odrębnym zatwierdzeniu zweryfikować te trzy ścieżki osobno; nie używać masowej kwarantanny Exchange jako testu konfiguracji.

Co ustalić przed decyzją o zmianie produkcyjnej

Grupy objęte zmianą: osobno zebrać informacje o własności urządzeń i sposobie zarządzania nimi, dotychczasowej i planowanej zasadzie, urządzeniu i systemie operacyjnym, aplikacji pocztowej, rodzaju konta oraz używanym uwierzytelnianiu. Nie wnioskować o zgodności OAuth klientów Windows i starszych klientów Androida z listy migracyjnej Sophos.
Tenant i uprawnienia: sprawdzić chmurę Microsoft, punkt końcowy, plan Exchange Online i skrzynki użytkowników; konto usługi kontroli dostępu korzysta z innej ścieżki logowania niż konto pocztowe użytkownika. Wymagane uprawnienia oraz zasady MFA i dostępu warunkowego (Conditional Access) sprawdzić z zespołem Exchange, zamiast zakładać potrzebę szerokich uprawnień administratora lub możliwość powrotu do Basic.
Bezpieczna weryfikacja: najpierw, bez przypisywania ani odinstalowywania zasad, na zatwierdzonym urządzeniu pilotażowym z testową skrzynką zapisać urządzenie docelowe, dotychczasowe przypisanie, stan synchronizacji, aplikację pocztową, stan skrzynki i istniejące dane pocztowe. Przed każdą zmianą pilotażową uzgodnić z zespołem Exchange obsługiwaną metodę logowania, możliwe skutki dla profili i danych, możliwą do sprawdzenia kopię zapasową danych objętych zmianą oraz kryteria przerwania i powrotu; jeśli skutki lub sposób powrotu są nieznane, na tym etapie przerwać. Dopiero potem zaplanować osobno zatwierdzoną zmianę zasady ograniczoną do grupy pilotażowej i obserwować, czy nowe ustawienia konta zostały zastosowane, czy logowanie faktycznie działa, czy można wysyłać i odbierać wiadomości oraz – jeśli jest używana – czy zapada zamierzona decyzja kontroli dostępu EAS. Dopiero po tej weryfikacji decydować o szerokim wdrożeniu lub usunięciu starej zasady. Nie zakładać, że stare i nowe profile mogą istnieć równocześnie ani że Uninstall policy jest odwracalne; nie uruchamiać odinstalowania jedynie jako wstępnej kontroli pilotażu. W razie rozbieżności najpierw zbadać klienta i logowanie, a osobno połączenie systemu kontroli dostępu; nie włączać masowego blokowania nieznanych urządzeń jako kroku diagnostycznego.
Powrót i zatwierdzenie: udokumentować stare i nowe zasady oraz pakiety zadań samoobsługi; przed zmianą ustalić okno serwisowe, kryteria przerwania, odpowiedzialność oraz możliwość odtworzenia rzeczywistego środowiska skrzynek i serwerów. Ponowne przypisanie starej zasady Sophos nie przywróci skrzynki, która została już przeniesiona, ani wyłączonego lokalnego serwera Exchange Server.

Dopóki te kwestie nie zostaną potwierdzone dla konkretnego środowiska, opis zasad pozostaje jedynie podstawą do planowania. Nie zaleca się tu przełączenia produkcyjnego ani zakładania, że powodzenie jest gwarantowane lub że zawsze można wrócić do poprzedniego stanu.