Schlagwort: ModernWorkplace

iOS 26: MDM-Migration ohne Factory Reset – Apple beendet den Vendor Lock-in

iOS 26: MDM-Migration ohne Factory Reset – Apple beendet den Vendor Lock-in

Apple löst eines der lästigsten Probleme in der Apple-Enterprise-Welt: Mit iOS/iPadOS/macOS 26 könnt ihr eure Geräte direkt im Apple Business Manager zwischen MDM-Lösungen verschieben – ohne Wipe, ohne Nachtschicht, ohne Drama. Fast.

Ab iOS/iPadOS/macOS 26 könnt ihr ADE-enrolled Corporate Devices direkt im ABM einem neuen MDM zuweisen – kein Factory Reset nötig. Ihr setzt eine Deadline, der User bekommt eine Notification, das Gerät enrollt sich neu. Persönliche Daten bleiben erhalten. Managed Apps auf iPhone/iPad werden entfernt und müssen vom neuen MDM neu ausgerollt werden. VPP-Lizenzen wandern nicht automatisch. Vorbereitung ist trotzdem Pflicht.

Was ist neu – und stimmt das wirklich?

In den letzten Wochen macht ein LinkedIn-Post die Runde, der das neue Feature von iOS 26 beschreibt. Kaum gelesen, weckte dieser Post mein Interesse.

Im Kern stimmt er – aber ein paar Details sind ungenau oder fehlen komplett. Ich hab das Ganze gegen die offizielle Apple-Dokumentation, Microsoft Intune Docs und mehrere MDM-Hersteller-Guides gecheckt. Hier kommt der vollständige Faktencheck.

Abb. 1: MDM-Migration bisher vs. ab iOS/iPadOS/macOS 26

Was stimmt (korrekte Claims im Umlauf)

  • MDM-Migration ohne Factory Reset für iOS/iPadOS/macOS 26 – korrekt
  • Steuerung komplett über Apple Business Manager – korrekt
  • Deadline-Feature mit automatischem Erzwingen – korrekt
  • User-Notifications mit steigender Häufigkeit – korrekt
  • Persönliche Daten bleiben auf dem Gerät – korrekt
Was fehlt oder ist ungenau (wichtige Details)

  • „Ohne Datenverlust“ ist nuanciert: Persönliche Daten bleiben, aber MDM-verwaltete Apps werden auf iPhone/iPad beim Unenrollment entfernt – außer das neue MDM liefert sie via await_device_configured rechtzeitig nach.
  • Nur für ADE-enrolled Corporate Devices: BYOD-Geräte sind komplett ausgeschlossen. Shared iPad und Apple Business Essentials ebenfalls nicht unterstützt.
  • Einmaliger Reset bei alten ABM-Einschreibungen: Geräte, die ursprünglich mit iOS < 26 in ABM eingeschrieben wurden, benötigen EINMALIG einen Reset zur Re-Registrierung. Danach nie wieder.
  • VPP-Lizenzen migrieren nicht automatisch: Der Apps & Books Content Token muss manuell aus dem alten MDM entfernt und im neuen registriert werden.
  • Vorbereitung ist Pflicht: Konfigurationsprofile, Compliance-Policies, Scripts und App-Deployments müssen im neuen MDM vorab nachgebaut werden.

Wie funktioniert das technisch?

Apple hat den nativen MDM-Protokoll-Stack erweitert. Der ABM koordiniert jetzt aktiv den Wechsel zwischen zwei MDM-Servern und kommuniziert gleichzeitig mit beiden. Das Gerät wird vom alten MDM unenrollt und enrollt sich direkt in das neue – alles gesteuert durch das OS, ohne manuellen Eingriff.

Technisch relevant: Das Feature basiert auf Declarative Device Management (DDM). Die Logik läuft direkt auf dem Gerät, wodurch die Abhängigkeit vom MDM-Server reduziert wird. Apple rotiert dabei automatisch sicherheitsrelevante Keys – z.B. den FileVault Personal Recovery Key auf macOS.

Was bleibt auf dem Gerät, was wird entfernt?
Was iPhone/iPad Mac
Persönliche Daten Bleiben vollständig erhalten Bleiben vollständig erhalten
MDM-Konfigurationsprofile Werden entfernt Werden entfernt
Managed Apps (MDM-deployed) Werden entfernt (*) Bleiben ggf. erhalten
App-Daten (bei Preservation) Bleiben bei korrektem Setup Bleiben bei korrektem Setup
VPP-Lizenzen Manuell migrieren! Manuell migrieren!
Activation Lock / Bypass Code Wird vom neuen MDM neu erstellt Wird vom neuen MDM neu erstellt
FileVault Key (macOS) N/A Wird automatisch rotiert

(*) Managed Apps können bei korrektem Setup preserviert werden: Das neue MDM muss die Apps per await_device_configured installieren, bevor DeviceConfigured gesendet wird. Declarative Managed Apps werden immer behalten.

Voraussetzungen

Bevor ihr loslegt, müssen folgende Punkte erfüllt sein:

Abb. 2: Voraussetzungen auf einen Blick

  • Gerät läuft auf iOS 26, iPadOS 26 oder macOS 26
  • Gerät ist per Automated Device Enrollment (ADE) enrolled – kein User Enrollment, kein BYOD
  • Gerät ist in Apple Business Manager (ABM) oder Apple School Manager (ASM) erfasst
  • Neues MDM ist als MDM-Server in ABM konfiguriert (Token-Austausch abgeschlossen)
  • APNs-Zertifikat im neuen MDM ist aktiv
  • VPP/Apps & Books Token für das neue MDM ist eingerichtet (falls Apps per VPP deployt werden)
  • Neues MDM ist vollständig vorbereitet: Profile, Policies, Apps und Scripts nachgebaut
Einschränkungen

  • Nicht unterstützt: Apple Business Essentials, Shared iPad, BYOD-Geräte
  • Return to Service mit App Preservation (is_return_to_service = TRUE) blockiert die Migration
  • Geräte offline nach Unenrollment: User wird zur WLAN-Auswahl geleitet, bis Migration abgeschlossen
  • Bei VPP-Apps: Deadline nicht größer als 30 Tage setzen

How-to: MDM-Migration mit iOS 26 – Schritt für Schritt

Phase 1: Vorbereitung (vor dem ersten Klick in ABM)

Die Migration selbst dauert Minuten – aber die Vorbereitung entscheidet über Erfolg oder Chaos. Hier solltet ihr keine Abkürzungen nehmen.

# Aufgabe Prio
Vollständiges Inventar aller Geräte exportieren – Seriennummern, OS-Version, Enrollment-Status Pflicht
Alle Konfigurationsprofile dokumentieren: Wi-Fi, VPN, Zertifikate, Restrictions, E-Mail Pflicht
Compliance-Policies, Security-Baselines und Scripts erfassen Pflicht
App-Deployment dokumentieren: Welche Apps, VPP oder direkt, welche Managed Configs Pflicht
Neues MDM vollständig konfigurieren: APNs, ABM-Token, Enrollment Profile, alle Profile nachbauen Pflicht
VPP Content Token: Aus altem MDM entfernen, neues Token im neuen MDM registrieren Kritisch
Pilot-Gruppe definieren (5–10 Geräte) für Testlauf vor Massenrollout Empfohlen
User-Kommunikation vorbereiten: Was passiert, wann, was müssen User tun Empfohlen

Phase 2: Migration in ABM starten

  1. Anmelden bei business.apple.com als Administrator oder Device Enrollment Manager
  2. Im Seitenmenü auf ‚Devices‘ gehen
  3. Geräte suchen und auswählen (Seriennummer, Order-Nummer oder Filter ‚Eligible Devices‘ nutzen)
  4. Auf das Gerät klicken → ‚…‘ (Ellipsis-Menü) oder ‚Edit‘ → ‚Assign Device Management‘
  5. Neuen MDM-Server auswählen
  6. ‚Add Deadline‘ klicken und Datum/Uhrzeit setzen (kein Deadline = kein automatisches Erzwingen)
  7. ‚Continue‘ → Prompt lesen → ‚Confirm‘

Hinweis: Ohne Deadline kein Zwang!

Wenn ihr keine Deadline setzt, migriert das Gerät nur bei einem nächsten Erase oder wenn ihr manuell den profiles-Befehl ausführt. Für einen kontrollierten Rollout immer Deadline setzen.

Troubleshooting: „Add Deadline“ nicht verfügbar

Wenn der „Add Deadline“-Button im ABM ausgegraut ist oder gar nicht erscheint, liegt das fast immer an einem der folgenden drei Gründe:

Problem Ursache Lösung
OS < iOS/iPadOS/macOS 26 ABM zeigt die Option erst ab iOS 26 an – das Feature ist OS-seitig implementiert Gerät auf iOS 26 updaten, dann erneut in ABM prüfen
Gerät nur „Assigned“, nicht „Enrolled“ Migration setzt aktives, laufendes Enrollment voraus – „Assigned“ allein reicht nicht Gerät normal enrollen, dann Migration starten
Gerät im Status „Pending“ Gerät frisch ausgepackt oder noch im Setup Assistant – Enrollment-Flow noch nicht abgeschlossen Setup abschließen und einmalig enrollen, dann Option prüfen
Enrolled, aber Option fehlt trotzdem Letzter Check-in zu weit zurück oder MDM-Push ausstehend Force Check-in über MDM senden, ABM-Seite neu laden
Quelle = „Apple Configurator“ Gerät wurde manuell über Configurator 2 in ABM eingebracht – nicht über Reseller/DEP Siehe nächster Abschnitt
Schnellcheck: Enrolled vs. Assigned

Den Enrollment-Status „Enrolled“ bzw. „Assigned“ findet ihr nicht in ABM, sondern im jeweiligen MDM (z.B. Intune: Geräte → Gerät auswählen → Übersicht). ABM zeigt unter „Geräteverwaltungsdienst“ nur den zugewiesenen MDM-Server – keinen separaten Enrolled/Assigned-Status.

Was ihr direkt in ABM prüfen solltet: das Feld „Quelle“ unter Details. Steht dort „Apple Configurator“ → siehe nächster Abschnitt. Steht dort „Apple“ oder ein Reseller-Name → Migration sollte funktionieren, sofern das Gerät auf iOS 26 läuft und aktiv enrolled ist.

Sonderfall: Quelle „Apple Configurator“ – Migration nicht möglich

Wenn im ABM-Gerätedetail unter „Quelle“ der Wert „Apple Configurator“ steht, wurde das Gerät manuell über Apple Configurator 2 in ABM eingebracht – und nicht automatisch über den Kaufprozess via Reseller oder direkt bei Apple. Die Quelle ist fest gesetzt und lässt sich nachträglich nicht ändern. Die Option „Add Deadline“ erscheint für diese Geräte nicht.

Optionen und Lösungswege

Option 1 – Einmaliger Reset auf iOS 26 (empfohlen): Factory Reset des Geräts auf iOS 26. Beim Neuaufsetzen enrollt es sich sauber im ADE-Flow. Danach funktioniert die nahtlose MDM-Migration – dauerhaft, ohne weiteren Reset. Der einmalige Wipe ist der „Eintrittsbonus“ für den neuen Mechanismus.

Option 2 – Aus ABM entfernen und neu hinzufügen: über Configurator 2 möglich, ändert aber nichts – die Quelle bleibt „Apple Configurator“. Für dieses Problem kein sinnvoller Weg.

Option 3 – Für neue Geräte: Geräte künftig direkt über einen Apple Authorized Reseller oder Apple selbst kaufen. Diese landen automatisch mit Quelle „Apple“ bzw. Reseller-Name in ABM und sind von Anfang an für die nahtlose Migration geeignet.

Phase 3: User-Experience und Monitoring

Was der User sieht, hängt vom Zeitpunkt ab:

Abb. 3: Notification-Verhalten je nach Zeitpunkt bis zur Deadline

Zeitpunkt Notification-Verhalten
Deadline gesetzt Tägliche Benachrichtigung
24h vor Deadline Stündliche Benachrichtigung
Letzte Stunde Benachrichtigung alle 60, 30, 10 und 1 Minute(n)
Deadline erreicht Nicht-wegklickbarer Vollbild-Dialog, Enrollment wird erzwungen
Wann erscheint die erste Notification? Kann man das beschleunigen?

Die initiale Notification erscheint bei einem online Gerät in der Regel innerhalb weniger Minuten nach der ABM-Zuweisung. Der Ablauf dahinter: ABM benachrichtigt das alte MDM über das MDM-Protokoll → das alte MDM schickt einen APNs-Push ans Gerät → das Gerät checkt beim alten MDM ein, holt sich die Migration-Instruction und zeigt dem User die Notification an. Ist das Gerät offline, wartet APNs auf die nächste Verbindung.

Wichtig: Die täglichen, stündlichen und minuten-genauen Benachrichtigungen aus der Tabelle oben sind der Reminder-Rhythmus für den Fall, dass der User noch nicht reagiert hat – nicht der Zeitplan für die initiale Erstbenachrichtigung.

Beschleunigen möglich? Ja – aber nur über das alte MDM: einen manuellen Force Check-in / Sync-Befehl ans Gerät schicken. Das triggert sofort ein Check-in, das Gerät holt sich die Migration-Instruction und zeigt die Notification ohne Wartezeit an. Ein ABM-Sync im neuen MDM hat darauf keinen Einfluss – die User-Notification läuft ausschließlich über das alte MDM und APNs.

Phase 4: Was auf dem Gerät passiert (User-Flow)

Auf iPhone/iPad:

  1. User erhält eine Notification ‚Enrollment Required‘
  2. Tippen auf die Notification öffnet Einstellungen → VPN & Geräteverwaltung
  3. ‚Enrollment starten‘ antippen
  4. Gerät startet neu – nach dem Neustart enrollt sich das Gerät automatisch im neuen MDM
  5. Alle neuen MDM-Konfigurationen werden direkt im Anschluss OTA verteilt

Auf Mac:

  1. Notification erscheint im Notification Center
  2. Klick öffnet Systemeinstellungen → Geräteverwaltung
  3. ‚Enrollment starten‘ → Vollbild-Dialog → ‚Enroll‘
  4. MDM-Profile werden entfernt, Gerät enrollt sich neu
  5. Nach erfolgtem Enrollment: alle neuen MDM-Konfigurationen werden OTA verteilt
Was wenn’s schiefläuft?

Schlägt das Enrollment fehl (z.B. kein WLAN), wird das Gerät nicht mehr vom alten MDM verwaltet und gilt als ‚unmanaged‘. In diesem Fall: Gerät wie ein neu zu enrollendes Gerät behandeln. Es gibt keinen automatischen Rückfall zum alten MDM.

Wie sieht das konkret für Intune und Workspace ONE aus?

Beide Lösungen unterstützen das Feature. Die Vorbereitung auf Intune-Seite laut Microsoft:

  • APNs-Zertifikat in Intune hochladen
  • ABM/ASM-Token in Intune registrieren (gegenseitiger Token-Austausch)
  • Enrollment Profile in Intune erstellen und Geräten zuweisen
  • Danach in ABM: MDM-Server auf Intune umstellen und Deadline setzen

Für Workspace ONE gilt dasselbe Prinzip. Da ich in nächster Zeit den ganzen Prozess selbst teste, folgt dazu ein detaillierter Praxisbericht – Stay tuned.

Best Practices für die Praxis

  • Immer mit einer Pilot-Gruppe anfangen: 5–10 Geräte, alles prüfen, dann skalieren.
  • Separate ABM-Server-Tokens: Für altes und neues MDM je einen eigenen Token verwenden.
  • await_device_configured nutzen: Dadurch können Apps (inkl. deren Daten) preserviert werden – wichtig für nahtlose User-Experience.
  • VPP-Migration zuerst planen: Token aus altem MDM ZUERST entfernen, dann im neuen registrieren. Deadline max. 30 Tage bei VPP-Apps.
  • User-Kommunikation: Vorab informieren, was passiert. Kein Datenverlust, aber der Enrollment-Dialog kommt – das kann erschrecken.
  • Offline-Fälle einplanen: Geräte ohne WLAN nach der Deadline landen im Setup-Assistant, bis sie sich verbinden.

Omnissa Sovereign Solution: Das Ende von WS1 On-Premise – und was jetzt auf Kunden zukommt

Omnissa Sovereign Solution: Das Ende von WS1 On-Premise – und was jetzt auf Kunden zukommt

Wer meinen Post zum WS1 vs. Intune Vergleich gelesen hat, wird sich erinnern: Ich hab die Sovereign Solution dort kurz als Option für regulierte Umgebungen erwähnt und einen eigenen Post versprochen. Der Zeitpunkt ist dabei kein Zufall – denn das Thema ist gerade für alle WS1-Kunden und deren Berater hochaktuell. Der Countdown läuft. WS1 On-Premise hat ein Ablaufdatum: 30. April 2027.

In diesem Post gehen wir tiefer. Woher kommt WS1 überhaupt? Was steckt wirklich hinter der Sovereign Solution? Welche Optionen gibt es – und was bedeutet das Ende von On-Premise für Kunden, die aus regulatorischen Gründen nie in eine Public Cloud wollten oder nicht dürfen!? Und die große Frage zum Schluss: Ist das der Anfang vom Ende für Workspace ONE – oder doch ein Neustart?

Spoiler: Meine Einschätzung ist kritisch. Aber der Reihe nach.

Von AirWatch zu Omnissa: Eine kurze Reise durch 20 Jahre UEM

Wer im MDM-Markt unterwegs ist, kennt die Geschichte – aber für alle die sie nicht kennen: AirWatch wurde 2003 gegründet und war spätestens ab 2012/2013 die Referenz im Enterprise-MDM-Markt. 2014 übernahm VMware AirWatch für rund 1,54 Milliarden Dollar – damals eine der teuersten Software-Akquisitionen im EUC-Segment. Daraus entstand Workspace ONE: ein vollintegriertes Digital Workspace-Ökosystem mit MDM, Identity, Conditional Access und App-Management.

Jahrelang war WS1 das Maß der Dinge – besonders im Enterprise-Segment mit komplexen Anforderungen, heterogenen Device-Flotten und strengen Security-Vorgaben. On-Premise war dabei für viele Kunden nicht nur eine Option, sondern eine Notwendigkeit: KRITIS-Unternehmen, Behörden, Banken und Healthcare-Organisationen konnten oder wollten ihre MDM-Infrastruktur schlicht nicht in eine US-amerikanische Public Cloud geben.

Dann kam Broadcom. Im November 2023 schloss Broadcom die VMware-Übernahme für rund 61 Milliarden Dollar ab – und seitdem ist vieles anders. Das VMware EUC-Portfolio (also alles rund um Workspace ONE und Horizon) wurde im Mai 2024 in ein eigenständiges Unternehmen ausgegliedert: Omnissa. Privatgehalten, mit KKR als Hauptinvestor, 4.000 Mitarbeitern und dem klaren Auftrag, das EUC-Portfolio weiterzuführen und zu modernisieren. Klingt erstmal solide – aber der Markt hat das mit gemischten Gefühlen aufgenommen, und das zu Recht.

Der Countdown läuft: WS1 On-Premise End of Support am 30. April 2027

⚠️ Wichtige Deadline: Workspace ONE UEM On-Premises End of Support: 30. April 2027. Letzte installierbare Version: 24.10. Keine Neuentwicklungen – nur noch Security-Patches bis zum Stichtag. Neue On-Premise-Deployments sind nur noch als Ausnahme mit PS-Engagement möglich.

Omnissa hat es offiziell kommuniziert: Die monolithische On-Premise-Architektur von WS1 UEM wird nicht mehr weiterentwickelt. Der Grund ist technischer Natur – und eigentlich nachvollziehbar: Die klassische On-Premise-Architektur ist komplex, wartungsintensiv und inkompatibel mit dem, was Omnissa als strategische Zukunft sieht: den Modern Stack (kurz: ModStack).

Was ist der Modern Stack?

Der ModStack ist eine komplette Neuentwicklung der WS1 UEM-Architektur – weg vom monolithischen Aufbau, hin zu Microservices und Containern. Das bringt echte Vorteile: schnellere Updates, kürzere Release-Zyklen, bessere Skalierbarkeit und – das ist der entscheidende Punkt – Infrastrukturautonomie. Der ModStack kann auf verschiedenen Infrastrukturen laufen, also nicht nur auf einer bestimmten Public Cloud. Genau das ist die technische Grundlage für die Sovereign Solution.

Für On-Premise-Kunden bedeutet das aber auch: Features die im ModStack verfügbar sind – Freestyle Orchestrator, deklaratives Management für Apple, Linux-Support, WS1 Intelligence, DEX – die gibt’s für euch nicht mehr. Wer On-Premise betreibt, fährt ab sofort mit angezogener Handbremse. Keine neuen Features, nur noch Patches bis April 2027.

Was passiert nach dem 30. April 2027?

„End of Support“ heißt: keine Patches mehr, keine Security-Updates, kein Support. Wer dann noch On-Premise betreibt, tut das auf eigenes Risiko – in einer Umgebung ohne Sicherheits-Updates, die täglich verwundbarer wird. Für alle Unternehmen in regulierten Branchen ist das de facto kein tragbarer Zustand.

Der Handlungsdruck ist also real. Und wer glaubt, bis 2027 ist noch Zeit: Migrationsprojekte in Enterprise-Umgebungen mit tausenden Devices, bestehenden Zertifikatsinfrastrukturen, SCEP-Setups und gewachsenen Policy-Strukturen brauchen Zeit. Wer 2026 anfängt, könnte es eng werden.

Die Optionen: Wohin können Kunden migrieren?

Omnissa stellt drei zentrale Wege für den Umstieg bereit. Alle drei basieren auf dem ModStack – der Unterschied liegt in der Hosting-Infrastruktur und dem Datensouveränitätsniveau.

Option 1: Shared SaaS

Das ist die klassische Public-Cloud-Variante. WS1 UEM läuft in der Omnissa-Cloud, mandantenübergreifend auf shared Infrastructure. Günstigste Option, einfachste Migration via Brownfield-Ansatz (bestehende Umgebung wird 1:1 migriert, keine Neu-Enrollments nötig). Für Unternehmen ohne besondere Datensouveränitäts-Anforderungen der schnellste Weg nach vorne.

Aber: Die Daten liegen in einer US-amerikanischen Public Cloud. CLOUD Act. GDPR-Grauzone. Für KRITIS, Behörden und stark regulierte Branchen ein No-Go.

Option 2: Preferred SaaS

Wie Shared SaaS, aber mit dediziertem Tenant. Höhere Isolation, schnellere Performance, keine geteilten Ressourcen mit anderen Kunden. Teurer, aber für Unternehmen interessant, die zwar in die Cloud wollen, aber mehr Kontrolle über ihren Tenant brauchen. An den Datensouveränitäts-Fragen ändert das aber grundsätzlich nichts – die Daten liegen immer noch bei Omnissa in der Public Cloud.

Option 3: Sovereign Solution – der neue Weg für regulierte Umgebungen

Und hier wird’s interessant. Die Omnissa Sovereign Solution für Workspace ONE ist ein partner-gehostetes SaaS-Modell: Ein zertifizierter Omnissa-Partner betreibt die WS1 UEM-Umgebung vollständig auf eigener, lokaler Infrastruktur in privaten Rechenzentren – abgeschirmt von internationalen Public Clouds und damit vom Anwendungsbereich des U.S. CLOUD Act.

Technisch läuft das ganze auf dem ModStack – also moderner SaaS-Architektur, aber eben nicht in einer internationalen Public Cloud. Der Kunde hat direkten Vertrag mit einem lokalen Partner, volle Kontrolle über Datenhaltung und Compliance, und trotzdem alle ModStack-Features. Bring Your Own Key (BYOK) und Desired State Management (DSM) sind direkt integriert.

Wer der oder die aktuellen Partner für die Sovereign Solution in Deutschland und Europa sind, lässt sich mit etwas Recherche schnell herausfinden – ich nenne hier bewusst keine Namen. Warum? Dazu gleich mehr.

ℹ️ Sovereign Solution in Kürze: Partner-gehostetes SaaS | Lokales Rechenzentrum in DE/EU | Volle DSGVO/BDSG-Konformität | Schutz vor U.S. CLOUD Act | BYOK + DSM integriert | ModStack-Architektur | Verfügbar über zertifizierte Omnissa-Partner

Kriterium Shared SaaS Preferred SaaS Sovereign Solution
Hosting Omnissa Public Cloud Omnissa Public Cloud Partner-privates RZ (DE/EU)
Datensouveränität ❌ US-Cloud ❌ US-Cloud ✅ Lokal DE/EU
DSGVO / BDSG ⚠️ Eingeschränkt ⚠️ Eingeschränkt ✅ Vollständig konform
CLOUD Act Risiko ❌ Vorhanden ❌ Vorhanden ✅ Ausgeschlossen
ModStack-Features ✅ Alle ✅ Alle ✅ Alle
BYOK Support ⚠️ Begrenzt ⚠️ Begrenzt ✅ Nativ integriert
Kosten Niedrig Mittel Höher (Partner-Managed)
Für KRITIS geeignet
Verfügbarkeit Sofort Sofort Über zertif. Partner (DE/EU)

Migration: Greenfield vs. Brownfield – was bedeutet das in der Praxis?

Für alle, die gerade eine On-Premise-Umgebung betreiben, ist die Migrationsfrage entscheidend. Omnissa unterscheidet zwei Ansätze:

Greenfield: Neuer Tenant, neue Struktur, alles von Grund auf neu aufgebaut. Für große Umgebungen mit viel gewachsenem Tech-Debt eigentlich die sauberere Lösung – aber bedeutet in den meisten Fällen: alle Devices neu enrollen. In einer Umgebung mit 10.000+ Geräten und Nutzern im Schichtbetrieb ist das operativ eine echte Herausforderung.

Brownfield: Die bestehende On-Premise-Umgebung wird 1:1 migriert. URLs, Zertifikate, Datenbankinhalt – alles wird übernommen, kein Re-Enrollment notwendig. Voraussetzung ist ein dedizierter UEM-Tenant. Das ist der bevorzugte Ansatz für bestehende Installationen und in den meisten Enterprise-Projekten die realistischere Option.

Mein Rat aus der Praxis: Fangt jetzt an zu planen. Nicht 2026. Evaluiert eure Umgebung, prüft ob Shared SaaS, Preferred SaaS oder Sovereign Solution für euren Use Case passt, und startet mit einem Proof of Concept. Migrationen dieser Größenordnung haben immer unerwartete Stolpersteine – sei es die Zertifikatsinfrastruktur, bestehende Integrations-Workflows oder schlicht organisatorische Hürden.

Ein Appell an die Berater-Community: Mehr Anbieter, mehr Wettbewerb, mehr Sicherheit

Ich möchte an dieser Stelle einen Punkt ansprechen, der mir persönlich am Herzen liegt – und der über die reine Technologiediskussion hinausgeht.

Die Sovereign Solution ist aktuell ein sehr junges Angebot im Markt. Das bedeutet: Es gibt bisher nur sehr wenige zertifizierte Partner in Deutschland und Europa, die diesen Service anbieten können und wollen. Und das ist – aller technischen Qualität zum Trotz – ein strukturelles Risiko. Wenn ein Modell das auf lokaler, partnerbasierter Infrastruktur aufbaut, de facto von einer Handvoll Anbieter abhängt, dann ist das keine gesunde Marktsituation.

Stellt euch vor: Ein Kunde entscheidet sich für die Sovereign Solution, bindet sich an einen Partner – und dieser Partner ändert seine Strategie, wird übernommen oder stellt den Service ein. Was dann? Die Abhängigkeit wäre mindestens genauso groß wie die, die man durch den Abschied von On-Premise gerade hinter sich lassen wollte.

💡 Mein Appell: Berater, SEs und Systemhäuser in Deutschland und der EU – schaut euch die Omnissa Sovereign Solution genauer an! Das Modell braucht mehr Anbieter. Mehr Wettbewerb bedeutet bessere Preise, mehr Auswahl für Kunden und vor allem: eine resilientere Infrastruktur für einen Markt, der auf Datensouveränität angewiesen ist. Gerade große Systemhäuser mit eigenen Rechenzentren und bestehendem Omnissa-Partnerstatus haben hier eine echte Chance – und eine Verantwortung gegenüber ihren Kunden.

Ich weiß, dass das Investment in Zertifizierung, Infrastruktur und Betrieb nicht trivial ist. Aber der Bedarf ist real, die regulatorischen Anforderungen wachsen, und die Kunden suchen aktiv nach Alternativen zur Public Cloud. Wer jetzt in diesen Markt einsteigt, positioniert sich für die nächsten Jahre. Und das ist – Stand heute – noch eine echte Chance, kein überfüllter Markt.

Die große Frage: Zukunft oder Todesurteil für Workspace ONE?

Jetzt kommt der Teil, für den ich bekannt bin: meine ehrliche, ungeschönte Meinung. Und die ist, um es direkt zu sagen, kritisch-skeptisch.

Was für Omnissa spricht

Technisch ist der ModStack ein echter Fortschritt. Die Microservices-Architektur ist moderner, skalierbarer und flexibler als das, was WS1 On-Premise je war. Die Sovereign Solution ist eine clevere Antwort auf ein reales Marktbedürfnis – gerade in Europa, wo Datensouveränität durch DSGVO, BDSG und den U.S. CLOUD Act ein echtes Thema ist. Und die Tatsache, dass Omnissa beim Gartner Critical Capabilities for Endpoint Management 2026 laut eigenen Angaben top platziert ist, zeigt: technisch ist das Produkt noch konkurrenzfähig.

Dazu kommt: Omnissa ist jetzt eigenständig. Kein großer Broadcom-Konzern der entscheidet, ob EUC-Investment Sinn ergibt oder nicht. Das kann – wenn KKR als Investor langfristig denkt – ein Vorteil sein.

Was mich besorgt – und das ist mehr

Aber dann ist da noch das Broadcom-Erbe. Und das sitzt tief. Die Lizenzstruktur-Änderungen nach der VMware-Übernahme haben viele Kunden und Partner kalt erwischt. Vertrauensverlust ist schwer zu reparieren – das spürt Omnissa bis heute im Markt. Viele Kunden die On-Premise betrieben haben, haben das bewusst gewählt. Nicht nur wegen Datensouveränität, sondern auch weil sie die Kontrolle über ihre Infrastruktur haben wollten. Die werden jetzt in eine SaaS-Abhängigkeit gedrängt – entweder Public Cloud oder Partner-Modell. Das ist eine fundamentale Veränderung in der Kundenbeziehung.

Dann ist da die Frage: Was passiert mit Omnissa selbst? Private Equity als Investor bedeutet in der Regel: Wachstum oder Exit. KKR wird Omnissa irgendwann verkaufen oder an die Börse bringen. Was das für Kunden und das Produkt bedeutet, ist heute nicht absehbar. Wer sich heute für die Sovereign Solution entscheidet, wettet also nicht nur auf die Technologie, sondern auch auf die Kontinuität des Unternehmens dahinter.

Und dann ist da noch der Elefant im Raum: Microsoft Intune. Für alle Kunden, die tief im M365-Stack stecken – und das sind in Deutschland viele – ist Intune heute eine echte Alternative. Nicht für alle Use Cases, nicht für Rugged Devices, nicht für maximale Granularität. Aber für die breite Masse der Standard-Device-Flotten? Intune holt auf, ist günstiger (weil oft schon lizenziert) und hat den Vorteil des vertrauteren Microsoft-Ökosystems.

⚠️ Meine Einschätzung: Die Sovereign Solution ist technisch solide und strategisch sinnvoll – aber das Vertrauen in Omnissa als Unternehmen muss erst noch zurückgewonnen werden. Kunden sollten die Migration nicht als reine Technologieentscheidung betrachten, sondern auch die langfristige Unternehmenskontinuität und die Stabilität des Partner-Ökosystems evaluieren. Wer jetzt migriert, bindet sich an ein junges, privatgehaltenes Unternehmen mit unklarer Eigentümer-Roadmap – und aktuell an einen sehr überschaubaren Kreis von Service-Anbietern.

Ist es das Todesurteil für WS1?

Nein – noch nicht. Aber es ist eine kritische Phase. Workspace ONE hat in spezifischen Segmenten – Rugged Devices, komplexe Multi-OS-Flotten, KRITIS-Umgebungen – nach wie vor keine gleichwertige Alternative. Intune kommt da schlicht nicht ran. Für diese Kunden ist die Sovereign Solution ein Lebenszeichen, kein Schwanengesang.

Für alle anderen – die Standard-Enterprise-Umgebungen mit iOS und Android die sowieso im M365-Ökosystem leben – wird die Abwanderung zu Intune weitergehen. Das ist eine Marktverschiebung die bereits im Gange ist, und die Sovereign Solution wird sie für dieses Segment nicht stoppen.

Mein Fazit: Workspace ONE wird überleben – aber in einer anderen Form und für eine schmalere, spezialisierte Zielgruppe. Die große Frage ist nicht ob WS1 stirbt, sondern ob Omnissa als Unternehmen die Zeit und Ressourcen hat, diesen Wandel erfolgreich zu gestalten. Und ob das Partner-Ökosystem rund um die Sovereign Solution schnell genug wächst, um dem Modell eine echte Marktbasis zu geben. Das liegt letztlich nicht nur an der Technologie.

Was sollten Kunden und Berater jetzt tun?

  • Bestandsaufnahme: Wie viele On-Premise-Deployments habt ihr, in welchen Versionen, mit welchen Integrationen?
  • Regulatorischen Bedarf prüfen: Shared SaaS, Preferred SaaS oder Sovereign Solution – das hängt vom Datenschutzbedarf ab, nicht von der Präferenz.
  • Partner für die Sovereign Solution selbst recherchieren: Ein kurzer Blick in das offizielle Omnissa Partner-Ökosystem reicht – und wer mehrere Anbieter vergleicht, ist besser aufgestellt als wer sich blind auf den ersten einlässt.
  • Migration planen, nicht improvisieren: Brownfield ist der bevorzugte Weg – aber auch der braucht einen dedizierten Tenant, saubere Vorbereitung und ausreichend Zeit.
  • Intune als Alternative ernsthaft evaluieren: Gerade für Unternehmen im M365-Ökosystem ohne KRITIS-Anforderungen ist das kein Tabu mehr – sondern eine legitime strategische Option.
  • Deadline 30. April 2027 nicht unterschätzen: Wer mit einem Security Audit, einer ISO-Zertifizierung oder einer BSI-Prüfung zu tun hat, sollte nicht im März 2027 noch auf einem ungesupporteten System sitzen.
  • An Berater und Systemhäuser: Schaut euch die Möglichkeit an, selbst Sovereign Solution Partner zu werden. Der Markt braucht euch.

Fazit: Ein Neuanfang unter Vorbehalt – und ein Markt der mehr Mitspieler braucht

Die Omnissa Sovereign Solution ist – technisch betrachtet – die richtige Antwort auf ein reales Problem. Datensouveränität ist in der EU kein Marketing-Buzzword mehr, sondern eine rechtliche und operative Notwendigkeit. Dass Omnissa hierfür einen konkreten, partnerbasierten Weg bietet, ist positiv.

Aber das Vertrauen ist angekratzt. Die Broadcom-Ära hat Spuren hinterlassen. Omnissa muss das jetzt durch Kontinuität, transparente Kommunikation und stabile Preismodelle zurückgewinnen. Und das Partner-Ökosystem muss wachsen – schnell. Ein Markt, der auf Datensouveränität setzt, darf nicht selbst in eine neue Abhängigkeit laufen, diesmal von einer Handvoll Service-Anbieter.

Für alle WS1-On-Premise-Kunden und ihre Berater gilt: Die Uhr tickt. April 2027 klingt weit weg, ist es aber nicht. Jetzt ist der Moment, die Strategie zu definieren – nicht zu warten, bis der Support-Ablauf zum operativen Notfall wird.

Ich bin gespannt auf eure Meinungen – gerade von denen die täglich in Kundenprojekten mit WS1 zu tun haben, oder von Beratern und SEs die überlegen, ob die Sovereign Solution für sie als Service-Angebot interessant wäre. Seid ihr Team „Sovereign Solution“, Team „Intune-Migration“ oder habt ihr ganz andere Pläne? Ran an die Kommentare! 😄

Intune Managed Home Screen: Neue RBAC-Permissions – kleines Feature, große Wirkung

Intune Managed Home Screen: Neue RBAC-Permissions – kleines Feature, große Wirkung

Manchmal sind es die kleinen Änderungen, die im Alltag den größten Unterschied machen. Microsoft hat mit dem Intune Februar-Release (2602) zwei neue RBAC-Permissions für den Managed Home Screen eingeführt:

TemporarilySuspendManagedHomeScreen | RestoreManagedHomeScreen

Klingt erstmal technisch und unspektakulär. Ist es aber nicht. Wer schon mal versucht hat, einen Android-Kiosk in einer Schule oder im Frontline-Worker-Umfeld zu supporten, ohne lokalen Admin-Zugriff aufs Gerät zu haben, wird beim Lesen dieser Zeilen vielleicht kurz aufatmen. Warum? Das erkläre ich hier.

Kurzer Auffrischungskurs: Was ist eigentlich der Managed Home Screen?

Für alle die noch nicht täglich mit Android-Enterprise-Deployments zu tun haben: Der Microsoft Managed Home Screen (kurz MHS) ist eine App aus dem Managed Google Play Store, die Microsoft Intune als Standard-Launcher für Android-Kiosk-Geräte verwendet.

Das bedeutet konkret: Statt dem normalen Android-Homescreen sieht der Nutzer nur das, was der Admin ihm erlaubt. Welche Apps, welche Einstellungen, welche Widgets – alles zentral gesteuert. MHS läuft dabei typischerweise auf:

  • Android Enterprise Dedicated Devices (Corporate-owned, kein User-Account) – klassisch für Kiosk, Shared Devices, Info-Terminals
  • Fully Managed Devices (Corporate-owned, user-affiliated) – z.B. Frontline Worker, Schüler-Tablets, Lagermitarbeiter

Der Vorteil ist klar: Kein Nutzer kommt aus dem Kiosk raus, installiert irgendwas, oder ändert die WLAN-Einstellungen. Das Gerät macht was es soll – und sonst nichts.

ℹ️ MHS in Kürze: Intune-verwalteter Android-Launcher | Kiosk-Modus für Dedicated & Fully Managed Devices | Konfigurierbar via App Configuration Policies oder Device Configuration Profiles | Unterstützt Android Enterprise ab OS 8.0 | Beliebt in Schulen, Logistik, Healthcare und Retail

Das Problem: Kiosk ist super – bis jemand Support braucht

Kiosk-Geräte sind im laufenden Betrieb wunderbar. Aber dann kommt der Moment, wo etwas nicht funktioniert. Eine App hängt sich auf, eine Policy greift nicht, das Gerät braucht ein Update das sich im Lock-Down nicht automatisch installiert. Oder – klassischer Schulkontext – ein Schüler hat irgendwas Kreatives angestellt und das Gerät verhält sich komisch.

Vor den neuen Permissions war die Situation für Help Desk Operators und Schuladmins in solchen Momenten nicht schön. Um aus dem MHS-Kiosk rauszukommen und auf die normale Android-Oberfläche zugreifen zu können, gab es im Wesentlichen drei Wege:

  • Den Kiosk-Exit-PIN verwenden – sofern konfiguriert und dem Supporter bekannt
  • Den Debug-Modus über das 15-malige Zurück-Drücken aktivieren – undurchsichtig, nutzerfeindlich, nicht skalierbar
  • Einen vollwertigen Intune-Admin einschalten – weil nur der die nötigen Berechtigungen hatte

Für große Organisationen mit vielen Geräten und einem gestaffelten Support-Modell (Tier 1 / Tier 2 / Tier 3) ist das ein echtes Problem. Ein Help Desk Operator der in einer Schule 300 iPads und 200 Android-Kiosks supportet, braucht operative Handlungsfähigkeit – ohne dass man ihm gleich globale Admin-Rechte geben will. Genau hier setzen die neuen Permissions an.

Die zwei neuen RBAC-Permissions im Detail

TemporarilySuspendManagedHomeScreen – Kiosk kurz auf Pause

Mit dieser Permission kann ein berechtigter Admin den Managed Home Screen vorübergehend aussetzen. Das Gerät verlässt damit den Kiosk-Modus und gibt temporär Zugriff auf die normale Android-Oberfläche – ohne dass der Kiosk dauerhaft deaktiviert wird oder irgendwas an der Konfiguration geändert werden muss.

Was das in der Praxis bedeutet: Der Help Desk kann aus der Ferne – oder direkt am Gerät via Intune Remote Action – den Kiosk kurz „parken“, das Problem lösen (App-Cache leeren, Update erzwingen, Einstellungen prüfen), und danach den MHS-Kiosk wieder aktivieren. Sauber, kontrolliert, ohne Admin-Eskalation.

💡 Praxisbeispiel Schule: Schüler-Tablet in Klasse 7b verhält sich komisch – App startet nicht, Lehrer ruft Support. Help Desk Operator suspendiert remote den MHS, sieht auf die vollständige Android-Oberfläche, stellt das Problem fest (abgelaufene App-Version), triggert ein Sync, aktiviert MHS wieder. Dauer: 5 Minuten. Ohne diese Permission: IT-Admin-Eskalation, Ticket-Ping-Pong, ggf. Gerät einschicken.

RestoreManagedHomeScreen – zurück in den Kiosk

Das ist die Gegenseite. Nachdem der MHS temporär suspendiert wurde, stellt diese Permission sicher, dass der Help Desk Operator den Kiosk-Modus wieder aktivieren kann – ohne auf einen vollständigen Intune-Admin angewiesen zu sein.

Das ist wichtiger als es klingt. Ein Suspend ohne kontrollierten Restore ist in einer Kiosk-Umgebung ein Sicherheitsrisiko. Ein Gerät das „aus Versehen“ dauerhaft aus dem Kiosk ist, ist im Schulkontext oder im Retail-Einsatz schnell ein Problem. Mit RestoreManagedHomeScreen hat der Help Desk die volle Kontrolle über den gesamten Suspend/Restore-Zyklus.

ℹ️ Wichtig: Die beiden Permissions sind als Paar gedacht. TemporarilySuspend ohne Restore ergibt keinen sicheren Support-Workflow. Microsoft hat sie deshalb auch gemeinsam in die Built-in-Rollen aufgenommen.

Wer bekommt die neuen Permissions – und warum genau diese Rollen?

Microsoft hat die beiden Permissions mit dem Februar-Release (2602) automatisch in zwei bestehende Built-in-Rollen integriert:

RBAC-Rolle Bisherige Kernaufgaben Neu hinzukommend
Help Desk Operator Remote-Tasks (Wipe, Lock, Retire), App/Policy-Zuweisung, User-Support TemporarilySuspend + RestoreManagedHomeScreen
School Administrator Apps & Settings für Gruppen, Remote-Lock/Restart/Retire, Intune for Education TemporarilySuspend + RestoreManagedHomeScreen

Die Wahl dieser beiden Rollen ist nicht zufällig. Der Help Desk Operator ist die typische Tier-1-bis-Tier-2-Support-Rolle in Unternehmen mit MHS-Deployments – Retail, Logistik, Healthcare, Frontline Worker. Und der School Administrator ist die dedizierte Rolle für Intune for Education-Umgebungen, wo Kiosk-Tablets und Shared Devices allgegenwärtig sind.

Beide Rollen haben gemeinsam, dass sie operativ nah an den Geräten dran sind – aber eben nicht die volle Intune-Admin-Power haben sollen. Genau deshalb macht es Sinn, ihnen die MHS-Suspend/Restore-Kontrolle zu geben: genug Handlungsspielraum für den Daily Support, ohne sicherheitskritische Berechtigungen wie Policy-Erstellung oder Enrollment-Management zu öffnen.

Kurzer RBAC-Exkurs: Warum das Prinzip so wichtig ist

Role-Based Access Control (RBAC) ist in Intune das zentrale Berechtigungsmodell. Statt jedem Admin die gleichen Rechte zu geben, definiert man Rollen mit klar begrenzten Berechtigungen – und weist diese Rollen dann an spezifische Personen oder Gruppen zu. Das Prinzip dahinter: Least Privilege – jeder bekommt genau die Rechte, die er für seine Aufgabe braucht. Nicht mehr, nicht weniger.

Microsoft empfiehlt ausdrücklich, für den täglichen Betrieb auf Built-in-Rollen zu setzen und Microsoft Entra ID-Rollen (die oft zu viel Zugriff haben) nicht als Standard-Admin-Rollen zu verwenden. Die neuen MHS-Permissions sind ein gutes Beispiel für diese Philosophie in der Praxis: Eine Aufgabe (Kiosk suspendieren) bekommt eine dedizierte Permission, die gezielt an die richtigen Rollen vergeben werden kann.

RBAC-Konzept Bedeutung für MHS-Deployments
Least Privilege Help Desk kann Kiosk managen ohne globale Admin-Rechte
Built-in Roles School Admin + Help Desk Operator bekommen die Permissions automatisch
Custom Roles Granulare Vergabe möglich: z.B. nur RestoreManagedHomeScreen ohne Suspend
Scope Tags Permissions können auf bestimmte Gerätegruppen oder Standorte begrenzt werden

Für Organisationen die Custom RBAC-Rollen nutzen: Die neuen Permissions können auch gezielt einzeln vergeben werden. Wer zum Beispiel einen noch engeren Tier-1-Support nur mit Restore-Recht ausstatten will (um zu verhindern dass jemand den Kiosk unberechtigt suspendiert), kann das über eine Custom Role abbilden.

Wie funktioniert das technisch – was passiert beim Suspend?

Wenn TemporarilySuspendManagedHomeScreen ausgelöst wird, passiert folgendes auf dem Gerät:

  • Der Managed Home Screen-Launcher gibt die Steuerung temporär ab
  • Das Android-System zeigt wieder den Standard-Launcher (oder einen anderen konfigurierten Launcher)
  • Der Nutzer/Admin hat Zugriff auf die vollständige Android-Oberfläche, System-Settings und alle installierten Apps
  • Die MHS-Konfiguration, Policies und App-Zuweisungen bleiben dabei vollständig erhalten – es wird nichts gelöscht oder geändert
  • Per RestoreManagedHomeScreen wird MHS wieder als aktiver Launcher gesetzt – der Kiosk-Modus ist sofort wiederhergestellt

Das ist der entscheidende Unterschied zur bisherigen „Exit Kiosk Mode“-Funktionalität über das Debug-Menü: Die neuen Permissions erlauben eine saubere, remote-auslösbare, auditierbare Aktion – keine Workarounds, kein manuelles Rumdrücken am Gerät, keine PIN-Weitergabe.

⚠️ Zu beachten: Die Suspend-Aktion gibt dem Nutzer temporär Vollzugriff auf das Android-System. In sensiblen Umgebungen (z.B. Healthcare, KRITIS) sollte der Suspend-Workflow dokumentiert und per Scope Tags auf berechtigte Admins begrenzt sein. Ein unbeaufsichtigtes Gerät im Suspend-Zustand ist de facto aus dem Kiosk – das sollte nicht dauerhafter Zustand sein.

Die konkreten Vorteile für den Admin-Alltag

1. Eskalationen werden seltener

Der häufigste Support-Aufwand bei MHS-Deployments ist die Kiosk-Intervention: Gerät hängt, App macht nicht mit, Update ist blockiert. Bisher musste in vielen Szenarien ein Intune-Admin eingreifen. Mit den neuen Permissions kann der Help Desk das selbst lösen – weniger Tickets, kürzere Lösungszeiten, weniger frustrierte Lehrer oder Schichtleiter.

2. Kein PIN-Sharing mehr

Die bisherige „Exit Kiosk“-Methode via Kiosk-PIN war ein Sicherheitsproblem in der Praxis: Entweder kannte der Help Desk den PIN nicht, oder er wurde geteilt und damit zum Sicherheitsrisiko. Mit den RBAC-Permissions ist das obsolet. Kein Pin-Sharing, kein Post-it an der Unterseite des Tablets. Die Aktion ist an die Rolle gebunden, nicht an ein Shared Secret.

3. Vollständige Auditierbarkeit

RBAC-Aktionen in Intune werden geloggt. Wer den MHS suspendiert hat, wann, auf welchem Gerät – das ist alles in den Intune-Audit-Logs nachvollziehbar. Für Compliance-Reports, ISO-Zertifizierungen oder einfach nur für den internen Überblick ist das ein echter Mehrwert gegenüber dem bisherigen PIN-basierten Zugang.

4. Kein Sicherheits-Downgrade nötig

Bisher war die pragmatische Lösung in manchen Organisationen: Help-Desk-Mitarbeitern mehr Intune-Rechte geben als eigentlich nötig, damit sie Kiosk-Probleme lösen können. Das ist klassisches Permission Creep – und ein Risiko. Die neuen granularen Permissions erlauben es, genau das zu vermeiden: Der Help Desk Operator bekommt MHS-Suspend-Rechte, aber eben keine Policy-Erstellungs- oder Enrollment-Rechte.

5. Perfekt für Schul- und Frontline-Umgebungen

Genau die Szenarien wo MHS am meisten eingesetzt wird – Schulen, Retail, Logistik, Healthcare – sind auch die Szenarien mit dem höchsten Support-Aufkommen und dem geringsten Admin-Personal vor Ort. Ein Schulleiter oder Schichtverantwortlicher mit Help-Desk-Operator-Rolle kann jetzt selbst eingreifen, ohne auf den zentralen IT-Admin warten zu müssen. Das ist in der Praxis ein erheblicher Effizienzgewinn.

Was müssen Admins jetzt tun?

Microsoft hat das klar kommuniziert: Es ist keine Admin-Aktion erforderlich. Die Permissions werden automatisch den Built-in-Rollen hinzugefügt. Aber „kein Handlungsbedarf“ heißt nicht „kein Nachdenken erforderlich“. Hier die Empfehlungen:

  • Rolle-Assignments reviewen: Wer hat bei euch die School Administrator- oder Help Desk Operator-Rolle zugewiesen bekommen? Diese Personen bekommen die neuen Permissions automatisch. Ist das in allen Fällen gewollt?
  • Dokumentation aktualisieren: Wenn ihr interne IT-Handbücher, Schulungsunterlagen oder SOPs für den Kiosk-Support habt, müssen diese aktualisiert werden. Der neue Workflow via Suspend/Restore sollte dokumentiert und kommuniziert sein.
  • Custom Roles prüfen: Wer Custom RBAC-Rollen nutzt, kann die neuen Permissions manuell hinzufügen – oder bewusst weglassen, wenn der engste Least-Privilege-Ansatz gewünscht ist.
  • Scope Tags einsetzen: Besonders in großen Organisationen mit verteilten Standorten: Scope Tags sicherstellen, dass Help Desk Operators nur die Geräte suspendieren können, für die sie auch zuständig sind.
  • Auslöser in Intune kennenlernen: Die Aktion wird in der Intune Admin Console als Remote Action auf dem Gerät auslösbar sein – ähnlich wie Remote Lock oder Sync. Den genauen Workflow für das eigene Team einmal durchspielen bevor es der erste echte Support-Fall erfordert.

Fazit: Klein, aber fein – und überfällig

TemporarilySuspendManagedHomeScreen und RestoreManagedHomeScreen sind keine Features die auf Konferenzen mit großem Tamtam vorgestellt werden. Aber für jeden der täglich MHS-Deployments in Schulen, im Frontline-Worker-Umfeld oder im Kiosk-Betrieb supporten muss, sind sie ein echter Lebensverbesserer.

Das Prinzip dahinter ist einfach und richtig: Wer Support machen darf, soll auch die Werkzeuge haben, um guten Support machen zu können – ohne dafür einen sicherheitskritischen Permission-Overhead zu bekommen. Granulares RBAC ist genau dafür gemacht. Und Microsoft setzt das hier konsequent um.

Wer schon MHS im Einsatz hat: Jetzt ist ein guter Zeitpunkt, die Role Assignments zu reviewen und den Suspend/Restore-Workflow in den internen Support-Prozess aufzunehmen. Und wer noch überlegt, MHS für ein Kiosk-Deployment einzusetzen: Diese Verbesserung macht es noch attraktiver – gerade wenn kein dediziertes Vor-Ort-Admin-Team zur Verfügung steht.

💡 Mein Fazit: Kleine Permissions, große Wirkung. Wer 100+ Kiosk-Geräte ohne dediziertes Admin-Team vor Ort supportet, wird diese Änderung lieben. Der Help Desk kann jetzt genau das tun, wofür er da ist – Probleme lösen – ohne bei jedem Kiosk-Issue einen Global Admin klingeln zu müssen.

🔗 Quellen & weiterführende Links:

• M365 Admin – Originalmeldung MC1213781: m365admin.handsontek.net

• Microsoft Learn – Configure Managed Home Screen App: learn.microsoft.com/intune/apps/app-configuration-managed-home-screen-app

• Microsoft Learn – RBAC with Microsoft Intune: learn.microsoft.com/intune/fundamentals/role-based-access-control

• Microsoft Tech Community – MHS Setup Guide (Kiosk Mode): techcommunity.microsoft.com

• Systunation – The Incredible Managed Home Screen: systunation.com/the-incredible-managed-home-screen-mhs-of-intune