Die zunächst als Nomad bezeichnete Windows PowerShell ist seit Kurzem offiziell verfügbar. Die bisherigen Versionen, die von einigen Anwendungen bereits benötigt wurden, waren also Vorversionen, auch wenn das nicht immer so ganz klar war. Mit dem offiziellen Release der Version 1.0 kann man nun aber wirklich voll in das Scripting mit der PowerShell einsteigen.
Ein besonders interessanter Teilbereich ist dabei der Umgang mit WMI (Windows Management Instrumentation), weil darüber auf viele Detailinformationen zu Hard- und Software zugegriffen werden kann. Und manche Einstellungen im System lassen sich auch direkt über WMI modifizieren. Der bisher übliche Ansatz für das Skripting von WMI ist die Verwendung von VBScript. Darauf wurde in verschiedenen Artikeln in Expert’s inside Windows NT/2000 schon detailliert eingegangen. Man kann durch Zugriff auf winmmgts und dort die entsprechenden Bereiche der WMIStrukturen Informationen auslesen. Das geht von der Liste der laufenden Prozesse über den freien Speicherplatz auf Festplatten bis hin zu Daten von Anwendungen, die über einen WMI-Provider verfügen.
|
Teil 1 |
Grundlagen zum Scripting von WMI mit der PowerShell |
|
Teil 2 |
Gründe für die PowerShell
Abgesehen von einigen Syntaxänderungen kann man dasselbe auch mit der PowerShell. Man kommt nicht an mehr Daten, es sind aber auch nicht weniger Informationen, auf die man zugreifen kann. Das wirft natürlich die Frage auf, warum man für den Zugriff auf WMI überhaupt mit der Windows PowerShell arbeiten sollte. Vielleicht arbeitet der eine oder andere ja einfach lieber mit der PowerShell. Da viele Administratoren aber mit VBScript wenigstens einigermaßen vertraut sind, während die PowerShell für die meisten Neuland ist, dürfte dieses Argument nur in den wenigsten Fällen zutreffen.
Ein viel besseres Argument ist die einfachere Verarbeitung der zurückgelieferten Daten. So werden die Ergebnisse einer WMI-Anforderung beispielsweise immer in der Sortierung nach dem Schlüsselfeld geliefert. VBScript bietet aber keine einfache Option, um Daten zu sortieren. Man könnte zwar einen der klassischen Algorithmen für die Sortierung nachprogrammieren, das ist aber allenfalls interessant, um zu testen, ob man sich noch an solche klassischen Algorithmen erinnert (falls man sie je kannte).
Leistungsfähige Mechanismen
Dagegen gibt es bei der PowerShell sehr einfache, leistungsfähige Mechanismen. Die Ergebnisse einer Abfrage müssen einfach in einer Pipe neu sortiert werden, wie das folgende Beispiel zeigt:
$strComputer = "."
$colItems = get-wmiobject -class "Win32_Process" -
namespace "root\cimv2" -computername $strComputer |
sort "WorkingSetSize"
foreach ($objItem in $colItems) {write-host $objItem.Name, $objItem.WorkingSetSize
Die erste Zeile in diesem Skript setzt zunächst den Fokus auf den lokalen Computer. Anschließend werden die Informationen abgefragt. Dabei ist insbesondere der letzte Teil wichtig:
| sort "WorkingSetSize"
nimmt die Ergebnisse aus der Abfrage und sortiert sie nach dem angegebenen Kriterium. Anschließend werden sie in diesem Fall in einer Schleife ausgegeben. Die Sortierung ist also ausgesprochen einfach – und entsprechend schlanker werden die Skripts, die man erstellen kann. Aber auch bei der Filterung und anderen Ansätzen für die Einschränkung der zurückgelieferten Daten ist die PowerShell deutlich einfacher in der Nutzung als VBScript. Es gibt also durchaus gute Gründe, den Schritt vom klassischen VBScript hin zur PowerShell zu machen.
Wie geht es weiter?
In den beiden folgenden Teilen dieser Serie werden verschiedene Beispiele für das WMI-Scripting in der PowerShell besprochen. Es werden sowohl unterschiedliche Anwendungsbereiche angesprochen als auch auch Techniken für das PowerShell-Scripting vorgestellt.