Sophos Mobile Aufgabenpakete planen, übertragen und sicher prüfen

Ein Aufgabenpaket (Task bundle) bündelt mehrere Geräteaufgaben. Sophos nennt das eine Transaktion; daraus folgt keine Zusage eines atomaren Rollbacks, wenn eine spätere Aufgabe fehlschlägt. Insbesondere kann eine frühere Richtlinienzuweisung oder App-Aktion bereits wirksam sein. Die Beispiele unterscheiden sich nach Sophos-Mobile- und Threat-Defense-Handbuch: Im vollständigen Mobile-Handbuch gehören auch App-Installationen zum Einrichtungsbeispiel; die Threat-Defense-Edition nennt Registrierung und Richtlinien. Nicht aus dem gemeinsamen Menüpfad auf gleiche Berechtigungen oder Aufgabentypen schliessen.

Entwurf / Freigabegrenze: Die offiziellen Anleitungen wurden verglichen, aber kein Tenant, Gerät, Berechtigungsumfang oder Wiederanlauf praktisch getestet. Vor einer produktiven Übertragung Edition/Lizenz, Plattform, Eigentums- und Verwaltungsmodus, Zielgeräte sowie mögliche Datenverluste am eigenen Bestand prüfen. Dieses Dokument autorisiert weder Wipe noch einen automatischen Wiederholungsversuch.

Vor dem Anlegen: Plattform, Modus und Folgen festlegen

Je Plattform ein eigenes Paket anlegen. Android und Android Enterprise nicht in einem Paket mischen. Für Android Enterprise Full device und iOS/iPadOS Full MDM sind im jeweiligen Einrichtungsablauf passende Registrierungsmodi und dazu passende Richtlinien auszuwählen. Die Entscheidung über den Registrierungsmodus ist eine Voraussetzung, nicht ein nachträglicher Reparaturschritt.

Device administrator ist ein veralteter Android-Verwaltungsmodus und in Sophos Mobile nur für Android 9 oder älter verfügbar; für Android 10 oder neuer kann er nicht verwendet werden. Die unten beschriebenen Android-Aufgaben Install app und Uninstall policy gehören zu diesem Altmodus, nicht zu Android Enterprise. Das ist keine Empfehlung für neue Registrierungen oder den Weiterbetrieb alter Android-Versionen. Bestehende Geräte über die separate Migration zu Android Enterprise einordnen; ein Aufgabenpaket ersetzt diese Migration nicht.

Verfügbare Aufgabentypen pro Edition und Plattform vor der Übertragung im eigenen Tenant abgleichen. Threat Defense listet Android- und ChromeOS-Pakete mit Registrierung, Richtlinie, Nachricht und Abmeldung; iOS/iPadOS zusätzlich Wipe, aber kein pauschales App-Deployment. Das vollständige Mobile-Handbuch enthält weitere plattformabhängige Aufgaben. macOS und Windows stehen in dessen Aufgabenlisten, nicht in der Task-Bundle-Navigation der Threat-Defense-Edition. Die folgenden App-, Profil- und plattformspezifischen Auswahlwege beziehen sich auf die vollständige Mobile-Edition.

Editionsgrenze für Registrierung und Richtlinien: Die Anweisungen zu Full device, Full MDM und der initialen, moduspassenden Richtlinie gelten hier nur für den dokumentierten Einrichtungsablauf der vollständigen Mobile-Edition. Threat Defense beschreibt für Enroll auf Android und iOS/iPadOS eine Registrierungs-E-Mail und für Assign policy die Auswahl einer Richtlinie, ohne den Full-MDM-Assistenten oder einen iOS-Richtlinientyp-Selektor zu dokumentieren. Diese Unterschiede belegen keine generelle Nichtverfügbarkeit einzelner Steuerelemente in allen Tenants; die tatsächlich angebotenen Optionen vor Ort prüfen.

Wipe: Datenumfang und Wiederaktivierung vorab klären

Destruktive Aufgaben separat freigeben. Android, iOS/iPadOS, macOS und Windows dokumentieren Wipe mit Datenverlust ohne Benutzerbestätigung; Unenroll und Wipe dürfen nicht in dasselbe Paket. Bei iOS/iPadOS setzt die Paketaufgabe das Gerät auf Werkseinstellungen zurück; iOS User Enrollment erlaubt Wipe nicht.

Auf Windows setzt die Paketaufgabe das Gerät ebenfalls auf Werkseinstellungen zurück und löscht alle Daten des jeweiligen Zielgeräts, nicht nur Arbeitsdaten. Windows-Support, Schlüsselverwahrung und sicheren Rückweg gesondert prüfen; nicht aus der alten Aufgabentabelle auf den aktuellen Tenant schliessen.

Die Android-Paketaufgaben-Seite beschreibt für an Android-Enterprise-Arbeitsprofilgeräte übertragene Wipe-Aufgaben nur die Entfernung des Arbeitsprofils und der verwalteten Google-Play-Apps; für andere Android-Geräte beschreibt sie einen Werksreset. Die separate Einzelgeräte-Wipe-Aktion schliesst Arbeitsprofilgeräte dagegen aus. Das sind unterschiedliche Aktionsoberflächen, keine Bestätigung, dass eine Paket-Wipe-Aufgabe im eigenen Tenant/Modus auswählbar ist oder wie sie dort ausgeführt wird. Vor einem Werksreset vollständig verwalteter Android-Geräte gültige FRP-Konten und Zugriff auf deren Zugangsdaten klären.

Vor jeder Erwägung eines Mac-Wipe den aktuellen Sperrstatus des Ziel-Mac prüfen. Die Anleitung zur Einzelgeräteaktion schliesst remote gesperrte Macs aus; die Eignung der Paketaufgabe für diesen Zustand ist damit nicht belegt. Bei Remote-Sperre Wipe nicht einplanen oder übertragen. Zuerst den autorisierten Entsperr-/Wiederherstellungsweg und den tatsächlichen Gerätezustand klären.

Für die Mac-Wipe-Aufgabe wird eine sechsstellige System-Lock-PIN gesetzt; das Gerät startet neu und löscht die Festplatte. Zum Entsperren nach dieser Aufgabe muss der Benutzer diese Wipe-PIN eingeben.

Sophos zeigt die Wipe-PIN unter Device properties > Unlock passcode auf der Geräteseite oder unter Task details > Lock PIN. Wipe-PIN und PIN einer vorherigen Remote-Sperre nach dem jeweiligen Auftrag unterscheiden. Die Kenntnis einer PIN belegt weder, dass der Mac bereits entsperrt ist, noch dass Wipe möglich ist.

Vor Freigabe PIN-Zugriff und sichere Übergabe an Berechtigte klären, nicht durch einen Test-Wipe prüfen.

Unenroll ist kein Wipe, aber ein eigener Verlust der Sophos-Mobile-Registrierung ohne Bestätigung durch den Gerätebenutzer. Dies gilt laut den jeweiligen Paketaufgabenlisten für Android, iOS/iPadOS, macOS, Windows und ChromeOS im vollständigen Mobile-Handbuch sowie für Android, iOS/iPadOS und ChromeOS in Threat Defense. Dass ChromeOS dort keine Wipe-Aufgabe listet, macht Unenroll nicht harmlos. Vor Übertragung oder erneutem Transfer für jedes Zielgerät und die aktuelle Gruppenzugehörigkeit gesondert autorisieren, Auswirkungen auf die Verwaltung prüfen und einen Weg zur erneuten Registrierung festlegen; keine stillschweigende Wiederholung. Den separaten Abmeldeablauf nicht mit der Paketaufgabe gleichsetzen; die modusabhängigen Folgen und den internen Sicherheitsablauf im nächsten Absatz prüfen.

Vor einer Unenroll-Aufgabe die Folgen des konkreten Modus klären. Die Sophos-Abmeldeanleitung verlangt für vollständig verwaltete Android-Enterprise-Geräte einen Werksreset; dabei wird das gesamte Gerät zurückgesetzt. Bei Arbeitsprofilgeräten wird das Profil entfernt und alle Apps und Daten darin werden gelöscht. Im alten Device administrator-Modus dagegen wird der Mobile-Control-Geräteadministrator deaktiviert, werden Server-Zugangsdaten und empfangene Daten entfernt und wird Intercept X for Mobile zurückgesetzt. Bei iPhone/iPad werden Richtlinien, verwaltete Apps und MDM-Zertifikate entfernt und Intercept X zurückgesetzt; bei Macs werden Richtlinien und MDM-Zertifikate entfernt. Diese Folgen gehören zur Freigabe, auch wenn die Aufgabe nicht Wipe heisst. Der separate Sicherheitsablauf für Abmeldung, Datenentfernung und Wiederaktivierung behandelt die dafür nötigen Prüfungen. Aus diesen Einzelgeräteabläufen folgt nicht, dass eine Paketaufgabe Unenroll für jeden Android-Enterprise-Modus auswählbar ist oder selbst automatisch einen Werksreset ausführt. Bei unklarer Eignung nicht übertragen; eine erneute Registrierung stellt gelöschte Daten nicht wieder her.

Paket vorbereiten und Reihenfolge prüfen

1. In Sophos Mobile Task bundles und die passende Plattform wählen, Create task bundle öffnen, Name und optional Beschreibung erfassen. Bei jedem Speichern erhöht sich die Paketversion. Wer ein ähnliches Paket benötigt, kann über das blaue Dreieck Duplicate wählen; die Kopie vor Übertragung erneut auf Ziel, Typen und alte destruktive Schritte prüfen.

2. Mit Add task den passenden Typ hinzufügen und die erforderlichen Angaben für diese Aufgabe eingeben. Parameter und Zielmodus prüfen, dann mit Apply übernehmen. Der Aufgabenname wird im Sophos Fusion Self Service Portal angezeigt, wenn das Aufgabenpaket angewendet wird; das gilt nicht nur für Enroll. Für Enroll gilt stattdessen der folgende Assistentenablauf.

3. Nur vollständige Mobile-Edition: Bei einem Registrierungs-Paket Add task > Enroll öffnen. Der folgende Assistent mit Full device beziehungsweise Full MDM und initialer, moduspassender Richtlinie gehört zu diesem dokumentierten Einrichtungsablauf, nicht zur Threat-Defense-Anleitung:

   • Optional den Namen der Enroll-Aufgabe ändern. Er sollte die Aufgabe für Benutzer verständlich bezeichnen.
   • Den Verwaltungsmodus wählen: Für vollständig verwaltete Android-Enterprise-Geräte Full device, für vollständig verwaltete iPhones und iPads Full MDM auswählen.
   • Auf der nächsten Seite innerhalb dieser Enroll-Aufgabe die initiale Richtlinie wählen, die dem Gerät bei der Registrierung zugewiesen wird. Die Liste zeigt nur Richtlinien, die zum gewählten Verwaltungsmodus passen.
   • Nach der Richtlinienauswahl den Enroll-Assistenten mit Finish abschliessen.

   Erst danach bei Bedarf über Add task > Assign policy zusätzliche Aufgaben für weitere Richtlinien hinzufügen; auch App- und Nachrichtenaufgaben sind optional und plattform-/modusabhängig. Die Pfeile ändern die Installationsreihenfolge.

4. In der vollständigen Mobile-Edition kann Ignore app installation failures bei Android- oder iOS-Paketen die Verarbeitung nach fehlgeschlagener App-Installation fortsetzen; die Option erscheint nur mit Install app oder Install managed Google Play app. Deshalb bewusst entscheiden, ob ein Folgeauftrag trotz fehlender App überhaupt sicher ist. Die Threat-Defense-Erstellseite beschreibt diese Option und Selectable for compliance actions nicht.

Bei Enroll auf Android, iOS/iPadOS, macOS, Windows und ChromeOS geht die Registrierungs-E-Mail an die für das jeweilige Gerät konfigurierte E-Mail-Adresse. Diese Adresse vor der Übertragung prüfen: Für ein neues Gerät ist Benutzeraktion nach den Schritten der E-Mail nötig. An einem bereits registrierten Gerät wird die Registrierungsaufgabe übersprungen.

Compliance-Auswahl ist noch keine Reaktionskonfiguration

Selectable for compliance actions macht ein Paket für Compliance-Reaktionen auswählbar. Die Übertragung bei Nichtkonformität wird in einer Compliance-Richtlinie konfiguriert, nicht allein durch dieses Häkchen. Eine entsprechend konfigurierte Reaktion kann das Paket automatisch an Geräte übertragen, wenn sie nicht konform werden. Enthält es Wipe, kann damit auch die Löschung automatisch ausgelöst werden. Das ist keine harmlose Testoption und keine Empfehlung, Wipe als Standardreaktion zu hinterlegen. Regeln, Zielbereich und Reaktionen gehören in die separate Planung der Compliance-Richtlinie.

Richtlinienaufgaben: Auswahl und stille Wirkung unterscheiden

Auf Android und ChromeOS unter Assign policy die gewünschte Richtlinie wählen; bei iOS/iPadOS in der vollständigen Mobile-Edition zuerst den Richtlinientyp, dann eine Richtlinie dieses Typs. Auf Android, iOS/iPadOS und ChromeOS wird die Richtlinie bei Übertragung still, ohne Benutzeraktion, zugewiesen. Auf Windows unter Assign policy eine Richtlinie aus der Liste der verfügbaren Geräterichtlinien auswählen; bei Übertragung wird sie still zugewiesen und ersetzt eine bestehende Geräterichtlinie. Eine Bestätigung am Gerät deshalb nicht als Freigabeschritt erwarten.

Auf macOS bestimmt der Aufgabentyp die Auswahlliste:

Diese drei Mac-Aufgaben weisen die ausgewählte Richtlinie bei Übertragung still zu und ersetzen jeweils eine bereits zugewiesene Richtlinie desselben Typs. Benutzerrichtlinien werden erst bei der nächsten Anmeldung angewendet. Unter Assign imported policy dagegen ein Apple-Konfigurationsprofil aus den bereits in Sophos Mobile importierten Profilen wählen; das ist eine andere Eingabequelle als die drei nativen Richtlinienlisten.

Für Uninstall policy auf Android und iOS/iPadOS unter Select source > Policies die Richtlinie auswählen. Die Liste enthält sowohl in Sophos Mobile hinzugefügte Richtlinien als auch Richtlinien, die auf irgendeinem verwalteten Gerät installiert sind; ein Listeneintrag allein belegt also nicht die Installation auf dem vorgesehenen Zielgerät. Eine nicht gelistete Richtlinie lässt sich über ihre bekannte Kennung adressieren.

Die Grenzen bleiben dabei bestehen: Android Uninstall policy ist nur verfügbar, wenn in Sophos Mobile der Verwaltungsmodus Device administrator konfiguriert ist, und entfernt nur Android-Geräterichtlinien oder Knox-Container-Richtlinien. Bei iOS Device Enrollment dient Uninstall policy zur Entfernung passender Richtlinien; bei User Enrollment stattdessen Unassign iOS user policy verwenden und dort ebenfalls unter Select source > Policies die Benutzerrichtlinie wählen. Für andere Richtlinientypen die Richtlinie aktualisieren oder eine andere zuweisen, nicht die Deinstallation als pauschale Umkehrung einer Zuweisung voraussetzen.

Sophos dokumentiert unter SMCSRV-13800, dass umbenannte Profile in Aufgaben zur Profilentfernung noch mit ihrem alten Namen angezeigt werden können. Vor der Übertragung die Identität des zur Entfernung vorgesehenen Profils anhand des freigegebenen Inventars und der vorgesehenen Zuweisung prüfen, nicht allein anhand des angezeigten Namens. Bleibt die Zuordnung unklar, das Paket nicht übertragen; Sophos nennt für dieses Anzeigeproblem keinen Workaround.

Davon getrennt nennt die am 6. Oktober 2026 geprüfte Sophos-Known-Issues-Liste SMCSRV-13802: Android-Profile, die mit Duplicate in einer älteren Sophos-Mobile-Version erstellt wurden, lassen sich nicht über ein Aufgabenpaket entfernen. Der Eintrag nennt weder eine genaue betroffene Versionsnummer noch eine Fix-Version und keinen Workaround. Das betrifft diesen Altbestand, nicht jede Profilentfernung. Bei einem passenden Fehlerbild Profilherkunft und Teilschritt dokumentieren und mit dem Sophos-Support den für den eigenen Versionsstand unterstützten Weg klären; nicht durch erneute Paketübertragung oder eine ungeprüfte Ersatzaktion umgehen.

Fehlt eine benötigte Richtlinie in der ChromeOS-Zuweisungsliste, diese zuerst nach dem internen Ablauf für Richtlinienerstellung und direkte Zuweisung anlegen. Danach zur Paketaufgabe zurückkehren und dort die Richtlinie auswählen; nicht die direkte Zuweisung mit der Konfiguration einer Paketaufgabe verwechseln.

App-Aufgaben nach Plattform planen

Android: Verwaltungsmodus und Benutzerentscheidung

Install app ist nur verfügbar, wenn in Sophos Mobile Device administrator als Verwaltungsmodus konfiguriert ist. In der Aufgabe eine App aus der Liste der verfügbaren Apps wählen. Für Android Enterprise ist stattdessen Install managed Google Play app vorgesehen: Dieser Typ ist nur bei konfiguriertem Android Enterprise verfügbar und lässt eine für die Organisation genehmigte verwaltete Google-Play-App auswählen.

Fehlt ein gewöhnlicher App-Eintrag, gehört dessen Erfassung zum App-Katalog und allgemeinen Bereitstellungsablauf. Für Android Enterprise zuerst die vorhandene Organisationsanbindung und Play-Freigabe im Managed-Google-Play-Ablauf prüfen. Dort sind auch die separate Installation über Apps - Android Enterprise und der Play-spezifische Rückzug beschrieben. Die Paketaufgabe erteilt keine Katalogfreigabe; Uninstall app unten ersetzt diesen Play-Rückzugsweg und dessen Allow app uninstall-Prüfung nicht.

Bei Android Uninstall app unter Select source > Apps die Ziel-App wählen. Die Liste enthält in Sophos Mobile hinzugefügte oder auf irgendeinem verwalteten Gerät installierte Apps, aber keine Android-System-Apps oder vom Hersteller vorinstallierten Apps. Für eine nicht gelistete App Identifier wählen und ihren Paketnamen eingeben. Knox container app richtet die Entfernung auf den Samsung-Knox-Container. Die Kennung ist kein belegter Weg, die genannten System-App-Grenzen zu umgehen.

Bei Install app und Uninstall app erhalten Benutzer eine Benachrichtigung am Gerät: OK startet den Vorgang, Not now verschiebt ihn und führt nach kurzer Zeit zu einer erneuten Benachrichtigung. Tippt der Benutzer nach OK im nachfolgenden Android-Dialog auf Cancel, schlägt die jeweilige Aufgabe fehl. Ist die zu deinstallierende App nicht installiert, erscheint keine Benachrichtigung; daraus keinen bestimmten Erfolgsstatus ableiten. Install app kann eine bereits installierte App aktualisieren. App-Stand und Update-Freigabe daher auch vor einem erneuten Transfer prüfen.

iOS/iPadOS: App-Ziel und Enrollment-Grenzen

Unter Install app eine App aus der verfügbaren Liste auswählen. Beim von der Aufgabenhilfe beschriebenen Installationsdialog startet Install den Vorgang; Cancel lehnt ihn ab und die Aufgabe schlägt fehl. Daraus nicht ableiten, dass jeder iOS-Verteilungsmodus immer eine Nachfrage zeigt. Bei bereits installierten Apps kann die Aufgabe ein Update auslösen. Auf Apple User Enrollment kann Install app nur über Apple Business gekaufte Apps installieren.

Vor Uninstall app: Am konkreten iPhone/iPad unter Show device > Installed apps > Managed prüfen, ob die Ziel-App verwaltet ist. Nicht verwaltete Apps lassen sich über Sophos Mobile nicht deinstallieren; bei verwalteten Apps werden mit der Entfernung auch die Daten ihres App-Containers gelöscht. Vor dem Auftrag den Datenverlust-Preflight für iPhone/iPad abschliessen: benötigte Daten, zulässigen Export oder Backup und einen freigegebenen, überprüften Wiederherstellungsweg klären. Solange Verwaltungsstatus oder Datensicherung und Wiederherstellung ungeklärt sind, die Entfernung nicht einplanen oder übertragen.

Für Uninstall app unter Select source > Apps die Ziel-App wählen. Die Liste enthält in Sophos Mobile hinzugefügte oder auf irgendeinem verwalteten Gerät installierte Apps, jedoch keine System-Apps. Nicht gelistete Apps werden über Identifier und ihre Bundle-ID adressiert. Die Aufgabenhilfe beschreibt die Entfernung als still, ohne Bestätigung am Gerät; daraus folgt keine allgemeine Zusage für jeden Verwaltungsmodus. Die allgemeine Dokumentation zu verwalteten iOS/iPadOS-Apps beschreibt dieses Verhalten ausdrücklich für betreute (supervised) Geräte. Vor dem freigegebenen Änderungsauftrag den tatsächlichen Verwaltungs- und Betreuungsstatus sowie das erwartete Bestätigungsverhalten klären; weder universelle Stille noch eine generelle Nachfrage auf nicht betreuten Geräten voraussetzen. App-Ziel und Berechtigung auch bei wiederholtem Transfer vorab prüfen; eine etwaige Gerätebestätigung ersetzt die Freigabe nicht. Die Listenbegrenzung belegt keinen alternativen Weg zur System-App-Entfernung.

macOS: Installation und Lizenzentzug sind verschiedene Aufträge

Unter Install app eine App aus der verfügbaren Liste wählen; die Installation erfolgt bei Übertragung still. Enthält eine PKG-Datei mehrere Apps, werden alle enthaltenen Apps installiert. Vor Freigabe daher den Paketinhalt prüfen, nicht nur den angezeigten App-Namen. Der Status Successful belegt dennoch zunächst nur den begonnenen Download; die Prüfung des Installationsergebnisses folgt unten.

Unter Unassign VPP app die Ziel-App aus der Liste der verfügbaren Apple-Business-Apps auswählen. Die Aufgabe entfernt eine zugewiesene Apple-Business-App-Lizenz vom Gerät; der Benutzer kann die App dennoch noch 30 Tage weiterverwenden. Vor dem Auftrag pro Mac die konkrete App und Lizenzzuweisung prüfen und spätere Nutzbarkeit nicht als fortbestehende Lizenz werten.

Windows: Sichtbarkeit in der Liste ist keine Deinstallationsberechtigung

Unter Install app eine App aus der Liste der verfügbaren Apps auswählen; bei Übertragung wird sie still installiert und eine bereits installierte App aktualisiert. Auch unter Uninstall app die Ziel-App aus der Liste der verfügbaren Apps auswählen; die ältere Aufgabenliste beschreibt die Entfernung als still. Die neuere allgemeine Apps-Deinstallationsanleitung knüpft die stille Entfernung unter Windows dagegen an die für die App konfigurierte Installationsoption /quiet. Damit ist nicht belegt, dass die Paketaufgabe diese Bedingung umgeht oder in jedem Tenant identisch arbeitet. Vor der Annahme einer unbeaufsichtigten Entfernung die dokumentierten Installationsoptionen der konkreten App und das Verhalten im tatsächlichen Tenant/Modus im Rahmen der Änderungsfreigabe klären; /quiet nicht blind bei einem unbekannten Installer ergänzen. Die Deinstallationsliste enthält in Sophos Mobile hinzugefügte Apps sowie Apps auf irgendeinem verwalteten Windows-Computer, aber keine Windows-System-Apps. Entfernt werden können nur von Sophos Mobile installierte Apps; bei einer vom Benutzer installierten App schlägt die Aufgabe fehl. Listenherkunft, Installationsherkunft und autorisiertes Ziel vor Übertragung oder Wiederholung getrennt prüfen.

Diese App-Aufgaben der vollständigen Mobile-Edition sind nicht aus den Task-Listen der Threat-Defense-Edition ableitbar.

iOS/iPadOS: Profile, SMC-Verbindung und OS-Update

Für Install provisioning profile ein App-Provisioning-Profil aus der verfügbaren Liste auswählen; bei Übertragung wird es still installiert. Fehlt das Profil, zuerst den Import eines App-Provisioning-Profils vorbereiten und durchführen. Vor einer Entfernung auch die dort beschriebenen Auswirkungen auf Apps und Daten sowie die Prüfungen unter Pilotkontrolle und Rückweg klären.

Unter Uninstall provisioning profile mit Select source > Profiles das Profil wählen. Die Liste enthält hinzugefügte Profile und Profile, die auf irgendeinem verwalteten Gerät installiert sind. Ein nicht gelistetes Profil über Identifier und seine Profilkennung adressieren. Auch die Entfernung erfolgt still. Beide Aufgaben sind bei User Enrollment nicht verfügbar; die Prüfung von Profilidentität und Zielgerät bleibt vor der Entfernung erforderlich.

Reconfigure SMC app verbindet Sophos Mobile Control nach versehentlicher Deinstallation wieder mit Sophos Mobile. Der Benutzer muss dafür einen QR-Code scannen oder die Konfigurationsdetails manuell eingeben. Diese Angaben findet die Administration auf Show device > Tasks über das Show-Symbol der betreffenden Aufgabe. Sophos empfiehlt, Install app für Sophos Mobile Control im Paket vor Reconfigure SMC app anzuordnen, damit die App verfügbar ist. Die Neukonfiguration ist bei User Enrollment nicht verfügbar; sie ist kein allgemeiner Synchronisierungs-Fix.

Install latest iOS update gilt nur für betreute (supervised) oder Apple-Business-Geräte und ist für User Enrollment nicht verfügbar; bei anderen Geräten schlägt die Aufgabe fehl. Je nach Gerätemodell können unterschiedliche Updates installiert werden. Für die Abnahme deshalb das Ergebnis pro Modell prüfen, statt eine einheitliche Versionsnummer für das ganze Paket vorauszusetzen.

ChromeOS und Nachrichten

Das vollständige Sophos-Mobile-Handbuch listet für ChromeOS-Pakete Enroll, Assign policy, Send message und Unenroll. Diese konkrete Liste enthält weder Wipe noch eine App-Installationsaufgabe; daraus keine pauschale Aussage über andere Aktionsoberflächen oder die Verfügbarkeit im eigenen Tenant ableiten.

Send message auf Android, iOS/iPadOS und ChromeOS nimmt einfachen Text entgegen. Bei Übertragung erscheint der Nachrichtentext in einem Benachrichtigungsfenster. Frühere Nachrichten können Benutzer auf Android und iOS/iPadOS in der Threat-Defense-Edition in Sophos Intercept X for Mobile, in der vollständigen Mobile-Edition in Sophos Mobile Control anzeigen. Auf ChromeOS stehen sie in der Erweiterung Sophos Chrome Security zur Verfügung. Eine versandte Nachricht ist weder eine Lesebestätigung noch ein Nachweis für eine angewendete Richtlinie.

Nachricht im Registrierungs-Paket: Die am 6. Oktober 2026 geprüfte Known-Issues-Liste nennt unter SMCSRV-13893 einen möglichen Fehler von Send message innerhalb eines Enrollment-Aufgabenpakets: Benötigt das Gerät zu lange, um APNS-/FCM-Informationen an das Backend zu senden, kann die Nachrichtenaufgabe wegen fehlender Informationen scheitern. Der Eintrag nennt keine genaue betroffene Version oder Fix-Version und derzeit keinen Workaround. Das ist keine Aussage, dass jede Nachricht oder die gesamte Registrierung fehlschlägt. Bei diesem Fehler zuerst den tatsächlichen Registrierungs- und Aufgabenstatus prüfen und das konkrete Fehlerbild mit dem Sophos-Support klären, statt das ganze Paket erneut zu übertragen. Beide Hinweise sind auf den genannten Dokumentationsstand und das jeweilige Fehlerbild begrenzt; vor einem späteren Einsatz den aktuellen Known-Issues-Stand für den eigenen Versionsstand prüfen.

Übertragung und beobachtbare Ergebnisse

Vor der Übertragung Geräte einzeln oder Gerätegruppen inklusive aktueller Mitgliedschaft und Betriebsfenster abgleichen. Der dokumentierte Transferablauf nennt Android und iOS & iPadOS:

1. Unter Task bundles > Android beziehungsweise iOS & iPadOS das Paketdreieck öffnen und Transfer wählen.
2. In der Geräteauswahl einzelne Geräte markieren oder Select device groups öffnen und auf der Gruppenauswahl eine oder mehrere Gerätegruppen auswählen. Aktuelle Mitglieder gegen die freigegebene Zielmenge prüfen, dann Next wählen.
3. Now für die sofortige Ausführung wählen oder nach Date den Ausführungstag und die Uhrzeit eingeben. Die Angaben vor Finish mit dem Betriebsfenster abgleichen.
4. Mit Finish abschliessen. Das Paket wird zum angegebenen Zeitpunkt an die ausgewählten Geräte übertragen; damit ist seine Wirkung noch nicht nachgewiesen.

Nicht behaupten, dass die Anleitung diese Menüfolge gleichermassen für Mac/Windows/ChromeOS belegt; die plattformbezogene Verfügbarkeit ist separat zu prüfen.

Aufgabenstatus ≠ Geräteergebnis: Eine Android-Enterprise-Google-Play-Installation erscheint als erfolgreich, sobald der Auftrag an Google gesendet wurde, nicht erst nach nachgewiesener Installation. Eine macOS-App-Aufgabe mit Status Successful bedeutet laut Sophos zunächst, dass der Download begonnen hat; zur Installation Gerät synchronisieren und installierte Apps in den Gerätedetails prüfen. Eine Richtlinie und deren Wirkung ebenfalls getrennt kontrollieren; ein übersprungener, nicht unterstützter Auftrag ist keine erfolgreiche Ausführung.

Für die Android-App-Abnahme das konkrete Zielgerät unter Show device > Installed apps prüfen und die tatsächliche Installation am Gerät kontrollieren. Bei Android Enterprise zeigt Apps pending installation den Stand Installation request to be sent to Google beziehungsweise Installation request sent to Google; nach Googles Installation wird der Eintrag nach Installed apps verschoben. Bleibt der erste Stand bestehen, Länder- und Gerätetypverfügbarkeit der App prüfen; bleibt der zweite bestehen, am Gerät in Google Play Pending downloads auf einen blockierenden Auftrag prüfen. Die eigene Installation beginnt erst nach den darüber stehenden Downloads. Diese Statusbeschreibung stammt vom direkten Play-Installationsablauf und belegt keine zusätzlichen Paket-Statusnamen. Ist Installed apps durch Datenschutzeinstellungen verborgen, ist die fehlende Ansicht kein Nachweis einer fehlenden Installation; die autorisierte Geräteprüfung beziehungsweise den App-Verantwortlichen einbeziehen, ohne die Datenschutzeinstellung als Diagnosetest zu ändern.

Fehler eingrenzen, nicht das ganze Paket blind erneut ausführen

Unter Tasks Status und Task details je Zielgerät lesen: Zeitpunkte, Fehlercodes und gegebenenfalls Details für einzelne Befehle sichern. Delayed wartet auf andere Aufgaben; Not started bezeichnet einen noch nicht abgearbeiteten Paketteilschritt, Skipped einen auf dem Gerät nicht unterstützten Schritt, Task partly failed nur teilweise erfolgreiche Befehle.

Will be retried betrifft laut Statustabelle Verbindungsprobleme zu Drittservern; Sophos versucht alle drei Minuten erneut und markiert die Aufgabe nach fünf Versuchen (insgesamt 15 Minuten) als fehlgeschlagen. Failed (retry queued) und Task failed sind nicht dasselbe; Completely failed ist nicht wiederholbar. Bei Waiting for user interaction schlägt die Aufgabe nach 72 Stunden ohne Benutzerreaktion fehl; bei Device is locked wartet sie darauf, dass das iOS-Gerät entsperrt wird, und schlägt nach 72 Stunden ohne Entsperren fehl. Davon getrennt gelten für die Bestätigung unter Commands sent und die Erfolgsmeldung unter Result evaluation started jeweils 15 Minuten. Diese Statusangaben sind dokumentierte Produktsemantik, kein Beleg eines Tests im eigenen Tenant.

Vor jeder manuellen Wiederholung pro Gerät klären, welche Schritte bereits wirksam wurden und welche noch automatisch erneut versucht werden. Die Ursache am fehlgeschlagenen Teilschritt eingrenzen und beheben. Eine automatische Rückabwicklung aller Paketaufgaben ist in den ausgewerteten offiziellen Anleitungen nicht belegt; bei Unenroll/Wipe keine Wiederholung als Fehlerdiagnose.

Für den betroffenen Auftrag die passende Vorprüfung durchführen. Bei Richtlinien den Richtlinientyp und Verwaltungsmodus prüfen, statt Uninstall policy als pauschale Rücknahme zu verwenden. Bestehende Mac-/Windows-Richtlinien nicht unbemerkt ersetzen. Bei Android-/iOS-Apps sowie Windows Install app App-Stand und Update-Freigabe prüfen, damit bereits installierte Apps nicht unbeabsichtigt aktualisiert werden. Deinstallierte Apps und entfernte Profile bei der Entscheidung über einen erneuten Transfer berücksichtigen. Auf dem Mac die VPP-Lizenzzuweisung kontrollieren, nicht bloss die weiterhin nutzbare App. Auf iOS/iPadOS App-Entfernung nur für das autorisierte Ziel zulassen und Verwaltungs-/Betreuungsstatus sowie erwartetes Bestätigungsverhalten gemäss den oben genannten Grenzen prüfen.

Nur einen gesondert freigegebenen, sicher erneut ausführbaren Schritt gezielt planen. Bei Unenroll für jedes Zielgerät die Abmeldung und den Weg zur erneuten Registrierung ausdrücklich neu freigeben; keine Benutzerbestätigung erwarten. Nach der Ausführung Gerätestatus und tatsächlichen Effekt getrennt verifizieren.

Die weiterführende Aufgaben- und Synchronisierungsdiagnose gehört zum separaten Monitoring-Ablauf.