SEO-Feld	Wert
Titel	Workspace ONE Launcher startet nicht: COPE vs. COSU – der Enrollment-Modus als Ursache
Meta Description	WS1 Launcher meldet „not set as the home app“? Warum COPE-Enrollment den Kiosk-Modus blockiert und wie ihr Android-Geräte korrekt als Device Owner (Fully Managed) bereitstellt.
Focus Keyword	Workspace ONE Launcher COPE
Slug	workspace-one-launcher-cope-cosu-troubleshooting
Kategorie	Workspace ONE / Android Enterprise
Tags	Workspace ONE, Launcher, COSU, COPE, Android Enterprise, Kiosk, Knox Mobile Enrollment, Troubleshooting
Lesedauer	ca. 8 Minuten

Workspace ONE Launcher startet nicht: Wenn COPE den Kiosk-Modus blockiert

TL;DR Der Workspace ONE Launcher setzt zwingend den Enrollment-Modus Work Managed (Device Owner / Fully Managed) voraus. Auf Geräten im Modus COPE / Work Profile on Company-Owned (WPCO) kann er sich nicht als Home-App setzen – ab Android 11 hat das MDM dort schlicht keinen Zugriff auf die persönliche Geräteseite. Die Fehlermeldung „Launcher is not set as the home app or is not installed“ in den Device Details ist deshalb ein Frühindikator: Erst den Enrollment-Modus prüfen, bevor ihr euch in OG-, Profil- und Smart-Group-Diagnose verrennt. Der Wechsel von COPE zu Work Managed erfordert einen Factory Reset und ein Re-Enrollment als Device Owner (z. B. via Knox Mobile Enrollment, QR-Code oder Zero Touch).

Kennt ihr das? Das Launcher-Profil ist sauber gebaut, die Smart Group passt, das Profil steht in der Konsole auf Assigned – und trotzdem bleibt das Gerät stur beim System-Launcher. In den Device Details prangt die Meldung „Launcher is not set as the home app or is not installed“. Genau diesen Fall hatte ich kürzlich bei einem COSU-Rollout mit Samsung-Geräten auf dem Tisch – und die Ursache steckte am Ende nicht im Profil, sondern eine Ebene tiefer: im Enrollment-Modus.

In diesem Beitrag zeige ich euch, warum der Workspace ONE Launcher auf COPE-Geräten prinzipbedingt nicht funktionieren kann, wie ihr das Problem in unter einer Minute diagnostiziert und wie der saubere Weg zum Device-Owner-Enrollment aussieht.

Das Symptom

Der Rollout-Plan: dedizierte Android-Geräte (COSU), Multi-App-Kiosk über den Workspace ONE Launcher, Staging über einen Staging-User in einer eigenen Organization Group. Die Realität nach dem Enrollment:

• Der Launcher installiert sich nicht – der seeded Auto-Install springt nie an.
• Device Details melden: „Launcher is not set as the home app or is not installed“.
• Je nach Grouping-Konfiguration wandert das Gerät beim User-Login zusätzlich in die falsche OG – ein Nebenschauplatz, der die eigentliche Ursache zunächst verschleiert.

Der entscheidende Blick: Device Details → Enrollment. Dort stand nicht Work Managed, sondern Corporate Owned Personally Enabled (COPE) – im konkreten Fall via Knox provisioniert. Damit war der Fall klar.

Grundlagen: Android Enterprise Management-Modi im Überblick

Zur Einordnung die vier relevanten Modi und ihre Eignung für den Launcher:

Modus	Ownership	MDM-Kontrolle	WS1 Launcher
Work Managed (COBO / Device Owner)	Corporate	Gesamtes Gerät	Ja – Voraussetzung
COSU (Dedicated Device / Kiosk)	Corporate	Gesamtes Gerät (Work Managed + Lockdown)	Ja – Kernszenario
COPE / WPCO (Work Profile on Company-Owned)	Corporate	Ab Android 11: nur Work Profile + gerätweite Policies	Nein
Work Profile (BYOD)	Personal	Nur Work Profile	Nein

Wichtig für das Verständnis: COSU ist kein eigener Enrollment-Modus, sondern ein Work-Managed-Gerät mit Kiosk-Lockdown (Launcher-Profil, Lock Task Mode). Die Basis muss also immer Device Owner sein.

Warum der Launcher auf COPE nicht laufen kann

Seit Android 11 hat Google den COPE-Modus grundlegend umgebaut („Work Profile on Company-Owned Devices“, kurz WPCO). Der Intelligent Hub installiert sich dabei nur noch innerhalb des Work-Profile-Containers und verwaltet ausschließlich diesen. Die persönliche Geräteseite – inklusive Home-Screen, Default-Apps und persönlichem Play Store – ist für das MDM aus Datenschutzgründen tabu.

Der Workspace ONE Launcher ist aber genau das: ein Home-Screen-Replacement auf Geräteebene. Er muss sich als Default-Home-App des Gerätes registrieren – und genau dieser Zugriff ist im COPE-Modus technisch nicht möglich. Das ist kein Bug und keine Fehlkonfiguration, sondern by design.

Dazu kommt: Der komfortable seeded Auto-Install des Launchers wird nur ausgelöst, wenn ein Launcher-Profil einem Fully-Managed-Gerät zugewiesen wird oder ein Fully-Managed-Gerät über einen Staging-User enrolled ist. COPE erfüllt keine der beiden Bedingungen – der Launcher wird also nicht einmal installiert, geschweige denn als Home gesetzt.

Achtung: Weitere COSU-Bausteine, die auf COPE wegbrechen Single-User- und Multi-User-Staging werden für COPE-Enrollments nicht unterstützt. Der klassische COSU-Staging-Flow (Staging-User → Gerät → OG) ist auf COPE damit von vornherein nicht lauffähig. Product Provisioning wird auf COPE ebenfalls nicht unterstützt – auch der Fallback „Launcher-APK per Product Provisioning ausrollen“ scheidet aus. Fazit: Auf COPE bekommt ihr den Launcher-Kiosk grundsätzlich nicht zum Laufen – egal wie sauber Profil, OG-Struktur und Smart Groups sind.

Diagnose in unter einer Minute

1. Device Details → Enrollment öffnen: Steht dort Work Managed oder Corporate Owned Personally Enabled? Bei COPE: Ursache gefunden, weiter zu Schritt 4.
2. Falls Work Managed: Device Details → Profiles prüfen – steht das Launcher-Profil auf Installed oder hängt es auf Pending? Bei Pending liegt das Gerät vermutlich außerhalb des Profil-Scopes (OG / Smart Group) oder es gibt ein Kommunikationsproblem.
3. OG-Standort und Smart-Group-Zuweisung verifizieren: Für COSU empfiehlt sich eine geräte-basierte Smart Group (Ownership = Corporate, Platform = Android, Enrollment = Work Managed), keine user-gebundene Zuweisung – Staging-Geräte matchen sonst nicht.
4. Bei COPE: Re-Enrollment als Device Owner planen (nächster Abschnitt). Ein In-Place-Wechsel des Modus ist nicht möglich.

Die Lösung: Re-Enrollment als Device Owner

Der Wechsel von COPE zu Work Managed ist kein Schalter, sondern ein Neu-Enrollment ab Werkszustand:

1. COPE-Toggle in der Ziel-OG prüfen: In den Android-Enrollment-Einstellungen der OG gibt es die Option, die beim Enrollment COPE statt Fully Managed erzwingt. Für die Kiosk-OG muss diese aus sein – idealerweise legt ihr eine dedizierte Fully-Managed-OG für COSU-Geräte an.
2. Provisionierungsprofil korrigieren: Bei Samsung-Geräten über Knox Mobile Enrollment (KME) sicherstellen, dass das KME-Profil das Gerät als Device Owner provisioniert – nicht als Work Profile on Company-Owned. Gleiches gilt für QR-Code- und Zero-Touch-Konfigurationen.
3. Factory Reset durchführen und das Gerät via KME / QR / Zero Touch neu enrollen.
4. Verifizieren: Device Details → Enrollment = Work Managed. Erst dann greifen seeded Launcher-Install, Staging-User-Flow und COSU-Lockdown.

Für QR-Code-Provisionierung als Device Owner sieht der relevante Payload-Kern so aus (Hub als Device Owner, Enrollment direkt in die COSU-OG über die Group ID):

{ „android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_NAME“: „com.airwatch.androidagent“, „android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME“: „com.airwatch.androidagent/.agent.AdminReceiver“, „android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM“: „<Checksum von Omnissa>“, „android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION“: „https://getalp.omnissa.com/product/workspace-one/hub“, „com.airwatch.enrollment.server“: „https://<tenant>.awmdm.com“, „com.airwatch.enrollment.gid“: „<COSU-Gruppen-ID>“, „com.airwatch.enrollment.uid“: „<Staging-User>“ }

Info: Grouping-Einstellungen für den Staging-Flow Damit COSU-Geräte nach dem Enrollment in ihrer Staging-/Kiosk-OG bleiben, sollte die OG-Zuordnung aus der Group ID des Enrollments kommen und nicht dem anmeldenden User folgen. Prüft dazu die Grouping-Einstellungen unter Gruppen & Einstellungen → Alle Einstellungen → Geräte & Benutzer → Allgemein → Enrollment → Gruppierung. Folgt die OG dem User und hat dieser keine Zuordnung, landet das Gerät in der Root-OG – und fällt aus dem Profil-Scope.

Zwei Launcher-Payload-Einstellungen für den Praxisbetrieb

Wenn das Enrollment stimmt, lohnt ein zweiter Blick in den Launcher-Payload – zwei Parameter fallen im COSU-Betrieb gerne auf die Füße:

Parameter	Empfehlung COSU	Warum
AllowLaunchOnReboot	True	Sonst startet der Launcher nach einem Reboot nicht automatisch als Home-App – für einen unbeaufsichtigten Kiosk ein No-Go.
AllowStagingActivities	Beim Debugging: True	Kann Provisioning-Aktivitäten blockieren, wenn der Launcher-Lockdown zu früh übernimmt.

Lessons Learned

• Die Meldung „Launcher is not set as the home app or is not installed“ auf einem Corporate-Gerät ist ein Frühindikator für den falschen Enrollment-Modus. Erst den Modus prüfen, dann Profile und OGs.
• COPE und COSU schließen sich gegenseitig aus: Wer private Nutzung erlaubt (COPE), kann das Gerät nicht gleichzeitig in einen Kiosk sperren. Ein „Kiosk mit privater Seite“ ist ein Widerspruch in sich.
• Provisionierungsprofile (KME, QR, Zero Touch) und OG-Einstellungen müssen zusammenpassen: Ein einziger COPE-Toggle in der falschen OG macht aus dem geplanten Fully-Managed-Rollout unbemerkt einen COPE-Rollout.
• Launcher-Profile für COSU immer an geräte-basierte Smart Groups hängen – user-gebundene Zuweisungen matchen Staging-Geräte nicht.

Wie handhabt ihr das in euren Umgebungen: Trennt ihr COPE- und COSU-Geräte konsequent über dedizierte Organization Groups, oder steuert ihr die Modi zentral über die Provisionierungsprofile? Schreibt es mir in die Kommentare!

#WorkspaceONE #Omnissa #AndroidEnterprise #COSU #COPE #Launcher #MDM #UEM #Kiosk #KnoxMobileEnrollment

lajdych.com – MDM aus der Praxis | Thorsten Lajdych