Monat: Juli 2026

Workspace ONE Modern SaaS (ModStack): Was die neue Architektur bedeutet – und warum On-Prem 2410 die Endstation ist

27. Juli 2026 / / Keine Kommentare

Wer On-Prem betreibt, sollte die Migration jetzt planen: Shared SaaS, Preferred SaaS (dedizierter Tenant, ohne Re-Enrollment der Geräte) oder – für regulierte Umgebungen – die partner-gehostete Sovereign Solution.

Wenn ihr in den letzten Monaten Omnissa-Blogs, KB-Artikel oder Community-Posts verfolgt habt, seid ihr an einem Begriff nicht vorbeigekommen: Modern SaaS Architecture, intern und in der Community meist ModStack (Modern Stack) genannt. Klingt erstmal nach Marketing – ist aber die größte technische Umbaumaßnahme in der Geschichte der Plattform seit den AirWatch-Tagen. Und sie hat handfeste Konsequenzen: für die tägliche Administration, für die Feature-Roadmap und vor allem für alle, die noch On-Premises unterwegs sind.

In diesem Beitrag erkläre ich, was ModStack technisch ist, warum Omnissa diesen Schritt geht, welche Features die neue Architektur bereits gebracht hat und noch bringen wird – und wo für On-Prem-Kunden die harte Deadline liegt.

Was ist ModStack? Der Umbau plausibel erklärt

Workspace ONE UEM stammt architektonisch aus der AirWatch-Ära: ein monolithischer Stack aus Windows-Servern (Console, Device Services, AWCM, API) und einer zentralen MS-SQL-Datenbank. Dieselbe Codebasis lief On-Prem beim Kunden und in Omnissas SaaS-Rechenzentren – die SaaS war im Kern eine gehostete On-Prem-Installation.

Das Modell hat zwei strukturelle Probleme. Erstens die Skalierung: Ein Monolith skaliert nur als Ganzes – wer mehr Enrollment-Durchsatz braucht, muss den kompletten Stack größer ziehen, auch wenn nur eine Teilfunktion am Limit ist. Zweitens die Release-Geschwindigkeit: Jede Änderung muss durch den gesamten Monolithen getestet und als großes Release ausgerollt werden. Quartalsweise Major-Releases plus Patch-Zyklen waren die Folge – in einer Welt, in der Apple und Google im Wochentakt neue MDM-Anforderungen liefern, ein echtes Handicap.

ModStack löst beides, indem das Backend in Microservices zerlegt wird: einzelne, unabhängig deploybare Dienste (Enrollment, Profil-Engine, App-Delivery, Event-Verarbeitung usw.) in Containern, orchestriert in einer Cloud-nativen Umgebung. Jeder Dienst skaliert für sich, jeder Dienst kann einzeln aktualisiert werden – ohne Big-Bang-Release, ohne Wartungsfenster für die ganze Plattform. Die Kommunikation zwischen UEM und Geräten wurde laut Omnissa dabei um mehr als das Zehnfache beschleunigt: Neue Apps und Settings kommen praktisch sofort auf dem Gerät an („Desired State“ statt Polling-Warterei).

Warum macht Omnissa das?

  • Innovationsgeschwindigkeit: Features können pro Microservice entwickelt und ausgerollt werden. Bestes Beispiel: Die Apple-DDM-Integration importiert Declarative-Management-Konfigurationen inzwischen automatisch aus Apples GitHub-Repository – Day-0-Support für neue iOS-Releases (z. B. iOS 26), ohne dass die Plattform ein Versions-Upgrade braucht.
  • Skalierung und Resilienz: Lastspitzen (Massen-Enrollments, große Rollouts) treffen nur die betroffenen Dienste, die horizontal skalieren. Ausfälle bleiben lokal begrenzt statt die Konsole komplett zu reißen.
  • Infrastruktur-Neutralität: Die containerisierte Architektur läuft auf Public Clouds ebenso wie in privaten Rechenzentren. Genau das ermöglicht die neue Omnissa Sovereign Solution – ein von qualifizierten Partnern komplett lokal gehostetes, modernes UEM für regulierte Branchen (Stichwort GDPR, BDSG, CLOUD-Act-Risiken).
  • Eine Codebasis statt zwei Welten: Die Pflege des On-Prem-Monolithen parallel zur SaaS band Entwicklungsressourcen. Die Konsequenz ist bekannt – und Thema des letzten Abschnitts.

Was ModStack an Features bringt – heute und morgen

Bereits verfügbar (auf Modern-SaaS-Umgebungen)

  • Massiv beschleunigte Geräte-Kommunikation und häufigere Desired-State-Abgleiche – Profile und Apps erreichen Geräte deutlich schneller.
  • Fast Lane Deployment für sofortige Auslieferung kritischer Updates.
  • App-Exclusions auf Versions-Ebene statt pauschal pro Bundle-ID – granulareres App-Management (Achtung, Verhaltensänderung – siehe Warn-Box unten).
  • Verbesserte Troubleshooting-Event-Logs mit mehr Detailtiefe in der Konsole.
  • Apple DDM mit automatischem Konfigurations-Import aus dem Apple-GitHub-Repository (Day-0-Support ohne Plattform-Upgrade).
  • Intelligence-UEM Modern Integration: komplett überarbeitete Datenpipeline mit End-to-End-Monitoring, erweitertem Schema und Daten-Joins in Dashboard-Widgets (erfordert Modern Architecture 2506 Patch 16 oder neuer).

Auf ModStack gebaut: die Feature-Welle 2602/2604

Die jüngsten Releases zeigen, wofür der Umbau gemacht wurde – dieses Tempo und diese Feature-Dichte wären auf dem Monolithen kaum denkbar gewesen:

  • Next-Gen Windows Management: Intelligent Hub Managed Mode ohne OMA-DM-Abhängigkeit, koexistenzfähig mit SCCM/anderen MDMs, Server-side Step-up von Registered zu Managed – und Windows Server Management (GA in 2604).
  • Vulnerability Defense (Limited Availability, 2604): CVE-zu-Endpoint-Mapping mit CrowdStrike-Integration und Remediation direkt aus der Konsole.
  • Enterprise App Repository für Windows (10.000+ Apps) und macOS (kuratierter Katalog mit Auto-Updates).
  • Phased App Deployments, eSIM-Management für Android, erweiterte AMAPI-Policies, modernisierte Konsolen-UI – die Liste wächst mit jedem Release.

Die Richtung ist klar: Neue Features erscheinen zuerst – und zunehmend ausschließlich – auf der Modern-SaaS-Schiene.

On-Premises: Endstation 2410 – die Fakten zur Deadline

Die Kehrseite der ModStack-Strategie: Der On-Prem-Monolith wird nicht auf die neue Architektur portiert. Das bedeutet im Klartext:

Frage Antwort
Bis zu welcher Version kann On-Prem upgegradet werden? Workspace ONE UEM 2410 (24.10) ist die letzte installierbare On-Prem-Version. Einen Upgrade-Pfad auf 2412, 25xx oder 26xx gibt es nicht.
Gibt es noch Patches? Ja – bis zum End of Support werden für 2410 weiterhin Patches bereitgestellt, aber keine neuen Funktionen.
Wann ist Schluss? End of Support: 30. April 2027. Danach gibt es weder Patches noch Support.
Bis wann sollte migriert werden? Deutlich vor dem 30.04.2027 – die Migration selbst (inkl. ACC/UAG/SEG-Neuaufbau, Tests, ggf. Re-Enrollment) braucht je nach Umgebung mehrere Monate Vorlauf. Alle Komponenten müssen für eine unterstützte Migration auf supporteten Versionen laufen.

Wichtig zur Einordnung der Frage „bis wann kann ich noch zu SaaS migrieren“: Es gibt keinen technischen Stichtag, an dem die Migration abgeschaltet wird. Aber nach dem 30.04.2027 betreibt ihr eine unsupportete, ungepatcht alternde Plattform – jede Migration von dort ist ein Risiko-Projekt ohne Herstellerrückendeckung. Praktisch ist der 30.04.2027 daher die Deadline, bis zu der die Migration abgeschlossen sein sollte, nicht gestartet.

Die drei Migrationspfade

Pfad Modell Besonderheit
Shared SaaS Public Cloud, geteilte Ressourcen Kostengünstigster Einstieg; Re-Enrollment der Geräte erforderlich
Preferred SaaS Public Cloud, dedizierter UEM-Tenant Migration ohne Re-Enrollment der Geräte möglich (Device Migration); höhere Kosten
Sovereign Solution Partner-gehostet im lokalen Rechenzentrum Für regulierte Branchen (Energie, Finanzen, Healthcare, Public); volle Datensouveränität auf ModStack-Basis

Fazit

ModStack ist kein Buzzword, sondern die Grundlage für alles, was bei Workspace ONE in den nächsten Jahren passiert – von Day-0-OS-Support über Next-Gen Windows Management bis zur Sovereign Solution. Für SaaS-Kunden heißt das: schnellere Features, aber auch ein paar Verhaltensänderungen, die man vor der Umstellung sauber vorbereitet. Für On-Prem-Kunden heißt es: 2410 ist das Ende des Weges, am 30. April 2027 fällt der Vorhang. Wer jetzt mit der Migrationsplanung beginnt, wandelt die Pflicht in eine Chance – und landet auf einer Plattform, die technologisch endlich wieder vorne mitspielt.

Intelligent Hub Registrierungsfehler nach Backup-Restore: Warum die iOS Keychain dein Enrollment killt

24. Juli 2026 / / Keine Kommentare

Intelligent Hub Registrierungsfehler nach Backup-Restore: Warum die iOS Keychain dein Enrollment killt

Das Fehlerbild

Folgendes Szenario landete diese Woche auf meinem Tisch: Ein iPhone (nicht supervised, Hub-basiertes Enrollment) wird registriert. Schritt 1 und 2 im Hub laufen sauber durch, das MDM-Profil ist installiert – und dann knallt es:

Fehler

Die Registrierung konnte nicht abgeschlossen werden.

Bitte registrieren Sie das Gerät erneut oder wenden Sie sich an Ihren Administrator.

Das Kuriose daran: Aus Sicht der UEM-Konsole ist alles in Ordnung. Das Gerät ist enrolled, Profile werden gepusht und installiert, Compliance läuft, der Benutzer ist in allen Gruppen korrekt zugeordnet. Nur der Intelligent Hub selbst kommt nicht über seine Registrierung hinaus. Und um es noch besser zu machen: Das andere iPhone desselben Benutzers funktioniert ohne Probleme.

Wichtig für das Verständnis: MDM-Enrollment und Hub-Registrierung sind zwei getrennte Vorgänge. Apples mdmclient redet mit den Device Services und installiert das Profil – das lief hier fehlerfrei. Danach macht die Hub-App ihren eigenen Handshake (Token-Austausch plus Hub Services Check-in), um sich mit dem Device Record zu pairen. Und genau der scheiterte.

Was nicht geholfen hat

Die üblichen Verdächtigen wurden der Reihe nach abgearbeitet – ohne Erfolg:

Maßnahme Ergebnis
Device Record auf Duplikate geprüft (Suche per Seriennummer/UDID) Kein doppelter oder veralteter Eintrag vorhanden
Geräte → Lebenszyklus → Registrierungsstatus geprüft Kein verwaister Eintrag, alles sauber
Hub-App gelöscht, Gerät neu gestartet, Hub neu installiert Identischer Fehler beim nächsten Versuch
Enrollment komplett neu (Profil entfernt, Record gelöscht, Re-Enrollment) MDM läuft, Hub-Registrierung scheitert erneut
Benutzer, Gruppen, Enrollment Restrictions geprüft Alles korrekt – zweites Gerät des Users funktioniert

Wenn Konsole, Benutzer und Netzwerk sauber sind und selbst ein komplettes Re-Enrollment nichts ändert, bleibt nur noch eine Erkenntnis: Das Problem liegt auf dem Gerät selbst – und zwar an einer Stelle, die weder App-Neuinstallation noch Re-Enrollment anfasst.

Die Ursache: Die Keychain aus dem Backup

Der entscheidende Hinweis kam aus der Vorgeschichte des Geräts: Es wurde bei der Einrichtung aus einem verschlüsselten iTunes-Backup wiederhergestellt. Und damit war der Fall klar.

Verschlüsselte lokale Backups sichern die komplette Keychain

Verschlüsselte iTunes-/Finder-Backups sichern die iOS Keychain vollständig mit – inklusive der Keychain-Einträge von Third-Party-Apps. Der Intelligent Hub legt genau dort seine Enrollment-Identität ab: das Authentifizierungs-Token, mit dem er sich gegenüber den Device Services als „dieses eine, bereits registrierte Gerät“ ausweist.

Beim Restore kommt diese Identität eins zu eins zurück auf das Gerät. Das Problem: Sie gehört zu einem Enrollment, das serverseitig längst nicht mehr existiert – in unserem Fall war das alte Enrollment vor dem Restore per Enterprise Wipe aus dem MDM entfernt worden. Der Hub präsentiert dem Server also bei jeder Registrierung ein Token, zu dem es keinen Datensatz mehr gibt. Der Server lehnt ab, der Hub wirft die generische Fehlermeldung.

Warum Hub löschen und neu installieren nichts bringt

Hier kommt die zweite iOS-Eigenheit ins Spiel, über die man erst stolpern muss: iOS löscht die Keychain-Einträge einer App bei deren Deinstallation nicht. Der frisch aus dem App Store installierte Hub findet beim ersten Start die alte Identität in der Keychain, verwendet sie – und scheitert exakt gleich. Man kann die App so oft neu installieren, wie man will.

Warum das MDM trotzdem funktioniert

Konfigurationsprofile und der MDM-Verwaltungsstatus sind grundsätzlich nicht Teil von iOS-Backups. Das frische MDM-Enrollment, das nach dem Restore durchgeführt wurde, ist also vollkommen intakt – Apples mdmclient weiß nichts von der Keychain-Leiche und arbeitet brav seine Commands ab. Deshalb das paradoxe Bild: Gerät voll gemanagt, Hub tot.

Info

Diagnose-Tipp: Wenn der Hub nicht bis zum Login kommt, gibt es auch keinen Diagnosebericht aus der App heraus. Alternative: iPhone per USB an einen Mac, Console.app öffnen, Gerät auswählen und den Live-Stream beim Reproduzieren des Fehlers mitschneiden. Filter auf den Hub-Prozess bzw. Suchbegriffe wie „AirWatch“, „awmdm“ oder „deviceservices“. Ein 401/403 beim Registration-Call gegen die Device Services ist die Bestätigung für ein verwaistes Token.

iTunes-Backup vs. iCloud-Backup: Der feine Unterschied

An dieser Stelle lohnt ein Blick in die Apple Platform Security Dokumentation, denn die beiden Backup-Verfahren behandeln die Keychain fundamental unterschiedlich – und genau dieser Unterschied entscheidet darüber, ob euch das Problem beim nächsten Gerätetausch wieder einholt:

Eigenschaft Verschlüsseltes lokales Backup iCloud-Backup
Keychain wird gesichert Ja, vollständig Ja, vollständig
Schutz der Keychain Backup-Passwort (PBKDF2) Gerätespezifischer Hardware-Key (Secure Enclave UID)
Restore auf anderes Gerät Keychain wandert mit (außer ThisDeviceOnly-Items) Keychain wird verworfen – Rest kommt an
Restore auf dasselbe Gerät Keychain kommt zurück Keychain kommt zurück
Risiko im MDM-Kontext Hub-Identität wandert beim Gerätetausch mit Beim Gerätetausch sauber, beim Same-Device-Restore nicht

Kurz gesagt: Das iCloud-Backup verschlüsselt die Keychain mit einem Schlüssel, der aus der Secure Enclave des Geräts abgeleitet wird. Diese Keychain lässt sich damit ausschließlich auf exakt dieselbe Hardware zurückspielen. Beim Gerätetausch bleibt die Hub-Identität des Altgeräts also automatisch auf der Strecke – genau das, was wir im MDM-Umfeld wollen. Das verschlüsselte lokale Backup dagegen schützt die Keychain nur mit dem Backup-Passwort und transportiert sie damit fröhlich auf jede beliebige neue Hardware.

Achtung

Der iCloud-Vorteil greift nur beim Wechsel auf ein anderes Gerät! Wird ein Backup – egal ob lokal oder iCloud – auf dasselbe Gerät zurückgespielt, kommt die Keychain in beiden Fällen zurück. Für ein Re-Enrollment desselben Geräts ist daher grundsätzlich keine Backup-Wiederherstellung geeignet. Und: Auch die Quick-Start-Direktübertragung von Gerät zu Gerät migriert die Keychain – die ist im MDM-Kontext genauso tabu wie das verschlüsselte lokale Backup.

Die Lösung für das betroffene Gerät

Die restaurierte Keychain lässt sich auf dem Gerät nicht selektiv bereinigen – ohne Jailbreak kommt man an die Einträge einer fremden App schlicht nicht ran. Es hilft also nur der harte Schnitt:

  1. MDM-Profil auf dem Gerät entfernen und Device Record in der Konsole löschen (inklusive Check unter Geräte → Lebenszyklus → Registrierungsstatus).
  2. Gerät auf Werkseinstellungen zurücksetzen und als neues iPhone einrichten – ohne Backup-Wiederherstellung.
  3. Enrollment über den Intelligent Hub durchführen und die Registrierung vollständig abschließen, bevor irgendetwas anderes am Gerät passiert.
  4. Persönliche Daten anschließend über die iCloud-Synchronisierungsdienste zurückholen: Fotos, Kontakte, Kalender, Mail und Passwörter via iCloud-Schlüsselbund. Diese Dienste synchronisieren Inhalte, ohne die lokale Keychain des Geräts zu überschreiben.

Ja, ein Factory Reset ist genau das, was man bei einem fertig eingerichteten Endanwender-Gerät vermeiden will. Aber die Kombination aus restaurierter Keychain und gewiptem Device Record ist device-seitig anders schlicht nicht zu reparieren – da hilft auch keine noch so kreative Reihenfolge aus Löschen, Neustarten und Neu-Enrollen.

Der richtige Workflow für die Zukunft

Damit euch das Thema nicht beim nächsten Gerätetausch wieder auf die Füße fällt, hier die Empfehlung für die beiden relevanten Szenarien:

Szenario Empfohlen Vermeiden
Gerätetausch (neue Hardware) Neugerät als neues Gerät einrichten, MDM-Enrollment durchführen, persönliche Daten via iCloud-Dienste synchronisieren. Alternativ: Restore aus iCloud-Backup. Verschlüsseltes lokales Backup (iTunes/Finder/Apple Devices App), Quick-Start-Direktübertragung
Re-Enrollment desselben Geräts (z. B. Benutzerwechsel, Austritt) Factory Reset und Einrichtung als neues Gerät. Immer. Jede Form von Backup-Restore – auch iCloud, da auf identischer Hardware die alte Keychain zurückkehrt
Generell Enrollment immer auf frisch eingerichtetem Gerät, Hub-Registrierung komplett abschließen, bevor weitere Schritte folgen Backup-Restore nach oder während des Enrollments
Tipp

Firmen-Apps und -Konfigurationen müssen ohnehin nicht aus einem Backup kommen – die pusht euer MDM nach dem Enrollment automatisch aufs Gerät. Wer die persönlichen Daten der Anwender konsequent über iCloud-Dienste synchronisiert statt über Backups transportiert, hat beim Gerätetausch den saubersten und nebenbei auch den schnellsten Prozess.

Fazit

Ein Fehlerbild, das auf den ersten Blick nach Konsolen- oder Netzwerkproblem aussieht, entpuppt sich als Apple-Security-Feature mit Nebenwirkungen: Die Keychain überlebt App-Deinstallationen und reist in verschlüsselten lokalen Backups mit – inklusive der Enrollment-Identität des Intelligent Hub. Wer das Verhalten der beiden Backup-Verfahren kennt, erspart sich stundenlanges Troubleshooting an Stellen, an denen das Problem gar nicht liegt. Und wer seinen Gerätetausch-Workflow einmal sauber definiert, sieht diesen Fehler nie wieder.

 

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