Schlagwort: Android Enterprise

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

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

Schon wieder März – und wieder eine Release, die zeigt, wo Microsofts Reise hingeht. Diesmal hat man sich besonders Zeit für Apple DDM genommen, und das ist bedeutsam. Als jemand, der schon länger im MDM-Umfeld unterwegs ist, sehe ich hier einen wichtigen Shift: Apple zieht mit Declarative Device Management aus dem klassischen MDM-Modus raus. Das ist nicht einfach nur „noch ein Feature“ – das ändert, wie wir iOS/iPadOS Apps deployen.

Gleichzeitig bekommt macOS endlich ordentliche Recovery Lock Features, Android Enterprise kriegt neuen OEM-Support, und Linux wird erwachsen. Lass mich die wichtigsten Punkte durchgehen.


Übersichtstabelle: Was ändert sich in 2603?

Feature Plattform Kategorie Status
Declarative Device Management (DDM) für Line-of-Business Apps iOS/iPadOS 18+ App Management ✅ Verfügbar
Recovery Lock mit Password Rotation macOS Device Configuration 🔄 Rollout (bis Ende April)
Inventus OEMConfig Integration Android Enterprise OEMConfig ✅ Verfügbar
Disable Cross Device Resume Policy Windows 10/11 Settings Catalog ✅ Windows Insiders
Remove Microsoft Copilot App Policy Windows 10/11 Settings Catalog ✅ Verfügbar
Apple Intelligence & AI Settings (DDM) iOS/iPadOS, macOS Settings Catalog ✅ Verfügbar
Remote Help Connectivity Endpoint Windows Device Management ✅ Verfügbar
RHEL 9 LTS & 10 LTS Support Linux Enrollment ✅ Verfügbar
Microsoft Identity Broker für Linux Linux Authentication ✅ Verfügbar

1. Declarative Device Management für Apple – Das große Ding

Was ist DDM und warum sollte dich das interessieren?

Seit iOS 18 und iPadOS 18 können wir Apple DDM nutzen, um Line-of-Business Apps zu verwalten. Das ist ein großer Unterschied zur klassischen MDM-Verwaltung:

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

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

Praktisch im Intune Admin Center:

  1. DevicesApps → Deine iOS/iPadOS Line-of-Business App öffnen
  2. App Information → Management Type auf Declarative Device Management setzen
  3. Neue Per-App-Optionen konfigurieren (z.B. Associated Domains)
  4. Deployment starten

Was dich erwartet:

✅ Schnellere App-Bereitstellung
✅ Bessere App-Status-Transparenz
✅ Neue Security Features via Associated Domains
❌ Nur für iOS/iPadOS 18+ (Versionsprüfung nötig)

Meine Einschätzung: Das ist ein echter Game-Changer für Unternehmen mit großen iOS-Flotten. Wenn du noch auf iOS 17 bist, solltest du jetzt deinen Update-Plan prüfen.


2. Recovery Lock für macOS – Sicherheit auf neuer Ebene

Das Problem, das Recovery Lock löst:

Ein User mit lokalen Admin-Rechten kann sich in Recovery Mode booten, die Festplatte neuformatieren und dein MDM-Management umgehen. Damit ist Schluss.

Was ist Recovery Lock?

Ein Recovery OS Password, der verhindert:
– Booten in Recovery Mode
– macOS Neuinstallation ohne Admin-Genehmigung
– Umgehen der Remote Management

Zwei Wege zur Umsetzung:

Option 1: Settings Catalog Policy

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

Option 2: Remote Device Action (Manuelle Rotation)

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

Wichtig: RBAC für Passwords

⚠️ Handlungsbedarf: Admins brauchen explizit die Berechtigung:

Remote tasks/View macOS recovery lock password

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

Verfügbarkeit:

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


3. Android Enterprise: Inventus OEMConfig

Neu: Inventus com.inventus.oemconfig.gen

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

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

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

Für wen relevant: Unternehmen mit Zebra/Honeywell/Inventus Devices im Warehouse/Retail.


4. Windows Settings Catalog – Zwei neue Policies mit Bedeutung

Policy 1: Disable Cross Device Resume

Scenario: Der User startet etwas auf seinem iPhone und will es auf dem PC fortsetzen. Security-Policy sagt: Nein.

Devices → Configuration profiles → Create
→ Windows 10 and later
→ Settings Catalog
→ Connectivity
→ Disable Cross Device Resume: Select "Disabled"

Effekt: Keine „Resume from your phone“ Prompts mehr.

Status: ⚠️ Nur für Windows Insiders (Preview-Feature)

Policy 2: Remove Microsoft Copilot App

Szenario: Copilot ist vorinstalliert, aber deine Security Policy sagt: Nicht auf unternehmenseigenen Devices.

Settings Catalog
→ Windows AI
→ Remove Microsoft Copilot App: Enable

Bedingungen (automatisch prüfbar):
– Beide Copilot Apps sind installiert
– User hat die App nicht selbst installiert
– App wurde in letzten 14 Tagen nicht geöffnet

Effekt: App wird deinstalliert (User kann sie später neu installieren).

Status: ✅ Sofort verfügbar


5. Apple Settings Catalog – DDM erweitert sich massiv

DDM x Apple Intelligence Settings (Neu!)

Mit iOS 18 / macOS Sonoma kommt Apple Intelligence. Intune kann jetzt granular kontrollieren:

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

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

Praktisch:

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

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


6. Remote Help – Neue Connectivity-Anforderung ⚠️

Firewall-Update erforderlich!

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

*.trouter.communications.svc.cloud.microsoft

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

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

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


7. Linux Support – RHEL wird erwachsen

Support-Änderung:

Version Status Aktion
RHEL 8 LTS ❌ End of Support Bestehende Devices bleiben enrollt, aber kein Support mehr
RHEL 9 LTS ✅ Neu unterstützt Production-Ready
RHEL 10 LTS ✅ Neu unterstützt Production-Ready

Handlungsbedarf für dich:

  1. Identify RHEL 8 Devices:
Intune Admin Center
→ Devices → All devices
→ Filter: OS = Linux
→ Add Column: OS Version
  1. User Notification:
    – E-Mail an Admins mit RHEL 8-Devices
    – Upgrade-Plan für Q2/Q3 2026
  2. Enrollment Verification:
    – Neue Enrollments nur auf RHEL 9+ akzeptieren
    – Enrollment Restrictions prüfen

Microsoft Intune App für Linux – Identity Broker Integration

Die neue Version der Intune-App für Linux unterstützt jetzt Microsoft Identity Broker, was bedeutet:
– SSO zwischen Linux-Apps und Browser
– Bessere Token-Verwaltung
– Sicherere Authentication Flow


🚨 Kritische Handlungsbedarfe

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

Meine persönliche Einschätzung

Diese Release 2603 ist solider mittlerer Release – nicht revolutionär, aber substanziell:

Positiv:
– Apple DDM für LOB Apps ist längst überfällig und wird Deployment-Performance spürbar verbessern
– Recovery Lock für macOS schliesst echte Security-Lücke
– Linux Support mit RHEL 9/10 macht Sinn (Zukunftsicherung)
– AI Settings Katalog zeigt, dass Microsoft ernst mit Apple Intelligence-Management meint

⚠️ Vorsichtig:
– Recovery Lock ist nur graduelle Rollout (bis Ende April) – nicht ideal für große Deployments
– Cross-Device Resume Policy ist noch Insider-only (zu nischig?)
– Copilot Removal braucht spezifische Bedingungen (14 Tage nicht geöffnet – kann frustrierend sein)

🔔 Wichtigste Action: Firewall-Update für Remote Help. Das übersehen viele und dann funktioniert Remote Help plötzlich nicht.


Quellen & Dokumentation

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

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.

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