PowerShell und WMI, Teil 2

Die Basis

Wenn man mit den Grundkonzepten von WMI vertraut ist, also ein gewisses Gefühl für die Klassen und die Namespaces gewonnen hat, dann ist die Umstellung von VBScript zu PowerShell in der WMI-Programmierung nicht allzu schwierig. Um sich erst einmal eine Liste von WMI-Klassen anzeigen zu lassen, verwendet man den Befehl

get-wmiobject –list

Die dabei erzeugte Liste (Bild 1) ist allerdings ausgesprochen lang und unübersichtlich. Daher bietet es sich an, hier gleich ein bisschen zu filtern.

Bild 1: Die Ausgabe einer Liste der WMI-Objekte, die mit der PowerShell genutzt werden können.
Bild 1: Die Ausgabe einer Liste der WMI-Objekte, die mit der PowerShell genutzt werden können.

So kann man sich beispielsweise auf die Win32- Provider innerhalb von WMI beschränken, die ja besonders häufig verwendet werden. Ein Ansatz für diese Filterung wäre

get-wmiobject –list | where {$_.Name –like "Win32*"}

Spätestens hier wird der Reiz von WMI deutlich: Durch das Piping der Ausgabe der Liste als Eingabe für die Where-Bedingung kann man mit sehr geringem Aufwand Informationen filtern.

Bild 2: Eine gefilterte Liste mit der Ausgabe nur noch einzelner Klassen von WMI.
Bild 2: Eine gefilterte Liste mit der Ausgabe nur noch einzelner Klassen von WMI.

Daneben gibt es, wie in den bisher erschienenen Artikeln rund um WMI bereits gezeigt, noch etliche andere Ansätze, um eine Weiterverarbeitung von Ausgaben durchzuführen. Auch in diesem Artikel werden noch andere Varianten vorgestellt. Da man beim Operator –like auch zwei Wildcards einsetzen kann, lässt sich auch nach dem Text innerhalb einer Zeichenkette suchen. Man könnte also beispielsweise mit

get-wmiobject –list | where {$_.Name –like"*Process*"}

auch eine Liste von WMI-Klassen erzeugen, in denen die Zeichenkette Process enthalten ist. Das dürften alle Klassen sein, die man für die Überwachung von Prozessen in der einen oder anderen Form verwenden kann. Diese Liste ist übrigens schon recht übersichtlich, wie man in Bild 2 erkennen kann.