Schlagwort: MDM

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

4. März 2026 / / Keine Kommentare

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

Manchmal sind es die kleinen Änderungen, die im Alltag den größten Unterschied machen. Microsoft hat mit dem Intune Februar-Release (2602) zwei neue RBAC-Permissions für den Managed Home Screen eingeführt:

TemporarilySuspendManagedHomeScreen | RestoreManagedHomeScreen

Klingt erstmal technisch und unspektakulär. Ist es aber nicht. Wer schon mal versucht hat, einen Android-Kiosk in einer Schule oder im Frontline-Worker-Umfeld zu supporten, ohne lokalen Admin-Zugriff aufs Gerät zu haben, wird beim Lesen dieser Zeilen vielleicht kurz aufatmen. Warum? Das erkläre ich hier.

Kurzer Auffrischungskurs: Was ist eigentlich der Managed Home Screen?

Für alle die noch nicht täglich mit Android-Enterprise-Deployments zu tun haben: Der Microsoft Managed Home Screen (kurz MHS) ist eine App aus dem Managed Google Play Store, die Microsoft Intune als Standard-Launcher für Android-Kiosk-Geräte verwendet.

Das bedeutet konkret: Statt dem normalen Android-Homescreen sieht der Nutzer nur das, was der Admin ihm erlaubt. Welche Apps, welche Einstellungen, welche Widgets – alles zentral gesteuert. MHS läuft dabei typischerweise auf:

  • Android Enterprise Dedicated Devices (Corporate-owned, kein User-Account) – klassisch für Kiosk, Shared Devices, Info-Terminals
  • Fully Managed Devices (Corporate-owned, user-affiliated) – z.B. Frontline Worker, Schüler-Tablets, Lagermitarbeiter

Der Vorteil ist klar: Kein Nutzer kommt aus dem Kiosk raus, installiert irgendwas, oder ändert die WLAN-Einstellungen. Das Gerät macht was es soll – und sonst nichts.

ℹ️ MHS in Kürze: Intune-verwalteter Android-Launcher | Kiosk-Modus für Dedicated & Fully Managed Devices | Konfigurierbar via App Configuration Policies oder Device Configuration Profiles | Unterstützt Android Enterprise ab OS 8.0 | Beliebt in Schulen, Logistik, Healthcare und Retail

Das Problem: Kiosk ist super – bis jemand Support braucht

Kiosk-Geräte sind im laufenden Betrieb wunderbar. Aber dann kommt der Moment, wo etwas nicht funktioniert. Eine App hängt sich auf, eine Policy greift nicht, das Gerät braucht ein Update das sich im Lock-Down nicht automatisch installiert. Oder – klassischer Schulkontext – ein Schüler hat irgendwas Kreatives angestellt und das Gerät verhält sich komisch.

Vor den neuen Permissions war die Situation für Help Desk Operators und Schuladmins in solchen Momenten nicht schön. Um aus dem MHS-Kiosk rauszukommen und auf die normale Android-Oberfläche zugreifen zu können, gab es im Wesentlichen drei Wege:

  • Den Kiosk-Exit-PIN verwenden – sofern konfiguriert und dem Supporter bekannt
  • Den Debug-Modus über das 15-malige Zurück-Drücken aktivieren – undurchsichtig, nutzerfeindlich, nicht skalierbar
  • Einen vollwertigen Intune-Admin einschalten – weil nur der die nötigen Berechtigungen hatte

Für große Organisationen mit vielen Geräten und einem gestaffelten Support-Modell (Tier 1 / Tier 2 / Tier 3) ist das ein echtes Problem. Ein Help Desk Operator der in einer Schule 300 iPads und 200 Android-Kiosks supportet, braucht operative Handlungsfähigkeit – ohne dass man ihm gleich globale Admin-Rechte geben will. Genau hier setzen die neuen Permissions an.

Die zwei neuen RBAC-Permissions im Detail

TemporarilySuspendManagedHomeScreen – Kiosk kurz auf Pause

Mit dieser Permission kann ein berechtigter Admin den Managed Home Screen vorübergehend aussetzen. Das Gerät verlässt damit den Kiosk-Modus und gibt temporär Zugriff auf die normale Android-Oberfläche – ohne dass der Kiosk dauerhaft deaktiviert wird oder irgendwas an der Konfiguration geändert werden muss.

Was das in der Praxis bedeutet: Der Help Desk kann aus der Ferne – oder direkt am Gerät via Intune Remote Action – den Kiosk kurz „parken“, das Problem lösen (App-Cache leeren, Update erzwingen, Einstellungen prüfen), und danach den MHS-Kiosk wieder aktivieren. Sauber, kontrolliert, ohne Admin-Eskalation.

💡 Praxisbeispiel Schule: Schüler-Tablet in Klasse 7b verhält sich komisch – App startet nicht, Lehrer ruft Support. Help Desk Operator suspendiert remote den MHS, sieht auf die vollständige Android-Oberfläche, stellt das Problem fest (abgelaufene App-Version), triggert ein Sync, aktiviert MHS wieder. Dauer: 5 Minuten. Ohne diese Permission: IT-Admin-Eskalation, Ticket-Ping-Pong, ggf. Gerät einschicken.

RestoreManagedHomeScreen – zurück in den Kiosk

Das ist die Gegenseite. Nachdem der MHS temporär suspendiert wurde, stellt diese Permission sicher, dass der Help Desk Operator den Kiosk-Modus wieder aktivieren kann – ohne auf einen vollständigen Intune-Admin angewiesen zu sein.

Das ist wichtiger als es klingt. Ein Suspend ohne kontrollierten Restore ist in einer Kiosk-Umgebung ein Sicherheitsrisiko. Ein Gerät das „aus Versehen“ dauerhaft aus dem Kiosk ist, ist im Schulkontext oder im Retail-Einsatz schnell ein Problem. Mit RestoreManagedHomeScreen hat der Help Desk die volle Kontrolle über den gesamten Suspend/Restore-Zyklus.

ℹ️ Wichtig: Die beiden Permissions sind als Paar gedacht. TemporarilySuspend ohne Restore ergibt keinen sicheren Support-Workflow. Microsoft hat sie deshalb auch gemeinsam in die Built-in-Rollen aufgenommen.

Wer bekommt die neuen Permissions – und warum genau diese Rollen?

Microsoft hat die beiden Permissions mit dem Februar-Release (2602) automatisch in zwei bestehende Built-in-Rollen integriert:

RBAC-Rolle Bisherige Kernaufgaben Neu hinzukommend
Help Desk Operator Remote-Tasks (Wipe, Lock, Retire), App/Policy-Zuweisung, User-Support TemporarilySuspend + RestoreManagedHomeScreen
School Administrator Apps & Settings für Gruppen, Remote-Lock/Restart/Retire, Intune for Education TemporarilySuspend + RestoreManagedHomeScreen

Die Wahl dieser beiden Rollen ist nicht zufällig. Der Help Desk Operator ist die typische Tier-1-bis-Tier-2-Support-Rolle in Unternehmen mit MHS-Deployments – Retail, Logistik, Healthcare, Frontline Worker. Und der School Administrator ist die dedizierte Rolle für Intune for Education-Umgebungen, wo Kiosk-Tablets und Shared Devices allgegenwärtig sind.

Beide Rollen haben gemeinsam, dass sie operativ nah an den Geräten dran sind – aber eben nicht die volle Intune-Admin-Power haben sollen. Genau deshalb macht es Sinn, ihnen die MHS-Suspend/Restore-Kontrolle zu geben: genug Handlungsspielraum für den Daily Support, ohne sicherheitskritische Berechtigungen wie Policy-Erstellung oder Enrollment-Management zu öffnen.

Kurzer RBAC-Exkurs: Warum das Prinzip so wichtig ist

Role-Based Access Control (RBAC) ist in Intune das zentrale Berechtigungsmodell. Statt jedem Admin die gleichen Rechte zu geben, definiert man Rollen mit klar begrenzten Berechtigungen – und weist diese Rollen dann an spezifische Personen oder Gruppen zu. Das Prinzip dahinter: Least Privilege – jeder bekommt genau die Rechte, die er für seine Aufgabe braucht. Nicht mehr, nicht weniger.

Microsoft empfiehlt ausdrücklich, für den täglichen Betrieb auf Built-in-Rollen zu setzen und Microsoft Entra ID-Rollen (die oft zu viel Zugriff haben) nicht als Standard-Admin-Rollen zu verwenden. Die neuen MHS-Permissions sind ein gutes Beispiel für diese Philosophie in der Praxis: Eine Aufgabe (Kiosk suspendieren) bekommt eine dedizierte Permission, die gezielt an die richtigen Rollen vergeben werden kann.

RBAC-Konzept Bedeutung für MHS-Deployments
Least Privilege Help Desk kann Kiosk managen ohne globale Admin-Rechte
Built-in Roles School Admin + Help Desk Operator bekommen die Permissions automatisch
Custom Roles Granulare Vergabe möglich: z.B. nur RestoreManagedHomeScreen ohne Suspend
Scope Tags Permissions können auf bestimmte Gerätegruppen oder Standorte begrenzt werden

Für Organisationen die Custom RBAC-Rollen nutzen: Die neuen Permissions können auch gezielt einzeln vergeben werden. Wer zum Beispiel einen noch engeren Tier-1-Support nur mit Restore-Recht ausstatten will (um zu verhindern dass jemand den Kiosk unberechtigt suspendiert), kann das über eine Custom Role abbilden.

Wie funktioniert das technisch – was passiert beim Suspend?

Wenn TemporarilySuspendManagedHomeScreen ausgelöst wird, passiert folgendes auf dem Gerät:

  • Der Managed Home Screen-Launcher gibt die Steuerung temporär ab
  • Das Android-System zeigt wieder den Standard-Launcher (oder einen anderen konfigurierten Launcher)
  • Der Nutzer/Admin hat Zugriff auf die vollständige Android-Oberfläche, System-Settings und alle installierten Apps
  • Die MHS-Konfiguration, Policies und App-Zuweisungen bleiben dabei vollständig erhalten – es wird nichts gelöscht oder geändert
  • Per RestoreManagedHomeScreen wird MHS wieder als aktiver Launcher gesetzt – der Kiosk-Modus ist sofort wiederhergestellt

Das ist der entscheidende Unterschied zur bisherigen „Exit Kiosk Mode“-Funktionalität über das Debug-Menü: Die neuen Permissions erlauben eine saubere, remote-auslösbare, auditierbare Aktion – keine Workarounds, kein manuelles Rumdrücken am Gerät, keine PIN-Weitergabe.

⚠️ Zu beachten: Die Suspend-Aktion gibt dem Nutzer temporär Vollzugriff auf das Android-System. In sensiblen Umgebungen (z.B. Healthcare, KRITIS) sollte der Suspend-Workflow dokumentiert und per Scope Tags auf berechtigte Admins begrenzt sein. Ein unbeaufsichtigtes Gerät im Suspend-Zustand ist de facto aus dem Kiosk – das sollte nicht dauerhafter Zustand sein.

Die konkreten Vorteile für den Admin-Alltag

1. Eskalationen werden seltener

Der häufigste Support-Aufwand bei MHS-Deployments ist die Kiosk-Intervention: Gerät hängt, App macht nicht mit, Update ist blockiert. Bisher musste in vielen Szenarien ein Intune-Admin eingreifen. Mit den neuen Permissions kann der Help Desk das selbst lösen – weniger Tickets, kürzere Lösungszeiten, weniger frustrierte Lehrer oder Schichtleiter.

2. Kein PIN-Sharing mehr

Die bisherige „Exit Kiosk“-Methode via Kiosk-PIN war ein Sicherheitsproblem in der Praxis: Entweder kannte der Help Desk den PIN nicht, oder er wurde geteilt und damit zum Sicherheitsrisiko. Mit den RBAC-Permissions ist das obsolet. Kein Pin-Sharing, kein Post-it an der Unterseite des Tablets. Die Aktion ist an die Rolle gebunden, nicht an ein Shared Secret.

3. Vollständige Auditierbarkeit

RBAC-Aktionen in Intune werden geloggt. Wer den MHS suspendiert hat, wann, auf welchem Gerät – das ist alles in den Intune-Audit-Logs nachvollziehbar. Für Compliance-Reports, ISO-Zertifizierungen oder einfach nur für den internen Überblick ist das ein echter Mehrwert gegenüber dem bisherigen PIN-basierten Zugang.

4. Kein Sicherheits-Downgrade nötig

Bisher war die pragmatische Lösung in manchen Organisationen: Help-Desk-Mitarbeitern mehr Intune-Rechte geben als eigentlich nötig, damit sie Kiosk-Probleme lösen können. Das ist klassisches Permission Creep – und ein Risiko. Die neuen granularen Permissions erlauben es, genau das zu vermeiden: Der Help Desk Operator bekommt MHS-Suspend-Rechte, aber eben keine Policy-Erstellungs- oder Enrollment-Rechte.

5. Perfekt für Schul- und Frontline-Umgebungen

Genau die Szenarien wo MHS am meisten eingesetzt wird – Schulen, Retail, Logistik, Healthcare – sind auch die Szenarien mit dem höchsten Support-Aufkommen und dem geringsten Admin-Personal vor Ort. Ein Schulleiter oder Schichtverantwortlicher mit Help-Desk-Operator-Rolle kann jetzt selbst eingreifen, ohne auf den zentralen IT-Admin warten zu müssen. Das ist in der Praxis ein erheblicher Effizienzgewinn.

Was müssen Admins jetzt tun?

Microsoft hat das klar kommuniziert: Es ist keine Admin-Aktion erforderlich. Die Permissions werden automatisch den Built-in-Rollen hinzugefügt. Aber „kein Handlungsbedarf“ heißt nicht „kein Nachdenken erforderlich“. Hier die Empfehlungen:

  • Rolle-Assignments reviewen: Wer hat bei euch die School Administrator- oder Help Desk Operator-Rolle zugewiesen bekommen? Diese Personen bekommen die neuen Permissions automatisch. Ist das in allen Fällen gewollt?
  • Dokumentation aktualisieren: Wenn ihr interne IT-Handbücher, Schulungsunterlagen oder SOPs für den Kiosk-Support habt, müssen diese aktualisiert werden. Der neue Workflow via Suspend/Restore sollte dokumentiert und kommuniziert sein.
  • Custom Roles prüfen: Wer Custom RBAC-Rollen nutzt, kann die neuen Permissions manuell hinzufügen – oder bewusst weglassen, wenn der engste Least-Privilege-Ansatz gewünscht ist.
  • Scope Tags einsetzen: Besonders in großen Organisationen mit verteilten Standorten: Scope Tags sicherstellen, dass Help Desk Operators nur die Geräte suspendieren können, für die sie auch zuständig sind.
  • Auslöser in Intune kennenlernen: Die Aktion wird in der Intune Admin Console als Remote Action auf dem Gerät auslösbar sein – ähnlich wie Remote Lock oder Sync. Den genauen Workflow für das eigene Team einmal durchspielen bevor es der erste echte Support-Fall erfordert.

Fazit: Klein, aber fein – und überfällig

TemporarilySuspendManagedHomeScreen und RestoreManagedHomeScreen sind keine Features die auf Konferenzen mit großem Tamtam vorgestellt werden. Aber für jeden der täglich MHS-Deployments in Schulen, im Frontline-Worker-Umfeld oder im Kiosk-Betrieb supporten muss, sind sie ein echter Lebensverbesserer.

Das Prinzip dahinter ist einfach und richtig: Wer Support machen darf, soll auch die Werkzeuge haben, um guten Support machen zu können – ohne dafür einen sicherheitskritischen Permission-Overhead zu bekommen. Granulares RBAC ist genau dafür gemacht. Und Microsoft setzt das hier konsequent um.

Wer schon MHS im Einsatz hat: Jetzt ist ein guter Zeitpunkt, die Role Assignments zu reviewen und den Suspend/Restore-Workflow in den internen Support-Prozess aufzunehmen. Und wer noch überlegt, MHS für ein Kiosk-Deployment einzusetzen: Diese Verbesserung macht es noch attraktiver – gerade wenn kein dediziertes Vor-Ort-Admin-Team zur Verfügung steht.

💡 Mein Fazit: Kleine Permissions, große Wirkung. Wer 100+ Kiosk-Geräte ohne dediziertes Admin-Team vor Ort supportet, wird diese Änderung lieben. Der Help Desk kann jetzt genau das tun, wofür er da ist – Probleme lösen – ohne bei jedem Kiosk-Issue einen Global Admin klingeln zu müssen.

🔗 Quellen & weiterführende Links:

• M365 Admin – Originalmeldung MC1213781: m365admin.handsontek.net

• Microsoft Learn – Configure Managed Home Screen App: learn.microsoft.com/intune/apps/app-configuration-managed-home-screen-app

• Microsoft Learn – RBAC with Microsoft Intune: learn.microsoft.com/intune/fundamentals/role-based-access-control

• Microsoft Tech Community – MHS Setup Guide (Kiosk Mode): techcommunity.microsoft.com

• Systunation – The Incredible Managed Home Screen: systunation.com/the-incredible-managed-home-screen-mhs-of-intune

Workspace ONE vs. Microsoft Intune: Mein ehrlicher MDM-Vergleich nach 16+ Jahren im Feld

1. März 2026 / / Keine Kommentare

Workspace ONE vs. Microsoft Intune: Mein ehrlicher MDM-Vergleich nach 16+ Jahren im Feld

Also, lasst mich direkt loslegen – kein Blabla vorneweg. Ich bin seit 26 Jahren in der IT, die letzten 16+ davon speziell im Mobile Device Management. iOS, Android und in den letzten 7 Jahren dazu noch der Fokus auf Zebra-Rugged-Devices, Honeywell MDE. Dabei hab‘ ich schon so ziemlich alles gesehen, was die Branche zu bieten hat. Und die beiden Systeme, die mich dabei am längsten begleiten: VMware Workspace ONE (WS1) und Microsoft Intune. Beide stark. Beide mit Ecken und Kanten. Und beide für bestimmte Szenarien einfach die richtige Wahl.

In diesem Post zeige ich euch keinen Marketing-Vergleich, sondern meinen ehrlichen Blick aus dem Admin-Alltag. Kein Sieger, kein Verlierer – nur Fakten, Erfahrungen und ein bisschen Meinung. Los geht’s!

Ein kurzer Blick zurück: Wie haben sich WS1 und Intune entwickelt?

Wer lange genug dabei ist, erinnert sich noch an AirWatch. Damals – so ab 2012/2013 – war das die Referenz im MDM-Markt. VMware hat AirWatch 2014 übernommen und daraus Workspace ONE gemacht, ein vollintegriertes Digital Workspace-Ökosystem. Der Ansatz: Ein Ökosystem für alles – MDM, Identity, App-Management, Conditional Access. Klingt gut, und ist es auch – wenn man bereit ist, etwas Zeit zu investieren.

Microsoft Intune startete ungefähr zur gleichen Zeit als eher schlichter MDM-Dienst in der Azure-Cloud. Lange Zeit war es ehrlich gesagt… okay-ish. Aber mit der Einführung von Microsoft Endpoint Manager (MEM) und der späteren Umbenennung und Neuausrichtung als Intune innerhalb des Microsoft 365-Ökosystems hat sich das massiv verändert. Heute ist Intune ein ernstzunehmender Konkurrent – gerade wenn man sowieso tief im Microsoft-Stack steckt.

iOS-Management: Wer macht’s besser?

Workspace ONE

WS1 und iOS – das war lange die Traumehe im Enterprise-Umfeld. Supervised Mode, Apple Business Manager Integration, Custom Payloads, granulare Richtlinien für jede erdenkliche Einstellung: Workspace ONE hat hier jahrelang die Benchmark gesetzt. Besonders bei komplexen Enrollment-Szenarien (Zero-Touch via DEP, Shared Device Mode, etc.) ist WS1 stark.

Was ich persönlich schätze: Die Flexibilität bei Custom Profiles. Wenn Apple mal wieder eine Einstellung nicht offiziell im MDM-Standard freigibt, kann man mit WS1 via Custom XML Payload trotzdem rankommen. Das ist für erfahrene Admins Gold wert.

Zusätzlich ist der Workspace ONE Intelligent Hub unter iOS die Steuerzentrale & bietet dem Anwender über die Umsetzung der Policy, Verteilung der Apps bis hin zu Pushnachrichten, alles was benötigt wird.

Microsoft Intune

Intune hat in den letzten Jahren enorm aufgeholt. ADE (Automated Device Enrollment), Apple Business Manager-Integration, SCEP-Zertifikate (okay okay, hier gibt es so manche Use-Cases, da kann man nur mit dem Kopf drüber schütteln), Conditional Access – das läuft mittlerweile alles rund. Für Organisationen, die primär Microsoft 365 nutzen, ist die Integration einfach nahtlos. Ein Klick in Azure AD, und der Mac (Ja ja, JAMF ist the King, but don’t judge me 😉) oder das iPhone ist im Unternehmensnetzwerk.

Wo Intune noch hinterherhinkt: Bei sehr spezifischen, tief greifenden iOS-Konfigurationen kommt man schneller an Grenzen als bei WS1. Custom Profiles gehen auch hier, aber die Dokumentation und der Support sind nicht immer auf dem gleichen Level.

Kriterium Workspace ONE Microsoft Intune
Apple Business Manager ✅ Stark, tiefe Integration ✅ Gut, nahtlos mit M365
Supervised Mode ✅ Vollständig unterstützt ✅ Vollständig unterstützt
Custom Profiles (XML) ✅ Sehr flexibel ⚠️ Möglich, aber weniger komfortabel
Zero-Touch Enrollment ✅ Excellent ✅ Gut
Conditional Access ✅ Via Workspace ONE Intelligence ✅ Nativ in Azure AD

Android-Management: Enterprise-tauglich oder Bastelbude?

Android for Enterprise (AfE) – die Grundlage

Seit Google Android for Enterprise eingeführt hat, ist Android im Enterprise-Umfeld erwachsen geworden. Beide Systeme unterstützen die gängigen AfE-Enrollment-Methoden: Work Profile, Fully Managed, Dedicated Device. Der Unterschied liegt – wie so oft – im Detail.

Workspace ONE bei Android

WS1 ist im Android-Segment extrem stark, gerade wenn es um Fully Managed Devices oder Dedicated Devices (Kiosk-Mode) geht. Ich hab das in Projekten mit Samsung Knox & Zebra Devices immer wieder erlebt: WS1 gibt dir einfach mehr Hebel. OEM Config-Support, tiefe Knox Integration, granulare App-Verwaltung über Managed Google Play – das sitzt. Auch wenn ich da nochmal sagen muss, Knox und Ich, naja das wird nie eine richtige Freundschaft 😏

Ein echtes Highlight: der Workspace ONE Intelligent Hub. Der Agent macht auf Android deutlich mehr als nur MDM-Policies zu verteilen. Self-Service, App Catalog, Benachrichtigungen – das fühlt sich für den User weniger nach „Kontrolle“ an und mehr nach „Tool“.

Microsoft Intune bei Android

Intune hat bei Android in den letzten Jahren ebenfalls stark nachgelegt. Work Profile Enrollment läuft smooth (okay, wenn wir realistisch sind, kommt es auch hier manchmal auf die Laune von Microsoft an & man darf den einen oder anderen Kaffee trinken, bis das System es richtig umsetzt), MAM (Mobile App Management) ohne Enrollment ist für BYOD-Szenarien oft die smartere Wahl – und hier glänzt Intune wirklich. Die Integration mit Microsoft Apps (Outlook, Teams, Edge) via App Protection Policies ist einfach unschlagbar komfortabel.

Bei Dedicated Devices und komplexen Kiosk-Setups merkt man aber schneller die Grenzen. Hier fehlt Intune die Tiefe, die WS1 mitbringt – vor allem wenn OEM-spezifische Features gefragt sind.

Kriterium Workspace ONE Microsoft Intune
Work Profile (BYOD) ✅ Gut ✅ Sehr gut, bes. mit MAM
Fully Managed Devices ✅ Exzellent ✅ Gut
Dedicated/Kiosk Mode ✅ Sehr flexibel ⚠️ Eingeschränkt
OEM Config (Zebra/Samsung) ✅ Tiefe Integration ⚠️ Basis-Support
MAM ohne Enrollment (BYOD) ✅ Vorhanden ✅ Best-in-Class
Knox Integration ✅ Exzellent ⚠️ Eingeschränkt

Rugged Devices: Zebra, Honeywell & Co. – das oft vergessene Segment

Das ist das Thema, das in 80% der MDM-Blogposts völlig ignoriert wird – aber in den letzten über 7 Jahren durfte ich in meiner täglichen Arbeit einige Erfahrungen sammeln. Zebra TC-Serie, Honeywell CT-Serie, MDE-Devices für Logistik, Produktion, Einzelhandel – das sind Tiere für sich.

Workspace ONE hat hier einen klaren Vorteil: Die Zebra OEM Config-Unterstützung ist exzellent. StageNow-Integration, SOTI-ähnliche Konfigurationsmöglichkeiten via WS1, spezifische Hardware-Profile für Barcode-Scanner, PTT-Tasten, Display-Helligkeit unter bestimmten Bedingungen – das alles lässt sich über WS1 granular steuern.

Intune verbessert sich hier, aber wenn ihr ernsthaft in der Welt der Rugged Devices unterwegs seid, werdet ihr mit Intune allein oft nicht glücklich. Hier braucht man entweder WS1 oder spezialisierte EMM-Lösungen wie SOTI MobiControl. Manche Kunden kombinieren das auch – Intune für Standard-Devices, WS1 oder SOTI für den Rugged-Bereich.

Administration: Wo macht’s mehr Spaß (oder weniger Frust)?

Die WS1-Konsole

Ich sag’s ehrlich: WS1 ist mächtig. Und mit Macht kommt Komplexität. Die Admin-Konsole ist funktionsreich bis an die Grenze des Überwältigenden. Wenn du weißt, was du tust, kannst du quasi alles konfigurieren. Wenn du neu bist, kannst du dich erstmal eine Weile in den Menüs verlieren.

Mit dem Umstieg auf Workspace ONE UEM Cloud und dem neueren UI hat VMware / Broadcom einiges verbessert. Trotzdem: Die Lernkurve ist real. Ich empfehle hier immer eine gute Schulung (auch wenn die nur auf Labs wie bei allen großen besteht) oder – noch besser – jemanden mit Erfahrung an Bord zu holen.

Die Intune-Konsole (aka Microsoft Intune Admin Center)

Wer regelmäßig im Azure-Portal unterwegs ist, fühlt sich in Intune schnell zuhause. Das Layout folgt Microsoft-Logik, die Dokumentation ist umfangreich und auf Microsoft Learn sehr gut aufbereitet. Für Admins, die bereits mit Azure AD, Conditional Access oder Defender for Endpoint arbeiten, ist das ein echter Vorteil – alles spielt zusammen.

Was mich bei Intune manchmal wahnsinnig macht: Einstellungen, die sich an drei verschiedenen Stellen befinden können (Device Configuration, Security Baselines, Endpoint Security…). Das sorgt für „Wo war das nochmal?“-Momente, die man kennt, wenn man Intune schon länger nutzt.

Security: Wer schläft ruhiger?

Security ist das Herzstück jedes MDM-Systems, und hier spielen beide in der obersten Liga – auf unterschiedliche Weise.

Workspace ONE Intelligence & Trust Network

WS1 bringt mit Workspace ONE Intelligence eine eigene SIEM-ähnliche Analyse- und Automatisierungsschicht mit. Ich kann Policies definieren, die automatisch auf Geräte reagieren (z.B.: Device ohne aktuelles OS-Update → Zugriff auf Unternehmensressourcen sperren). Das Trust Network integriert Security-Drittanbieter – hier möchte ich einfach keine Namen nennen, dort gilt: try and error. Für komplexe Enterprise-Security-Setups ist das richtig stark.

Microsoft Defender + Conditional Access

Microsoft spielt seine Stärken hier aus: Microsoft Defender for Endpoint ist direkt in Intune integriert. Conditional Access in Azure AD ist für viele Szenarien der Standard-Ansatz – und das aus gutem Grund. Wenn ihr M365 E5 oder ähnliche Lizenzen habt, bekommt ihr Security-Features, für die ihr bei WS1 extra zahlen würdet.

Für reine Microsoft-Shops ist das Sicherheits-Stack von Microsoft schwer zu schlagen. Für heterogene Umgebungen mit vielen Nicht-Microsoft-Produkten hat WS1 mehr Flexibilität.

Flexibilität & Skalierbarkeit: Wächst das System mit?

Workspace ONE: Extrem skalierbar, extrem flexibel – und extrem komplex wenn man’s falsch angeht. WS1 kann On-Premise, Cloud oder Hybrid betrieben werden. Das ist in regulated industries (KRITIS, Banken, Healthcare) ein echtes Argument.

Und genau für diese regulierten Umgebungen gibt es seit kurzem eine weitere spannende Option: die Omnissa Sovereign Solution für Workspace ONE. Das ist kein klassisches On-Premise mehr im alten Sinne, sondern ein partner-gehostetes SaaS-Modell – sprich, ein zertifizierter Partner betreibt die WS1 UEM-Umgebung in seinem eigenen privaten, lokalen Rechenzentrum. Damit bekommt man die Vorteile einer modernen SaaS-Architektur, ohne die Daten in eine internationale Public Cloud geben zu müssen. Für KRITIS, Behörden oder stark regulierte Branchen kann das ein echter Game-Changer sein – und ist definitiv ein Thema, dem ich hier auf dem Blog noch einen eigenen Post widmen werde!

Intune: Cloud-first, kein On-Premise. Das ist für die meisten Unternehmen heutzutage kein Problem – kann aber in stark regulierten Umgebungen zum Showstopper werden. Dafür ist der Betrieb operativ günstiger und einfacher.

Kriterium Workspace ONE Microsoft Intune
Deployment-Option Cloud, On-Premise, Hybrid, Sovereign Cloud-only
Skalierbarkeit Sehr hoch Hoch
API-Integration Umfangreiche REST APIs Microsoft Graph API
Multi-Tenant ✅ ✅
Lizenzkosten Höher, modular In M365 oft inkludiert
Community & Docs VMware Tech Zone / Broadcom Docs Microsoft Learn (sehr gut)

Das Broadcom-Thema: Der Elefant im Raum

Ich wäre kein ehrlicher MDM-Blogger, wenn ich das nicht ansprechen würde: Broadcom hat VMware übernommen – und das hat die WS1-Welt ordentlich durchgeschüttelt. Lizenzstruktur-Änderungen, Partner-Ökosystem-Unsicherheiten, Support-Fragen… Das sind reale Themen, die Kunden zu Recht beschäftigen.

Ich sage nicht, dass WS1 deshalb keine gute Wahl mehr ist. Aber wer heute eine Entscheidung treffen muss, sollte das Broadcom-Thema in der Bewertung nicht ignorieren. Es hat viele Unternehmen dazu gebracht, ihre MDM-Strategie zu überdenken – und nicht wenige davon landen gerade bei Intune oder evaluieren Alternativen wie Jamf (für Apple-only) oder SOTI.

Für wen ist was die bessere Wahl?

Jetzt wird’s meinungsstark – aber ohne Sieger. Es gibt kein „besser“ ohne Kontext. Hier meine Einschätzung:

  • Du bist tief im Microsoft 365-Ökosystem, nutzt Azure AD, Defender und Teams? → Intune ist dein Weg.
  • Du hast eine heterogene Umgebung mit iOS, Android und Rugged Devices von Zebra oder Honeywell? → WS1 hat die tiefere Feature-Abdeckung.
  • Du bist ein kleines bis mittelständisches Unternehmen ohne dediziertes MDM-Team? → Intune ist einsteigerfreundlicher und günstiger.
  • Du brauchst On-Premise, Hybrid oder Sovereign-Deployment aus regulatorischen Gründen? → WS1 (inkl. Omnissa Sovereign Solution) ist dein einziger Kandidat der beiden.
  • BYOD-Strategie mit Android und minimaler Eingriff auf Privatgeräte? → Intune MAM ist hier das Mittel der Wahl.
  • Komplexe Enterprise-Security mit Drittanbieter-Integration? → WS1 Intelligence bietet hier mehr Flexibilität.

Fazit: Zwei Welten, eine Entscheidung

Nach 16+ Jahren MDM kann ich euch sagen: Es gibt kein universell „besseres“ System. Workspace ONE ist das Schweizer Taschenmesser – mächtig, flexibel, aber komplex. Microsoft Intune ist der verlässliche Werkzeugkasten für alle, die schon tief im Microsoft-Stack stecken.

Was ich euch mitgeben will: Evaluiert ehrlich eure eigene Umgebung. Welche Devices, welche Nutzungsszenarien, welche internen Skills habt ihr? Und schaut euch die Lizenzkosten ganzheitlich an – Intune ist oft schon in euren M365-Lizenzen drin, WS1 kostet extra.

Aber eins ist klar: Es bleibt spannend und der Bereich entwickelt sich und entwickelt sich. Man darf sich hier einfach weiter drauf freuen, wie es weitergeht – und wer weiß, vielleicht kommt ja noch einer der underated Underdogs aus dem Untergrund wieder hoch. 😄

Ich freue mich auf eure Erfahrungen in den Kommentaren – seid ihr Team WS1, Team Intune, oder habt ihr eine ganz andere Lösung gefunden? Immer her damit! 😄

Vmware WSONE: macOS managemend Install LOG auslesen

18. November 2021 / / Keine Kommentare

Kurze Notize, wenn man auf dem Mac das Install LOG welches durch Workspace One erstellt wird, auslesen möchte, kann man dies ganze einfach via Terminal machen.

Dazu einfach den Terminal starten und folgenden Befehl eingeben:

tail -n 20 -F /Library/Application\ Support/AirWatch/Data/Munki/Managed\ Installs/Logs/ManagedSoftwareUpdate.log

That’s it

Workspace ONE UEM 1903: Technical Deep Dive

3. April 2019 / / Keine Kommentare

Heute mal ein kleiner Verweis auf die neue Workspace ONE UEM 1903 Version. Es sind einige neue Features enthalten. Einen super überblick erhaltet Ihr in diesem Video. Also nehmt euch die 36 min zeit und schaut es euch an.

 

EMM Identifier in Workspace ONE UEM ändert sich (afw#hub)

3. April 2019 / / Keine Kommentare

Da ich mich im beruflichen Leben ja mit Mobile Device Management (MDM) beschäftige und in diesem Bereich seit Anfang 2019 nun als Specialist Mobile Device Management tätig bin, werde ich hier in Zukunft immer mal Info’s – Notes & Marker zu diesem Bereich online stellen.

VMWare hat schon im Januar in Ihrem Blog verkündet das sich der EMM Identifier für Airwatch aka. Workspace ONE UEM unter Android for Enterprise ändert.

Wie unter https://support.workspaceone.com/articles/360015746473 zu lesen, ändert sich der Identifier von afw#airwatch nach afw#hub !

Damit wird die Namenstransformation von Airwatch zu Workspace ONE komplett (der Agent wurde ja schon im laufe 2018 in Intelligent HUB umgeändert).