Intune Advanced Analytics im Vergleich

In diesem Blogbeitrag möchte ich mir Microsoft Intune Advanced Analytics ansehen und es mit klaren Worten mit den anderen Analytics-Tools vergleichen, die es da draussen gibt — und ehrlich zeigen, wie es dabei abschneidet. Das ist ein Thema, das ich gut kenne. Bevor ich angefangen habe, Blogs zu schreiben und mein eigenes Unternehmen zu führen, war ich jahrelang Tech Lead für AIOps in einem grossen Unternehmen. Teil meiner Aufgabe war es, Analytics- und Digital-Employee-Experience-Plattformen (DEX) zu evaluieren – Nexthink, Aternity, die Analytics-Lösung von HP und einige mehr. Das ist also kein Marketing-Text. Es ist das, was ich aus dem Betrieb dieser Tools im grossen Massstab gelernt habe, und wo Microsofts Ansatz aus meiner Sicht wirklich anders ist.

Hier mein ehrliches Fazit gleich vorweg: Die meisten dieser Plattformen kochen auch nur mit Wasser. Sie sind ausgereift und leistungsfähig, lösen aber weitgehend dieselben Probleme auf dieselbe Weise. Das Schwierige war nie das Dashboard – es war der Aufbau eines Business Case, der einen zweiten Blick überstanden hat, denn jede einzelne kam mit ihrem eigenen Agent, ihrem eigenen Datenspeicher, ihrem eigenen Portal und ihrer eigenen Lizenz. Genau diese Kosten beseitigt Microsoft Intune Advanced Analytics.

Gut zu wissen, bevor du weiterliest: Ab dem 1. Juli 2026 ist Microsoft Intune Advanced Analytics in Microsoft 365 E3 und Microsoft 365 E5 als Teil von Microsoft Intune Plan 2 enthalten. Das separate Add-on, das früher rund 10 USD pro Benutzer und Monat gekostet hat, ist jetzt Teil des Plans. Viele Teams besitzen das bereits und wissen es noch nicht.

Inhaltsverzeichnis

Was ist Microsoft Intune Advanced Analytics?

Intune Advanced Analytics erweitert Endpoint Analytics innerhalb von Microsoft Intune. Das wichtige Wort ist innerhalb. Es ist kein separates Produkt. Es lebt im selben Admin Center, in dem du bereits Geräte registrierst, Konfigurationen ausrollst und Behebungen durchführst.

Das klingt nach einem kleinen Detail. Nach Jahren des Betriebs der Alternativen kann ich dir sagen: Es ist das ganze Spiel. Jede DEX-Plattform, die ich betrieben habe, brauchte ihren eigenen Agent auf jedem Gerät, ihren eigenen Data Lake und eine zweite Konsole zum Einloggen. Mit Advanced Analytics gibt es keinen zusätzlichen Agent. Die Geräte, die du bereits verwaltest, sind die Geräte, die du bereits analysierst.

Wie funktioniert es hinter den Kulissen?

Das ist der Teil, den ich mir in mehr Vergleichen erklärt gewünscht hätte, also lass mich eine Ebene tiefer gehen.

Deine verwalteten Geräte senden bereits Diagnose- und Telemetriedaten an Intune. Advanced Analytics baut auf genau dieser Pipeline auf, sodass kein neuer Agent bereitgestellt werden muss.

Es hilft, zwei Dinge auseinanderzuhalten, die oft vermischt werden:

• Das Geräteinventar ist eine Kernfunktion von Intune. Unter Windows sammelst du zusätzliche Hardware- und Software-Eigenschaften mit einer Properties-Catalog-Richtlinie. Das ist nicht Teil von Advanced Analytics und benötigt kein Add-on – es ist in Microsoft Intune Plan 1 enthalten. (Und um es klarzustellen: Der Properties Catalog ist nicht der Settings Catalog, den du für Konfigurationsprofile verwendest. Zwei verschiedene Dinge.) Unter iOS/iPadOS, Android und macOS wird dieses Inventar automatisch erfasst.
• Advanced Analytics ist die Abfrage- und Intelligence-Schicht darüber. Device Query, die Machine-Learning-Anomaliemodelle, der Akkuzustand, die Ressourcenleistung und die Gerätezeitleiste sind die Teile, die die Lizenz benötigen.

Nun der Teil, den ich eine Weile gebraucht habe, um ihn richtig zu verstehen, und den die meisten Beiträge falsch darstellen: Die Einzelgeräteabfrage und die Flottenberichte nutzen zwei völlig unterschiedliche Kanäle.

• Kanal 1 – Einzelgeräteabfrage (nahezu Echtzeit). Diese berührt das Inventar überhaupt nicht. Wenn du eine Abfrage gegen ein einzelnes Gerät ausführst, sendet das Portal einen createQuery-POST an Microsoft Graph, eine Nachricht von Windows Push Notification Services (WNS) weckt das Gerät und startet den PilotDeviceQuery-Workflow, und die Intune Management Extension (IME) übernimmt. Die IME prüft das Registry-Flag EnableDeviceActionFeature, lädt eine DeviceQueryDetail-Nutzlast herunter, die deine KQL als base64-String trägt, und führt sie über IntunePivotPlugin.dll gegen die passenden WMI-Provider, CSP und die Registry aus. Das Ergebnis wird als DeviceQueryResult base64-codiert und innerhalb von Sekunden zurückgegeben. Da WNS das Transportmittel ist, schlägt die Abfrage einfach fehl, wenn WNS blockiert ist – und du brauchst IME 1.75.4.0 oder neuer. Rudy Ooms hat diesen gesamten Ablauf auf call4cloud reverse-engineert; es ist der beste Blick unter die Haube, den ich gesehen habe, und daher stammt auch das Detail im Diagramm oben.
• Kanal 2 – Flotteninventar und Berichte (etwa alle 24 Stunden aktualisiert). Hier sammelt der Geräteinventar-Agent Daten aus CSP, WMI und der Registry, wobei der Umfang durch den Properties Catalog (eine Kernfunktion von Intune) definiert wird. Beim geplanten Check-in wird dies auf die Intune-Datenplattform hochgeladen – kein separater Data Lake, der aufgebaut oder abgesichert werden muss. Advanced Analytics führt dann seine Machine-Learning-Modelle und KQL darauf aus, um die Berichte zu Anomalien, Akku, Ressourcen und Gerätezeitleiste zu erzeugen und um die Device Query für mehrere Geräte zu beantworten. Ein flottenweites Ergebnis spiegelt daher den letzten Inventar-Upload wider, nicht die aktuelle Sekunde.

Da alles innerhalb von Intune bleibt, handelst du auf eine Erkenntnis in derselben Konsole, in der du sie gefunden hast. Kein Export, kein zweites Tool.

Hinweis: Wenn die Device Query für mehrere Geräte auf deinen Windows-Geräten nichts zurückgibt, fehlt fast immer die Properties-Catalog-Richtlinie – richte sie zuerst ein (sie ist Kern-Intune, nicht Advanced Analytics) und gib dem Inventar dann Zeit, einzutreffen. Beachte, dass die Einzelgeräteabfrage sie nicht benötigt, weil dieser Pfad das Gerät live über WNS ausliest.

Was kann es? Ein genauerer Blick

Lass mich die Teile durchgehen, die ich am meisten nutze, auf dem Detailniveau, das im Produktivbetrieb tatsächlich zählt.

Device Query – KQL in einer Sprache, die du bereits sprichst

Mit Device Query kannst du einem Gerät oder der Flotte eine direkte Frage in Kusto Query Language (KQL) stellen – derselben Sprache, die dein Security-Team bereits in Microsoft Defender, Microsoft Sentinel und Azure Monitor verwendet. Eine Einzelgeräteabfrage gibt dir nahezu Echtzeit-Zugriff auf dieses Gerät; eine Mehrgeräteabfrage läuft über das gesammelte Inventar. Bei jedem anderen Live-Query-Tool, das ich betrieben habe, musste das Team den eigenen Abfragedialekt dieses Produkts lernen und noch eine weitere Konsole bedienen. Hier gibt es, wenn du KQL schreibst, fast nichts Neues zu lernen:

// Find Windows devices that are low on disk space
DeviceData
| where FreeStorageGB < 10
| project DeviceName, Model, FreeStorageGB, OSVersion
| sort by FreeStorageGB asc

Diese gemeinsame Abfragesprache über Endpoint und Security hinweg ist aus meiner Erfahrung ein echtes Unterscheidungsmerkmal. Keines der eigenständigen DEX-Tools konnte an dieselben Abfragekenntnisse und dieselben Security-Daten andocken, die mein Team bereits hatte.

Mein Lieblingsteil: Lass Copilot die KQL schreiben. Mit Security Copilot in Intune musst du die Abfrage nicht einmal selbst schreiben. Du beschreibst in einfacher Sprache, was du willst – „zeig mir Windows-11-Geräte mit TPM 2.0, die sich seit 14 Tagen nicht synchronisiert haben“ – und Copilot generiert die KQL, zeigt dir die Abfrage und erklärt, wie sie aufgebaut wurde. Es funktioniert auch andersherum: Füge eine Abfrage ein, die ein Kollege geschrieben hat, frage „was macht das?“, und du bekommst eine Erklärung in einfacher Sprache.

Für mich ist das die Funktion, die Device Query für das ganze Team nutzbar macht, nicht nur für die zwei Leute, die KQL fliessend beherrschen. Das hatte ich mit keinem anderen Analytics-Tool je – der Schritt von natürlicher Sprache zur Abfrage lebte immer in einem separaten Produkt, falls es ihn überhaupt gab.

Anomalieerkennung – das Machine Learning erklärt

Der Anomalienbericht ist die Funktion, die am direktesten mit den Premium-DEX-Plattformen konkurriert, und hier zeigt sich Microsofts Datenvorteil. Er überwacht App-Hänger, Abstürze und Stop-Error-Neustarts und gruppiert dann betroffene Geräte, damit du die gemeinsame Ursache findest.

Der Anomalienbericht, gruppiert nach Schweregrad. Quelle: Microsoft Learn.

Dahinter stehen vier statistische Modelle, und es hilft zu wissen, welches was tut:

• Schwellenwertbasierte Heuristik – markiert ein Gerät, wenn Abstürze, Hänger oder Stop-Error-Neustarts einen festgelegten Schwellenwert überschreiten. Einfach, gut für offensichtliche oder statische Probleme.
• Gepaarter t-Test – vergleicht dasselbe Gerät vor und nach einer Änderung (einem Richtlinien-Update oder einem OS-Update) und sucht nach einem statistisch signifikanten Unterschied. Das ist das Modell, das „das Update hat es kaputtgemacht“ erkennt.
• Populations-Z-Score – findet Ausreissergeräte oder -Apps im Vergleich zum Flottendurchschnitt. Benötigt einen grossen Datensatz, um genau zu sein.
• Zeitreihen-Z-Score – ein gleitendes Fenster über die Zeit, sodass es sich an Trends anpasst statt an einen festen Schwellenwert.

Wenn etwas markiert wird, zeigen Gerätekorrelationsgruppen die gemeinsamen Faktoren – App-Version, Treiber-Update, OS-Version, Gerätemodell – und eine Prävalenzrate sagt dir, welcher Anteil einer Gruppe betroffen ist. In einem grossen Unternehmen ist das genau die Ansicht, die ich vorher immer von Hand bauen musste: Sie zeigt direkt auf den schlechten Treiber oder das eine Hardwaremodell, anstatt es dich selbst korrelieren zu lassen.

Akkuzustand – mehr als ein einzelner Wert

Der Akkuzustandsbericht bewertet jeden Windows-Laptop-Akku, aber das Detail darunter macht ihn nützlich.

Der Akkuzustandsbericht mit Score und Insights. Quelle: Microsoft Learn.

Der Akkuzustands-Score ist ein gewichteter Durchschnitt aus zwei Werten, jeweils von 0 (schlecht) bis 100 (aussergewöhnlich):

• Kapazitäts-Score – basiert auf der maximalen Kapazität, also der Vollladekapazität geteilt durch die Auslegungskapazität. Ein Akku, der für 70 Wattstunden ausgelegt ist und jetzt 35 hält, liegt bei 50 %.
• Laufzeit-Score – basiert auf der geschätzten Zeit, die ein Gerät mit einer vollen Ladung läuft.

Du bekommst ausserdem die Anzahl der Ladezyklen und einen Reiter App impact, der zeigt, welche Apps in den letzten 14 Tagen am meisten Akku verbraucht haben. Genau dieser letzte Teil macht aus „dieser Laptop hat eine schlechte Akkulaufzeit“ ein „dieser Laptop führt eine stromhungrige App aus“ – eine völlig andere Lösung. Bei den Alternativen bedeutete diese Tiefe ein separates Hardware-Analytics-Modul, oft gegen Aufpreis.

Gerätezeitleiste – die Troubleshooting-Ansicht, die ich am meisten nutze

Die Gerätezeitleiste ist im Tagesgeschäft der Bericht, den ich am häufigsten öffne, also verdient sie mehr als eine Fussnote. Sie zeigt die Ereignisse eines einzelnen Geräts – Neustarts, Stop Errors, App-Hänger und Abstürze, Treiber- und Update-Ereignisse – auf einer Zeitleiste mit geringer Latenz. Sie ersetzt den älteren Bericht zur Anwendungszuverlässigkeit und führt die Ereignisse, die früher über Logs verstreut waren, in einer geordneten Ansicht zusammen.

Warum das wichtig ist: Wenn die Maschine eines VIPs Probleme macht, lautet die erste Frage immer „was hat sich wann geändert?“. Die Zeitleiste beantwortet das direkt. Ich kann sehen, dass die Abstürze direkt nach einem bestimmten Update oder Treiber begannen, es mit dem Anomalienbericht abgleichen und dem Service Desk eine Ursache statt einer Vermutung übergeben. Für den Tier-1- und Tier-2-Support beendet das die meisten Tickets ohne Eskalation – und zwar ohne forensischen Agent auf dem Gerät. Bei den Tools, die ich vorher betrieben habe, bedeutete diese geordnete, korrelierte Ansicht, Ereignisprotokolle zu exportieren und von Hand zusammenzufügen.

Ressourcenleistung – Kaufentscheidungen mit Belegen

Ressourcenleistung reiht CPU- und RAM-Engpässe nach Gerät, Modell und Hersteller. Das macht aus „wir glauben, die Flotte von 2022 ist langsam“ ein belastbares, datengestütztes Kaufargument. Zusammen mit dem Akkuzustand ist es der Bericht, der die Planung eines Hardware-Refreshs zu einem faktenbasierten Gespräch mit dem Einkauf macht statt zu einem Bauchgefühl. Er ist in dieselbe Konsole integriert – kein zusätzlicher Agent, der ihn speist.

Wie schneidet es im Vergleich zu den Tools ab, die ich genutzt habe?

So gewichte ich es. Hier geht es um die Eignung, nicht um einen Sieger – jede Spalte ist eine leistungsfähige, ausgereifte Kategorie, und die DEX-Plattformen machen manche Dinge tatsächlich besser.

Punkt	Intune Advanced Analytics	Dedizierte DEX-Plattform	osquery / Live-Query-Tool
Zusätzlicher Agent bereitzustellen	Keiner – nutzt Intune	Ja, pro Platz	Ja, separat
Separater Datenspeicher	Nein	Ja	Meist
Abfragesprache	KQL (wie Defender/Sentinel)	Eigene Sprache	osquery SQL
ML-Anomalieerkennung	Eingebaut	Oft eine Premium-Stufe	Nicht eingebaut
Behebung in derselben Konsole	Ja – es ist Intune	Nein, zurück zum MDM	Nein
Plattformübergreifende Reichweite	Windows-first	Breit	Breit
Streaming-Telemetrie	Nahezu Echtzeit	Stark	Stark
Kosten	In M365 E3/E5 enthalten (ab 1. Juli 2026)	Separates Abonnement	Separat / Open Source

Das ehrliche Fazit aus den Evaluierungen, die ich durchgeführt habe – Nexthink, Aternity, die Analytics-Tools von HP und andere: Das sind starke, ausgereifte Produkte. Sie führen bei der Breite (Windows, macOS, Mobile und reichhaltiges Experience-Scoring in einem Modell) und bei kontinuierlicher Streaming-Telemetrie. Wenn diese Breite dein Hauptbedarf ist, gewinnen sie nach wie vor, und das sage ich ganz klar.

Aber drei Unterschiede tauchten in meinen Evaluierungen immer wieder auf, und sie sind architektonisch, nicht kosmetisch:

• Wo die Daten liegen. Jede eigenständige Plattform schickt ihre Telemetrie in den eigenen Cloud-Data-Lake des Anbieters. Advanced Analytics hält sie innerhalb der Grenzen deines bestehenden Microsoft-Intune- und Microsoft-365-Tenants – eine Daten-Residenz- und Security-Prüfung weniger, was in einem regulierten Unternehmen keine Kleinigkeit ist.
• Eine Geräteidentität, nicht zwei. Die Drittanbieter-Tools bauen ihren eigenen Geräte-Datensatz auf, und du steckst echten Aufwand in den Abgleich ihres Geräts mit deinem Intune-Objekt, bevor ein Bericht vertrauenswürdig ist. In Advanced Analytics sind das analysierte Gerät, das konfigurierte Gerät und das Compliance-Gerät dasselbe Objekt. Kein Abgleich, keine Datenqualitäts-Pflichtaufgabe.
• Time-to-Value. Ein DEX-Rollout ist ein Agent-Bereitstellungsprojekt – Paketierung, ringbasierter Rollout, Tuning, monatelang. Advanced Analytics ist ein Lizenz-Schalter: aktivieren, bis zu 48 Stunden warten, fertig.

Beim Business Case war dieser kombinierte Overhead – ein zweiter Agent, ein zweiter Data Lake, eine zweite abzugleichende Identität, ein zweites Team für den Betrieb – immer der Teil, der die Zahlen dünn machte.

Wo Microsofts Ansatz einzigartig geeignet ist

Das tiefste Unterscheidungsmerkmal ist strukturell, und es ist das eine, das kein eigenständiges Tool kopieren kann: Microsoft besitzt alle drei Schichten gleichzeitig – die OS-Telemetrie, die Management-Ebene und den Security-Graph. Nexthink, Aternity und der Rest sind hervorragend in der Analytics-Schicht, aber sie sitzen neben deinem Management- und Security-Stack und müssen sich wieder in ihn integrieren. Advanced Analytics sitzt darin. Deshalb kann eine Erkenntnis direkt in eine Konfigurationsänderung, eine Compliance-Richtlinie oder eine Microsoft-Defender-Untersuchung fliessen, ohne die Plattform zu verlassen oder das Gerät neu zu identifizieren. Die konkreten Unterscheidungsmerkmale zusammengefasst:

• Kein zusätzlicher Agent und keine separate Datenplattform. Es reitet auf der Telemetrie, die deine verwalteten Geräte ohnehin senden, und die Daten bleiben in deinem Tenant.
• Eine Abfragesprache über Endpoint und Security hinweg. KQL wird mit Microsoft Defender, Microsoft Sentinel und Azure Monitor geteilt, sodass deine vorhandenen Kenntnisse und deine vorhandenen Security-Daten direkt übertragbar sind. Keines der eigenständigen Tools konnte daran andocken.
• Copilot schreibt die Abfragen für dich. Security Copilot in Intune verwandelt Fragen in einfacher Sprache in KQL für Device Query – sodass das ganze Team der Flotte Fragen stellen kann, nicht nur die zwei KQL-Experten. In den eigenständigen Tools hatte ich nie ein eingebautes Äquivalent.
• Du behebst dort, wo du analysierst. Erkenntnis und Behebung leben im selben Admin Center – für mich ist das der grösste operative Gewinn überhaupt, und der eine, den die nebeneinanderstehenden Tools strukturell nicht erreichen können.
• Machine Learning ist eingebaut, kein Premium-Upsell. Die Anomaliemodelle sind in der Funktion enthalten, statt hinter einer höheren Stufe zu sitzen.
• Es ist in Microsoft 365 E3 und E5 enthalten. Kein separates Add-on zu rechtfertigen. Das ist der Punkt, der endlich den Business Case schliesst, den ich mit den eigenständigen Tools nie ganz hinbekommen habe.

Szenarien aus der Praxis

Enterprise – einen schlechten Treiber abfangen, bevor der Sturm kommt. Das ist ein echtes Muster aus meiner AIOps-Zeit. Ein Grafiktreiber geht an einem Freitag an ein paar Tausend Laptops raus. Am Montag zeigt der Anomalienbericht ein neues Element mit mittlerem Schweregrad: eine Spitze bei Stop-Error-Neustarts. Hier verdient das Modell des gepaarten t-Tests seinen Platz – es vergleicht jedes Gerät vor und nach der Änderung, sodass der Bericht nicht rät, sondern auf eine echte Regression zeigt. Du öffnest die Gerätekorrelationsgruppe, und sie ist eindeutig: ein Hersteller, ein Modell, eine Treiberversion, mit hoher Prävalenzrate. Um klar zu sein, was als Nächstes passiert, denn hier übertreiben es die Leute: Der Anomalienbericht hat keinen magischen „Rollback“-Knopf.

Was er dir gibt, sind die Ursache sowie die Listen der betroffenen und gefährdeten Geräte. Du handelst dann mit den Kern-Intune-Tools – und entscheidend: ohne Intune zu verlassen: bestätige die Ausbreitung mit einer Mehrgeräte-Device-Query, lehne diese Treiberversion in deinem Windows-Treiber-Update-Profil ab, sodass sie dem Rest der Flotte nicht mehr angeboten wird, und pushe ein Intune-Remediation-Skript (ein pnputil-Treiber-Rollback) an die bereits betroffenen Geräte. Erkennen, Ursache finden, beheben – alles in einer Plattform, bevor das Service-Desk-Volumen überhaupt anzieht. Bei den eigenständigen Tools, die ich betrieben habe, lebte die Erkennung in einem Produkt und die Behebung in einem anderen, und beide von Hand zu überbrücken war der langsame Teil.

KMU – Fähigkeiten, die früher ausser Reichweite waren. Ein schlankeres IT-Team hatte selten das Budget oder die Personalkapazität, um eine dedizierte DEX-Plattform zu betreiben – jemand muss diesen Agent und diesen Datenspeicher verantworten. Die Paketierungsänderung zählt hier am meisten: Eine Organisation mit Microsoft 365 E3 oder E5 bekommt jetzt Akkuzustand, Anomalieerkennung und Device Query als Teil von Microsoft Intune Plan 2 – ohne neuen Agent, ohne neuen Vertrag und ohne jemanden, der auf einer zweiten Konsole geschult werden muss.

(Ein ehrlicher Vorbehalt: Das gilt für Microsoft 365 E3/E5 – ein Tenant mit Microsoft 365 Business Premium ist nicht Teil dieser Änderung.) Für ein kleines Team ersetzt allein die nahezu Echtzeit-Einzelgeräteabfrage – stell einem fehlerhaften Laptop eine Frage und bekomme in Sekunden eine Antwort – eine Menge Rätselraten in Remote-Sessions.

Was ich wählen würde

• Überwiegend Windows, bereits auf Intune, Team kennt KQL? Beginne mit Advanced Analytics. Wahrscheinlich besitzt du es bereits, und du kannst separate Akku-, Ressourcen- und Anomalie-Tools ausmustern.
• Brauchst du schnelle Antworten über die ganze Flotte? Nutze Device Query für mehrere Geräte – stelle zuerst die Properties-Catalog-Richtlinie bereit und denke daran, dass sich das Inventar etwa alle 24 Stunden aktualisiert.
• Brauchst du echte Streaming-Telemetrie oder tiefes macOS- und Mobile-Experience-Scoring? Eine dedizierte DEX-Plattform führt dort nach wie vor, und die beiden funktionieren problemlos nebeneinander.

Worauf du achten solltest

• Es ist nicht sofort verfügbar. Nach der Lizenzierung und für die Mehrgeräteabfrage kann es bis zu 48 Stunden dauern, bevor Daten erscheinen. Schalte es ein, bevor du es brauchst.
• Die Properties-Catalog-Richtlinie ist unter Windows zwingend. Denke daran, dass es eine Kern-Funktion von Intune ist, die du separat konfigurierst – ohne sie gibt die Device Query für mehrere Geräte nichts zurück.
• Es ist nahezu Echtzeit, kein Streaming-SIEM. Die Einzelgeräteabfrage ist nahezu Echtzeit; das Flotteninventar ist konstruktionsbedingt etwa einen Tag alt.
• Prüfe deine Cloud und Plattform. Device Query und Ressourcenleistung sind heute nicht in DoD verfügbar, und das tiefste Reporting ist Windows-first.

Ein kurzes Wort zur Lizenzierung

Das ist der Teil, der die Rechnung für mich verändert hat, also lohnt es sich, ihn klar zu wiederholen. Ab dem 1. Juli 2026 ist Microsoft Intune Advanced Analytics in sowohl Microsoft 365 E3 als auch Microsoft 365 E5 als Teil von Microsoft Intune Plan 2 enthalten – das alte Add-on pro Benutzer ist weg. Ein paar der fortgeschritteneren Intune-Funktionen bleiben bei Microsoft 365 E5: Microsoft Intune Endpoint Privilege Management, Enterprise App Management und Microsoft Cloud PKI. Aber Advanced Analytics selbst ist in E3 und E5. Die Details stehen im Microsoft-Intune-Blog zu den Paketierungsänderungen.

Nach Jahren des Versuchs, eine separate Analytics-Plattform zu rechtfertigen, ist das die Änderung, die ich am spannendsten finde: Der Business Case macht sich weitgehend von selbst, weil die meisten Teams die Lizenz bereits besitzen.

Wenn du lesen willst, wohin das alles steuert, habe ich darüber in AI-driven endpoint management: the future with Intune geschrieben. Für die offiziellen Details ist die Advanced-Analytics-Übersicht auf Microsoft Learn die Seite, die ich offen halte.

Ich hoffe, das hilft dir, wenn du Intune Advanced Analytics mit den anderen Tools da draussen vergleichst.

Bleib gesund, Cheers Jannik