Android Enterprise in Sophos Mobile einrichten und Geräte sicher registrieren

Kurzantwort: Für die MDM-Registrierung benötigt die Organisation eine passende Sophos Mobile Device Management- oder Sophos Mobile-Lizenz, eine mit Sophos Mobile verbundene Android-Enterprise-Registrierung und ein zum beabsichtigten Gerätetyp passendes Richtlinien-/Aufgabenpaket. Sophos Mobile Threat Defense allein berechtigt nicht zur hier beschriebenen MDM-Verwaltung. Bei Full Device kann Sophos Mobile das ganze Gerät verwalten; beim hier beschriebenen Android Enterprise work profile auf einem nachweislich persönlichen Gerät (BYOD) nur das Arbeitsprofil. Firmeneigentum ist kein Nachweis für Full Device, und eine Work-Profile-Richtlinie macht ein Firmengerät nicht zum vollständig verwalteten Gerät. Vor jeder Anmeldung Eigentum, tatsächlichen Modus, vorhandene Daten, Google-Identität und den autorisierten Ausstieg feststellen. Dieser Leitfaden ist keine Freigabe für eine Flottenmigration oder einen Reset.

Für die Editionswahl und Zählung vor dem Pilot siehe Sophos-Mobile-Lizenzierung; die tatsächliche Berechtigung im eigenen Tenant bleibt zu prüfen.

Vorprüfung: welchen Pfad darf dieses Gerät nehmen?

Neues oder zurückgesetztes Firmengerät – volle Verwaltung genehmigt. Android Enterprise full device mit Android Enterprise device policy verwenden. Full Device lässt sich nur vor der ersten Einrichtung oder nach Werksreset einschreiben; späteres Abmelden erfordert ebenfalls Werksreset. Vorhandene Gerätedaten nicht ohne geprüfte Sicherung durch einen Reset ersetzen.

Bei Full Device ist kein persönliches Google-Konto für die Einschreibung nötig. Standardmässig stehen nur in Managed Google Play freigegebene Apps zur Verfügung; die Google-Play-Konfiguration kann den Zugriff auf alle Play-Store-Apps erlauben. Zu Beginn ist nur ein Mindestbestand an Apps aktiviert: Google Play Store, Contacts, Messages und Phone. Fehlende vorinstallierte Apps deshalb nicht mit einem fehlgeschlagenen Enrollment gleichsetzen. Verwaltete Apps können ohne Nutzerinteraktion installiert, entfernt oder aktualisiert werden; Laufzeitberechtigungen und unterstützte App-Konfigurationen werden über die passende Richtlinie gesteuert. Den tatsächlichen App-Bestand und notwendige Freigaben im Pilot prüfen.

Persönliches Gerät – nur Arbeitsdaten. Android Enterprise work profile mit Android Enterprise work profile policy verwenden. Das ist keine Geräte-Vollverwaltung: kein Full-Device-Wipe als angeblicher Ausstieg. Beim Entfernen des Arbeitsprofils werden dessen Apps und Daten gelöscht; private Daten ausserhalb sind nicht Teil dieses Verwaltungspfads.

Einwilligung, Einrichtung und Entfernung auf persönlichen Geräten behandelt der Android-BYOD-Leitfaden; er gilt nicht für Firmengeräte mit Arbeitsprofil.

Firmengerät mit gewünschtem Arbeitsprofil oder unklarer Zuordnung – Stopp. Der hier beschriebene Work-Profile-Pfad gilt für BYOD, nicht für einen eigenen organisationsbezogenen Work-Profile-Provisioning-Pfad mit anderen Reset- und Offboarding-Folgen. Nicht allein nach Eigentum oder Richtlinienname als Full Device beziehungsweise BYOD klassifizieren. Zuerst Geräte- und OEM-Modus sowie die für diesen Tenant unterstützte Einschreibung gesondert verifizieren und autorisieren lassen. Firmengeräte mit Arbeitsprofil (COPE) sind von den folgenden BYOD-Aussagen zu Profilentfernung, Wiederherstellung und Offboarding ausgeschlossen.

Bereits im Device-administrator-Modus verwaltet – Migration getrennt planen. Nicht einfach eine neue Enterprise-Registrierung darüber starten. Dieser veraltete Modus ist nur für Android 9 oder älter verfügbar und bei Android 10 oder neuer nicht zulässig. Bestandsgerät und Datensicherung prüfen; einen getrennten Migrationsplan nach dem Leitfaden zur Device-Administrator-Migration erstellen. Dort werden alte Deregistrierung und Firmengeräte-Reset getrennt behandelt; die Übergabe ist keine Reset-Freigabe und ersetzt keinen am Gerät bestätigten Rückbau.

Nutzerloses Firmen-/Kioskgerät – eigener Provisioning-Pfad. Als vollständig verwaltetes Android-Enterprise-Gerät mit QR oder Zero-touch möglich. Bei vor dem 9. April 2024 im managed Google domain-Modus registrierten Organisationen ist dafür zuerst Use managed Google domain device enrollment erforderlich; ohne diesen Schalter diesen Pfad nicht starten. Ein nutzerloses QR-Paket enthält Assign policy für eine Android Enterprise device policy, aber keine Enroll-Aufgabe. Beim Enrollment keine E-Mail-Adresse zuweisen. Kiosk-/Provisioning-Konfiguration ist ein eigener Ablauf, nicht das Standard-Nutzerpaket. Ein Dedicated device entsteht durch eine Kiosk mode-Konfiguration auf einem vollständig verwalteten Gerät und ist auf eine App oder eine Auswahl von Apps beschränkt.

Für nutzerlose QR-Anmeldung gibt es Setup > Google setup > QR code enrollment (user-less). Bei Zero-touch bestimmt User authentication auf dem Zero-touch-Tab die Anmeldung mit oder ohne Nutzer. Obwohl keine E-Mail angebunden und kein Sophos-Mobile-Nutzer zugewiesen wird, legt Google intern ein Konto an. Unter Internal properties heisst dessen ID bei managed Google domain android.enterprise.bte.userless-device.account-id, bei Managed Google Play Account afw_play_emm_managed_device_account_user_id. Diese ID ist kein Beleg für eine persönliche Nutzerzuordnung; ein Nutzer kann bei Bedarf später gesondert zugewiesen werden. Provider-Zuweisung, QR-Erstellung und physische Einrichtung müssen vor dem Einsatz im eigenen Provisioning-Ablauf geklärt sein. Für diese Vorbereitung den Leitfaden für dedizierte Android-Geräte verwenden: Er trennt QR, Zero-touch und KME und beschreibt den autorisierten QR-Pilot. Die dort offene Zuordnung des Sophos-KME-Profils zur aktuellen Samsung-Oberfläche bleibt ein Stopp vor ausführbarer KME-Profilerstellung; weder dieser Verweis noch ein QR-Erfolg bestätigt KME, einen Reset oder den physischen Kiosk-Ausstieg.

KME-Voraussetzung: Gerätebestand zwischen Kunde und Reseller klären

Bei Knox Mobile Enrollment (KME) beginnt die Vorbereitung vor der Profilzuweisung: Die IT-Administration des Kunden und der Reseller müssen dieselbe Organisation und dieselben beschafften Geräte meinen. Der folgende Zusammenhang erklärt diese vorgelagerte Übergabe, nicht die Erstellung eines KME-Profils in der aktuellen Samsung-Oberfläche.

Identitäten austauschen und prüfen: Die IT-Administration gibt dem Reseller die Knox Customer ID der vorgesehenen Kundenorganisation; der Reseller gibt der IT seine Reseller ID. Gemeint ist ein von Samsung zugelassener, vertrauenswürdiger Reseller im Knox Deployment Program. Vor der Freigabe dieser Zusammenarbeit beide IDs und die zugehörigen Organisationen abgleichen: Eine falsche Kunden-ID würde die Geräteübergabe dem falschen Kundenbestand zuordnen. Diese IDs sind weder Google-Anmeldedaten noch der separat beschriebene Knox-Lizenzschlüssel.
Beschaffte Geräte hochladen und teilen: Nach der Beschaffung lädt der Reseller die Liste der gekauften Geräte-IDs in das Knox Reseller Portal hoch. Diese Geräte-IDs werden zwischen dem Reseller-Portal und KME geteilt und bilden den vorgelagerten Gerätebestand für die Kundenkonsole. Der Upload ist noch keine Sophos-Einschreibung. Zur Prüfung gehören die richtige Kundenorganisation und der Abgleich der Geräteidentitäten mit Bestellung, Lieferung und internem Inventar; fehlende oder fremde Geräte zuerst mit dem Reseller klären, nicht durch eine Profilzuweisung übergehen.
Benachrichtigung und Kundenfreigabe trennen: Die IT-Administration wird per E-Mail über den Geräteupload informiert und genehmigt den Upload auf Kundenseite. Die Nachricht meldet den Upload, ersetzt aber nicht die Genehmigung. Vor dieser Freigabe nochmals Customer ID, Reseller-Zuordnung und die gemeldeten Geräte-IDs gegen den vorgesehenen Bestand prüfen. Erst ein korrekt zugeordneter und akzeptierter Gerätebestand ist die Grundlage für die spätere Profilzuweisung; daraus folgt noch kein erfolgreich eingerichtetes Gerät.

Automatischer Upload und automatische Genehmigung sind verschiedene Entscheidungen: Auto-upload betrifft das automatische Hochladen von Gerätedaten; Auto-approval betrifft die automatische kundenseitige Annahme von Uploads des vertrauenswürdigen Resellers. Aus der einen Einstellung darf man die andere nicht ableiten. Auch die automatische Profilzuweisung ist eine separate Entscheidung, keine zwangsläufige Folge eines Uploads oder seiner Genehmigung. Avanet empfiehlt, jede vorgesehene Automatisierung gesondert für den benannten Reseller und Kundenbestand zu autorisieren und ihre tatsächlich wirksamen Einstellungen zu prüfen. Ohne ausdrücklich bestätigte automatische Genehmigung die manuelle Kundenfreigabe nicht als erledigt behandeln. Bei autorisierter Automatisierung bleibt der Abgleich von Kunden-ID, Geräteidentitäten und akzeptiertem Inventar vor der Profilzuweisung erforderlich; bei Abweichungen stoppen und die zuständige IT-Administration sowie den Reseller einbeziehen. Hier werden weder aktuelle Bedienelemente noch Standardwerte dieser Einstellungen vorausgesetzt.

Die KME-Übergabe hebt keinen Betriebsstopp auf: Der geprüfte Bestand allein bestätigt weder die Zuordnung des Sophos-KME-Profils zur aktuellen Samsung-Oberfläche noch den Verwaltungsmodus am Gerät. Der oben verlinkte Provisioning-Leitfaden und sein Stopp vor ausführbarer KME-Profilerstellung gelten unverändert. Profilzuweisung und anschliessender Abschluss der Einschreibung durch die Gerätenutzer sind nachgelagerte Schritte; ihr Ergebnis muss separat in Sophos Mobile und am Gerät geprüft werden. Diese Voraussetzungen erlauben weder einen Reset noch eine Provider-Freigabe oder einen physischen Kiosk-Ausstieg.

Der Android-Tab unter Setup > Google setup enthält die Moduswahl Management mode > Android Enterprise > Save; diese Wahl steuert auch, welche Richtlinientypen in der Oberfläche erscheinen. Sophos Mobile Threat Defense ist dagegen nicht die Berechtigung für diese MDM-Moduswahl; das Hosten der Intercept-X-App ist eine getrennte Aufgabe. Android Enterprise-Tab und Samsung Knox license-Tab haben wieder andere Aufgaben: Kontoanbindung/FRP beziehungsweise optional eine Samsung Knox Premium-Lizenz für den Knox-Container (Schlüsseltypen KPE Premium oder KLM Workspace). Ein Knox-Lizenzschlüssel ist weder Voraussetzung für jedes Android-Enterprise-Gerät noch eine Knox-Mobile-Enrollment-Zuweisung. Schlüssel nur bei tatsächlichem Anspruch unter Setup > Google setup > Samsung Knox license eintragen und Save wählen; vor Remove abhängige Geräte/Container prüfen. Remove deregistriert den Schlüssel, nicht eine KME-Provider-Zuweisung.

Abgrenzung der Einstellungen: Host Sophos apps on your web server und Set synchronization interval (Android) auf dem Android-Tab sind getrennte Aufgaben; App-Hosting und das Einstellen des Synchronisierungsintervalls werden hier nicht angeleitet. Auf dem Android Enterprise-Tab ist Configure email placeholder eine weitere, getrennte Aufgabe neben Einrichtung und FRP. Die Prüfung der Anmelde-E-Mail in diesem Artikel ersetzt keine Konfiguration dieses Platzhalters. Das Hosten von Intercept X in der Threat-Defense-Edition ist ebenfalls nicht Teil dieses Ablaufs.

Android-Push-Verbindung vor dem Pilot prüfen: Für Google Firebase Cloud Messaging (FCM) den Verbindungsaufbau vom Android-Gerät ausgehend zu Google über TCP 5228-5230 ermöglichen; Sophos nennt dafür sämtliche IP-Blöcke aus Googles ASN 15169. Google nennt für Android-FCM zusätzlich TCP 443. Das ist keine eingehende Portweiterleitung zum Gerät. Bei IP-basierter Filterung die aktuelle Google-IP-Bereichsliste als Live-JSON abrufen: Sie enthält unter prefixes die Einträge ipv4Prefix und ipv6Prefix; creationTime und syncToken helfen, den abgerufenen Stand zu dokumentieren. Dies ist eine veränderliche Betriebsdatenquelle, keine ausgelagerte Anleitung und keine FCM-exklusive Adressliste. Google rät von IP-basierter FCM-Filterung ab, weil die grossen, häufig wechselnden Bereiche leicht unvollständig oder veraltet werden. Falls diese Filterung vorgeschrieben ist, die vollständigen aktuellen Bereiche mit den freigegebenen Firewall-Objekten abgleichen, Änderungen kontrolliert übernehmen und die Liste mindestens monatlich sowie bei Zustellproblemen erneut prüfen; keine eingefrorene Liste aus diesem Artikel oder nur die kleinere Google-Cloud-Bereichsliste verwenden.

Den tatsächlichen Geräte-Netzpfad mit der Netzwerkadministration abgleichen: vorgesehenes WLAN/Mobilfunknetz, allfälliges VPN, wirksame ausgehende Regel und Rückverkehr prüfen. FCM-Push benötigt eine direkte Verbindung und lässt sich nicht über einen Netzwerkproxy vermitteln; bei NAT oder Stateful Packet Inspection für Verbindungen über 5228-5230 einen Timeout von mindestens 30 Minuten vorsehen. Im autorisierten Pilot Firewall-Logs beziehungsweise einen gezielten Paketmitschnitt mit dem Gerätezeitpunkt abgleichen und danach Aufgabenübernahme in Sophos Mobile und am Gerät kontrollieren. Bei blockiertem oder abbrechendem Verbindungsaufbau zuerst Regel, Route, VPN/Proxy und Timeout klären, nicht die Google-Bindung neu registrieren. Diese Push-Verbindung einschliesslich ihres TCP-443-Pfads ist von HTTPS 443 zum regionalen Sophos-Mobile-Gerätehost und von SCEP-Inbound-Freigaben getrennt; jeden benötigten Pfad gesondert prüfen. Eine Freigabe, ein JSON-Abruf oder eine erfolgreiche Kontoanbindung allein belegt weder Geräte-Enrollment noch Aufgabenübernahme.

Organisation bei Google anbinden – mit Kontinuität statt zweiter Registrierung

In Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise zuerst den vorhandenen Android Enterprise mode und die Kontodetails prüfen. Ist eine Registrierung vorhanden, nicht blind ein zweites Google-Unternehmenskonto anlegen oder eine Bindung ersetzen. Zuständiges Administratorkonto, Domainzugriff und Wiederherstellung vor Änderungen intern dokumentieren.
Nur bei noch nicht verbundener Organisation: Configure > Register account öffnen. Die Weiterleitung führt zu Google. Dort eine organisationskontrollierte Arbeits-E-Mail in Create Admin Account eingeben, Next wählen und die von Google für diese Identität angezeigten Schritte zur Unternehmensregistrierung befolgen. Ist die E-Mail-Adresse Google noch nicht bekannt, den zugesandten Bestätigungslink öffnen; bei bestehender Google-Domain oder Microsoft-Identität können die Schritte abweichen. Auf der Aboseite Android Enterprise auswählen; das Google-Android-Enterprise-Abonnement ist kostenlos, zusätzliche Google-Abos können kostenpflichtig sein.
Nach Rückkehr zu Sophos Mobile dieselbe E-Mail des angelegten Android-Enterprise-Admin-Kontos eintragen, Finalize setup wählen und am Android Enterprise-Tab die angezeigten Kontodetails kontrollieren. Nicht aus einer erfolgreichen Google-Anmeldung bereits auf erfolgreiche Geräteverwaltung schliessen.

Nach der Registrierung einer zuvor bei Google unbekannten Arbeits-E-Mail meldet Google den Administrator im neuen Enterprise Google Account an. Dieses Konto kann auch für andere Google-Dienste wie die Google Admin console unter admin.google.com verwendet werden. Avanet empfiehlt, dort vor weiteren Änderungen die tatsächlich angemeldete Identität und Organisation abzugleichen. Das ist eine vorgesehene Kontrolle, kein für diesen Beitrag ausgeführter Anmeldetest. Eine bestehende Google-Domain oder Microsoft-Identität kann einen anderen Registrierungsablauf haben; daraus keine zweite Kontoanlage ableiten.

Bindung und kurzlebige Tokens nicht verwechseln: Die bestehende Android-Enterprise-Organisationsregistrierung ist nicht das zeitlich begrenzte Google-Token für die Anmeldung eines neuen Geräts und nicht das Token für das Upgrade eines bereits eingeschriebenen Geräts. Ein abgelaufener oder fehlgeschlagener Geräteauftrag rechtfertigt weder Configure/Register account erneut noch das Entfernen der bisherigen Google-Bindung. Zuerst Konto-/Domaininhaberschaft, aktuellen Registrierungsmodus und Schalter, Geräte- und Nutzerzuordnung sowie den Auftrag dokumentieren; bei unklarer Bindung stoppen und administrativ klären statt eine zweite Registrierung als Reparatur zu verwenden. Die unten genannten beiden Ein-Stunden-Fristen haben verschiedene Start- und Endpunkte.

Registrierungs- und Anmeldemodus getrennt betrachten: Vor dem 9. April 2024 konnten Organisationen zwischen Managed Google Play Account und managed Google domain als Registrierungsmodus wählen; spätere neue Registrierungen verwenden managed Google domain. Die zusätzliche Einstellung Use managed Google domain device enrollment entscheidet über die Anmeldung neuer Geräte: dann authentifizieren sich Benutzer bei Google statt bei Sophos Fusion und benötigen vorab ein Konto in Google Workspace/Cloud Identity (gegebenenfalls via IdP). Managed-Google-domain-Registrierung allein bedeutet noch keine Google-Domain-Geräteanmeldung: Ohne den Schalter verwaltet Sophos Mobile die Google-Konten bei nach dem Stichtag registrierten Organisationen selbst. Bei vor dem Stichtag im managed-Google-domain-Modus registrierten Organisationen erfolgt die Benutzerzuordnung über Sophos Fusion; Sophos Mobile erstellt bei der SSP-Anmeldung das verwaltete Google-Konto, übernimmt aber nicht dessen spätere Kontopflege. Für diese Bestandsregistrierung ist ohne den Schalter auch das Administrator-Enrollment eingeschränkt: nur Benutzer können über das Sophos Fusion Self Service Portal anmelden. Ist die Organisation im Managed Google Play Account-Modus registriert und noch nicht auf managed Google domain umgestellt, verwaltet Sophos Mobile die Google-Benutzerkonten selbst. Bei Managed-Google-Play-Account-Registrierung gilt eine technische Grenze von 10 gleichzeitig registrierten Android-Enterprise-Geräten je Nutzer; das ist keine Lizenzzählformel.

Nur wenn die Domain-Geräteanmeldung für neue Einschreibungen ausdrücklich freigegeben ist: Bestehenden Android Enterprise mode, Schalterzustand und Google-/Sophos-Nutzerzuordnung dokumentieren; alle vorgesehenen Nutzer müssen vorher in der verwalteten Google-Domain angelegt sein. Dann in Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise > Managed Google domain device enrollment Use managed Google domain device enrollment auswählen und Save wählen. Danach Schalterzustand und für den Pilot die Google-Anmeldung mit der vorgesehenen Identität prüfen; nicht aus dem Speichern eine erfolgreiche Geräteanmeldung ableiten. Fehlt der Schalter, nicht ersatzweise eine neue Bindung anlegen: zuerst den Organisations-Registrierungsmodus prüfen und das separate Upgrade auf managed Google domain nur nach eigener Freigabe beurteilen. Bei vor dem Stichtag registrierten managed-Google-domain-Organisationen werden damit auch QR, Zero-touch und Knox Mobile Enrollment verfügbar; diese Methoden waren bei anderen Android-Enterprise-Registrierungsarten bereits verfügbar. KME mit managed Google domain device enrollment unterstützt keinen Legacy-Device-administrator-Modus.

Richtlinie, Paket und Benutzeridentität vorbereiten

Die konkreten Optionen einer Full-Device-Richtlinie erklärt die Android-Enterprise-Geräterichtlinie für Firmengeräte; sie ersetzt nicht die Wahl des Einschreibemodus.

Für Full Device eine Android Enterprise device policy, für Work Profile eine Android Enterprise work profile policy anlegen. Keine Work-Profile-Policy als Beleg für volle Firmen-Geräteverwaltung ausgeben. Für jeden verwendeten Gerätetyp ein separates Aufgabenpaket mit mindestens Enroll und Assign policy für genau dessen Richtlinie erstellen. Zielgruppe und bestehende Zuweisungen vor dem Pilot notieren.
Vor Einladungen die wirksame, gespeicherte SSP-Konfiguration prüfen: Unter Setup > Self Service Portal für die vorgesehenen Benutzergruppen feststellen, welche vorhandene Konfiguration gilt: Bei mehreren passenden Gruppenzuordnungen gewinnt die höchste Priorität; Default greift nur, wenn keine andere Konfiguration passt. Eine bereits passende Konfiguration prüfen, nicht neu erstellen. Unter Maximum number of devices muss für die geplante Einschreibung noch Platz sein; diese SSP-Grenze ist weder die Lizenzzählung noch die technische Google-Grenze. In den Android-Plattformeinstellungen Owner, Ziel-Device group und Enrollment package mit Eigentum, genehmigtem Verwaltungsmodus und vorbereitetem Aufgabenpaket abgleichen; für persönliche und Firmengeräte können verschiedene Pakete verwendet werden. Owner allein belegt keinen tatsächlichen Full-Device-Modus. Bei unklarer oder unpassender Konfiguration stoppen und die zuständige Administration einbeziehen, nicht auf ein anderes Konto oder einen anderen Einschreibetyp ausweichen oder Default breit ändern.
Die Konfigurationsprüfung und der Pilot nach dem SSP-Adminablauf sind Voraussetzung für Einladungen: Fehlt eine passende Konfiguration, sie dort gesondert vorbereiten. Änderungen auf einen autorisierten, eng begrenzten Pilot mit nur den benötigten Aktionen beschränken, bevor gespeichert wird: Save kann Aktionen für bereits zugeordnete Gruppen sofort verfügbar machen, noch vor einer Prioritätskorrektur. Geänderte Plattformeinstellungen mit Apply übernehmen, danach die Konfiguration mit Save speichern. Zur Kontrolle empfiehlt Avanet, die Konfiguration erneut zu öffnen und die gespeicherten Einstellungen sowie die wirksame Gruppenpriorität einschliesslich Default nochmals abzugleichen. Vor Einladungen oder breiter Gruppenzuordnung den im SSP-Adminablauf beschriebenen Einschreibetest mit autorisierten Testpersonen und Geräten für jede betroffene Gruppe und jeden vorgesehenen Besitz-/Verwaltungsmodus durchführen und das Ergebnis am Gerät sowie in Sophos Mobile prüfen; eine sichtbare Portaloption genügt nicht.
Die Sophos Mobile Control-App in Managed Google Play freigeben, sonst aktualisiert sie sich nicht automatisch. Erst nach diesen Prüfungen und der IT-Freigabe Benutzer auf ihr Portal beziehungsweise die organisationsseitige Einladungs-E-Mail und die SSP-Benutzerübergabe verweisen: Nutzer installieren und konfigurieren Mobile Control nach den dort angezeigten konkreten Anweisungen. Diese allgemeinen SSP-Schritte ersetzen keine Modus- oder Resetentscheidung.
Bei Use managed Google domain device enrollment alle vorgesehenen Nutzer vorab in der verwalteten Google-Domain anlegen, die Google-Anmeldedaten mit dem Nutzer klären und die Gerätezuordnung prüfen. Bei einem von Sophos Mobile gestarteten Auftrag muss die dem Gerät zugewiesene E-Mail exakt der bei Google zur Einschreibung verwendeten E-Mail entsprechen. Eine andere Person oder das Ändern der vorausgefüllten E-Mail führt zum Fehlschlag. Sophos Mobile Control 9.8 oder neuer ist erforderlich; für Work Profile zusätzlich alle verfügbaren OS- und App-Updates. Bei einer neuen Domain-Geräteanmeldung muss der Nutzer die Einschreibung auf dem Gerät innerhalb einer Stunde nach ihrem Beginn abschliessen; der blosse Start oder die Token-Nutzung in dieser Zeit genügt nicht. Preparing enrollment kann mehrere Minuten ohne sichtbaren Fortschritt stehen bleiben: App offen lassen und Gerät nicht ausschalten. Scheitert dieser Schritt dennoch, nicht wiederholt blind Aufgaben auslösen. Als Wiederherstellungswege kommen die manuelle Entfernung des Arbeitsprofils oder ein Werksreset des Geräts infrage. Nicht zwischen diesen Eingriffen frei wählen: erst Eigentum, tatsächlichen Modus und Zustand am Gerät prüfen; nur bei einem nachweislich persönlichen Gerät im bestätigten Sophos-BYOD-Work-Profile-Modus die Profilentfernung als Wiederherstellungsweg prüfen und deren Folgen für Arbeitsdaten klären, bei bestätigtem Full Device die Folgen des Werksresets für sämtliche Gerätedaten. Bei Firmengeräten mit Arbeitsprofil oder unklarem Eigentum beziehungsweise Modus stoppen und den unterstützten Sophos-/OEM-Wiederherstellungsweg separat verifizieren und autorisieren lassen. Vor jedem Eingriff Eigentum, verifizierte Sicherung und Wiederherstellbarkeit, betroffenen Nutzer und ausdrückliche Freigabe dokumentieren; vor einem Reset zusätzlich FRP-Konfiguration und Zugang zu den vorgesehenen Google-Konten sowie erneute QR-/Zero-touch-/KME-Zuweisung und den Provisioning-Weg prüfen. Bei unbekannten Zugangsdaten kein Reset. Erst nach bestätigtem Gerätezustand die Einschreibung erneut auslösen; weder ein alter Geräte-Token noch eine neue Organisationsregistrierung ist ein Ersatz für diesen Preflight.

Administrator-Pilot: Unter Devices > Add > Add device wizard bei User > Search for user die passende Person suchen und auf User selection auswählen, bei Device details > Platform Android setzen und unter Enrollment type das vorbereitete Android-Enterprise-Paket wählen. Ob das Gerät fully managed oder work profile wird, hängt an der dem Paket zugewiesenen Richtlinie; die Android-Auswahl allein legt das nicht fest. Für einen Legacy-Managed-Google-Domain-Tenant ohne aktivierte Domain-Geräteanmeldung stattdessen den zulässigen SSP-Pfad benutzen. Bei nutzerlosen Geräten ausschliesslich das ausdrücklich dafür konfigurierte QR-/Zero-touch-Verfahren nach der separaten Provisioning-Anleitung einsetzen.

Vor jeder Änderung an einer bestehenden Google-Bindung stoppen und prüfen

Ein Upgrade der Organisationsregistrierung von Managed Google Play Account auf managed Google domain ist ein anderer Eingriff als das Einschalten von Use managed Google domain device enrollment für neue Anmeldungen und wiederum anders als das Upgrade eines einzelnen bereits registrierten Geräts. Die Organisationsumstellung bindet die Verwaltung an die Arbeitsdomain und die Google Admin console statt an ein einzelnes Gmail-Konto. Vorher Domaininhaberschaft, Identitätsverwaltung, bisherige Konten und Freigabe klären; keine einfache Rücknahme behaupten.

Domain und Kontaktdaten vor der Bestätigung klären

Die genaue Domain der vorgesehenen Arbeits-E-Mail prüfen und für diese Organisationsumstellung freigeben lassen. Die gewählte Domain ist nach Abschluss des Upgrades dauerhaft festgelegt. Bei einer bestehenden verwalteten Google-Domain ist der autorisierte Zugang mit deren Super-Admin-Konto nötig. Diese Anmeldung authentifiziert die Anbindung; die Inhaberschaft bleibt an die Domain gebunden, nicht an diese einzelne Person.

Beim erfolgreichen Upgrade löscht Google die Kontaktinformationen der bisherigen Bindung, darunter die Gmail-Adresse sowie Angaben zum Datenschutzbeauftragten und EU-Vertreter. Avanet empfiehlt, benötigte Angaben vor der Bestätigung unter den internen Datenschutz- und Zugriffsregeln zu sichern und die zuständige Person für die spätere Pflege zu benennen. Das betrifft die Kontaktmetadaten der Bindung, nicht eine dokumentierte Löschung des Gmail-Kontos. Bei unklarer Domain, fehlender Super-Admin-Berechtigung oder ungeklärter Kontaktübernahme vor Upgrade stoppen.

Google-Upgrade aus Sophos Mobile fortsetzen

Nach eigener Freigabe in Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise > Upgrade to managed Google domain die Google-Weiterleitung öffnen. Dieser EMM-initiated upgrade wird aus der bestehenden Verwaltungskonsole gestartet; die Sophos-Weiterleitung ist der Einstieg in die tatsächliche Google-Transaktion, nicht eine zweite Erstregistrierung oder eine allgemeine Google-Anmeldung. Dort die Einrichtung des Administratorkontos für die verwaltete Google-Domain durchlaufen und den passenden Zweig verwenden:

Besteht bereits eine verwaltete Google-Domain, mit deren Super-Admin-Konto anmelden. Die freigegebene Domain nochmals abgleichen und Upgrade wählen. Bei bereits synchronisierten Nutzern kann Google während der Bindung zusätzlich Authenticate using Google anbieten. Die Auswirkungen dieser Google-Authentifizierung gesondert mit der Identitätsadministration freigeben lassen; bei ungeklärter Wirkung nicht aktivieren. Dieser bedingte Google-Schritt ist nicht der Sophos-Schalter Use managed Google domain device enrollment.
Besteht noch keine verwaltete Google-Domain, sie mit der freigegebenen Arbeits-E-Mail erstellen und das Administratorkonto einrichten. Die E-Mail über die Google-Nachricht bestätigen. Die vollständige Domainverifizierung ist in diesem Ablauf optional. Vor der Bestätigung die Domain nochmals abgleichen und Upgrade wählen. Das ist die Fortsetzung der bestehenden Organisationsbindung, keine zweite Erstregistrierung über Configure > Register account.

Anschliessend zu Sophos Mobile zurückkehren, die Seite aktualisieren und Android Enterprise mode = Managed Google domain kontrollieren. Description muss das zur Registrierung verwendete Administratorkonto zeigen; bei Bedarf korrigieren. Diese Kontrollen sind am Zieltenant durchzuführen, nicht bereits für diesen Beitrag ausgeführt. Bei abweichender Anzeige stoppen und die Bindung mit der zuständigen Administration klären.

Nach erfolgreichem Upgrade erfolgt die Unternehmensverwaltung in der Google Admin console der nun angebundenen Domain; die App-Verwaltung bleibt in Sophos Mobile als EMM. Benötigte Kontaktangaben in der Google Admin console dieser Domain aktualisieren und die Einträge kontrollieren. Das erneute Eintragen stellt nur Kontaktmetadaten her und ist keine Rücknahme der Bindungsumstellung. Googles empfohlene weitere Einrichtungsschritte 3 bis 6 im EMM-Setup-Leitfaden sind eine getrennte Google-Administrationsaufgabe, keine zusätzliche Lizenz- oder OS-Voraussetzung dieses Upgrades.

Neue Geräteanmeldung und Einzelgeräte-Upgrade getrennt planen

Erst danach die Domain-Geräteanmeldung für neue Geräte und das getrennte Upgrade bestehender Geräte beurteilen. Die erfolgreiche Umstellung der Organisation ist noch kein Nachweis, dass ein bestehendes Gerät seinen Anmeldemodus gewechselt hat.

Beim Einschalten des neuen Geräte-Anmeldemodus müssen alle Nutzer vorher in der Google-Domain stehen; für vor dem Stichtag registrierte Domains müssen die vorhandenen Nutzernamen erhalten bleiben, sonst kann Sophos Mobile sie nicht zuordnen. Gemeint ist der Namensanteil vor dem @, nicht zwingend dieselbe Domain: Aus dem fiktiven Fusion-Konto anna@firma.example wird bei der verwalteten Google-Domain google.firma.example das Konto anna@google.firma.example. Namen und Domains im eigenen Tenant ersetzen; bei von Sophos Mobile gestarteter Geräteanmeldung gilt zusätzlich weiterhin die exakte E-Mail-Übereinstimmung mit dem Google-Login. Bei der alten SSP-Anmeldung kombiniert Sophos Mobile den Fusion-Nutzernamen mit der verwalteten Google-Domain, sucht dieses Konto und erstellt es nur, wenn es noch nicht existiert. Das Löschen eines Mobile-Benutzers löscht kein Google-Domain-Konto. Die weitere Kontopflege erfolgt in der Google Admin console; eine Verzeichnisanbindung über Google Cloud Directory Sync (GCDS) ist eine getrennte Identitätsaufgabe.

Einzelgeräte-Upgrade ist nicht rückgängig zu machen. Nur bei freigegebenem Pilot und nach bestätigter Nutzerzuordnung (auch bei bisher nutzerlos eingeschriebenen Geräten), E-Mail-Adresse aus der verwalteten Google-Domain, Google-Zugangsdaten, eingeschalteter Domain-Geräteanmeldung und Mobile Control 9.8+: Devices > [Gerät] > Show device > Actions > Upgrade to managed Google domain enrollment; der Nutzer muss die Benachrichtigung auf dem Gerät bestätigen und sich bei Google anmelden. Der Nutzer muss das Upgrade innerhalb einer Stunde nach Auslösen der Aktion in Sophos Mobile auf dem Gerät beginnen; danach ist das Google-Upgrade-Token ungültig. Diese Frist betrifft den Beginn des Upgrades, anders als den Abschluss der neuen Geräteanmeldung oben. Bei Ablauf nicht von fortbestehender Gültigkeit ausgehen, Status und Nutzerzuordnung vor einer gesondert autorisierten neuen Aktion prüfen; weder Bindung wechseln noch blind erneut auslösen. Vorheriges Backup und Ersatzweg sind erforderlich; diese Aktion ist keine Migration von Device administrator nach Android Enterprise und nicht als allgemeiner Rückweg bei fehlgeschlagener Registrierung geeignet. Die Aktion ist bei Geräten, die bereits managed Google domain enrollment verwenden, nicht verfügbar; eine fehlende Aktion ist deshalb kein Grund zum erneuten Registrieren der Organisation.

Ergebnis prüfen und sicher aussteigen

Im Pilot Geräteidentität, Eigentumsform, tatsächlich angezeigten Verwaltungsmodus, richtige Nutzerzuordnung, abgeschlossene Aufgaben und wirksame Richtlinie gegen das Protokoll prüfen; zusätzlich auf dem Gerät bestätigen, dass beim bestätigten persönlichen BYOD-Gerät mit Work Profile nur verwaltete Apps/Daten betroffen sind beziehungsweise dass das Firmengerät korrekt eingerichtet wurde. Ein angelegter Aufgaben- oder Google-Kontoeintrag ist kein Nachweis einer erfolgreichen Enrollment-Wirkung. Bei Zeitüberschreitung, falscher E-Mail oder nicht übernommener Richtlinie vor einem erneuten Auftrag stoppen, Gerät und Aufgabenstatus sichern und den Fehler gezielt klären.

Offboarding nicht als Enrollment-Rollback verkürzen: Ein vollständig verwaltetes Android-Enterprise-Gerät benötigt zum Abmelden einen Werksreset; vor Freigabe Eigentum, wiederherstellbare Sicherung aller betroffenen Daten, Resetweg, Factory Reset Protection (FRP), Gültigkeit und verfügbare Zugangsdaten der dafür konfigurierten Google-Konten sowie eine erneute Provisionierung separat klären. Sind die Kontodaten unbekannt oder ungültig, stoppen: Nach einem Wipe kann das Gerät unbenutzbar werden. QR erfordert einen Scan bei der Geräteeinrichtung; bei Zero-touch/KME die aktive Provider-Zuweisung und den Rückgabe-/Wiederverwendungsweg vor dem Reset im separaten Provisioning-Ablauf klären. Auch das Löschen eines noch verwalteten Full-Device-Eintrags kann einen automatischen Werksreset auslösen; nicht als risikolose Bereinigung verwenden. Nur bei einem nachweislich persönlichen Gerät (BYOD) mit tatsächlich bestätigtem Sophos-Work-Profile-Modus nach Autorisierung Devices > [Arbeitsprofilgerät] > Actions > Wipe Android work profile prüfen: dabei verschwinden die Apps und Daten im Arbeitsprofil, nicht automatisch das gesamte persönliche Gerät. Erst nach dem Abgleich von Gerät, Modus, Sicherung und Freigabe mit Yes im Bestätigungsdialog auslösen. Bei Managed Google Play Account-Registrierung kann nach dem Abmelden ein Google-Konto auf dem Gerät verbleiben und weiter auf die Grenze gleichzeitig registrierter Geräte angerechnet werden; in diesem Fall nur das eindeutig identifizierte verwaltete Konto manuell entfernen, nicht das private Google-Konto des Nutzers, bevor der Platz als frei gilt. Erst nach bestätigtem Gerätezustand Bestand und Zuordnung bereinigen; kein erfolgreiches Abmelden aus dem Verschwinden eines Konsoleneintrags ableiten. Das Legacy-Device-Administrator-Unenroll ist kein Ersatz für Full-Device-Wipe.

Für die Prüfung von FRP-Konten, Gerätesynchronisierung und Reset-Wegen vor einer Freigabe siehe Android-FRP vorbereiten und prüfen; das ist keine pauschale Reset-Freigabe.

Geltungsbereich des Leitfadens: QR-, Zero-touch- und Knox-Mobile-Enrollment einschliesslich Reset und Provider-Freigabe, FRP-Kontowiederherstellung, Device-Administrator-Migration, detaillierte BYOD-Entfernung sowie App-/Richtlinienrollout sind eigene Aufgaben. Kein Gerät, Tenant, Tokenwechsel, Reset oder Abmelden wurde für diesen Beitrag ausgeführt; unterstützte OS-/OEM-Kombinationen, effektive Lizenz und tatsächliche Google-/Sophos-Rollen sind am Zielsystem zu prüfen.