Sophos Mobile: migrera från Android-enhetsadministratör till Android Enterprise

Den här artikeln hjälper till att välja migreringsväg och fastställa vilka kontroller som behövs. Den ger inget godkännande för fabriksåterställning i produktion. Sophos betecknar enhetsadministratör som ett föråldrat hanteringsläge: I Sophos Mobile är det endast tillgängligt för Android 9 eller äldre; Android 10 och senare kan inte registreras i detta läge. Det innebär inte att alla Android Device Policy Manager-funktioner generellt har avskaffats, och är inte en rekommendation att fortsätta använda Android 9. Registrera inte nya enheter i det gamla läget. Migreringen som beskrivs nedan förutsätter en Android Enterprise-miljö som redan har konfigurerats.

Fastställ först ägande och målläge

Före varje ändring ska det faktiska hanteringsläget, enhetsidentitet, ägande, Android-version, användartilldelning, policyer, appar, nåbarhet och senaste enhetsstatus stämmas av på enheten och i rätt Sophos-klientorganisation.

Förbered nyregistreringen före åtgärden

Denna kontroll görs medan den gamla enheten fortfarande hanteras. Den utlöser varken återställning eller avregistrering. Dokumentera följande uppgifter för det valda målläget i migreringsprotokollet:

Under Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise, kontrollera befintligt Android Enterprise mode, de kontouppgifter som visas och status för Use managed Google domain device enrollment. Fortsätt använda en befintlig organisationsregistrering; kör inte Register account igen och ersätt inte kopplingen till Google. Om kopplingen saknas eller är oklar, red ut detta först enligt avsnittet Anslut organisationen till Google.
Ha en Android Enterprise device policy redo för företagsenheten och en Android Enterprise work profile policy för den privata enheten. Anteckna namnet på målpolicyn och det tillhörande uppgiftspaketet. Paketet för respektive enhetstyp måste innehålla åtminstone Enroll och Assign policy med exakt denna policy. En gammal enhetsadministratörspolicy är ingen ersättning.
Om Self Service Portal används, öppna den konfiguration som gäller för användaren under Setup > Self Service Portal. I plattformsinställningarna för Android måste Enrollment package peka på det förberedda uppgiftspaketet. Stäm av Owner, målgruppen i Device group, gruppprioritet och återstående enhetskvot. Kontrollera en befintlig lämplig konfiguration; skapa inte rutinmässigt en ny och ändra inte Default. Förberedelserna beskrivs i Förbered policy, paket och användaridentitet.
Kontrollera att Sophos Mobile Control är godkänd i Managed Google Play. Utan detta godkännande uppdateras den hanterade appen inte automatiskt. Om enhetsregistrering via domänen är aktiverad måste de avsedda användarna finnas i den hanterade Google-domänen. För denna enhetsregistrering via domänen krävs Mobile Control 9.8 eller senare; för arbetsprofiler måste dessutom alla tillgängliga operativsystems- och appuppdateringar vara installerade. För en uppgift som startas av Sophos Mobile måste den tilldelade e-postadressen exakt motsvara Google-inloggningen.
Välj en registreringsväg som är tillåten i organisationens befintliga läge och förbered i förväg följande överlämning till användaren tillsammans med ansvarig IT. För en organisation som registrerades före 9 april 2024 i managed-Google-domain-läge utan aktiverad enhetsregistrering via domänen är administratörsregistrering inte tillgänglig; förbered då den tillåtna SSP-vägen. Aktivera inte omkopplaren slentrianmässigt som ett migreringssteg. Ändringar av organisationskopplingen eller registreringsläget kräver ett separat godkännande.

För en företagsägd enhet med tilldelad användare beskriver Android Enterprise-guiden under ”Administratörspilot” den stödda registreringsvägen via Devices > Add > Add device wizard, val av användare, Platform: Android och det förberedda registreringspaketet. Använd denna väg först efter att fabriksåterställningen har godkänts separat och bekräftats på enheten. Om SSP krävs, använd SSP-flödet som beskrivs där. QR-, Zero-touch- och användarlösa metoder är alternativ med egna förberedelser, inte ytterligare obligatoriska steg.

För en enhet som bevisligen är privat ska avsnittet Konfigurera arbetsprofil i Android BYOD-guiden göras tillgängligt i förväg inför överlämningen till användaren. Det går igenom Owner: Personal, Work-Profile-paketet och konfigurationen av Mobile Control på enheten. Denna nyregistrering påbörjas först efter bekräftad avregistrering från det gamla läget och efterföljande borttagning av rätt gammal post. Kontrollen av dataskydd och samtycke under ”Före registrering” ingår också; BYOD-flödet gäller inte företagsägda enheter med arbetsprofil.

Om någon av dessa förutsättningar saknas, stoppa före båda migreringsgrenarna. Kontrollera den valda vägen på en godkänd representativ testenhet före en åtgärd i produktion. Förberedda konton, ett sparat paket eller synliga portalalternativ visar ännu inte att en enhet har registrerats framgångsrikt. Efter registreringen ska hanteringsläge, användartilldelning, uppgiftsstatus och gällande policy kontrolleras i Sophos Mobile och på enheten.

Dokumenterade migreringsgrenar

Blanda inte ihop de två dokumenterade vägarna:

Företagsägd, hittills enhetsadministratör → Android Enterprise: fullständig enhetshantering. Via Gerät anzeigen > Aktionen > Zurücksetzen återställs enheten till fabriksinställningarna; registrera den därefter på nytt. Sophos anger guiden ”Gerät hinzufügen”, Sophos Fusion Self Service Portal samt registrering med QR-kod och Zero Touch som möjliga vägar. Utför denna åtgärd endast efter separat godkännande.
Privat, hittills enhetsadministratör → Android Enterprise: arbetsprofilshantering. Välj Gerät anzeigen > Aktionen > Deregistrieren, därefter Aktionen > Löschen; registrera arbetsprofilen på nytt först efter detta. Sophos anger guiden ”Gerät hinzufügen” eller Sophos Fusion Self Service Portal. Även denna åtgärd kräver separat godkännande. Ingen fabriksåterställning som standardsteg för BYOD.

Dessa benämningar kommer från Sophos tyskspråkiga hjälp från 22 september 2026; i en engelskspråkig konsol används Show device > Actions > Wipe, Unenroll och Delete. Kontrollera i förväg de konkreta menyerna, behörigheterna och tillgängliga registreringsvägarna i målklientorganisationen. En Wipe i Sophos Fusion, en Zurücksetzen i Mobile Admin och borttagning av en redan konfigurerad arbetsprofil är inte utbytbara benämningar eller migreringssteg. Befintliga företagsägda enheter med arbetsprofil och enheter i andra lägen kräver ett separat beslut; denna tvådelning ska inte användas som automatisk klassificering.

Stanna upp före varje destruktiv åtgärd

Företagsägd enhet: Inhämta skriftligt godkännande för fabriksåterställning av just den här enheten; kontrollera lokala data, företagskonton, appar, autentisering, användbar säkerhetskopia och återställning. En genomförd fabriksåterställning förstör lokala data som inte har säkerhetskopierats. En fungerande väg för nyregistrering i Android Enterprise, åtkomst via Wi-Fi/mobilnät samt nödvändiga inloggningsuppgifter och behörigheter måste finnas. Kontrollera i förväg Google-konton och återställningsspärrar utifrån den specifika enheten och återställningsmetoden. Sophos dokumenterar Factory Reset Protection för fullständigt hanterade Android Enterprise-enheter; det innebär inte att samma FRP-konfiguration redan styrde återställning i det gamla enhetsadministratörsläget. Utlova inte att FRP kan kringgås.
Privat enhet: Klargör samtycke, vilka privata respektive verksamhetsrelaterade data som finns och hur den gamla avregistreringen påverkar dem tillsammans med användaren. Vid avregistrering från det gamla läget inaktiveras enhetsadministratören för Sophos Mobile Control, serverinloggningsuppgifter och mottagna data tas bort och Sophos Intercept X for Mobile återställs. Först bekräftad avregistrering, därefter borttagning av den tillhörande posten; ett väntande kommando eller en post som har försvunnit ur konsolen visar inte att ändringen har genomförts på enheten. Om en arbetsprofil som konfigureras senare tas bort går dess appar och lokala data förlorade; den gamla profilen kan inte återställas genom detta. Garantera inte att privata data finns kvar utan att kontrollera enheten.
Offline, okänt tillstånd eller låst enhet: Markera inte åtgärden som slutförd och utlös inte en andra borttagnings- eller återställningsåtgärd på chans. Klargör enhetens faktiska tillstånd, om kommandot har levererats och en godkänd återställningsväg med användaren och Sophos-/enhetssupporten. Ett molnkommando är inget bevis för att det har utförts.

Före åtgärden ska befintliga Restrictions granskas: dokumentera det faktiska krypteringstillståndet för enheten och SD-kortet samt en tillåten säkerhetskopierings- och återställningsväg som bevisligen fungerar. En begärd SD-kryptering kan ha avbrutits på vissa äldre enheter; tilldelningen bevisar inte tillståndet. Enligt den gamla källan stänger ett inaktiverat Allow backup av Google-säkerhetskopiering, inte alla alternativa säkerhetskopieringsmetoder. USB-/MTP-spärrar kan hindra den filöverföring som behövs. Lätta inte på spärrar på chans. Allow factory reset gäller användarens återställning; dra inga slutsatser om godkännande eller genomförbarhet för en separat godkänd Wipe från konsolen utifrån detta.

Använd den gamla policyn enbart som inventering, inte som mall för Android Enterprise

Android-enhetspolicyn gäller det gamla enhetsadministratörsläget. För Android Enterprise full device och Android Enterprise work profile gäller var sin egen policyfamilj. Upprätta före godkännande en dokumenterad käll-/målmatris för alla 14 gamla underkonfigurationer; ange för varje rad målläge, vilken ny inställning som stöds eller att ersättning uttryckligen saknas, OS/OEM/licens, test, konsekvenser och återställningsväg:

Följande kontrollområden ska ingå i matrisen. Dokumentera befintliga värden, inte nya konfigurationer för enhetsadministratörsläget. Om en ersättning saknas ska det framgå som ett öppet beslut; liknande namn på målalternativ bevisar inte samma effekt.

Anslutningar och certifikat

Inventera även följande fält för varje befintlig APN-konfiguration:

User-friendly name, det extra namnet som visas på enheten; de två Server-posterna separat som HTTP-server för webbtrafik och som WAP-gateway samt webbserverns Port.
User name och beroendet av User password, endast med en åtkomstskyddad identitetsreferens och en säker hänvisning till hemligheten; MMSC (Multimedia Messaging Service Center), MMS proxy server och MMS proxy port separat för MMS-vägen.
Authentication type för PPP-autentisering, APN type för typer av dataanslutning, Bearer för radioåtkomstteknik samt Protocol och Roaming protocol för operatörens protokoll i hemnätet respektive vid roaming.

Alla gamla fält utom APN är valfria; markera uttryckligen oanvända fält som inte konfigurerade i stället för att fylla i gissade värden. För APN type betyder * eller ett tomt fält alla datatyper. Endast en APN-konfiguration får använda Use as default APN. Dessa betydelser förklarar det gamla tillståndet, inte hur en ny APN i det gamla läget skapas. Koppla varje använt värde till en separat kontrollerad ersättning som stöds i målläget eller ange uttryckligen att sådan saknas; bekräfta separat operatörens godkännande för mållägets SIM-kort/abonnemang. Den oberoende återställningsanslutningen behövs fortfarande.

För APN, dokumentera den befintliga åtkomstpunkten, nätoperatören och det SIM-kort eller abonnemang som används. Stäm av med operatören om denna APN godtas för det avsedda abonnemanget. Dokumentera och kontrollera även befintliga Mobile Country Code (MCC) och Mobile Network Code (MNC): dessa värden begränsar användningen av den gamla APN-konfigurationen till den angivna operatören. En felaktig Use as default APN kan bryta mobildataanslutningen. Säkra därför operatörsvärden och en oberoende anslutning före åtgärden; ändra inte standard-APN på försök.

För Wi-Fi och VPN, dokumentera gamla Wi-Fi-/EAP-certifikat, SSID och VPN-typer och kontrollera målanslutningen separat; WEP är ingen säker målstandard. Testa även att enheten kan checka in till hanteringssystemet via en oberoende anslutning.

Ta med följande gamla värden i matrisen för varje befintlig Wi-Fi-konfiguration:

SSID och faktisk Security type: None, WEP, WPA/WPA2 PSK, EAP/PEAP, EAP/TLS eller EAP/TTLS. None och WEP är inga rekommendationer för målläget. Den gamla beskrivningen utesluter policytilldelning med WEP till Android 12 och senare; detta historiska villkor öppnar ingen registreringsväg i det gamla hanteringsläget.
Phase 2 authorization endast för EAP/PEAP och EAP/TTLS: dokumentera det befintliga valet None, PAP, CHAP, MSCHAP eller MSCHAPv2. Lägg inte till något sådant gammalt värde för EAP/TLS.
För EAP, dokumentera Identity och Anonymous identity separat. Det senare är den pseudonym som skickas okrypterad i fas 1 av EAP-förhandlingen. För Password, dokumentera beroendet av det befintliga Wi-Fi-lösenordet och hur det förvaras säkert eller hur ett ersättningslösenord tillhandahålls, inte själva lösenordet.
Dokumentera Proxy host som namn eller IP-adress för proxyn i denna Wi-Fi-anslutning och Proxy port separat. En Global HTTP proxy är ingen verifierad likvärdig ersättning för denna anslutningsspecifika proxy.

För varje befintlig VPN-konfiguration, dokumentera Connection name (namnet som visas på enheten), Server (gatewayens värdnamn eller IP-adress) och faktisk Connection type. Den gamla beskrivningen skiljer mellan följande beroenden:

L2TP/IPsec (PSK): Dokumentera användarkopplingen under User och lösenordsberoendet under Password separat från den i förväg överenskomna autentiseringsnyckeln i fältet L2TP/IPsec (PSK).
L2TP/IPsec (certificate): Ta med valt Client certificate och Root certificate samt även User och beroendet av Password. I denna gamla gren ersätter certifikatvalet inte beroendet av användare och lösenord.
Cisco AnyConnect: Inventera befintlig VPN-profil-XML och NVM-profil-XML (Network Visibility Module) separat, med ansvarig, version och hänvisning till säker lagringsplats för varje profil; markera en profil som saknas som saknad. Dra inga slutsatser om automatisk XML-import eller likvärdig nätverkssynlighet i målläget utifrån detta.

Dokumentera identitetskopplingar endast i det åtkomstskyddade migreringsprotokollet. För lösenord, PSK:er och privata nycklar ska endast hänvisningar till säker förvaring eller tillhandahållande tas med; ta varken med hemligheter eller känsliga verkliga identiteter i offentliga underlag. Koppla varje använt gammalt Wi-Fi-värde och varje VPN-beroende till en separat kontrollerad ersättning i målläget, eller dokumentera uttryckligen att den saknas. För VPN, kontrollera stöd i app, OS och gateway samt stöd för autentiseringen; dra inga slutsatser om detta utifrån den gamla anslutningstypen. Kontrollera målfältens betydelse, certifikatroller och VPN-appens konfiguration i den länkade artikeln Android-anslutningar; certifikatkontrollerna nedan behövs också.

Dokumentera Client certificate, Root certificate och SCEP var för sig. Gamla klientcertifikat och förtroendeankare är knutna till policyn; SCEP kräver SCEP-serverns CA som rotkonfiguration. Verifiera på nytt målidentitet, utfärdande/förnyelse, CA-tillit och inloggning för Wi-Fi/VPN; stäng aldrig av certifikatkontroll för att lösa problem.

I den gamla Android-enhetspolicyn installerades rotcertifikatet som angavs i Root certificate på enheten när policyn tilldelades. Dokumentera den befintliga X.509-certifikatfilen och dess PEM- eller DER-kodning i inventeringen av den äldre miljön. Varje ytterligare rotcertifikat krävde en egen Root certificate-konfiguration; ta därför med varje befintlig rotkonfiguration separat i käll-/målmatrisen. Den gamla tilldelningen ensam visar varken det faktiska certifikattillståndet på den aktuella enheten eller att certifikaten överförs automatiskt till Android Enterprise.

För varje befintlig Root certificate-konfiguration ska även den gamla policyn och de andra konfigurationerna i samma policy som faktiskt använder rotcertifikatet dokumenteras, inklusive servertillit för Wi-Fi/EAP om sådan finns. Håll servertillit åtskild från klientidentitet och SCEP-serverns CA. Koppla varje beroende till den valda målpolicyn och målläget, eller dokumentera att en ersättning som stöds saknas. Verifiera förväntad serveridentitet, CA-tillit och anslutning/autentisering i den godkända målpiloten; anta ingen automatisk överföring.

Endast för att tolka de gamla SCEP-fälten: URL kunde via %_SCEPPROXYURL_% vara kopplat till serverns URL på fliken SCEP på sidan Sophos setup; Challenge kunde via %_CACHALLENGE_% hänvisa till den challenge-URL som konfigurerats där. När platshållarna har ersatts med faktiska uppgifter måste Subject vara ett giltigt X.500-namn. De gamla SAN-alternativen betyder: RFC 822 name = en giltig e-postadress; DNS name = CA-serverns DNS-namn; Uniform resource identifier = CA-serverns fullständigt kvalificerade URL. Dokumentera konfigurerade och okonfigurerade fält samt den faktiskt upplösta identiteten i inventeringen med begränsad åtkomst; använd endast säkra förvarings-/provisioneringsreferenser för hemligheter. Detta är inte en instruktion att provisionera det gamla läget på nytt eller återanvända challenge-hemligheter. Härled inte SAN-betydelser i målläget från detta och kopiera inte dessa gamla CA-relaterade betydelser till en ny klientidentitet.

För varje befintlig SCEP-konfiguration ska följande beroenden dokumenteras tillsammans med ansvarig PKI-/MDM-funktion, utan att ändra gamla poster för att ta fram uppgifterna:

Hämtning: Dokumentera server- och challenge-slutpunkt med beroenden och eventuell variabelkoppling som har lösts via konfigurationen. Ta inte med challenge-lösenord eller andra hemligheter i protokollet eller artikeln.
Identitet och val: Dokumentera gammalt alias eller urvalsreferens, användar-/enhetskoppling, Subject-uttryck och det namn som det resulterar i, samt konfigurerade SAN-typer/-värden och AD-UPN. Markera uttryckligen fält som inte har konfigurerats som saknade. Jämför i piloten med den tjänsteidentitet som behövs och det faktiska certifikatvalet i målläget; lämna kopplingar som inte stöds som öppna frågor.
Tillitskoppling: Identifiera entydigt det rotcertifikat som faktiskt har valts i den aktuella gamla policyn, vid behov med fingeravtryck. Kontrollera tilliten till SCEP-servern separat från tilliten till det utfärdade klientcertifikatet och till tjänstens server. Ta inte bort ett förtroendeankare som fortfarande behövs innan målläget har verifierats och godkänts.
Nyckel och syfte: Dokumentera befintlig Key size, CA:ns kompatibilitetskrav och de separata valen/syftena för digital signatur och kryptering. Klargör målkraven med PKI-funktionen och tjänsten som använder certifikatet; kontrollera det utfärdade certifikatet och den användning som behövs i piloten. Aktivera inte rutinmässigt båda syftena och överför inte det gamla nyckelvärdet automatiskt.

Kontrollera oberoende vilken hämtningsväg som stöds i målläget samt certifikatroller och användningssyften med hjälp av Android-anslutningar och certifikat-/SCEP-runbooken som länkas där. Dessa målguider ersätter varken inventeringen eller verifieringen av den faktiska effekten i målläget.

Identifiera även befintligt Client certificate entydigt genom en säker hänvisning till den faktiska PKCS #12 (.pfx)-filen och det Certificate name som lästs ur filen. Dokumentera i certifikatinventeringen vilka konfigurationer i samma gamla policy som väljer certifikatet. Andra gamla policyer krävde separata uppladdningar; detta är ett gammalt beroende, inte en anvisning om ny konfigurering i det gamla läget. Publicera eller exportera ingen privat nyckel och anta ingen automatisk överföring till målläget.

Appar, behörigheter och applösenord

Appfilter i Restrictions: Dokumentera värdet för Filter type separat från App Control: Allowed apps eller Forbidden apps, tillhörande appgrupp och medlemmar samt vilka appar som faktiskt berörs. Enligt den gamla källan är appar som installerats av Sophos Mobile undantagna från filtret; startspärren i App Control är därför ingen verifierad ersättning. Enligt den gamla källan påverkar en spärr av den inbyggda webbläsaren inte heller tredjepartswebbläsare. Verifiera målomfattning och faktisk effekt separat för det app-/webbläsarskydd som behövs.
App Control: Dokumentera den valda gamla appgruppen och dess medlemmar. Spärren förhindrar att appar startas, även tillverkarappar som inte kan avinstalleras; den tar inte bort apparna. Ange målläge och ny grupptilldelning för varje spärrad app. Det innebär varken automatisk överföring från Play Store eller att privata appar spärras i målläget.
App permissions: Anteckna varje gammal apps exakta identitet och varje konfigurerad körningsbehörighet med dess värde: Selectable innebär att användaren kan ändra den, Granted beviljar den och Denied nekar den. Koppla varje app och behörighet till målläge, målapp, önskad effekt och tillåtna användarändringar, eller ange att ersättning saknas. I arbetsprofiler från Android 12 kan plats, kamera, mikrofon, kroppssensorer och fysisk aktivitet nekas på användarens vägnar men inte beviljas. Denna gräns måste beaktas i beslutet om målläget.
App Protection: Dokumentera den gamla appgruppen och dess medlemmar, Password complexity, Grace period in minutes och Allow fingerprint authentication. Alla skyddade appar använder samma lösenord; användaren väljer det när en av apparna öppnas första gången. Under den inställda respittiden efter att en skyddad app stängts kan skyddade appar öppnas utan en ny lösenordsfråga. Fingeravtryck är ett möjligt alternativ till applösenordet. Det gamla skyddet kan kringgås via andra appar/systemfunktioner eller flera fönster; det innebär inte likvärdigt företagsskydd. Jämför inställningarna som stöds för fullständig enhetshantering respektive arbetsprofil separat.

E-postkonto och överlämning till användaren

För Email account, kontrollera e-postapp, Exchange-molntjänst, inloggning med OAuth som stöds och faktiskt e-postflöde separat. Ett gammalt lösenordsfält eller Allow all certificates är ingen reservlösning för Exchange Online. Utöver server, certifikat och användartilldelning ska följande gamla värden ingå i protokollet:

Kontonamn, väg, transport och innehåll

Dokumentera Account name och faktiskt Server name; skilj en direkt Exchange-slutpunkt från URL:en till en EAS proxy. outlook.office365.com gäller det globala Microsoft 365-molnet, inte alla andra Microsoft-moln. Observera den faktiskt godkända e-postvägen utan att ersätta den utan kontroll.
Dokumentera de upplösta värdena för Email address och Sender oberoende av User; %_EMAILADDRESS_% ersätts med den faktiska e-postadressen i båda fälten. Identitetsuppgifterna stannar i det åtkomstskyddade protokollet.
För Password, dokumentera endast hänvisningen till säker förvaring/tillhandahållande och det befintliga beroendet: ett tomt gammalt fält krävde att användaren skrev in lösenordet på enheten. Det är ingen rekommendation om lösenord som reservlösning i stället för OAuth som stöds.
Dokumentera befintliga tillstånd för SSL/TLS och Allow all certificates, valt Client certificate och Synchronize content types. Det gamla kringgåendealternativet är inget säkert målvärde. Koppla varje använt e-postfält till en effekt som stöds i målläget eller ange uttryckligen att ersättning saknas. Verifiera i den godkända målpiloten faktisk konto-/avsändar- och serveridentitet, TLS-tillit och det valda synkroniserade innehållet med ofarliga data; använd varken lösenord som reservlösning eller kringgående av certifikatkontroll.

Identitet i det gamla kontot och i målläget

Dokumentera först det gamla värdet för User och det faktiska inloggningsnamn som det resulterar i. För platshållarna %_USERNAME_% och %_EMAILADDRESS_% måste fälten Exchange Login och Email Address vara ifyllda för den tilldelade användaren i Sophos Fusion. Den gamla källan anger normalt %_EMAILADDRESS_% för Exchange Online och %_USERNAME_% för Exchange Server. E-postadress och faktisk inloggning är ändå inte automatiskt identiska.

Även Domain ska ingå i protokollet. Enligt den gamla beskrivningen lämnas fältet tomt för Exchange Online och innehåller användarkontots domän för Exchange Server. Uppgifterna förklarar vilken identitet det gamla kontot använder. Jämför före godkännande de gamla värden som faktiskt används och användartilldelningen med den valda målidentiteten. Kontrollera då hur användarnamn och domän anges i målläget; inloggningsmetoden som stöds kontrolleras separat enligt ovan.

Konfiguration på den gamla enheten

Dokumentera OEM/API och om kontot konfigurerades automatiskt eller manuellt. Den gamla beskrivningen anger LG GATE, Samsung Knox och Sony Enterprise API för automatisk konfiguration. På andra enheter behövde användaren konfigurera e-postappen med uppgifterna i Sophos Mobile Control. Planera en separat överlämning till användaren och en pilot för målappen; upprepa inte bara den gamla konfigurationen.

Synkronisering och standardkonto

Dokumentera Synchronization interval som tiden mellan synkroniseringar, separat från Synchronization period, som anger åldern på de meddelanden som tas med. Dokumentera hur hämtningsfrekvensen styrs i målläget eller att ersättning saknas. Ta även med Default account och klargör hur målappen väljer standardkonto eller om en hanterad inställning saknas.

Dataflöde, format och meddelandestorlek

För Allow forwarding emails och Allow use of HTML format, dokumentera befintliga värden och tidigare beslut om verksamhetsbehov och dataskydd. Ange för båda inställningarna om målappen eller Exchange kan upprätthålla dem. Om inte, ange uttryckligen att ersättning saknas.

Dokumentera värdet för Maximum attachment size in MB ordagrant. Trots fältnamnet beskriver Sophos detta som den maximala storleken på ett enskilt e-postmeddelande, inte uttryckligen bara en bilaga. Kontrollera separat vilken effekt som är relevant för verksamheten och vilken gräns målappen eller Exchange sätter.

Sony-specialfall bland äldre enheter

Den tyska källan anger Enterprise API Level 6.x eller äldre, den engelska Level 6 eller tidigare. På berörda enheter måste Exchange-kontouppgifterna stämma med den tilldelade användaren. Mobile Control kan inte överföra ActiveSync-ID:t där. Vid den första kontakten med EAS-proxyn söker proxyn därför efter en enhet med okänt ActiveSync-ID och matchande användartilldelning. Om den hittar en sådan kopplar den det ID som e-postklienten skickat till enheten och vidarebefordrar begäran; annars avvisas den. Stäm av API-version, tilldelad användare och faktisk klientidentitet innan det gamla kontot godkänns. Observera den befintliga godkända e-postvägen utan att återställa identiteter eller kringgå åtkomstkontroller. Verifiera målvägen separat; överför inte detta gamla villkor till Gmail i Android Enterprise.

Kioskläge och godkänd väg ut

För Kiosk mode, dokumentera det befintliga värdet för Select source (Custom, App list eller No app), exakt App ID, faktisk installation, tilldelningsstatus och enhetstillstånd. För App list, dokumentera den valda Android-appposten som redan har lagts till i Sophos Mobile och stäm av dess upplösta paketidentitet med App ID och den faktiskt installerade appen innan den kopplas till målläget. Om den konfigurerade kioskappen saknas vid tilldelning av den gamla policyn förblir uppgiften för policytilldelning Incomplete / Unvollständig tills appen är installerad. Vid sådan gammal status ska identitet och installation först stämmas av; en återställning är ingen felsökning på chans. No app innebär däremot att begränsningarna överförs men att ingen app startar. Likställ inte detta med ett saknat paket eller ett Enterprise-alternativ som heter None.

Om enhetsfunktioner inte har inaktiverats kan användaren lämna den gamla kioskappen och använda enheten normalt; appvalet ensamt bevisar inte att enheten är låst i kioskläge. Dokumentera särskilt befintliga värden för Allow Home button och Allow task manager samt godkänd fysisk eller alternativ administratörsåtkomst. Kontrollera kioskappen, att den går att starta och vägen ut före återställning, och verifiera detta separat för målläget.

För Sony Enterprise API Level 9 eller senare gäller enligt den gamla källan: om ens ett av alternativen Allow volume up, Allow volume down eller Allow volume mute är inaktiverat är alla volymknappar inaktiverade. Dokumentera berörd modell, API-nivå och gammalt tillstånd. Kontrollera i den godkända målpiloten vilken ljud- och knappstyrning som stöds för modellen och det valda hanteringsläget. Testa det ljud och de knappar som behövs på enheten i stället för att förutsätta den gamla effekten.

Knox Premium, startskydd och administratörsappar

Dokumentera det befintliga värdet för Allow firmware auto update options, ansvarig och stöd för enheten/licensen. Det gamla alternativet gör att enheten automatiskt söker efter firmwareuppdateringar; användaren kan inte ändra detta i enhetsinställningarna. Det betyder inte att varje uppdatering installeras automatiskt. Dokumentera separat den ersättning som stöds i målläget eller att den saknas och observera det faktiska uppdateringsbeteendet i den godkända piloten utan att aktivera gamla alternativ på nytt.

Gamla Knox Premium restrictions påverkar Samsung Knox-enheten, inte Knox-containern. För att de ska tillämpas krävs en Samsung Knox Premium-licens registrerad i Sophos Mobile. Kontrollera enhetstyp, licensregistrering och faktisk effekt på enheten var för sig. Klargör separat vilken licens som behövs och vilken enhetseffekt som stöds för det valda Enterprise-målläget; den gamla licensregistreringen bevisar inte någon överföring.

Dokumentera det befintliga värdet för Enable ODE Trusted Boot verification. Enligt den gamla beskrivningen dekrypteras datapartitionen vid start endast med officiär binärfil och kärna. Klargör dataåtkomst och godkänd återställningsväg före omstart eller återställning; inaktivera inte verifieringen som en genväg för migrering eller återställning.

Dokumentera Prevent installation of another administrator app och Prevent activation of another administration app separat. Det första gamla alternativet förhindrar installation av appar med enhetsadministratörsrättigheter, utom appar som installerats av Sophos Mobile; det andra förhindrar aktivering av dessa rättigheter. Kontrollera i förväg den faktiska effekten på nödvändiga appar och den avsedda registreringsvägen utan att generellt lätta på spärrarna.

Om Allow Common Criteria mode finns, dokumentera dessutom alla sex gamla villkor:

enhetskryptering på;
snabbkryptering av;
kryptering av extern lagring på;
gräns för misslyckade försök som utlöser radering av enheten inställd;
certifikatåterkallelse på;
lösenordshistorik av.

Utan dessa villkor tillämpas CC Mode inte enligt den gamla källan. Detta är beroenden i utgångsläget, ingen uppmaning att aktivera gamla alternativ på nytt eller försvaga lösenordsskyddet i målläget. Testa inte radering efter misslyckade försök på produktionsenheter. Kontrollera aktuellt stöd, ersättning i målläget och återställning separat i den godkända piloten; den gamla beskrivningen är inget aktuellt certifieringsbevis.

Skärmlås och begränsningar

För det befintliga skärmlåset under Password policies, dokumentera värdet för Password type och dess betydelse i den gamla policyn: Pattern, PIN or password kräver ett skärmlås utan ytterligare begränsningar; Simple password kräver ett lösenord med minst en bokstav, och siffror är tillåtna; PIN or password tillåter dessa två låstyper. Alphanumeric password och Complex password kräver ett lösenord med bokstäver och siffror. Endast Complex password lägger till de sex minimikraven på sammansättning som anges nedan. Detta beskriver utgångspolicyn, inte konfiguration av en ny policy i det gamla läget eller ett identiskt beteende i Android Enterprise.

För Simple password, PIN or password, Alphanumeric password och Complex password, dokumentera även de värden som finns: Minimum password length (totalt antal tecken), Maximum idle time before password prompt (inställd inaktivitetstid; enheten kan kräva en kortare tid), Maximum password age in days (bytesintervall; gammalt intervall 0–730 dagar, där 0 innebär att inget byte krävs), Maximum sign-in attempts (misslyckade försök innan den gamla policyn raderar enheten) och Password history (antal lagrade tidigare lösenord som inte får återanvändas). Hitta inte på värden för fält som saknas för den valda typen. Dokumentera före godkännande den effekt som stöds i målläget eller att den uttryckligen saknas, OS/OEM och valt enhets- eller arbetsprofilslås för typen och varje fält; överför inte gamla värden automatiskt.

För Password policies, dokumentera de sex minimivärdena för ett befintligt Complex password var för sig: bokstäver, gemener, versaler, icke-alfabetiska tecken, siffror och specialtecken. Icke-alfabetiska tecken och specialtecken är separata gamla värden, inte ett gemensamt krav. Stäm av varje värde mot den valda fullständiga enhetshanteringen, enhetslåset eller arbetsprofilslåset och OS-/OEM-markeringarna. Dokumentera för varje minimivärde den ersättning som stöds eller att sådan saknas, samt tillämpningen som observerats utan destruktiva tester.

Ta även med Allow fingerprint authentication och Allow iris authentication och deras befintliga val. De gamla upplåsningsmetoderna gäller bara på enheter som stöder dem. Kontrollera tillgänglighet och faktiskt tillåtna upplåsningsmetoder i målläget separat för OS och OEM. Fingeravtryck i App Protection eller Weak biometric recognition bevisar inte en identisk ersättning.

För Password policies och Restrictions, kontrollera återställning, säkerhetskopiering och effekten av varje relevant spärr och begränsning för aktuellt OS och läge; anta inte samma effekt på privata och företagsägda enheter. En gräns för misslyckade försök kan radera enheten; testa inte på produktionsenheter.

För de Restrictions som faktiskt används ska matrisen fyllas i ned till varje relevant inställning: gammalt värde, effekt som observerats på enheten, verksamhetens skyddssyfte, OS/OEM och beroenden mellan huvud- och underalternativ, ersättning som stöds i målläget eller en uttrycklig och godkänd avvikelse. Ta särskilt med datadelning och inspelning, radio-/delningsfunktioner och kringutrustning, nåbarhet/nödkommunikation/roaming, uppdateringar/återställning, konton inklusive borttagning av Google-konton samt appinstallationskällor och avinstallation. Motivera varför sådant som inte används eller inte är tillämpligt utesluts. Bedöm inte spärrar enbart efter namnet: enligt den gamla källan tillåter ett videoförbud foton och streaming; den delade urklippsfunktionen förutsätter Allow clipboard. Om Bluetooth används ska även befintliga parkopplingar och profiler granskas; för internetdelning eller kamera på låsskärmen ska även huvudalternativet kontrolleras. Dokumentera också relevanta SD-/USB-undervärden tillsammans med deras huvudalternativ. En gammal Beam-spärr styr inte Quick Share. Verifiera nödvändiga funktioner och förbjudna dataflöden med ofarliga testdata i den godkända målpiloten; om ersättning saknas eller effekten skiljer sig, stoppa utrullningen tills ett dokumenterat beslut finns.

De historiska undersidorna beskriver ursprungliga inställningar, delvis från 2022–2023, inte aktuellt stöd för gamla protokoll/OEM-funktioner på målenheterna. Kontrollområdena visar vilka beroenden som behöver klarläggas före migreringen. Kontrollera båda fullständiga målpolicyerna och den egna klientorganisationen innan konkreta policyrekommendationer ges. De separata KB-artiklarna om policyer för fullständigt hanterade enheter, arbetsprofilpolicyer, Android-anslutningar, BYOD och FRP ersätter inte ett migreringsgodkännande. E-postautentisering behandlas dessutom i artikeln om Exchange-migrering.

Pilot, avbrott och återställningsväg

Genomför en pilot per läge endast på enheter som kan avvaras och är representativa, efter att ägande, klientorganisation och licensläge har klarlagts och en godkänd återställningsväg finns. Säkra först enhetsdata och befintliga policyer; förbered den nya policyn och registreringsmetoden var för sig. Bekräfta under piloten kommandot på enheten, kontrollera det nya hanteringsläget och den faktiska tilldelningen och observera appar, kontoinloggning/e-postflöde, kioskläge (om sådant finns), Wi-Fi/VPN, certifikatutfärdande och certifikatförnyelse samt privata data efter BYOD-övergången. Besluta om fler enheter först när effekten har belagts.

För de dokumenterade gamla värdena ska konkreta förväntade och faktiska resultat antecknas i piloten:

Mobilnät

Kontrollera mobildataåtkomst med avsett SIM-kort hos avsedd operatör, separat från den oberoende återställnings-/hanteringsanslutning som testats tidigare. Kontrollera därefter att enheten checkar in till hanteringssystemet. Migrera inga fler enheter om dataåtkomst saknas; använd den i förväg godkända oberoende anslutningen och eskaleringsvägen.

Appar och behörigheter

Kontrollera först startbeteendet för varje tidigare spärrad app samt nödvändiga verksamhets- och nödappar. Kontrollera därefter varje målapp och dess körningsbehörigheter med testdata. Jämför förväntat tillstånd med appens faktiska funktion när behörigheten är beviljad eller nekad. Kontrollera även om användaren får ändra behörigheten som avsett eller om ändring förhindras. Beakta då Android 12-gränserna i arbetsprofilen.

Dokumentera inställningarna och tilldelningen före en ändring. Använd endast den uppdaterings- eller ersättningsväg som stöds och har testats i förväg. Om en policyändring måste återtas, bekräfta synkroniseringen och upprepa samma behörighetskontroller.

Bevilja inte behörigheter generellt bara för att få en app att fungera. Ett senare återkallande tar inte tillbaka data som redan har röjts.

Applösenord och skärmlås

Kontrollera i målläget förväntad lösenordsfråga, tillåtna alternativa åtkomstsätt, respittid utan ny fråga och autentisering. För enhets- respektive arbetsprofilslås ska de enskilda minimikraven och tillgängliga biometriska metoder kontrolleras utan destruktiva tester och utan att nå gränsen för misslyckade försök.

För det valda mållåset, jämför tillåtna låstyper och total längd med det dokumenterade beslutet och observera den faktiska inaktivitetstiden fram till lösenordsfrågan, inklusive eventuella kortare enhetsgränser. Kontrollera bytes- och återanvändningsbeteende, i den mån det stöds, med ett godkänt testkonto eller en godkänd testenhet, eller med statusunderlag som stöds; dokumentera uttryckligen om stöd saknas. På produktionsenheter ska lösenordsbyten varken påskyndas, skyddet försvagas eller gränsen för misslyckade försök nås. Behåll den förberedda återställningsvägen och stoppa utrullningen vid avvikelser.

E-post

Använd ett godkänt testkonto för att kontrollera leveranstid, standardkonto när ett meddelande skrivs, tillåten/förbjuden vidarebefordran, HTML-beteende och relevanta meddelandestorlekar med ofarligt innehåll. Använd inga verkliga konfidentiella data. Jämför resultatet med det dokumenterade målbeslutet, även om en tidigare hanterad inställning saknas i målläget.

Stoppa vid avvikelser

Stoppa utrullningen vid en avvikelse. En synlig målkonfiguration räcker inte; klargör först orsak, ersättning som stöds och säker återställningsväg.

Vid utebliven nåbarhet, oklart dataläge, fel enhet eller läge, misslyckad inloggning eller återställningsspärr: stoppa och eskalera. Fastställ ansvarig support, en fungerande oberoende anslutning och en väg för att driftsätta enheten på nytt före åtgärden. Rollback innebär inte att en fabriksåterställning eller en borttagen arbetsprofil kan ångras: återställning är bara möjlig från säkerhetskopior som bevisligen går att använda och genom godkänd nyregistrering; varken omedelbar fjärrleverans av kommandon eller identisk policyeffekt är belagd. Utan test i klientorganisationen och på enheten: ingen migreringsanvisning för produktion eller framgångsgaranti.