WMI-Scripting

Namensbereiche, Klassen, Methoden

WMI kann aber auch genutzt werden, um mehr über WMI zu erfahren. Ein wichtiges Konzept bei WMI sind die so genannten Namespaces. Ein Namespace definiert einen Bereich von Informationen. In der Regel wird mit dem Namespace CIMv2 gearbeitet. CIM steht dabei für Common Information Model, eine standardisierte Struktur für die Bereitstellung von Informationen über Computer. Neben diesem Namensbereich gibt es aber bei WMI etliche weitere Namensbereiche, die sich über ein einfaches Skript ermitteln lassen.

Das Skript ist sehr einfach und erfragt nur die verschiedenen Einträge für die Namespaces unterhalb von root. Die Länge der Liste (Bild 6) variiert in Abhängigkeit der installierten WMI-Provider (und damit Anwendungen) und des Betriebssystems.

Listing 9: Skript für die Ermittlung der Namensbereiche (Quelle:
Microsoft)
strComputer = "."
Set objServices = GetObject("winmgmts:\\" & strComputer & "\root")
Set colNameSpaces = objServices.InstancesOf("__NAMESPACE")
For Each objNameSpace In colNameSpaces
WScript.Echo objNameSpace.Name
Next

Da die einzelnen Namespaces wiederum hierarchisch organisiert sind, kann man auch noch die untergeordneten Bereiche ermitteln. Das bringt aber nicht so viel Erkenntnisgewinn. Reizvoller ist die Abfrage der Klassen, die es in Namespaces gibt. Auch hier handelt es sich wieder um ein Skript, das unbedingt über cscript.exe ausgeführt werden oder seine Ergebnisse in eine Datei schreiben sollte, da die ermittelten Informationen recht umfangreich sind. Listing 10 zeigt ein Beispiel für ein solches Skript.

Listing 10: Skript für die Ausgabe aller Klassen in einem
Namespace
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colClasses = objWMIService.SubclassesOf()
For Each objClass In colClasses
WScript.Echo objClass.Path_.Path
Next

Ebenso können über Skripts auch die Methoden und Eigenschaften von Klassen ermittelt werden. In der Regel macht es aber mehr Sinn, die Dokumentation zu WMI zu verwenden, in der alle diese Informationen bereits enthalten sind. Die URL wurde bereits weiter oben in diesem Artikel genannt.

Asynchrone und synchrone Zugriffe

Bei WMI-Abfragen wird zwischen asynchronen und synchronen Zugriffen unterschieden. Eine synchrone Abfrage behält die Kontrolle über die Anwendung, solange die Abfrage ausgeführt wird. Das bedeutet, dass die weiteren Verarbeitungsschritte erst ausgeführt werden können, wenn die Abfrage vollständig bearbeitet wurde – was unter Umständen sehr lange dauern kann, wenn man beispielsweise Ereignisse aus dem Ereignisprotokoll ausliest. Dafür ist die Verwendung solcher Abfragen sehr einfach.

Die meisten Methoden, die nicht explizit asynchron arbeiten, nutzen aber einen so genannten semisynchronen Modus. In diesem läuft die Anwendung weiter, während noch Informationen ermittelt werden. Diese werden jeweils an die weiteren Elemente der Anwendung übergeben. Allerdings kann das bei sehr großen Abfragen zu Lastproblemen führen. Zu den Methoden, die automatisch semisynchron ausgeführt werden, gehören ExecQuery und InstancesOf, also die in den Beispielen üblicherweise verwendeten Methoden.

Das wird beispielsweise beim Auslesen von Daten aus dem Ereignisprotokoll deutlich. Dort werden nicht erst alle Ereigniseinträge ausgelesen. Die Anzeige der Einträge beginnt vielmehr unmittelbar, während im Hintergrund weiter Daten aus dem Ereignisprotokoll gelesen werden. Daher muss man sich in den meisten Fällen auch nicht darum kümmern, ob nun synchron oder asynchron gearbeitet wird. Die automatische semisynchrone Verarbeitung löst die meisten Probleme. Nur die drei Methoden

• Delete

• ExecMethod

• Get

sind generell synchron. Von den ersten beiden Methoden gibt es aber mit DeleteAsync und Exec MethodAsync auch asynchrone Varianten, ebenso wie mit ExecQueryAsync oder InstancesOf-Async.

Falls explizit eine asynchrone Verarbeitung bevorzugt wird, steigt der Programmieraufwand stark an. In diesem Fall kommt ein so genannter Sink zum Einsatz, in dem die Ergebnisse der Verarbeitung geschrieben werden, während das Programm weiter ausgeführt wird. Die asynchronen Methoden erzeugen Ereignisse, die wiederum über Subroutinen im Skript abgefangen werden müssen. Dazu zählt beispielsweise onCompleted mit Informationen zur Ausführung der asynchronen Methode.

Asynchrone Methoden sollten nur verwendet werden, wenn die Abfragen so komplex sind, dass die Ausführung der Skripts mit semisynchronen Methoden in der Praxis zu Fehlern führt. Das ist aber nur selten der Fall. Umfassende Informationen zur Verwendung von asynchronen Aufrufen finden sich unter

http://msdn.microsoft.com/library/enus/wmisdk/wmi/making_an_asynchronous_call_with_vbscri
pt.asp

Dort wird schrittweise erläutert, wie asynchrone Aufrufe unter Verwendung von VBscript durchgeführt werden können.

Die Serie hat verschiedene Aspekte zu WMI vorgestellt. Dabei wurde auch deutlich, dass WMI eine der mächtigsten Entwicklungsschnittstellen von Windows ist, die in sehr großem Umfang über Skripts genutzt werden kann. Die Beispiele erschließen dabei nur die Grundlagen von WMI, auf denen eigene Anwendungen aufbauen können.

In zukünftigen Ausgaben von Expert’s inside Windows NT/2000 werden weitere Beispiele vorgestellt, mit denen konkrete Herausforderungen im Systemmanagement mit Hilfe von Skripts gelöst werden. Dabei werden noch mehr Details zu WMI auf der einen Seite und VBscript auf der anderen Seite vorgestellt werden. Zu den Themen, die dabei besprochen werden, zählen unter anderem erweiterte Funktionen für die Eingabe von Informationen.

Vorschläge für Skripts erwünscht
Um die weiteren Beiträge zu diesem Thema möglichst praxisgerecht gestalten zu können, können Sie einerseits Vorschläge für Problemstellungen, die mit Skripts gelöst werden sollen, und andererseits fertige
Skripts an den Autor mailen, die dann im Rahmen von Artikeln – natürlich unter Nennung des Erstellers des Skripts – vorgestellt werden. Die E-Mail-Adresse ist martin@kuppinger.de.