Sophos Mobile: migracja z administratora urządzenia Android na Android Enterprise

Ten artykuł pomaga ustalić ścieżkę migracji i niezbędne kontrole. Nie stanowi zgody na reset urządzeń produkcyjnych. Sophos określa tryb administratora urządzenia jako przestarzały: w Sophos Mobile jest dostępny tylko dla systemu Android 9 lub starszego; urządzeń z systemem Android 10 lub nowszym nie można w tym trybie rejestrować. Nie oznacza to, że każda funkcja Android Device Policy Manager została ogólnie wycofana, ani nie jest zaleceniem dalszego używania systemu Android 9. Nie rejestruj nowych urządzeń w starym trybie. Opis migracji poniżej zakłada, że środowisko Android Enterprise zostało już skonfigurowane.

Najpierw ustal właściciela i tryb docelowy

Przed każdą zmianą porównaj rzeczywisty tryb zarządzania, tożsamość urządzenia, własność, wersję Androida, przypisanie użytkownika, zasady, aplikacje, łączność oraz ostatnio znany stan urządzenia na urządzeniu i we właściwym tenancie Sophos.

Przygotuj ponowną rejestrację przed rozpoczęciem zmian

Wykonaj tę kontrolę, gdy stare urządzenie jest jeszcze zarządzane. Nie uruchamia ona resetu ani wyrejestrowania. W protokole migracji odnotuj poniższe informacje dla wybranego trybu docelowego:

W Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise sprawdź aktualny Android Enterprise mode, wyświetlane dane konta i stan ustawienia Use managed Google domain device enrollment. Korzystaj z istniejącej rejestracji organizacji; nie uruchamiaj ponownie Register account ani nie zastępuj powiązania z Google. Brakujące lub niejasne powiązanie wyjaśnij najpierw zgodnie z sekcją Powiązanie organizacji z Google.
Dla urządzenia firmowego przygotuj Android Enterprise device policy, a dla prywatnego — Android Enterprise work profile policy. Zapisz nazwę zasady docelowej i powiązanego pakietu zadań. Pakiet dla danego typu urządzenia musi zawierać co najmniej Enroll i Assign policy z dokładnie tą zasadą. Stara zasada administratora urządzenia nie jest zamiennikiem.
Jeśli korzystasz z Self Service Portal, w Setup > Self Service Portal otwórz konfigurację obowiązującą danego użytkownika. W ustawieniach platformy Android pole Enrollment package musi wskazywać przygotowany pakiet zadań. Sprawdź Owner, docelową Device group, priorytet grupy i pozostały limit urządzeń. Sprawdź istniejącą, odpowiednią konfigurację; nie twórz automatycznie nowej ani nie zmieniaj Default. Przygotowanie opisuje sekcja Przygotowanie zasady, pakietu i tożsamości użytkownika.
Sprawdź zatwierdzenie Sophos Mobile Control w Managed Google Play. Bez tego zatwierdzenia zarządzana aplikacja nie aktualizuje się automatycznie. Jeśli rejestracja urządzeń w domenie jest włączona, przewidziani użytkownicy muszą istnieć w zarządzanej domenie Google. Ta metoda rejestracji wymaga Mobile Control 9.8 lub nowszego; w przypadku profili służbowych muszą być dodatkowo zainstalowane wszystkie dostępne aktualizacje systemu operacyjnego i aplikacji. W zadaniu uruchomionym przez Sophos Mobile przypisany adres e-mail musi dokładnie odpowiadać loginowi Google.
Wybierz ścieżkę rejestracji dozwoloną w aktualnym trybie organizacji i wcześniej przygotuj z odpowiedzialnym zespołem IT przekazanie użytkownikowi instrukcji opisanych poniżej. W organizacji zarejestrowanej przed 9 kwietnia 2024 r. w trybie managed Google domain, bez włączonej rejestracji urządzeń w domenie, rejestracja przez administratora nie jest dostępna; przygotuj wtedy dozwoloną ścieżkę SSP. Nie włączaj tego ustawienia przy okazji migracji. Zmiany powiązania organizacji lub trybu rejestracji wymagają osobnej zgody.

Dla urządzenia firmowego z przypisanym użytkownikiem przewodnik Android Enterprise w części „Pilotaż administratora” opisuje obsługiwaną ścieżkę kreatora przez Devices > Add > Add device wizard, wybór użytkownika, Platform: Android i przygotowany pakiet rejestracji. Wykonaj te kroki dopiero po osobno zatwierdzonym przywróceniu ustawień fabrycznych, którego wykonanie potwierdzono na urządzeniu. Jeśli wymagany jest SSP, zastosuj opisany tam przebieg rejestracji przez SSP. Metody QR, zero-touch i bez użytkownika są alternatywami wymagającymi własnego przygotowania, a nie dodatkowymi obowiązkowymi krokami.

Dla urządzenia o potwierdzonej własności prywatnej przygotuj wcześniej dla użytkownika sekcję Konfiguracja profilu służbowego w przewodniku Android BYOD. Prowadzi ona przez Owner: Personal, pakiet profilu służbowego i konfigurację Mobile Control na urządzeniu. Tę nową rejestrację rozpocznij dopiero po potwierdzonym wyrejestrowaniu ze starego trybu i późniejszym usunięciu właściwego starego wpisu. Uwzględnij także kontrolę prywatności i zgody z sekcji „Przed rejestracją”; procedura BYOD nie dotyczy urządzeń firmowych z profilem służbowym.

Jeśli którykolwiek z tych warunków nie jest spełniony, zatrzymaj się przed rozpoczęciem którejkolwiek ścieżki migracji. Przed zmianami na urządzeniach produkcyjnych sprawdź wybraną ścieżkę na reprezentatywnym urządzeniu testowym, dla którego uzyskano zgodę na test. Przygotowane konta, zapisany pakiet ani widoczne opcje portalu nie dowodzą jeszcze pomyślnej rejestracji urządzenia. Po rejestracji sprawdź tryb zarządzania, przypisanie użytkownika, stan zadań i faktycznie obowiązującą zasadę w Sophos Mobile oraz na urządzeniu.

Udokumentowane ścieżki migracji

Nie mieszaj dwóch udokumentowanych ścieżek:

Firmowe, dotychczas w trybie administratora urządzenia → Android Enterprise: pełne zarządzanie urządzeniem. Polecenie Gerät anzeigen > Aktionen > Zurücksetzen przywraca urządzenie do ustawień fabrycznych; następnie zarejestruj je ponownie. Sophos wymienia kreator „Gerät hinzufügen”, Sophos Fusion Self Service Portal, rejestrację za pomocą kodu QR i zero-touch jako możliwe ścieżki. Wykonaj tę operację wyłącznie po uzyskaniu osobnej zgody.
Prywatne, dotychczas w trybie administratora urządzenia → Android Enterprise: zarządzanie profilem służbowym. Wybierz Gerät anzeigen > Aktionen > Deregistrieren, następnie Aktionen > Löschen; dopiero potem ponownie zarejestruj profil służbowy. Sophos wymienia kreator „Gerät hinzufügen” lub Sophos Fusion Self Service Portal. Ta operacja również wymaga osobnej zgody. Przywrócenie ustawień fabrycznych nie jest standardowym krokiem dla BYOD.

Nazwy pozycji menu pochodzą z niemieckojęzycznej pomocy Sophos z 22 września 2026 r.; w konsoli ustawionej na język angielski występują Show device > Actions > Wipe, Unenroll i Delete. Sprawdź wcześniej konkretne menu, uprawnienia oraz dostępne sposoby rejestracji w docelowym tenancie. Wipe w Sophos Fusion, Zurücksetzen w administracji Sophos Mobile oraz usunięcie istniejącego profilu służbowego nie są zamiennymi nazwami ani krokami migracji. Istniejące urządzenia firmowe z profilem służbowym oraz inne tryby wymagają osobnej decyzji; nie należy automatycznie przypisywać ich do jednej z tych dwóch kategorii.

Zatrzymaj się przed każdą operacją powodującą utratę danych

Urządzenie firmowe: Uzyskaj pisemną zgodę na przywrócenie ustawień fabrycznych dokładnie tego urządzenia; sprawdź dane lokalne, konta firmowe, aplikacje, uwierzytelnianie, użyteczną kopię zapasową i możliwość odtworzenia danych. Planowany reset usuwa niezabezpieczone dane lokalne. Muszą być dostępne działająca ścieżka ponownej rejestracji w Android Enterprise, dostęp do Wi-Fi lub sieci komórkowej, niezbędne dane uwierzytelniające i uprawnienia. Sprawdź zawczasu konta Google i blokady po resecie w odniesieniu do konkretnego urządzenia i sposobu resetowania. Sophos dokumentuje Factory Reset Protection dla w pełni zarządzanych urządzeń z Android Enterprise; nie wynika z tego, że ta sama konfiguracja FRP obejmowała już reset w starym trybie administratora urządzenia. Nie obiecuj obejścia FRP.
Urządzenie prywatne: Uzgodnij z użytkownikiem zgodę, rozdzielenie danych prywatnych i firmowych oraz skutki wyrejestrowania ze starego trybu. Wyrejestrowanie ze starego trybu wyłącza administratora urządzenia Sophos Mobile Control, usuwa dane dostępowe serwera i otrzymane dane oraz resetuje Sophos Intercept X for Mobile. Najpierw potwierdź wyrejestrowanie, dopiero potem usuń powiązany wpis; oczekujące zadanie ani zniknięcie wpisu z konsoli nie dowodzą, że zmiany zostały wykonane na urządzeniu. Późniejsze usunięcie nowo skonfigurowanego profilu służbowego oznacza utratę jego aplikacji i danych lokalnych, a nie możliwość przywrócenia starego profilu. Nie zapewniaj o zachowaniu danych prywatnych bez sprawdzenia urządzenia.
Urządzenie offline, o nieznanym stanie lub zablokowane: Nie oznaczaj zadania jako zakończonego i nie zlecaj na próbę kolejnego usunięcia lub resetu. Ustal z użytkownikiem i pomocą techniczną Sophos lub producenta faktyczny stan urządzenia, dostarczenie zadania i zatwierdzoną ścieżkę odzyskiwania. Zadanie w chmurze nie dowodzi jego wykonania.

Przed zmianami, jeśli stosowane są Restrictions, zapisz rzeczywisty stan szyfrowania urządzenia i karty SD oraz dozwoloną ścieżkę tworzenia kopii zapasowej i odtwarzania danych, której działanie zostało potwierdzone. Na niektórych starszych urządzeniach zlecone szyfrowanie karty SD mogło zostać przerwane; samo przypisanie nie potwierdza stanu szyfrowania. Według starego źródła wyłączenie Allow backup wyłącza kopie zapasowe Google, a nie wszystkie alternatywne metody tworzenia kopii. Blokady USB/MTP mogą uniemożliwić potrzebny transfer plików. Nie łagodź blokad na próbę. Allow factory reset dotyczy resetu wykonywanego przez użytkownika; nie wywodź z tego ani zgody na osobno zatwierdzone polecenie Wipe w konsoli, ani możliwości jego wykonania.

Stara zasada jako spis ustawień, a nie wzorzec dla Android Enterprise

Zasady urządzeń z Androidem dotyczą starego trybu administratora urządzenia. Android Enterprise full device i Android Enterprise work profile mają odrębne rodziny zasad. Przed zatwierdzeniem przygotuj udokumentowaną macierz źródło–cel dla wszystkich 14 starych podkonfiguracji; w każdym wierszu odnotuj tryb docelowy, obsługiwane nowe ustawienie lub wyraźny brak odpowiednika, system operacyjny/OEM/licencję, test, skutki i ścieżkę wycofania zmian:

Poniższe obszary kontroli uwzględnij w tej macierzy. Zapisuj istniejące wartości, a nie nowe konfiguracje administratora urządzenia. Brak odpowiednika pozostaw jako nierozstrzygniętą decyzję; podobne nazwy opcji docelowych nie dowodzą takiego samego działania.

Połączenia i certyfikaty

Dla każdej istniejącej konfiguracji APN zinwentaryzuj również te pola:

User-friendly name, dodatkową nazwę widoczną na urządzeniu; dwie pozycje Server oddzielnie jako serwer HTTP dla ruchu WWW i bramę WAP, a także Port serwera WWW.
User name i zależność od User password, wyłącznie przez odwołanie do tożsamości z ograniczonym dostępem i bezpieczne odwołanie do sekretu; MMSC (Multimedia Messaging Service Center), MMS proxy server i MMS proxy port oddzielnie dla ścieżki MMS.
Authentication type dla uwierzytelniania PPP, APN type dla typów połączeń danych, Bearer dla technologii dostępu radiowego oraz Protocol i Roaming protocol dla protokołów operatora w sieci macierzystej i w roamingu.

Wszystkie stare pola poza APN są opcjonalne; wyraźnie oznacz nieużywane pola jako nieskonfigurowane, zamiast wpisywać domyślone wartości. W APN type znak * lub puste pole oznacza wszystkie typy danych. Tylko jedna konfiguracja APN może używać Use as default APN. Te znaczenia wyjaśniają stary stan, a nie tworzenie nowego APN w starym trybie. Każdej używanej wartości przyporządkuj osobno sprawdzony, obsługiwany odpowiednik docelowy albo wyraźnie wskaż jego brak; osobno potwierdź akceptację operatora dla docelowej karty SIM/abonamentu. Niezależne połączenie do odzyskiwania pozostaje konieczne.

Dla APN zapisz dotychczasowy punkt dostępu, operatora oraz używaną kartę SIM lub abonament. Ustal z operatorem, czy akceptuje ten APN dla przewidzianego abonamentu. Zapisz i porównaj także istniejące Mobile Country Code (MCC) i Mobile Network Code (MNC): wartości te ograniczają użycie starego APN do wskazanego operatora. Błędne ustawienie Use as default APN może odciąć transmisję danych komórkowych. Dlatego przed zmianami zabezpiecz wartości operatora i niezależne połączenie; nie zmieniaj domyślnego APN na próbę.

Dla Wi-Fi i VPN zapisz stare certyfikaty Wi-Fi/EAP, SSID i typy VPN, a dostęp w konfiguracji docelowej sprawdź osobno; WEP nie jest bezpiecznym standardem docelowym. Przetestuj komunikację z systemem zarządzania także przez niezależne połączenie.

Dla każdej istniejącej konfiguracji Wi-Fi zapisz w macierzy następujące stare wartości:

SSID i rzeczywisty Security type: None, WEP, WPA/WPA2 PSK, EAP/PEAP, EAP/TLS lub EAP/TTLS. None i WEP nie są zaleceniami dla konfiguracji docelowej. Stary opis wyklucza przypisanie zasad z WEP do urządzeń z Androidem 12 lub nowszym; ten historyczny warunek nie umożliwia rejestracji w starym trybie zarządzania.
Phase 2 authorization tylko dla EAP/PEAP i EAP/TTLS: zapisz istniejący wybór None, PAP, CHAP, MSCHAP lub MSCHAPv2. Dla EAP/TLS nie dopisuj takiej starej wartości.
Przy EAP zapisz osobno powiązania Identity i Anonymous identity. Drugie pole to pseudonim wysyłany bez szyfrowania w fazie 1 negocjacji EAP. Dla Password udokumentuj istniejącą zależność od hasła Wi-Fi oraz bezpieczny sposób jego przechowywania lub udostępnienia hasła zastępczego, a nie samo hasło.
Zapisz oddzielnie Proxy host, czyli nazwę lub adres IP serwera proxy dla tego połączenia Wi-Fi, oraz Proxy port. Global HTTP proxy nie jest potwierdzonym równoważnym odpowiednikiem tego serwera proxy przypisanego do połączenia.

Dla każdej istniejącej konfiguracji VPN zapisz Connection name (nazwę widoczną na urządzeniu), Server (nazwę hosta lub adres IP bramy) oraz rzeczywisty Connection type. Stary opis rozróżnia następujące zależności:

L2TP/IPsec (PSK): udokumentuj powiązanie z użytkownikiem w User i zależność od hasła w Password oddzielnie od uzgodnionego wcześniej klucza uwierzytelniania w polu L2TP/IPsec (PSK).
L2TP/IPsec (certificate): zapisz wybrane Client certificate i Root certificate, a dodatkowo User i zależność od Password. W tym wariancie starej konfiguracji wybór certyfikatów nie zastępuje zależności od użytkownika i hasła.
Cisco AnyConnect: zinwentaryzuj osobno istniejący plik XML profilu VPN i plik XML profilu NVM (Network Visibility Module), dla każdego podając osobę odpowiedzialną, wersję i odwołanie do bezpiecznej lokalizacji; nieistniejący profil oznacz jako brakujący. Nie wywodź z tego automatycznego importu XML ani takiej samej widoczności sieci w konfiguracji docelowej.

Powiązania tożsamości zapisuj wyłącznie w protokole migracji z ograniczonym dostępem. Dla haseł, kluczy PSK i kluczy prywatnych zapisuj jedynie odwołania do bezpiecznych miejsc przechowywania lub sposobów udostępniania; nie umieszczaj sekretów ani rzeczywistych wrażliwych danych identyfikacyjnych w publicznej dokumentacji potwierdzającej wyniki. Każdej używanej starej wartości Wi-Fi i każdej zależności VPN przyporządkuj osobno sprawdzony odpowiednik docelowy albo wyraźnie udokumentuj jego brak. Dla VPN sprawdź w tym celu obsługę aplikacji, systemu operacyjnego, bramy i uwierzytelniania; nie zakładaj jej na podstawie starego typu połączenia. Znaczenie pól docelowych, role certyfikatów i konfigurację aplikacji VPN sprawdź w podlinkowanym artykule o łączności urządzeń z Androidem; nadal wymagane są również poniższe kontrole certyfikatów.

Zapisz oddzielnie Client certificate, Root certificate i SCEP. Stare certyfikaty klienta i kotwice zaufania są powiązane z zasadami; SCEP wymaga certyfikatu CA serwera SCEP w konfiguracji certyfikatu głównego. Od nowa potwierdź docelową tożsamość, wydawanie i odnawianie certyfikatów, zaufanie do CA oraz logowanie do Wi-Fi/VPN; nigdy nie wyłączaj weryfikacji certyfikatów w celu usunięcia problemu.

W starej zasadzie urządzenia z Androidem certyfikat główny zapisany w Root certificate był instalowany na urządzeniu przy przypisaniu zasady. Dla istniejącej konfiguracji zapisz plik certyfikatu X.509 wraz z kodowaniem PEM lub DER. Każdy dodatkowy certyfikat główny wymagał osobnej konfiguracji Root certificate; dlatego wszystkie istniejące konfiguracje certyfikatów głównych uwzględnij oddzielnie w macierzy źródło–cel. Samo stare przypisanie nie potwierdza ani rzeczywistego stanu certyfikatów na konkretnym urządzeniu, ani automatycznego przeniesienia ich do Android Enterprise.

Dla każdej istniejącej konfiguracji Root certificate zapisz dodatkowo starą zasadę i inne konfiguracje tej samej zasady, które rzeczywiście korzystają z tego certyfikatu głównego, w tym zaufanie do serwera Wi-Fi/EAP, jeśli występuje. Oddziel zaufanie do serwera od tożsamości klienta i CA serwera SCEP. Przyporządkuj każdą zależność do wybranej zasady i trybu docelowego albo udokumentuj brak obsługiwanego odpowiednika. W zatwierdzonym pilotażu docelowym potwierdź oczekiwaną tożsamość serwera, zaufanie do CA oraz połączenie i uwierzytelnianie; nie zakładaj automatycznego przeniesienia.

Wyłącznie do interpretacji starych pól SCEP: URL mogło być powiązane przez %_SCEPPROXYURL_% z adresem URL serwera na karcie SCEP strony Sophos setup; Challenge mogło przez %_CACHALLENGE_% wskazywać skonfigurowany tam adres URL challenge. Po zastąpieniu symboli zastępczych rzeczywistymi danymi Subject musi być prawidłową nazwą X.500. Stare opcje SAN oznaczają: RFC 822 name = prawidłowy adres e-mail; DNS name = nazwa DNS serwera CA; Uniform resource identifier = w pełni kwalifikowany adres URL serwera CA. Zapisz pola skonfigurowane i nieskonfigurowane oraz faktycznie rozwiniętą tożsamość w spisie z ograniczonym dostępem; dla sekretów używaj wyłącznie bezpiecznych odwołań do przechowywania lub udostępniania. Nie jest to instrukcja ponownego konfigurowania starego trybu ani ponownego używania sekretów challenge. Nie wyprowadzaj z tego znaczeń SAN w konfiguracji docelowej ani nie kopiuj tych starych znaczeń odnoszących się do CA do nowej tożsamości klienta.

Dla każdej istniejącej konfiguracji SCEP zapisz z odpowiedzialnym zespołem PKI/MDM poniższe zależności, nie zmieniając starych wpisów w celu ich ustalenia:

Pobieranie certyfikatu: Udokumentuj punkty końcowe serwera i challenge wraz z zależnościami oraz, jeśli dotyczy, powiązanie zmiennych rozwijanych na podstawie ustawień. Nie zapisuj haseł challenge ani innych sekretów w protokole lub artykule.
Tożsamość i wybór: Zapisz stary alias lub odwołanie służące do wyboru certyfikatu, powiązanie z użytkownikiem lub urządzeniem, wyrażenie Subject i rozwiniętą nazwę, a także skonfigurowane typy i wartości SAN oraz AD-UPN. Wyraźnie oznacz pola, które nie były skonfigurowane. W pilotażu porównaj te dane z tożsamością wymaganą przez usługę i faktycznym wyborem certyfikatu docelowego; pozostaw nieobsługiwane przyporządkowania jako nierozstrzygnięte.
Powiązanie zaufania: Jednoznacznie wskaż faktycznie wybrany certyfikat główny z aktualnej starej zasady, w razie potrzeby podając jego odcisk. Zaufanie do serwera SCEP sprawdź oddzielnie od zaufania do wydanego certyfikatu klienta i do serwera usługi. Nie usuwaj nadal potrzebnej kotwicy zaufania, zanim działanie konfiguracji docelowej nie zostanie potwierdzone.
Klucz i przeznaczenie: Zapisz istniejącą wartość Key size, wymagania zgodności CA oraz oddzielne ustawienia i przeznaczenia dotyczące podpisu cyfrowego i szyfrowania. Ustal wymagania docelowe z zespołem PKI i zespołem odpowiedzialnym za usługę korzystającą z certyfikatu; w pilotażu sprawdź wydany certyfikat i jego wymagane zastosowanie. Nie włączaj obu przeznaczeń bez rozróżnienia ani nie przenoś automatycznie starej wartości rozmiaru klucza.

Obsługiwaną docelową ścieżkę pobierania, role certyfikatów i ich przeznaczenia sprawdź niezależnie na podstawie artykułu o łączności urządzeń z Androidem i podlinkowanej w nim instrukcji dotyczącej certyfikatów i SCEP. Te instrukcje docelowe nie zastępują ani spisu istniejącej konfiguracji, ani potwierdzenia rzeczywistego działania w trybie docelowym.

Jednoznacznie zidentyfikuj także istniejący Client certificate przez bezpieczne odwołanie do rzeczywistego pliku PKCS #12 (.pfx) i odczytanej z niego wartości Certificate name. W spisie certyfikatów zapisz, które konfiguracje tej samej starej zasady go wybierają. Inne stare zasady wymagały osobnego przesłania pliku; jest to stara zależność, a nie polecenie ponownego przygotowania starego trybu. Nie publikuj ani nie eksportuj klucza prywatnego i nie zakładaj automatycznego przeniesienia do konfiguracji docelowej.

Aplikacje, uprawnienia i hasło aplikacji

Filtr aplikacji w Restrictions: Zapisz wartość Filter type oddzielnie od App Control: Allowed apps lub Forbidden apps, powiązaną grupę aplikacji i jej członków oraz aplikacje, na które filtr rzeczywiście działa. Według starego źródła aplikacje zainstalowane przez Sophos Mobile są wyłączone z tego filtra; blokada uruchamiania w App Control nie jest więc potwierdzonym odpowiednikiem. Według tego samego źródła blokada przeglądarki systemowej nie obejmuje przeglądarek innych producentów. Dla wymaganej ochrony aplikacji i przeglądarek osobno potwierdź zakres i rzeczywiste działanie w konfiguracji docelowej.
App Control: Udokumentuj wybraną starą grupę aplikacji i jej członków. Blokada ta uniemożliwia uruchamianie, również aplikacji producenta, których nie można odinstalować; nie usuwa aplikacji. Dla każdej zablokowanej aplikacji zapisz tryb docelowy i przypisanie do nowej grupy. Nie oznacza to automatycznego przeniesienia ze sklepu Play ani blokady aplikacji prywatnych w trybie docelowym.
App permissions: Dla każdej starej aplikacji zapisz jej dokładną tożsamość oraz każde skonfigurowane uprawnienie przyznawane w czasie działania wraz z wartością: Selectable pozwala użytkownikowi zmienić ustawienie, Granted przyznaje uprawnienie, a Denied go odmawia. Dla każdej pary aplikacja–uprawnienie określ tryb docelowy, aplikację docelową, oczekiwany efekt i dozwolone zmiany użytkownika albo wskaż brak odpowiednika. W profilu służbowym od Androida 12 można w imieniu użytkownika odmówić dostępu do lokalizacji, aparatu, mikrofonu, czujników ciała i aktywności fizycznej, ale nie można go przyznać. Uwzględnij to ograniczenie w decyzji dotyczącej konfiguracji docelowej.
App Protection: Zapisz starą grupę aplikacji i jej członków, Password complexity, Grace period in minutes oraz Allow fingerprint authentication. Wszystkie chronione aplikacje używają tego samego hasła; użytkownik ustala je przy pierwszym otwarciu jednej z nich. W ustawionym okresie po zamknięciu chronionej aplikacji można otwierać chronione aplikacje bez ponownego żądania hasła. Odcisk palca może zastąpić hasło aplikacji. Stary mechanizm ochrony można obejść przez inne aplikacje, funkcje systemowe lub tryb wielu okien; nie zapewnia więc równoważnej ochrony firmowej. Osobno porównaj obsługiwane ustawienia pełnego zarządzania urządzeniem i profilu służbowego.

Konto pocztowe i instrukcje dla użytkownika

Dla Email account osobno sprawdź aplikację pocztową, chmurę Exchange, obsługiwane logowanie przez OAuth i rzeczywisty przepływ poczty. Stare pole hasła lub Allow all certificates nie stanowi rozwiązania awaryjnego dla Exchange Online. Oprócz serwera, certyfikatów i przypisania użytkownika zapisz następujące stare wartości:

Nazwa konta, ścieżka, transport i treści

Zapisz Account name i rzeczywisty Server name; odróżnij bezpośredni punkt końcowy Exchange od adresu URL EAS proxy. outlook.office365.com dotyczy globalnej chmury Microsoft 365, a nie wszystkich innych chmur Microsoft. Obserwuj faktycznie zatwierdzoną ścieżkę poczty, nie zastępując jej bez sprawdzenia.
Zapisz rozwinięte wartości Email address i Sender niezależnie od User; %_EMAILADDRESS_% jest w obu polach zastępowane rzeczywistym adresem e-mail. Dane tożsamości pozostają w protokole z ograniczonym dostępem.
Dla Password zapisz jedynie bezpieczne odwołanie do przechowywania/udostępniania i istniejącą zależność: puste stare pole wymagało wpisania hasła przez użytkownika na urządzeniu. Nie jest to zalecenie awaryjnego użycia hasła zamiast obsługiwanego OAuth.
Zapisz istniejące stany SSL/TLS i Allow all certificates, wybrany Client certificate oraz Synchronize content types. Stara opcja omijania weryfikacji nie jest bezpiecznym ustawieniem docelowym. Każdemu używanemu polu poczty przyporządkuj obsługiwane działanie docelowe albo wyraźnie wskaż brak odpowiednika. W zatwierdzonym pilotażu sprawdź rzeczywistą tożsamość konta/nadawcy i serwera, zaufanie TLS oraz wybrane synchronizowane treści, używając nieszkodliwych danych; nie stosuj awaryjnego logowania hasłem ani obejścia weryfikacji certyfikatów.

Tożsamość w starym koncie i w konfiguracji docelowej

Najpierw zapisz starą wartość User i faktyczną nazwę logowania wynikającą z jej rozwinięcia. Aby używać symboli zastępczych %_USERNAME_% i %_EMAILADDRESS_%, pola Exchange Login i Email Address przypisanego użytkownika muszą być wypełnione w Sophos Fusion. Stare źródło podaje zwykle %_EMAILADDRESS_% dla Exchange Online i %_USERNAME_% dla Exchange Server. Mimo to adres e-mail i rzeczywisty login nie są automatycznie identyczne.

Zapisz także Domain. Według starego opisu pole pozostaje puste dla Exchange Online, a dla Exchange Server zawiera domenę konta użytkownika. Dane te wyjaśniają, jakiej tożsamości używało stare konto. Przed zatwierdzeniem porównaj rozwinięte stare wartości i przypisanie użytkownika z wybraną tożsamością docelową. Sprawdź przy tym, jak w konfiguracji docelowej przedstawiane są nazwa użytkownika i domena; obsługiwaną metodę logowania sprawdź osobno, zgodnie z opisem powyżej.

Konfiguracja na starym urządzeniu

Udokumentuj OEM/API oraz automatyczną lub ręczną konfigurację konta. Stary opis wymienia LG GATE, Samsung Knox i Sony Enterprise API dla konfiguracji automatycznej. Na innych urządzeniach użytkownik musiał skonfigurować aplikację pocztową na podstawie szczegółów konfiguracji w Sophos Mobile Control. Dla klienta docelowego przygotuj osobne instrukcje dla użytkownika i pilotaż aplikacji zamiast powtarzać starą konfigurację.

Synchronizacja i konto domyślne

Zapisz Synchronization interval jako odstęp między synchronizacjami, oddzielnie od Synchronization period, czyli wieku uwzględnianych wiadomości. Udokumentuj docelowy mechanizm określania częstotliwości pobierania lub brak odpowiednika. Zapisz także Default account i ustal, jak aplikacja docelowa wybiera konto domyślne albo czy brakuje zarządzanego ustawienia.

Przepływ danych, format i rozmiar wiadomości

Dla Allow forwarding emails i Allow use of HTML format zapisz istniejące wartości oraz wcześniejsze decyzje dotyczące potrzeb biznesowych i ochrony danych. Dla obu ustawień odnotuj, czy aplikacja docelowa lub Exchange może je wymusić. W przeciwnym razie wyraźnie wskaż brak odpowiednika.

Zapisz dosłowną wartość Maximum attachment size in MB. Mimo nazwy pola Sophos opisuje ją jako maksymalny rozmiar pojedynczej wiadomości e-mail, a nie wyraźnie samego załącznika. Osobno sprawdź, jaki efekt ma znaczenie dla pracy i jaki limit ustawia aplikacja docelowa lub Exchange.

Szczególny przypadek starszych urządzeń Sony

Niemieckie źródło podaje Enterprise API Level 6.x lub starszy, a angielskie Level 6 lub wcześniejszy. Na takich urządzeniach dane konta Exchange muszą odpowiadać przypisanemu użytkownikowi. Mobile Control nie może tam przekazać identyfikatora ActiveSync. Przy pierwszym kontakcie z EAS proxy szuka więc urządzenia z nieznanym identyfikatorem ActiveSync i pasującym przypisaniem użytkownika. Jeśli je znajdzie, wiąże identyfikator przesłany przez klienta pocztowego i przekazuje żądanie dalej; w przeciwnym razie je odrzuca. Przed zatwierdzeniem starego konta porównaj wersję API, przypisanego użytkownika i rzeczywistą tożsamość klienta. Obserwuj istniejącą zatwierdzoną ścieżkę poczty, nie resetując tożsamości ani nie obchodząc kontroli dostępu. Ścieżkę docelową potwierdź osobno; nie przenoś tego starego warunku na Gmail w Android Enterprise.

Kiosk i zatwierdzona możliwość wyjścia

Dla Kiosk mode zapisz istniejącą wartość Select source (Custom, App list lub No app), dokładny App ID, faktyczną instalację, stan przypisania i stan urządzenia. Dla App list udokumentuj wybrany wpis aplikacji Android, która została już dodana do Sophos Mobile. Przed przyporządkowaniem do konfiguracji docelowej porównaj wynikający z tego wpisu identyfikator pakietu z App ID i faktycznie zainstalowaną aplikacją. Jeśli przy przypisaniu starej zasady brakuje skonfigurowanej aplikacji kiosku, zadanie przypisania zasady pozostaje Incomplete / Unvollständig do czasu jej instalacji. Przy takim starym stanie najpierw porównaj tożsamość i instalację; reset nie jest sposobem rozwiązywania problemów na próbę. Natomiast No app oznacza, że ograniczenia są przekazywane, ale nie uruchamia się żadna aplikacja. Nie utożsamiaj tego z brakującym pakietem ani z opcją Enterprise o nazwie None.

Jeśli funkcje urządzenia nie zostały wyłączone, użytkownik może wyjść ze starej aplikacji kiosku i normalnie używać urządzenia; sam wybór aplikacji nie dowodzi zablokowania możliwości wyjścia. W szczególności udokumentuj istniejące stany Allow Home button i Allow task manager oraz zatwierdzony fizyczny lub alternatywny dostęp administratora. Przed resetem sprawdź aplikację kiosku, możliwość jej uruchomienia i wyjścia z niej, a dla trybu docelowego potwierdź je osobno.

Dla Sony Enterprise API Level 9 lub nowszego stare źródło podaje: jeśli wyłączona jest choć jedna z opcji Allow volume up, Allow volume down lub Allow volume mute, wszystkie przyciski głośności są wyłączone. Zapisz model, poziom API i stary stan. W zatwierdzonym pilotażu docelowym sprawdź, jakie sterowanie dźwiękiem i przyciskami jest obsługiwane dla tego modelu i wybranego trybu zarządzania. Przetestuj potrzebny dźwięk i przyciski na urządzeniu zamiast zakładać działanie takie jak wcześniej.

Knox Premium, ochrona uruchamiania i aplikacje administratora

Zapisz istniejącą wartość Allow firmware auto update options, osobę odpowiedzialną oraz obsługę przez urządzenie/licencję. Stara opcja powoduje automatyczne sprawdzanie dostępności aktualizacji firmware przez urządzenie; użytkownik nie może tego zmienić w ustawieniach urządzenia. Nie oznacza to automatycznej instalacji każdej aktualizacji. Osobno udokumentuj obsługiwany odpowiednik docelowy lub jego brak i obserwuj rzeczywiste działanie aktualizacji w zatwierdzonym pilotażu, bez ponownego włączania starych opcji.

Stare Knox Premium restrictions działają na urządzenie Samsung Knox, a nie na kontener Knox. Ich wymuszanie wymaga licencji Samsung Knox Premium zarejestrowanej w Sophos Mobile. Osobno sprawdź typ urządzenia, rejestrację licencji i rzeczywisty efekt na urządzeniu. Dla wybranego docelowego trybu Enterprise ustal oddzielnie, jaka licencja jest potrzebna i jakie działanie na urządzeniu jest obsługiwane; stara rejestracja licencji nie dowodzi jej przeniesienia.

Zapisz istniejący stan Enable ODE Trusted Boot verification. Według starego opisu partycja danych jest odszyfrowywana przy uruchomieniu tylko przy użyciu oficjalnego pliku binarnego i jądra. Ustal dostęp do danych i zatwierdzoną ścieżkę odzyskiwania przed ponownym uruchomieniem lub resetem; nie wyłączaj weryfikacji jako skrótu przy migracji lub odzyskiwaniu.

Zapisz oddzielnie Prevent installation of another administrator app i Prevent activation of another administration app. Pierwsza stara opcja zapobiega instalacji aplikacji z uprawnieniami administratora urządzenia, z wyjątkiem aplikacji instalowanych przez Sophos Mobile; druga zapobiega aktywacji tych uprawnień. Wcześniej sprawdź rzeczywisty wpływ na wymagane aplikacje i przewidzianą ścieżkę rejestracji, nie łagodząc wszystkich blokad bez rozróżnienia.

Jeśli występuje Allow Common Criteria mode, zapisz dodatkowo wszystkie sześć starych warunków:

szyfrowanie urządzenia włączone;
szybkie szyfrowanie wyłączone;
szyfrowanie pamięci zewnętrznej włączone;
ustawiony próg nieudanych prób powodujący wymazanie urządzenia;
sprawdzanie unieważnienia certyfikatów włączone;
historia haseł wyłączona.

Bez tych warunków, według starego źródła, CC Mode nie jest stosowany. Są to zależności konfiguracji wyjściowej, a nie polecenie, by ponownie włączać stare opcje lub osłabiać ochronę hasłem w konfiguracji docelowej. Nie testuj wymazywania po nieudanych próbach na urządzeniach produkcyjnych. Aktualną obsługę, odpowiednik docelowy i odzyskiwanie sprawdź oddzielnie w zatwierdzonym pilotażu; stary opis nie jest dowodem aktualnej certyfikacji.

Blokada ekranu i ograniczenia

Dla istniejącej blokady ekranu w Password policies zapisz wartość Password type i jej znaczenie w starej zasadzie: Pattern, PIN or password wymaga blokady ekranu bez dodatkowych ograniczeń; Simple password wymaga hasła zawierającego co najmniej jedną literę, a cyfry są dozwolone; PIN or password dopuszcza te dwa typy blokady. Alphanumeric password i Complex password wymagają hasła z literami i cyframi. Tylko Complex password dodaje sześć wymienionych poniżej wartości minimalnych dotyczących składu hasła. Opisuje to zasadę wyjściową; nie jest instrukcją tworzenia nowej zasady dla starego trybu ani potwierdzeniem identycznego działania w Android Enterprise.

Dla Simple password, PIN or password, Alphanumeric password i Complex password zapisz dodatkowo istniejące wartości: Minimum password length (łączna liczba znaków), Maximum idle time before password prompt (ustawiony czas bezczynności; urządzenie może wymusić krótszy czas), Maximum password age in days (odstęp między zmianami hasła; stary zakres 0–730 dni, przy 0 zmiana nie jest wymagana), Maximum sign-in attempts (liczba nieudanych prób powodująca wymazanie urządzenia w starym trybie) oraz Password history (liczba zapamiętanych wcześniejszych haseł, których nie wolno użyć ponownie). Nie wymyślaj wartości dla pól niedostępnych przy wybranym typie. Przed zatwierdzeniem zapisz dla typu i każdego pola obsługiwane działanie docelowe lub jego wyraźny brak, system operacyjny/OEM oraz wybraną blokadę urządzenia lub profilu służbowego; nie przenoś starych wartości automatycznie.

W Password policies dla istniejącego Complex password zapisz oddzielnie sześć wartości minimalnych: litery, małe litery, wielkie litery, znaki niealfabetyczne, cyfry i znaki specjalne. Znaki niealfabetyczne i specjalne to odrębne stare wartości, a nie jedno połączone wymaganie. Porównaj każdą wartość z wybranym pełnym zarządzaniem urządzeniem, blokadą urządzenia lub profilu służbowego oraz oznaczeniami systemu operacyjnego i OEM. Dla każdego minimum udokumentuj obsługiwany odpowiednik lub jego brak oraz zaobserwowane bez ryzyka utraty danych wymuszanie.

Zapisz także Allow fingerprint authentication i Allow iris authentication wraz z obecnym wyborem. Stare metody odblokowania działają tylko na urządzeniach, które je obsługują. Osobno sprawdź dostępność i faktycznie dozwolone metody odblokowania w trybie docelowym według systemu operacyjnego i OEM. Odcisk palca w App Protection ani Weak biometric recognition nie dowodzą istnienia identycznego odpowiednika.

Dla Password policies i Restrictions sprawdź odzyskiwanie, kopię zapasową oraz wpływ systemu i trybu na każdą istotną blokadę i ograniczenie; nie zakładaj jednakowego działania na urządzeniach prywatnych i firmowych. Próg nieudanych prób może wymazać urządzenie; nie testuj tego na urządzeniach produkcyjnych.

Dla faktycznie używanych Restrictions wypełnij macierz aż do poziomu każdego istotnego ustawienia: stara wartość, działanie zaobserwowane na urządzeniu, biznesowy cel ochrony, system operacyjny/OEM i zależności między opcjami głównymi a podrzędnymi, obsługiwany odpowiednik docelowy albo wyraźnie wskazana i zatwierdzona różnica. Uwzględnij zwłaszcza przekazywanie i rejestrowanie danych, łączność bezprzewodową, udostępnianie i urządzenia peryferyjne, dostępność łączności, komunikację alarmową i roaming, aktualizacje i odzyskiwanie, konta — w tym usuwanie konta Google — oraz źródła instalacji aplikacji i odinstalowywanie. Uzasadnij pominięcie ustawień nieużywanych lub niemających zastosowania. Nie oceniaj blokad wyłącznie po nazwach: według starego źródła zakaz nagrywania wideo nadal dopuszcza zdjęcia i streaming; współdzielony schowek wymaga Allow clipboard. Jeśli używany jest Bluetooth, sprawdź również istniejące parowania i profile; przy tetheringu lub aparacie na ekranie blokady sprawdź także opcję główną. Istotne podrzędne ustawienia SD/USB również zapisz wraz z ich opcjami głównymi. Stara blokada Beam nie kontroluje Quick Share. W zatwierdzonym pilotażu docelowym potwierdź wymagane funkcje i blokowanie niedozwolonych przepływów danych przy użyciu nieszkodliwych danych testowych; przy braku odpowiednika lub innym działaniu zatrzymaj wdrożenie do czasu udokumentowania decyzji.

Historyczne podstrony opisują ustawienia źródłowe, częściowo z lat 2022–2023, a nie aktualną obsługę dawnych protokołów czy funkcji OEM na urządzeniach docelowych. Opisane obszary kontroli wskazują zależności, które trzeba wyjaśnić przed migracją. Przed sformułowaniem konkretnych zaleceń dotyczących zasad sprawdź obie pełne rodziny zasad docelowych oraz własny tenant. Osobne artykuły KB o zasadach dla w pełni zarządzanych urządzeń, zasadach profilu służbowego, łączności urządzeń z Androidem, BYOD i FRP nie zastępują zgody na migrację. Kwestie uwierzytelniania poczty omówiono także w artykule o migracji Exchange.

Pilotaż, warunki przerwania i odzyskiwanie

Dopiero po ustaleniu własności urządzeń, właściwego tenanta, licencji i zatwierdzonej ścieżki odzyskiwania wykonaj pilotaż na urządzeniach reprezentatywnych, które można wyłączyć z użytku, osobno dla każdego trybu. Wcześniej zabezpiecz dane urządzenia i dotychczasowe zasady oraz osobno przygotuj nową zasadę i metodę rejestracji. Podczas pilotażu potwierdź wykonanie zadania na urządzeniu, sprawdź nowy tryb zarządzania i faktyczne przypisanie oraz obserwuj aplikacje, logowanie do konta i przepływ poczty, kiosk (jeżeli jest używany), Wi-Fi/VPN, wydawanie i odnawianie certyfikatów oraz dane prywatne po zmianie trybu BYOD. O rozszerzeniu migracji na kolejne urządzenia decyduj dopiero po potwierdzeniu rzeczywistych skutków.

Dla zapisanych starych wartości odnotuj w pilotażu konkretne wyniki oczekiwane i rzeczywiste:

Sieć komórkowa

Sprawdź dostęp do danych komórkowych z przewidzianą kartą SIM u przewidzianego operatora, oddzielnie od wcześniej przetestowanego niezależnego połączenia do odzyskiwania i zarządzania. Następnie sprawdź komunikację z systemem zarządzania. Jeśli nie ma dostępu do danych, nie migruj kolejnych urządzeń; użyj wcześniej zatwierdzonego niezależnego połączenia i ścieżki eskalacji.

Aplikacje i uprawnienia

Najpierw sprawdź uruchamianie każdej dotychczas zablokowanej aplikacji oraz potrzebnych aplikacji roboczych i awaryjnych. Następnie z użyciem danych testowych sprawdź każdą aplikację docelową i jej uprawnienia przyznawane w czasie działania. Porównaj stan oczekiwany z rzeczywistym działaniem aplikacji przy przyznanym lub odmówionym uprawnieniu. Sprawdź także, czy użytkownik może zmienić uprawnienie zgodnie z założeniem, czy też zmiana jest blokowana. Uwzględnij przy tym ograniczenia Androida 12 w profilu służbowym.

Przed zmianą zapisz ustawienia i przypisanie. Używaj wyłącznie obsługiwanej, wcześniej przetestowanej ścieżki aktualizacji lub zastąpienia. Jeśli trzeba cofnąć zmianę zasad, potwierdź synchronizację i powtórz te same kontrole uprawnień.

Nie przyznawaj wszystkich uprawnień tylko po to, aby aplikacja działała. Późniejsze odebranie uprawnienia nie cofnie wcześniejszego ujawnienia danych.

Hasło aplikacji i blokada ekranu

W konfiguracji docelowej sprawdź oczekiwane żądanie hasła, dozwolone alternatywne sposoby dostępu, okres bez ponownego żądania oraz uwierzytelnianie. Przy blokadzie urządzenia lub profilu służbowego sprawdź bez ryzyka utraty danych poszczególne wymagania minimalne i dostępne metody biometryczne, nie dochodząc do progu nieudanych prób.

Dla wybranej blokady docelowej porównaj dozwolone typy blokady i łączną długość hasła z udokumentowaną decyzją. Obserwuj rzeczywisty czas bezczynności do żądania hasła, uwzględniając krótsze limity narzucane przez urządzenie. Sprawdź zmianę i ponowne użycie haseł, o ile są obsługiwane, na zatwierdzonym koncie lub urządzeniu testowym albo na podstawie obsługiwanych informacji o stanie; wyraźnie zapisz brak obsługi. Na urządzeniach produkcyjnych nie przyspieszaj zmian hasła, nie osłabiaj ochrony ani nie wykorzystuj limitu nieudanych prób. Zachowaj przygotowaną ścieżkę odzyskiwania, a przy rozbieżnościach zatrzymaj wdrożenie.

Poczta

Na zatwierdzonym koncie testowym sprawdź z użyciem nieszkodliwych treści czas dostarczenia, konto domyślne przy tworzeniu wiadomości, dozwolone i zabronione przekazywanie, zachowanie HTML oraz istotne rozmiary wiadomości. Nie używaj rzeczywistych poufnych danych. Porównaj wynik z udokumentowaną decyzją dotyczącą konfiguracji docelowej, również wtedy, gdy brakuje w niej wcześniej zarządzanego ustawienia.

Zatrzymaj się przy rozbieżnościach

Przy rozbieżności zatrzymaj wdrożenie. Sam widok konfiguracji docelowej nie wystarcza; najpierw ustal przyczynę, obsługiwany odpowiednik i bezpieczną ścieżkę wycofania zmian.

Jeśli urządzenie jest nieosiągalne, stan danych jest niejasny, wskazano niewłaściwe urządzenie lub tryb, logowanie się nie udaje albo wystąpiła blokada po resecie, zatrzymaj działania i eskaluj sprawę. Przed rozpoczęciem wyznacz odpowiednią pomoc techniczną, działające niezależne połączenie i ścieżkę ponownego przygotowania urządzenia. Wycofanie migracji nie cofa przywrócenia ustawień fabrycznych ani usunięcia profilu służbowego: odtworzenie jest możliwe wyłącznie z kopii zapasowych o potwierdzonej użyteczności i przez zatwierdzoną ponowną rejestrację; nie potwierdzono ani natychmiastowego dostarczenia zadań zdalnych, ani identycznego działania zasad. Bez testów w tenancie i na urządzeniu nie traktuj tego artykułu jako instrukcji migracji produkcyjnej ani gwarancji powodzenia.