Kategorie: MDM

Intune Release 2607: Samsung Knox, Edge & OneDrive

6. August 2026 / / Keine Kommentare

Intune Release 2607: Samsung Knox E-FOTA und die nächste Welle neuer Policies

Juli 2026 – und wieder gibt’s Bewegung im Intune-Kosmos. Diese Release bringt mir ehrlich gesagt ein paar richtig interessante Features, die den MDM-Alltag vereinfachen. Allen voran: Samsung Knox E-FOTA Integration. Endlich können wir Firmware-Updates für Samsung-Geräte direkt aus Intune rollen, ohne Umwege über externe Tools. Aber auch sonst ist einiges los – neue Windows Settings Catalog Einträge, frische Edge-Policies und OneDrive-Kontrollen, die echte Use-Cases lösen.

Quick-Überblick: Was ändert sich?

Feature Plattform Kategorie Priorität
Samsung Knox E-FOTA Android Enterprise (COSU/COBO/COPE) Device Config 🔴 Hoch
Windows Settings Catalog (Camera, WSL, Keyboard Filter) Windows 10/11 Device Config 🟡 Mittel
Microsoft Edge 149 Policies Windows Device Config 🟡 Mittel
Windows App (AVD) Settings Windows Device Config 🟡 Mittel
Remove Default MS Store Packages (Custom PFNs) Windows Device Config 🟢 Niedrig
Disable Get Started App Windows Device Config 🟢 Niedrig
OneDrive Custom Folder Name & OIDC Auth Windows Device Config 🟡 Mittel
Setup Assistant Screens (tvOS/visionOS) tvOS, visionOS Enrollment 🟢 Niedrig
Visual Studio MCP Setting Windows Device Config 🟢 Niedrig

Die Highlights im Detail

Samsung Knox E-FOTA Integration – Das Game-Changer-Feature

Das ist die größte News dieser Release. Samsung Knox E-FOTA ermöglicht es dir, Firmware-Updates für Corporate-Owned Samsung Devices direkt aus dem Intune Admin Center zu orchestrieren.

Was praktisch bedeutet das?

  • Kontrollierte Firmware-Rollouts: Du wählst, welche Firmware-Version auf welche Devices kommt
  • Zero-Touch Deployment: Updates laufen ohne User-Interaktion im Hintergrund
  • Intelligente Scheduling: Downloads und Installationen lassen sich zeitlich steuern, um Downtime zu minimieren
  • Kompatibilität: Funktioniert mit COSU, COBO und COPE

Für wen ist das relevant?

Wenn du in deinem Org Samsung-Devices mass-deployest (Retail, Logistics, Manufacturing), war die Firmware-Verwaltung bisher manuell oder über Workarounds. Jetzt ist es native in Intune. Das spart echte Stunden bei großen Deployments.

Achtung: Samsung Knox E-FOTA setzt voraus, dass die Devices mit Samsung Knox Manage enrolled sind. Das ist ne Abhängigkeit, die du im Planning checken musst.

Windows Settings Catalog erweitert: Camera, WSL & Keyboard Filter

Microsoft packt wieder neue Knöpfe ins Settings Catalog rein:

Camera-Verhalten: Neue Policies für Kamera-Kontrollen – nützlich für Security-sensitive Umgebungen, wo du Kamera-Zugriff lockdown musst.

Windows Subsystem for Linux (WSL): Erste WSL-Policies im Catalog. Das interessiert primär DevOps- und Developer-Teams, die WSL in Corporate-Umgebungen einsetzen.

Keyboard Filter (Windows Insider): Für Kiosk- und COSU-ähnliche Szenarien auf Windows – praktisch für restricted Devices.

Wo gehst du hin?
Devices > Manage devices > Configuration > Create > New policy > Windows 10 and later > Settings catalog

Microsoft Edge 149 Policies – Copilot & Security im Fokus

Die Edge Administrative Templates wurden auf Version 149.0.4022.21 aktualisiert. Das bedeutet ~20+ neue Policies. Highlights:

Copilot-Integration:
– AllowBrowsingWithCopilot – Browsing with Copilot aktivieren/deaktivieren
– CopilotNewTabPageEnabled – Neue Tab Page mit Copilot
– ConfigureNTPFeedTabVisibility – Discover oder Work Feed steuern
– SetNTPDefaultFeedTab – Standard-Feed definieren
– CopilotAddressBarSuggestionsEnabled – Address Bar Suggestions

Microsoft 365 & Authentifizierung:
– M365AuthPopupsInWorkEnabled – M365-Auth in Work Profiles
– M365LinksAutoOpenCopilotEnabled – Auto-Open Copilot für Outlook-Links
– MAMWithDeviceDLP – MAM-Enrollment mit Device-DLP Policies

Sicherheit:
– LocalFontsAllowedForUrls / LocalFontsBlockedForUrls – Fine-Grained Control für lokale Fonts
– DeveloperToolsAvailabilityAllowlist / DeveloperToolsAvailabilityBlocklist – DevTools-Kontrolle per URL
– BrowsingWithCopilotAllowList / BrowsingWithCopilotBlockList – Copilot per URL steuern

Performance:
– CpuPerformanceTierOverride – CPU-Performance-Tier anpassen
– MaxConnectionsPerProxyForWebSocket – WebSocket-Proxy-Limits

Relevanz: Wenn du Copilot in Enterprise rollst, werden diese Policies zentral – vor allem AllowBrowsingWithCopilot und die Allow/Block-Lists für spezifische URLs.

Windows App (Azure Virtual Desktop) – Update-Management & UX

Neue Settings für Windows App (the modern Azure Virtual Desktop client):

Update-Steuerung:
– Turn off automatic updates – Automatische Updates deaktivieren (z.B. für Change Windows)
– Admin Release Ring Policy – Auf welchem Release Ring läuft die App (Stable/Preview/etc.)

User Experience:
– Automatically log off users after inactive interval – Idle-Timeout mit Auto-Logoff
– Skip First Run Experience (FRE) – Direkt zu Ressourcen, ohne Setup-Wizard
– Automatically create Windows App shortcuts to desktop – Desktop-Shortcuts für Resources

Praktischer Nutzen: Für VDI-Admins mit großen Windows App Deployments. FRE-Skip spart Support-Tickets, Inactivity Logout erhöht Security in Shared-Device Szenarien.

OneDrive Settings: Custom Folder Name, OIDC & Offline Mode

Ordentlich was Neues für OneDrive-Verwaltung:

Collaboration & Hybrid:
– Custom OneDrive Folder Name – Branding deiner Sync-Ordner
– OpenID Connect (OIDC) für On-Prem SharePoint – OneDrive kann sich via OIDC an on-prem SharePoint Server authentifizieren. Das ist wichtig für Hybrid-Setups ohne Legacy-Auth
– Application ID URI für OIDC – Konfigurierbar, wenn dein OIDC-App-ID-URI vom SharePoint-URL abweicht

Security & Compliance:
– Block Offline Mode on Web – Verhindert, dass User OneDrive Web offline nutzen
– Block Offline Mode für externally shared Libraries/Folders – Granularer – nur externe Shares blocken, interne erlauben
– Hard-Delete Folder Shortcuts – Wenn User Shortcut unmountet oder Permissions verliert, wird Content permanent gelöscht (nicht in Recycle Bin)

Use-Case: Das letzte Feature ist interessant für DLP/Compliance – wenn jemand eine Folder Shortcut zu sensiblen Daten verliert, wird sie nicht versehentlich wiederhergestellt.

Remove Default Microsoft Store Packages – Custom PFN Support

Die bestehende Remove Default Microsoft Store packages Policy kriegt eine neue Sub-Setting:

Specify additional package family names to remove – Ihr könnt jetzt custom Package Family Names (PFNs) definieren, die neben den default Microsoft Store Packages entfernt werden.

Praktisch: Wenn ihr Edge oder andere Microsoft Apps aus dem Store blocken wollt, ohne dass sie via CSP neu installiert werden.

Disable Get Started App

Neue Policy: Disable Get Started in der Experience Policy CSP.

Simpel: Windows Get Started App wird nicht verfügbar. Gut für Kiosk-Szenarien oder wenn ihr ein Custom Onboarding habt.

tvOS & visionOS Setup Assistant Screens Kontrolle

Bei Automated Device Enrollment (ADE) für tvOS und visionOS könnt ihr jetzt einzelne Setup Assistant Screens zeigen/verstecken:

  • Apple ID
  • Diagnostics Data
  • Location Services
  • (weitere)

Default: Alle Screens werden angezeigt. Ihr könnt jetzt selektiv skippen.

Relevanz: Für Apple TV oder Vision Pro in Corporate-Umgebungen – schnellerer Setup für Kiosks oder Shared Devices.

Visual Studio MCP Setting

Die Visual Studio Admin Templates wurden auf v1.0.184.40051 aktualisiert.

Neues Setting: Disable Model Context Protocol (MCP) (DisableMCP)

Model Context Protocol ist AI-Assistant-Zeug für Entwickler. Falls du willst, dass Devs das nicht nutzen, kannst du’s jetzt Policy-wide deaktivieren.

Handlungsbedarfe

🔴 Samsung Knox E-FOTA – Activation erforderlich

Falls du Samsung COSU/COBO/COPE Devices hast und Firmware-Updates zentralisieren möchtest:

  1. Dependency Check: Geräte müssen mit Samsung Knox Manage enrolled sein
  2. Tenant-Setup: Samsung Knox E-FOTA muss in deinem Intune Tenant aktiviert werden (wahrscheinlich via Samsung Business Cloud oder Intune Admin Portal)
  3. Testing: Pilot mit 5-10 Devices vor Prod-Rollout – Firmware ist kritisch
  4. Rollback-Plan: Falls ein Update schiefgeht, brauchst du ne Strategie (Manual Recovery vs. Retry)

🟡 Edge 149 Policies – Copilot Governance

Wenn Copilot in eurer Org rollts (und das tut’s):

  1. Allow/Block-List Strategy: Definiert, auf welchen Sites Copilot funktionieren soll
  2. DLP + MAM: Falls ihr Device-DLP habt, schaut auf die neue MAMWithDeviceDLP Policy
  3. Testing in Staging: Edge-Policies können Performance beeinflussen – testet vorher

🟡 OneDrive OIDC – Hybrid-Szenarien

Wenn ihr noch On-Prem SharePoint Server habt:

  1. OIDC-Readiness: Euer SharePoint Server muss OIDC unterstützen
  2. Entra App Registration: Ihr braucht ne App-Registration mit korrektem Application ID URI
  3. Testing: OIDC-Auth ist ne Abhängigkeit – nicht einfach so in Prod rollsen

🟢 Windows App Updates – Change Windows planen

Wenn ihr Turn off automatic updates nutzt:

  1. Kommunikation: User müssen wissen, dass Updates manual sind oder via Admin Ring gesteuert
  2. Support: Prepare Support Team auf ältere App-Versionen

Fazit

Release 2607 ist solide – keine groundbreaking Changes, aber echte Verbesserungen im Daily-Business:

  1. Samsung Knox E-FOTA ist das Highlight – endlich native Firmware-Verwaltung für Android Enterprise
  2. Edge 149 Policies zeigen, wie tief Copilot in der Verwaltung sitzt – das wird wichtig für Security & Governance
  3. OneDrive + Windows App Settings adressieren Hybrid- und Modern Work Szenarien smart
  4. tvOS/visionOS Setup Control – klein, aber für Apple-fokussierte Orgs relevant

Quellen

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.

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

iOS 27 und Workspace ONE: DDM-Migration – Der Schrittplan für deutsche Admins

10. Juni 2026 / / Keine Kommentare

iOS 27 und Workspace ONE: DDM-Migration – Der Schrittplan für deutsche Admins

Apple hat auf der WWDC 2026 den Startschuss gegeben – iOS 27 kommt im September. Für dich als Admin bedeutet das: Legacy MDM ist offiziell Geschichte. Hier bekommst du alles, was du wirklich wissen musst.

💡 Das Wichtigste in 30 Sekunden
iOS 27 erscheint September 2026 – Legacy MDM Update-Commands funktionieren danach NICHT mehr.
DDM (Declarative Device Management) ist ab iOS 27 Pflicht für Software-Update-Enforcement.
Workspace ONE UEM 2406+ unterstützt DDM für iOS – du brauchst mindestens diese Version.
Bestehende Profile und Policies bleiben unberührt – nur Update-Management muss migriert werden.
Die Siri AI kommt in der EU NICHT auf iOS 27 (Digital Markets Act) – vorerst nur auf macOS 27.

Was Apple auf der WWDC 2026 angekündigt hat

A m 8. Juni 2026, hat Apple auf der Worldwide Developers Conference in Apple Park iOS 27 offiziell vorgestellt. Der Fokus lag klar auf KI – konkret auf einem von Googles Gemini-Modell betriebenen Siri. Aber für uns Admins ist etwas anderes der eigentliche Knackpunkt:

  • iOS 27 unterstützt alle Geräte, die aktuell iOS 26 laufen – auch das iPhone 11 und neuere.
  • Apple Intelligence läuft nur auf iPhone 15 Pro, iPhone 16 und iPads/Macs mit M1 oder neuer.
  • Legacy MDM Update-Commands (ScheduleOSUpdate, OSUpdateStatus) werden mit iOS 27 komplett ignoriert.
  • DDM ist ab sofort Standard – nicht optional, nicht „demnächst“, sondern jetzt.
⚠️ Wichtig für die EU / Deutschland
Siri AI wird auf iOS 27 und iPadOS 27 in der EU NICHT verfügbar sein.
Apple begründet das mit dem Digital Markets Act (DMA).
Auf macOS 27, watchOS 27 und visionOS 27 ist Siri AI hingegen auch in der EU verfügbar.
Für Unternehmensumgebungen in Deutschland bleibt der operative Betrieb unverändert.

DDM vs. Legacy MDM – Was hat sich eigentlich geändert?

Der Unterschied zwischen Legacy MDM und DDM ist kein Buzzword – er ist architektonisch. Kurz gesagt:

Merkmal Legacy MDM (alt) DDM – Declarative Device Management (neu)
Steuerung Server schickt Befehle, Gerät führt aus Server definiert Zielzustand, Gerät kommt selbst dahin
Software Updates ScheduleOSUpdate-Command Software Update Enforcement Declaration
Check-in Abhängigkeit Ja – Command-Delivery muss klappen Nein – Gerät arbeitet eigenständig
Fehlertoleranz Gering (kein Check-in = kein Update) Hoch (Gerät retried eigenständig)
Statusreporting Nur nach Command-Ausführung Kontinuierlich via Status-Channel
iOS 27 kompatibel? NEIN – Commands werden ignoriert JA – vollständig unterstützt
Nutzer-Benachrichtigung Einmalig Mehrfach, Wochen im Voraus
ℹ️ Wie DDM intern funktioniert
Beim alten MDM: Workspace ONE schickt „Update jetzt!“ – und wartet.
Bei DDM: Workspace ONE erklärt den gewünschten Zustand (z.B. „iOS 27.0 bis 15.09.2026“).
Das Gerät übernimmt die Verantwortung, diesen Zustand zu erreichen.
Kein Check-in? Kein Problem – beim nächsten Kontakt macht das Gerät weiter.
Schlechte Verbindung? Das Gerät retried ohne serverseitigen Eingriff.

Workspace ONE UEM und DDM – Was du jetzt brauchst

Die gute Nachricht: Omnissa hat seine Hausaufgaben gemacht. DDM ist kein Zukunftsprojekt mehr – es ist fertig. Hier der aktuelle Stand:

WS1 UEM Version DDM Support Details
2406 (August 2024) iOS / iPadOS GA-Release: Software Update Enforcement, DDM Declarations, Status-Channel
2410 (Oktober 2024) macOS DDM für macOS hinzugekommen
2406+ (SaaS) Vollständig Beide Typen: Imperative und Declarative Profiles parallel möglich

Für On-Premises Kunden: Wenn ihr noch auf WS1 UEM 2306 oder älter seid, müsst ihr bis September 2026 auf mindestens 2406 upgraden – sonst habt ihr nach dem iOS 27 Rollout keine Kontrolle mehr über Software Updates auf iOS-Geräten.

⚠️ On-Premises Admins: Handlungsbedarf jetzt
WS1 UEM 2306 und älter: Kein DDM-Support.
Legacy Update-Commands funktionieren nach iOS 27 Release nicht mehr.
Upgrade auf mindestens WS1 UEM 2406 ist Pflicht vor September 2026.
SaaS-Kunden sind automatisch auf dem aktuellen Stand – kein Handlungsbedarf.

Schrittplan: Migration auf DDM in Workspace ONE

Hier ist der praxiserprobte Schrittplan – inklusive Timeline für September 2026:

Schritt 1: WS1 UEM Version prüfen (Sofort)

Prüfe deine aktuelle WS1 UEM Version unter System > General > Product Information.

  • SaaS: Ihr seid automatisch aktuell.
  • On-Premises: Ihr braucht mindestens Version 2406.
  • Ist deine Version älter als 2406, startet den Upgrade-Prozess asap. Bei Fragen, wende dich an deinen Dienstleister des Vertrauens.

Schritt 2: Bestehende iOS Update Policies inventarisieren (Woche 1–2)

Dokumentiert alle vorhandenen Legacy-Update-Policies unter Devices > Apple Updates > iOS/iPadOS Update Policies.

  • Welche Smart Groups sind zugewiesen?
  • Welche Versionen werden enforced?
  • Welche Deferred-Zeiten sind konfiguriert?
ℹ️ Koexistenz möglich
DDM und Legacy MDM können parallel auf denselben Geräten laufen.
Du musst nicht alles auf einmal migrieren.
Sobald eine DDM Software Update Enforcement Declaration aktiv ist, wird sie priorisiert.
Legacy Update Commands werden dann ignoriert – auch wenn sie noch konfiguriert sind.

Schritt 3: Erstes DDM Profil erstellen – Testumgebung (Woche 2–3)

In der Workspace ONE Console navigierst du zu Resources > Profiles > Add Profile > iOS. Jetzt siehst du eine neue Option:

2. Platform: iOS
3. Management Type: Declarative <– neu seit WS1 2406
4. Declaration Type: Configuration

Schritt 4: Testen und Validieren (Woche 3–4)

Beobachte den Status-Channel in WS1 – das ist das neue Herzstück von DDM:

  • Devices > Device Details > [Gerät] > DDM Status
  • Prüfe, ob die Declaration korrekt zugewiesen wurde.
  • Nutzer bekommen jetzt automatisch Benachrichtigungen auf dem Gerät.
  • Validiere das Update nach Enforcement-Datum.

Schritt 5: Rollout auf Produktion (August 2026 – vor iOS 27)

Sobald der Test stabil läuft, rollt ihr die DDM Declarations auf alle iOS-Geräte aus. Folgende Empfehlung für Timing:

Phase Zeitraum Aktion
Vorbereitung Juni 2026 WS1 Version prüfen, Inventarisierung, Test-Declarations erstellen
Pilot Juli 2026 DDM auf 10–20% der Geräte (IT-Team, Power User)
Rollout Welle 1 August 2026 DDM auf 50% der Geräte, Legacy Policies parallel aktiv lassen
Vollständig Vor September 2026 DDM auf 100% der Geräte aktiv
iOS 27 Release September 2026 iOS 27 erscheint – nur DDM Devices bekommen kontrollierten Update-Rollout
Legacy Cleanup Oktober 2026 Alte Legacy Update Policies aus WS1 entfernen

Achtung: TLS-Verschärfung in iOS 27

iOS 27 und macOS 27 erzwingen strengere TLS-Anforderungen für Systemprozesse. Das ist ein separates Thema, aber ein kritisches – insbesondere für On-Premises WS1-Umgebungen mit eigenen PKI-Infrastrukturen:

⚠️ TLS-Kompatibilität prüfen
iOS 27 erzwingt via neuen ProfileAssetReference-Key strengere TLS-Anforderungen.
Betroffen sind Systemprozesse, die HTTPS-Verbindungen zu internen Servern aufbauen.
Prüft eure internen CA-Zertifikate auf SHA-256 Signatur und ausreichende Key-Länge.
Besonders kritisch: On-Premises WS1 mit eigener PKI (z.B. D-Trust, Microsoft CA).
Test-Enrollment mit iOS 27 Developer Beta empfohlen, sobald verfügbar.

Best Practices für deutsche Admins

  1. Migrationszeitpunkt: Nicht bis September warten. Jetzt anfangen.
  2. Test-Gruppe aufbauen: 3–5 Geräte, mindestens iOS 16+, verschiedene Modelle.
  3. Legacy Policies nicht sofort löschen: Koexistenz nutzen, erst nach validiertem DDM-Rollout aufräumen.
  4. Status-Channel auswerten: Das ist euer neues Dashboard für Update-Compliance.
  5. Nutzer-Kommunikation planen: DDM schickt automatisch Benachrichtigungen – stimmt das Timing mit eurer IT-Policy ab.
  6. On-Prem: Seed-Script für neue iOS-Versionen von Omnissa Connect herunterladen (beta-Unterstützung).
  7. TLS-Audit jetzt: Interne CA-Zertifikate auf iOS 27 Kompatibilität prüfen.

Häufige Fehler – und wie ihr sie vermeidet

Fehler Auswirkung Lösung
WS1 Version < 2406 Kein DDM möglich Upgrade auf 2406 oder neuer vor September
Legacy + DDM ohne Priorität beachten Unerwartetes Verhalten DDM Override verstehen: DDM Declaration gewinnt immer
Enforcement Date zu früh gesetzt Nutzer werden überrascht Mindestens 2 Wochen Vorlauf einplanen
TLS-Zertifikate nicht geprüft Enrollment-Fehler nach iOS 27 Upgrade CA-Zertifikate vor Release prüfen
iOS 27 Beta ignoriert Keine Vorwarnung bei Problemen Jetzt Developer Beta testen

Und zur guter letzt nochmal der Hinweis. WS1 On-Prem ist zum 30.04.2027 abgekündigt und EOL! Hier wird Omnissa keine Grace-Periode geben. Somit ist hier Handlungsbedarf, da ich Migration in die SaaS mehrere Wochen benötigt.

BlackBerry UEM Release 12.23 … just a little Watch Back

11. Mai 2026 / / Keine Kommentare

BlackBerry UEM 12.23: Das November-Update im Reality-Check, just a little Watch Back

Heute mal ein kleiner Watch back und ich schaue mir das 12.23 release von BB und Ihrem UEM an. Ich hatte ja in meiner Zeit beim Land, mehr als genug mit BB zutun. Dann kam der wechsel und die letzten 7,5 Jahren, waren mehr WS1 und nachher Intune im UEM & MDM Feld im Fokus. Nun ist es aber auch mal wieder Zeit, sich dem alten Herren in Schwarz zu widmen und auch diesen zu beleuchten.

Es ist November 2026 und UEM 12.23 ist da – und ehrlich gesagt: Das ist kein Release, das große Headlines verdient. Das ist ein solides, pragmatisches Update, das zeigt, wohin BlackBerry UEM wirklich unterwegs ist. Kein Marketing-Blabla, keine zehn neuen Features, die niemand braucht. Stattdessen: Stabilität, Sicherheit, Zertifizierungen.

Wenn eine neue Version im November kommt und die Release Notes nicht vor Features überlaufen, ist das erfrischend ehrlich. BlackBerry hat verstanden: In einem etablierten UEM-System geht es nicht um Raketenfunktionen, sondern um Zuverlässigkeit.

Das Wichtigste in einer Tabelle

Feature / Bereich 12.23 Relevanz Status
Upgrade-Pfade von 12.21, 12.22 Standard ✓ Supported
iOS/iPadOS Tag-Null Support für aktuelle OS Enterprise-Muss ✓ Ready
Android Android Enterprise, Management API Standard ✓ Stabil
Windows 10/11 MDM-Management Enterprise-Standard ✓ Unterstützt
macOS Vollständige Unterstützung BYOD/Enterprise ✓ Stabil
Automatische Backups Setup-Tool integration Betrieb-Critical ✓ Automatisch
Gatekeeping Microsoft 365 Modern Auth Email-Management ✓ Optimiert
BlackBerry Connectivity Node Optional für große Umgebungen Skalierung ✓ Verfügbar

Was sich in 12.23 konkret ändert

Installation und Upgrade

Die Setup-Anwendung erlaubt Installation von UEM 12.23 oder Upgrade von UEM 12.21 oder 12.22. Das ist sauber: Sie sind nicht auf eine Version beschränkt, können aber überspringen sollten Sie noch auf 12.20 sein (das ist dann ein etwas aufwändigeres Upgrade, das ich separat planen würde).

⚠️ Breaking Change Watch: Wenn der Setup-Tool lädt, stoppt und startet er alle UEM-Services automatisch. Das ist normal – aber planen Sie Wartungsfenster. In Produktionsumgebungen machen Sie das am Wochenende oder nachts. Die Datenbank wird automatisch gebackt, aber trotzdem: Backups vor dem Upgrade, auch wenn die Software das macht.

Database-Anforderungen verschärfen sich

BlackBerry UEM Core Server müssen weniger als 5ms Latenz zur Datenbank haben. Das ist nicht neu, aber wird strikte überprüft. Wenn Sie eine Standard-SQL-Server-Installation mit Fernanbindung haben und die Latenz borderline ist – jetzt wird das zum echten Problem. Optimieren Sie vorher.

Sicherheit: JRE 17 ist Pflicht

JRE 17 muss auf dem Computer installiert sein, der UEM hostet. Das ist eine harte Anforderung. Wenn Sie noch auf JRE 11 rumfahren: Das endet jetzt. JRE 17 ist seit November 2023 LTS, also aktuell und stabil.

Plattform-spezifische Neuerungen

iOS & iPadOS

BlackBerry UEM ist eine Multi-Platform-EMM-Lösung, die umfassendes Device-, App- und Content-Management mit integrierter Sicherheit für iOS, macOS, Android und Windows 10 Geräte bereitstellt.

Für iOS-Admin bedeutet 12.23:
– Tag-Null-Kompatibilität mit den neuesten iOS-Versionen (der Standard in jedem BlackBerry-Release)
– Verwaltung von Zertifikaten für Devices und Apps mittels UEM-Profilen und Setup von Work Connections.
– VPN-Profile und PKI sind weiterhin der Standard

Praxis-Tipp: Wer noch auf ältere iOS-Versionen verteilt ist – plant jetzt das Upgrade auf 12.23, damit bei iOS 19 keine Überraschungen kommen.

Android

Keine großen Explosionen hier. OEMConfig-Apps erlauben Administratoren, Device-spezifische Funktionen über App-Konfigurationen zu verwalten, wie für Samsung Knox und andere Hersteller.

Die wichtigsten Unterstützungen:
– Android Enterprise – Standard und stabil
– Android Management API (AMAPI) – für modernere Gerätekontrolle
– Samsung Knox – weiterhin vollständig

Was sich nicht ändert: Das Android-Management in BlackBerry UEM ist pragmatisch, nicht flashy. Policies, Compliance, App-Verwaltung – all bewährte Features.

Windows 10/11

Windows 10 Devices werden als Teil des umfassenden Device-Management unterstützt. Windows 11 auch – obwohl die Docs noch „Windows 10“ sagen, ist das eine dokumentations-Verzögerung.

Für Enterprise-Umgebungen, die Intune für Windows nutzen: BlackBerry UEM can Co-Exist, ist aber eher für spezialisierte Szenarien (alte Geräte, Hybrid-Umgebungen, sehr restrictive Sicherheitsrichtlinien).

Sicherheit und Zertifizierungen – Das Eigentliche Update

Das große News für 12.23 ist nicht in den technischen Features, sondern in der Compliance-Welt: BlackBerry UEM ist das erste UEM-Produkt, das BSI-Zertifizierung erreicht hat und wurde gegen die Common Criteria Standards auf den höchsten Levels validiert.

Was bedeutet das praktisch?

  • Deutsche Regierungsbehörden müssen jetzt nicht mehr auf Ausnahmegenehmigungen kämpfen
  • NATO-Länder, Skandinavien, Frankreich sehen das als Vertrauenszeichen
  • Kritische Infrastruktur (Energie, Telekommunikation, Gesundheit) bekommt ein zusätzliches Zertifikat

Für normale Enterprise-Kunden ist das eher ein Verkaufs-Feature („Ja, sogar die deutsche Bundesregierung vertraut uns“). Aber für hochregulierten Umgebungen: Das ist jetzt ein Kaufargument.

Gatekeeper und Microsoft 365 Authentication

Für Modern Authentication mit Microsoft 365 muss man ein Entra-App hinzufügen und dessen Details bereitstellen – man muss nicht die Anmeldedaten eines M365-Admin-Kontos angeben, sondern nur das Entra Application ID und Organization Values.

Das ist ein echter Fortschritt für größere Orgs:
– Weniger Admin-Accounts mit Super-Privilegien
– OAuth-basiert, nicht mehr nur Legacy-Auth
– Microsoft-Integration wird moderner

Handlungsbedarf: Das musst du vor dem Upgrade wissen

1. Datenbank-Latenz überprüfen – JETZT

Nicht erst im Upgrade. Führe einen Test durch:

ping <deine-db-server>

Wenn die Latenz über 10ms ist, hast du ein Problem. Unter 5ms: Alles gut.

2. JRE 17 im Voraus installieren

Nicht während des Upgrades. Installiere JRE 17 auf dem UEM-Server, teste es, dann erst das Upgrade.

3. Backups – und zwar echte Backups

Die Software macht das automatisch, aber:
– Externe Backups VOR dem Upgrade
– Oder: Snapshot der ganzen VM vor dem Upgrade
– Test-Restore auf einer Testumgebung, falls möglich

4. Notification der Nutzer

Das Upgrade stoppt Services. Mach es nachts oder am Wochenende. User sollten das nicht während der Arbeit erleben.

5. Critical Issue Advisories lesen

Die dokumentierten Critical Issue Advisory Knowledge Base Articles für UEM und Enterprise Mobility Server sollten vor dem Upgrade gelesen werden. BlackBerry publiziert dort wichtige Gotchas.

Marktkontext: Wohin geht BlackBerry UEM?

Seien wir ehrlich: BlackBerry UEM ist eine Nischen-Lösung. Das ist nicht negativ gemeint – es ist realistisch.

  • Große Konzerne mit Sicherheits-Paranoia? → BlackBerry UEM
  • Regierungen, Militär, kritische Infrastruktur? → BlackBerry UEM
  • Mittelständler mit Standard-Anforderungen? → Intune, Jamf, MobileIron

Das Release 12.23 zeigt das deutlich: Keine Konsumenten-Features, keine Mobile-First-Optik. Sondern:
– Stabilität
– Compliance
– Enterprise-Hardening

Die BSI-Zertifizierung ist nicht zufällig: Sie zeigt, dass BlackBerry sich bewusst positioniert – nicht „für jeden“, sondern „für die, die Security ernst nehmen“.

Fazit: Solltest du upgraden?

Ja, aber:

  1. Wenn du aktuell auf 12.21 oder 12.22 bist → Im nächsten Wartungsfenster. Das ist ein normales Stabilitäts-Update.
  2. Wenn du auf 12.20 oder älter bist → Plane einen größeren Upgrade-Prozess. Das ist ein Multi-Version-Jump.
  3. Wenn du von anderer Lösung kommst → 12.23 ist aktuell und stabil. Guter Zeitpunkt für einen New Deployment.
  4. Wenn du in stark regulierter Branche bist → Die BSI-Zertifizierung könnte Compliance-Anforderungen erfüllen, die bisher ein Problem waren.

Was ich nicht empfehle: Hektik. Dieses Release ist nicht „müssen sofort upgraden“. Es ist ein „plane in den nächsten 2-3 Monaten und mach es dann“.

Die Technologie ist reif, die Anforderungen sind klar, die Migration ist standardisiert. Das ist das Gegenteil von hastig.

Die letzte Realität

Nach 16+ Jahren in MDM-Land sag ich dir eins: Die besten Enterprise-Updates sind die, die man kaum merkt. Man startet die Systeme neu, alles läuft wie vorher, die Devices synchronisieren sich, Policies pushen, Compliance wird überwacht.

Das ist 12.23. Genau das.

Ressourcen & Dokumentation

Omnissa Workspace ONE UEM Release 2604

10. Mai 2026 / / Keine Kommentare

Hey Leute,

ich hatte es ja versprochen und nun kommt mein Artikel zum neuen 2604. Geile release Nummer by the Way (kleiner Insider 🤩). Das 2604 Release ist einer der expansivsten der letzten Zeit und baut auf dem Momentum der 2602 auf . Und ehrlich? Das ist die Release, auf die viele von euch gewartet haben. Windows Server endlich im UEM-Universum, macOS-Admins können die Verpackungsorgie lassen, und mit Vulnerability Defense gibt’s jetzt auch nen CrowdStrike-Integration (mir stellen sich die Nackenhaare auf 🤯🤓, aber das ist eher ein persönliches Problem mit CrowdStrike wieder so ein Insider), die tatsächlich Sinn macht.

Ich bin mir aber auch bewusst: Das ist eine Broadcom/KKR-Omnissa, die hier liefert. Die Richtung stimmt, die Features sind solid – aber wir beobachten weiterhin kritisch, wie stabil das bleibt und ob OEMConfig, Rugged und DEX im Fokus bleiben.

Lass mich ein paar Stunden recherchiert haben und dann durch die Features nehmen.

Übersichtstabelle: Features nach Kategorie

Feature Plattform Kategorie Status
Windows Server Management (Enroll 2016+) Windows Server Infrastructure GA
Granular Patch Management Windows Server OS Management GA
Vulnerability Defense (CrowdStrike Integration) Windows Security Limited Availability
Enterprise App Repository (macOS) macOS App Management GA
Platform SSO in Setup Assistant (ADE) macOS, iOS Enrollment Limited Availability
App Preservation during MDM Migration iOS/iPadOS 26+ App Lifecycle GA
Redesigned UEM Console All UI/UX GA
Phased Deployments (Percentage-based) All Deployment GA
Ansible in Custom Config Profiles Linux Configuration GA
Device Update Profile (SUSE Linux) Linux (openSUSE, SLED, SLES) OS Updates GA
Platform-specific ADE Default Profiles iOS, macOS Enrollment GA
Application Removal Protection Improvements iOS App Security GA

Die Top Features im Detail

🖥️ Windows Server Management – Jetzt generell verfügbar (GA)

Das ist die Headline: Windows Server Management ist nun generell verfügbar in Workspace ONE UEM und bringt Server-Infrastruktur in die gleiche Management-Ebene wie der Rest der Endpoint-Flotte .

Konkret:

  • Enroll Windows Server 2016 oder später via Intelligent Hub, und sie tauchen neben deinen Desktops auf mit Server-spezifischen Details wie installierten Rollen und Features
  • Du kannst die Tools nutzen, die du schon kennst: ADMX-Profile mit vorgeladenen Templates, Baselines für automatische Config-Refresh, granulare OS-Patching mit Scheduling, vollständiges App-Lifecycle-Management via Enterprise Application Repository, und Freestyle Orchestrator für Automation
  • Remote Support funktioniert auch: Screen Share, File Access, Command Line – genauso wie bei Desktops

Das ist clever gedacht von Omnissa. Jahrelang haben Server-Teams separate Tools gebraucht. Jetzt ist die Frage: Wie tief geht das? Die ADMX-Integration und das Patching-Handling hören sich solide an. Aber ich warte auf Real-World-Reports zu Skalierungsfragen – einen 5.000er Server-Fleet mit WS1 zu patchen ist nochmal ne andere Hausnummer als Desktops.

Granular Patch Management: Du kannst spezifische Updates aus dem Windows Update Catalog suchen und selektieren, sie auf definierte Server-Gruppen zielen und die Deployment innerhalb deinem Timeframe planen. Du kannst sogar Updates vorab herunterladen, damit die Installation sofort startet, wenn die Zeit kommt .

🔒 Vulnerability Defense + CrowdStrike Falcon – Limited Availability

Workspace ONE Vulnerability Defense tritt in Limited Availability ein und bringt einen kompletten Assessment-to-Remediation-Workflow direkt in die Omnissa Platform für Windows Endpoints. Die Lösung integriert WS1 UEM mit CrowdStrike Falcon Exposure Management, um die Lücke zwischen Vulnerability Management, Exposure Discovery und Remediation zu schließen .

Der Workflow:

  • Wenn ne CVE oder High-Risk-Bedingung identifiziert wird, mapped WS1 UEM das automatisch zu betroffenen Endpoints für schnelle Risk-based Priorisierung
  • Empfohlene Remediation Paths werden direkt in der Admin-Console angezeigt, zusammen mit vorkonfigurierten Updates aus dem Enterprise App Repository. Patches und App-Updates werden über UEM ausgeliefert und IT-Teams können den Remediation-Progress monitoren

Die Integration mit CrowdStrike ist clever – Falcon hat etablierte Visibility, und jetzt hast du direkt im UEM-Portal die Remediation-Automation. Das reduziert Ticket-Ping-Pongs massiv. Aber: Limited Availability heißt, das ist noch nicht für alle da. Warte auf GA, bevor du architektural darauf planst. Und der CrowdStrike-Lizenz-Stack ist nicht zu unterschätzen.

🍎 Enterprise App Repository (macOS) – Jetzt GA

Das war lange überfällig. Workspace ONE UEM launcht die Enterprise App Repository (EAR) für macOS – ein kuratierter Katalog von beliebten Applikationen, der Deployment und laufende Verwaltung streamlined .

Praktisch:

  • Admins können Apps aus dem Repository direkt in der UEM-Console selektieren und sofort in Device-Gruppen deployen – kein manuelles Packaging nötig
  • Updates werden automatisch gehandhabt, und Notifications halten Admins informiert, wenn neue Appversionen verfügbar sind
  • Das App-Repository integriert nativ mit bestehenden UEM Assignment Workflows – Deployment passiert wie mit jeder anderen verwalteten App

Endlich. macOS-Admins hatten bisher ne Lücke: Android und iOS haben ihre App-Kataloge, aber macOS-Packaging war immer ne Sandbox, wo man sich selbst überlassen war. Mit der EAR kriegt ihr da Consistency. Die Frage ist: Wie groß ist der Katalog wirklich? Und können Custom Apps dazukommen? Aber für die Top-Use-Cases (Office, Teams, Browser, Dev-Tools) ist das jetzt ein echter Gewinn.

🔐 Platform SSO beim Setup Assistant (ADE) – Limited Availability

Platform SSO kann jetzt direkt im Setup Assistant während Automated Device Enrollment (ADE) konfiguriert werden. Wenn ein Device ADE durchläuft, authentifizieren sich User mit ihrem Org-Identity-Provider und erstellen ihren ersten Local Account – alles während Initial Setup, bevor das Device übergeben wird. Keine zusätzlichen Schritte, kein separater Profile Push .

Das Resultat ist eine cleanere Onboarding-Experience und eine stärkere Security-Baseline von Tag 1 .

Das ist die richtige Richtung. Zero-Touch Enrollment mit PSSO on Day 0 – das war der USP von großen Apple-Lösungen, und jetzt kann WS1 das auch. Noch im Limited Availability Status, aber sobald das GA ist, sollte das zum Standard gehören für neue Mac-Enrollments.

📱 App Preservation during MDM Migration (iOS 26+)

Workspace ONE UEM führt granulare App Preservation während MDM Migration für iOS/iPadOS 26+ Devices ein .

Das Szenario: Du migrierst eine Flotte von nem anderen MDM zu WS1? Früher wurden die Apps gelöscht und neuinstalliert – Friction für User, Komplexität für IT. Jetzt können Apps erhalten bleiben.

Praktisch für größere Migrations-Szenarien. Aber iOS 26+ ist ne spezifische Anforderung – für ältere Devices musst du weiterhin mit App-Reinstall rechnen.

🖼️ Redesigned UEM Console – Now GA

Die neu designte WS1 UEM Admin-Console ist jetzt generell verfügbar. Sie ist auf einem modernisiertem Tech-Stack gebaut, geprägt von iterativem User Research und Testing. Die neue Experience reorganisiert Navigation in logischere Kategorien, stellt die meistgenutzten Features in den Vordergrund, und ersetzt Labels, die Institutional Knowledge brauchten, durch Sprache, die sofort klar ist .

UI-Überarbeitungen sind immer zweischneidig. Manche Admins haben Jahrzehnte in der alten Console gelebt. Aber wenn das Research-driven ist und auf Usability-Testing basiert, sollte das okay sein. Wird schnell klar, ob das wirklich besser ist oder nur anders. Ich bin gespannt drauf.

📊 Phased Deployments mit Percentage-based Rollout – GA

Phased Deployments sind jetzt GA, und diese Release fügt ne neue Capability hinzu: Admins können jede Phase jetzt nach Prozentanteil der Zielgruppe definieren, statt Gruppen explizit zu spezifizieren .

Praktisch: „Rollout an 10% → 25% → 50% → 100%“ ohne dass du Gruppen manuell aufteilen musst.

Das ist ein DLP-Playing-Field. Apple hat das via MDM-Restrictions seit Jahren, Microsoft Intune auch. Jetzt kann WS1 auch prozentual rollout – das ist gut.

🐧 Ansible in Linux Custom Config Profiles + SUSE Update Management

Zwei Linux-Highlights:

  1. Ansible Support: Enterprise Linux Environments vertrauen oft auf Ansible für Configuration Management. In 2604 bringt WS1 UEM diese Capability direkt ins Custom Configuration Profile. Ansible ist jetzt neben Bash, Python und Puppet als unterstützter Payload-Type verfügbar. Admins können Ansible Playbooks nutzen, um enrolled Linux Devices zu konfigurieren, mit Support für Ansible Collections und Roles .
  2. Device Update Profile für SUSE: Das Device Update Profile erweitert sich auf SUSE-basierte Linux Devices (openSUSE, SLED, SLES). Admins können das Level und die Frequenz von automatischen Updates konfigurieren, Security- und Policy-spezifische Update Rules, und Notifications für neue Major OS Versions .

Das ist solider Enterprise-Linux-Support. Ansible ist das Orchestration-Tool, und wenn WS1 das nativ unterstützt, brauchst du weniger Custom Integrations. Für SUSE-Shops ist das dann ne große Erleichterung.

🔧 Platform-specific ADE Default Profiles (iOS & macOS)

Ein Clarity-Feature: Admins können jetzt platform-spezifische Default ADE Profiles assignen. iOS und macOS können unterschiedliche On-Boarding-Profile haben, ohne dass man überall Conditional Logic bauen muss.

⚠️ Handlungsbedarfe & Deprecations

Vulnerability Defense: Limited Availability Status

Vulnerability Defense ist noch nicht GA. Wenn du das architekturiert, solltest du mit dem Omnissa-Account-Team aligned sein. Das kann sich bis GA noch verschieben.

CrowdStrike-Lizenzierung

Wenn du Vulnerability Defense einführen willst, brauchst du nicht nur WS1 UEM, sondern auch CrowdStrike Falcon Exposure Management. Das ist ein separater Lizenzstack – kalkuliere das mit in deine TCO.

Windows Server 2016+ Requirement

Windows Server Management funktioniert nur ab 2016. Wenn du ältere Server-Flotten hast (2012 R2, 2008 R2), brauchst du weiterhin separate Tools.

iOS 26+ für App Preservation

App Preservation during Migration funktioniert nur auf iOS/iPadOS 26+. Ältere Devices haben weiterhin App-Wipe während Migration.

Vergleich zu Microsoft Intune: Wo WS1 Vorteile hat

Der 2604 Release ist eines der expansivsten in letzter Zeit und baut auf 2602-Momentum auf . Wenn du Intune mit WS1 vergleichst:

Feature Workspace ONE UEM 2604 Microsoft Intune
Windows Server Management ✅ Jetzt GA ❌ Nicht native
macOS Enterprise App Repository ✅ GA (curated) ⚠️ Basic app store integration
Rugged Device Support ✅ OEMConfig first ❌ Limited
Linux Management ✅ Ansible

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.

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

7. März 2026 / / Keine Kommentare

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

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

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

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

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

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

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

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

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

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

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

Was ist der Modern Stack?

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

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

Was passiert nach dem 30. April 2027?

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

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

Die Optionen: Wohin können Kunden migrieren?

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

Option 1: Shared SaaS

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

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

Option 2: Preferred SaaS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Was für Omnissa spricht

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

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

Was mich besorgt – und das ist mehr

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

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

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

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

Ist es das Todesurteil für WS1?

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

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

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

Was sollten Kunden und Berater jetzt tun?

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

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

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

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

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

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