Microsoft erweitert das Intune-Geräteinventar um definierbare Windows-Registry-Schlüssel und -Werte unter HKLM. Administratoren können die gesammelten Daten abfragen, ohne für jede Fragestellung ein Remediation-Skript zu bauen. Das wirkt wie eine Komfortfunktion, verändert aber den Umgang mit Endpoint-Nachweisen: Lesende Konfigurationsprüfung kann zur verwalteten Inventarfunktion werden.
Bedeutung für den Betrieb
Der Nutzen ist dort am größten, wo dieselben engen Fragen wiederkehren: Hat ein Security-Produkt den erwarteten Versionswert geschrieben? Welcher Anwendungsmodus ist gesetzt? Bleibt ein Migrationsflag aktiv? Welche Geräte tragen noch eine Altkomponente? Solche Prüfungen benötigen keine Reparaturrechte. Als Inventar ausgeführt, reduzieren sie Code, Ausführungsrisiko und die Zeit bis zu einer belastbaren Geräteliste.
Zentrale Erfassung braucht trotzdem Grenzen. Registry-Daten können Kennungen, Pfade, Produktdetails und betriebliche Informationen enthalten, die nicht ohne Zweck gesammelt werden sollten. Vor dem breiten Rollout gehören freigegebene Schlüssel, Aufbewahrung, Zugriffsrollen und Benennung festgelegt. Wer wild sammelt, erzeugt einen unkontrollierten Datenbestand und schwächt das Vertrauen in spätere Abfragen.
Ein guter Pilot wählt wenige stabile HKLM-Werte mit bekannter fachlicher Bedeutung, vergleicht Intune-Ergebnisse mit einer verlässlichen Stichprobe und dokumentiert fehlende Schlüssel, Typabweichungen, veraltete Geräte sowie 32- und 64-Bit-Pfade. Das Ergebnis sollte eine Entscheidung wie Anwendungsablösung oder Compliance-Nacharbeit unterstützen und nicht nur ein weiteres Dashboard füllen.
Praktische Konsequenz
Die praktische Konsequenz: Intune Registry Inventory sollte lesende Skripte abbauen und nicht deren Wildwuchs in einer neuen Oberfläche nachbauen. Ausgangspunkt sind konkrete Fragen und die minimal nötigen Werte. Die Funktion sammelt Daten; der betriebliche Wert entsteht durch den sicheren Weg von Konfigurationsunsicherheit zu einer verantworteten Maßnahme.