Wer im Intune Admin Center auf Sync klickt, kennt dieses Gefühl: Knopf drücken und hoffen. Ob das Gerät die Richtlinie wirklich bekommen hat, zeigt sich irgendwann – im Zweifel erst, wenn der Anwender wieder anruft. Seit dem Sommer ist dieses Ratespiel deutlich kleiner geworden.
Microsoft hat zwischen Juni und August 2026 gleich mehrere neue Intune-Features ausgerollt, die auf denselben Punkt einzahlen: weniger Eigenbau, mehr Sichtbarkeit. Drei davon verändern den Alltag im Endpoint Management spürbar – die überarbeitete Sync-Aktion, das Registry-Inventar im Properties Catalog und automatische Updates für Apps aus dem Enterprise App Catalog. Alle drei sind schon in der Praxis nutzbar, alle drei haben Kanten, die man kennen sollte.
Der Sync-Button tut endlich das, was alle erwartet haben
Bisher war "Synchronisieren" vor allem ein Anstoß zum Check-in. Mit Service Release 2607 stößt Intune stattdessen eine umfassende Synchronisierung über mehrere Workloads an: Konfigurationsrichtlinien werden verarbeitet, App-Erkennung und Bereitstellungsstatus aktualisiert, Skripte und Remediations laufen mit. Microsoft nennt diese Liste ausdrücklich nicht abschließend – weitere Gerätesignale, die den Zustand mit den aktuellen Zuweisungen abgleichen, gehören dazu.
Der eigentliche Gewinn steckt aber nicht im Umfang, sondern im Tab Device sync status in der Geräteansicht. Dort läuft der Vorgang Schritt für Schritt mit: Gerät benachrichtigt, Verbindung hergestellt, Richtlinien verarbeitet, Apps angeboten, Skripte ausgeführt, Compliance berechnet. Statt einer Blackbox sieht man, an welcher Stelle es klemmt.
Zwei Details dazu. Erstens gilt das neue Verhalten inklusive Status-Tab nur für Windows und iOS/iPadOS. Zweitens hängt es an der neuen Geräteseite, die im April als Preview startete und seit Service Release 2608 (Woche vom 25. August 2026) standardmäßig aktiv ist. Wer den Schalter Preview new device view irgendwann bewusst ausgeschaltet hat, sieht auch den Sync-Status nicht.
Im Troubleshooting ist das ein echter Unterschied. Bei einer dringenden Richtlinienänderung, einem eiligen App-Rollout oder einem Incident muss man nicht mehr aus Symptomen rückschließen, was am Gerät passiert ist. Man schaut nach.
Registry-Werte inventarisieren, ohne ein einziges Skript
Die zweite Neuerung dürfte in vielen Umgebungen ein paar PowerShell-Skripte überflüssig machen. Über den Properties Catalog lassen sich seit Service Release 2607 ausgewählte Registry-Werte verwalteter Windows-Geräte inventarisieren. Drei Erfassungsmethoden stehen zur Verfügung: ein einzelner Wert, alle Werte direkt unterhalb eines Schlüssels (nicht rekursiv) oder derselbe Wert über die unmittelbaren Unterschlüssel hinweg.
Angelegt wird das als ganz normales Konfigurationsprofil – Plattform "Windows 10 and later", Profiltyp Properties catalog, dann die Kategorie Registry auswählen und zuweisen. Die Daten landen unter Device Inventory am jeweiligen Gerät. Für die erste Erfassung sollte man Geduld mitbringen: Bis zu 24 Stunden dauert es, bis Inventardaten das erste Mal ankommen.
Die Grenzen der ersten Version sind klar dokumentiert und relevant für die Planung: Es wird ausschließlich unter HKEY_LOCAL_MACHINE gelesen, ein Wert darf höchstens 6 KB groß sein, pro Gerät sind maximal 100 Registry-Schlüssel möglich. Wer alles einsammeln will, was interessant sein könnte, ist damit schnell am Limit – die Auswahl muss also sitzen.
Der Punkt, den ich für den wichtigsten halte, steht etwas unscheinbar in der Dokumentation: Registry Inventory ist nicht für sensible oder vertrauliche Werte gedacht. Eine Erkennungslogik soll verhindern, dass solche Werte überhaupt erfasst werden, und was einmal als potenziell sensibel eingestuft ist, wird nicht gesammelt. Trotzdem weist Microsoft ausdrücklich darauf hin, dass der Zugriff über die bestehenden Device-Inventory-Berechtigungen läuft und Organisationen die Sicherheits- und Datenschutzfolgen prüfen sollten, bevor sie den Zugriff breit öffnen. Das ist keine Formalie. Wer heute schon großzügig Leserechte auf Geräteinformationen vergeben hat, sollte diese Rollen noch einmal ansehen.
Typische sinnvolle Fälle: Anwendungseinstellungen prüfen, Sicherheitskonfigurationen gegen einen Sollwert abgleichen, Altlasten aus früheren Migrationen finden. Und wenn eine Policy irgendwann gelöscht wird, bleiben die zuletzt erfassten Daten noch bis zu 28 Tage sichtbar – praktisch, wenn man erst hinterher merkt, dass man sie noch gebraucht hätte.
Enterprise-Apps, die sich selbst aktuell halten
Für Anwendungen aus dem Enterprise App Catalog lässt sich seit Service Release 2606 Auto-Update aktivieren. Erkennt Intune eine neuere Version im Katalog, wird die App auf den zugewiesenen Geräten aktualisiert – ohne neue App-Instanz, ohne Supersedence-Beziehung, ohne den ganzen Klickweg, der bisher pro Update fällig war.
Die Voraussetzungen sind eng gefasst: nur Katalog-Apps, nur Zuweisungen vom Typ Required, nur Windows 10 und 11. Apps, die als "Available for enrolled devices" ausgerollt sind, bleiben beim bisherigen Verfahren. Aktiviert wird die Option im Assistenten im Schritt "Assignments".
So verlockend das klingt – die Liste der Einschränkungen sollte man vor dem Aktivieren gelesen haben. Es gibt keine Rollout-Ringe und keine gestaffelte Verteilung: Eine neue Version geht gleichzeitig an alle Zielgeräte. Es gibt kein Rollback und keine automatische Deinstallation; muss eine Version wieder runter, ist das Handarbeit über eine Uninstall-Zuweisung oder ein Remediation-Skript. Die Katalogdaten sind bis zu einer Stunde zwischengespeichert, und selbst wenn Microsoft eine schädliche Version aus dem Katalog entfernt und im Admin Center darüber informiert, bleibt das Identifizieren und Bereinigen betroffener Geräte Aufgabe des Kunden. Dazu kommt: Das Reporting speichert nur den zuletzt gemeldeten Zustand pro Gerät, eine Versionshistorie gibt es nicht.
Mein pragmatischer Weg wäre deshalb zweigeteilt. Werkzeuge mit hoher Update-Frequenz und niedrigem Risiko – Browser, Runtimes, kleine Utilities – laufen gut im Auto-Update. Für geschäftskritische Anwendungen, bei denen ein Versionssprung Prozesse stoppen kann, bleibt Guided Update Supersedence der ruhigere Weg: Man sieht das verfügbare Update unter "Enterprise App Catalog apps with updates" und entscheidet selbst.
Wichtig für die Planung: Enterprise App Management ist kein Bestandteil der Intune-Basislizenz, sondern Teil der Microsoft Intune Suite oder als eigenständige SKU erhältlich.
Was sich in den nächsten zwei Wochen umsetzen lässt
Alle drei Funktionen lassen sich klein anfangen, und genau so würde ich sie einführen:
Sync-Status im Betrieb verankern. Prüfen, ob die neue Geräteansicht aktiv ist, und den Tab Device sync status in die Troubleshooting-Anleitung des Service Desks aufnehmen. Kostet eine halbe Stunde, spart pro Ticket ein paar Minuten Rätselraten.
Ein Registry-Profil mit klarem Zweck bauen. Nicht "alles Interessante", sondern eine konkrete Frage – etwa: Welche Geräte tragen noch die alte Konfiguration aus dem letzten Rollout? Zuweisen, 24 Stunden warten, Ergebnis in Device Inventory ansehen. Erst danach erweitern.
Auto-Update an einer unkritischen App testen. Eine Pilotgruppe, eine App, ein Update abwarten. Parallel festlegen, welche Anwendungen bewusst beim geführten Supersedence-Verfahren bleiben.
Berechtigungen nachziehen. Wer darf Inventardaten sehen? Diese Frage wird mit Registry-Inventar wichtiger, als sie es vorher war.
Fazit
Die neuen Intune-Features lösen keine großen Architekturprobleme. Sie nehmen dem Alltag drei kleine Reibungspunkte: das blinde Warten nach einem Sync, den Skript-Umweg für ein paar Registry-Werte und die manuelle Update-Pflege bei Katalog-Apps.
Was dabei bleibt, ist die Verantwortung für die Entscheidung: Auto-Update ohne Ringe ist ein Tempo-gegen-Kontrolle-Tausch, und ein Registry-Inventar ist immer auch eine Frage danach, wer diese Daten sehen darf. Wer beides bewusst beantwortet, bekommt drei Funktionen, die einfach Arbeit abnehmen.
Sie möchten wissen, was davon in Ihrer Umgebung sinnvoll ist und wie sich der Rollout sauber vorbereiten lässt? Sprechen Sie uns an – wir schauen uns Ihren Intune-Tenant gemeinsam an.