SearchNetworking PowerShell-Corner

Installierte Software, Updates und Service Packs mit der PowerShell ermitteln

Update- und Service-Pack-Management plus Überprüfung installierter Software: die PowerShell macht‘s möglich

In dieser Ausgabe des PowerShell-Corners geht SearchNetworking der Frage nach, wie installierte Softwareprodukte mithilfe der Microsoft PowerShell ganz einfach ermittelt werden können. Zudem werden so auch installierte Service Packs und Windows-Updates aufgelistet.

SearchNetworking zeigt deren Einsatz bei der Ermittlung installierter Softwareprodukte, Service Packs und Windows-Updates.

1. Softwareprodukte

Die Ermittlung der installierten Softwareprodukte kann über die WMI-Klasse Win32_Product vorgenommen werden. Diese enthält unter anderem die Eigenschaften Name, Version, Vendor, InstallDate und PackageName. Das PowerShell-Cmdlet get-wmiobject liefert die Objekte dieser WMI-Klasse zurück.

• get-wmiobject -class Win32_Product

An dieser Stelle gleich ein Hinweis an Windows Vista-Anwender. Unter Vista wird hier bei der Abfrage der Klasse Win32_Product ein allgemeiner Fehler ausgegeben. Dabei handelt es sich um einen Fehler, der mit dem Service Pack 1 für Windows Vista verschwinden soll.

Wurde der Standardnamensraum geändert, muss der Namensraum „root\CIMV2“ bei der Abfrage mit angegeben werden.

• get-wmiobject -class Win32_Product -namespace „root\CIMV2“

Das Cmdlet get-wmiobject ist auch in der Lage, die Abfrage auf einem Computer im Netzwerk auszuführen. Dazu wird der Parameter „computername“ entsprechend gesetzt.

• get-wmiobject -class Win32_Product -computername London

Es ist nicht erforderlich, auf dem angegebenen Computer die PowerShell zu installieren, nur WMI muss installiert und geeignet konfiguriert sein. Soll die Abfrage unter einem anderen Benutzerkontext ausgeführt werden, kann dieser über den Parameter „credential“ angegeben werden. Allerdings nicht im Klartext, sondern über ein spezielles Credential-Objekt, das wiederum über das Cmdlet get-credential angelegt werden kann.

• $cred = get-credential

• get-wmiobject -class Win32_Product -computername London -credential $cred

Bei diesem Beispiel wird der Anwender zur Eingabe eines Benutzernamens samt zugehörigem Kennwort aufgefordert. Seine Angaben werden in der Variable $c gespeichert und für die WMI-Abfrage eingesetzt.

Wie so häufig zeigt die PowerShell bei der Ausgabe der Objekte nur eine Auswahl der Eigenschaften an. Sollen alle ausgegeben werden, hilft ein select-object.

• get-wmiobject -class Win32_Product | select-object -property *

Sollen nur die Softwareprodukte eines bestimmten Herstellers angezeigt werden, kann in klassischer PowerShell-Manier über das Cmdlet where-object ein Filter eingesetzt werden. Das folgende Beispiel zeigt nur Produkte der Microsoft Corporation. Dazu wird die Eigenschaft Vendor der Win32_Product-Klasse entsprechend verglichen.

• get-wmiobject -class Win32_Product | where-object { $_.Vendor –eq „Microsoft Corporation“ }

Diese Abfrage kann aber auch direkt über get-wmiobject mit dem Parameter „filter“ durchgeführt werden. Diese Variante ist bei vielen zurückzugebenden Objekten schneller, da nicht alle Objekte über die Pipeline verarbeitet werden müssen und die Filterung schon von WMI vorgenommen wird.

• get-wmiobject -class Win32_Product -filter „Vendor=‘Microsoft Corporation‘“

2. Service Pack

Der bisher dargestellte Vorgang kommt auch bei der Ermittlung des installierten SPs zum Einsatz. Allerdings wird nicht mehr die Klasse Win32_Product abgefragt, sondern Win32_QuickFixEngineering. Da mit dieser Klasse auch andere Hotfixes verwaltet werden, ist eine Abfrage der Eigenschaft FixComments auf den Wert „Service Pack“ erforderlich.

• get- wmiobject -class Win32_QuickFixEngineering -filter „FixComments=‘Service Pack‘“

Von besonderem Interesse sind die Eigenschaften Description (Bezeichnung des Service Packs), InstalledBy und InstalledOn (Installationsdatum).

3. Windows-Updates

Die letzte Aufgabe besteht in der Ermittlung der installierten Windows-Updates. Dazu wird diesmal keine WMI-Klasse abgefragt, sondern es kommt die so genannte WUA API (Windows Update Agent Application Program Interface) zum Einsatz. Diese bietet über eine COM-Schnittstelle Zugriff auf den Windows-Update-Mechanismus und kann etwa zur Konfiguration oder auch zum Start des Update-Vorgangs benutzt werden. Auch in unserem Fall hilft sie bei der Auflistung der Windows-Updates.

Zuerst wird das benötigte COM-Objekt erstellt.

• $session = new-object -comobject „Microsoft.Update.Session“

Dieses Objekt bietet eine Suchfunktion, die auch zum einfachen Ermitteln aller Updates eingesetzt werden kann. Für diese Suche wird ein spezielles Objekt benötigt, das die Methode CreateUpdateSearcher liefert.

• $searcher = $session.CreateUpdateSearcher()

Mit der Methode QueryHistory werden schließlich die Updates ermittelt. Die Methode benötigt den Index des ersten zurückzugebenden Updates (im gegebenen Fall 0) und die Anzahl. Die Gesamtanzahl der verfügbaren Updates kann dabei über die Methode GetTotalHistoryCount abgerufen werden. Mit diesen Vorarbeiten sieht die Abfrage wie folgt aus:

• $history = $searcher.QueryHistory(0, $searcher.GetTotalHistoryCount())

• $history

Die history-Variable enthält danach je ein beschreibendes Objekt pro Update. Besonders interessant sind hier die Eigenschaften Title, Description, Categories und Date. Diese Eigenschaften können auch zur Einschränkung des Suchergebnisses genutzt werden, etwa zur Suche nach einem bestimmten Update. Beispielsweise ist in der Eigenschaft Title bei manchen Updates die Knowledgebase-Artikel-ID angegeben, die hier genutzt werden kann.

• $history | where-object { $_.Title -like „*KB937500*“ }

Der Vergleichsoperator „like“ kann mit Wildcards, wie dem Stern, umgehen, was den Vergleich deutlich einfacher macht.