Schlagwort: Omnissa

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

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

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

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

Was ist ModStack? Der Umbau plausibel erklärt

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

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

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

Warum macht Omnissa das?

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

Was ModStack an Features bringt – heute und morgen

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

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

Auf ModStack gebaut: die Feature-Welle 2602/2604

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

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

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

On-Premises: Endstation 2410 – die Fakten zur Deadline

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

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

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

Die drei Migrationspfade

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

Fazit

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

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

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

Das Fehlerbild

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

Fehler

Die Registrierung konnte nicht abgeschlossen werden.

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

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

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

Was nicht geholfen hat

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

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

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

Die Ursache: Die Keychain aus dem Backup

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

Verschlüsselte lokale Backups sichern die komplette Keychain

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

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

Warum Hub löschen und neu installieren nichts bringt

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

Warum das MDM trotzdem funktioniert

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

Info

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

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

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

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

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

Achtung

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

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

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

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

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

Der richtige Workflow für die Zukunft

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

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

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

Fazit

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

 

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

Was ist der Modern Stack?

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

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

Was passiert nach dem 30. April 2027?

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

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

Die Optionen: Wohin können Kunden migrieren?

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

Option 1: Shared SaaS

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

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

Option 2: Preferred SaaS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Was für Omnissa spricht

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

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

Was mich besorgt – und das ist mehr

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

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

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

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

Ist es das Todesurteil für WS1?

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

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

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

Was sollten Kunden und Berater jetzt tun?

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

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

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

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

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

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

Workspace ONE UEM 2602: Ein ehrlicher Überblick zum großen Release

 

Workspace ONE UEM 2602: Ein ehrlicher Überblick zum großen Release

Die 2602er ist eine dieser Releases, bei denen Omnissa sein Selbstvertrauen zeigt – und das ist nicht ganz unbegründet (jeder von uns kennt sehr wahrscheinlich die Probleme der letzten Updates, welche immer so naja liefen Nicht amüsiert ). Mit dieser Version liefern sie eines ihrer ambitioniertesten Updates: vollständig aufgefrischte Admin Experience, innovative Android- und Apple-Management-Fähigkeiten, Game-Changing Windows Management und intelligentere Automation überall.

Lass mich die wichtigsten Punkte durchlaufen.


Feature-Übersichtstabelle: 2602 auf einen Blick

Feature Plattform Kategorie Status
Modernisierte Admin Console Cross-Plattform UI/UX Limited Availability
Phased App Deployments Cross-Plattform Automation GA
Advanced eSIM Management Android Connectivity GA
Erweiterte AMAPI-Policies Android Enterprise Control GA
Account-Driven Enrollment (vereinfacht) iOS/macOS Enrollment GA
Dynamic Mac Hardware Seeding macOS Automation GA
Intelligente Enrollment-Labels iOS/macOS Grouping GA
Intelligent Hub Managed Enrollment Windows Enrollment GA
Enterprise App Repository v2 (EARv2) Windows App Distribution GA
Automatisierte Windows App-Patching Windows App Management GA
Windows Agent Updates Dashboard Windows Visibility GA
Dropship Provisioning Bulk Import Windows Provisioning GA
Intel Chip-to-Cloud Logging Windows Troubleshooting GA
Granular App Retention Control Windows App Lifecycle GA
ADMX Profiles (Windows Server Preview) Windows Server Policy Limited Availability

Die wichtigsten Features im Detail

1. Modernisierte Admin Console – Limited Availability, aber vielversprechend

Omnissa kündigt eine modernisierte Konsole mit intuitiver Navigation, neu gestalteter Device List View und intelligenteren Workflows an, die Klicks reduzieren. Admins können sich schrittweise anmelden und jederzeit zurückwechseln.

Meine Analyse: Das ist nicht einfach eine Kosmetik-Operation. Eine frische Konsolen-UI ist bei MDM-Plattformen überraschend kritisch – die Funktion befindet sich derzeit in Limited Availability , also nicht hastig upgraden. Die Opt-in-Strategie ist smart: Admins können taste, backup-Plan bei Bedarf. Das respektiere ich.

2. Android: eSIM Management & erweiterte AMAPI-Policies

Workspace ONE UEM bietet jetzt fortgeschrittenes eSIM-Management für Android, mit dem IT-Teams die Geräteverbindung optimieren. Administratoren können eSIM-Profile remote bereitstellen, aktivieren, überwachen und entfernen – über die UEM Console oder REST API.

Zusätzlich: Workspace ONE weitet Android AMAPI-Unterstützung mit neuen Policies aus, die granulare Kontrolle über Bildschirmverhalten, Private Space und Google Play Protect bieten.

Praktische Bedeutung: Das ist ein echter Differentiator. eSIM ist nicht sexy, aber für GlobalPlayer mit großen Android-Flotten (Logistics, Telco) = essentiell. Die Private Space Policies sind auch clever – das passt zu Googles Android 15+ Richtung.

3. Apple: Enrollment vereinfacht, Automation kommt

Das Release vereinfacht zwei kritische Apple-Szenarien:

Account-Driven Enrollment (ADE):
Das Release vereinfacht Account-Driven Enrollments erheblich. Früher erforderte die Erstellung einer well-known-Datei manuelle Schritte und externes Hosting. Jetzt aktivieren Admins das Feature, und WS1 generiert die JSON-Datei automatisch via Apple Business Manager.

Mac Hardware Seeding:
Mac-Modell-Hardware-Seeding ist jetzt automatisiert. Mit automatisch erfassten und befüllten Mac-Modelldaten können Admins Smart Groups nutzen – mit Same-Day Support für neue Apple Hardware.

Kritisches Take: Das ist Micro-Automation, aber die Art, die deinen Alltag vereinfacht. Weniger manuelle Datei-Hosting-Fricktion = weniger Fehler = happier Admins. 👍

4. Windows: Das Game-Changer-Release (25+ Features!)

Das ist das Herzstück von 2602. Mit Next-Gen Windows Management in 2602 redefine Omnissa modernes Windows-Management – von Intelligent Hub managed mode über stärkere Desired-State-Controls bis zur verbesserten Enterprise App Repository.

Intelligent Hub Managed Enrollment:
Neue Enrollment-Option namens „Intelligent Hub Managed“ – als Übergangsmechanismus vom alten OMA-DM-Anbieter. Volle Intelligent Hub-Power, aber mit mehr Flexibilität.

Enterprise Application Repository v2 (EARv2):
Ihr könnt jetzt über 8.500 Enterprise-Apps browsen, konfigurieren und an Windows-Geräte pushen – direkt aus WS1 UEM. Noch besser: WS1 kann über 8.500 Apps automatisch patchen. Ihr konfiguriert den Plan einmal – WS1 kümmert sich um den Rest, Apps bleiben aktuell ohne manuelle Intervention.

Unified Application Sampling:
Besseres App-Reporting mit konsistenten Daten. Mit dem neuen Sampling-Framework werden App-Daten einheitlich über Intelligent Hub, UEM und DEX/DEEM erfasst.

Windows Agent Updates Dashboard:
Neues Dashboard für Echtzeit-Sichtbarkeit aller Intelligent Hub & SFD Agentversionen. Zwischen Agenten wechseln, Charts ansehen, zu Device-Listen drilldown – alles from one dashboard.

Intel Chip-to-Cloud Logging:
C2C-Events sind jetzt in dedizierter Log-Datei, ohne unrelated data. AMT-Interface-Aktivierung & Checking verbessert.

Granular App Retention:
Admins steuern jetzt, ob Apps beim Device-Wipe oder App-Unassign entfernt oder behalten werden.

Dropship Provisioning:
Bulk-Import von Geräte-Records – egal ob 1 oder 100 Devices auf einmal.

Meine Analyse: Das ist substantiell. 25+ Windows-Features sind nicht gequetscht, sondern strategisch: DeviceList-Visibility (Admin), App-Automation (Speed), Troubleshooting-Verbesserungen (Ops). EARv2 mit Automatic Patching ist besonders nice – Zero-Touch Patching für 8.500 Apps reduziert MSP-Intervention massiv.

⚠️ Warnung: Windows Server Management ist noch Limited Availability. Wenn ihr auf WS1 für Server-Flotten setzt – noch ein paar Releases warten.


Automation & Workflows: Smarter, nicht komplexer

Mit Phased Deployments könnt ihr Apps schrittweise ausrollen – mit kleiner Gruppe starten, Probleme früh catch, Rest der Fleet schützen. Ziel exakte Assignment Groups in jeder Phase, automatische oder manuelle Phase-Progression, Clear Phase-Level Insights.

Das ist LowCode-Orchestration im Best-Sense: nicht Freestyle, aber simpler als vor 2602.


Handlungsbedarfe & Deprecations: Was ist zu beachten?

⚠️ Console Modernization = Limited Availability

Die neue Admin Console ist noch nicht GA. Testet in Lab/Non-Prod, bevor ihr großflächig rolled. Die Opt-in Strategy ist gut, aber seids vorsichtig mit Critical Workflows.

⚠️ Windows Server = Not Yet Production-Ready

Windows Server Management ist derzeit in Limited Availability mit General Availability demnächst . Wenn ihr Windows Server managed, wartet noch.

⚠️ Apple Migration ohne App Preservation (noch)

WS1 UEM unterstützt derzeit keine App Preservation während Migration. Ihr müsst Apps vorab in WS1 aufsetzen. An diesem Feature wird gearbeitet.

⚠️ Legacy App Catalog Sunset: 30. April 2025

Wechselt zur neuen Enterprise App Repository – Legacy-Path wird deprecated.


Kurzer Vergleich zu Microsoft Intune

Ja, die Frage kommt. Hier meine ehrliche Sicht:

Wo WS1 2602 Intune schlägt:
Cross-Device Management: Windows + Mac + Android + rugged aus einer Konsole. Intune braucht mehr Basteln.
eSIM Management: Noch nicht in Intune, WS1 has it. Nice-Feature, aber strategisch.
ADMX Profiles (kommend): Familiarität für Group Policy Admins.
Enterprise App Repo (8.500+ Apps): Intune’s Win32 App Management ist granular, aber anstrengender.

Wo Intune Punkte macht:
Microsoft Ecosystem Integration: Wenn ihr 100% Microsoft-Stack seid, Intune ist built-in.
Conditional Access: WS1 ist gut, Intune’s AAD-Integration tighter.
Community & Adoption: Intune-Adoption ist bei SMB größer (aktuell).

Fazit: 2602 macht WS1 für gemischte Umgebungen (Apple + Android + Windows + Rugged) attraktiver. Für rein Microsoft-Shops bleibt Intune einfacher. Für Enterprise Complexity: WS1.


Quellen & offizielle Dokumentation