Intune Release 2606: macOS-Updates im Autopilot, Android Enterprise wird erwachsen
Mal ehrlich – wer kennt das nicht? Sie spielen neue macOS-App-Versionen ein, und die Nutzer vergessen grundsätzlich, auf „Install“ oder „Reinstall“ in Company Portal zu klicken. Die Release 2606 setzt dem ein Ende. Aber das ist nur die Spitze des Eisbergs. Diese Week ist vollgepackt mit Updates, die vor allem macOS-Admins und Android Enterprise-Spezialisten freuen werden.
Lass mich durchgehen, was sich ändert und wo du handeln musst.
Quick-Überblick: Was ändert sich?
Feature
Plattform
Kategorie
Priorität
macOS PKG Auto-Updates
macOS
App Management
🔴 Hoch
ChatGPT als Protected App
Alle
App Management
🟡 Mittel
EAM für GCC High/DoD
Windows
Enterprise Management
🔴 Hoch
EAM Auto-Update-Feature
Windows
App Management
🟡 Mittel
15+ neue Android Enterprise Settings
Android
Device Config
🟢 Standard
Die Highlights im Detail
🍎 macOS PKG Apps updaten sich jetzt selbst
Das ist echte Arbeitserleichterung: Wenn du eine verfügbare macOS PKG-App mit einer neueren Version hochlädst, deployt Intune das Update automatisch auf Geräte, auf denen die App bereits installiert ist.
Das funktioniert so:
– Du editierst eine bestehende App-Policy
– Lädst eine neuere Version der gleichen App hoch (gleiche Bundle ID)
– Intune erkennt das und rolled den Update automatisch aus
– Der Nutzer klickt nirgendwo auf „Install“ – es passiert einfach
Wichtig – Breaking Change:
Dafür brauchst du Microsoft Intune management agent for macOS Version 2606.013 oder neuer. Wenn Geräte noch älter sind, funktioniert der Auto-Update nicht. Das sollte in deiner Pre-Deployment-Checklist stehen.
Praktisches Beispiel:
Du hast Microsoft Edge 127.0 deployed. Jetzt kommt 127.0.1 raus. Du lädst die neue Version hoch → Intune pusht’s automatisch. Schluss mit Suppor-Tickets „Warum hab ich noch die alte Version?“
🤖 ChatGPT ist jetzt eine Protected App
Microsoft hat ChatGPT zur Liste der Protected Apps hinzugefügt. Das bedeutet, es unterliegt jetzt Intune App Protection Policies (APP) – Conditional Access, Offline-Sperren, Clipboard-Restrictions et cetera.
Das ist ein Signal: KI-Tools werden zunehmend ernst genommen in der Enterprise-Sicherheit. Wenn du sensible Daten schützen musst, kannst du ChatGPT jetzt granular steuern, ohne es zu blocken.
🏛️ Enterprise App Management jetzt auch für GCC High & DoD
Das ist Government-spezifisch wichtig: Microsoft bringt Enterprise App Management (EAM) in die GCC High (GCCH) und DoD Cloud-Umgebungen.
Was heißt das?
Gouvernementale Organisationen können jetzt im EAM-Katalog Microsoft- und Third-Party-Apps entdecken, deployen und updaten – ohne manuelle Repackaging. Ein sichere Cross-Cloud-Integration wahrt Compliance-Grenzen und Auth-Requirements für Government Tenants.
Impact für Government IT-Admins:
– Weniger manuelle App-Packaging-Arbeit
– Native Compliance mit FedRAMP/DoD-Anforderungen
– Schnellere App-Rollouts in sensitiven Umgebungen
⚡ EAM Auto-Update – Supersedence auf Autopilot
Neben GCC-Support kommt auch Auto-Update für EAM-Apps. Wenn du ein EAM-App mit required Assignment deployst und Auto-Update aktivierst:
Intune erkennt eine neue Version im EAM-Katalog
Update wird automatisch auf Zielgeräten installiert
Keine manuellen Packaging-/Supersedence-Workflows mehr
Das spart:
– Zeitaufwand für Update-Management
– Fehleranfälligkeit durch manuelle Versionsersetzung
– Sicherheitslücken durch veraltete Apps
Wichtig: Das gilt nur für required Assignments. „Available“ Apps musst du noch manuell managen (das ist absichtlich, damit Nutzer die Kontrolle behalten).
🤖 Android Enterprise: 15+ neue Settings im Settings Catalog
Das ist die große Erweiterung: Intune 2606 bringt etwa 15 neue Android Enterprise Settings in den Settings Catalog. Hier die wichtigsten Kategorien:
Applications
Block apps from exposing app functions – Verhindert, dass verwaltete Apps Funktionen für andere Apps/KI-Agenten freigeben (COBO, COSU, COPE)
Block widgets from work profile apps – Widgets aus Work-Profile-Apps vom Home Screen blockieren (COPE)
Connectivity (neu in 2606)
Allow selection of a preferential network service – Priorisiert bestimmte Netze (z.B. 5G Enterprise Slice)
Block airplane mode – Flugzeugmodus deaktivieren
Block cellular 2G – Nur auf Android 14+; verhindert 2G-Fallback
Block configuring cell broadcasts – Notfall-Alerts blockieren (⚠️ – das kann problematisch sein!)
Block configuring mobile networks – Nutzer darf Netz-Settings nicht ändern
Block configuring VPN – VPN-Konfiguration durch Nutzer verhindern
Meine Einschätzung: Das sind Sicherheits-Heavy-Hitter, besonders für:
– Kiosk-Devices (COSU) – Printing, Calls, SMS sperren
– Rugged Devices – 2G-Block, UWB-Control
– BYOD-ähnliche Szenarien (COPE) – Granulare Widget-Kontrolle
That’s it. Microsoft macht aktuell echt viel in Intune und versucht sich einer Omnissa mit großen Schritten zu nähern. Aber alles in allen. Omnissa rennt weiter und ist bis dato für mich immer noch das Top of the Top UEM/MDM.
Intune Release 2605: Multiple Accounts, Apple Intelligence Umbruch & MHS-Power-Up
Die Juni-Release 2605 fällt mir sofort durch zwei Dinge auf: Da kommt endlich Multi-Account-Support für Teams (nur iOS/iPadOS – Android schaut in die Röhre), und Apple dreht bei Intelligence-Einstellungen ordentlich am Rad. Wer noch alte MDM-Restrictions für Apple Intelligence setzt, muss sich umorientieren. Dazu neue MHS-Features, die Kiosk-Szenarien smarter machen. Lass uns durchgehen, was sich ändert.
Quick-Überblick: Was ändert sich?
Feature
Plattform
Kategorie
Priorität
Multiple Managed Accounts
iOS/iPadOS (Teams)
App Management
🟡 Mittel
Custom Top Bar (MHS)
Android Enterprise
Device Config
🟡 Mittel
MHS Lock Task Password Migration
Android Enterprise
Breaking Change
🔴 Hoch
Block Bluetooth Sharing
Android Enterprise
Device Config
🟢 Niedrig
Apple Intelligence Settings Deprecation
iOS/iPadOS, macOS
Breaking Change
🔴 Hoch
App Silencing (MHS)
Android Enterprise
Device Config
🟡 Mittel
Microsoft Edge NTP Feed Settings
Windows
Device Config
🟢 Niedrig
Die Highlights im Detail
Multiple Managed Accounts für Microsoft Teams (iOS/iPadOS)
Das ist endlich praktisch: Nutzer können jetzt mehr als ein verwaltetes Konto in derselben App (konkret: Teams) hinzufügen und managen. Jedes Konto bekommt eigene App Protection Policies – perfekt für:
Berater & Consultants mit Kundenzugängen
M&A-Teams mit mehreren Tenant-Zugehörigkeiten
Multi-Mailbox-Szenarien (Compliance, HR, etc.)
Aktuell nur Teams v8.10.0+ auf iOS/iPadOS. Android und weitere Apps folgen später – das ist ein klassisches „Coming Soon“. Rollout erfolgt graduell, also nicht bei allen Tenants sofort verfügbar.
Custom Top Bar Text in Managed Home Screen
Die MHS bekommt mehr Flexibilität: Statt nur Serial Number, Device Name und Tenant Name kannst du jetzt Custom Text (bis 63 Zeichen) setzen. Bonus: Dynamic Variables werden unterstützt:
Früher konntest du das **Lock Task Mode Password** für MHS über **App Configuration Policy** setzen. Das funktioniert jetzt **nicht mehr**. Du musst auf **Device Configuration Profile** wechseln
Docs: Configure the Microsoft Managed Home Screen app for Android Enterprise (Microsoft Learn)
Block Bluetooth Sharing – Neue Android Settings Catalog Policy
Settings Catalog bekam ein neues Boolean-Setting: Block Bluetooth Sharing
True: Device blockiert Bluetooth-Sharing
False: Keine Änderung (OS-Default bleibt)
OS-Defaults aktuell:
– COBO & COSU: Bluetooth Sharing erlaubt
– COPE: Bluetooth Sharing blockiert
Nutzen: Falls du eine konsistente Sharing-Policy across all AOSP-Devices brauchst.
Applies to: COPE, COBO, COSU
🔴 BREAKING CHANGE: Apple Intelligence Settings werden deprecated
Das ist der große Umbruch: Apple hat in iOS/iPadOS 26.4 viele Intelligence-Settings aus dem MDM Restrictions Payload entfernt. Microsoft folgt jetzt nach und depreciert diese Settings in Intune:
Betroffene Settings in Device Restrictions Template:
– Built-in apps: Siri (alle Varianten), User-Generated Content
– Keyboard & Dictionary: Word Definition, Predictive Keyboards, Auto-Correction, Spell Check, Keyboard Shortcuts, Dictation
Die neue Lösung:DDM Configurations (ab März 2026 released)
Applies to: iOS/iPadOS, macOS
App Silencing in Managed Home Screen (MHS)
Neue Security-Feature für Kiosk-Umgebungen: Wenn MHS den User zur Authentication auffordert (Sign-in, Session PIN), können Apps jetzt silenced werden. Das heißt:
Keine Activity Starts
Keine Notifications
Nicht in Recent Apps sichtbar
Keine Toasts, Dialogs oder Device Ringing
Mit Allowlist: Kritische Apps (z.B. Phone/Calls) können du in der Allowlist behalten, damit Telefonate nicht unterbrochen werden.
Szenario: Checkout-Geräte in Supermärkten – während der PIN-Authentifizierung kann Werbung/Notifications nicht ablenken. Nach Unlock: Normal.
Applies to: Android Enterprise (alle Varianten)
Microsoft Edge 148 Settings im Windows Settings Catalog
Zwei neue NTP (New Tab Page) Policies für Edge 148:
1. ConfigureNTPFeedTabVisibility
– EnableBothWorkDiscover (Default): Beide Tabs sichtbar
– EnableOnlyWork: Nur Work Feed
– EnableOnlyDiscover: Nur Discover Feed
2. Default NTP Feed Tab
– Work (Default)
– Discover
Nutzen: Für Enterprises, die ihren Mitarbeitern nur unternehmensrelevante Inhalte auf der Edge New Tab Page zeigen wollen.
Applies to: Windows 10 and later
Handlungsbedarfe
🔴 KRITISCH – Apple Intelligence Migration (iOS/iPadOS, macOS)
Timeline: Beginn jetzt, Abschluss bis Ende Q3 2026
Action: Migrate alte Intelligence-Restrictions zu DDM Configs
Fallback: Alte Policies funktionieren noch, aber sind deprecated
Testing: Wie funktionieren Custom App Protection Policies mit Multi-Account?
Scope: Android-Support kommt später – nicht sofort erwarten
🟡 OPTIONAL – Custom MHS Top Bar & App Silencing
Timeline: Nächster Kiosk-Deployment
Action: ROI-Check für deine Kiosk-Szenarien
Use Cases: Checkout, Konferenzraum-Displays, Public Kioske
Fazit
Release 2605 ist ein Mixed Bag:
✅ Das Gute:
– Multiple Managed Accounts endlich für Teams = echte Productivity-Gewinne
– MHS-Features (Custom Top Bar, App Silencing) machen Kiosk-Deployment smarter
– Edge & Bluetooth Settings geben mehr Granularität
⚠️ Das Kritische:
– Apple Intelligence Deprecation ist ein echtes Project – du musst zu DDM migrieren
– MHS Lock Task Password erfordert Policy-Rewrite – das ist Arbeit
– Gradueller Rollout bedeutet: Nicht alle Features sind sofort da
iOS 27 und Workspace ONE: DDM-Migration – Der Schrittplan für deutsche Admins
Apple hat auf der WWDC 2026 den Startschuss gegeben – iOS 27 kommt im September. Für dich als Admin bedeutet das: Legacy MDM ist offiziell Geschichte. Hier bekommst du alles, was du wirklich wissen musst.
💡 Das Wichtigste in 30 Sekunden
iOS 27 erscheint September 2026 – Legacy MDM Update-Commands funktionieren danach NICHT mehr.
DDM (Declarative Device Management) ist ab iOS 27 Pflicht für Software-Update-Enforcement.
Workspace ONE UEM 2406+ unterstützt DDM für iOS – du brauchst mindestens diese Version.
Bestehende Profile und Policies bleiben unberührt – nur Update-Management muss migriert werden.
Die Siri AI kommt in der EU NICHT auf iOS 27 (Digital Markets Act) – vorerst nur auf macOS 27.
Was Apple auf der WWDC 2026 angekündigt hat
A m 8. Juni 2026, hat Apple auf der Worldwide Developers Conference in Apple Park iOS 27 offiziell vorgestellt. Der Fokus lag klar auf KI – konkret auf einem von Googles Gemini-Modell betriebenen Siri. Aber für uns Admins ist etwas anderes der eigentliche Knackpunkt:
iOS 27 unterstützt alle Geräte, die aktuell iOS 26 laufen – auch das iPhone 11 und neuere.
Apple Intelligence läuft nur auf iPhone 15 Pro, iPhone 16 und iPads/Macs mit M1 oder neuer.
Legacy MDM Update-Commands (ScheduleOSUpdate, OSUpdateStatus) werden mit iOS 27 komplett ignoriert.
DDM ist ab sofort Standard – nicht optional, nicht „demnächst“, sondern jetzt.
⚠️ Wichtig für die EU / Deutschland
Siri AI wird auf iOS 27 und iPadOS 27 in der EU NICHT verfügbar sein.
Apple begründet das mit dem Digital Markets Act (DMA).
Auf macOS 27, watchOS 27 und visionOS 27 ist Siri AI hingegen auch in der EU verfügbar.
Für Unternehmensumgebungen in Deutschland bleibt der operative Betrieb unverändert.
DDM vs. Legacy MDM – Was hat sich eigentlich geändert?
Der Unterschied zwischen Legacy MDM und DDM ist kein Buzzword – er ist architektonisch. Kurz gesagt:
Merkmal
Legacy MDM (alt)
DDM – Declarative Device Management (neu)
Steuerung
Server schickt Befehle, Gerät führt aus
Server definiert Zielzustand, Gerät kommt selbst dahin
Software Updates
ScheduleOSUpdate-Command
Software Update Enforcement Declaration
Check-in Abhängigkeit
Ja – Command-Delivery muss klappen
Nein – Gerät arbeitet eigenständig
Fehlertoleranz
Gering (kein Check-in = kein Update)
Hoch (Gerät retried eigenständig)
Statusreporting
Nur nach Command-Ausführung
Kontinuierlich via Status-Channel
iOS 27 kompatibel?
NEIN – Commands werden ignoriert
JA – vollständig unterstützt
Nutzer-Benachrichtigung
Einmalig
Mehrfach, Wochen im Voraus
ℹ️ Wie DDM intern funktioniert
Beim alten MDM: Workspace ONE schickt „Update jetzt!“ – und wartet.
Bei DDM: Workspace ONE erklärt den gewünschten Zustand (z.B. „iOS 27.0 bis 15.09.2026“).
Das Gerät übernimmt die Verantwortung, diesen Zustand zu erreichen.
Kein Check-in? Kein Problem – beim nächsten Kontakt macht das Gerät weiter.
Schlechte Verbindung? Das Gerät retried ohne serverseitigen Eingriff.
Workspace ONE UEM und DDM – Was du jetzt brauchst
Die gute Nachricht: Omnissa hat seine Hausaufgaben gemacht. DDM ist kein Zukunftsprojekt mehr – es ist fertig. Hier der aktuelle Stand:
Beide Typen: Imperative und Declarative Profiles parallel möglich
Für On-Premises Kunden: Wenn ihr noch auf WS1 UEM 2306 oder älter seid, müsst ihr bis September 2026 auf mindestens 2406 upgraden – sonst habt ihr nach dem iOS 27 Rollout keine Kontrolle mehr über Software Updates auf iOS-Geräten.
⚠️ On-Premises Admins: Handlungsbedarf jetzt
WS1 UEM 2306 und älter: Kein DDM-Support.
Legacy Update-Commands funktionieren nach iOS 27 Release nicht mehr.
Upgrade auf mindestens WS1 UEM 2406 ist Pflicht vor September 2026.
SaaS-Kunden sind automatisch auf dem aktuellen Stand – kein Handlungsbedarf.
Schrittplan: Migration auf DDM in Workspace ONE
Hier ist der praxiserprobte Schrittplan – inklusive Timeline für September 2026:
Schritt 1: WS1 UEM Version prüfen (Sofort)
Prüfe deine aktuelle WS1 UEM Version unter System > General > Product Information.
SaaS: Ihr seid automatisch aktuell.
On-Premises: Ihr braucht mindestens Version 2406.
Ist deine Version älter als 2406, startet den Upgrade-Prozess asap. Bei Fragen, wende dich an deinen Dienstleister des Vertrauens.
In der Workspace ONE Console navigierst du zu Resources > Profiles > Add Profile > iOS. Jetzt siehst du eine neue Option:
2. Platform: iOS
3. Management Type: Declarative <– neu seit WS1 2406
4. Declaration Type: Configuration
Schritt 4: Testen und Validieren (Woche 3–4)
Beobachte den Status-Channel in WS1 – das ist das neue Herzstück von DDM:
Devices > Device Details > [Gerät] > DDM Status
Prüfe, ob die Declaration korrekt zugewiesen wurde.
Nutzer bekommen jetzt automatisch Benachrichtigungen auf dem Gerät.
Validiere das Update nach Enforcement-Datum.
Schritt 5: Rollout auf Produktion (August 2026 – vor iOS 27)
Sobald der Test stabil läuft, rollt ihr die DDM Declarations auf alle iOS-Geräte aus. Folgende Empfehlung für Timing:
Phase
Zeitraum
Aktion
Vorbereitung
Juni 2026
WS1 Version prüfen, Inventarisierung, Test-Declarations erstellen
Pilot
Juli 2026
DDM auf 10–20% der Geräte (IT-Team, Power User)
Rollout Welle 1
August 2026
DDM auf 50% der Geräte, Legacy Policies parallel aktiv lassen
Vollständig
Vor September 2026
DDM auf 100% der Geräte aktiv
iOS 27 Release
September 2026
iOS 27 erscheint – nur DDM Devices bekommen kontrollierten Update-Rollout
Legacy Cleanup
Oktober 2026
Alte Legacy Update Policies aus WS1 entfernen
Achtung: TLS-Verschärfung in iOS 27
iOS 27 und macOS 27 erzwingen strengere TLS-Anforderungen für Systemprozesse. Das ist ein separates Thema, aber ein kritisches – insbesondere für On-Premises WS1-Umgebungen mit eigenen PKI-Infrastrukturen:
⚠️ TLS-Kompatibilität prüfen
iOS 27 erzwingt via neuen ProfileAssetReference-Key strengere TLS-Anforderungen.
Betroffen sind Systemprozesse, die HTTPS-Verbindungen zu internen Servern aufbauen.
Prüft eure internen CA-Zertifikate auf SHA-256 Signatur und ausreichende Key-Länge.
Besonders kritisch: On-Premises WS1 mit eigener PKI (z.B. D-Trust, Microsoft CA).
Test-Enrollment mit iOS 27 Developer Beta empfohlen, sobald verfügbar.
Best Practices für deutsche Admins
Migrationszeitpunkt: Nicht bis September warten. Jetzt anfangen.
Test-Gruppe aufbauen: 3–5 Geräte, mindestens iOS 16+, verschiedene Modelle.
Legacy Policies nicht sofort löschen: Koexistenz nutzen, erst nach validiertem DDM-Rollout aufräumen.
Status-Channel auswerten: Das ist euer neues Dashboard für Update-Compliance.
Nutzer-Kommunikation planen: DDM schickt automatisch Benachrichtigungen – stimmt das Timing mit eurer IT-Policy ab.
On-Prem: Seed-Script für neue iOS-Versionen von Omnissa Connect herunterladen (beta-Unterstützung).
TLS-Audit jetzt: Interne CA-Zertifikate auf iOS 27 Kompatibilität prüfen.
Häufige Fehler – und wie ihr sie vermeidet
Fehler
Auswirkung
Lösung
WS1 Version < 2406
Kein DDM möglich
Upgrade auf 2406 oder neuer vor September
Legacy + DDM ohne Priorität beachten
Unerwartetes Verhalten
DDM Override verstehen: DDM Declaration gewinnt immer
Enforcement Date zu früh gesetzt
Nutzer werden überrascht
Mindestens 2 Wochen Vorlauf einplanen
TLS-Zertifikate nicht geprüft
Enrollment-Fehler nach iOS 27 Upgrade
CA-Zertifikate vor Release prüfen
iOS 27 Beta ignoriert
Keine Vorwarnung bei Problemen
Jetzt Developer Beta testen
Und zur guter letzt nochmal der Hinweis. WS1 On-Prem ist zum 30.04.2027 abgekündigt und EOL! Hier wird Omnissa keine Grace-Periode geben. Somit ist hier Handlungsbedarf, da ich Migration in die SaaS mehrere Wochen benötigt.
ich hatte es ja versprochen und nun kommt mein Artikel zum neuen 2604. Geile release Nummer by the Way (kleiner Insider 🤩). Das 2604 Release ist einer der expansivsten der letzten Zeit und baut auf dem Momentum der 2602 auf . Und ehrlich? Das ist die Release, auf die viele von euch gewartet haben. Windows Server endlich im UEM-Universum, macOS-Admins können die Verpackungsorgie lassen, und mit Vulnerability Defense gibt’s jetzt auch nen CrowdStrike-Integration (mir stellen sich die Nackenhaare auf 🤯🤓, aber das ist eher ein persönliches Problem mit CrowdStrike wieder so ein Insider), die tatsächlich Sinn macht.
Ich bin mir aber auch bewusst: Das ist eine Broadcom/KKR-Omnissa, die hier liefert. Die Richtung stimmt, die Features sind solid – aber wir beobachten weiterhin kritisch, wie stabil das bleibt und ob OEMConfig, Rugged und DEX im Fokus bleiben.
Lass mich ein paar Stunden recherchiert haben und dann durch die Features nehmen.
Übersichtstabelle: Features nach Kategorie
Feature
Plattform
Kategorie
Status
Windows Server Management (Enroll 2016+)
Windows Server
Infrastructure
GA
Granular Patch Management
Windows Server
OS Management
GA
Vulnerability Defense (CrowdStrike Integration)
Windows
Security
Limited Availability
Enterprise App Repository (macOS)
macOS
App Management
GA
Platform SSO in Setup Assistant (ADE)
macOS, iOS
Enrollment
Limited Availability
App Preservation during MDM Migration
iOS/iPadOS 26+
App Lifecycle
GA
Redesigned UEM Console
All
UI/UX
GA
Phased Deployments (Percentage-based)
All
Deployment
GA
Ansible in Custom Config Profiles
Linux
Configuration
GA
Device Update Profile (SUSE Linux)
Linux (openSUSE, SLED, SLES)
OS Updates
GA
Platform-specific ADE Default Profiles
iOS, macOS
Enrollment
GA
Application Removal Protection Improvements
iOS
App Security
GA
Die Top Features im Detail
🖥️ Windows Server Management – Jetzt generell verfügbar (GA)
Das ist die Headline: Windows Server Management ist nun generell verfügbar in Workspace ONE UEM und bringt Server-Infrastruktur in die gleiche Management-Ebene wie der Rest der Endpoint-Flotte .
Konkret:
Enroll Windows Server 2016 oder später via Intelligent Hub, und sie tauchen neben deinen Desktops auf mit Server-spezifischen Details wie installierten Rollen und Features
Du kannst die Tools nutzen, die du schon kennst: ADMX-Profile mit vorgeladenen Templates, Baselines für automatische Config-Refresh, granulare OS-Patching mit Scheduling, vollständiges App-Lifecycle-Management via Enterprise Application Repository, und Freestyle Orchestrator für Automation
Remote Support funktioniert auch: Screen Share, File Access, Command Line – genauso wie bei Desktops
Das ist clever gedacht von Omnissa. Jahrelang haben Server-Teams separate Tools gebraucht. Jetzt ist die Frage: Wie tief geht das? Die ADMX-Integration und das Patching-Handling hören sich solide an. Aber ich warte auf Real-World-Reports zu Skalierungsfragen – einen 5.000er Server-Fleet mit WS1 zu patchen ist nochmal ne andere Hausnummer als Desktops.
Granular Patch Management: Du kannst spezifische Updates aus dem Windows Update Catalog suchen und selektieren, sie auf definierte Server-Gruppen zielen und die Deployment innerhalb deinem Timeframe planen. Du kannst sogar Updates vorab herunterladen, damit die Installation sofort startet, wenn die Zeit kommt .
Workspace ONE Vulnerability Defense tritt in Limited Availability ein und bringt einen kompletten Assessment-to-Remediation-Workflow direkt in die Omnissa Platform für Windows Endpoints. Die Lösung integriert WS1 UEM mit CrowdStrike Falcon Exposure Management, um die Lücke zwischen Vulnerability Management, Exposure Discovery und Remediation zu schließen .
Der Workflow:
Wenn ne CVE oder High-Risk-Bedingung identifiziert wird, mapped WS1 UEM das automatisch zu betroffenen Endpoints für schnelle Risk-based Priorisierung
Empfohlene Remediation Paths werden direkt in der Admin-Console angezeigt, zusammen mit vorkonfigurierten Updates aus dem Enterprise App Repository. Patches und App-Updates werden über UEM ausgeliefert und IT-Teams können den Remediation-Progress monitoren
Die Integration mit CrowdStrike ist clever – Falcon hat etablierte Visibility, und jetzt hast du direkt im UEM-Portal die Remediation-Automation. Das reduziert Ticket-Ping-Pongs massiv. Aber: Limited Availability heißt, das ist noch nicht für alle da. Warte auf GA, bevor du architektural darauf planst. Und der CrowdStrike-Lizenz-Stack ist nicht zu unterschätzen.
🍎 Enterprise App Repository (macOS) – Jetzt GA
Das war lange überfällig. Workspace ONE UEM launcht die Enterprise App Repository (EAR) für macOS – ein kuratierter Katalog von beliebten Applikationen, der Deployment und laufende Verwaltung streamlined .
Praktisch:
Admins können Apps aus dem Repository direkt in der UEM-Console selektieren und sofort in Device-Gruppen deployen – kein manuelles Packaging nötig
Updates werden automatisch gehandhabt, und Notifications halten Admins informiert, wenn neue Appversionen verfügbar sind
Das App-Repository integriert nativ mit bestehenden UEM Assignment Workflows – Deployment passiert wie mit jeder anderen verwalteten App
Endlich. macOS-Admins hatten bisher ne Lücke: Android und iOS haben ihre App-Kataloge, aber macOS-Packaging war immer ne Sandbox, wo man sich selbst überlassen war. Mit der EAR kriegt ihr da Consistency. Die Frage ist: Wie groß ist der Katalog wirklich? Und können Custom Apps dazukommen? Aber für die Top-Use-Cases (Office, Teams, Browser, Dev-Tools) ist das jetzt ein echter Gewinn.
🔐 Platform SSO beim Setup Assistant (ADE) – Limited Availability
Platform SSO kann jetzt direkt im Setup Assistant während Automated Device Enrollment (ADE) konfiguriert werden. Wenn ein Device ADE durchläuft, authentifizieren sich User mit ihrem Org-Identity-Provider und erstellen ihren ersten Local Account – alles während Initial Setup, bevor das Device übergeben wird. Keine zusätzlichen Schritte, kein separater Profile Push .
Das Resultat ist eine cleanere Onboarding-Experience und eine stärkere Security-Baseline von Tag 1 .
Das ist die richtige Richtung. Zero-Touch Enrollment mit PSSO on Day 0 – das war der USP von großen Apple-Lösungen, und jetzt kann WS1 das auch. Noch im Limited Availability Status, aber sobald das GA ist, sollte das zum Standard gehören für neue Mac-Enrollments.
📱 App Preservation during MDM Migration (iOS 26+)
Workspace ONE UEM führt granulare App Preservation während MDM Migration für iOS/iPadOS 26+ Devices ein .
Das Szenario: Du migrierst eine Flotte von nem anderen MDM zu WS1? Früher wurden die Apps gelöscht und neuinstalliert – Friction für User, Komplexität für IT. Jetzt können Apps erhalten bleiben.
Praktisch für größere Migrations-Szenarien. Aber iOS 26+ ist ne spezifische Anforderung – für ältere Devices musst du weiterhin mit App-Reinstall rechnen.
🖼️ Redesigned UEM Console – Now GA
Die neu designte WS1 UEM Admin-Console ist jetzt generell verfügbar. Sie ist auf einem modernisiertem Tech-Stack gebaut, geprägt von iterativem User Research und Testing. Die neue Experience reorganisiert Navigation in logischere Kategorien, stellt die meistgenutzten Features in den Vordergrund, und ersetzt Labels, die Institutional Knowledge brauchten, durch Sprache, die sofort klar ist .
UI-Überarbeitungen sind immer zweischneidig. Manche Admins haben Jahrzehnte in der alten Console gelebt. Aber wenn das Research-driven ist und auf Usability-Testing basiert, sollte das okay sein. Wird schnell klar, ob das wirklich besser ist oder nur anders. Ich bin gespannt drauf.
📊 Phased Deployments mit Percentage-based Rollout – GA
Phased Deployments sind jetzt GA, und diese Release fügt ne neue Capability hinzu: Admins können jede Phase jetzt nach Prozentanteil der Zielgruppe definieren, statt Gruppen explizit zu spezifizieren .
Praktisch: „Rollout an 10% → 25% → 50% → 100%“ ohne dass du Gruppen manuell aufteilen musst.
Das ist ein DLP-Playing-Field. Apple hat das via MDM-Restrictions seit Jahren, Microsoft Intune auch. Jetzt kann WS1 auch prozentual rollout – das ist gut.
🐧 Ansible in Linux Custom Config Profiles + SUSE Update Management
Zwei Linux-Highlights:
Ansible Support: Enterprise Linux Environments vertrauen oft auf Ansible für Configuration Management. In 2604 bringt WS1 UEM diese Capability direkt ins Custom Configuration Profile. Ansible ist jetzt neben Bash, Python und Puppet als unterstützter Payload-Type verfügbar. Admins können Ansible Playbooks nutzen, um enrolled Linux Devices zu konfigurieren, mit Support für Ansible Collections und Roles .
Device Update Profile für SUSE: Das Device Update Profile erweitert sich auf SUSE-basierte Linux Devices (openSUSE, SLED, SLES). Admins können das Level und die Frequenz von automatischen Updates konfigurieren, Security- und Policy-spezifische Update Rules, und Notifications für neue Major OS Versions .
Das ist solider Enterprise-Linux-Support. Ansible ist das Orchestration-Tool, und wenn WS1 das nativ unterstützt, brauchst du weniger Custom Integrations. Für SUSE-Shops ist das dann ne große Erleichterung.
Ein Clarity-Feature: Admins können jetzt platform-spezifische Default ADE Profiles assignen. iOS und macOS können unterschiedliche On-Boarding-Profile haben, ohne dass man überall Conditional Logic bauen muss.
⚠️ Handlungsbedarfe & Deprecations
Vulnerability Defense: Limited Availability Status
Vulnerability Defense ist noch nicht GA. Wenn du das architekturiert, solltest du mit dem Omnissa-Account-Team aligned sein. Das kann sich bis GA noch verschieben.
CrowdStrike-Lizenzierung
Wenn du Vulnerability Defense einführen willst, brauchst du nicht nur WS1 UEM, sondern auch CrowdStrike Falcon Exposure Management. Das ist ein separater Lizenzstack – kalkuliere das mit in deine TCO.
Windows Server 2016+ Requirement
Windows Server Management funktioniert nur ab 2016. Wenn du ältere Server-Flotten hast (2012 R2, 2008 R2), brauchst du weiterhin separate Tools.
iOS 26+ für App Preservation
App Preservation during Migration funktioniert nur auf iOS/iPadOS 26+. Ältere Devices haben weiterhin App-Wipe während Migration.
Vergleich zu Microsoft Intune: Wo WS1 Vorteile hat
Der 2604 Release ist eines der expansivsten in letzter Zeit und baut auf 2602-Momentum auf . Wenn du Intune mit WS1 vergleichst:
Intune Release 2604 – Die wichtigsten Neuerungen (KW 27.04.2026)
🤔 Was mir an dieser Release auffällt
Ehrlich gesagt, die 2604er Release ist bemerkenswert solide. Keine großen Breaking Changes, aber dafür drei sehr sinnvolle Punkte, die ich täglich in Kundenprojekten höre:
EPM endlich für alle User – bisher war das ein nerving restrictions für Shared Devices (Kiosk, Hotspot-Devices)
Android 14: Credential Manager-Kontrolle – das schreit geradezu nach Zero-Trust-Architektur
Vision Pro & Apple TV management – ok, nichts für den Massenmarkt, aber für Specialized Use Cases ein Game-Changer
Lass mich die Details durchkauen.
📊 Feature-Übersicht: Was sich ändert
Feature
Plattform
Kategorie
Wichtigkeit
EPM: Support-approved Elevation für alle User
Windows
Security/Privilege Mgmt
🔴 High
Android 14: Credential Manager Permissions
Android Enterprise
Device Config
🔴 High
Location Services Settings Katalog (neu)
Android Enterprise
Device Config
🟡 Medium
Apple Access Management (ABM/ASM)
iOS/macOS
Enrollment/Access
🟡 Medium
visionOS & tvOS ADE Support
visionOS/tvOS
Enrollment
🟡 Medium
Ubuntu 26.04 LTS Support
Linux
Device Management
🟡 Medium
Neue Device Page (Public Preview)
All
UI/UX
🟢 Low (UX)
EPM: Suspend/Restore für Managed Hosting
Windows
Device Management
🟡 Medium
🔧 Die wichtigsten Features im Detail
1️⃣ Endpoint Privilege Management (EPM): Support-Approved Elevations für ALLE User
Vorher:
– Support-approved file elevation requests funktionieren nur für:
– Den Primary User des Devices
– Den User, der das Device enrolled hat
– Auf Shared Devices (Hotspot, Kiosk, Hoteling): komplettes Blockkade
Nachher (2604):
– Alle User auf einem Device können Support-Approved Elevation Requests stellen
– Der Support-Admin muss nicht mehr jonglieren, welcher User gerade logged ist
Szenarios wo das hilft:
– Shared Hotspot-Geräte in Logistik-Hubs
– Kiosk-Modus für Retail/Hospitality
– Hot-Desking in großen Büros
Vorsicht: Das ist ein Feature von Intune Suite – nicht im Standard-Intune Plan 1 enthalten. Kosten-Impact checken!
2️⃣ Android 14+: Credential Manager Permissions – Das Security-Highlight
Das Problem:
– Android 14 blockt standardmäßig Third-Party Credential Provider auf Corporate Devices
– Passkey-Adoption scheitert, weil kein Custom Password Manager nutzbar ist
– Microsoft Authenticator kann nicht als Default-Provider fungieren
Die Lösung (2604):
Neue Config im Intune Admin Center:
Was du hier steuern kannst:
✅ Spezifische Apps als System-Credential-Provider zulassen
✅ Passkey-basierte Sign-in aktivieren
✅ Nur vertraute Credential Sources erlauben
❌ Google Password Manager bleibt blockiert (Known Limitation!)
Unterstützte Device Types:
– Android COBO (Fully Managed)
– Android COSU (Dedicated)
– Android COPE (Corporate-Owned Work Profile)
– Android BYOD mit Work Profile (AM API)
Meine Einschätzung:
Das ist Zero-Trust für Android. Du kannst jetzt explizit definieren: „Nur Microsoft Authenticator + 1Password dürfen Passkeys speichern.“ Game-changer für Finance/Legal-Geräte.
⚠️ Warnung: Google Password Manager funktioniert nicht – musst du in deinen Rollout-Docs erwähnen!
3️⃣ Android Enterprise: Location Settings – Mehr Granularität
Neu (war vorher Binary-Block):
Drei Optionen statt Ja/Nein:
Option
Verhalten
Use Case
Device default
OS-Standard, User kann togglen
Flexible Policies
Location enabled
Erzwungen an, User kann nicht aus
Fleet Tracking, Delivery
Location disabled
Erzwungen aus, User kann nicht an
High-Security Devices
Gilt für:
– Android 10 und älter (COPE, COBO, COSU)
Warum sag ich dir das?
Der alte „Block location“ Setting war ein Sledgehammer. Jetzt kannst du differenzieren: Fleet-Devices tracken, Admin-Devices privat halten.
4️⃣ Apple Access Management (neu) – For ABM/ASM Admins
Was ist neu:
– Direkt in Apple Business Manager / Apple School Manager konfigurierbar
– Du steuert jetzt aus ABM, welche Devices ein User nutzen darf
– Welche Apps & Services verfügbar sind (z.B. App Store blockieren?)
Gilt für:
– iOS/iPadOS
– macOS
Impact für Intune Admins:
Das ist eher ein Apple-seitiges Feature. Aber wenn dein ABM Admin das nutzt, synchronisiert es mit Intune. Wichtig: In deine ABM-Onboarding-Docs aufnehmen!
5️⃣ 🎯 visionOS & tvOS ADE Support – The Future is Here
Brechen wir’s runter:
Zum ersten Mal unterstützt Intune:
– Apple Vision Pro Management
– Apple TV Management
– Ohne User Affinity (userless ADE)
Technische Details:
– Über Apple Business Manager / Apple School Manager
– Intune Plan 2 erforderlich (Teil Microsoft 365 Suite)
– Voraussetzung: tvOS 26+ oder visionOS 26+
– Custom Configuration Uploads möglich
– Enrollment Restrictions & Device Actions funktionieren
Wo erscheinen diese Devices?
Intune Admin Center → Devices → All Devices →
Apple Mobile Devices (Filter: tvOS/visionOS)
Szenarios:
– 🏥 Krankenhaus: Vision Pro für Chirurgie-Planung + MDM-Lockdown
– 🏬 Retail: Apple TV in Stores mit gepinnten Apps
– 🎓 Education: VisionOS für AR-Learning, zentral verwaltet
⚠️ WICHTIG: Keep devices updated! tvOS/visionOS 26+ = Sicherheit. Das ist kein „kann“, das ist Pflicht für deine Governance.
6️⃣ Linux: Ubuntu 26.04 LTS Support + 22.04 EOL-Warnung
Timeline:
Version
Status
Maßnahme
Ubuntu 22.04 LTS
EOL August 2026 ⚠️
Migration planen
Ubuntu 26.04 LTS
Neu supported ✅
Rollout ready
Praktisch:
Devices auf 22.04 können enrolled bleiben, aber:
1. Du solltest Upgrade-Kampagne starten
2. Im Intune Admin Center kannst du identifizieren:
Devices → All Devices → Filter: Linux → Add Column: OS Version
7️⃣ New Device Page (Public Preview) – UI/UX Facelift
Das ist in Preview – noch nicht produktiv!
Enable:
Intune Admin Center → Devices → All Devices → Toggle: „Preview new device view“
Was ändert sich:
– Single unified view für Device-Info statt 5 verschiedene Tabs
– Neue Struktur:
– Device action status – Was läuft gerade?
– Tools and reports – Compliance, Config Status, Remediations
– Properties – Editable Device Infos
– Device details – Hardware & Entra-Infos
Wichtig:
– Nur bei Devices → All Devices aktiv
– Wenn du ein Device aus Report-View öffnest → alte UI
– Keine Funktionalitäts-Changes, rein UI
Meine Einschätzung:
Langfristig überraschend gut durchdacht. Aber warte bis GA, bevor du es im Training zeigst.
🔴 CRITICAL: Google Password Manager blocked auf Android Work Profile
Was passiert:
Android COPE / BYOD Work Profile + Android 14
→ Google Password Manager funktioniert NICHT als Credential Provider
Dein Handeln:
1. Audit: Welche User nutzen Google Password Manager?
2. Communication: „Wir wechseln zu [Microsoft Authenticator / 1Password]“
3. Policy: Setze explizit authorized credential providers
4. Timeline: VOR Android 14 Roll-out implementieren!
🟠 WARNING: Ubuntu 22.04 LTS EOL August 2026
Was passiert:
Nach August 2026 keine Security Patches für 22.04
Dein Handeln:
1. Identifiziere alle Ubuntu 22.04 Devices (Filter in Intune)
2. Kommuniziere Migration zu 26.04 LTS
3. Teste 26.04 LTS in Pilot vor August 2026
4. Hardware-Check: Manche ältere Geräte unterstützen 26.04 nicht!
🟡 NOTICE: visionOS/tvOS 26+ Requirement
Was ist neu:
Apple Vision Pro & Apple TV management nur mit tvOS 26+ / visionOS 26+
Dein Handeln:
– Falls du Vision Pro pilotierst: Update-Strategie definieren
– Alte tvOS-Versionen bleiben „unmanaged“
– Monitoring: „Devices with unsupported OS version“ tracken
✅ Android Enterprise Admins (Credential Manager Control ist ein Must-Have für Security)
✅ EPM-Nutzer auf Shared Devices (endlich nicht mehr Workarounds!)
✅ Apple-Shops mit tvOS/Vision Pro Piloten
Wer kann warten (bis GA):
⏳ Reine iOS/macOS Orgs (Features sind nett, nicht game-changing)
⏳ Linux-only Shops (Ubuntu 26.04 ist Standard, 22.04 EOL ist erst Aug 2026)
⏳ Wer Device Page neue UI noch nicht braucht (noch in Preview)
Meine persönliche Einschätzung:
Nach 16+ Jahren MDM: Diese Release ist stabil und pragmatisch. Keine Überraschungen, keine großen Deprecated Features, aber echte Mehrwerte bei Android Security + Credential Management.
Das Android Credential Manager Feature verdient eure volle Aufmerksamkeit. Das ist nicht nur ein „nice-to-have“ – das ist Zero-Trust für Mobile Devices.
Rollout-Plan:
Phase 1 (Juni 2026): Pilot mit Android Credential Manager (5% Devices)
Phase 2 (Juli 2026): EPM Policies für Shared Devices updaten
Phase 3 (Aug 2026): Ubuntu 22.04 → 26.04 Migration starten
Phase 4 (Sept 2026): visionOS/tvOS in Pilot (wenn relevant)
„`
Microsoft Intune Release 2603: DDM für Apple, Recovery Lock für macOS und Linux Support
Schon wieder März – und wieder eine Release, die zeigt, wo Microsofts Reise hingeht. Diesmal hat man sich besonders Zeit für Apple DDM genommen, und das ist bedeutsam. Als jemand, der schon länger im MDM-Umfeld unterwegs ist, sehe ich hier einen wichtigen Shift: Apple zieht mit Declarative Device Management aus dem klassischen MDM-Modus raus. Das ist nicht einfach nur „noch ein Feature“ – das ändert, wie wir iOS/iPadOS Apps deployen.
Gleichzeitig bekommt macOS endlich ordentliche Recovery Lock Features, Android Enterprise kriegt neuen OEM-Support, und Linux wird erwachsen. Lass mich die wichtigsten Punkte durchgehen.
Übersichtstabelle: Was ändert sich in 2603?
Feature
Plattform
Kategorie
Status
Declarative Device Management (DDM) für Line-of-Business Apps
iOS/iPadOS 18+
App Management
✅ Verfügbar
Recovery Lock mit Password Rotation
macOS
Device Configuration
🔄 Rollout (bis Ende April)
Inventus OEMConfig Integration
Android Enterprise
OEMConfig
✅ Verfügbar
Disable Cross Device Resume Policy
Windows 10/11
Settings Catalog
✅ Windows Insiders
Remove Microsoft Copilot App Policy
Windows 10/11
Settings Catalog
✅ Verfügbar
Apple Intelligence & AI Settings (DDM)
iOS/iPadOS, macOS
Settings Catalog
✅ Verfügbar
Remote Help Connectivity Endpoint
Windows
Device Management
✅ Verfügbar
RHEL 9 LTS & 10 LTS Support
Linux
Enrollment
✅ Verfügbar
Microsoft Identity Broker für Linux
Linux
Authentication
✅ Verfügbar
1. Declarative Device Management für Apple – Das große Ding
Was ist DDM und warum sollte dich das interessieren?
Seit iOS 18 und iPadOS 18 können wir Apple DDM nutzen, um Line-of-Business Apps zu verwalten. Das ist ein großer Unterschied zur klassischen MDM-Verwaltung:
App Information → Management Type auf Declarative Device Management setzen
Neue Per-App-Optionen konfigurieren (z.B. Associated Domains)
Deployment starten
Was dich erwartet:
✅ Schnellere App-Bereitstellung
✅ Bessere App-Status-Transparenz
✅ Neue Security Features via Associated Domains
❌ Nur für iOS/iPadOS 18+ (Versionsprüfung nötig)
Meine Einschätzung: Das ist ein echter Game-Changer für Unternehmen mit großen iOS-Flotten. Wenn du noch auf iOS 17 bist, solltest du jetzt deinen Update-Plan prüfen.
2. Recovery Lock für macOS – Sicherheit auf neuer Ebene
Das Problem, das Recovery Lock löst:
Ein User mit lokalen Admin-Rechten kann sich in Recovery Mode booten, die Festplatte neuformatieren und dein MDM-Management umgehen. Damit ist Schluss.
Was ist Recovery Lock?
Ein Recovery OS Password, der verhindert:
– Booten in Recovery Mode
– macOS Neuinstallation ohne Admin-Genehmigung
– Umgehen der Remote Management
Für wen relevant: Unternehmen mit Zebra/Honeywell/Inventus Devices im Warehouse/Retail.
4. Windows Settings Catalog – Zwei neue Policies mit Bedeutung
Policy 1: Disable Cross Device Resume
Scenario: Der User startet etwas auf seinem iPhone und will es auf dem PC fortsetzen. Security-Policy sagt: Nein.
Devices → Configuration profiles → Create
→ Windows 10 and later
→ Settings Catalog
→ Connectivity
→ Disable Cross Device Resume: Select "Disabled"
Effekt: Keine „Resume from your phone“ Prompts mehr.
Status: ⚠️ Nur für Windows Insiders (Preview-Feature)
Policy 2: Remove Microsoft Copilot App
Szenario: Copilot ist vorinstalliert, aber deine Security Policy sagt: Nicht auf unternehmenseigenen Devices.
Settings Catalog
→ Windows AI
→ Remove Microsoft Copilot App: Enable
Bedingungen (automatisch prüfbar):
– Beide Copilot Apps sind installiert
– User hat die App nicht selbst installiert
– App wurde in letzten 14 Tagen nicht geöffnet
Effekt: App wird deinstalliert (User kann sie später neu installieren).
Status: ✅ Sofort verfügbar
5. Apple Settings Catalog – DDM erweitert sich massiv
DDM x Apple Intelligence Settings (Neu!)
Mit iOS 18 / macOS Sonoma kommt Apple Intelligence. Intune kann jetzt granular kontrollieren:
Bestehende Devices bleiben enrollt, aber kein Support mehr
RHEL 9 LTS
✅ Neu unterstützt
Production-Ready
RHEL 10 LTS
✅ Neu unterstützt
Production-Ready
Handlungsbedarf für dich:
Identify RHEL 8 Devices:
Intune Admin Center
→ Devices → All devices
→ Filter: OS = Linux
→ Add Column: OS Version
User Notification:
– E-Mail an Admins mit RHEL 8-Devices
– Upgrade-Plan für Q2/Q3 2026
Enrollment Verification:
– Neue Enrollments nur auf RHEL 9+ akzeptieren
– Enrollment Restrictions prüfen
Microsoft Intune App für Linux – Identity Broker Integration
Die neue Version der Intune-App für Linux unterstützt jetzt Microsoft Identity Broker, was bedeutet:
– SSO zwischen Linux-Apps und Browser
– Bessere Token-Verwaltung
– Sicherere Authentication Flow
Diese Release 2603 ist solider mittlerer Release – nicht revolutionär, aber substanziell:
✅ Positiv:
– Apple DDM für LOB Apps ist längst überfällig und wird Deployment-Performance spürbar verbessern
– Recovery Lock für macOS schliesst echte Security-Lücke
– Linux Support mit RHEL 9/10 macht Sinn (Zukunftsicherung)
– AI Settings Katalog zeigt, dass Microsoft ernst mit Apple Intelligence-Management meint
⚠️ Vorsichtig:
– Recovery Lock ist nur graduelle Rollout (bis Ende April) – nicht ideal für große Deployments
– Cross-Device Resume Policy ist noch Insider-only (zu nischig?)
– Copilot Removal braucht spezifische Bedingungen (14 Tage nicht geöffnet – kann frustrierend sein)
🔔 Wichtigste Action: Firewall-Update für Remote Help. Das übersehen viele und dann funktioniert Remote Help plötzlich nicht.
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
1
Vollständiges Inventar aller Geräte exportieren – Seriennummern, OS-Version, Enrollment-Status
Pflicht
2
Alle Konfigurationsprofile dokumentieren: Wi-Fi, VPN, Zertifikate, Restrictions, E-Mail
Pflicht
3
Compliance-Policies, Security-Baselines und Scripts erfassen
Pflicht
4
App-Deployment dokumentieren: Welche Apps, VPP oder direkt, welche Managed Configs
VPP Content Token: Aus altem MDM entfernen, neues Token im neuen MDM registrieren
Kritisch
7
Pilot-Gruppe definieren (5–10 Geräte) für Testlauf vor Massenrollout
Empfohlen
8
User-Kommunikation vorbereiten: Was passiert, wann, was müssen User tun
Empfohlen
Phase 2: Migration in ABM starten
Anmelden bei business.apple.com als Administrator oder Device Enrollment Manager
Im Seitenmenü auf ‚Devices‘ gehen
Geräte suchen und auswählen (Seriennummer, Order-Nummer oder Filter ‚Eligible Devices‘ nutzen)
Auf das Gerät klicken → ‚…‘ (Ellipsis-Menü) oder ‚Edit‘ → ‚Assign Device Management‘
Neuen MDM-Server auswählen
‚Add Deadline‘ klicken und Datum/Uhrzeit setzen (kein Deadline = kein automatisches Erzwingen)
‚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 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:
User erhält eine Notification ‚Enrollment Required‘
Tippen auf die Notification öffnet Einstellungen → VPN & Geräteverwaltung
‚Enrollment starten‘ antippen
Gerät startet neu – nach dem Neustart enrollt sich das Gerät automatisch im neuen MDM
Alle neuen MDM-Konfigurationen werden direkt im Anschluss OTA verteilt
MDM-Profile werden entfernt, Gerät enrollt sich neu
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.
Managed Home Screen: Woher kommt der angezeigte Gerätename?
Wer den Microsoft Managed Home Screen (MHS) im Shared Device Mode einsetzt, kennt das: In der Top Bar wird ein Gerätename angezeigt – übersichtlich, praktisch, nützlich für Frontline-Worker-Umgebungen. Aber mal ehrlich: Hast du dich schon gefragt, wo dieser Name eigentlich herkommt? Aus dem Android-System? Aus Intune? Und was passiert, wenn du das Gerät in der Konsole umbenennst?
Genau diese Frage hatte ich letztens im Office und habe mich rangesetzt, um ihr auf den Grund zu gehen. Spoiler: Ich wusste schon intuitiv woher die Info kommt – aber ich wollte es dann doch etwas technischer beleuchten. 😄
1. Die Quelle: Nicht Android – sondern Intune
Kurze Antwort zuerst: Der angezeigte Gerätename kommt nicht vom Android-Betriebssystem selbst. Es ist nicht das, was unter Einstellungen → Gerät → Gerätename steht. Sondern es ist der Device Name-Eintrag aus dem Microsoft Intune Admin Center – also der Anzeigename, den du in der Verwaltungskonsole vergeben hast.
⚠️ Wichtig: Das Umbenennen eines Geräts in Intune ändert nur den Anzeigenamen in der Konsole – nicht den lokalen Gerätenamen auf dem Android-Betriebssystem selbst! MHS zeigt immer den Intune-seitigen Namen an.
2. Der Übertragungsweg: App Configuration Policy mit {{DeviceName}}
Der Name gelangt über eine App Configuration Policy an das Gerät. Microsoft stellt dafür die dynamische Variable {{DeviceName}} bereit – Intune löst diese Variable serverseitig auf und bettet den echten Gerätenamen in die Policy ein, bevor sie ans Gerät gepusht wird.
Die drei relevanten Konfigurationsschlüssel in der App Configuration Policy:
Konfigurationsschlüssel
Wert
Funktion
Top Bar Primary Element
Device Name
Gerätename als primäres Element (nur ohne Sign-In)
Top Bar Secondary Element
Device Name
Gerätename als sekundäres Element
Show device name for all supported OS versions on MHS
{{DeviceName}}
Pflichtfeld – Intune befüllt automatisch den korrekten Wert
ℹ️ Shared Device Mode – Sonderregel: Wenn Sign-In aktiviert ist, wird das primäre Top-Bar-Element automatisch durch den Namen des angemeldeten Benutzers ersetzt. Der Gerätename kann dann nur noch als sekundäres Element konfiguriert werden.
3. Wird der Name lokal gespeichert? Ja – aber nicht wo du denkst
Hier wird es technisch interessant. Der Gerätename wird lokal auf dem Gerät gespeichert – allerdings nicht in einer einfachen Datei oder Datenbank, die ein Nutzer einsehen könnte. Stattdessen nutzt Android dafür den sogenannten Managed Configuration Mechanismus, auch bekannt als App Restrictions oder RestrictionsManager.
Der vollständige Datenpfad
Schritt
Was passiert?
1
Intune löst {{DeviceName}} serverseitig auf → z.B. „DEV-WARD-01“
2
App Configuration Policy mit aufgelöstem Wert wird an das Gerät gepusht
3
Device Policy Controller (Intune / Company Portal) schreibt Wert ins Android Managed Config Bundle
4
Android RestrictionsManager speichert Bundle im geschützten Systembereich
5
MHS App liest Wert beim Start via RestrictionsManager.getApplicationRestrictions()
6
Anzeige des Namens in der Top Bar
Eigenschaften des lokalen Caches
Eigenschaft
Detail
Speicherort
Systembereich des Android OS – nicht im App-eigenen Storage
Format
Android Bundle (Key-Value-Pairs, binär)
Zugriffsrechte
Nur der DPC (Intune Company Portal) darf schreiben; MHS darf nur lesen
Persistenz
Bleibt über App-Neustarts erhalten; wird bei Policy-Sync oder Factory Reset aktualisiert
Offline-Verhalten
Gerätename wird auch ohne Netzwerkverbindung angezeigt (gecacht)
Update-Zyklus
Wird beim nächsten Policy-Sync aktualisiert (~alle 8 Stunden oder manuell)
4. Wo wird der Name nicht gespeichert?
Zur Klarheit – diese Speicherorte werden explizit nicht verwendet:
❌ Nicht im lokalen Android-Gerätenamen (Settings.Global.DEVICE_NAME)
❌ Nicht in einer Datei im MHS-App-Verzeichnis (/data/data/com.microsoft.launcher.enterprise/)
❌ Nicht in einer für den Nutzer zugänglichen Datenbank
✅ Ausschließlich im geschützten Android Managed Configuration Bundle – weder einsehbar noch manipulierbar durch den Endnutzer
Fazit
Der im Managed Home Screen angezeigte Gerätename kommt direkt aus dem Intune Admin Center – übermittelt via App Configuration Policy mit der Variable {{DeviceName}}. Lokal wird er im Android RestrictionsManager-Bundle gecacht: sicher, persistent, offline-fähig und für den Endnutzer weder einsehbar noch veränderbar.
Das macht die Sache für Frontline-Worker-Szenarien besonders praktisch. Egal ob das Gerät gerade online ist oder nicht – der Gerätename wird immer korrekt angezeigt.
Workspace ONE UEM 2602: Ein ehrlicher Überblick zum großen Release
Die 2602er ist eine dieser Releases, bei denen Omnissa sein Selbstvertrauen zeigt – und das ist nicht ganz unbegründet (jeder von uns kennt sehr wahrscheinlich die Probleme der letzten Updates, welche immer so naja liefen ). Mit dieser Version liefern sie eines ihrer ambitioniertesten Updates: vollständig aufgefrischte Admin Experience, innovative Android- und Apple-Management-Fähigkeiten, Game-Changing Windows Management und intelligentere Automation überall.
Lass mich die wichtigsten Punkte durchlaufen.
Feature-Übersichtstabelle: 2602 auf einen Blick
Feature
Plattform
Kategorie
Status
Modernisierte Admin Console
Cross-Plattform
UI/UX
Limited Availability
Phased App Deployments
Cross-Plattform
Automation
GA
Advanced eSIM Management
Android
Connectivity
GA
Erweiterte AMAPI-Policies
Android
Enterprise Control
GA
Account-Driven Enrollment (vereinfacht)
iOS/macOS
Enrollment
GA
Dynamic Mac Hardware Seeding
macOS
Automation
GA
Intelligente Enrollment-Labels
iOS/macOS
Grouping
GA
Intelligent Hub Managed Enrollment
Windows
Enrollment
GA
Enterprise App Repository v2 (EARv2)
Windows
App Distribution
GA
Automatisierte Windows App-Patching
Windows
App Management
GA
Windows Agent Updates Dashboard
Windows
Visibility
GA
Dropship Provisioning Bulk Import
Windows
Provisioning
GA
Intel Chip-to-Cloud Logging
Windows
Troubleshooting
GA
Granular App Retention Control
Windows
App Lifecycle
GA
ADMX Profiles (Windows Server Preview)
Windows Server
Policy
Limited Availability
Die wichtigsten Features im Detail
1. Modernisierte Admin Console – Limited Availability, aber vielversprechend
Omnissa kündigt eine modernisierte Konsole mit intuitiver Navigation, neu gestalteter Device List View und intelligenteren Workflows an, die Klicks reduzieren. Admins können sich schrittweise anmelden und jederzeit zurückwechseln.
Meine Analyse: Das ist nicht einfach eine Kosmetik-Operation. Eine frische Konsolen-UI ist bei MDM-Plattformen überraschend kritisch – die Funktion befindet sich derzeit in Limited Availability , also nicht hastig upgraden. Die Opt-in-Strategie ist smart: Admins können taste, backup-Plan bei Bedarf. Das respektiere ich.
Workspace ONE UEM bietet jetzt fortgeschrittenes eSIM-Management für Android, mit dem IT-Teams die Geräteverbindung optimieren. Administratoren können eSIM-Profile remote bereitstellen, aktivieren, überwachen und entfernen – über die UEM Console oder REST API.
Zusätzlich: Workspace ONE weitet Android AMAPI-Unterstützung mit neuen Policies aus, die granulare Kontrolle über Bildschirmverhalten, Private Space und Google Play Protect bieten.
Praktische Bedeutung: Das ist ein echter Differentiator. eSIM ist nicht sexy, aber für GlobalPlayer mit großen Android-Flotten (Logistics, Telco) = essentiell. Die Private Space Policies sind auch clever – das passt zu Googles Android 15+ Richtung.
3. Apple: Enrollment vereinfacht, Automation kommt
Das Release vereinfacht zwei kritische Apple-Szenarien:
Account-Driven Enrollment (ADE):
Das Release vereinfacht Account-Driven Enrollments erheblich. Früher erforderte die Erstellung einer well-known-Datei manuelle Schritte und externes Hosting. Jetzt aktivieren Admins das Feature, und WS1 generiert die JSON-Datei automatisch via Apple Business Manager.
Mac Hardware Seeding:
Mac-Modell-Hardware-Seeding ist jetzt automatisiert. Mit automatisch erfassten und befüllten Mac-Modelldaten können Admins Smart Groups nutzen – mit Same-Day Support für neue Apple Hardware.
Kritisches Take: Das ist Micro-Automation, aber die Art, die deinen Alltag vereinfacht. Weniger manuelle Datei-Hosting-Fricktion = weniger Fehler = happier Admins. 👍
4. Windows: Das Game-Changer-Release (25+ Features!)
Das ist das Herzstück von 2602. Mit Next-Gen Windows Management in 2602 redefine Omnissa modernes Windows-Management – von Intelligent Hub managed mode über stärkere Desired-State-Controls bis zur verbesserten Enterprise App Repository.
Intelligent Hub Managed Enrollment:
Neue Enrollment-Option namens „Intelligent Hub Managed“ – als Übergangsmechanismus vom alten OMA-DM-Anbieter. Volle Intelligent Hub-Power, aber mit mehr Flexibilität.
Enterprise Application Repository v2 (EARv2):
Ihr könnt jetzt über 8.500 Enterprise-Apps browsen, konfigurieren und an Windows-Geräte pushen – direkt aus WS1 UEM. Noch besser: WS1 kann über 8.500 Apps automatisch patchen. Ihr konfiguriert den Plan einmal – WS1 kümmert sich um den Rest, Apps bleiben aktuell ohne manuelle Intervention.
Unified Application Sampling:
Besseres App-Reporting mit konsistenten Daten. Mit dem neuen Sampling-Framework werden App-Daten einheitlich über Intelligent Hub, UEM und DEX/DEEM erfasst.
Windows Agent Updates Dashboard:
Neues Dashboard für Echtzeit-Sichtbarkeit aller Intelligent Hub & SFD Agentversionen. Zwischen Agenten wechseln, Charts ansehen, zu Device-Listen drilldown – alles from one dashboard.
Intel Chip-to-Cloud Logging:
C2C-Events sind jetzt in dedizierter Log-Datei, ohne unrelated data. AMT-Interface-Aktivierung & Checking verbessert.
Granular App Retention:
Admins steuern jetzt, ob Apps beim Device-Wipe oder App-Unassign entfernt oder behalten werden.
Dropship Provisioning:
Bulk-Import von Geräte-Records – egal ob 1 oder 100 Devices auf einmal.
Meine Analyse: Das ist substantiell. 25+ Windows-Features sind nicht gequetscht, sondern strategisch: DeviceList-Visibility (Admin), App-Automation (Speed), Troubleshooting-Verbesserungen (Ops). EARv2 mit Automatic Patching ist besonders nice – Zero-Touch Patching für 8.500 Apps reduziert MSP-Intervention massiv.
⚠️ Warnung: Windows Server Management ist noch Limited Availability. Wenn ihr auf WS1 für Server-Flotten setzt – noch ein paar Releases warten.
Automation & Workflows: Smarter, nicht komplexer
Mit Phased Deployments könnt ihr Apps schrittweise ausrollen – mit kleiner Gruppe starten, Probleme früh catch, Rest der Fleet schützen. Ziel exakte Assignment Groups in jeder Phase, automatische oder manuelle Phase-Progression, Clear Phase-Level Insights.
Das ist LowCode-Orchestration im Best-Sense: nicht Freestyle, aber simpler als vor 2602.
Handlungsbedarfe & Deprecations: Was ist zu beachten?
⚠️ Console Modernization = Limited Availability
Die neue Admin Console ist noch nicht GA. Testet in Lab/Non-Prod, bevor ihr großflächig rolled. Die Opt-in Strategy ist gut, aber seids vorsichtig mit Critical Workflows.
⚠️ Windows Server = Not Yet Production-Ready
Windows Server Management ist derzeit in Limited Availability mit General Availability demnächst . Wenn ihr Windows Server managed, wartet noch.
⚠️ Apple Migration ohne App Preservation (noch)
WS1 UEM unterstützt derzeit keine App Preservation während Migration. Ihr müsst Apps vorab in WS1 aufsetzen. An diesem Feature wird gearbeitet.
⚠️ Legacy App Catalog Sunset: 30. April 2025
Wechselt zur neuen Enterprise App Repository – Legacy-Path wird deprecated.
Kurzer Vergleich zu Microsoft Intune
Ja, die Frage kommt. Hier meine ehrliche Sicht:
Wo WS1 2602 Intune schlägt:
– Cross-Device Management: Windows + Mac + Android + rugged aus einer Konsole. Intune braucht mehr Basteln.
– eSIM Management: Noch nicht in Intune, WS1 has it. Nice-Feature, aber strategisch.
– ADMX Profiles (kommend): Familiarität für Group Policy Admins.
– Enterprise App Repo (8.500+ Apps): Intune’s Win32 App Management ist granular, aber anstrengender.
Wo Intune Punkte macht:
– Microsoft Ecosystem Integration: Wenn ihr 100% Microsoft-Stack seid, Intune ist built-in.
– Conditional Access: WS1 ist gut, Intune’s AAD-Integration tighter.
– Community & Adoption: Intune-Adoption ist bei SMB größer (aktuell).
Fazit: 2602 macht WS1 für gemischte Umgebungen (Apple + Android + Windows + Rugged) attraktiver. Für rein Microsoft-Shops bleibt Intune einfacher. Für Enterprise Complexity: WS1.
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:
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
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:
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.
). Mit dieser Version liefern sie eines ihrer ambitioniertesten Updates: vollständig aufgefrischte Admin Experience, innovative Android- und Apple-Management-Fähigkeiten, Game-Changing Windows Management und intelligentere Automation überall.