Kategorie: Microsoft

Intune Release 2606: macOS Auto-Updates & Android Enterprise

13. Juli 2026 / / Keine Kommentare

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:

  1. Intune erkennt eine neue Version im EAM-Katalog
  2. Update wird automatisch auf Zielgeräten installiert
  3. 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
  • Block network reset – Netzwerk-Reset unterbinden
  • Block outgoing calls – Telefonie komplett deaktivieren
  • Block SMS – SMS-Versand/-Empfang blockieren
  • Block ultra wideband – UWB (Android 14+) deaktivieren
  • Select minimum Wi-Fi security level – Erzwingt WPA3-Pers/Enterprise (Android 13+)

General

  • Block printing – Drucken verhindern
  • Block setting user icon – Profilbild ändern verhindern
  • Block setting wallpaper – Wallpaper-Änderung sperren
  • Block users from adding eSIM profiles – eSIM-Management blockieren

Device Type Support:

  • COBO – Corporate-Owned, Fully Managed
  • COSU – Corporate-Owned, Shared/Dedicated
  • COPE – Corporate-Owned, Personal-Enabled (Work Profile)

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.

Quellen

Intune 2605: Multiple Accounts, Apple Intelligence & MHS

5. Juli 2026 / / Keine Kommentare

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:

  • {{SerialNumber}}
  • {{DeviceName}}
  • {{TenantName}}

Praktische Anwendungen:
– Checkout-Kioske: "Register 03 - {{DeviceName}}"
– Departmental Tagging: "Warehouse - {{SerialNumber}}"
– Konferenzraum-Kioske: "Meeting Room 4B"

Applies to: Android Enterprise COSU (Dedicated) & COBO (Fully Managed)

🔴 BREAKING CHANGE: MHS Lock Task Mode Password migriert

Achtung – das ist eine echte Breaking Change:

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 Settings Catalog (Restrictions):
– Allow Apple Intelligence Report
– Allow Assistant (und alle Varianten)
– Allow Auto Correction
– Allow Continuous Path Keyboard
– Allow Definition Lookup
– Allow Dictation
– Allow External Intelligence Workspace IDs / Integrations
– Allow Genmoji
– Allow Image Playground / Image Wand
– Allow Mail Smart Replies / Mail Summary
– Allow Notes Transcription / Summary
– Allow Predictive Keyboard
– Allow Safari Summary
– Allow Spell Check
– Allow Visual Intelligence Summary
– Allow Writing Tools
– Alle Force Varianten

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
  • Docs: Apple DDM Framework (Microsoft Learn)

🔴 WICHTIG – MHS Lock Task Password (Android Enterprise)

  • Timeline: Nächste Wartungsfenster
  • Action: App Config Policies → Device Configuration Profiles
  • Überwachung: Legacy Policies weiterhin testen, parallele Migration empfohlen
  • Docs: Configure Microsoft Managed Home Screen

🟡 MITTELHOCH – Multiple Managed Accounts (iOS/iPadOS)

  • Timeline: Jetzt QA-testen, später rollout
  • Action: Teams v8.10.0+ in Pilot-Group testen
  • 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

Quellen

Intune Release 2604 – Die wichtigsten Neuerungen (KW 27.04.2026)

4. Mai 2026 / / Keine Kommentare

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:

  1. EPM endlich für alle User – bisher war das ein nerving restrictions für Shared Devices (Kiosk, Hotspot-Devices)
  2. Android 14: Credential Manager-Kontrolle – das schreit geradezu nach Zero-Trust-Architektur
  3. 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

Was ich dir empfehle:

Intune Admin Center → Endpoint Privilege Management →
Policies → [Deine Policy] → Elevation Settings prüfen

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:

Apps → Android → Configuration → Managed Devices
→ Android Enterprise → Credential Manager Permissions

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.

⚠️ HANDLUNGSBEDARF: Breaking Changes & Deprecations

🔴 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

📚 Microsoft Learn Ressourcen

Alle offizielle Docs:

  1. EPM Support-Approved Elevations

  2. Android Credential Manager Config

  3. Android Settings Catalog

  4. Apple ADE Overview

  5. Linux Device Enrollment

  6. Ubuntu 26.04 Details

Wer MUSS upgraden:

✅ 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)
„`

🔗 Schnelle Links
Intune What’s New – Service Release 2604
Microsoft Intune Blog
Intune Roadmap
Endpoint Privilege Management Docs

Microsoft Intune Release 2603: DDM für Apple, Recovery Lock für macOS und Linux Support

2. April 2026 / / Keine Kommentare

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:

Klassisches MDM:
– Reaktive Verwaltung (Befehl → Antwort)
– Höhere Latenz bei App-Installationen
– Limitierte Per-App-Optionen

Apple DDM:
– Deklarativ (Zielzustand definieren, Apple macht den Rest)
– Echte Echtzeit-App-Status
– Associated Domains Support
– Bessere Delivery Efficiency

Praktisch im Intune Admin Center:

  1. Devices → Apps → Deine iOS/iPadOS Line-of-Business App öffnen
  2. App Information → Management Type auf Declarative Device Management setzen
  3. Neue Per-App-Optionen konfigurieren (z.B. Associated Domains)
  4. 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

Zwei Wege zur Umsetzung:

Option 1: Settings Catalog Policy

Devices → Configuration profiles → Create profile
→ macOS → Settings Catalog
→ Recovery Lock
  • Feature aktivieren
  • Password Rotation Schedule setzen (z.B. alle 90 Tage)
  • Speichern

Option 2: Remote Device Action (Manuelle Rotation)

Devices → All devices
→ [Device auswählen]
→ ... → Remote tasks
→ Recovery Lock rotation → Starten

Wichtig: RBAC für Passwords

⚠️ Handlungsbedarf: Admins brauchen explizit die Berechtigung:

Remote tasks/View macOS recovery lock password

Das stellst du unter Roles & Admins → Custom Role → Permissions ein.

Verfügbarkeit:

🔄 Graduelle Rollout bis Ende April 2026 – nicht sofort in allen Tenants verfügbar.

3. Android Enterprise: Inventus OEMConfig

Neu: Inventus com.inventus.oemconfig.gen

Für Admin, die mit Inventus-Rugged-Devices arbeiten (stark in der Logistik/Warehouse), ist das relevant.

OEMConfig erlaubt es, OEM-spezifische Features direkt über Intune zu verwalten:

Devices → Configuration profiles → Create
→ Android Enterprise
→ OEMConfig
→ Inventus (com.inventus.oemconfig.gen)
→ OEM-spezifische Settings konfigurieren

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:

iOS/iPadOS DDM Settings (neu):
– External Intelligence: Sign In, Workspace IDs
– Apple Intelligence: Report, Genmoji, Image Playground, Visual Intelligence Summary
– Mail: Smart Replies, Summary
– Notes: Transcription, Summary
– Safari: Summary
– Keyboard: Definition Lookup, Auto-Correction, Dictation, Predictive Text, etc.
– Siri: User Generated Content, While Locked, Profanity Filter

macOS DDM Settings (neu):
– File Provider: Remote Syncing, External Volume Syncing, Domain Auto-Enablement
– Rosetta Usage Awareness (für ARM-Transition)

Praktisch:

Devices → Configuration profiles → Create
→ iOS or macOS
→ Settings Catalog
→ Declarative Device Management
→ Intelligence Settings
→ z.B. "Allow Apple Intelligence Report" = Toggle

Security-Tipp: Wenn deine Compliance-Policy Says „Keine Cloud-Datenanalyse“, stellst du hier alle AI-Features auf Disabled.

6. Remote Help – Neue Connectivity-Anforderung ⚠️

Firewall-Update erforderlich!

Microsoft hat einen neuen Endpoint für Remote Help (Launch Remote Help in Admin Center) hinzugefügt:

*.trouter.communications.svc.cloud.microsoft

Handlungsbedarf:
1. ✅ Aktualisiere deine Firewall-Regeln
2. ✅ Prüfe Proxy-Konfiguration
3. ✅ Teste Remote Help mit Windows-Device nach Update

Neues Log-File:
– NotificationInfra.log (Intune Management Extension)
– Trackt Real-Time-Communication-Notifications
– Hilfreich für Troubleshooting

Ort: C:\Program Files (x86)\Microsoft Intune Management Extension\Logs\

7. Linux Support – RHEL wird erwachsen

Support-Änderung:

Version Status Aktion
RHEL 8 LTS ❌ End of Support 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:

  1. Identify RHEL 8 Devices:
Intune Admin Center
→ Devices → All devices
→ Filter: OS = Linux
→ Add Column: OS Version
  1. User Notification:
    – E-Mail an Admins mit RHEL 8-Devices
    – Upgrade-Plan für Q2/Q3 2026
  2. 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

🚨 Kritische Handlungsbedarfe

Punkt Kritikalität Deadline Aktion
Firewall Update (Remote Help Endpoint) 🔴 Hoch Sofort *.trouter.communications.svc.cloud.microsoft allowlisten
RHEL 8 Geräte identifizieren 🟡 Mittel Bis Juni 2026 Inventory + Upgrade-Plan
Recovery Lock RBAC Setup 🟡 Mittel Bis Ende April Berechtigungen für Admin-Rollen anpassen
iOS 18 DDM Readiness Check 🟡 Mittel Vor Rollout Device-Kompatibilität prüfen (iOS 18+)
Windows Insider Copilot Policy Testen 🟢 Niedrig Optional In Test-Ring deployen

Meine persönliche Einschätzung

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.

Quellen & Dokumentation

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

13. März 2026 / / Keine Kommentare

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 Pflicht
5  Neues MDM vollständig konfigurieren: APNs, ABM-Token, Enrollment Profile, alle Profile nachbauen Pflicht
6  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

  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.

Managed Home Screen: Woher kommt der angezeigte Gerätename?

8. März 2026 / / Keine Kommentare

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.

Microsoft Intune Release 2602: Das ist neu (Woche 2. März 2026)

5. März 2026 / / Keine Kommentare

Microsoft Intune Release 2602: Das ist neu (Woche 2. März 2026)

Moin zusammen,

ich sitze hier gerade vor den Release Notes zur Woche 2. März 2026 – und ehrlich gesagt: Das ist eine Release, die zeigt, wohin die Reise geht. Microsoft macht hier ernsthaft ernst mit Apple’s Declarative Device Management (DDM). Das Legacy-Zeug wird eingestampft, die neuen Features sind gut durchdacht, und das Multi-Admin Approval Feature adressiert endlich ein Problem, das viele von euch im Enterprise haben.

Auch interessant: Autopatch Update Readiness kommt mit echtem Reporting-Zeugs statt nur „lädt gerade Update“ zu zeigen. Das spart euch Zeit beim Troubleshooting.

Lass mich die wichtigsten Punkte durchgehen – und wo ihr aufpassen müsst.

Release-Übersicht: Feature nach Kategorie

Feature Betroffen Kategorie Status
Apple DDM + Assignment Filters iOS, iPadOS, macOS Device Configuration ✅ Neu
Settings Catalog Updates (AirPlay, Defender) iOS, iPadOS, macOS Device Configuration ✅ Erweitert
Multi-Admin Approval für Policies iOS, iPadOS, macOS, Windows Device Management & Security ✅ Neu
Legacy MDM Software Updates deprecated iOS, iPadOS, macOS Device Security ⚠️ Breaking
Protected Apps: Jump, Mijn InPlanning Android App Management ✅ Neu
Autopatch Update Readiness Dashboard Windows Update Management ✅ Neu
Device Query Operators erweitert Alle Monitor & Troubleshoot ✅ Erweitert

Die wichtigsten Features im Detail

1. Apple Declarative Device Management (DDM) mit Assignment Filters 🎯

Das ist die Headline dieser Release.

Was ändert sich?
– Assignment Filters funktionieren jetzt auch mit DDM-basierten Konfigurationen (Software Updates, Policies)
– Bisher war das nur bei Legacy-Policies möglich
– Ermöglicht granulares Targeting: z.B. „Software Updates nur für Devices im Finance-Department mit iOS 24+“

Warum ist das wichtig?

Bei großen Umgebungen brauchst du Granularität. Mit Assignment Filters kannst du jetzt:
– Nach Azure AD Groups filtern
– Nach Device Attributes filtern (Owner Type, OS Version, Location)
– Nach User Attributes filtern

Praxisbeispiel:

Device Configuration → Create Policy (DDM-based)
→ Assign → Add Assignment Filter
→ "iOS >= 25 AND Department = Engineering"

Das reduziert Rollout-Komplexität erheblich – vor allem wenn ihr mehrere tenants oder heterogene Environments habt.

Gilt für: iOS/iPadOS, macOS

2. ⚠️ WARNUNG: Legacy Apple MDM Software Update Policies werden deprecated 🚨

Das ist wichtig. Sehr wichtig.

Microsoft und Apple beenden Support für die alten MDM Software Update Commands mit iOS 26, iPadOS 26 und macOS 26. Das bedeutet:

  • Legacy-Policies (die ihr vermutlich heute noch nutzt) funktionieren in Kürze nicht mehr
  • Apple hat diese alten Payloads aus dem MDM-Spec rausgenommen
  • Action Item für euch: Migration zu DDM-based Software Updates erforderlich

Was müsst ihr machen?

  1. Audit: Welche Legacy-Policies habt ihr aktuell deployed?
  2. Planning: Welche Geräte sind noch auf iOS < 25 / macOS < 25?
  3. Rollout: DDM Software Update Policies neu erstellen und testen
  4. Sunset: Legacy Policies systematisch deaktivieren

Zeitrahmen? Microsoft nennt kein genaues Datum, aber „soon“ ist im Tech-Speak nicht mehr fern. Ich würde Q2-Q3 2026 kalkulieren.

Ressource: Schaut euch den Intune Customer Success Blog an – da wird’s detailliert erklärt.

3. Multi-Administrator Approval für Device Configuration & Compliance Policies 👥

Das ist ein Security-Feature, das lange überfällig war.

Was ändert sich?
– Dual-Authorization für Policy-Änderungen ist jetzt auch für Settings Catalog Policies möglich
– Vorher war das nur für Compliance Policies relevant
– Jede Änderung (Create, Edit, Delete) muss von Admin #2 genehmigt werden

Warum?
– Verhindert versehentliche Breaking Changes (z.B. falsch konfigurierte VPN-Policies)
– Schützt vor Malicious Actions durch compromised Admin-Accounts
– Audit Trail für Compliance-Reviews (SOC 2, ISO 27001, etc.)

Wo stellt ihr das ein?

Intune Admin Center
→ Devices → Device Configuration oder Compliance
→ Create Policy
→ Policies (unter Access policies)
→ Require Multi Admin Approval: ON

Praktischer Hinweis: Das wird euer Change-Management verlangsamen. Ein Policy-Update dauert dann länger. Aber der Security Gewinn ist es wert – vor allem in Enterprise-Umgebungen.

Gilt für: iOS, iPadOS, macOS, Android, Windows

4. Settings Catalog Updates: AirPlay & Microsoft Defender 🎨

Microsoft hat die Settings Catalog (das zentrale Policy-Management-Tool) erweitert.

Neue Settings:

Setting Platform Use Case
AirPlay → Device Name iOS, iPadOS, macOS Custom Device-Naming für AirPlay
Microsoft Defender → Neue Policies macOS Advanced Threat Protection Config

Das klingt marginal, aber für Environments die AirPlay oder Defender managed endpoints haben: Jetzt könnt ihr das via Policy zentralisiert steuern statt manuell auf jedem Device.

Für macOS-Defender: Besonders interessant für Security Teams, die Microsoft Defender als Standard-AV eingerollt haben. Mehr Policy-Control = bessere Compliance.

5. Autopatch Update Readiness Dashboard 📊

Das ist für Windows-Teams ein großes Ding.

Was ist neu?
– Unified Dashboard für Update-Readiness (Intune + Windows Autopatch)
– Device Update Journey: Granulare Status pro Gerät
– Centralized Alerting: Failures, Policy Conflicts, Readiness Gaps
– Update Readiness Checker: Proaktive Risk-Evaluation
– OS Reinstall Trigger: Automatisches Remediating bei Blockern (z.B. Disk Space)

Konkret:

Autopatch Dashboard
→ Update Status: "In Progress" / "Failed" / "At Risk"
→ Reason: "Insufficient disk space (22 GB free, 30 GB required)"
→ Remediation: "Trigger OS reinstall" (mit Alerts & Reporting)

Wofür nutze ich das?
– Pre-Deployment Risk Assessment
– Quick Troubleshooting (warum stockt das Update?)
– Proactive Device Remediation

Das spart euch echte Stunden bei größeren Updates.

6. Protected Apps: Jump & Mijn InPlanning 📱

Zwei neue Apps sind jetzt auf der Intune Protected Apps Liste.

Jump by Accio Inc. – Scheduling/Planning App
Mijn InPlanning by Intus Workforce Solutions – Workforce Planning (Android)

Das bedeutet: Diese Apps kriegen automatisch Mobile App Protection Policies (MAMP) angeboten:
– Biometric Lock
– Data Encryption
– Clipboard Restrictions
– etc.

Relevant, wenn ihr diese Tools deployed und data protection braucht.

7. Device Query Operators – Erweiterte Abfragen 🔍

Für die Admin-Power-User da draußen:

Neue Join Types:
– leftsemi, rightsemi, leftanti, rightanti

Breaking Changes:
– on Device.DeviceId wird nicht mehr unterstützt → nutzt stattdessen on Device
– Device allein in distinct, summarize, order by geht nicht mehr → specific properties required

Bessere Error Messages + Devices als clickable Links in Query Results

Das ist ein UX-Upgrade für euer Troubleshooting, aber Achtung: Falls ihr custom KQL-Queries gebaut habt, müssen die angepasst werden.

Handlungsbedarfe & Warnungen 🚨

1. Legacy iOS/macOS Software Updates – Migration erforderlich

Item Details
Was? Legacy MDM Software Update Policies
Deadline Unklar, aber „soon“ – rechne Q2-Q3 2026
Action Audit + Rollout zu DDM-based Policies
Impact Breaking Change für iOS/macOS Updates

Meine Empfehlung: Startet noch diesen Monat mit der Audit & Test-Phase. DDM ist die Zukunft – besser proaktiv als reaktiv migrieren.

2. Multi-Admin Approval Performance-Impact

Wenn ihr das Feature enablet:
– Policy-Rollouts werden langsamer (Genehmigung erforderlich)
– Notfall-Changes brauchen schnelle Admin-Koordination

Lösung: Separate Approval-Policies für kritische vs. Standard-Changes einplanen.

3. Device Query Syntax-Änderungen

Falls ihr custom Queries nutzt:
– Alt: on Device.DeviceId → Neu: on Device
– Test eure Queries gegen die neuen Anforderungen

Fazit & Meine persönliche Einschätzung 💭

Diese Release ist solid und forward-looking. Drei Dinge fallen mir auf:

  1. Microsoft stellt Apple Legacy-Zeug konsequent ab – Das ist richtig. DDM ist moderner, sicherer, zuverlässiger. Wer noch auf Legacy-Policies läuft: Wake up call. Migration sollte jetzt starten.
  2. Multi-Admin Approval ist Enterprise-ready – Das Feature adressiert echte Security-Anforderungen. In großen Umgebungen unverzichtbar.
  3. Autopatch Update Readiness ist praktisch – Endlich echtes Troubleshooting-Tooling statt „lädt gerade“. Time Saver.

Quellenlinks

Intune Releases 2601 & 2602: Die wichtigsten MDM-Neuerungen – was Admins jetzt wissen müssen

5. März 2026 / / Keine Kommentare

Intune Releases 2601 & 2602: Die wichtigsten MDM-Neuerungen – was Admins jetzt wissen müssen

Kurze Info vorab: Ich versuche diese Serie nun hier zu etablieren und will die jeweiligen Erneuerungen welche Microsoft in Ihren Monatlichen Releases für Intune packt, hier klar zusammenzufassen. 

Microsoft Intune liefert monatlich neue Features – und manchmal passiert das so schnell, dass man kaum hinterherkommt. Heute schaue ich mir die Neuerungen aus den Service Releases 2601 (Februar 2026) und 2602 (März 2026) an und filtere raus, was für MDM-Admins wirklich relevant ist.

Kleiner Hinweis vorweg: Das 2602-Release ist heute, am 3. März 2026, gerade frisch deployed worden. Die detaillierten Release Notes auf Microsoft Learn wurden zum Zeitpunkt dieses Posts noch nicht vollständig publiziert – das ist bei neuen Releases normal, da die Doku immer etwas hinterherläuft. Was ich an 2602-Inhalten habe, kommt aus der offiziellen Microsoft-Ankündigung. Der Großteil dieses Posts deckt die gut dokumentierten 2601-Features ab – und da ist einiges dabei das sich lohnt genauer anzuschauen.

ℹ️ Wichtige Info zur Verfügbarkeit: Intune-Updates werden schrittweise ausgerollt – Tag 1: APAC, Tag 2: EMEA, Tag 3: Nordamerika, Tag 4+: Government. Manche Features brauchen mehrere Wochen bis zur vollständigen Verfügbarkeit. Wer etwas noch nicht sieht: einfach abwarten, es kommt automatisch.

Übersicht: Was ist neu in 2601 & 2602?

Feature Plattform Release Kategorie
Neue MHS RBAC-Permissions (Suspend/Restore) Android 2602 🔐 RBAC / Kiosk
EPM-Support für Azure Virtual Desktop Windows 2601 🔐 Security
Lenovo Device Orchestration Link im Admin Center Windows 2601 🛠️ Management
Neue Windows Settings Catalog Policies (Edge, AI, Chrome) Windows 2601 ⚙️ Konfiguration
Neue OEMConfig Apps (FCNT, Sonim) Android 2601 📱 Android OEM
Android Management Mode Filter im Settings Catalog Android 2601 ⚙️ Konfiguration
iOS/iPadOS Rating Apps Exempted Bundle IDs iOS/iPadOS 2601 ⚙️ Konfiguration
Erweiterte Assignment Filter für Managed Apps Android/iOS 2601 ⚙️ Policy
Zimperium MTD: Certificate Inventory Sync (iOS) iOS/iPadOS 2601 🔐 Security
Azure Front Door IPs – Firewall-Anpassung nötig! Alle 2601 ⚠️ Aktion erforderlich
Win11 25H2 in Feature Update Reports Windows 2601 📊 Reporting
Admin Tasks jetzt Generally Available Alle 2601 🛠️ Management
PowerShell-Installer für Win32 Apps Windows 2601 📦 App Management

🆕 Release 2602 – Was bisher bekannt ist

Neue RBAC-Permissions für den Managed Home Screen: TemporarilySuspendManagedHomeScreen & RestoreManagedHomeScreen

Das ist das Feature aus 2602, über das ich heute einen eigenen Post geschrieben habe – also kurz die Zusammenfassung: Mit diesem Release kommen zwei neue RBAC-Permissions für den Managed Home Screen, die automatisch den Built-in-Rollen School Administrator und Help Desk Operator hinzugefügt werden.

Was das bedeutet: Help Desk Operators und Schuladmins können jetzt einen Android-Kiosk temporär aus dem MHS-Modus herausnehmen, das Problem lösen, und ihn danach wieder zurücksetzen – alles ohne einen Global Admin einschalten zu müssen. Für alle die MHS in Schulen, im Retail oder bei Frontline Workern einsetzen: Das ist ein echter Alltagshelfer.

Mehr Details dazu gibt es in meinem ausführlichen Post: Intune MHS RBAC – Neue Permissions im Detail

📦 Release 2601 – Die wichtigsten Features im Detail

Android Enterprise: Neue OEMConfig Apps und bessere Filteroptionen

Zwei Themen die für Android-Enterprise-Admins interessant sind:

Erstens: Neue OEMConfig Apps. Microsoft hat drei neue OEMConfig-Apps in Intune verfügbar gemacht – FCNT Senior Care, FCNT Schema und Sonim. FCNT ist ein japanischer OEM mit Fokus auf robuste und barrierefreie Geräte (Senior Care ist selbst erklärend), Sonim ist für ultra-ruggedized Devices bekannt. Wer Geräte dieser Hersteller im Einsatz hat oder plant: die OEMConfig-Integration ermöglicht herstellerspezifische Konfigurationen direkt über Intune, ohne App-Wrapper oder Sonderlösungen.

Zweitens: Android Management Mode Filter im Settings Catalog. Beim Erstellen von Android-Policy-Profiles im Settings Catalog gibt es jetzt einen Filter nach dem Enrollment-Typ: Fully Managed, Corporate-owned Work Profile oder Dedicated. Das klingt nach einem kleinen QoL-Feature – ist aber in der Praxis ein echter Zeitgewinn. Wer heterogene Android-Flotten mit verschiedenen Enrollment-Typen verwaltet, findet die relevanten Settings jetzt schneller, ohne durch hunderte Optionen zu scrollen.

Android & iOS: Granularere Assignment Filter für Managed Apps

Das ist ein Feature das unter dem Radar läuft, aber operativ relevant ist. Assignment Filter erlauben es in Intune, Policy-Zuweisungen nicht nur nach Gruppe, sondern nach spezifischen Device-Properties zu steuern. Mit 2601 kommen deutlich mehr Optionen für den Device Management Type bei Managed Apps:

  • Android neu: Corporate-owned with work profile, Corporate-owned fully managed, Corporate-owned dedicated devices without Entra ID Shared mode
  • iOS/iPadOS neu: Automated Device Enrollment user-associated, Automated Device Enrollment userless, Account Driven User Enrollment, Device Enrollment with Company Portal and Web Enrollment

Warum ist das wichtig? In komplexen Umgebungen mit gemischten Enrollment-Typen – z.B. BYOD mit Work Profile neben Corporate-owned Fully Managed Devices – können Admins jetzt granular steuern welche App Protection Policies und App Config Policies für welchen Device-Typ gelten. Das reduziert Policy-Wildwuchs und ermöglicht sauberere Segmentierung. Das Feature rollt laut Microsoft bis Ende März 2026 vollständig aus.

iOS/iPadOS: Neues im Settings Catalog

Zwei Änderungen für iOS-Admins:

Erstens das neue Setting Rating Apps Exempted Bundle IDs. Wer auf Schulgeräten Altersrestriktionen konfiguriert hat (z.B. nur Apps bis 9 Jahre), konnte bisher keine Ausnahmen für bestimmte Apps definieren. Mit diesem Setting können Admins spezifische Apps vom Altersfilter ausnehmen – z.B. eine Lern-App die technisch ein 17+-Rating hat, aber inhaltlich für Schüler vollkommen unbedenklich ist.

Zweitens ein Umbenennung: Apple hat Rapid Security Responses in Background Security Improvements umbenannt. Intune hat das im Settings Catalog entsprechend nachgezogen. Kein funktionaler Unterschied – aber wer nach dem alten Namen gesucht hat, findet es jetzt unter dem neuen.

Windows: Neue Settings Catalog Policies

Microsoft hat wieder eine Reihe neuer Policies in den Windows Settings Catalog aufgenommen. Hier die MDM-relevanten Highlights:

  • Microsoft Edge bis v143 – inklusive neuer Policy zum Teilen von browsing history mit Microsoft 365 Copilot Search (ja, genau das was viele Admins kontrollieren wollen), RAM-Ressourcensteuerung und Local Network Access Restrictions
  • Windows AI Controls – neue Settings für Agent Workspaces, Agent Connectors und Remote Agent Connectors (aktuell noch Windows Insiders, aber gut zu kennen für die Zukunft)
  • Disable Share App Promotions – endlich: Admins können verhindern dass Windows im Share Sheet Werbung für Apps macht. Klingt trivial, war aber ein echtes Ärgernis in managed Umgebungen
  • Firewall Audit Mode – neues Setting um den Audit Mode für die Windows Firewall zu aktivieren (nützlich für Security-Reviews und Compliance-Audits)
  • Google Chrome ADMX bis v141 – immer schön wenn der Settings Catalog aktuell bleibt

Windows: PowerShell-Installer für Win32 Apps

Das ist ein Feature aus dem Januar-Update (Week of January 12) das ich kurz erwähnen möchte, weil es für viele App-Deployments relevant ist: Win32 Apps können jetzt mit einem PowerShell-Script als Installer deployt werden – statt mit einer klassischen Command Line. Das bedeutet: Prerequisite-Checks, Config-Änderungen, Post-Install-Aktionen – alles direkt im Installer-Script. Das ist besonders nützlich für komplexe App-Deployments die mehr als nur ein simples Setup.exe /S brauchen.

EPM: Support für Azure Virtual Desktop

Endpoint Privilege Management (EPM) – das Feature für granulare Elevation-Policies ohne lokale Admin-Rechte – unterstützt jetzt auch Azure Virtual Desktop (AVD) Single-Session VMs. Für alle die AVD in ihrem Modern Workplace Stack haben: EPM-Elevation-Policies können jetzt auch auf diese VMs deployed werden. EPM ist Teil des Intune Suite Add-ons.

Lenovo Device Orchestration: Direktlink im Admin Center

Kleines aber praktisches Feature für alle mit Lenovo-Flotten: Das Intune Admin Center hat jetzt einen direkten Link zur Lenovo Device Orchestration (LDO) Plattform unter Partner Portals. Das schafft einen single entry point für Lenovo-spezifische Device-Management-Funktionen – ohne extra Login oder Tab-Hopping.

⚠️ Wichtig & Handlungsbedarf: Azure Front Door IP-Adressen

⚠️ AKTION ERFORDERLICH wenn ihr IP-basierte Allowlists nutzt: Microsoft Intune verwendet seit Dezember 2025 Azure Front Door (AFD) IP-Adressen zusätzlich zu den bisherigen Intune Service IPs. Wer IP-basierte Firewall-Regeln, VPN-Policies oder Proxy-Allowlists betreibt, MUSS diese anpassen – sonst kann die Intune-Kommunikation der verwalteten Geräte eingeschränkt oder unterbrochen werden.

Microsoft hat das im Rahmen der Secure Future Initiative (SFI) kommuniziert – und es ist eines der Features das im Alltag leicht übersehen wird, aber operative Konsequenzen hat. Hier die Details:

Wenn ihr FQDN-basierte Regeln nutzt (empfohlen): Stellt sicher dass *.manage.microsoft.com als Wildcard-Regel konfiguriert ist. Typischerweise kein weiterer Handlungsbedarf.

Wenn ihr IP-basierte Allowlists nutzt: Folgende IP-Ranges müssen hinzugefügt werden (Commercial Endpoints):

  • 13.107.219.0/24
  • 13.107.227.0/24
  • 13.107.228.0/23
  • 150.171.97.0/24
  • 2620:1ec:40::/48 (IPv6)
  • 2620:1ec:49::/48 (IPv6)
  • 2620:1ec:4a::/47 (IPv6)

Alternativ kann der Azure Service Tag AzureFrontDoor.MicrosoftSecurity genutzt werden. Für US Government Endpoints gelten separate IPs – die aktuellen Ranges findet ihr direkt in den offiziellen Intune Network Endpoints Dokumenten.

💡 Empfehlung: Wenn ihr es noch nicht getan habt – wechselt auf FQDN-basierte Regeln. Ihr reduziert damit dauerhaft den Wartungsaufwand, weil IP-Änderungen nicht mehr manuell nachgepflegt werden müssen. Microsoft empfiehlt das ausdrücklich.

Reporting & Administration: Was sich verbessert hat

Admin Tasks jetzt Generally Available

Der Admin Tasks Node unter Tenant Administration ist aus der Public Preview raus und jetzt Generally Available. Was ist das? Eine zentrale Ansicht im Intune Admin Center die alle offenen Aufgaben bündelt – EPM-Elevation-Requests, Microsoft Defender Security Tasks und Multi-Admin-Approval-Requests. Alles auf einer Seite, mit Such- und Filterfunktion. Wer bisher durch verschiedene Admin-Center-Bereiche navigieren musste um den Überblick zu behalten – das ist jetzt deutlich angenehmer.

Windows 11 25H2 in Feature Update Reports

Die Windows Feature Update Readiness- und Compatibility Risks-Reports unterstützen jetzt Windows 11 25H2 als Ziel-OS. Das ist relevant für alle die gerade planen, wann und wie sie auf 25H2 upgraden wollen – die Reports zeigen jetzt Readiness-Status und potenzielle Compatibility-Risiken für diese Version, bevor man das Update ausrollt.

Zimperium MTD: Certificate Inventory Sync für iOS

Wer Zimperium als Mobile Threat Defense Partner nutzt: Es gibt eine neue Integration. Der Zimperium MTD Connector kann jetzt das Certificate Inventory von iOS-Geräten synchronisieren – also eine Liste der installierten Zertifikate. Das erlaubt Zimperium zu erkennen, wenn ein Device durch ein potenziell schädliches Zertifikat kompromittiert wurde. Konfigurierbar über den MTD Connector mit zwei neuen Settings: Enable Certificate Sync und Send full certificate inventory data for personally-owned devices.

Fazit: Zwei Releases – viel Substanz

2601 und 2602 sind keine „Mega-Releases“ mit einem einzelnen Killer-Feature – aber sie zeigen schön wie Microsoft Intune in der Breite reift: Granularere Policies, bessere Filter, mehr OEM-Support, sicherere Infrastruktur und mit den neuen MHS RBAC-Permissions ein echtes Alltagsproblem gelöst.

Was sollten Admins jetzt konkret tun? Erstens die Azure Front Door IP-Situation prüfen – das ist der einzige Punkt mit echtem Handlungsbedarf. Zweitens die neuen Assignment Filter für Managed Apps im Auge behalten (Rollout bis Ende März). Und drittens – wenn MHS im Einsatz ist – die neuen RBAC-Permissions reviewen und den Support-Workflow anpassen.

Ich bin gespannt was 2602 noch alles bringt wenn die vollständige Dokumentation online ist. Bis dahin – ran an die Kommentare, welches Feature freut euch am meisten? 😄

🔗 Quellen & weiterführende Links:

• Microsoft Learn – Intune What’s New (2601/2602): learn.microsoft.com/intune/fundamentals/whats-new

• M365 Admin – Service Update February 2026 (2602): m365admin.handsontek.net

• Microsoft Support Tip – Upcoming Intune Network Changes: techcommunity.microsoft.com

• Microsoft Learn – Intune Network Endpoints: learn.microsoft.com/intune/fundamentals/intune-endpoints

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

4. März 2026 / / Keine Kommentare

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