Hardware mit Endpoint Analytics erkennen

Moderne Endpoint-Landschaften bestehen aus weit mehr als nur dem Laptop selbst: Dockingstationen, externe Monitore, Headsets, USB-Peripheriegeräte und eine lange Reihe an unternehmensspezifischer Ausstattung. Microsoft Endpoint Analytics gibt dir die Grundlage, all das mit einem benutzerdefinierten Skript zur Datenerfassung zu erfassen und in Log Analytics einzuspeisen, wo du das Peripherie-Inventar mit Benutzern, Standorten und Refresh-Zyklen korrelieren kannst. Dieser Beitrag zeigt dir das Muster, das ich zur Erkennung angeschlossener Hardware verwende: einen PowerShell-Collector, der CIM-Klassen ausliest, das Ergebnis normalisiert und es in eine benutzerdefinierte Log-Analytics-Tabelle schreibt – bereit für Power BI und Beschaffungs-Reporting.

Um zu sehen, welche Geräte einen bestimmten Monitor oder eine bestimmte Tastatur verwenden, kann es sehr hilfreich sein, wenn du diese Informationen sammeln kannst. In diesem Blog zeige ich dir, wie du das mit Hilfe von Endpoint Analytics machst. Diese Informationen kannst du anschließend nutzen, um diesen Geräten einen Treiber zuzuweisen oder einen Hardware-Austausch auszulösen. Wie du auf Basis der Ausgabe eines Endpoint-Analytics-Skripts automatisch eine Gruppe befüllen kannst, habe ich in Microsoft Entra ID Gruppe basierend auf lokalen Attributen erstellen und befüllen erklärt.

Wie du die Hardware-ID ermittelst

Führe den folgenden Befehl in einer PowerShell-Sitzung aus

Get-PnpDevice | Format-List

Suche die Hardware, die du erfassen möchtest, und kopiere die DeviceID:

Trage die DeviceId oder mehrere DeviceIds in das Array im PowerShell-Skript aus meinem GitHub-Repository ein:

Ein Endpoint-Analytics-Skript zum Erfassen der Werte bereitstellen

Zuerst stellen wir ein Endpoint-Analytics-Skript auf unseren Clients bereit, um von den Clients den Rückgabewert mit dem Gerätehersteller zu erhalten.

• Öffne Endpoint Analytics
• Klicke auf + Create script package

• Gib einen Namen ein und klicke auf Next

• Lade das Detection- Skript hoch. Dieses Skript findest du in meinem GitHub-Repository.
• Klicke auf Next > Next

• Weise das Skript einer Gruppe zu
• Erstelle einen Zeitplan. In meinem Fall wähle ich täglich.
• Klicke auf Next > Create

Ergebnis

In der Ansicht Device status des Remediation-Skripts kannst du das Ergebnis sehen.

• With issues = Gerät gefunden
• Without issues = Gerät nicht gefunden

Die Ergebnisse kannst du auch über Graph abrufen:

https://graph.microsoft.com/beta/deviceManagement/deviceHealthScripts/**SCRIPT_ID**/deviceRunStates?$top=100

Tipps und häufige Fallstricke

Einige Details entscheiden darüber, ob dieses Muster im produktiven Betrieb zuverlässig bleibt. Der häufigste Fehler ist, nur auf eine einzige, sehr spezifische DeviceID zu prüfen. Hersteller liefern denselben Monitor oder dasselbe Headset oft unter mehreren Hardware-IDs aus – je nach Firmware-Stand oder Anschlussart. Eine strenge Gleichheitsprüfung übersieht dann stillschweigend die Hälfte deiner Geräte. Ich prüfe daher lieber auf einen stabilen Teilstring der Hardware-ID oder auf den Anzeigenamen des Geräts, wenn der Hersteller ihn konsistent vergibt, und halte das Match-Array kurz und gut kommentiert.

Achte außerdem auf den Ausführungskontext. Endpoint-Analytics-Remediations laufen standardmäßig im SYSTEM-Kontext. Das bedeutet, dass ein Peripheriegerät, das nur in der Sitzung des angemeldeten Benutzers sichtbar ist, möglicherweise nicht auftaucht. Bei USB-Geräten, die vom Benutzer-Logon abhängen, solltest du beide Kontexte testen, bevor du dem Inventar vertraust. Es lohnt sich zudem, das Skript täglich statt nur einmalig auszuführen: Mitarbeitende docken, undocken und tauschen ständig Peripherie, sodass eine einzelne Momentaufnahme schnell veraltet – ein täglicher Rhythmus hält deine Log-Analytics-Tabelle nah an der Realität.

Behandle die Ausgabe der Erkennung von Anfang an als strukturierte Daten. Wenn du einen sauberen, parsbaren String zurückgibst (zum Beispiel eine kommagetrennte Liste von Modellnamen), lässt sich später problemlos eine dynamische Gruppe oder ein Power-BI-Report aufbauen. Freitext hingegen zwingt dich, die Daten bei jeder Abfrage erneut zu bereinigen.

Ein letzter Tipp zur Fehlersuche: Protokolliere bei jedem Lauf zusätzlich den Rückgabe-Exitcode des Skripts. So erkennst du im Device-Status sofort, ob ein leeres Ergebnis daher kommt, dass tatsächlich keine Hardware angeschlossen war, oder ob das Skript schlicht nicht sauber durchgelaufen ist.

Wie du basierend auf diesem Wert eine Microsoft Entra ID Gruppe befüllst, findest du unter Microsoft Entra ID Gruppe basierend auf lokalen Attributen erstellen und befüllen.