Microsoft Windows 2000 - Scripting-Handbuch (Teil 1) Scripting-Konzepte und -Technologien zur Systemadministration: Kapitel 3 - Der WSH

Veröffentlicht: 26. Apr 2004

(Engl. Originaltitel: WSH Primer)

Der Windows Script Host (WSH), ein Feature der Microsoft Windows 2000-

Familie, ist eine mächtige Scripting-Umgebung, die ideal zur Automatisierung von Administrationsaufgaben eingesetzt werden kann. Scripte, die in der WSH-Umgebung ausgeführt werden, können die umfangreichen Möglichkeiten der WSH-Objekte und anderer COM-basierter Automatisationsobjekte nutzen - zum Beispiel WMI (Windows Management Instrumentation) und ADSI (Active Directory Service Interfaces) zur Verwaltung der Windows-Subsysteme und zur Zentralisierung von Administrationsaufgaben.

Zurück zur Übersichtsseite

Auf dieser Seite	Links zu verwandten Themen
WSH-Übersicht Die WSH-Architektur Komponenten der WSH-Umgebung Zusammenarbeit der einzelnen Komponenten der WSH-Umgebung Das WSH-Objektmodell WSH-Script ausführen WSH-Objekte Das Objekt WScript Das Objekt WshShell Das Objekt WshNetwork Das Objekt WshController Absichern von Scripten Signieren von Scripten Die Ausführung von Scripten einschränken	Engl. Originalversion dieses Artikels
	Artikel im PDF-Format sas_wsh_overview.pdf PDF-Datei Adobe Acrobat Reader downloaden

Der Windows Script Host (WSH), ein Feature der Microsoft® Windows® 2000-Familie, ist eine mächtige Scripting-Umgebung, die ideal zur Automatisierung von Administrationsaufgaben eingesetzt werden kann. Scripte, die in der WSH-Umgebung ausgeführt werden, können die umfangreichen Möglichkeiten der WSH-Objekte und anderer COM-basierter Automatisationsobjekte nutzen - zum Beispiel WMI (Windows Management Instrumentation) und ADSI (Active Directory Service Interfaces) zur Verwaltung der Windows-Subsysteme und zur Zentralisierung von Administrationsaufgaben.

WSH-Übersicht

Die meisten Leute, die sich zum ersten Mal mit dem Windows Script Host (WSH) beschäftigen, sind leicht irritiert. Was genau ist WSH? Handelt es sich um eine Sprache wie VBScript oder JScript? Nein - auch wenn der WSH das Ausführen von Programmen ermöglicht, die in einer dieser Sprachen geschrieben wurden. Handelt es sich um ein Objektmodell wie WMI oder ADSI? Nein - der WSH stellt zwar ein einfaches Objektmodell zur Verfügung, aber ist nicht seine primäre Aufgabe.

Was ist also der WSH? Wie der Name schon sagt, ist der WSH ein Script Host. Ein Script Host ist ein Programm, dass eine Umgebung zur Verfügung stellt, in der ein Benutzer Scripte ausführen kann. Diese Scripte können durchaus in unterschiedlichen Sprachen geschrieben sein.

Wahrscheinlich haben Sie bereits andere Script Hosts verwendet. Zum Beispiel Microsoft® Internet Explorer - dieser Script Host führt Scripte aus, die das Dynamic-HTML-Objektmodell verwenden. Oder Shell-Programme (zum Beispiel C Shell, Bourne Shell und Korn Shell) - auch sie ermöglichen es Ihnen Scripte zu schreiben. Auch jede Eingabeaufforderung können Sie sich als Script Host vorstellen. Sie ermöglicht es Ihnen schließlich Script auszuführen, die in der "Batchsprache" geschrieben sind.

Der WSH ist ein eher ungewöhnlicher Script Host. Im Gegensatz zu den oben erwähnten Script Hosts ist der WSH nicht auf eine bestimmte Scriptsprache oder auf bestimmte Objektmodelle eingeschränkt.

Die Funktionalität des WSH kann man in vier Hauptbereiche unterteilen. Diese Bereiche werden im Rest des Kapitels ausführlich besprochen.

• Die standardmäßige Fähigkeit, Administrationsaufgaben durchzuführen.
• Die Fähigkeit, COM-Objekte zu verwenden.
• Die Fähigkeit, Standard-Programmierungsfeatures einer WSH-kompatiblen Scriptsprache zu nutzen.
• Die Fähigkeit, Kommandozeilentools zu verwenden.

Standardmäßige Durchführung von Administrationsaufgaben

Der WSH ist primär eine Laufzeitumgebung für Scripte. Er stellt eine Umgebung zur Verfügung, in der Scripte ausgeführt werden können - ganz ähnlich wie ein Befehlsinterpreter (zum Beispiel cmd.exe oder command.com), über den Batchdateien ausgeführt werden können.

Auch wenn der WSH primär als 'Container' zur Verwendung anderer Scriptsprachen oder -technologien dient, ist es doch möglich, "reine" WSH-Scripte zu nutzen. Mit dem WSH können Sie zum Beispiel Netzlaufwerke und Drucker verbinden. Das folgende zweizeilige Script ordnet zum Beispiel den Laufwerksbuchstaben X zur Freigabe \\atl-fs-01\public zu:

Set objNetwork = Wscript.CreateObject("WScript.Network")
objNetwork.MapNetworkDrive "X:", "\\atl-fs-01\public"

Verwendung von COM-Objekten

Wie Sie nun wissen, können Sie den WSH zum Zuordnen von Netzlaufwerken verwenden. Leider gibt es außer dieser Möglichkeit wenig, was Sie noch über den WSH alleine durchführen können. Sie können über den WSH nicht die Hardware eines Computers abfragen oder feststellen, welche Software installiert ist.

Auch wenn der WSH selbst keine dieser Möglichkeiten zur Verfügung stellt, können Sie sie trotzdem in einem WSH-Script nutzen. Mit dem WSH können Sie nämlich COM-Objekte (Component Object Model) in Ihren Scripten verwenden.

Ein COM-Objekt ist eine Möglichkeit für Anwendungen (.exe) oder Programmbibliotheken (.dll) Ihre Funktionen zur Verfügung zu stellen. Der WSH kann diese Funktionen dann verwenden, indem er diese Objekte in das Script einbindet.

Der WSH stellt zum Beispiel keine Methoden zur Verwaltung von Diensten zur Verfügung. WMI bietet jedoch solche Möglichkeiten (WMI ist eigentlich eine Sammlung von COM-Objekten). Mit WMI können Sie die Eigenschaften von Diensten abfragen, Dienste anhalten und starten und die Diensteinstellungen konfigurieren. Statt also eigene Methoden zur Verwaltung von Diensten zur Verfügung zu stellen, verwendet der WSH einfach die von WMI.

Der WSH kann jedes COM-Objekt nutzen, das eine Automatisation unterstützt (Automatisation ist ein Standardverfahren, um auf COM-Objekte zuzugreifen). Auf den meisten Computern steht eine riesige Menge an Automatisationsobjekten zur Verfügung. Der WSH kann so nahezu jede beliebige Aufgabe ausführen - vom Festlegen von Datenträgerkontingenten bis zur Active Directory-Verwaltung.

Das folgende WSH-Script verwendet zum Beispiel ADSI, um ein Benutzerkonto in Active Directory zu erstellen:

Set objOU = Wscript.GetObject("LDAP://OU=management,dc=fabrikam,dc=com")
Set objUser = objOU.Create("User", "cn=MyerKen")
objUser.Put "sAMAccountName", "myerken"
objUser.SetInfo

Nutzung von Standard-Programmierungsfeatures einer WSH-kompatiblen Scriptsprache

Der Verwendungszweck von Anwendungen und wie diese Anwendungen verwendet werden ist oft sehr unterschiedlich. Der Windows-Taschenrechner hat zum Beispiel nur wenig Ähnlichkeit mit Ipconfig.exe - beide haben wiederum wenig mit Microsoft® Word gemeinsam. Abgesehen von diesen Unterschieden gibt es jedoch einige grundlegende Eigenschaften, die sich diese Anwendungen teilen. Viele Anwendungen geben etwas aus und nehmen Benutzereingaben entgegen. Viele Anwendungen können Lese- und Schreiboperationen in der Registrierung durchführen. Viele Anwendungen können mit Kommandozeilenparametern gestartet werden - sogar viele grafische Anwendungen. Wenn Microsoft Word zum Beispiel mit dem Schalter /n gestartet wird, dann wird gleich ein leeres Dokument geöffnet:

winword.exe /n

Diese Standardfunktionalitäten werden auch für administrative Scripte benötigt. Was würde Ihnen zum Beispiel ein Script nützen, das keine Informationen anzeigen kann? Viele dieser Funktionalitäten stellt Ihnen der WSH zur Verfügung. Er kann Informationen ausgeben und Eingaben entgegennehmen, Lese- und Schreiboperationen in der Registrierung durchführen und Kommandozeilenparameter entgegennehmen.

Stellen wir uns vor, Sie benötigen ein Script, das einen Ordner löscht. Wenn Sie das Script starten, können Sie den Ordnernamen als Parameter angeben:

deletefolder.vbs c:\scripts

Das Löschen des Ordners können Sie über das Objekt FileSystemObject durchführen. Das Script selbst schreiben Sie mit VBScript. Aber wie verarbeiten Sie die Kommandozeilenparameter? Werder das FileSystemObject noch VBScript können diese Parameter verarbeiten.

Glücklicherweise ist der WSH dazu in der Lage. Das folgende Script verwende drei unterschiedliche Technologien:

• In Zeile 1 wird VBScript verwendet, um eine neue Instanz des Objektes FileSystemObject zu erstellen.
• In Zeile 2 wird der WSH verwendet, um die Kommandozeilenparameter einzulesen und diese einer Variable zuzuweisen.
• In Zeile 3 wird das Objekt FileSystemObject zum Löschen des angegebenen Ordners verwendet.

Set objFSO = Wscript.CreateObject("Scripting.FileSystemObject")
strFolder = Wscript.Arguments.Item(0)
objFSO.DeleteFolder(strFolder)

Das gleiche Script können Sie über Jscript, PythonScript oder eine andere WSH-kompatible Scriptsprache implementieren. Es ist völlig egal, ob die gewählte Sprache die Verarbeitung von Kommandozeilenparametern unterstützt, da der WSH ja diese Funktionalität zur Verfügung stellt.

Verwendung von Kommandozeilentools

Sie brauchen den WSH nicht wirklich, um Kommandozeilentools auszuführen. Sie können ganz einfach in einer Eingabeaufforderung oder über eine Batchdatei gestartet werden. Der WSH ist jedoch dann ziemlich nützlich, wenn Sie die Tools oder Batchdateien mit etwas "Intelligenz" ausstatten möchten. Stellen Sie sich zum Beispiel vor, Sie möchten eine Netzwerkfreigabe nur dann zuordnen, wenn der Benutzer sich in einer bestimmten Domäne (zum Beispiel "fabricam") anmeldet - andernfalls soll nichts passieren.

Ist das über eine Batchdatei möglich? Ja, ist es - es ist jedoch ziemlich kompliziert. In einem Script können Sie diese Aufgabe im Gegensatz dazu über die folgenden sechs Zeilen erledigen:

Set objNetwork = Wscript.CreateObject("Wscript.Network")
Set objShell = WScript.CreateObject("WScript.Shell")
strDomain = objNetwork.DomainName
If strDomain = "fabrikam" Then
    objShell.Run "net use x: \\atl-fs-01"
End If

WSH vs. Cmd.exe

An dieser Stelle könnte es ganz nützlich sein, den WSH und Cmd.exe (der Kommandozeileninterpreter von Windows) zu vergleichen. Beide sind Scripting-Umgebungen: Der WSH ermöglicht das Ausführen von WSH-Scripten und Cmd.exe ermöglicht das Ausführen von Batchdateien (manchmal auch Shellscripte genannt). Sowohl WSH als auch Cmd.exe benötigen eine Scriptsprache und entsprechende Werkzeuge. Es ist schwierig, Scripte nur mit dem WSH zu schreiben und es ist genauso schwierig, Batchdateien nur mit der Shellsprache zu schreiben.

Hier treten nun die Unterschiede beider Umgebung zu tage. Während der WSH Ihnen den Zugriff auf eine große Zahl an ausgereiften Scriptsprachen ermöglicht, sind Sie mit Cmd.exe auf die einfache Shellsprache eingeschränkt. Die einzigen Tools, die Sie mit Cmd.exe verwenden können, sind Kommandozeilentools. Der WSH bietet Ihnen nicht nur einen Zugriff auf dieselben Tools, sondern Sie sind zusätzlich in der Lage, Automatisationsobjekte zu verwenden.

Soll das heißen, Sie sollen alle Kommandozeilentools und Batchdateien wegwerfen und alles nur noch über WSH-Script durchführen? Natürlich nicht - wenn Sie bereits über eine funktionierende Lösung verfügen, dann gibt es keinen Grund, diese nicht weiter zu verwenden. Der WSH ist jedoch eine hervorragende Lösung für die Probleme, die Sie mit Batchdateien und Kommandozeilentools nicht lösen können.

Ein Hinweise zu WSH-Versionen

Die Beispielscripte in diesem Kapitel wurden mit der WSH-Version 5.6 entwickelt und getestet. Einige der beschriebenen Funktionalitäten stehen auch nur unter Version 5.6 oder höher zu Verfügung. Daher sollten Sie prüfen, welche WSH-Version bei Ihnen installiert ist und diese im Zweifelsfall auf Version 5.6 aktualisieren.

Anmerkung:
Aufgrund der nützlichen zusätzlichen Funktionalitäten sollten Sie den WSH auf jeden Fall auf Version 5.6 aktualisieren - egal, ob Sie die Scripte in diesem Kapitel ausführen möchten oder nicht.

Um die installierte WSH-Version abzufragen, geben Sie in einer Eingabeaufforderung einfach cscript ein und drücken die Eingabetaste. Wenn Sie Version 5.6 installiert haben, dann sollten Sie die folgende Ausgabe sehen:

C:\WINDOWS>cscript
Microsoft (R) Windows Script Host, Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten. 
Die gleichen Informationen können Sie auch mit Hilfe eines Scripts abrufen:
Wscript.Echo Wscript.Version

Die gleichen Informationen können Sie auch mit Hilfe eines Scripts abrufen:

Wscript.Echo Wscript.Version

Zum Seitenanfang

Die WSH-Architektur

Wenn Sie Auto fahren lernen, müssen Sie nicht erst eine Ausbildung als Kfz-Mechaniker machen. Wenn Sie zwischen Gas- und Bremspedal unterscheiden können und verstehen, wie das Lenkrad funktioniert, dann sind Sie wahrscheinlich auch in der Lage von A nach B zu fahren.

Wenn wir davon ausgehen, dass Sie nie wieder mit einem Auto fahren, nachdem Sie an Punkt B angekommen sind, reicht dieses Wissen sicher auch aus. Was ist jedoch, wenn Sie regelmäßig fahren möchten? In diesem Fall könnte es recht nützlich sein, wenn Sie etwas darüber wissen, wie ein Auto funktioniert - und warum es möglicherweise nicht funktioniert. Sie sollten wissen, dass ein Auto Benzin benötigt, dass in die Reifen Luft gehört und dass Batterien leer werden können. Wenn Sie diese grundlegenden Informationen nicht kennen, dann werden Sie möglicherweise einige unangenehme Überraschungen erleben.

Das gleiche gilt für Scripting. Wenn Sie nur ein Script benötigen, um den Warndienst auf dem lokalen Computer anzuhalten, dann benötigen Sie dieses Buch nicht. Stattdessen können Sie sich folgendes Script kopieren:

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colServices = objWMIService.ExecQuery _
    ("SELECT * FROM Win32_Service WHERE Name = 'Alerter'")
For Each objService in colServices
    errReturnCode = objService.StopService()
Next

Was passiert aber, wenn Sie einen anderen Dienst anhalten möchten? Oder wenn Sie einen Dienst auf einem Remotecomputer anhalten möchten? Was, wenn Sie den Warndienst starten möchten? Wenn Sie bestehende Scripte verändern oder eigene Scripte entwickeln möchten, dann müssen Sie auch wissen, wie diese Scripte arbeiten - und für dieses Verständnis sind Grundkenntnisse der WSH-Architektur unerlässlich.

Zum Seitenanfang

Komponenten der WSH-Umgebung

Die Architektur des WSH ist modular aufgebaut. Sie setzt sich aus Einzelteilen zusammen, die jeweils für bestimmte Funktionalitäten verantwortlich sind. Diese Modularität führt zu zwei Vorteilen: Der WSH unterstützt verschiedene Scriptsprachen und kann COM-Objekte verwenden.

In Abbildung 3.1 sehen Sie die Hauptkomponenten der WSH-Umgebung und wie diese miteinander in Verbindung stehen (Scriptdateien, Script Host, Scripting Language Engines und COM-Objekte). Die Komponenten im dunklen Kasten werden mit der Installation von WSH 5.6 eingerichtet. Im Rest dieses Kapitels werden die einzelnen Komponenten genauer besprochen.

Abbildung 3.1: Hauptkomponenten der WSH-Umgebung

Scriptdateien

WSH-Scriptdateien (meist einfach als Script bezeichnet) sind einfache Textdateien mit Scriptbefehlen ("Textdatei" bedeutet in diesem Fall, dass keine Zeichen mit speziellen Formatierungen verwendet werden). Das folgende Script wird zum Beispiel fehlschlagen, da es typografische Anführungszeichen enthält (das Anführungszeichen ist unten statt oben):

Wscript.Echo "This line is correct."
Wscript.Echo „This line is incorrect."

Da viele Textverarbeitungsprogramme standardmäßig solche Zeichen verwenden, stellen sie nicht unbedingt die beste Script-Entwicklungsumgebung dar. Texteditoren werden hingegen für die Arbeit mit normalen Textdateien entwickelt (zum Beispiel Notepad.exe) - daher sollten Sie Ihre Scripte mit einem Texteditor schreiben.

Anmerkung:
Sie sollten es auch vermeiden, Scripte mit einer Textverarbeitung zu erstellen und diese dann in einen Texteditor zu kopieren. Es gibt keine Garantie dafür, dass bei diesem Kopiervorgang tatsächlich nur unformatierter Text eingefügt wird. Probleme durch formatierten Text sind oft schwer zu finden, da ein Zeichen möglicherweise nur unformatiert aussieht.

Das Script kann in jeder Scriptsprache geschrieben werden, für die eine entsprechende Scripting Language Engine installiert ist. Sie sollten die Datei mit der Dateierweiterung speichern, die der Scriptsprache zugeordnet ist. In Tabelle 3.1 sehen Sie drei Beispiele zu Scriptsprachen und deren Dateierweiterungen.

Tabelle 3.1: Dateierweiterungen von Scripten

Dateierweiterung	Beispiel-Dateiname	Scriptsprache
.VBS	EnumPrinters.vbs	VBScript
.JS	EnumProcesses.js	JScript
.PLS	EnumDisks.pls	PerlScript

Wenn Sie ein Script mit VBScript schreiben, dann sollten Sie das Script also mit der Dateierweiterung .vbs speichern.

Anmerkung:
Es auch dann möglich ein Script auszuführen, wenn Sie nicht die Standard-Dateierweiterung verwendet haben. Weitere Informationen hierzu erhalten Sie später in diesem Kapitel.

Nachdem Sie das Script in Notepad eingegeben und gespeichert haben, können Sie es ausführen. Ein Vorteil von Scripting ist hierbei: Sie müssen das Script nicht erst kompilieren oder weitere Dateien erstellen. Stattdessen starten Sie es im einfachsten Fall mit einem Doppelklick. Geben Sie zum Beispiel die beiden folgenden Zeilen in Notepad ein:

Set objNetwork = Wscript.CreateObject("Wscript.Network")
Wscript.Echo objNetwork.ComputerName

Speichern Sie die Datei mit der Dateiendung .vbs, und Sie haben ein Script erstellt, das Ihnen den Namen des lokalen Computers zurückgibt.

Script Hosts

Der Script Host initiiert und koordiniert die Ausführung Ihres Scripts. Er liest die Scriptdatei ein und interagiert mit den Komponenten der WSH-Umgebung und den COM-Objekten. Außerdem stellt er fest, welche Scriptsprache er bei der Ausführung des Scripts verwenden muss. Wenn das Script zum Beispiel die Dateierweiterung .vbs verwendet, dann lädt der Script Host die VBScript Language Engine, und arbeitet dann mit dieser den Scriptcode ab.

Die WSH-Umgebung stellt zwei Script Hosts zur Verfügung: das konsolenbasierte CScript und das GUI-basierte WScript. Diese bieten beide eine nahezu identische Funktionalität. In den meisten Fällen ist es vollkommen egal welcher Script Hosts Ihr Script ausführt.

Die zwei einzigen Unterschiede zwischen den Script Hosts betreffen die Interaktion mit dem Script - also den Weg, wie Sie Informationen an das Script übergeben (Eingaben) oder von diesem erhalten (Ausgaben). Die Ein- und Ausgaben von CScript erfolgen über die Eingabeaufforderung. Im Gegensatz dazu werden bei WScript die Ein- und Ausgaben über Nachrichtenfenster durchgeführt.

Ansonsten sind die beiden Script Hosts identisch. Wenn Sie ein Script schreiben, dass keine Interaktion mit dem Benutzer erfordert, dann können Sie es sowohl mit CScript als auch mit WScript ausführen. Das folgende Script ordnet zum Beispiel eine Netzwerkfreigabe einem Laufwerksbuchstaben zu. Es wird unter beiden Script Hosts exakt gleich ausgeführt:

Set objNetwork = Wscript.CreateObject("WScript.Network")
objNetwork.MapNetworkDrive "g:", "\\atl-fs-01\Sales"

Ein Script, das Informationen ausgibt, wird hingegen unter CScript ganz anders ausgeführt (die Ausgaben werden zeilenweise in der Eingabeaufforderung vorgenommen), als unter WScript (die Ausgaben werden als Nachrichtenfenster angezeigt). Weitere Informationen zum Ausführen von Scripts mit CScript und WScript finden Sie weiter unten im Abschnitt WSH-Scripte ausführen in diesem Kapitel.

Scripting Language Engines

Obwohl der Script Host für die Initiierung und Koordinierung der Scriptausführung verantwortlich ist, kann er trotzdem keine Scriptsprache interpretieren. Diese Aufgabe wurde in der WSH-Umgebung in eine andere Komponente ausgelagert.

Durch diese Teilung ist der WSH in der Lage mit mehreren Scriptsprachen zu arbeiten. Er beherrscht selbst keine einzige Scriptsprache, sondern gibt die Interpretation des Scripts an die entsprechende Language Engine weiter. Sie können VBScript nur darum verwenden, weil die VBScript Language Engine bereits installiert ist.

Wenn eine neue Scriptsprache installiert wird, dann wird in der Registrierung mindestens eine neue Zuordnung eingerichtet. Diese verbindet eine Dateierweiterung mit der DLL (Dynamic Link Library), über die die Scriptsprache implementiert wird. Der Scripthost erkennt die in einem Script verwendete Scriptsprache normalerweise an der Dateierweiterung des Scripts. Dann prüft er in der Registrierung, welche Scripting Language Engine (als DLL) dieser Erweiterung zugeordnet ist, und verwendet die Engine.

Anmerkung:
Sie können den Script Host dazu zwingen eine bestimmte Scripting Language Engine zu verwenden, indem Sie den Kommandozeilenschalter //E: verwenden (siehe Tabelle 3.2). Auf diese Art können Sie jede beliebige Dateierweiterung für Ihre Scriptdateien verwenden.

COM-Objekte

Der WSH stellt das Objekt WScript und drei COM-basierte Objekte zur Verfügung: WshShell, WshNetwork und WshController. Auch wenn diese standardmäßig bereits in der WSH-Umgebung vorhanden sind, handelt es sich doch um COM-Objekte. Sie werden also auch genauso wie COM-Objekte verwendet.

Die WSH-COM-Objekte bieten natürlich nicht die gleichen administrativen Möglichkeiten wie WMI oder ADSI. Trotzdem sind sie in einigen Situationen sehr nützlich:

• Wenn Sie Aufgaben ausführen müssen, die nicht über ein anderes Automatisationsobjekt durchgeführt werden können. Das Objekt WshNetwork erlaubt es Ihnen beispielsweise Netzlaufwerke zu Laufwerksbuchstaben zuzuordnen - dies ist mit WMI oder ADSI nicht möglich.
• Wenn Sie mit Clients arbeiten müssen, die WMI oder ADSI nicht zur Verfügung stellen. Mit ADSI können Sie zum Beispiel den Namen des lokalen Computers abfragen - es sei denn, es handelt sich um einen Computer unter Windows 98. In diesem Fall müssen Sie das Objekt WshNetwork verwenden.
• Wenn sie ein Script auf einem Remotecomputer ausführen müssen. Weder WMI noch ADSI sind hierzu in der Lage. Mit dem Objekt WshController können Sie jedoch auch diese Aufgabe bewältigen.

Zum Seitenanfang

Zusammenarbeit der einzelnen Komponenten der WSH-Umgebung

Die Komponenten der WSH-Umgebung müssen mit den anderen Komponenten zusammenarbeiten. Diese Zusammenarbeit sieht folgendermaßen aus:

Script Host und Scriptdatei: Wenn Script Host für die Ausführung eines Scripts aufgerufen wird, prüft er die Dateierweiterung der Scriptdatei. Dann sucht der Script Host in der Registrierung nach der Scripting Language Engine, die der Erweiterung zugeordnet ist. Dies passiert alles, bevor eine einzige Zeile Scriptcode ausgeführt wird.

Script Host und Scripting Language Engine: Nachdem die Scriptsprache festgestellt wurde, arbeitet der Script Host mit der entsprechenden Scripting Language Engine zusammen, um die Befehle im Script zu interpretieren. Der Script Host kommuniziert mit der Scripting Language Engine über die Windows-Script-Schnittstellen. Bevor die erste Scriptzeile ausgeführt wird, wird das gesamte Script eingelesen und auf syntaktische Fehler geprüft. Das folgende Script hat zum Beispiel eine fehlerhafte Anweisung in Zeile 3. Der If-Then-Befehl ist falsch:

Wscript.Echo "Line 1."
Wscript.Echo "Line 2."
If x = 1
    Wscript.Echo "X is equal to 1."
End If

Vielleicht erwarten Sie, dass Zeile 1 und 2 ausgeführt werden, bevor der Fehler in Zeile 3 auftritt. Dies ist jedoch nicht so. Der Fehler wird bereits bei der Syntaxprüfung vor der Ausführung festgestellt. Daher wird mit der Scriptausführung gar nicht begonnen.

WScript-Bibliothek und COM-Objekte: Wenn im Script ein COM-Objekt verwendet wird, dann führt die WScript-Bibliothek die Interaktion mit diesem COM-Objekt durch.

Anmerkung:

Viele Scriptsprachen bieten die Möglichkeit direkt mit COM-Objekten zu interagieren. In diesem Fall ist WScript nicht an der Zusammenarbeit beteiligt. Da es in diesem Kapitel jedoch um den WSH geht, werden die Methoden CreateObject und GetObject von WScript verwendet. VBScript bietet Ihnen jedoch eine wesentlich einfachere Möglichkeit mit COM-Objekten zu arbeiten. Daher werden in fast allen anderen Scripten dieses Buches die VBScript-Funktionen verwendet. Eine genauere Betrachtung der beiden Möglichkeiten finden Sie im Kapitel VBScript Primer dieses Buches.

Zum Seitenanfang

Das WSH-Objektmodell

Meist wird von WSH als einzelnes Objekt gesprochen. In Wahrheit setzt sich der WSH jedoch aus mehreren Komponenten zusammen - zum Beispiel aus dem standardmäßig verfügbaren Objekt WScript und den drei COM-Objekten WshShell, WshNetwork und WshController. Diese Objekte werden zusammen als WSH-Objekte bezeichnet.

In Abbildung 3.2 sehen Sie das WSH-Objektmodell. Die einzelnen Elemente des Diagrams werden in diesem Kapitel besprochen.

Abbildung 3.2: Diagram des WSH-Objektmodells

Zum Seitenanfang

WSH-Script ausführen

Wenn Sie mehrere Leute fragen wie sie Word starten, dann werden Sie wahrscheinlich einige unterschiedliche Antworten erhalten - zum Beispiel indem Sie im Startmenü auf Word klicken, indem Sie in einer Eingabeaufforderung winword.exe eingeben oder über eine Tastenkombination. Egal welche Methode Sie auch verwenden, dass Ergebnis ist immer das gleiche: Word wird gestartet.

Auch für das Ausführen von WSH-Scripten gibt es mehrere Möglichkeiten. Administrative Scripte können zum Beispiel als Anmeldescript oder über einen geplanten Task ausgeführt werden. Andere Scripte können über eine Eingabeaufforderung oder über einen Doppelklick gestartet werden. In vielen Fällen macht es keinen Unterschied wie ein Script gestartet wird - in anderen Fällen kann es jedoch ein sehr großer Unterschied sein.

Wenn Sie die Beispiele in diesem Kapitel nachvollziehen, dann wird empfohlen die Scripte in einer Kommandozeile über CScript auszuführen. Dies geschieht aus zwei Gründen: Erstens können Scripte unter CScript externe Programme starten und deren Ausgaben weiterverarbeiten, und zweitens werden die Ausgaben im der Eingabeaufforderung statt in einem Nachrichtenfenster ausgegeben. Dies ist besonders bei Scripten wichtig, die Hunderte von Informationen ausgeben. In den nächsten Abschnitten dieses Kapitels wird das Ausführen von Scripten detaillierter besprochen.

Scripte über die Kommandozeile ausführen

Auch wenn wir uns im Zeitalter der grafischen Benutzerschnittstellen befinden, arbeiten viele Administratoren oft mit einer Eingabeaufforderung statt mit der grafischen Benutzerschnittstelle. Mit dem WSH können Sie Script sowohl in der Eingabeaufforderung als auch über die GUI starten. In der Kommandozeile stehen Ihnen die gleichen Möglichkeiten wie über die GUI zur Verfügung - zusätzlich bietet Ihnen CScript jedoch zwei Vorteile:

• Es ist einfach, Argumente an das Script zu übergeben. Diese Argumente können im Script selbst verwendet werden (Sie können zum Beispiel den Ordner angeben, der vom Script gelöscht werden soll), oder der Script Host kann sie zur Ausführung des Scripts verwenden.
• Mit CScript ist es einfach die Scriptausführung abzubrechen - Sie schließen einfach das Kommandozeilenfenster oder drücken STRG+C. Wenn ein Script unter WScript ausgeführt wird, dann können Sie nur den Prozess Wscript.exe über den Taskmanager beenden.

Es gibt zwei Arten, über die Sie in einer Kommandozeile ein Script starten können:

• Sie geben den Namen des Scripts inklusive der Dateierweiterung an:
  HardwareAudit.vbs
• Sie geben den Namen eines der beiden Script Hosts gefolgt vom Namen des Scripts an:
  cscript HardwareAudit.vbs
  wscript HardwareAudit.vbs

Bei der ersten Methode entscheidet der Kommandozeileninterpreter, welcher Script Host verwendet wird. In diesem Fall wird das Script unter dem auf dem Computer konfigurierten Standard-Script Host ausgeführt. Bei der zweiten Methode entscheiden Sie selbst, unter welchem Script Host das Script ausgeführt wird.

Script Host-Optionen

Sowohl CScript als auch WScript akzeptieren einige Parameter. Diese legen fest, wie ein Script ausgeführt wird oder ändern die Konfiguration der WSH-Umgebung. Einige Optionen werden von beiden Script Host verwendet - CScript verfügt jedoch auch über ein paar Optionen, die von WScript nicht verwendet werden (zum Beispiel //logo und //nologo).

Wenn der WSH installiert wird, dann ist WScript der Standardhost. Er wird verwendet, wenn Sie ein Script nicht explizit über CScript oder WScript starten. Um den Standardhost auf CScript zu konfigurieren, verwenden Sie folgenden Befehl:

cscript //H:cscript

Um den Standardhost wieder auf WScript zu setzen, verwenden Sie diesen Befehl:

wscript //H:wscript

Tabelle 3.2 zeigt die am häufigsten verwendeten WSH-Parameter.

Tabelle 3.2: Script Host-Parameter

Parameter	Beschreibung
//B	Batch-Modus; unterdrückt alle Benutzereingaben und Scriptfehler. Wenn ein Script zum Beispiel eine Ausgabe über Wscript.Echo durchführt, dann wird diese im Batch-Modus nicht angezeigt. Auch VBScript-Funktionen wie Msgbox werden unterdrückt. Der Standardmodus ist der interaktive Modus.
//D	Aktiviert den Microsoft Script Debugger, wenn dieser installiert ist. Der Script Debugger wird zusammen mit Windows 2000 zur Verfügung gestellt - er wird standardmäßig jedoch nicht installiert. Windows XP stellt keinen Script Debugger zur Verfügung. Wenn der Script Debugger nicht installiert ist, tritt kein Fehler auf - stattdessen wird das Script einfach weiter ausgeführt.
//E:engine	Führt das Script über eine bestimmte Script Engine aus. Neben anderen Dingen haben Sie mit diesem Schalter die Möglichkeit, beliebige Dateierweiterungen für Ihre Scripte zu verwenden. Ohne den Parameter //E können Sie Script nur dann starten, wenn diese eine der registrierten Dateierweiterungen verwenden. Wenn Sie zum Beispiel versuchen den folgenden Befehl auszuführen, erhalten Sie eine Fehlermeldung: cscript test.admin Die Fehlermeldung sieht so aus: Eingabefehler: Für die Dateierweiterung '.admin' gibt es kein Skriptmodul. Wenn Sie das Script jedoch mit dem Parameter //E starten, wird es korrekt ausgeführt: cscript //E:vbscript test.admin Wenn Sie nicht die standardmäßigen Dateierweiterungen verwenden, dann schützen Sie sich dagegen, ein Script versehentlich durch einen Doppelklick zu starten. Sie müssen jedoch in diesem Fall bei jeder Ausführung des Scripts den Schalter //E verwenden.
//H:CScript oder //H:WScript	Konfiguriert Cscript.exe oder Wscript.exe als Standard-Script Host.
//I	Interaktiver Modus; alle Ausgaben werden wie im Script vorgesehen angezeigt. Dies ist der Standardmodus - die Alternative wäre der Batch-Modus.
//logo	Zeigt ein Logo an, wenn das Script unter CScript ausgeführt wird (das Standardverhalten des WSH). Dieses Logo wird vor der Ausführung des Scripts angezeigt und sieht folgendermaßen aus: Microsoft (R) Windows Script Host, Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten.
//nologo	Verhindert die Anzeige des Logos. Die Option //nologo wird oft verwendet, wenn die Ausgaben des Scripts in eine Textdatei umgeleitet werden.
//S	Legt die Optionen Timeout und Logo dauerhaft für den aktuellen Benutzer fest. Der folgende Befehl stellt zum Beispiel sicher, dass das Logo unter CScript garnicht mehr angezeigt wird: cscript //nologo //S Diese Einstellung können Sie auch ändern, indem Sie mit der rechten Maustaste auf die Scriptdatei klicken und dann zur Registerkarte Eigenschaften wechseln.
//T:nn	Legt die maximale Anzahl an Sekunden fest, die ein Script ausgeführt wird (die Standardeinstellung ist ohne Einschränkung).
//X	Startet das Programm im Microsoft Script Debugger. Wenn der Script Debugger nicht installiert ist, dann wird das Script ganz normal ausgeführt.
//?	Zeigt eine Beschreibung der Kommandozeilenparameter an. Hierbei handelt es sich um die Informationen, die Sie in dieser Tabelle sehen.

Die Scriptausgaben in eine Textdatei umleiten

Stellen Sie sich vor, Sie möchten ein Script ausführen, und die von diesem Script erhaltenen Informationen erst später analysieren. Zum Beispiel, wenn Sie ein Script verwenden, das alle auf einem Domänencontroller installierten Programm ausgibt, und Sie diese Liste erst benötigen, wenn Sie den Domänencontroller wiederherstellen müssen.

In einem solchen Fall wäre es sehr praktisch, wenn Sie die Scriptausgaben in einer Datenbank oder einer Textdatei speichern könnten - beides ist möglich. Wenn Ihr Script die Ausgaben immer irgendwo speichern soll, dann werden Sie wahrscheinlich eine entsprechende Funktionalität in dieses Script einbauen. Was aber, wenn die Scriptausgaben nur einmalig gespeichert werden sollen? Wenn Ihr Script die Ausgaben über WScript.Echo durchführt, dann können Sie ein einem solchen Fall die Scriptausgaben in eine Textdatei umleiten. Die Ausgaben werden bei diesem Verfahren einfach in der Textdatei gespeichert und nicht auf dem Bildschirm angezeigt.

Der Kommandozeileninterpreter bietet Ihnen hierzu zwei Wege an. Mit dem Zeichen gefolgt von einem Dateinamen werden die Ausgaben in einer Textdatei gespeichert. Alles, was sich in dieser Datei bereits befindet, wird überschrieben. Der folgende Kommandozeilenbefehl speichert zum Beispiel die Ausgaben des Scripts in der Textdatei c:\scripts\services.txt:

cscript service_info.vbs > c:\scripts\services.txt

Mit dem Zeichen können Sie die Daten an die entsprechende Textdatei anhängen. In diesem Fall werden die vorhandenen Inhalte der Textdatei nicht überschrieben:

cscript service_info.vbs >> c:\scripts\services.txt

Außerdem sollten Sie den Parameter //nologo verwenden, um zu verhindern dass das Logo in der Textdatei gespeichert wird:

cscript //nologo service_info.vbs > c:\scripts\services.txt

Wenn Sie die Ausgaben eines Scripts in eine Textdatei umleiten, werden keine Informationen auf dem Bildschirm angezeigt. Stattdessen gehen alle Ausgaben (auch Fehlermeldung) in die Textdatei.

Ausführung von Scripten planen

Mit dem Windows 2000 Taskplaner oder dem Kommandozeilentool At.exe können Sie die Ausführung von Scripten vorausplanen. Die Scripte werden dann ohne Ihr Zutun ausgeführt. Nehmen wir zum Beispiel einmal an, Sie verwenden ein Script, dass einmal in der Woche ausgeführt wird und die Ereignisprotokolle auf allen Domänencontrollern sichert und leert. Wenn sie dieses Script als Task planen, müssen Sie nicht mehr selbst daran denken das Script regelmäßig auszuführen.

Geplante Tasks können Sie auch über WMI erstellen, löschen und verwalten (weitere Informationen hierzu finden Sie im Kapitel Creating Enterprise Scripts dieses Buches). Das folgende Script erstellt zum Beispiel einen Task, der das Script monitor.vbs jeden Montag, Mittwoch und Freitag um 12:30 Uhr ausführt:

Set Service = GetObject("winmgmts:")
Set objNewJob = Service.Get("Win32_ScheduledJob")
errJobCreated = objNewJob.Create _
    ("cscript c:\scripts\monitor.vbs", "********123000.000000-420", _
        True , 1 OR 4 OR 16, , , JobID)
Wscript.Echo errJobCreated

Andere Verfahren zum Starten eines Scripts

In den meisten Fällen wird ein Systemadministrator ein Script wohl über die Kommandozeile oder über einen geplanten Task starten. Es gibt jedoch noch einige weitere Möglichkeiten:

• Scripte auf Remotecomputern starten: Das Objekt WshController ermöglicht es Ihnen WSH-basierte Scripte auf Remotecomputern auszuführen. Weitere Informationen hierzu finden Sie im Abschnitt WSHController Object weiter unten in diesem Kapitel.
• Scripte über den Windows Explorer starten: Natürlich können Sie ein WSH-Script auch über einen Doppelklick im Windows Explorer starten. Es wird dann mit dem Standardhost ausgeführt. Wenn es sich beim Standardhost um CScript handelt, dann wird ein Kommandozeilenfenster geöffnet. Dieses wird wieder geschlossen, sobald das Script beendet ist.
• Scripte über das Kontextmenü starten: Sie können ein WSH-Script starten, indem Sie mit der rechten Maustaste auf die Scriptdatei klicken, und die entsprechende Option auswählen.
• Scripte über Drag and Drop starten: Sie können ein Script starten, indem Sie es auf eine oder mehrere Dateien oder Ordner ziehen. Hierbei wird dem Script Host automatisch der vollständige Pfad der Datei oder des Ordners übergeben, auf den Sie das Script gezogen haben.

Das folgende Script zeigt zum Beispiel den Pfadnamen jedes Ordners oder jeder Datei an, auf den es gezogen wird:

For Each strArgument in Wscript.Arguments
    Wscript.Echo strArgument
Next

Diese Verfahren können Sie sehr gut verwenden, wenn Sie mit Scripten arbeiten, die Datei- oder Ordnernamen als Parameter erwarten. Stellen Sie sich zum Beispiel vor, Sie ziehen mehrere Dateien auf ein Script, und das Script kopiert diese automatisch auf einen Remoteserver.

Die Länge aller Parameter eines Scripts ist jedoch durch den Kommandozeileninterpreter auf 2048 Zeichen begrenzt.

Zum Seitenanfang

WSH-Objekte

In der WSH-Umgebung stehen Ihnen standardmäßig das Objekt WScript und drei COM-Objekte zur Verfügung (WshShell, WshNetwork und WshController). Einige der Aufgaben, die Sie mit diesen Objekten durchführen können, lassen sich jedoch leichter mit anderen Technologien erledigen - zum Beispiel mit WMI und ADSI.

Das Objekt WshShell stellt Ihnen zum Beispiel eine Methode mit dem Namen RegRead zur Verfügung. Über diese Methode können Sie einen Registrierungseintrag auslesen. Sie funktioniert sehr gut, wenn Sie den Registrierungsschlüssel, den das Script auslesen soll, vorher schon kennen - zum Beispiel wenn Sie feststellen möchten, welches Hintergrundbild ein Benutzer verwendet. Das folgende WSH-Script führt diese Aufgabe problemlos aus:

Set WshShell = WScript.CreateObject("WScript.Shell")
strWallpaper = WshShell.RegRead "HKCU\Control Panel\Desktop\Wallpaper"
Wscript.Echo strWallpaper

Was aber, wenn es um eine etwas weniger genau definierte Aufgabe geht? Zum Beispiel um das Auflisten aller Einträge unter einem bestimmten Schlüssel? In einem solchen Fall nützt Ihnen WSH ziemlich wenig. Stattdessen sollten Sie den WMI-Anbieter StdRegistry verwenden - er listet alle Einträge unter einem bestimmten Schlüssel auf. Eine solche WMI-Abfrage ist in diesem Fall deutlich einfacher umzusetzen.

Außerdem funktioniert WMI in den meisten Fällen auf Remotecomputern genauso wie auf dem lokalen Computer. Der WSH arbeitet hingegen nur auf den lokalen Computern. Um WSH-Scripte auf Remotecomputern auszuführen, müssen Sie zwei Scripte erstellen: das Script, das ausgeführt werden soll, und ein Script, das dieses Script auf dem Remotecomputer startet.

Trotzdem gibt es einige Fälle, in denen Sie möglicherweise dennoch auf die WSH-Objekte statt auf WMI zurückgreifen. Reine WSH-Scripte werden zum Beispiel auch von Computern unter Windows NT 4.0 und Windows 98 unterstützt - dies ist bei WMI und ADSI nicht der Fall.

Zum Seitenanfang

Das Objekt WScript

Das Objekt WScript bietet Ihnen eine große Menge von Funktionalitäten. Egal welche Scriptsprache Sie verwenden, einige Schlüsselaufgaben (zum Beispiel das Einbinden von COM-Objekten und das Entgegennehmen von Kommandozeilenargumenten) können Sie so immer ausführen.

Abhängig von der verwendeten Scriptsprache kann es sein, dass Sie das WScript-Objekt nicht benötigen. VBScript stellt zum Beispiel ebenfalls eine Funktion GetObject zur Verfügung, über die Sie COM-Objekte einbinden können. Da die Syntax dieser Funktion viel einfacher als ihr WScript-Equivalent ist, werden Sie diese wahrscheinlich viel häufiger verwenden.

Andererseits gibt es in VBScript keine Funktionen zur Verarbeitung von Kommandozeilenargumenten. Es hindert Sie jedoch nichts daran, die entsprechenden WScript-Funktionen unter VBScript zu verwenden. Die Möglichkeit, die Methoden und Funktionen der Scriptsprache und von WScript gemischt zu verwenden, ist einer der Hauptvorteile der WSH-Umgebung.

In Abbildung 3.3 sehen Sie die Eigenschaften und Methoden des WScript-Objekts und der Collections WshArguments, WshUnnamed und WshNamed.

Abbildung 3.3: Das Objektmodell von WScript

Auf das Objekt WScript zugreifen

Das Objekt WScript steht in allen WSH-Scripten zur Verfügung, ohne dass Sie es einbinden müssen. Die folgende Codezeile können Sie überall in Ihrem Script verwenden, ohne die Methode CreateObject aufrufen zu müssen:

Wscript.Echo "Keine Bindung erforderlich."

Das Objekt steht deshalb immer zur Verfügung, weil die Methoden CreateObject und GetObject über dieses Objekt zur Verfügung gestellt werden. Wenn es nicht ständig zur Verfügung stände, dann könnten Sie ohne die beiden Methoden keine weiteren COM-Objekte einbinden.

Funktionen von WScript

Das WScript-Objekt soll Ihnen hauptsächlich einige grundlegende Funktionalitäten zur Verfügung stellen - diese Funktionalitäten sehen Sie in Tabelle 3.3. Die einzelnen Methoden und Eigenschaften werden in den folgenden Abschnitten dieses Kapitels genauer beschrieben.

Tabelle 3.3: Funktionen, die Ihnen über das Objekt WScript zur Verfügung stehen

Kategorie	Methoden oder Eigenschaften
Verwenden von COM-Objekten	CreateObject, GetObject
Eingaben und Ausgaben	Echo, StdOut, StdIn, StdErr
Arbeiten mit Kommandozeilenargumenten	Arguments
Scriptausführung steuern	Quit, Sleep, Timeout, Interactive
WSH-Umgebungsinformationen abfragen	Application, BuildVersion, FullName, Name, Path, ScriptFullName, ScriptName, Version
Ereignisse verarbeiten	CreateObject, GetObject, ConnectObject, DisconnectObject

COM-Objekte verwenden

Wenn Sie eine Information benötigen, dann können Sie diese zum Beispiel in einer öffentlichen Bibliothek finden. Sie werden jedoch wahrscheinlich nicht in die Bibliothek gehen, ein zufälliges Buch auswählen, und in diesem Buch die gewünschte Information erwarten. Stattdessen müssen Sie das Buch finden, dass Ihnen diese Information zur Verfügung stellt.

Genauso funktionieren auch COM-Objekte. Es gibt wahrscheinlich für fast alle administrativen Aufgaben ein passendes COM-Objekt. Sie können jedoch ein COM-Objekt nicht einfach verwenden. Objekte stellen nämlich nur ganz bestimmte Funktionalitäten zur Verfügung. Genauso, wie Sie ein Buch nicht lesen können, bevor Sie es gefunden haben, können Sie ein COM-Objekt nicht einfach verwenden. Stattdessen müssen Sie das Objekt erst in Ihr Script einbinden. Das WScript-Objekt stellt Ihnen hierzu zwei Methoden zur Verfügung: CreateObject und GetObject.

Eine neue Instanz eines COM-Objektes erstellen

Um eine neue Instanz eines COM-Objektes zu erstellen, können Sie die Methode CreateObject des Objektes WScript verwenden. Diese Methode erwartet als Parameter den Programmatic Identifier (ProgID) des COM-Objektes. Die genaue Syntax sieht so aus:

WScript.CreateObject("ProgID")

Um die Analogie mit der Bibliothek wieder aufzugreifen: Die ProgID ist das Equivalent zur Ablagenummer des Buches. Wenn Sie in die Bibliothek gehen, geben Sie dem Bibliothekar diese Ablagenummer, und er oder sie sucht das Buch für Sie heraus. Wenn Sie dem Scripting Host die ProgID geben, dann kann der Host in der Registrierung nach dem COM-Objekt suchen, das Sie erstellen möchten.

Woher wissen Sie nun die richtige ProgID eines COM-Objektes? Unglücklicherweise gibt es keine einfache Antwort auf diese Frage. Der einfachste Weg ist es, wenn Sie in die Dokumentation dieses Objektes schauen. Alle ProgIDs werden unter HKEY_CLASSES_ROOT in der Registrierung gespeichert. Ein Beispiel sehen Sie in Abbildung 3.4. Diese ProgID-Liste ist jedoch leider nur von eingeschränktem Nutzen, da nicht alle ProgIDs in Scripten verwendet werden können.

Abbildung 3.4: ProgIDs in der Regisrierung

Um ein neu erstelltes Objekt verwenden zu können, muss Ihr Script eine Referenz auf das Objekt in einer Variablen speichern:

SetobjVariable= WScript.CreateObject (" ProgID" )

Nachdem die Referenz in einer Variablen gespeichert wurde, kann das Script über die Punkt-Notation auf die Methoden und Eigenschaften des Objekts zugreifen (die Punkt-Notation wird im Kapitel VBScript Primer dieses Buches besprochen).

Eine Methode können Sie über die folgende Syntax aufrufen:

objVariable.Methodenname

Der Zugriff auf Eigenschaften verwendet die gleiche Syntax:

objVariable.Eigenschaftsname

Script 3.1 erstellt eine neue Instanz des ADSI-Objektes ADSystemInfo und speichert die Referenz auf das Objekt in der Variablen objSysInfo. Dann zeigt es den DNS-Namen der Domäne des angemeldeten Benutzers an.

Script 3.1: Ein COM-Objekt verwenden

1 2	Set objSysInfo = Wscript.CreateObject("ADSystemInfo") Wscript.Echo "Domain DNS name: " & objSysInfo.DomainDNSName

Wie Sie in Abbildung 3.5 sehen, müssen Sie nur zwei Teile des Befehls ändern, wenn Sie ein anderes COM-Objekt verwenden möchten - die ProgID und den Namen der Referenzvariable (die Variable brauchen Sie nur zu ändern, wenn Ihr Script mehrere Objekte verwenden soll).

Abbildung 3.5: Elemente des Befehls, der ein COM-Objekt erstellt

Das folgende Script bindet zum Beispiel mehrere COM-Objekte ein:

Set objReference = Wscript.CreateObject("Word.Application")
Set objReference = Wscript.CreateObject("InternetExplorer.Application")
Set objReference = Wscript.CreateObject("Scripting.Dictionary")
Set objReference = Wscript.CreateObject("Wscript.Network")

Eine Verbindung zu einer bestehenden Instanz eines COM-Objektes aufbauen

Wenn das COM-Objekt, das Sie verwenden möchten, bereits ausgeführt wird, können Sie auch dieses verwenden - Sie müssen in diesem Fall keine neue Instanz erstellen. Hierzu verwenden Sie die Methode GetObject des WScript-Objektes. Diese gibt Ihnen eine Referenz auf das bestehende Objekt zurück.

Wenn Sie Scripte schreiben, die WMI oder ADSI verwenden, dann werden Sie normalerweise immer die Methode GetObject verwenden. Das liegt daran, dass WMI und ADSI standardmäßig bereits zur Verfügung stehen (den WMI-Dienst können Sie zwar auch anhalten, aber wenn Sie ein Script ausführen, das WMI verwendet, dann wird der Dienst automatisch neu gestartet). Auch wenn es Ausnahmen gibt, wird das typische WMI-Script wohl meist mit einer Zeile wie der folgenden anfangen:

Set objWMIService = Wscript.GetObject("winmgmts:")

Vergleich der VBScript Funktionen CreateObject und GetObject mit den entsprechenden WSH-Funktionen

Auch VBScript stellt die Funktionen CreateObject und GetObject zur Verfügung. Wenn sie mit der ProgID des COM-Objektes als Parameter aufgerufen werden, erstellt sowohl die VBScript-Funktion CreateObject als auch Ihr WScript-Equivalent eine Instanz des COM-Objektes. Die folgenden zwei Codezeilen machen genau das Gleiche - die erste verwendet die VBScript-Version von CreateObject und die zweite die WSH-Version:

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFSO = Wscript.CreateObject("Scripting.FileSystemObject")

Beide Versionen von CreateObject akzeptieren auch einen zweiten Parameter - er wird jedoch bei beiden Methoden komplett anders interpretiert. Sehen Sie sich die folgenden zwei Codezeilen an. Wiederum wird in der ersten Zeile die VBScript-Version und in der zweiten Zeile die WSH-Version verwendet:

Set objExcel = CreateObject("Excel.Application", "Parameter2")
Set objExcel = Wscript.CreateObject("Excel.Application", "Parameter2")

Die CreateObject-Funktion von VBScript interpretiert den zweiten Parameter als Name eines Remotecomputers - in dem oben gezeigten Beispiel versucht die Methode eine Instanz von Microsoft Excel auf dem Remotecomputer mit dem Namen Parameter2 zu erstellen. Die WScript-Version von CreateObject interpretiert den zweiten Parameter hingegen als Prefix einer Subroutine, die verwendet werden soll, wenn Ereignisse für das Objekt auftreten.

Um einfach nur ein COM-Objekt zu erstellen, können Sie beide Funktionen verwenden. Es gibt in diesem Fall keinen Unterschied. Wenn Sie jedoch ein Remoteobjekt erstellen möchten oder auf Ereignisse des Objektes reagieren müssen, dann sollten Sie die passende Version der Methode auswählen. Weitere Informationen zu den Funktionen CreateObject und GetObject von VBScript finden Sie im Kapitel VBScript Primer dieses Buches.

Eingaben und Ausgaben

Scripte müssen mit Benutzern interagieren. Ein Script, das das Ereignisprotokoll nach bestimmten Ereignissen durchsucht, sollte auch mitteilen können, wenn passende Ereignisse gefunden wurden. Oder stellen Sie sich vor, Sie schreiben ein Script dass die Verbindung zwischen zwei Computern testet. Sie benötigen für dieses Script eine einfache Möglichkeit, die beiden Computernamen als Eingabe entgegenzunehmen.

WSH stellt Mittel zur Interaktion mit dem Benutzer und - möglicherweise viel wichtiger - Mittel für eine Eingabe und Ausgabe in der Kommandozeile zur Verfügung. Neben vielen anderen Dingen haben Sie so die Möglichkeit Scripte zu erstellen, die Sie wie Kommandozeilenwerkzeuge verwenden können.

Ein einfacher Weg eine Ausgabe zu erzeugen, ist die Methode WScript.Echo. Sie erwartet einen Parameter (einen String, eine Zahl oder ein Datum) und gibt diesen Parameter auf dem Bildschirm aus. Script 32. verwendet die Methode WScript.Echo, um die auf dem Computer installierte WSH-Version auszugeben.

Script 3.2: Anzeige der installierten WSH-Version

1	Wscript.Echo "The version of WSH on this computer is: " & WScript.Version

Das WScript-Objekt verfügt außerdem über Eigenschaften, die es Ihrem Script ermöglicht, auf drei Objekte zuzugreifen, die Eingabe- und Ausgabefunktionalitäten zur Verfügung stellen: StdOut, StdIn und StdErr. Diese Objekte verfügen wiederum über eigene Methoden und Eigenschaften - diese sehen Sie in Abbildung 3.6. Ein Script kann normalerweise nur dann auf die Methoden StdOut, StdIn und StdErr zugreifen, wenn es unter CScript ausgeführt wird.

Abbildung 3.6: Methoden und Eigenschaften der TextStream-Objekte

Nachrichten ausgeben

Ein primärer Zweck von administrativen Scripten ist das Abfragen von Informationen. Wie viel freier Festplattenplatz steht noch zur Verfügung? Unter welchem Konto werden die Internetinformationsdienste ausgeführt? Welche Prozesse verbrauchen den gesamten freien Speicher auf dem Mailserver?

Ein Script, das solche Fragen beantwortet, muss eine Möglichkeit haben, mit dem Benutzer zu kommunizieren. Auch wenn es die Informationen auch in einer Textdatei oder einer Datenbank speichern könnte, ist es doch einfacher, wenn sie direkt auf dem Bildschirm ausgegeben werden. Der WSH kann solche Bildschirmausgaben über die Methode Echo durchführen.

Wenn ein Script unter CScript ausgeführt wird, dann gibt die Methode WScript.Echo die Informationen in der Eingabeaufforderung aus. Unter WScript werden die Informationen hingegen in einem Nachrichtenfenster angezeigt. Die folgende Codezeile gibt zum Beispiel das Ergebnis einer Berechnung aus:

Wscript.Echo 2 + 2

Die Echo-Methode ist einfach zu implementieren. Sie geben ihr einfach die Informationen als Parameter mit, die auf dem Bildschirm angezeigt werden sollen - zum Beispiel über eine Variable:

Wscript.Echo strMyVariable

Auch die Inhalte von VBScript, wie zum Beispiel Now und Time, können Sie ausgeben:

Wscript.Echo Now

Um einen String auszugeben, schließen Sie diesen in Anführungsstriche ein:

Wscript.Echo "This is my string."

Das einzig wirklich Wichtige, das Sie bei der Arbeit mit WScript.Echo berücksichtigen müssen, ist das unterschiedliche Verhalten unter WScript und CScript. Script 3.3 gibt zum Beispiel drei Nachrichten über WScript.Echo aus:

Script 3.3: Ausgabe von drei Nachrichten über die Methode Echo

1 2 3	Wscript.Echo "Prüfung der Systemlaufwerke " Wscript.Echo "Abfragen des freien Speicherplatzes " Wscript.Echo "Zuordnen von Netzlaufwerken "

Wenn Sie das Script unter CScript ausführen, sehen Sie im Kommandozeilenfenster die folgende Ausgabe:

Prüfung der Systemlaufwerke 
Abfragen des freien Speicherplatzes 
Zuordnen von Netzlaufwerken 

Wenn Sie das Script unter WScript ausführen, produziert es die drei einzelnen Nachrichtenfenster, die Sie in Abbildung 2.7 sehen. Der Benutzer muss in jedem dieser Nachrichtenfenster auf OK klicken, damit das Script weiter ausgeführt wird.

Abbildung 3.7: Echo-Methode unter WScript

Unter WScript führt jeder Aufruf von WScript.Echo zu einem neuen Nachrichtenfenster. Abhängig vom Script kann das sehr mühsam werden. Bei einem kleinen Script, das den freien Speicherplatz auf Laufwerk C abfragt, ist es normalerweise egal, ob die Ausgabe in der Kommandozeile oder in einem Nachrichtenfenster angezeigt wird. Wenn des Script jedoch den Status aller Dienste zurückgibt, dann müssen Sie im Zweifelsfall in vielen Dutzend Nachrichtenfenstern auf OK klicken.

Unter CScript würden alle Informationen ohne Aktion des Benutzers im Kommandozeilenfenster ausgegeben.

Texteingaben und -ausgaben

Kommandozeilenwerkzeuge arbeiten typischerweise mit drei standardmäßigen Eingabe- und Ausgabemöglichkeiten - diese werden auch als Standard In (StdIn), Standard Out (StdOut) und Standard Error (StdErr) bezeichnet. Wenn sie es nicht anders festgelegt haben, geht der Kommandozeilenprozessor davon aus, dass die Eingaben über die Tastatur (StdIn), die Ausgaben (StdOut) und Fehlernachrichten (StdErr) in der Kommandozeile ausgegeben werden sollen.

StdIn, StdOut und StdErr stehen nur zur Verfügung, wenn das Script unter CScript ausgeführt wird. Über diese drei Objekte können Sie die drei unterschiedlichen Ein- und Ausgabemöglichkeiten in Ihren Scripten nutzen:

• Sie können Ausgaben im Kommandozeilenfenster durchführen.
• Sie können im Kommandozeilenfenster Eingaben durch den Benutzer einlesen.
• Sie können Fehlerinformationen in Ihrem Script entgegennehmen, die von anderen Scripten, Batchdateien oder Kommandozeilentools ausgegeben werden.

Ausgaben über StdOut durchführen

Über StdOut können sie Ausgaben im Kommandozeilenfenster durchführen. Die einzelnen Methoden von StdOut sehen Sie in Tabelle 3.4.

Tabelle 3.4: Methode von StdOut

Methode	Beschreibung
Write	Gibt den übergebenen Parameter auf dem Bildschirm aus. Hängt jedoch keinen Zeilenumbruch an. Das folgende Script führt zum Beispiel vier Ausgaben durch: Wscript.StdOut.Write "ABCD" Wscript.StdOut.Write "EFGHIJKLMN" Wscript.StdOut.Write "OPQRSTUV" Wscript.StdOut.Write "WXYZ" Die Ausgabe des Scripts sieht so aus: ABCDEFGHIJKLMNOPQRSTUVWXYZ
WriteLine	WriteLine arbeitet genauso wie WScript.Echo. Der angehängte Parameter wird auf dem Bildschirm ausgegeben, und es wird ein Zeilenumbruch angehängt. Das folgende Script führt wiederum vier Ausgaben durch: Wscript.StdOut.WriteLine "ABCD" Wscript.StdOut.WriteLine "EFGHIJKLMN" Wscript.StdOut.WriteLine "OPQRSTUV" Wscript.StdOut.WriteLine "WXYZ" Die Ausgabe des Scripts sieht dieses Mal jedoch so aus: ABCD EFGHIJKLMN OPQRSTUV WXYZ
WriteBlankLines	Gibt Leerzeilen aus. Als Parameter benötigt WriteBlankLines die Anzahl der auszugebenden Leerzeilen: Wscript.StdOut.WriteLine "ABCD" Wscript.StdOut.WriteBlankLines 1 Wscript.StdOut.WriteLine "EFGHIJKLMN" Wscript.StdOut.WriteLine "OPQRSTUV" Wscript.StdOut.WriteBlankLines 2 Wscript.StdOut.WriteLine "WXYZ" Das Script produziert die folgende Ausgabe: ABCD EFGHIJKLMN OPQRSTUV WXYZ

Script 3.4 zeigt eine Nachricht über die Methoden Write und WriteLine des Objektes StdOut.TextStream an.

Script 3.4: Verwendung der Methoden Write und WriteLine im Kommandozeilenfenster

1 2 3 4 5 6 7 8 9 10	Set objNetwork = Wscript.CreateObject("Wscript.Network") Set objStdOut = WScript.StdOut objStdOut.Write "Benutzer: " objStdOut.Write objNetwork.UserDomain objStdOut.Write "\" objStdOut.Write objNetwork.UserName objStdOut.WriteBlankLines(1) objStdOut.WriteLine objNetwork.ComputerName objStdOut.Write "Informationen abgefragt." objStdOut.Close

Die Ausgabe von Script 3.4 sieht so aus:

Benutzer: FABRIKAM\kenmyer

atl-wk-01
Informationen abgefragt.

Wenn Sie statt der Methode StdOut die Methode Wscript.Echo verwenden würden, sähe die Ausgabe so aus:

Benutzer:
FABRIKAM
\
kenmeyer

atl-wk-01
Informationen abgefragt.

Eingaben über StdIn entgegennehmen

Ein Weg, um in einem Script Eingaben entgegenzunehmen, sind Argumente (diese werden weiter unten in diesem Kapitel besprochen). Der folgende Befehl führt ein Script mit dem Namen DeleteUser.vbs aus und übergibt als Argument den zu löschenden Benutzernamen:

cscript DeleteUser.vbs kenmyer

Die Verwendung von Argumenten ist schnell und einfach umzusetzen. Andererseits muss der Benutzer bei der Verwendung des Scripts wissen, welche Argumente es gibt und wie er diese benutzen kann. Es gibt jedoch eine Alternative - fordern Sie den Benutzer zu Eingabe der benötigten Informationen auf, nachdem das Script gestartet wurde:

C:\Scripts\cscript DeleteUser.vbs
Bitte geben Sie den Namen des zu löschenden Benutzerkontos an: _

Mit StdIn können Sie Eingaben in der Kommandozeile entgegennehmen. Die Methoden und Eigenschaften von StdIn sehen Sie in Tabelle 3.5.

Tabelle 3.5: Methoden und Eigenschaften von StdIn

Methode/Eigenschaft	Beschreibung
Read	Liest die angegebene Anzahl an Zeichen ein. Der folgende Befehl liest zum Beispiel jeweils drei Zeichen über StdIn ein und gibt diese wieder aus, bis ein Zeilenumbruch (ENTER) eingegeben wurde: Do Until Wscript.StdIn.AtEndOfLine strInput = Wscript.StdIn.Read(3) Wscript.Echo strInput Loop Wenn Sie 'abcdefghijklmnopqrstuvwxyz' eingeben, wird die Ausgabe so aussehen: abc def ghi jkl mno pqr stu vwx yz
ReadLine	Liest eine Zeile ein. ReadLine ist besonders dann sehr nützlich, wenn der Benutzer Eingaben machen soll. Es liest alle Eingaben, bis der Benutzer die Taste ENTER drückt: strInput = Wscript.StdIn.ReadLine Wscript.Echo strInput Wenn Sie 'abcdefghijklmnopqrstuvwxyz' eingeben, sieht die Ausgabe des Scripts so aus: abcdefghijklmnopqrstuvwxyz
ReadAll	Liest die gesamten Ausgaben eines Kommandozeilentools, einer Batchdatei oder eines Shellbefehls ein.
Skip	Überspringt die angegebene Anzahl von Zeichen. Das folgende Script überspringt zum Beispiel die ersten 23 Zeichen der Eingabe und liest die verbleibenden Zeichen auf einmal ein: Wscript.StdIn.Skip(23) Do Until Wscript.StdIn.AtEndOfLine strInput = Wscript.StdIn.Read(1) Wscript.Echo strInput Bei der Eingabe 'abcdefghijklmnopqrstuvwxyz' sieht die Ausgabe des Scripts so aus: x y z
SkipLine	Überspringt eine Zeile.
AtEndOfLine	Ein Boolean-Wert (ein Wert, der nur zwei Zustände haben kann - typischerweise True und False), der anzeigt, ob das Ende einer Zeile erreicht wurde. Über diese Eigenschaft kann das Script erkennen, ob die gesamte Zeile eingelesen wurde - in diesem Fall hat sie den Wert True. Do Until Wscript.StdIn.AtEndOfLine strInput = Wscript.StdIn.Read(1) Wscript.Echo strInput Loop
AtEndOfStream	Ein Boolean-Wert, der anzeigt, ob das Ende der Eingabe erreicht wurde. Er zeigt einem Script zum Beispiel das Ende von einem Kommandozeilentool, von einer Batchdatei oder den von einem über einen Shellbefehl ausgegebenen Text an.

Mit StdIn können Sie Eingaben von Benutzern entgegennehmen. Hierzu gehen Sie folgendermaßen vor:

1. Verwenden Sie die Methode Write, um eine Eingabeaufforderung anzuzeigen (zum Beispiel "Bitte geben Sie Ihren Namen ein:"). Mit dieser Methode stellen Sie sicher, dass die Eingabeaufforderung und die Eingabe des Benutzers in derselben Zeile angezeigt werden (bei einer Ausgabe mit Write wird kein Zeilenumbruch an die Ausgabe angehängt). Eine solche Ausgabe sieht dann zum Beispiel so aus (der Unterstrich repräsentiert den Cursor):
   C:\Scripts Please enter your name: _
2. Verwenden Sie dann die Methode ReadLine, um die Eingaben des Benutzers einzulesen, und speichern Sie diese Eingaben in einer Variablen. Mit ReadLine werden die Eingaben so lange eingelesen, bis der Benutzer ENTER drückt. Wenn Sie zum Beispiel Klaus Meyer eingeben und dann ENTER drücken, dann wird in der Variable der Wert "Klaus Meyer" gespeichert. Mit ReadLine können Sie allerdings nicht mehr als 254 Zeichen am Stück einlesen.

Stellen Sie sich zum Beispiel vor, Sie möchten ein Script erstellen, das Zahlen aus dem dezimalen Format in das hexadezimale Format konvertiert. Sie müssen den Benutzer eine dezimale Zahl eingeben lassen. Script 3.5 verwendet hierzu die Methode ReadLine des WScript-Objekts StdIn. Der eingelesene Wert wird dann in der Variablen strDecimal gespeichert. Die Funktion Hex von VBScript konvertiert den gespeicherten dezimalen Wert dann in einen hexadezimalen Wert - dieser wird dann über die Methode WriteLine des WScript-Objekts StdOut ausgegeben.

Script 3.5: Konvertierung eines dezimalen Wertes in einen hexadezimalen Wert

1 2 3 4 5	Wscript.StdOut.Write "Geben Sie eine Dezimalzahl ein: " strDecimal = Wscript.StdIn.ReadLine Wscript.StdOut.WriteLine strDecimal & " entspricht dem Wert " & _ Hex(strDecimal) & " in hexadezimaler Schreibweise."

Wenn Sie das Script unter CScript ausführen, sieht die Ausgabe so aus:

C:\>cscript test.vbs
Microsoft (R) Windows Script Host, Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten.

Geben Sie eine Dezimalzahl ein: 254
254 entspricht dem Wert FE in hexadezimaler Schreibweise.

Verwenden von Kommandozeilenargumenten

Argumente sind Werte, die Sie beim Start des Scripts in der Kommandozeile angeben können. Wenn Sie bereits mit Kommandozeilentools gearbeitet haben, dann kennen Sie das Konzept wahrscheinlich. Wenn Sie zum Beispiel ping.exe ausführen, dann müssen Sie mindestens einen Hostnamen oder eine IP-Adresse als Argument (auch Parameter genannt) angeben:

ping 192.168.1.1

Das Aufrufen eines Scripts mit einem Argument ist in den Fällen sehr praktisch, in denen Sie bei jedem Aufruf des Scripts einen anderen Wert übergeben möchten. Wenn Sie den entsprechenden Wert fest in das Script eintragen würden, dann müssten Sie das Script vor jedem Aufruf bearbeiten. In diesen Fällen sparen Sie sich also mit Kommandozeilenargumenten eine Menge Zeit.

Die Arbeit mit Script-Argumenten unterscheidet sich nicht von der Arbeit mit Kommandozeilentools. Sie können Script-Argumente genauso verwenden, wie Sie zum Beispiel Argumente (Parameter) bei ping.exe angeben (IP-Adresse, -t, usw.).

Argumente werden in einer Collection mit dem Namen WshArguments gespeichert. Über die Eigenschaft Arguments des Objekts WScript können Sie auf diese Collection zugreifen - dies sehen Sie in Abbildung 3.8. Außerdem werden die Argumente automatisch nach deren Format gefiltert und zusätzlich in die beiden Collections WshNamed und WshUnnamed einsortiert.

Abbildung 3.8: Collections mit Kommandozeilenargumenten

Ablage und Filterung der Argumente

Wenn Sie ein Script mit Argumenten starten, dann speichert der WSH diese Argumente in der Collection WshArguments - und zwar in der Reihenfolge, in der Sie beim Start des Scripts angegeben wurden. WScript.Arguments.Item(0) enthält das erste Argument, WScript.Arguments.Item(1) enthält das zweite usw.

Die Argumente werden jedoch zusätzlich in zwei weiteren Collections gespeichert: WshNamed und WshUnnamed. Argumente, die im Format /name:wert angegeben wurden, werden in WshNamed gespeichert, und alle Argumente, die nicht dieses Format verwenden, werden in WshUnnamed gespeichert. Der Sinn dieser zusätzlichen gefilterten Speicherung wird weiter unten in diesem Abschnitt genauer besprochen.

Wenn Sie zum Beispiel den folgenden Befehl ausführen, dann starten Sie das Script ServerStats.vbs mit den drei Argumenten /s:atl-dc-01, /u:admin und perf.

cscript serverstats.vbs /s:atl-dc-01 /u:admin perf

Die Argumente werden nach dem Scriptnamen angegeben und müssen durch ein oder mehrere Leerzeichen getrennt werden. Argumente, die selbst Leerzeichen enthalten, müssen in Anführungszeichen eingeschlossen werden. Ein Beispiel hierfür ist das dritte Argument ("perf monitor")im folgenden Befehl:

cscript serverstats.vbs /s:atl-dc-01 /u:admin "perf monitor"

Ohne die Anführungsstriche würden perf und monitor als zwei einzelne Argumente behandelt werden.

In Abbildung 3.9 sehen Sie die Inhalte der drei Argument-Collections, nachdem Sie ein Script mit dem Namen status.vbs und den drei Argumenten /s:atl-dc-01, /u:admin und perf gestartet haben.

Abbildung 3.9: Inhalte der Argument-Collections

In der Collection WshArguments werden alle Argumente genauso gespeichert, wie Sie in der Kommandozeile angegeben wurden. Die Methode Count und die Eigenschaft Length geben die Gesamtzahl der übergebenen Argumente zurück.

In der Collection WshNamed sind die zwei Argumente gespeichert, die zusätzlich 'Werte' angeben. Solche Argumente bestehen immer aus zwei Teilen: dem Argument selbst (zum Beispiel /u) und dem Wert für dieses Argument (zum Beispiel admin). Argument und Wert werden hierbei durch einen Doppelpunkt getrennt (zum Beispiel /u:admin). Das Argument muss in diesem Fall immer mit einem Slash (/) angegeben werden. Es ist nicht möglich, alternativ ein Minuszeichen (-) zu verwenden. Der folgende Befehl führt zum Beispiel nicht dazu, dass das Argument in der Collection WshNamed gespeichert wird. Stattdessen wird das Argument in der Collection WSHUnnamed gespeichert:

cscript serverstats.vbs -Server:atl-dc-01

Wenn Sie sich Abbildung 3.9 genau ansehen, dann werden Sie feststellen, dass die Argumente in der Collection WshNamed vor deren Speicherung verändert werden. Der 'Argument-Teil' des Arguments (also zum Beispiel der Teil /s) wird zum Index und kann über die Eigenschaft Item der Collection WshNamed verwendet werden, um den 'Wert-Teil' (zum Beispiel at1-dc-01) des Arguments abzufragen. Auch für die Methode Exists der Collection WshNamed können Sie den 'Argument-Teil' verwenden. Diese Methode prüft, ob das entsprechende Argument beim Scriptstart angegeben wurde. Wie Sie in Abbildung 3.9 sehen, werden Slash und Doppelpunkt verworfen, und nur der tatsächliche Parametername (s) und der Wert des Parameters (at-dc-01) werden in der Collection gespeichert. Wie in der Collection WshArguments auch, können Sie in der Collection WshNamed über die Methoden Count und die Eigenschaft Length die Anzahl der Argumente in der Collection abrufen.

Es gibt also drei Wege, um auf die Kommandozeilenargumente zuzugreifen:

• Sie können über die Collection WshArguments auf alle Argumente zugreifen.
• Über die Collection WshNamed können Sie nur auf die Argumente zugreifen, bei denen ein zusätzlicher Wert angegeben wurde (zum Beispiel /s:at-dc-01).
• Über die Collection WshUnnamed können Sie auf die Argumente zugreifen, bei denen keine zusätzlichen Werte angegeben wurden (zum Beispiel /u).

Verwenden der standardmäßigen Argument-Collection WshArguments

Auf die Collection WshArguments greifen Sie über Eigenschaft Arguments des Objekts WScript zu. Die Collection WshArguments stellt zwei Methoden und vier Eigenschaften für die Arbeit mit Argumenten zur Verfügung.

Methoden

• Count - Gibt die Gesamtzahl der Argumente in der Collection WshArguments zurück.
• ShowUsage - Gibt Informationen zur Verwendung des Scripts aus. Diese Informationen werden dem Abschnitt runtime einer WSF-Datei (Windows Script File - .wsf) entnommen. WSF-Dateien werden in diesem Buch nicht besprochen.

Eigenschaften

• Named - Stellt einen Zugriff auf die Collection WshNamed zur Verfügung. WshNamed ist eine gefilterte Collection, in der alle Argumente im Format /name:wert gespeichert sind. Solche Argumente werden im WSH auch 'Named Arguments' (benannte Argumente) genannt.
• Unnamed - Stellt einen Zugriff auf die Collection WshUnnamed zur Verfügung. WshUnnamed ist eine gefilterte Collection mit den Argumenten, die nicht im Format /name:wert angegeben wurden. Solche Argumente werden im WSH auch 'Unnamed Arguments' (unbenannte Argumente) genannt.
• Length - Gibt die Gesamtzahl der Argumente in der Collection WshArguments an.

Anmerkung:
Vielleicht ist Ihnen aufgefallen, das die Eigenschaft Length mit der Methode Count gleichbedeutend ist. Die Eigenschaft Length wurde nur aufgenommen, um der ECMAScript-Sprachspezifikation zu entsprechen (Standard ECMA-262), auf der auch JScript basiert. Auch wenn Sie unter VBScript sowohl Count als auch Length verwenden können, müssen Sie unter JScript explizit Length verwenden.

• Item(n) - Gibt das Element mit der angegebenen Indexnummer (n) der Collection WshArguments zurück.

Mit dem folgenden Befehl wird ein Script mit dem Namen GetEvents.vbs und drei Argumenten ausgeführt:

cscript getevents.vbs atl-dc-01 "Directory Service" 1130

WSH speichert die drei Argumente in der Reihenfolge in der Collection WshArguments, in der sie angegeben wurden. Um die drei Argumente auszulesen, verwenden Sie die Eigenschaft Arguments des Objekts WScript in Kombination der Eigenschaft WshArguments.Item:

ServerName = WScript.Arguments.Item(0)
EventLog = WScript.Arguments.Item(1)
EventID = WScript.Arguments.Item(2)

Da alle Collections bei 0 beginnen, erhalten Sie mit WScript.Arguments.Item(0) das erste Argument zurück. WScript.Arguments.Item(1) liefert Ihnen das zweite Argument (dieses Argument wurde in Anführungszeichen eingeschlossen, da es Leerzeichen enthält). WScript.Arguments.Item(2) liefert Ihnen das dritte Argument zurück.

Die Inhalte der Collection sehen Sie in Tabelle 3.6.

Tabelle 3.6: Beispielinhalte der Collection WSHArguments

Item	Wert
0	atl-dc-01
1	Directory Service
2	1130

Wenn das Script mit weiteren Argumenten aufgerufen worden wäre, dann würde WScript.Arguments.Item(3) das vierte Argument zurückliefern usw.

Es gibt keine Beschränkung für die Anzahl der Argumente, die in der Collection WshArguments gespeichert werden können. Die gesamte Befehlszeile darf jedoch die maximale Länge der Kommandozeile nicht überschreiten.

Sie können sich viel Arbeit sparen, wenn Sie die Collection WshArguments einer Variablen zuweisen. So brauchen Sie nicht jedes Mal WScript.Arguments schreiben, wenn Sie auf ein Argument zugreifen möchten, sondern können den Namen der Variable nutzen. Verwenden Sie hierzu das VBScript-Schlüsselwort Set, gefolgt von dem Variablennamen. Das Schlüsselwort Set ist erforderlich, da es sich bei Collections um normale COM-Objekte handelt. Das folgende Beispiel macht genau das Gleiche, wie das vorhergehende Beispiel. Es verwendet jedoch zum Zugriff auf die Collection eine Variable:

Set args = WScript.Arguments
ServerName = args.Item(0)
EventLog = args.Item(1)
EventID = args.Item(2)

Die letzten drei Beispiele gehen alle davon aus, dass mit GetEvents.vbs immer drei Argumente übergeben werden. Bei einem eben schnell geschriebenen Ad-Hoc-Script können Sie möglicherweise darauf verzichten, die Anzahl der übergebenen Argumente zu überprüfen, bei anderen Scripten kann dies jedoch schnell zu Fehlern führen - ganz besonders dann, wenn auch andere Benutzer das Script verwenden sollen.

Die folgende Zeile startet das Script GetEvents.vbs ohne Argumente:

cscript getevents.vbs

In diesem Beispiel würden alle drei oben verwendeten Beispielscripte zu folgendem Laufzeitfehler führen:

C:\test.vbs(2, 1) Laufzeitfehler in Microsoft VBScript: Index außerhalb des gültigen Bereichs

Wenn Sie versuchen auf ein Item zuzugreifen, das nicht existiert, kommt es zu diesem Laufzeitfehler. In Script 3.6 sehen Sie, wie Sie über die Methode WshArguments.Count sicherstellen können, dass beim Scriptstart die richtige Anzahl von Argumenten verwendet wurde.

Script 3.6: Anzahl der übergebenen Argumente über Count prüfen

1 2 3 4 5 6 7 8	If WScript.Arguments.Count = 3 Then ServerName = WScript.Arguments.Item(0) EventLog = WScript.Arguments.Item(1) EventID = WScript.Arguments.Item(2) Else Wscript.Echo "Verwendung: GetEvents.vbs ServerName EventLog EventID" Wscript.Quit End If

In Zeile 1 des Scripts wird die Methode WshArguments.Count verwendet, um die Anzahl der übergebenen Argumente abzufragen. Wenn es sich um drei Argumente handelt, dann weist das Script diese den Variablen ServerName, EventLog und EventID zu. Andernfalls gibt das Script eine Information zur Verwendung des Scripts aus.

Unbenannte Kommandozeilenargumente

Unbenannte (Unnamed) Argumente bestehen nur aus einem einzelnen Wert. Solange die Reihenfolge der Argumente nicht egal ist (zum Beispiel, wenn drei Computernamen angegeben werden und es egal ist, welcher Computer als Erstes abgefragt wird), müssen die Argumente in der vom Script erwarteten Reihenfolge angegeben werden.

Unbenannte Argumente können Sie in den folgenden Fällen verwenden:

• Wenn das Script nur ein oder zwei Argumente verwendet - zum Beispiel den Namen eines Ordners. In diesem Fall gibt es keinen Grund, benannte (Named) Argumente zu verwenden.
• Wenn im Script alle Argumente gleich behandelt werden - wenn Sie zum Beispiel die Ereignisprotokolle auf bestimmten Computern abfragen wollen, dann können Sie für die Computernamen unbenannte Argumente verwenden.

Wenn Sie ein Script mit unbenannten Argumenten ausführen, dann werden diese von WSH in der Collection WshArguments gespeichert - und zwar in der Reihenfolge, in der Sie bei Scriptstart angegeben wurden. Sie können im Script über die Indexnummern auf die Argumente zugreifen. Diese beginnen bei 0.

Script 3.7 verwendet die Collection-Arguments zur Anzeige der verwendeten Argumente.

Script 3.7: Abfragen der Kommandozeilenargumente über die Collection Arguments

1 2 3 4 5 6 7	strServer = WScript.Arguments.Item(0) strPacketSize = WScript.Arguments.Item(1) strTimeout = WScript.Arguments.Item(2) Wscript.Echo "Anzupingender Server: " & strServer Wscript.Echo "Paketgröße: " & strPacketSize Wscript.Echo "Timeout: " & strTimeout

Die folgende Befehlszeile führt das Script mit Argumenten aus - und zwar in der Reihenfolge, in der das Script die Argumente erwartet:

EchoUnnamedArgs.vbs DCServer01 100 5000

Das Script erzeugt die folgende Ausgabe:

Anzupingender Server: DCServer01
Paketgröße: 100
Timeout: 5000

Die folgende Befehlszeile führt das gleiche Script aus. Die Argumente werden jedoch in einer falschen Reihenfolge angegeben:

EchoUnnamedArgs.vbs 100 DCServer01 5000

Das Script produziert die folgende Ausgabe:

Anzupingender Server: 100
Paketgröße: DCServer01
Timeout: 5000

Die Ausgabe im ersten Versuch ist korrekt - die Ausgabe im zweiten Versuch ist hingegen falsch. Da das Script mit unbenannten Argumenten arbeitet, und diese nicht über Ihren Namen, sondern nur in der Eingabereihenfolge ausgelesen werden können, ist das Script darauf angewiesen, dass die Argumente in der korrekten Reihenfolge angegeben werden. Wenn das Script im zweiten Versuch ping.exe mit den Argumenten ausgeführt hätte, dann hätte dies zu einem Fehler geführt - es gibt keinen Server mit dem Namen 100 oder eine Paketgröße von DCServer01.

Benannte Kommandozeilenargumente

Wie das vorhergehende Beispiel zeigt, ist die Reihenfolge der Argumente bei unbenannten Argumenten für die erfolgreiche Ausführung des Scripts entscheidend. Der Aufruf des Scripts wird so unnötig kompliziert. Der Benutzer muss sich nicht nur an die Parameter, sondern auch noch an deren Reihenfolge erinnern. Kommt es in diesem Zusammenhang zu einem Fehler, schlägt das Script fehl.

Um den Aufruf von Scripten mit mehreren Argumenten zu vereinfachen, können Sie benannte Argumente verwenden. Benannte Argumente sind die Argumente, die aus einem Namen und einem dazugehörigen Wert bestehen (zum Beispiel /s:DCServer01). Sie können in jeder beliebigen Reihenfolge angegeben werden.

Ein benanntes Argument beginnt im mit einem Slash (/) und dem Namen des Arguments. Dann folgt durch einen Doppelpunkt vom Namen getrennt der Wert des Arguments. Die folgende Befehlszeile führt ein Script mit dem Namen ServerTest.vbs mit zwei benannten Argumenten aus:

ServerTest.vbs /Server:HRServer01 /Timeout:3000

Der Name des ersten Arguments lautet Server - sein Wert ist HRServer01. Der Name des zweiten Arguments lautet Timeout und sein Wert ist 3000. Diese beiden Argumente könnten auch in umgekehrter Reihenfolge angegeben werden:

ServerTest.vbs /Timeout:3000 /Server:HRServer01

Die benannten Argumente eines Scripts werden in der Collection WshNamed gespeichert.

Script 3.8 verwendet diese Collection, um die Argumente anzuzeigen.

Script 3.8: Abfragen von Argumenten über die Collection WshNamed

1 2 3 4 5 6 7 8	Set colNamedArguments = WScript.Arguments.Named strServer = colNamedArguments.Item("Server") strPacketSize = colNamedArguments.Item("PacketSize") strTimeout = colNamedArguments.Item("Timeout") Wscript.Echo "Servername: " & strServer Wscript.Echo "Paketgröße: " & strPacketSize Wscript.Echo "Timeout (ms): " & strTimeout

Über die folgende Befehlszeile wird das Script zusammen mit drei benannten Argumenten ausgeführt:

EchoNamedArgs.vbs /Server:HRServer01 /PacketSize:300 /Timeout:8000

Das Script erzeugt die folgende Ausgabe

Servername: HRServer01
Paketgröße: 300
Timeout (ms): 8000

Die nächste Befehlszeile führt dasselbe Script aus. Die Argumente werden jedoch in einer anderen Reihenfolge angegeben:

EchoNamedArgs.vbs /Timeout:8000 /PacketSize:300 /Server:HRServer01

Trotzdem erzeugt auch dieses Script die folgende Ausgabe

Servername: HRServer01
Paketgröße: 300
Timeout (ms): 8000

Die Ausgabe ist bei beiden Befehlszeilen gleich. Sie können die Argumente in jeder beliebigen Reihenfolge angeben.

Auch wenn Sie optionale Parameter verwenden wollen, sind benannte Argumente sinnvoll. Script 3.9 entspricht Script 3.8. Das Argument PacketSize ist jedoch optional. Wenn der Benutzer keine Paketgröße angibt, verwendet das Script eine Standardpaketgröße.

Das Script verwendet die Methode Exists um zu prüfen, ob das Argument PacketSize angegeben wurde. Wenn das Ergebnis der Prüfung Wahr (True) ist, dann fährt das Script mit Zeile 7 fort. Wenn das Ergebnis der Prüfung Falsch (False) ist, dann geht es mit Zeile 9 weiter. In Zeile 9 wird die Variable PacketSize über die Konstante DEFAULT_PACKET_SIZE auf den Wert 100 gesetzt.

Script 3.9: Kommandozeilenargumente und Standardwerte

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Const DEFAULT_PACKET_SIZE = 100 Set colNamedArguments = WScript.Arguments.Named strServer = colNamedArguments.Item("Server") If colNamedArguments.Exists("PacketSize") Then strPacketSize = colNamedArguments.Item("PacketSize") Else strPacketSize = DEFAULT_PACKET_SIZE End If strTimeout = colNamedArguments.Item("Timeout") Wscript.Echo "Server Name: " & strServer If colNamedArguments.Exists("PacketSize") Then Wscript.Echo "Packet Size :" & strPacketSize Else Wscript.Echo "Packet Size [default]: " & strPacketSize End If Wscript.Echo "Timeout (ms): " & strTimeout

Unbenannte und benannte Argumente verwenden

Normalerweise sollten Sie benannte und unbenannte Argumente nicht zusammen in einem Script verwenden. Der Scriptaufruf wird so nur unnötig kompliziert. Wenn Sie zwei oder ein Argument verwenden, sollten Sie unbenannte Argumente nutzen. Bei mehr als zwei Argumenten ist es besser benannte Argumente zu verwenden.

Wenn Sie jedoch beide Argumenttypen zusammen verwenden, dann müssen die unbenannten Argumente beim Scriptaufruf zuerst angegeben werde:

CheckServer.vbs HRServer01 /timeout:200 /logfile:serverlog.txt /verbose:true

Überprüfen von Kommandozeilenargumenten

Viele Scripte benötigen eine bestimmte Anzahl von Argumenten. Um sicherzustellen, dass die Argumente angegeben wurden, haben Sie zwei Möglichkeiten:

• Sie prüfen, ob die Zahl der angegeben Argumente der erforderlichen Argumentzahl entspricht.
• Sie prüfen, ob die erforderlichen Argumente angegeben wurden.

Die Anzahl der angegebenen Argumente prüfen

Stellen Sie sich vor, Sie schreiben ein Script, das Dateien von einem Computer zum anderen kopiert. Ein solches Script erfordert wahrscheinlich genau zwei Argumente: den Namen des Quellcomputers und den Namen des Zielcomputers.

In einem solchen Fall sollten Sie in Ihrem Script als Erstes prüfen, ob die erforderliche Argumentzahl angegeben wurde. Dies können Sie am einfachsten über die Eigenschaft Count der entsprechenden Collection durchführen. Wenn Wscript.Arguments.Count den Wert 2 hat, dann gibt es zwei Argumente.

Script 3.10 prüft die Anzahl der übergebenen Argumente. Das Script akzeptiert bis zu vier Argumente - zwei von diesen sind optional. Daher muss der Benutzer mindestens zwei und höchstens vier Argumente angeben.

Script 3.10: Überprüfen der angegebenen Argumente

1 2 3 4 5 6 7 8 9	iNumberOfArguments = WScript.Arguments.Count If iNumberOfArguments >= 2 And iNumberOfArguments <= 4 Then Wscript.Echo iNumberOfArguments & " arguments entered. " & _ "Gültige Argumentzahl." Else Wscript.Echo "Fehler: Falsche Argumentzahl angegeben. " & _ "Bitte geben Sie 2, 3 oder 4 Argumente an." Wscript.Quit End If

In Zeile 1 des Scripts wird über die Eigenschaft WScript.Arguments.Count festgestellt, wie viele Argumente angegeben wurden. Das Script speichert diese Zahl in der Variable iNumberOfArguments.

In Zeile 2 verwendet das Script die Bedingung iNumberOfArguments =2 And iNumberOfArguments =4 um zu prüfen, ob der Benutzer 2, 3 oder 4 Argumente angegeben hat:

• Wenn die Bedingung Wahr (True) ist, dann fährt das Script mit Zeile 3 fort und gibt einen Text aus, der anzeigt, dass die Argumentzahl gültig war.
• Wenn die Bedingung Falsch (False) ist, dann fährt das Script mit Zeile 6 fort und gibt einen Text aus, der anzeigt, dass die Argumentzahl ungültig war.

Die folgende Befehlszeile führt das Script mit mehr als vier Argumenten aus:

CheckNumArgs.vbs HRServer01 RASServer01 SQLServer01 1000 300

Das Script produziert die folgende Ausgabe:

Fehler: Falsche Argumentzahl angegeben. Bitte geben Sie 2, 3 oder 4 Argumente an.'

Diese Befehlszeile führt das Script mit drei Argumenten aus:

CheckNumArgs.vbs HRServer01 1000 300

Das Script produziert die folgende Ausgabe:

Gültige Argumentzahl.

Überprüfen, ob alle erforderlichen Argumente angegeben wurden

Wenn Sie Argumente in Ihrem Script verwenden, dann sollte das Script überprüfen, ob alle erforderlichen Argumente angegeben wurden. Unglücklicherweise gibt es keine Möglichkeit WSH mitzuteilen, dass ein bestimmtes Argument zwingend erforderlich ist. Sie müssen sich also selbst darum kümmern, dass die erforderlichen Argumente angegeben werden.

Wenn bestimmte Argumente für Ihr Script erforderlich sind, dann sollten Sie benannte Argumente verwenden. Ein Vorteil von benannten Argumenten ist, dass Sie mit der Methode Exists prüfen können, ob das Argument angegeben wurde. Die folgende Codezeile prüft, ob das Argument mit dem Namen FolderName angegeben wurde. Wenn es vorhanden ist, dann wird der Wert-1 (True) ausgeben - andernfalls lautet die Ausgabe 0 (False):

Wscript.Echo colNamedArguments.Exists("FolderName")

Script 3.11 baut auf Script 3.10 auf. In Zeile 4 verwendet das Script die Bedingung Not colNamedArgument.Exists("Server") um zu testen, ob der Benutzer das benannte Argument Server angegeben hat.

• Wenn der Test feststellt, dass das Argument nicht angegeben wurde, fährt das Script mit Zeile 5 fort. Dort wird eine Nachricht ausgegeben, die dem Benutzer mitteilt, dass das Argument Server fehlt. In Zeile 6 wird der Befehl Wscript.Quit verwendet, um das Script anzuhalten.
• Wenn der Test feststellt, dass das Argument angegeben wurde, fährt das Script mit Zeile 7 fort. In den Zeilen 9 und 10 wird der Befehl colNamedArguments.Item("Server") verwendet, um den Wert des Argumentes Server abzufragen. Dann zeigt das Script eine Nachricht an.

Script 3.11: Überprüfen, ob alle erforderlichen Argumente angegeben wurden

1 2 3 4 5 6 7 8 9 10 11 12 13 14

iNumberOfArguments = WScript.Arguments.Count Set colNamedArguments = WScript.Arguments.Named If Not colNamedArguments.Exists("Server") Then Wscript.Echo "Verwendung: /Server:<servername> ist erforderlich." Wscript.Quit ElseIf iNumberOfArguments >= 2 Or iNumberOfArguments <= 4 Then Wscript.Echo iNumberOfArguments & " Argumente angegeben" Wscript.Echo "inklusive Servername: " & _ colNamedArguments.Item("Server") Else Wscript.Echo "Verwendung: Geben Sie 2 bis 4 Argumente an." Wscript.Quit End If

Die folgende Befehlszeile versucht das Script ohne das Argument Server auszuführen:

CheckReqArgs.vbs 1000 300

Das Script produziert die folgende Ausgabe:

Verwendung: /Server:<servername> ist erforderlich.

Die nächste Befehlszeile startet das Script mit dem erforderlichen Argument:

CheckReqArgs.vbs /Server:HRServer01 1000 300

Das Script produziert die folgende Ausgabe:

3 Argumente angegeben
Inklusive Servername: HRServer01

Die Scriptausführung steuern

Wenn Sie ein Script ausführen, werden die Befehle im Script normalerweise von oben nach unten ausgeführt. Es gibt keine Pausen, und das Script ist erst beendet, wenn die letzte Befehlszeile abgearbeitet wurde.

Das Objekt WScript stellt zwei Eigenschaften (Timeout und Interactive) und zwei Methoden (Sleep und Quit) zur Verfügung, über die Sie die Scriptausführung kontrollieren können. Sie haben folgende Möglichkeiten:

• Das Script für einen bestimmen Zeitraum anhalten.
• Die Scriptausführung sofort beenden.
• Die Scriptausführung nach einer bestimmen Zeitspanne beenden.

Ein Script anhalten

Normalerweise führt WSH ein Script so schnell wie möglich aus. Meist ist dies auch das gewünschte Verhalten - je schneller das Script beendet ist, desto besser.

Es gibt jedoch auch Fälle, in denen Sie nicht möchten, dass das Script so schnell wie möglich ausgeführt wird. Zum Beispiel dann, wenn Sie zum Beispiel alle 10 Sekunden die Prozessorauslastung abfragen möchten - und zwar so lange, bis 100 Messungen vorgenommen wurden.

Sie können die Ausführung eines Scripts mit der Methode Sleep des Objekts WScript für einen bestimmen Zeitraum anhalten. Die Methode erwartet als Parameter den Zeitraum in Millisekunden, für den das Script angehalten werden soll (eine Sekunde hat 1.000 Millisekunden und eine Minute hat 60.000 Millisekunden).

In folgenden Situationen können Sie die Methode Sleep verwenden:

• Wenn Sie auf ein bestimmtes Ereignis warten müssen.
• Wenn Sei möchten, dass Ihr Script einen bestimmten Status in regelmäßigen Zeitabständen prüft (zum Beispiel alle 10 Sekunden die Prozessorauslastung).
• Wenn Sie die Interaktion mit dem Benutzer auf ein vernünftiges Maß herunterbremsen möchten. Wenn Sie zum Beispiel die Einträge des Ereignisprotokolls anzeigen lassen, möchten Sie möglicherweise, dass eine kurze Pause zwischen den einzelnen Ausgaben liegt.

Script 3.12 prüft den freien Festplattenplatz aller Laufwerke des Computers. Dann wartet das Script 5 Minuten (300.000 Millisekunden) und prüft wiederum den freien Festplattenplatz.

Script 3.12: Das Script mit der Methode Sleep anhalten

1 2 3 4 5 6 7 8 9 10 11 12	strComputer = "." Set objWMIService = GetObject("winmgmts:" _ & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Do While True Set colDisks = objWMIService.ExecQuery _ ("SELECT * FROM Win32_LogicalDisk") For Each objDisk in colDisks Wscript.Echo "DeviceID: " & objDisk.DeviceID Wscript.Echo "Freier Festplattenplatz: " & objDisk.FreeSpace Next Wscript.Sleep 300000 Loop

Anmerkung:
Das Script wird unendlich ausgeführt. Um es zu beenden, müssen Sie den Prozess beenden, unter dem das Script ausgeführt wird (WScript.exe oder CScript.exe).

Ein Script beenden

Im Allgemeinen wird ein Script erst dann beendet, wenn die letzte Zeile ausgeführt wurde. Es mag jedoch Situationen geben, in denen Sie das Script abbrechen möchten, bevor die letzte Scriptezeile ausgeführt wurde. Zum Beispiel, wenn Sie ein Script schreiben, das zwei Argumente benötigt. Wenn der Benutzer nur ein Argument angibt, soll das Script abgebrochen werden.

Sie können ein Script über die Methode WScript.Quit beenden. Mit der Quit-Methode wird das Script sofort beendet. Das folgende Beispielscript gibt zum Beispiel drei Nachrichten aus und wird dann beendet. Die letzten drei Befehle werden niemals ausgeführt:

Wscript.Echo "1"
Wscript.Echo "2"
Wscript.Echo "3"
Wscript.Quit
Wscript.Echo "4"
Wscript.Echo "5"
Wscript.Echo "6"

Einen Time-Out-Wert für ein Script verwenden

Auch wenn eigentlich jedes Script einen Time-Out-Wert verwenden sollte, ist dies ganz besonders für Scripte wichtig, die möglicherweise unendlich ausgeführt werden können.

Stellen Sie sich zum Beispiel vor, ein Script muss sich als Erstes mit einem Remotecomputer verbinden. Was passiert, wenn diese Verbindung nicht aufgebaut werden kann? Das Script könnte zum Beispiel 60 Sekunden warten und einen neuen Verbindungsversuch starten. Dies könnte das Script so lange fortführen, bis die Verbindung zustande kommt.

Was aber, wenn der Zielcomputer permanent aus dem Netzwerk entfernt wurde? In diesem Fall wird das Script theoretisch für immer ausgeführt. Hier könnte es also praktisch sein, einen Time-Out-Wert zu definieren. Wenn eine bestimmte Aufgabe im definierten Zeitraum nicht ausgeführt werden kann, dann soll das Script beendet werden.

Die Eigenschaft WScript.Timeout definiert einen solchen Zeitraum in Sekunden (standardmäßig wird das Script unendlich ausgeführt). Script 3.13 setzt den Time-Out auf 5 Sekunden. Wenn das Script also nach fünf Sekunden nicht von selbst beendet wurde, wird es automatisch beendet. Da im Script in Zeile 2 eine Pause von 60 Sekunden definiert ist, wird es immer durch den Time-Out abgebrochen. Zeile 3 wird also niemals ausgeführt.

Script 3.13: Verwendung des Time-Out in einem Script

1 2 3	Wscript.Timeout = 5 Wscript.Sleep 60000 Wscript.Echo "Script is finished."

WSH-Umgebungsvariablen abfragen

Das Objekt WScript stellt über einige Eigenschaften Informationen zur Verfügung, die Ihnen zum Beispiel mitteilen, welcher Script Host verwenden wurde und welches Script ausgeführt wurde. Diese Metadaten sehen Sie in Tabelle 3.7.

Tabelle 3.7: WSH-Umgebungsinformationen

Eigenschaft	Beschreibung
ScriptFullName	Vollständiger Pfad des aktiven Scripts (zum Beispiel C:\Scripts\Monitor.vbs).
ScriptName	Dateiname des aktiven Scripts (zum Beispiel Monitor.vbs).
Version	Die WSH-Version (zum Beispiel 5.6).
Build	Die WSH-Buildnummer. Die vollständige Versionsnummer des Windows Script Hosts setzt sich aus der Versionsnummer und der Build-Versionsnummer zusammen. Wenn die Windows Script-Host-Versionsnummer zum Beispiel 5.6 und die Buildversion 6626 ist, dann ist die vollständige Versionsnummer 5.6.6626.
Name	Gibt immer den String Windows Script Host zurück.
FullName	Pfad und Name des Script Hosts (entweder Wscript.exe oder CScript.exe).
Path	Der vollständige Pfad des Ordners, in dem sich der Script Host befindet - ohne Dateiname.

Diese Metadaten können sehr nützlich sein. Über die Versionsnummer können Sie zum Beispiel feststellen, ob die korrekte WSH-Version installiert ist. Wenn Ihr Script beispielsweise die WSH 5.6 voraussetzt, können Sie dies über den folgenden Scriptcode testen:

If Wscript.Version <> "5.6" Then
    Wscript.Echo "Dieses Script muss unter WSH 5.6. ausgeführt werden."
    Wscript.Quit
End If

Oder stellen Sie sich vor, Ihr Script führt eine große Menge an Ausgaben über Wscript.Echo durch. In diesem Fall möchten Sie möglicherweise nicht, dass das Script unter WScript ausgeführt wird - dies könnte zu hunderten von Nachrichtenfenstern führen, die alle per Hand geschlossen werden müssten.

Sie können die verwendete Script Host-Version über die Eigenschaft FullName abfragen. Es reicht allerdings aus, die letzten 11 Zeichen des Wertes zu überprüfen (um sicherzustellen, dass die Überprüfung funktioniert, sollten Sie die Zeichen mit der Funktion UCase in Großbuchstaben umwandeln). Wenn die letzten 11 Zeichen 'WSCRIPT.EXE' sind, wird das Script unter WScript ausgeführt - bei 'CSCRIPT.EXE' handelt es sich beim Script Host um CScript.

Anmerkung:
Warum nur die letzten 11 Zeichen? Der Wert von FullName hängt davon ab, wo der WSH installiert wurde - er könnte "C:\Winnt\System32\CScript.exe" oder auch "E:\Windows\System32\Wscript.exe" sein. Die letzten 11 Zeichen enthalten jedoch immer den Text 'Wscript.exe' oder 'Cscript.exe'.

Das folgende Codestück prüft, welcher Script Host installiert ist und beendet das Script, wenn es sich im WSCRIPT.EXE handelt:

If UCase(Right(Wscript.FullName, 11)) = "WSCRIPT.EXE" Then
    Wscript.Echo "Dieses Script muss unter CScript ausgeführt werden."
    Wscript.Quit
End If

Script 3.14 zeigt alle verfügbaren WSH-Umgebungsinformationen an.

Script 3.14: Anzeigen der verfügbaren WSH-Umgebungsinformationen

1 2 3 4 5 6 7	Wscript.Echo "Script Full Name: " & Wscript.ScriptFullName Wscript.Echo "Script Name: " & Wscript.ScriptName Wscript.Echo "Version: " & WScript.Version Wscript.Echo "Build: " & Wscript.BuildVersion Wscript.Echo "Name: " & Wscript.Name Wscript.Echo "Full Name: " & Wscript.FullName Wscript.Echo "Path: " & Wscript.Path

Die Ausgabe des Scripts sieht so oder ähnlich aus:

Script Full Name: C:\test.vbs
Script Name: test.vbs
Version: 5.6
Build: 8515
Name: Windows Script Host
Full Name: C:\WINDOWS\system32\cscript.exe
Path: C:\WINDOWS\system32

Auf Ereignisse reagieren

Windows ist ein ereignisbasiertes Betriebssystem. Die Ereignisse, die unter Windows generiert werden, sind oftmals das Ergebnis einer Benutzeraktion - zum Beispiel das Klicken auf einen OK-Schalter oder eine Bewegung der Maus. Die meisten Windows-Programme reagieren auf diese Ereignisse. Wenn Sie zum Beispiel eine Anwendung wie Microsoft Word starten, dann wird die Anwendung geladen und wartet darauf, dass Sie etwas tun (zum Beispiel etwas eingeben). Wenn Sie kein Ereignis auslösen, auf das reagiert werden kann, dann wartet Word unendlich.

Außerdem ermöglicht dieser Ereignismechanismus verschiedenen Softwarekomponenten miteinander zu kommunizieren. Wenn ein Ereignis in einer Komponente auftritt (auslösende Komponente), dann wird eine andere Komponente (reagierende Komponente) davon benachrichtigt. Die reagierende Komponente kann dann die notwendige Aktion ausführen.

Die Ereignismechanismen des WSH werden in gewöhnlichen administrativen Scripten normalerweise nicht verwendet. Diese Scripte sind meist prozedurgesteuert. Das bedeutet, wenn Sie einmal gestartet wurden, laufen sie einfach weiter - und zwar ohne auf äußere Ereignisse zu reagieren.

Anmerkung:

Die Möglichkeit Ressourcen zu überwachen und auf deren Ereignisse zu reagieren ist sehr wichtig. Eine solche Ereignisüberwachung führen Sie jedoch am besten über WMI durch. Außerdem kann die Ereignisüberwachung für die Automatisation von GUI-Anwendungen wichtig sein. Scripte können zum Beispiel den Internet Explorer als Benutzerschnittstelle verwenden. In diesem Fall sollte das Script auch auf Ereignisse des Internet Explorers reagieren können. Weitere Informationen zu diesem Thema finden Sie im Kapitel Creating Enterprise Scripts dieses Buches.

Zum Seitenanfang

Das Objekt WshShell

Die Shell ist die Windows-Komponente, die die Benutzerschnittstelle zur Verfügung stellt. Sie ist für Elemente wie den Desktop, den Windows Explorer, das Startmenü, Verknüpfungen und Desktop-Schemata zuständig.

Das Objekt WshShell gibt Ihnen die Möglichkeit mit der Windows-Shell zu arbeiten. Ihre Scripte können über das Objekt eine Vielzahl von administrativen Aufgaben durchführen - inklusive Programme ausführen, Informationen in der Registrierung lesen und schreiben und Erstellen von Verknüpfungen. Die Methoden und Eigenschaften des WshShell-Objekts sehen Sie in Abbildung 3.10.

Abbildung 3.10: Das WshShell-Objektmodell

Auf das WshShell-Object zugreifen

Das WshShell-Object ist ein COM-Objekt. Mit der folgenden Codezeile können Sie eine Instanz des Objekts erstellen:

Set objShell = WScript.CreateObject("WScript.Shell")

Funktionalitäten von WshShell

Das WshShell-Objekt ermöglicht Ihrem Script die Automatisierung von Windows-Shell-bezogenen Aufgaben. In Tabelle 3.8 sehen Sie die Methoden und Eigenschaften des Objekts.

Tabelle 3.8: Methoden und Eigenschaften des WshShell-Objekts

Kategorie	Methode oder Eigenschaft
Programme ausführen	Run, Exec
Arbeiten mit Spezialordnern	SpecialFolders
Arbeiten mit Verknüpfungen	CreateShortcut
Arbeiten mit Umgebungsvariablen	Environment, ExpandEnvironmentStrings
Arbeiten mit dem Ereignisprotokoll	LogEvent
Arbeiten mit der Registrierung	RegRead, RegWrite, RegDelete
Tastendrücke an Anwendungen senden	AppActivate, SendKeys
Abfragen des aktuellen Verzeichnisses des Scripts	CurrentDirectory
Zeitgesteuerte Dialogfenster erstellen	Popup

Programme ausführen

Eine wichtige Lektion, die Sie über Scripting lernen müssen ist: Scripting ist nicht die Antwort auf Ihre gesamten administrativen Anforderungen.

Erstens deckt Scripting nicht 100 Prozent aller administrativen Aufgaben ab - Sie sind zum Beispiel nicht in der Lage, die Offline-Eigenschaften von Ordnern festzulegen. Eine solche Aufgabe müssen Sie weiterhin über die GUI oder über Net.exe durchführen.

Und zweitens gibt es keinen Grund ein Script zu schreiben, wenn es bereits ein Tool gibt, das Ihren Bedürfnissen entspricht. Nehmen wir an, Sie benötigen eine Liste der in einem Ordner auf dem lokalen Computer gespeicherten Dateien. Sie können entweder viel Zeit aufwenden, um ein entsprechendes Script zu schreiben - oder Sie können den Befehl dir eingeben.

WSH-Scripte können zwar Aufgaben automatisieren, sie ersetzten jedoch nicht alle Kommandozeilentools und Batchdateien, die Sie bis jetzt verwendet haben. Wenn Sie eine Batchdatei für eine Aufgabe haben, dann gibt es keinen Grund ein Script zu erstellen, das die gleiche Aufgabe ausführt.

Andererseits möchten Sie möglicherweise die Fähigkeiten einer Batchdatei mit den Möglichkeiten der WSH-Scriptumgebung kombinieren. Stellen Sie sich zum Beispiel vor, dass Sie ein Programm zum Aufräumen der Festplatte nur dann ausführen wollen, wenn der freie Platz auf der Festplatte unter einen bestimmten Wert sinkt. Dies ist mit einer Batchdatei schwer möglich - mit einem WSH-Script jedoch ganz einfach. Den freien Festplattenplatz können Sie über das Objekte FileSystemObject oder über WMI abfragen und dann das Programm zum Aufräumen der Festplatte starten.

Ein Vorteil des WSH ist es, dass Sie sich nicht zwischen WSH oder Batchdatei und Kommandozeilentools entscheiden müssen. Mit dem WSH schließen sich die beiden Ansätze nicht gegenseitig aus - stattdessen ergänzen sie sich gegenseitig. Sie können zum Beispiel die Methoden Run und Exec des Objekts WshShell verwenden, um Batchdateien oder Kommandozeilentools auszuführen.

Die beiden Methoden sind nicht auf Batchdateien oder Kommandozeilentools eingeschränkt. Sie können auf diese Art jede beliebige ausführbare Datei aus Ihrem Script heraus starten.

Unterschiede zwischen Run und Exec

Es gibt zwei Wege, Programme aus Ihrem Script heraus zu starten - welchen sollen Sie verwenden? Die Antwort zu dieser Frage hängt von Ihrem Script und von dem, was Sie mit dem Script erreichen wollen, ab.

Sie verwenden die Methoden Run und Exec fast genauso wie Sie ein Programm über das Dialogfenster Ausführen im Startmenü ausführen. Egal welche Methode Sie verwenden: Das Programm wird in einem neuen Prozess gestartet. Wenn Sie die Methode Run verwenden, hat Ihr Script jedoch keinen Zugriff auf die Standard-Eingabe-, -Ausgabe- und -Fehlerkanäle des gestarteten Programms.

Stellen Sie sich zum Beispiel vor, Sie möchten ping.exe starten und seine Ausgaben in Ihrem Script weiter verarbeiten. Über Run ist dies nicht möglich. Sie müssten stattdessen ping.exe starten, dessen Ausgaben in einer Datei speichern und dieses Datei mit Ihrem Script einlesen.

Das folgende Script verwendet die Methode Run, um ping.exe zu starten. Die Ausgaben von ping.exe werden in eine temporäre Datei umgeleitet. Das Script öffnet dann diese Textdatei, prüft, ob der Ping-Befehl erfolgreich ausgeführt wurde (ob Zeilen der Ausgabe mit dem Wort 'Antwort' beginnen) und löscht die Datei dann:

Set objFSO = Wscript.CreateObject("Scripting.FileSystemObject")
Set objShell = Wscript.CreateObject("Wscript.Shell")
objName = objFSO.GetTempName
objTempFile = objName
objShell.Run "cmd /c ping -n 3 -w 1000 157.59.0.1 >" & objTempFile, 0, True
Set objTextFile = objFSO.OpenTextFile(objTempFile, 1)
Do While objTextFile.AtEndOfStream <> True
    strText = objTextFile.ReadLine
    If Instr(strText, "Antwort") > 0 Then
        Wscript.Echo "Antwort erhalten."
        Exit Do
    End If
Loop
objTextFile.Close
objFSO.DeleteFile(objTempFile)

Auch wenn dieser Ansatz durchaus funktioniert, ist er doch etwas kompliziert. Wenn Sie auf die Ausgaben eines Programms zugreifen müssen, dann sollten Sie die Methode Exec verwenden. Auch das folgende Script interpretiert die Ausgaben von ping.exe. Es verwendet hierzu jedoch die Methode Exec. So kann es die Ausgaben direkt einlesen - es muss keine temporäre Datei erstellen, öffnen, lesen und löschen. Das Script ist so nur noch 9 Zeilen statt 15 Zeilen lang:

Set objShell = WScript.CreateObject("WScript.Shell")
Set objExecObject = objShell.Exec("cmd /c ping -n 3 -w 1000 157.59.0.1")
Do While Not objExecObject.StdOut.AtEndOfStream
    strText = objExecObject.StdOut.ReadLine()
    If Instr(strText, "Antwort") > 0 Then
        Wscript.Echo "Antwort erhalten."
        Exit Do
    End If
Loop

In vielen Fällen ist die Methode Exec die bessere Wahl. Aber auch die Run-Methode ist in einigen Situationen ganz nützlich:

• Wenn Sie eine Anwendung in einem bestimmten Fenstertyp, zum Beispiel einem minimierten Fenster, öffnen möchten, dann stellt Ihnen Run die in Tabelle 3.9 zu sehenden Optionen zur Verfügung.
• Wenn Sie ein Script auf einem Computer ausführen müssen, auf dem der WSH 5.6 nicht installiert ist. Exec wird erst ab WSH 5.6 unterstützt.
• Wenn Sie vor der weiteren Scriptausführung warten möchten, bis die gestartete Anwendung wieder beendet wurde. Dies ist zwar auch über Exec möglich, mit Run ist es jedoch einfacher.

Ausführen von Programmen

Die Methode Run verwendet drei Parameter. Nur der erste Parameter ist jedoch zwingend erforderlich - er definiert den Namen des Programms, das Sie ausführen möchten. Wenn sich das Programm im gleichen Ordner wie das Script befindet, reicht der Name der Programmdatei aus (zum Beispiel calc.exe). Andernfalls müssen Sie den vollständigen Pfad angeben (zum Beispiel C:\Admin\Monitoring\DiskSpace.exe).

Beim zweiten Parameter handelt es sich um einen Integer-Wert. Dieser legt den Fensterstil fest, mit dem das Programm gestartet wird (wenn das Programm in einem Fenster ausgeführt wird). Die möglichen Werte dieses Parameters sehen Sie in Tabelle 3.9.

Tabelle 3.9: Werte für den Parameter Window-Stil der Methode Run

Wert	Beschreibung
0	Verstecktes Fenster
1	Aktiviert das Fenster und zeigt es an. Wenn das Fenster minimiert oder maximiert ist, werden Originalgröße und -position des Fensters wiederhergestellt.
2	Aktiviert das Fenster und zeigt es minimiert an.
3	Aktiviert das Fenster und zeigt es maximiert an.
4	Zeigt das Fenster mit seiner letzten Größe und Position an. Das aktive Fenster bleibt aktiv.
5	Aktiviert das Fenster und zeigt es mit seiner aktuellen Größe und Position an.
6	Minimiert das Fenster und aktiviert das nächste Fenster in Z-Reihenfolge. Bei der Z-Reihenfolge handelt es sich um eine Liste, in der die Fenster aktiviert werden. Sie können die Liste sehen, wenn Sie ALT+TAB drücken.
7	Zeigt das Fenster minimiert an. Das aktive Fenster bleibt aktiv.
8	Zeigt das Fenster in seinem Zustand an. Das aktive Fenster bleibt aktiv.
9	Aktiviert das Fenster und zeigt es an. Wen das Fenster minimiert oder maximiert ist, dann werden seine Originalgröße und -position wiederhergestellt.
10	Setzt den Anzeigezustand des Fensters auf Basis des Anzeigezustands des Programms, das die Anwendung gestartet hat.

Script 3.15 startet Notepad. In Zeile 1 definiert das Script die Konstante MAXIMIZE_WINDOW mit dem Wert 3 (aktiviert und maximiert). In Zeile 3 verwendet das Script die Methode Run des Objekts WshShell, um Notepad zu starten. Hierbei übergibt es den Wert der Konstante MAXIMIZE_WINDOW als zweiten Parameter.

Script 3.15: Ein Programm über die Methode Run starten

1 2 3	Const MAXIMIZE_WINDOW = 3 Set objShell = WScript.CreateObject("WScript.Shell") objShell.Run "notepad.exe", MAXIMIZE_WINDOW

Anmerkung:
Der Parameter Windows-Stil wird nicht von allen Anwendungen verarbeitet. Die Systemsteuerung (control.exe) wird zum Beispiel immer in der gleichen Form geöffnet - egal welcher Fensterstil im Script definiert wurde.

Die Methode Run akzeptiert noch einen dritten Parameter. Dieser muss ein Boolean-Wert (also nur True oder False) sein. Wenn der Wert False ist (die Standardeinstellung), dann kümmert sich Run nicht darum, ob das Programm ausgeführt wird. Wenn der Wert auf True gesetzt ist, dann wartet das Script darauf, dass das Programm beendet wurde. Wenn Sie den Wert auf False setzen, dann können Sie also gleich mehrere Programme starten.

Das folgende Script führt den Windows-Taschenrechner aus und wartet dann, bis dieser beendet wurde. Erst dann wird die nächste Zeile ausgeführt. Wenn der Taschenrechner nicht geschlossen wird, dann wird Zeile 3 nicht ausgeführt:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run("calc.exe"),1,True
Wscript.Echo "Script completed."

Anmerkung:
Der WSH verfolgt die gestarteten Instanzen von Programmen. Wenn Sie den Taschenrechner zum Beispiel über ein Script starten, und dann den Taschenrechner noch einmal per Hand starten, dann wird das Script erst dann weiter ausgeführt, wenn Sie die vom Script gestartete Instanz des Taschenrechners beenden.

Ausführen von Kommandozeilentools

Das Ausführen von Kommandozeilentools ist sowohl über Run als auch über Exec möglich - in diesem Fall müssen Sie jedoch eine leicht andere Syntax als bei GUI-Programmen verwenden. Sie müssen den Kommandozeilentools einen der folgenden Werte voranstellen:

• %comspec% /k
• %comspec% /c

Bei %comspec% handelt es sich um eine Umgebungsvariable, die den Kommandozeilenprozessor zurückgibt. Mit ihr können Sie Scripte erstellen, die sowohl unter Windows 98 (hier ist der Kommandozeilenprozessor command.exe) und unter Windows 2000 (hier ist der Kommandozeilenprozessor cmd.exe) ausgeführt werden können.

Sie müssen die Variable %comspec% nicht verwenden - sie bietet jedoch den Vorteil, dass das Kommandozeilenfenster nach der Ausführung des Tools geöffnet bleibt (ohne dass Sie den Kommandozeilenprozessor mit angeben wird das Fenster geöffnet, das Tool wird ausgeführt, und das Fenster wird wieder geschlossen - Sie haben also nicht viel Zeit, die Ausgaben zu lesen).

Außerdem ist die Variable %comspec% der einzige Weg, Kommandozeilenbefehle wie zum Beispiel dir zu verwenden (dies liegt daran, dass dir kein Standardtool ist - es gibt kein Programm mit dem Namen dir.exe). Das folgende Script produziert daher nur einen Fehler:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run("dir"), 1, True

Dieses Script startet als Erstes den Kommandointerpreter und führt den dir-Befehl dann im Kommandointerpreter aus:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run("%comspec% /K dir"), 1, True

Über die Paramter /k und /c können Sie angeben, dass das Kommandozeilenfenster nach der Scriptausführung geöffnet bleibt (/k) oder geschlossen wird (/c).

Das folgende Script startet zum Beispiel das Tool Cacls.exe. Dies zeigt in diesem Fall die Berechtigung des Ordners C:\Scripts an. Das Script sorgt dafür, dass das Fenster geöffnet bleibt, so dass Sie die Ausgaben lesen können:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run("%comspec% /c sc.exe stop alerter"), 1, True

Das folgende Script startet das Tool Sc.exe und hält den Warndienst an. Sobald das Script ausgeführt wurde, wird auch das Fenster wieder geschlossen:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run("%comspec% /k sc.exe getkeyname "Upload Manager""), 1, True

Leerzeichen in Kommandozeilenparametern

Wenn die an ein Kommandozeilentool übergebenen Parameter Leerzeichen enthalten, dann müssen diese Parameter in Anführungszeichen eingeschlossen werden. Wenn Sie zum Beispiel das Tool Sc.exe zum Beenden des Dienstes Upload Manager verwenden möchten, dann müssen Sie die folgende Syntax verwenden:

sc.exe getkeyname "Upload Manager"

Um denselben Befehl in einem Script auszuführen, müssen Sie ebenfalls den Parameter in Anführungszeichen einschließen. Dies ist jedoch nicht ganz so einfach. Wenn Sie zum Beispiel versuchen die folgende Codezeile zu verwenden, dann erhalten Sie einen Fehler:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run("%comspec% /k sc.exe getkeyname "Upload Manager"), 1, True

Die Fehlermeldung sieht so aus:

Abbildung 3.11: Falsche Angabe der Parameter

Diese Fehlermeldung scheint erst einmal unsinnig - sie sagt, es würde die schließende Klammer fehlen. Im Scriptcode ist jedoch eine schließende Klammer vorhanden. Wie sich herausstellt, liegt das wahre Problem nicht in der Klammer, sondern in den Anführungszeichen. Der WSH sieht das erste Anführungszeichen (das sich direkt vor %comspec% befindet) als Beginn des Kommandostrings der der Methode Run übergeben werden soll. Das zweite Anführungszeichen markiert für den WSH logischerweise das Ende des Kommandostrings. Alles dazwischen ist für den WSH der Befehl, den Sie ausführen möchten. Die Zeile sieht für den WSH also so aus:

objShell.Run("%comspec% /k sc.exe getkeyname "

Da diese Syntax natürlich nicht korrekt ist (die rechte Klammer fehlt ja tatsächlich) kommt es zur Fehlermeldung.

Wenn Sie Anführungszeichen in einem String verwenden möchten, müssen Sie jedes Mal zwei Anführungszeichen schreiben:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run("%comspec% /k sc.exe getkeyname ""Upload Manager"""), 1, True

Ein Programm ausführen und auf dessen Ausgaben zugreifen

Um ein Programm auszuführen und auf dessen Ausgaben zuzugreifen, verwenden Sie die Exec-Methode von WshShell. Sie gibt ein Objekt zurück, das Ihnen einen Zugriff auf die Standard-Eingabe-, -Ausgabe- und -Fehlerkanäle des Programms ermöglicht.

Script 3.16 führt das Kommandozeilentoll ipconfig.exe aus. Dieses Tool fragt Informationen über die Netzwerkkonfiguration des Computers ab - inklusive der aktuellen IP-Adresse des Computers. Das Script fragt dann die Ausgaben des Tools über dessen Ausgabekanal ab und geht diese Ausgabe zeilenweise durch. Wenn es in einer Zeile das Wort 'Adresse' findet, gibt es die Zeile aus.

Script 3.16: Ausführen einer Anwendung und Zugriff auf deren Ausgabe

1 2 3 4 5 6 7 8 9 10	Set objShell = WScript.CreateObject("WScript.Shell") Set objExecObject = objShell.Exec("%comspec% /c ipconfig.exe") Do Until objExecObject.StdOut.AtEndOfStream strLine = objExecObject.StdOut.ReadLine() strIP = Instr(strLine,"Adresse") If strIP <> 0 Then Wscript.Echo strLine End If Loop

In Zeile 2 verwendet das Script die Methode Exec, um das Kommandozeilentool ipconfig.exe auszuführen. In der Variable objExecObject wird eine Referenz auf das Tool gespeichert.

In Zeile 4 nimmt das Script in einer Schleife die einzelnen Zeilen der Ausgabe des Tools entgegen - und zwar so lange, bis das Ende der Ausgabe erreicht ist.

In Zeile 6 verwendet das Script die Funktion Instr von VBScript, um zu prüfen ob in der aktuellen Zeile das Wort 'Adresse' enthalten ist. Wenn das Wort gefunden wurde, dann wird die Zeile über die Methode Echo ausgegeben.

Wenn Sie ipconfig.exe in einer Kommandozeile alleine ausführen, erhalten Sie eine Ausgabe wie diese:

Windows-IP-Konfiguration
Ethernetadapter VMware Network Adapter VMnet8:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : 192.168.184.1
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.184.100

Wenn Sie das Script ausführen sieht die Ausgabe so aus:

        IP-Adresse. . . . . . . . . . . . : 192.168.184.1

Arbeiten mit Verknüpfungen

Verknüpfungen sind Links zu Programmen, Dateien, Ordnern, Computern oder Internetadressen. Eine Verknüpfung ist eine Datei mit der Endung .lnk oder .url. Diese beiden Dateierweiterungen werden für Standardverknüpfungen (lnk) und URLs (Uniform Resource Locator) verwendet.

Verknüpfungen werden an vielen Stellen verwendet (Shell, Menüs, Werkzeugleisten, usw.). Das Startmenü besteht zum Beispiel aus Verknüpfungen - und die Verknüpfungen aus der Schnellstartleiste werden im folgenden Ordner gespeichert:

C:\Dokumente und Einstellungen\{Name des Benutzerprofils}\Anwendungsdaten\Microsoft\Internet Explorer\Quick Launch

Ihre Scripte können den Desktop und die Menüs eines Benutzers über Verknüpfungen anpassen. Sie können zum Beispiel ein Script erstellen, das unterschiedlichen Benutzergruppen unterschiedliche Menüoptionen zur Verfügung stellt.

In Tabelle 3.10 sehen Sie die Eigenschaften des Objekts WshShortcut.

Tabelle 3.10: Eigenschaften des Objekts WshShortcut

Eigenschaft	Beschreibung
Arguments	Zusätzliche Kommandozeilenargumente, die Sie beim Start der Anwendung verwenden können.
Description	Beschreibung der Verknüpfung.
FullName	Nur-Lese-Eigenschaft, die den vollständigen Pfad zur Zielanwendung angibt.
HotKey	Tastenkombination: Eine Tastenkombination, über die die Anwendung gestartet werden kann. Tastenkombinationen setzen sich normalerweise aus einer der folgenden Tasten plus einem Buchstaben (a-z), einer Zahl (0-9) oder einer Funktionstaste (F1-F12) zusammensetzen: ALT STRG HOCHSTELLTASTE Wenn Sie die Eigenschaft angeben, müssen Sie für die Taste STRG den Wert CTRL und für die Hochstelltaste den Wert SHIFT angeben. Für die Tastenkombination STRG und 9 verwenden Sie beispielsweise den folgenden Wert: Ctrl + 9 Wenn die Tastenkombination bereits verwendet wird, dann wird sie überschrieben und der neuen Verknüpfung zugewiesen.
IconLocation	Ermöglicht Ihnen die Angabe einen Symbols und eines Symbolindexes für die Verknüpfung. Wenn nichts angegeben wird, dann wird das Standardsymbol der Anwendung verwendet.
TargetPath	Vollständiger Pfad zur Zielanwendung. Sie müssen einen vollständigen Pfad (inklusive des Laufwerkbuchstabens) oder einen UNC-Pfad angeben. Der angegeben Wert wird nicht überprüft.
WindowStyle	Fenstertyp der gestarteten Anwendung. Die möglichen Werte entsprechen den Werten der Methode Run in Tabelle 3.9.
WorkingDirectory	Arbeitsverzeichnis der Anwendung.

Erstellen von Standardverknüpfungen

Zum Erstellen von Standardverknüpfungen sind drei Schritte erforderlich:

• Eine Instanz des Objekts WshShortcut über die Methode CreateShortcut() erstellen. Der Methode muss der Pfad für die neue Verknüpfungsdatei übergeben werden. Auch wenn Verknüpfungen überall im Dateisystem angelegt werden können, werden sie normalerweise jedoch in Spezialordnern wie AllUsersDesktop und StartMenu angelegt. Spezialordner werden weiter unten in diesem Kapitel besprochen.
• Festlegen der Eigenschaften des neuen WshShortcut-Objekts.
• Aufrufen der Methode WshShortcut.Save. Wenn Sie die Save-Methode nicht aufrufen, dann wird die Verknüpfung nicht erstellt.

Script 3.17 erstellt eine Verknüpfung zur IIS-Verwaltung (Internetinformationsdienste - Internet Information Services) auf dem Desktop. Die Verknüpfung wird für alle Benutzer angezeigt und kann entweder über einen Doppelklick oder über die Tastenkombination STRG-HOCHSTELLTASTE+I geöffnet werden.

Script 3.17: Erstellen einer Verknüpfung auf dem Desktop

1 2 3 4 5 6 7 8	Set objShell = WScript.CreateObject("WScript.Shell") strDesktopFolder = objShell.SpecialFolders("AllUsersDesktop") Set objShortCut = objShell.CreateShortcut(strDesktopFolder & _ "\IIS Manager.lnk") objShortCut.TargetPath = "%SystemRoot%\System32\Inetsrv\iis.msc" objShortCut.Description = "IIS-Verwaltung starten." objShortCut.HotKey = "Ctrl+Shift+I" objShortCut.Save

In Zeile 2 wird der Pfad zum Spezialordner Desktop über die Eigenschaft WshShell.SpecialFolders abgefragt und in der Variable strDesktopFolder gespeichert.

In den Zeilen 3 und 4 wird über die Methode CreateShortcut eine neue Verknüpfungsdatei mit dem Namen IISManager.lnk im Desktopordner erstellt.

In den Zeilen 5-7 füllt das Script die Eigenschaften TargetPath, Description und HotKey des WshShortcut-Objekts mit Werten.

In Zeile 8 erstellt das Script die Verknüpfung dann über die Methode WshShortcut.Save.

Anmerkung:
Auch wenn Sie keine Eigenschaften angeben, wird ein Symbol auf dem Desktop erstellt. Hierbei handelt es sich dann jedoch nicht um eine funktionierende Verknüpfung - wenn Sie doppelt auf das Symbol klicken passiert nichts (Sie erhalten nicht einmal eine Fehlermeldung). Für eine funktionierende Verknüpfung müssen Sie mindestens die Eigenschaft TargetPath definieren.

URL-Verknüpfungen erstellen

Zum Erstellen von URL-Verknüpfungen sind die gleichen drei Schritte erforderlich:

1. Eine Instanz des Objekts WshURLShortcut über die Methode CreateShortcut() erstellen. Der Methode muss der Pfad für die neue Verknüpfungsdatei übergeben werden.
2. Festlegen der Eigenschaften des neuen WshURLShortcut-Objekts.
3. Aufrufen der Methode WshURLShortcut.Save.

Script 3.18 erstellt eine Verknüpfung auf dem Desktop, die auf die MSDN®-Website verweist. Diese Verknüpfung ist nur für die Benutzer sichtbar, die das Script ausgeführt haben. Das liegt daran, dass sie im Desktopordner des angemeldeten Benutzers, und nicht im Desktopordner für alle Benutzer erstellt wird.

Script 3.18: Erstellen eine URL-Verknüpfung auf dem Desktop

1 2 3 4 5	Set objShell = WScript.CreateObject("WScript.Shell") strDesktopFld = objShell.SpecialFolders("Desktop") Set objURLShortcut = objShell.CreateShortcut(strDesktopFld & "\MSDN.url") objURLShortcut.TargetPath = "http://msdn.microsoft.com" objURLShortcut.Save

Ein Element zur Schnellstartleiste hinzufügen

Script 3.19 verwendet eine URL-Verknüpfung, um ein Element zur Schnellstartleiste hinzuzufügen, über das die Microsoft® TechNet-Website geöffnet wird. Da die neue Verknüpfung im Schnellstartordner des angemeldeten Benutzers erstellt wird, ist das neue Element nur für die Benutzer sichtbar, die das Script ausgeführt haben.

Script 3.19: Ein neues Element in der Schnellstartleiste erstellen

1 2 3 4 5 6 7 8 9	Set objShell = WScript.CreateObject("WScript.Shell") Set colEnvironmentVariables = objShell.Environment("Volatile") strQLFolder = colEnvironmentVariables.Item("APPDATA") & _ "\Microsoft\Internet Explorer\Quick Launch" Set objURLShortcut = objShell.CreateShortcut(strQLFolder & "\TechNet.url") objURLShortcut.TargetPath = "https://www.microsoft.com/germany/technet" objURLShortcut.Save

Löschen von Verknüpfungen

Verknüpfungsdateien können genauso gelöscht werden wie alle anderen Dateien. Das folgende Script löscht zum Beispiel die mit Script 3.19 erstellte Verknüpfung:

Set objShell = WScript.CreateObject("WScript.Shell")
Set colEnvironmentVariables = objShell.Environment("Volatile")
Set objFSO = CreateObject("Scripting.FileSystemObject")

strQLFolder = colEnvironmentVariables.Item("APPDATA") & _
    "\Microsoft\Internet Explorer\Quick Launch\TechNet.URL"
objFSO.DeleteFile(strQLFolder)

Weitere Informationen zur Arbeit mit Dateien in WSH-Scripten finden Sie im Kapitel Script Runtime Primer dieses Buches.

Arbeiten mit Spezialordnern

Spezialordner sind Ordner, die es unter allen Windows-Computern gibt (oder zumindest geben könnte) - zum Beispiel Eigene Dateien, Fonts und Startmenü. Es gibt zwei Arten von Spezialordnern: Spezialordner mit Standardordnern und welche ohne. Der Ordner Favoriten befindet sich zum Beispiel in einem Standardordner - der Ordner Arbeitsplatz nicht.

In der Collection WScript.SpecialFolders finden Sie die vollständigen Pfade zu allen Spezialordnern, die einen Standardpfad verwenden. In Tabelle 3.11 sehen Sie die Namen und die Inhalte dieser Ordner:

Tabelle 3.11: Spezialordner

Name	Inhalt
AllUsersDesktop	Desktopinhalte, die allen Benutzern angezeigt werden.
AllUsersStartMenu	Startmenüeinträge, die allen Benutzern angezeigt werden.
AllUsersPrograms	Einträge im Menü Programme, die allen Benutzern angezeigt werden.
AllUsersStartup	Programme, die für alle Benutzer beim Systemstart ausgeführt werden.
Desktop	Desktopinhalte, die nur dem aktuellen Benutzer angezeigt werden.
Favorites	Einträge in den Favoriten des aktuellen Benutzers.
Fonts	Installierte Schriften
MyDocuments	Ordner Meine Dokumente des aktuellen Benutzers.
NetHood	Objekte, die im Ordner Netzwerkumgebung angezeigt werden.
PrintHood	Drucker
Recent	Objekte, die unter dem Menüpunkt Dokumente im Startmenü angezeigt werden (für den aktuellen Benutzer).
SendTo	Optionen im Menü Senden an im Kontextmenü nach einem Rechtsklick im Windows Explorer.
StartMenu	Startmenü des aktuellen Benutzers.
Startup	Programme, die für den aktuellen Benutzer beim Systemstart ausgeführt werden.
Templates	Anwendungsvorlagen des aktuellen Benutzers.

Anmerkung:
Über die Collection SpecialFolders können Sie zwar den Pfad des Ordners abfragen, Sie haben jedoch keine Möglichkeit, diese Ordner oder deren Inhalte zu ändern. Hierzu können Sie zum Beispiel das Objekt FileSystemObject verwenden. Weitere Informationen zu diesem Objekt finden Sie im Kapitel Script Runtime Primer.

Den Speicherort von Spezialordner abfragen

Script 3.20 fragt den Speicherort des Spezialordners Fonts ab. Dann gibt das Script diesen Speicherort aus.

Script 3.20: Abfragen des Speicherortes des Spezialordners Fonts

1 2 3	Set objShell = WScript.CreateObject("WScript.Shell") strFontDirectoryPath = objShell.SpecialFolders.Item("Fonts") Wscript.Echo "Pfad zum Ordner Font: " & strFontDirectoryPath

Eine Verknüpfung in einem Spezialordner erstellen

Wenn Sie eine Anwendung installieren, dann weist sich diese oft einer Dateierweiterung zu. Wenn Sie zum Beispiel Microsoft® FrontPage® erstellen, weist sich Frontpage der Dateierweiterung .htm zu. Wenn Sie mit der rechten Maustaste auf eine .htm-Datei klicken und Bearbeiten auswählen, dann wird die Datei mit Frontpage geöffnet.

Manchmal möchten Sie die .htm-Datei aber vielleicht nur einfach in Notepad anzeigen. Hierzu gibt es unter Windows einen Spezialordner mit dem Namen SendTo (Senden an). In diesem Ordner finden Sie alle Anwendungen, über die Sie über das Kontextmenü im Windows Explorer eine Datei öffnen können. Über den Spezialordner SendTo können Sie diesem Ordner Verknüpfungen hinzufügen. Wenn Sie das nächste Mal eine .htm-Datei mit Notepad öffnen möchten, dann klicken Sie einfach mit der rechten Maustaste auf die Datei und wählen im Kontextmenü Senden an und Notepad aus.

Script 3.21 erstellt eine Verknüpfung zur Anwendung Notepad im Spezialordner SendTo.

Script 3.21: Notepad zum Menü Senden an hinzufügen.

1 2 3 4 5 6 7 8 9	Set objShell = WScript.CreateObject("WScript.Shell") strSendToFolder = objShell.SpecialFolders("SendTo") strPathToNotepad = objShell.ExpandEnvironmentStrings _ ("%SystemRoot%/system32/notepad.exe") Set objShortcut = objShell.CreateShortcut(strSendToFolder & _ "\notepad.lnk") objShortcut.TargetPath = strPathToNotepad objShortcut.Save

Umgebungsvariablen

Der Windows-Shellprozess verwendet einige Umgebungsvariablen, deren Inhalte Ihnen in Ihrem Script nützen können:

• Ordner, in denen nach Programmen gesucht wird, wenn Sie in der Eingabeaufforderung nur den Programmnamen angeben.
• Anzahl der CPUs, CPU-Hersteller und CPU-Architektur.
• Speicherort des Benutzerprofils.
• Speicherorte der temporären Ordner.

Wenn Sich ein Benutzer unter Windows anmeldet, dann lädt die Shell die computerspezifischen Umgebungsvariablen aus dem Pfad HKEY_LOCAL_MACHINE und die benutzerspezifischen Umgebungsvariablen aus dem Pfad HKEY_CURRENT_USER der Registrierung.

Zusätzlich zu diesen Umgebungsvariablen werden bei jeder Anmeldung noch Prozess-Umgebungsvariablen generiert.

Tabelle 3.12: Umgebungsvariablen und deren Speicherorte

Typ	Beschreibung	Speicherort in der Registrierung
User	Spezifisch für den angemeldeten Benutzer. Werden zwischen Ab- und Anmeldung des Benutzers gespeichert.	HKCU\Environment
System	Gelten für alle Benutzer des Computers und werden zwischen An- und Abmeldung gespeichert.	HKLM\System\CurrentControlSet\ Control\Session Manager\Environment
Volatile	Gelten nur für die aktuelle Sitzung. Werden nicht gespeichert.	HKCU\VolatileEnvironment
Process	Gelten nur für den aktuellen Prozess.	Werden nicht in der Registrierung gespeichert.

Die Eigenschaft Environment des Objekts WshShell gibt die Collection WshEnvironment zurück, über die Ihr Script Umgebungsvariablen abfragen, einrichten und verändern kann.

Abfragen von Umgebungsvariablen

Um eine Collection mit den Umgebungsvariablen eines bestimmten Typs zu erhalten, verwenden Sie die Eigenschaft WshShell.Environment. Ihr übergeben Sie eine String, der den gewünschten Variablentyp enthält: system, user, process oder volatile. Danach kann das Script über die Collection WshEnvironment über den Namen der Umgebungsvariablen auf diese zugreifen.

Tabelle 3.13: Umgebungsvariablen

Name	System	User	Process	Process (nur Windows 98/Me)
NUMBER_OF_PROCESSORS
PROCESSOR_ARCHITECTURE
PROCESSOR_IDENTIFIER
PROCESSOR_LEVEL
PROCESSOR_REVISION
OS
COMSPEC
HOMEDRIVE
HOMEPATH
PATH
PATHEXT
PROMPT
SYSTEMDRIVE
SYSTEMROOT
WINDIR
TEMP
TMP

Die Umgebungsvariablen in der Tabelle gibt es unter allen Windows-Computern. Es kann jedoch zusätzliche benutzerspezifische Variablen geben. Wenn Sie die Namen dieser zusätzlichen Variablen nicht kennen, dann können Sie in der Eingabeaufforderung eine komplette Liste über den Befehl Set abrufen.

Script 3.22 ruft die benutzerspezifische und die computerspezifische Umgebungsvariable PATH ab.

Script 3.22: Anzeigen der Umgebungsvariable PATH

1 2 3 4 5 6 7	Set objShell = WScript.CreateObject("WScript.Shell") Set colSystemEnvVars = objShell.Environment("System") Set colUserEnvVars = objShell.Environment("User") Wscript.Echo "Computer-specific PATH Environment Variable" Wscript.Echo colSystemEnvVars("PATH") Wscript.Echo "User-specific PATH Environment Variable" Wscript.Echo colUserEnvVars("PATH")

Wenn Sie das Script unter CScript ausführen, erhalten Sie die folgende Ausgabe:

Computer-specific PATH Environment Variable
C:\Programme\PTP2002;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem
User-specific PATH Environment Variable
C:\Programme\PTP2002;;

Umgebungsvariablen erstellen

Um Umgebungsvariablen zu erstellen, gehen Sie anfangs genauso vor wie beim Abfragen einer Umgebungsvariable: Sie benötigen eine Referenz auf die Collection mit den Umgebungsvariablen. Erst dann könnten Sie eine neue Umgebungsvariable erstellen.

Die folgende Codezeile erstellt zum Beispiel eine Umgebungsvariable mit dem Namen MeineVariable mit den Anfangswert 0.

colUsrEnvVars("MeineVariable") = 0

Sie können über Ihre Scripts Variablen vom Typ process oder volatile erzeugen - diese sind jedoch nicht sonderlich nützlich, da beide Variablentypen bei der Abmeldung des Benutzers nicht gespeichert werden. Daher finden Sie Variablen vom Typ user und system wahrscheinlich deutlich praktischer - diese werden bei der Abmeldung des Benutzers gespeichert.

Script 3.23 erstellt eine Umgebungsvariable vom Typ user mit dem Namen APP_VARIABLE und setzt deren Wert auf Installiert. Danach fragt das Script den Wert der neu erstellen Variable ab, um sicherzustellen, dass diese auch erstellt wurde.

Script 3.23: Erstellen einer Umgebungsvariable vom Typ user

1 2 3 4	Set objShell = WScript.CreateObject("WScript.Shell") Set colUsrEnvVars = objShell.Environment("USER") colUsrEnvVars("APP_VARIABLE") = "Installiert" Wscript.Echo colUsrEnvVars("APP_VARIABLE")

Ändern von Umgebungsvariablen

Auch bei der Änderung von Umgebungsvariablen beginnen Sie, indem Sie sich eine Referenz auf die Collection mit den Umgebungsvariablen erstellen. Script 3.24 ändert den Wert der Umgebungsvariable von Typ user mit dem Namen APP_VARIABLE auf den Wert Aktualisiert.

Script 3.24: Änderung einer Umgebungsvariable von Typ user

1 2 3 4 5	Set objShell = WScript.CreateObject("WScript.Shell") Set colUsrEnvVars = objShell.Environment("USER") strCurrentValue = colUsrEnvVars("APP_VARIABLE") colUsrEnvVars("APP_VARIABLE") = "Aktualisiert" Wscript.Echo colUsrEnvVars("APP_VARIABLE")

Auswerten von Umgebungsvariablen

Über Umgebungsvariablen können Sie Systeminformationen abrufen. Wenn Sie zum Beispiel auf den temporären Ordner des Benutzers zugreifen möchten, dann brauchen Sie die Pfadangabe für diesen Ordner (beispielsweise C:\Temp).

Um den Wert einer Umgebungsvariable abzufragen, verwenden Sie die Methode WshShell.ExpandEnvironmentStrings. Diese Methode erwartet als Parameter den in Prozentzeichen (%) eingeschlossenen Namen der Umgebungsvariable als String und gibt deren Wert zurück.

Script 3.25 gibt erst den Wert einer Umgebungsvariable und dann die ausgewertete Umgebungsvariable aus.

Script 3.25: Erstellen und Anzeigen einer Umgebungsvariable

1 2 3 4 5 6	Set objShell = WScript.CreateObject("WScript.Shell") Set colEnvVars = objShell.Environment("User") Wscript.Echo "temporärer Ordner:" Wscript.Echo colEnvVars("TEMP") & vbCrLf Wscript.Echo "temporärer Ordner (ausgewertet) " Wscript.Echo objShell.ExpandEnvironmentStrings("%TEMP%")

Wenn Sie das Script unter Cscript ausführen, erzeugt es eine Ausgabe wie die folgende.

temporärer Ordner:
%USERPROFILE%\Lokale Einstellungen\Temp

temporärer Ordner (ausgewertet)
C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp

Einträge im Ereignisprotokoll erzeugen

Die Fehlersuche in Anwendungen und bei Diensten wird dadurch vereinfacht, dass diese wichtige Ereignisse in das Ereignisprotokoll eintragen. Ihre Scripte können das ebenfalls so machen. Das WshShell-Objekt stellt Ihnen hierzu die Methode LogEvent zur Verfügung - sie erzeugt einen Eintrag im Anwendungsprotokoll.

Anmerkung:
Wenn Sie Ereignisprotkolleinträge lesen oder verarbeiten möchten, dann müssen Sie WMI verwenden. Weitere Informationen hierzu finden Sie im Kapitel Logs.

LogEvent erwartet zwei Parameter. Der erste Parameter ist ein Integerwert, der das Ereignis definiert, dass Sie in das Ereignisprotokoll eintragen möchten. Die möglichen Werte sehen Sie in Tabelle 3.14.

Tabelle 3.14: Ereignistypen

Wert	Ereignistyp
0	Erfolgreich
1	Fehler
2	Warnung
4	Information
8	Erfolgsüberwachung
16	Fehlerüberwachung

Der zweite Parameter gibt den Text für den Protokolleintrag an. Als dritten Parameter können Sie optional den Computernamen angeben - zum Beispiel, wenn das Ereignis nicht auf dem Computer eingetragen wird, auf dem das Script ausgeführt wird, sondern auf einem zentralen Computer (dieser Parameter wird unter Windows 95 und Windows 98 ignoriert).

Script 3.26 erzeugt jeweils ein Ereignis der in Tabelle 3.14 angegebenen Ereignistypen mit einer entsprechenden Beschreibung.

Script 3.26: Ereignisse im Ereignisprotokoll erzeugen

1 2 3 4 5 6 7	Set objShell = WScript.CreateObject("Wscript.Shell") objShell.LogEvent 0,"Test Erfolgreich" objShell.LogEvent 1,"Test Fehler" objShell.LogEvent 2,"Test Warnung " objShell.LogEvent 4, "Test Information " objShell.LogEvent 8, "Test Erfolgsüberwachung " objShell.LogEvent 16, "Test Fehlerüberwachung "

Mit der LogEvent-Methode können Sie Ereignisse nur im Anwendungsprotokoll erzeugen. Sie können keine bestimmte Ereignis-ID oder Quelle angeben. Die Quelle für alle Ereignisse ist automatisch der WSH - als Ereignis-ID werden die Werte aus Tabelle 3.14 verwendet.

Schreiben und Lesen in der lokalen Registrierungsdatenbank

Im Allgemeinen ist es besser die Registrierung über die entsprechenden Tools (zum Beispiel Regedit.exe) zu verwalten. Diese sind zwar auch nicht idiotensicher, verfügen jedoch über eingebaute Sicherheitsoptionen, um potentielle Beschädigungen der Registrierung zu verhindern. Andererseits ist es über solche Tools oft schwer die Registrierung auf mehreren Computern zu bearbeiten. In einem solchen Fall bietet Ihnen das WshShell-Objekt die Möglichkeit, Einträge in der Registrierung zu lesen, zu schreiben und diese zu verändern.

Registrierungseinträge lesen

Die Registrierung ist die primäre Konfigurationsdatenbank von Windows - die korrekte Ausführung vieler Betriebssystemkomponenten hängt von Registrierungseinstellungen ab.

Als Systemadministrator verbringen Sie wahrscheinlich des Öfteren Zeit damit, Werte in der Registrierung zu überprüfen. Diese Registrierungswerte können Sie entweder direkt über ein Tool wie regedit.exe oder über ein Script mit der Methode WshShell.RegRead auslesen.

In den meisten Fällen benötigen Sie hierzu nur zwei Dinge: Erstens eine Instanz des Objekts Wscript.Shell und zweitens die Methode RegRead. Die Betriebssystemversion wird zum Beispiel unter dem Registeriungsschlüssel HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion gespeichert - Sie können sie über das folgende Script abfragen:

Set objShell = WScript.CreateObject("WScript.Shell")
sngVersion = objShell.RegRead _
    ("HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion")
Wscript.Echo sngVersion

Datentypen in der Registrierung

Jeder in der Registrierung gespeicherte Wert hat einen eindeutigen Datentyp. In Tabelle 3.15 sehen Sie die von WSH unterstützten Registrierungstypen und die VBScript-Datentypen, in die diese von RegRead übersetzt werden.

Tabelle 3.15: Registrierungsdatentypen und die entsprechenden VBScript-Datentypen

Name	Datentyp	VBScript-Datentyp
REG_SZ	String	String
REG_DWORD	Number	Integer
REG_BINARY	Binary Value	Integer-Array
REG_EXPAND_SZ	Expandable String	String
REG_MULTI_SZ	Array of Strings	String-Array

Bei den Datentypen in der Tabelle handelt es sich nur um die gebräuchlichsten. Wenn Sie versuchen mit RegRead nicht unterstützte Datentypen auszulesen, führt dies zu einem Fehler.

Anmerkung:
Unglücklicherweise haben Sie mit dem WSH keine Möglichkeit, den Datentyp eines Registrierungseintrages vor dem Auslesen festzustellen - über WMI ist dies jedoch möglich.

Script 3.27 verwendet die Methode RegRead, um einen Registrierungswert vom Datentyp Multistring (REG_MULTI_SZ) auszulesen. Die Informationen werden als String-Array zurückgegeben, der in einer For-Each-Schleife ausgegeben wird.

Script 3.27: Auslesen eines Multistring-Wertes aus der Registrierung

1 2 3 4 5 6	Set objShell = WScript.CreateObject("WScript.Shell") arrValues = objShell.RegRead _ ("HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security\Sources") For Each strValue In arrValues Wscript.Echo strValue Next

Wenn Sie das Script unter CScript ausführen, erhalten Sie die folgende Ausgabe:

Spooler
Security Account Manager
SC Manager
NetDDE Object
LSA
DS
Security

Registrierungseinträge erstellen oder ändern

Über die Methode RegWrite können Sie neue Registrierungseinträge erstellen oder bestehende Einträge ändern. Die Methode nimmt hierzu drei Parameter entgegen: Den Registrierungseintrag, den Sie erstellen oder ändern möchten, den Wert, den Sie dem Eintrag zuweisen möchten und (optional) den Datentyp des Eintrages.

Script 3.28 verwendet die Methode RegWrite, um einen DWORD-Eintrag zu erstellen und dessen Wert auf 56 zu setzen.

Script 3.28: Einen DWORD-Eintrag in der Registrierung erstellen

1 2	Set objShell = WScript.CreateObject("WScript.Shell") objShell.RegWrite "HKCU\TestKey\Version", 56, "REG_DWORD"

Anmerkung:
Der Datentyp REG_MULTI_SZ wird von der Methode RegWrite nicht unterstützt.

Registrierungseinträge löschen

Mit der Methode RegDelete können Sie Schlüssel oder Einträge in der Registrierung löschen. Sie akzeptiert einen Parameter - dieser gibt den zu löschenden Schlüssel oder Eintrag an. Wenn Sie einen Schlüssel löschen, dann werden auch alle Einträge unter diesem Schlüssel gelöscht.

Script 3.29 verwendet die Methode RegDelete, um einen DWORD-Eintrag aus der Registrierung zu löschen.

Script 3.29: Löschen eines DWORD-Eintrags aus der Registrierung

1 2	Set objShell = WScript.CreateObject("WScript.Shell") objShell.RegDelete "HKCU\TestKey\Version"

Tastatureingaben an ein Programm schicken

Der WSH ermöglicht Ihnen eine Automatisierung von COM-fähigen Anwendungen, indem er Ihnen einen Zugriff auf die jeweiligen COM-Objekte zur Verfügung stellt. Unglücklicherweise sind einige Anwendungen nicht COM-fähig - dies betriff spezielle ältere Anwendungen. Um auch die Arbeit mit solchen Anwendungen automatisieren zu können, haben Sie die Möglichkeit, Tastatureingaben an die Anwendungen zu schicken.

Mit der Methode WshShell.SendKeys imitiert Ihr Script die Tastatureingaben durch einen Benutzer. Um ein einzelnes Zeichen zu simulieren, übergeben Sie der Methode SendKeys das Zeichen einfach als Parameter.

Sondertasten (zum Beispiel STRG oder ALT) können Sie über bestimmte Zeichenkombinationen angeben. In Tabelle 3.16 sehen Sie alle oft verwendeten Sondertasten und die entsprechenden Zeichenkombinationen.

Tabelle 3.16: Zeichenkombinationen für Sondertasten mit SendKeys

Taste	Wert für SendKeys
Rückschritt	{BACKSPACE}, {BS}, oder {BKSP}
Pause	{BREAK}
Feststelltaste	{CAPSLOCK}
Entf. oder Entfernen	{DELETE} oder {DEL}
Pfeil runter	{DOWN}
Ende	{END}
Eingabe	{ENTER} oder ~
ESC	{ESC}
Hilfe	{HELP}
Pos1	{HOME}
Einf. oder Einfügen	{INSERT} oder {INS}
Pfeil Links	{LEFT}
NUM	{NUMLOCK}
Bild runter	{PGDN}
Bild hoch	{PGUP}
Druck	{PRTSC}
Pfeil links	{RIGHT}
Rollen	{SCROLLLOCK}
Tabulator	{TAB}
Pfeil hoch	{UP}
Hochstelltaste	+
Steuerung (Strg)	^
Alt	%

Alle Funktionstasten werden über den Tastennamen in geschweiften Klammern angegeben - zum Beispiel {F1} für die Taste F1 usw.

Das folgende Script startet zum Beispiel Notepad und schreibt den Satz 'Dies ist ein Test.':

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run("Notepad.exe")
objShell.AppActivate "Editor"
objShell.SendKeys "Dies ist ein Test."

Wenn Sie das Script ausführen, wird Notepad geöffnet. Dann wird der Beispielsatz in Notepad geschrieben.

Abbildung 3.12: Notepad über SendKeys steuern

Anmerkung:
Mit SendKeys können Sie auch wiederholte Tastatureingaben simulieren. Wenn Sie zum Beispiel 10x die Taste a simulieren möchten, dann können Sie {a 10} als Parameter verwenden. Zwischen dem Zeichen und der Zahl muss sich in diesem Fall zwingend ein Leerzeichen befinden. Es ist jedoch nicht möglich mehrere Tastatureingaben zu wiederholen. Der Parameter {dog 10} führt also zu einem Fehler.

Sie sollten daran denken, dass eine Tastatureingabe nicht die optimale Möglichkeit ist, um eine Anwendung zu kontrollieren. Wenn Sie mit einer Anwendung arbeiten, die nicht COM-fähig ist, dann leisten sie natürlich gute Dienste - und in allen anderen Fällen sollten Sie jedoch versuchen, die COM-Objekte zu verwenden.

Mit SendKeys können eine Menge unterschiedlicher Probleme auftreten:

• Es kann schwer sein, die Tastatureingaben an das richtige Fenster zu schicken.
• Da die Zielanwendung im GUI-Modus ausgeführt wird, ist es möglich, dass ein Benutzer die Anwendung einfach schließt. Unglücklicherweise bricht das Script in einem solchen Fall jedoch nicht ab - die Tastatureingaben werden einfach an eine falsche Anwendung geschickt.
• Das Script ist schwer mit der Anwendung zu synchronisieren.

Das Timing-Problem ist ganz besonders schwer zu lösen - ganz einfach darum, weil die meisten Scripte sehr viel schneller ausgeführt werden, als die meisten GUI-basierten Anwendungen. Das folgende Script startet zum Beispiel den Windows-Taschenrechner und schickt dann die Ziffer 2 an diese Anwendung. Wahrscheinlich wird es zwar korrekt ausgeführt, die Zahl 2 ist im Taschenrechner jedoch nicht zu sehen:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run "Calc.exe"
objShell.AppActivate "Rechner"
objShell.SendKeys "2"

Das unerwartete Ergebnis liegt nicht an einem Fehler im Script, sondern an einem Timing-Problem. Das Script führt die folgenden Befehle so schnell wie möglich aus:

1. Windows-Taschenrechner starten.
2. Focus auf den Taschenrechner verschieben (über die Methode AppActivate).
3. Die Zahl 2 an den Taschenrechner schicken.

Das Script wird jedoch viel schneller ausgeführt, als der Windows-Taschenrechner geladen werden kann. Das führt dazu, dass die Zahl 2 schon gesendet wird, wenn der Taschenrechner noch nicht einmal vollständig geladen wurde - natürlich kann er in diesem Zustand noch keine Tastatureingaben entgegennehmen oder gar verarbeiten.

Zur Lösung dieses Problems gibt es zwei Wege. Bei der ersten Möglichkeit stellen Sie fest, wie lange die Anwendung zum Laden braucht, und halten dann das Script für diesen Zeitraum an. Das folgende Script verwendet zum Beispiel die Methode Run, und wartet dann 5 Sekunden auf das Laden des Taschenrechners:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run "Calc.exe"
Wscript.Sleep 5000
objShell.AppActivate "Rechner"
objShell.SendKeys "2"

In einigen Fällen kann es natürlich schwer einzuschätzen sein, wie lange eine Anwendung zum Laden benötigt. In einem solchen Fall können Sie das zweite Verfahren nutzen: Sie verwenden die Methode AppActivate, um den Rückgabewert der Anwendung zu überprüfen.

Verwendung von AppActivate

Bevor Sie Tastatureingaben an eine Anwendung schicken, müssen Sie sicherstellen, dass die Anwendung ausgeführt wird und über den Focus verfügt (das Anwendungsfenster muss also das aktive Fenster sein) - hierzu können Sie die Methode AppActivate verwenden.

AppActivate erwartet einen Parameter, bei dem es sich entweder um einen String mit dem Titel der Anwendung (wird ganz oben in der Titelleiste der Anwendung angezeigt) oder um die Prozess-ID der Anwendung handeln kann. Die Methode gibt einen Boolean-Wert zurück, der anzeigt, ob die Methode erfolgreich ausgeführt wurde oder nicht. Der Rückgabewert False bedeutet, dass AppActivate nicht in der Lage war, den Focus auf die Anwendung zu verschieben (zum Beispiel, wenn die Anwendung noch nicht vollständig geladen ist).

Sie können eine Schleife verwenden, in der AppActivate so lange aufgerufen wird, bis ihr Rückgabewert True ist. Dann wissen Sie, dass die Anwendung vollständig geladen wurde und bereit für Tastatureingaben ist.

Das folgende Script prüft den Rückgabewert von AppActivate. Wenn dieser Wert False ist, wartet das Script für eine Sekunde ab und prüft den Wert dann noch einmal. Dieser Vorgang wird so lange wiederholt, bis der Rückgabewert True ist. Erst dann fährt das Script mit den Tastatureingaben fort:

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run "Calc.exe"
Do Until Success = True
    Success = objShell.AppActivate("Rechner")
    Wscript.Sleep 1000
Loop
objShell.SendKeys "2"

Mit AppActivate wird der übergebene String mit allen Fenstertiteln verglichen. Wenn keine Übereinstimmung gefunden wird, setzt AppActivate den Focus auf das Fenster, dessen Titel mit dem übergebenen String beginnt. Wenn auch hier keine Übereinstimmung gefunden werden kann, wird der Focus auf das Fenster gesetzt, dessen Titel mit dem String endet. So wird sichergestellt, dass AppActivate auch mit Anwendungen funktioniert, in denen Dokumente geöffnet werden können (wenn Sie zum Beispiel Notepad starten und ein neue Dokument öffnen, dann lautet der Fenstertitel von Notepad Unbenannt -Editor und nicht Editor.

Das bedeutet, dass Sie die folgenden Codezeilen verwenden können, um den Focus auf den Taschenrechner zu verschieben:

objShell.AppActivate "Rechner"
objShell.AppActivate "Rech"
objShell.AppActivate "R"

Die 'Kurzmethode' kann natürlich auch zu Problemen führen. Stellen Sie sich vor, Sie verwenden die folgende Codezeile:

objShell.AppActivate "Rech"

Wenn Sie in diesem Fall ein Word-Dokument mit dem Namen Rechnungen.doc geöffnet haben, könnten die Tasteneingaben versehentlich an dieses Fenster geschickt werden.

Script 3.30 zeigt eine mehr praktische Anwendung der Methode SendKeys. Es startet die Microsoft Management Console (MMC) und verschiebt den Focus auf die Anwendung. Dann schickt es die Tastatureingaben an die Anwendung, die erforderlich sind, um den Dialog Snap-In hinzufügen/entfernen und das Dialogfenster Eigenständiges Snap-In hinzufügen anzuzeigen.

Script 3.30: Tastatureingaben an eine GUI-Anwendung schicken

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17	Const iNormalFocus = 1 Set objShell = WScript.CreateObject("WScript.Shell") objShell.Run "mmc.exe",iNormalFocus Wscript.Sleep 300 objShell.AppActivate "Konsole1" Wscript.Sleep 100 objShell.SendKeys "^m" Wscript.Sleep 100 objShell.SendKeys "{TAB}" Wscript.Sleep 100 objShell.SendKeys "{TAB}" Wscript.Sleep 100 objShell.SendKeys "{TAB}" Wscript.Sleep 100 objShell.SendKeys "{ENTER}"

Das aktuelle Arbeitsverzeichnis eines Scripts abfragen und ändern

Das Arbeitsverzeichnis eines Scripts ist standardmäßig das Verzeichnis, in dem das Script gestartet wurde. Dies ist nicht notwendigerweise das Verzeichnis, in dem das Script gespeichert ist. Wenn Sie sich in Verzeichnis C:\Temp befindenund das Script c:\scripts\report.vbs starten, dann ist das Arbeitsverzeichnis des Scripts c:\temp.

Das Objekt WshShell verfügt über eine Eigenschaft mit dem Namen CurrentDirectory. Über diese Eigenschaft können Sie das Arbeitsverzeichnis abfragen und verändern. Hierfür kann es mehrere Gründe geben:

• Sie möchten, dass das Script eine Protokolldatei in dem Ordner erstellt, in dem das Script gespeichert ist.
• Sie möchten feststellen, ob das Script lokal oder über das Netzwerk gestartet wurde - wenn es über das Netzwerk gestartet wurde, beginnt das Arbeitsverzeichnis mit zwei Backslashes (\\).

Um das Arbeitsverzeichnis abzufragen, erstellen Sie eine Instanz von WshShell und greifen dann auf die Eigenschaft CurrentDirectory zu. Um das Arbeitsverzeichnis zu ändern, weisen Sie der Eigenschaft einfach einen neuen Wert zu.

Script 3.31: Konfigurieren und Abfragen des aktuellen Arbeitsverzeichnisses

1 2 3 4 5 6 7 8 9	Set objShell = WScript.CreateObject("WScript.Shell") Wscript.Echo "Aktuelles Arbeitsverzeichnis:" Wscript.Echo objShell.CurrentDirectory objShell.CurrentDirectory = "C:\" Wscript.Echo "Arbeitsverzeichnis nach Änderung:" Wscript.Echo objShell.CurrentDirectory

Wenn Sie das Script aus dem Ordner c:\temp unter CScript starten, erhalten Sie die folgende Ausgabe:

Aktuelles Arbeitsverzeichnis:
C:\Temp
Arbeitsverzeichnis nach Änderung:
C:\

Zeitgesteuerte Nachrichtenfenster anzeigen

In einer perfekten Welt trifft Ihr Script bei jeder Ausführung auf perfekte Bedingungen - es führt seine vorgesehene Aufgabe schnell und zuverlässig aus. In der echten Welt funktionieren einige Dinge jedoch nicht immer so zuverlässig. Manchmal starten Sie ein Script, und es werden Entscheidungen erforderlich; zum Beispiel, wenn Sie eine Verbindung mit einem Remotecomputer aufbauen wollen und dieser nicht erreichbar ist. Soll das Script einen neuen Versuch unternehmen, den Computer zu erreichen oder das Problem ignorieren? Oder soll das Script möglicherweise einfach aufgeben?

In solchen Fällen können Sie die Methode WshShell.Popup verwenden. Sie zeigt ein Nachrichtenfenster an, und liefert als Rückgabewerte den Schalter, auf den der Benutzer geklickt hat. Sie können zum Beispiel ein Nachrichtenfenster mit einen Ja- und einem Nein-Schalter anzeigen lassen, und Ihr Script kann dann auf die Auswahl des Benutzers reagieren. 'Soll ein weiterer Verbindungsversuch unternommen werden? Ja/Nein'.

Ein weiterer Vorteil der Methode Popup ist, dass Sie einen Timeout-Wert definieren können und Symbol und Titel des Nachrichtenfensters festlegen können. Nachrichtenfenster, die über die Methode Wscript.Echo erzeugt werden, bieten Ihnen diese Möglichkeiten nicht - sie haben immer den Titel Windows Script Host.

In Abbildung 3.13 sehen Sie ein Beispiel für ein Nachrichtenfenster, das über die Methode Popup erzeugt wurde.

Abbildung 3.13: Popup-Nachrichtenfenster

Vergleich der Methoden Echo und Popup

Wenn Sie ein Script unter WScript ausführen, können Sie ein Nachrichtenfenster statt mit der Methode WshShell.Popup auch über die Methode Wscript.Echo anzeigen. Mit Wscript.Echo haben die Benutzer jedoch nur die Möglichkeit auf OK zu klicken.

Außerdem hält das Script an, wenn eine Nachricht über Wscript.Echo angezeigt wird. Erst nachdem der Benutzer auf OK geklickt hat, wird es weiter ausgeführt.

Abbildung 3.14: Mit Wscript.Echo unter WScript erzeugtes Nachrichtenfenster

Anmerkung:
Im Gegensatz zu Wscript.Echo zeigt die Methode Popup immer ein Nachrichtenfenster an - egal, ob das Script unter CScript oder WScript ausgeführt wird.

Ein Nachrichtenfenster mit Time-Out erstellen

Script 3.32 verwendet die Methode Popup, um drei Nachrichtenfenster zu erstellen. Jedes Fenster verfügt über einen OK-Schalter und wird für maximal 5 Sekunden angezeigt. Wenn der Benutzer nicht auf OK klickt, dann wird das Nachrichtenfenster automatisch nach 5 Sekunden geschlossen.

Script 3.32: Nachrichtenfenster mit Time-Out

1 2 3 4 5 6	Const TIMEOUT = 5 Set objShell = WScript.CreateObject("WScript.Shell") objShell.Popup "Festplattenprüfung durchgeführt", TIMEOUT objShell.Popup "Speicherprüfung durchgeführt", TIMEOUT objShell.Popup "CPU-Prüfung durchgeführt", TIMEOUT

Solche Nachrichtenfenster mit Time-Out sind in zwei Situationen sehr praktisch. Erstens, wenn Sie Informationen ausgeben wollen, ohne das Script zu unterbrechen - zum Beispiel könnte Script 3.32 ja tatsächlich die drei Prüfungen durchführen. Nachdem eine Prüfung durchgeführt wurde, würde das Script den Benutzer über die Popup-Methode benachrichtigen, jedoch bereits während der Anzeige mit der nächsten Prüfung fortfahren.

Zweitens können Sie dem Benutzer die Möglichkeit geben eine Entscheidung zu treffen oder das Script einfach weiter laufen zu lassen. Stellen Sie sich vor, Sie schreiben ein Script, das einige Aufgaben durchführt und dann Dateien auf einen Computer im Netzwerk kopiert. Da das Kopieren möglicherweise sehr lange dauert, können Sie den Benutzer vorher fragen, ob er die Aktion durchführen möchte. Wenn dieser nicht reagiert, könnten Sie automatisch mit dem Kopieren anfangen.

Symbole und Schalter in Nachrichtenfenstern

Sie haben die Möglichkeit, unterschiedliche Schalter und Symbole im Nachrichtenfenster anzeigen zu lassen (zum Beispiel die Schalter Ja und Nein oder die Schalter Abbrechen, Wiederholen, Ignorieren).

Die Angezeigten Schalter und Symbole definieren Sie mit dem vierten Parameter der Methode Popup. Er setzt sich auch einer Kombination von vordefinierten Konstanten zusammen - die beiden Werte werden einfach addiert. Die verfügbaren Symbole und die entsprechenden Werte sehen Sie in Tabelle 3.17.

Tabelle 3.17: Konstanten für Symbole

Symbol	Konstante	Wert
Stop	vbCritical	16
Fragezeichen	vbQuestion	32
Ausrufungszeichen	vbExclamation	48
Information	vbInformation	64

In Tabelle 3.18 sehen Sie die zur Verfügung stehenden Schalter und die entsprechenden Konstanten.

Tabelle 3.18: Konstanten für Schalter

Schalter	Konstante	Wert
OK	vbOKOnly	0
OK und Abbrechen	vbOKCancel	1
Abbrechen, Wiederholen und Ignorieren	vbAbortRetryIgnore	2
Ja, Nein und Abbrechen	vbYesNoCancel	3
Ja und Nein	vbYesNo	4
Wiederholen und Abbrechen	vbRetryCancel	5

Auch wenn Sie in Ihrem Script sowohl die Konstanten als auch die Werte verwenden können, sollten Sie bei den Konstanten bleiben. Ihre Scripte werden so leichter nachvollziehbar und lesbar.

Script 3.33 zeigt einige Nachrichtenfenster an, die jeweils unterschiedliche Symbole und Schalter verwenden. Wenn Sie auf einen Schalter im Nachrichtenfenster klicken, wird das nächste Nachrichtenfenster angezeigt - dies geschieht auch, wenn Sie einfach 5 Sekunden abwarten.

Script 3.33: Kombinationen von Symbolen und Schaltern anzeigen

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Const TIMEOUT = 5 Const POPUP_TITLE = "Symbole und Schalter " Set objShell = WScript.CreateObject("WScript.Shell") objShell.Popup "Stop / Abbrechen, Wiederholen und Ignorieren ", _ TIMEOUT,POPUP_TITLE,vbCritical+vbAbortRetryIgnore objShell.Popup "Fragezeichen/ Ja, Nein und Abbrechen ", _ TIMEOUT,POPUP_TITLE,vbQuestion+vbYesNoCancel objShell.Popup "Ausrufungszeichen / Ja und Nein ", _ TIMEOUT,POPUP_TITLE,vbExclamation+vbYesNo objShell.Popup "Information / Wiederholen und Abbrechen ", _ TIMEOUT,POPUP_TITLE,vbInformation+vbRetryCancel

In den Zeilen 4-14 wird die Methode WshShell.Popup vier Mal aufgerufen, um Nachrichtenfenstern mit unterschiedlichen Symbolen und Schaltern anzuzeigen. Als dritter Parameter wird immer die Konstante POPUP_TITLE übergeben - der Titel der Nachrichtenfenster lautet daher immer Symbole und Schalter. Als vierter Parameter werden Konstanten für die unterschiedlichen Schalter und Symbole übergeben. Die beiden Konstanten werden einfach addiert.

Einen Standardschalter auswählen

Mit der Methode WshShell.Popup haben Sie die Möglichkeit, einen Standardschalter anzugeben. Der Standardschalter ist der Schalter, der den Focus besitzt und ausgewählt wird, wenn der Benutzer einfach nur die Eingabetaste drückt.

Es ist für einen Benutzer nicht unüblich, dass er einfach die Eingabetaste drückt, wenn eine Fehlermeldung angezeigt wird. Daher sollten Sie bei der Auswahl des Standardschalters vorsichtig sein. Sie können zum Beispiel den Schalter verwenden, der fast immer ausgewählt wird. Oder Sie verwenden den 'sichersten' Schalter. Ihr Nachrichtenfenster könnte zum Beispiel lauten: 'Sind Sie sicher, dass Sie alle Dateien auf der Festplatte löschen möchten?'. In einem solchen Fall sollten Sie als Standardschalter den Schalter Nein festlegen - so werden keine Dateien gelöscht, wenn der Benutzer versehentlich die Eingabetaste drückt.

Den Standardschalter legen Sie fest, indem Sie eine weitere Konstante zum vierten Parameter addieren - Tabelle 3.19 zeigt Ihnen die möglichen Werte. Wenn Sie einen Schalter auswählen, der nicht angezeigt wird (zum Beispiel den mittleren Schalter, wenn nur ein Schalter angezeigt wird), dann ist der erste Schalter der Standardschalter.

Tabelle 3.19: Konstanten für den Standardschalter

Standardschalter	Konstante	Wert
Linker Schalter	vbDefaultButton1	0
Mittlerer Schalter	vbDefaultButton2	256
Rechter Schalter	vbDefaultButton3	512

Script 3.34 zeigt zwei Nachrichtenfenster an. Beide Fenster verwenden die Schalter Abbrechen, Wiederholen und Ignorieren. Beim ersten Fenster wird kein Standardschalter angegeben - daher hat der erste Schalter den Focus. Beim zweiten Fenster wird der Standardschalter mit der Konstante vbDefaultButton2 festgelegt - daher hat der Schalter Wiederholen den Focus.

Script 3.34: Schalter Wiederholen als Standardschalter definieren

1 2 3 4 5 6 7 8	Const TIMEOUT = 5 Set objShell = WScript.CreateObject("WScript.Shell") objShell.Popup "Kein Standarschalter." _ ,TIMEOUT,,vbAbortRetryIgnore objShell.Popup "Wiederholen ist der Standardschalter." _ ,TIMEOUT,,vbAbortRetryIgnore+vbDefaultButton2

Benutzereingaben abfragen

Ein Vorteil der Methode Popup ist, dass Sie dem Benutzer eine Auswahl ermöglichen können. Das bedeutet natürlich auch, dass sich Ihr Script darum kümmern muss, auf welchen Schalter der Benutzer geklickt hat. Popup gibt hierzu einen Integerwert zurück (wenn das Fenster durch den Timeout-Wert geschlossen wird, ist der Rückgabewert -1). Eine Auflistung der Rückgabewerte für die einzelnen Schalter finden Sie in Tabelle 3.20.

Die folgenden beiden Codezeilen prüfen beide, ob der Benutzer auf den Schalter OK geklickt hat:

If intClicked = 1
If intClicked = vbOK

Tabelle 3.20: Konstanten für Schalter

Wert	Konstante	Schalter
1	VbOK	OK
2	VbCancel	Abbrechen (bei OK, Abbrechen)
3	VbAbort	Abbrechen (bei Wiederholen, Abbrechen, Ignorieren)
4	VbRetry	Wiederholen
5	VbIgnore	Ignorieren
6	VbYes	Ja
7	VbNo	Nein

Script 3.35 zeigt ein Nachrichtenfenster mit den Schaltern Ja und Nein an. Es stellt dem Benutzer über das Objekt FileSystemObject Informationen über den Host zur Verfügung, über den das Script ausgeführt wird. Dann fragt es den Benutzer, ob dieser mehr Informationen über die Datei erhalten möchte.

Script 3.35: Benutzereingaben über ein Nachrichtenfenster entgegennehmen

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Const TIMEOUT = 7 Set objShell = WScript.CreateObject("WScript.Shell") Set objFS = WScript.CreateObject("Scripting.FileSystemObject") strPath = Wscript.FullName strFileVersion = objFS.GetFileVersion(strPath) iRetVal = objShell.Popup(Wscript.FullName & vbCrLf & _ "File Version: " & _ strFileVersion & vbCrLf & _ "Möchten Sie mehr wissen?" _ ,TIMEOUT,"Weitere Informationen?",vbYesNo + vbQuestion) Select Case iRetVal Case vbYes Set objFile = objFS.GetFile(strPath) objShell.Popup WScript.FullName & vbCrLf & vbCrLf & _ "Dateiversion: " & strFileVersion & vbCrLf & _ "Dateigröße: " & Round((objFile.Size/1024),2) & _ " KB" & vbCrLf & _ "Erstellungsdatum: " & objFile.DateCreated & vbCrLf & _ "Letzte Änderung: " & objFile.DateLastModified & _ vbCrLf,TIMEOUT Wscript.Quit Case vbNo Wscript.Quit Case -1 WScript.StdOut.WriteLine "Time-Out" Wscript.Quit End Select

Zum Seitenanfang

Das Objekt WshNetwork

Das Objekt WshNetwork ermöglicht es Ihren Scripten mit Netzwerklaufwerken und -druckern zu arbeiten. Außerdem können Sie den Namen des Computers, dessen Domäne und den Namen des angemeldeten Benutzers abfragen.

Das WshNetwork-Objekt kann für einige Aufgaben verwendet werden, die Sie auch über das Kommandozeiletool net.exe ausführen können. Der Befehl net name gibt zum Beispiel den Namen des Benutzers und den Namen des Computers zurück. Mit dem Befehl net use können Sie ein Netzlaufwerk erstellen. Diese Aufgaben können Sie auch über das Objekt WshNetwork ausführen, das somit zu einem idealen Werkzeug für Anmeldescripte wird.

In Tabelle 3.21 sehen Sie die Funktionalitäten von WshNetwork und dessen Methoden und Eigenschaften.

Tabelle 3.21: Methoden und Eigenschaften des Objekts WshNetwork

Funktionalität	Methode und Eigenschaft
Arbeiten mit Netzlaufwerken	MapNetworkDrive EnumNetworkDrives RemoveNetworkDrive
Arbeiten mit Netzwerkdruckern	AddPrinterConnection AddWindowsPrinterConnection EnumPrinterConnections SetDefaultPrinter RemovePrinterConnection
Informationen über den angemeldeten Benutzer abrufen	ComputerName UserDomain UserName

WshNetwork ist Teil des Windows Script Host-Objektmodells (wshom.ocx). Das Objektmodell von WshNetwork sehen Sie in Abbildung 3.15. Über die Methoden EnumNetworkDrives und EnumPrinterConnections des Objekts erhalten Sie unter anderem das Objekt WshCollection zurück.

Abbildung 3.15: Das Objektmodell von WshNetwork

Auf das Objekt WshNetwork zugreifen

Bei WshNetwork handelt es sich um ein COM-Objekt. Mit dem folgenden Ausdruck können Sie eine Instanz des Objekts erstellen:

Set objNetwork = WScript.CreateObject("WScript.Network")

Verwalten von Netzlaufwerken

Netzlaufwerke sind ein wichtiger Teil einer Netzwerkumgebung. Benutzer ziehen es normalerweise vor, mit Netzlaufwerken statt mit UNC-Pfaden (Universal Naming Convention) zu arbeiten - es ist einfach, sich daran zu erinnern, dass die Finanzdaten unter Laufwerk X gespeichert sind, als sich an die Netzwerkfreigabe \\atl-fs-01\departments\accounting\admin\financial_records\2002_archive zu erinnern.

Das Erstellen, Ändern und Löschen von Netzwerkfreigaben zu Laufwerksbuchstaben ist eine der wenigen Aufgaben, die Sie nicht über WMI durchführen können - das Auflisten von Netzwerklaufwerken ist hingegen sowohl mit dem WSH-Objekt WshNetwork alsauch über WMI (über die Klasse Win32_MappedLogicalDisk) möglich.

Zur Arbeit mit Netzlaufwerken stellt Ihnen WshNetwork drei Methoden zur Verfügung: MapNetworkDrive, RemoveNetworkDrive und EnumNetworkDrives.

Zuordnen von Netzwerklaufwerken

Über die Methode MapNetworkDrive ordnen Sie einen Laufwerksbuchstaben zu einer Netzwerkfreigabe zu. Die Methode hat zwei zwingende und drei optionale Argumente - diese sehen Sie in Tabelle 3.22.

Tabelle 3.22: Parameter von MapNetworkDrive

Parameter	Type	Erforderlich	Standardwert	Beschreibung
LocalName	String		Keiner	Der Laufwerksbuchstabe gefolgt von einem Doppelpunkt, der für das Netzlaufwerk verwendet werden soll (zum Beispiel H:)
RemoteName	String		Keiner	Der UNC-Pfad der Netzwerkfreigabe - zum Beispiel \\ServerName\ShareName oder \\ServerName\ShareName\FolderName.
UpdateProfile	Boolean		False	Ein Boolean-Wert, der angibt, ob das neue Laufwerk im aktuellen Benutzerprofil gespeichert werden soll. Mit dem Wert True wird das neue Laufwerk gespeichert.
UserName	String		Keiner	Verbindet das Netzlaufwerk unter Verwendung eines alternativen Benutzernamens.
Password	String		Keiner	Das Passwort zum alternativen Benutzernamen.

Das folgende Script zeigt, wie Sie mit MapNetworkDrive zwei neue Netzlaufwerke erstellen:

Set objNetwork = Wscript.CreateObject("WScript.Network")
objNetwork.MapNetworkDrive "G:", "\\atl-fs-01\Sales"
objNetwork.MapNetworkDrive "H:", "\\atl-fs-01\Users$\lewjudy"

Standardmäßig verwendet MapNetworkDrive die Anmeldeinformationen des aktuellen Benutzers. Da Sie jedoch ein Netzlaufwerk nur dann zuordnen können, wenn Sie über die erforderlichen Berechtigungen verfügen, haben Sie die Möglichkeit, über die Parameter UserName und Password alternative Anmeldeinformationen anzugeben - zum Beispiel für administrative Scripte.

Es gibt zwei Gründe, aus denen die Methode MapNetworkDrive fehlschlagen kann:

• Der Benutzer, der das Script ausführt verfügt nicht über ausrechende Berechtigungen um ein Netzwerklaufwerk zu erstellen.
• Der lokale Laufwerksbuchstabe wird bereits verwendet.

Um Fehler durch fehlende Berechtigungen zu vermeiden, sollten Sie eine Fehlerbehandlung über den Befehl On Error Resume Next implementieren. Einen Fehler durch einen bereits verwendeten Laufwerksbuchstaben können Sie zum Beispiel umgehen, indem Sie das Laufwerk trennen, das im Moment den Laufwerksbuchstaben verwendet.

Ein Netzlaufwerk trennen

Über die Methode RemoveNetworkDrive können Sie ein Netzlaufwerk trennen. Sie benötigt als einzigen Parameter den lokalen Laufwerksbuchstaben von dem Netzlaufwerk, das Sie trennen möchten.

Script 3.36: Trennen eines Netzlaufwerkes

1 2	Set objNetwork = WScript.CreateObject("Wscript.Network") objNetwork.RemoveNetworkDrive "G:"

Die Methode akzeptiert zwei weitere optionale Parameter:

• Einen Boolean-Wert - Wenn dieser auf True gesetzt ist, dann wird das Netzlaufwerk auch dann getrennt, wenn es gerade verwendet wird.
• Einen weiteren Boolean-Wert - Wenn dieser auf True gesetzt ist, dann wird das Netzlaufwerk auch aus dem Benutzerprofil entfernt.

Auflisten der aktuellen Netzlaufwerke

Mit der Methode EnumNetworkDrives können Sie die aktuell zugeordneten Netzlaufwerke auflisten. Sie gibt eine Collection zurück, in der jeweils in Paaren die lokalen Laufwerksbuchstaben und die entsprechenden UNC-Pfade gespeichert sind. Der Index der Collection beginnt bei 0 - die Elemente mit einer geraden Indexnummer enthalten jeweils die lokalen Laufwerksbuchstaben, und die ungeraden Elemente enthalten die UNC-Pfade.

In Tabelle 3.23 sehen Sie ein Beispiel für die Collection.

Tabelle 3.23: Beispiel für die Collection mit den Netzwerklaufwerken

Index	Wert
0	D:
1	\\atl-fs-01\users\kmyer
2	E:
3	\\atl-fs-02\accounting
4	F:
5	\\atl-fs-03\public

Wenn Sie die einzelnen Netzlaufwerke aus der Collection abfragen möchten, dann sollten Sie in jedem Schleifendurchlauf jeweils zwei Elemente (den Laufwerksbuchstaben und den UNC-Pfad) abfragen. Ein Beispiel hierfür sehen Sie in Script 3.37.

Listing 3.37: Abfragen der aktuellen Netzlaufwerke

1 2 3 4 5	Set objNetwork = WScript.CreateObject("WScript.Network") Set colDrives = objNetwork.EnumNetworkDrives For i = 0 to colDrives.Count-1 Step 2 Wscript.Echo colDrives.Item(i) & vbTab & colDrives.Item (i + 1) Next

Verwalten von Netzwerkdruckern

Mit dem WshNetwork-Objekt haben Sie die Möglichkeit Netzwerkdrucker hinzuzufügen oder zu entfernen, den Standarddrucker zu definieren und die Netzwerkdrucker aufzulisten.

Netzwerkdrucker hinzufügen

Es gibt zwei Methoden zum Hinzufügen von Netzwerkdruckern: AddWindowsPrinterConnection und AddPrinterConnection.

Mit der Methode AddWindowsPrinterConnection fügen Sie Windows-basierte Drucker hinzu (zum Beispiel so wie über den Assistenten Drucker hinzufügen der Systemsteuerung), und mit der Methode AddPrinterConnection fügen Sie eine MS-DOS-basierten Drucker hinzu.

Windows-basierte Netzwerkdrucker hinzufügen

Mit der Methode AddWindowsPrinterConnection können Sie Drucker unter Windows 2000, Windows Server 2003, Windows XP oder Windows NT hinzufügen. Als einzigen Parameter müssen Sie hier den UNC-Pfad des Druckers angeben.

Script 3.38: Hinzufügen einer Windows-basierten Druckerverbindung

1 2	Set objNetwork = Wscript.CreateObject("WScript.Network") objNetwork.AddWindowsPrinterConnection "\\HRServer01\Printer1"

Wenn Sie die Methode unter Windows 95, Windows 98 oder Windows Me verwenden, dann müssen sie zwei Parameter angeben: den UNC-Pfad des Druckers und den Namen des Druckertreibers (dieser muss bereits installiert sein). Außerdem akzeptiert die Methode unter diesen Betriebssystemen einen dritten optionalen Parameter - den lokalen Port für den Drucker.

Hinzufügen von MS-DOS-basierten Druckerverbindungen

Mit der Methode AddPrinterConnection können Sie MS-DOS-basierte Druckerverbindungen hinzufügen. Sie benötigt zwei Parameter: den lokalen Port für den Druck und den UNC-Pfad des Netzwerkdruckers.

Außerdem haben Sie die Möglichkeit, die neue Druckerverbindung zum Profil des Benutzers hinzuzufügen. Hierzu verwenden Sie einen optionalen dritten Parameter. Wenn dieser auf True gesetzt ist, dann wird die neue Druckerverbindung im Profil gespeichert.

Entfernen einer Druckerverbindung

Um eine Druckerverbindung zu entfernen, verwenden Sie die Methode RemovePrinterConnection.

WshNetwork.RemovePrinterConnection(printerName, [forced], [updateProfile])

Der erste Parameter definiert den freigegebenen Drucker. Die beiden anderen Parameter sind optional:

• Soll die Verbindung auch dann getrennt werden, wenn der Drucker gerade verwendet wird?
• Soll die Verbindung auch aus dem Benutzerprofil gelöscht werden?

Die Methode entfernt sowohl Windows- als auch MS-DOS-basierte Druckerverbindungen. Wenn der Drucker über die Methode AddPrinterConnection eingerichtet wurde, dann muss als Druckername der lokale Port angegeben werden. Wenn der Drucker mit der Methode AddWindowsPrinterConnection angelegt wurde, dann muss als Druckername der UNC-Pfad des Druckers angegeben werden.

Der folgende Befehl entfernt zum Beispiel den Drucker \\atl-ps-01\colorprinter.

Set objNetwork = WScript.CreateObject("WScript.Network")
objNetwork.RemovePrinterConnection "\\atl-ps-01\colorprinter"

Auflisten der verfügbaren Drucker

Die Abfrage der verfügbaren Netzwerkdrucker funktioniert genauso wie die Abfrage der zugeordneten Netzwerklaufwerke. Mit der Methode EnumPrinterConnections erhalten Sie eine Collection mit den Netzwerkdruckern. In ihr sind paarweise die lokalen Druckernamen bzw. die Ports und die UNC-Pfade gespeichert.

Script 3.39: Auflisten der verfügbaren Drucker

1 2 3 4 5	Set objNetwork = WScript.CreateObject("WScript.Network") Set colPrinters = objNetwork.EnumPrinterConnections For i = 0 to colPrinters.Count -1 Step 2 Wscript.Echo colPrinters.Item(i) & vbTab & colPrinters.Item (i + 1) Next

Wenn Sie das Script unter CScript ausführen, könnte die Ausgabe so aussehen:

LPT1:   Drucker Marketing-Abteilung
XRX00034716DD75 \\atl-prn-xrx\plotter
XRX0000AA622E89 \\atl-prn-xrx\farbdrucker

Definieren des Standarddruckers

Viele Benutzer drucken Dokumente einfach über das Drucken-Symbol der Anwendung aus. In den meisten Fällen bedeutet das, dass das Dokument über den Standarddrucker ausgedruckt wird. Wenn Sie den verschiedenen Benutzern unterschiedliche Standarddrucker zuweisen, können Sie die Last auf verschiedene Drucker verteilen. Dies können Sie über die Methode SetDefaultPrinter durchführen. Die Methode verwendet die folgende Syntax:

WshNetwork.SetDefaultPrinter(printerName)

Beim Parameter printerName handelt es sich um den UNC-Pfad des Druckers (wenn es sich um einen lokalen Drucker handelt, können Sie den Port des Druckers verwenden - zum Beispiel LPT1). Das folgende Script richtet den Drucker \\atl-ps-01\colorprinter als Standarddrucker ein:

Set objNetwork = WScript.CreateObject("WScript.Network")
objNetwork.SetDefaultPrinter("\\atl-ps-01\colorprinter")

Den aktuellen Standarddrucker können Sie über SetDefaultPrinter leider nicht abfragen.

Informationen über den Benutzer und den Computer abfragen

Das Objekt WshNetwork stellt drei Eigenschaften zur Verfügung: ComputerName, UserDomain und UserName - Sie können diesen Eigenschaften allerdings keinen Wert zuweisen (Nur-Lese-Eigenschaften).

Abhängig von Ihren Anforderungen können Sie die gleichen Informationen auch über ADSI abrufen. Mit dem WSH können Sie außerdem nur den SAM-Kontonamen abrufen - mit ADSI haben Sie auch Zugriff auf Informationen wie dem eindeutigen Namen (Distinguished Name - DN) des Objekts (zum Beispiel cn=Ulf Dornheck Busscher,ou=Human Resources,dc=fabrikam,dc=com). Mit dem DN können Sie dann direkt auf Active Directory zugreifen und Informationen wie zum Beispiel die Gruppenzugehörigkeit des Benutzers abrufen.

Wenn Sie jedoch nur den Benutzernamen, den Domänennamen oder den Computernamen benötigen, dann reicht das Objekt WshNetwork vollkommen aus. Außerdem steht das WSH-Objekt unter Windows 98 und Windows NT 4.0 standardmäßig zur Verfügung - dies ist bei ADSI nicht der Fall.

Das WshNetwork-Objekt wird oft in Anmeldescripten verwendet - hier werden die Informationen zum Beispiel zum Zuordnen von Netzwerklaufwerken benötigt. Script 3.40 führt eine solche Zuordnung durch (N zu \\fileserver01\accounting ). Jedoch nur, wenn der Benutzer der Domäne ACT angehört. Wenn der Benutzer der Domäne DEV angehört, dann wird Laufwerk N zu \\fileserver01\development zugeordnet.

Script 3.40: Zuordnen von Netzwerklaufwerken abhängig von der Domäne des Benutzers

1 2 3 4 5 6 7 8 9 10 11

Set objNetwork = WScript.CreateObject("WScript.Network") strUserDomain = objNetwork.UserDomain If strUserDomain = "ACCOUNTING" Then objNetwork.MapNetworkDrive "N:", "\\fileserver01\accounting", True ElseIf strUserDomain = "DEVELOPMENT" Then objNetwork.MapNetworkDrive "N:", "\\fileserver01\development", True Else Wscript.Echo "User " & objNetwork.UserName & _ "not in ACCOUNTING or DEVELOPMENT. N: not mapped." End If

Zum Seitenanfang

Das Objekt WshController

Eine Einschränkung des WSH war es immer, dass Scripte nur lokal ausgeführt werden können. Es war nicht möglich ein Script gegen einen Remotecomputer auszuführen. Stellen Sie sich zum Beispiel vor, Sie möchten über ein Script auf einigen Remotecomputern eine Druckerverbindung hinzufügen. Sie müssten dieses Script auf allen Remotecomputern ausführen. In der Vergangenheit waren Sie nicht in der Lage ein Script auf Computer A auszuführen und in diesem Script auf Computer B eine Druckerverbindung hinzuzufügen. Daher wurde der WSH auch primär nur in Anmeldescripten verwendet.

Natürlich wäre es viel praktischer, wenn ein Script Änderungen auf einem oder mehreren Remotecomputern durchführen könnte. Hierzu stellt Ihnen ab WSH 5.6 das Objekt WshController zur Verfügung.

Das Objekt WshController ermöglicht es Ihnen, ein *Controller Script (Steuerungsscript)*zu erstellen, das Worker Scripts (Arbeitsscripte) gegen andere Computer ausführen kann. Das Controller Script initiiert, überwacht und beendet das Worker Script. Das Worker Script ist hingegen einfach ein Script, das administrative Aufgaben ausführt - zum Beispiel das Hinzufügen einer Druckerverbindung oder eines Netzwerklaufwerkes.

Das Worker Script muss sich nicht auf dem selben Computer befinden wie das Controller Script - sein Speicherort muss jedoch relativ zu dem Computer angegeben werden, auf dem das Controller Script ausgeführt wird. Sie können zum Beispiel ein Controller Script erstellen, das auf ein Worker Script in einer Netzwerkfreigabe auf einem anderen Computer zugreift und dieses Worker Script auf einem dritten Computer ausführt.

Das Script, das auf dem Remotecomputer ausgeführt wird, wird hierbei niemals auf dem Remotecomputer gespeichert. Stattdessen wird es im WSH-Prozess des Remotecomputers gestartet.

In Abbildung 3.16 sehen Sie eine Liste aller Objekte, Methoden, Eigenschaften und Ereignisse des WshController-Objektes.

Abbildung 3.16: Das Objektmodell von WshController

Auf das Objekt WshController zugreifen

Bei WshController handelt es sich um ein COM-Objekt. Über die folgende Codezeile können Sie eine Instanz des Objekts erstellen:

Set objController = WScript.CreateObject("WshController")

Anmerkung:
Die ProgID des Objekts WshController folgt nicht denselben Namenskonventionen wie den Objekten WshNetwork (WScript.Network) und WshShell (WScript.Shell). Sie verwendet keinen Punkt und beginnt nicht mit WScript.

Vorbereiten der Remoteausführung von Scripten

Bevor Sie das Objekt WshController verwenden können, müssen Sie Ihre Umgebung folgendermaßen konfigurieren:

• Sowohl auf dem lokalen Computer als auch auf dem Remotecomputer muss der WSH in der Version 5.6 installiert sein.
• Sie müssen dem Registrierunsschlüssel HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings auf allen Zielcomputern einen String-Eintrag (REG_SZ) mit dem Namen Remotehinzufügen und dessen Wert auf 1 setzen. Auf dem lokalen Computer, von dem aus Sie das Script starten, ist dieser Eintrag nicht erforderlich.

Script 3.41 verwendet den WMI-Provider Registry, um den Eintrag Remote zur Registrierung des in der Variable strComputer definierten Computers hinzuzufügen und diesen auf den Wert 1 zu setzen.

Script 3.41: Hinzufügen eines Registrierungseintrags, um Scripte remote ausführen zu können

1 2 3 4 5 6 7 8	Const HKEY_LOCAL_MACHINE = &H80000002 strComputer = "RemoteComputerName" Set objRegProv = GetObject("winmgmts:{impersonationLevel=Impersonate}" & _ "!\\" & strComputer & "\root\default:StdRegProv") strKeyPath = "SOFTWARE\Microsoft\Windows Script Host\Settings" objRegProv.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,"Remote","1"

Der Benutzer, der das Script ausführt, muss ein Mitglied der Gruppe Administratoren des Zielcomputers sein.

Funktionalitäten von WshController

Das Objekt WshController ermöglicht es Ihnen, Scripte aus Remotecomputern auszuführen, deren Status zu überwachen und die von diesen Scripten generierten Fehler abzufragen. In Tabelle 3.24 sehen Sie die Methoden, Eigenschaften und Ereignisse der Objekte WshController, WshRemote und WshRemoteError, die Sie hierzu verwenden können.

Tabelle 3.24: Methoden, Eigenschaften und Ereignisse der Objekte WshController, WshRemote und WshRemoteError

Aufgabe	Methode, Eigenschaft oder Ereignis
Scripte auf Remotecomputern ausführen	CreateScript, Execute, Terminate
Den Status von Remotescripten überwachen	Status, Start, End, Error (Ereignisse)
Fehler eines Remotescripts abfragen	Error (Ereignis), Error (Eigenschaft), Character, Description, Line, Number, Source, SourceText

Scripte auf einem Remotecomputer ausführen

Zum Starten eine Scripts auf einem Remotecomputer stellt Ihnen WshController die Methode CreateScript zur Verfügung - diese gibt ein WshRemote-Objekt zurück.

Das WshRemote-Objekt kann dann zum Ausführen des Worker Scripts verwendet werden. Das Worker Script wird also nicht über die Methode CreateScript selbst gestartet. Stattdessen wird die Methode Execute des neuen WshRemote-Objekts zum Start des Scripts auf dem Remotecomputer verwendet.

Script 3.42 startet das hypothetische Worker Script MapNetworkDrive.vbs auf dem Remotecomputer RASServer01. Die Position des Worker Scripts kann als lokaler Pfad oder als UNC-Pfad angegeben werden. In Script 3.42 wird allerdings gar kein Pfad angegeben - in diesem Fall muss sich das Worker Script im gleichen Ordner befinden wie dass Controller Script.

Script 3.42: Ein lokales Script auf einem Remotecomputer ausführen

1 2 3 4 5 6 7 8 9 10 11	strRemoteComputer = "RASServer01" strWorkerScript = "MapNetworkDrive.vbs" Set objWshController = WScript.CreateObject("WshController") Set objRemoteScript = _ objWshController.CreateScript(strWorkerScript, strRemoteComputer) objRemoteScript.Execute Do While Not objRemoteScript.Status = 2 Wscript.Sleep(100) Wscript.Echo "Remote script not yet complete." Loop

Anmerkung:
Ein Remotezugriff ist kein interaktiver Prozess - das bedeutet, dass Remotescripte keine GUI-Elemente auf dem Remotecomputer anzeigen können. Wenn Sie dies versuchen, schlägt das Script fehl oder produziert unerwartete Ergebnisse - ein Nachrichtenfenster ist zum Beispiel nicht zu sehen.

Den Status von Remotescripten überwachen

Wenn Sie ein Remotescript starten, dann möchten Sie wahrscheinlich auch wissen, ob das Script erfolgreich ausgeführt wurde. Das Objekt WshRemote verfügt hierzu über eine Eigenschaft mit dem Namen Status. Sie kann drei verschiedene Werte annehmen:

• 0 - das Remotescript wurde noch nicht gestartet.
• 1 - das Remotescript wird gerade ausgeführt.
• 2 - die Ausführung des Remotescripts ist beendet.

Zusätzliche zur Eigenschaft Status stehen Ihnen drei Ereignisse zur Überwachung des Remotescripts zu Verfügung:

• Start - dieses Ereignis wird ausgelöst, wenn die Ausführung des Remotescripts beginnt.
• End - dieses Ereignis wird bei Beendigung des Remotescripts ausgelöst.
• Error - dieses Ereignis wird ausgelöst, wenn im Remotescript ein Fehler auftritt. In einem solchen Fall können Sie über das Objekt WshRemoteError von WshRemote weitere Informationen über den Fehler abfragen.

Script 3.43 verwendet drei Subroutinen (Remote_Start, Remote_End und Remote_Error), die auf die Ereignisse Start, Error und End reagieren. Diese Subroutinen werden aufgerufen, wenn eins der Ereignisse ausgelöst wird, und sie zeigen eine einfache Nachricht an.

Durch den Aufruf von ConnectObject in Zeile 7 zwingt das Script dazu auf die Ereignisse zu reagieren. Beachten Sie, dass der String 'Remote_', der als zweiter Parameter übergeben wird, der erste Teil des Namens der Subroutine ist, die das entsprechende Ereignis verarbeitet. Der zweite Teil des jeweiligen Namens ergibt sich aus dem jeweiligen Ereignis.

Script 3.43: Überwachen eines remote ausgeführten Scripts

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

strRemoteComputer = "RASServer01" strWorkerScript = "CreateTextFilMapNetworkDrive.vbs" Set objWshController = WScript.CreateObject("WshController") Set objRemoteScript =_ objWshController.CreateScript(strWorkerScript, strRemoteComputer) Wscript.ConnectObject objRemoteScript, "Remote_" objRemoteScript.Execute Do While Not objRemoteScript.Status = 2 Wscript.Sleep(100) Loop Sub Remote_Start Wscript.Echo "Start des Remotescripts." End Sub Sub Remote_Error Wscript.Echo "Fehler im Remotescript." objRemoteScript.Terminate Wscript.Quit End Sub Sub Remote_End Wscript.Echo "Beendigung des Remotescripts." End Sub

Wenn alles wie erwartet funktioniert, werden nur die Ereignisse Start und End ausgelöst - im Fall eines Fehlers wird das Ereignis Error ausgelöst. Weitere Informationen zur Abfrage von weiteren Fehlerdetails finden Sie im folgenden Abschnitt.

Die vom Remotescript ausgelösten Fehler genauer untersuchen

Wenn ein Fehler aufgetreten ist, dann müssen Sie feststellen, wie dieser Fehler zustande gekommen ist. Hierzu können Sie bei einem Remotescript das Objekt WshRemoteError verwenden (dieses Objekt ist eine Eigenschaft von WshRemote). Es enthält einige Eigenschaften, die den aufgetretenen Fehler genauer definieren. Diese Eigenschaften sehen Sie in Tabelle 3.25.

Tabelle 3.25: Eigenschaften des Objekts WshRemoteError

Eigenschaft	Beschreibung
Character	Gibt die Zeichenposition in der aktuellen Scriptzeile wieder, an der der Fehler aufgetreten ist. Beim Semikolon in der folgenden Zeile handelt es sich zum Beispiel um ein falsches Zeichen - es befindet sich an Position 14 der Zeile. Die Eigenschaft Character würde also den Wert 14 zurückgeben: Wscript.Echo ;
Description	Eine Beschreibung des Fehlers
Line	Die Zeilennummer des Scripts, in der der Fehler aufgetreten ist.
Number	Der Fehlercode des Fehlers.
Source	Das COM-Objekt, das den Fehler ausgelöst hat.
SourceText	Die Scriptzeile, die den Fehler ausgelöst hat. Diese Eigenschaft enthält jedoch nicht in allen Fällen einen Wert.

Script 3.44 reagiert mit einer Subroutine auf das Error-Ereignis. Im Gegensatz zu Script 3.43, dass nur eine einfach Fehlermeldung angezeigt hat, verwendet die Subroutine die Eigenschaft Error von WshRemote, um eine Instanz des Objekts WshRemoteError zu erhalten. Dann zeigt das Script alle verfügbaren Eigenschaften des Objekts an.

Script 3.44: Abfragen von Fehlerinformationen bei Remotescripten

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

strRemoteComputer = "RASServer01" strWorkerScript = "CreateTestFile.vbs" Set objWshController = WScript.CreateObject("WshController") Set objRemoteScript =_ objWshController.CreateScript(strWorkerScript, strRemoteComputer) Wscript.ConnectObject objRemoteScript, "Remote_" objRemoteScript.Execute Do While Not objRemoteScript.Status = 2 Wscript.Sleep(100) Loop Sub Remote_Error Wscript.Echo "Fehler im Remotescript." Set objError = objRemoteScript.Error Wscript.Echo "Character :" & objError.Character Wscript.Echo "Description :" & objError.Description Wscript.Echo "Line :" & objError.Line Wscript.Echo "Number :" & objError.Number Wscript.Echo "Source :" & objError.Source Wscript.Echo "Source Text :" & objError.SourceText objRemoteScript.Terminate Wscript.Quit End Sub

Beschränkungen im Zusammenhang mit Remotescripten

Es gibt zwei wichtige Einschränkungen im Zusammenhang mit Remotescripten. Erstens gibt es keinen einfachen Weg, um an die Ausgaben des Remotescripts zu gelangen, und zweitens können Remotescripte nicht mit den Kontoinformationen des Benutzers arbeiten, der das Controller Script ausgeführt hat.

Um das erste Problem zu umgehen, können Sie eine Textdatei erstellen, in der das Worker Script dann seine Ausgaben speichert - diese Textdatei kann dann zum Beispiel in einer Netzwerkfreigabe gespeichert sein. Weitere Informationen zur Erstellung von Textdateien erhalten Sie im Kapitel Script Runtime Primer in diesem Buch.

Es gibt leider keinen Weg, um das zweite Problem zu vermeiden - jedenfalls nicht ohne potentielle Sicherheitsprobleme.

Zum Seitenanfang

Absichern von Scripten

Sicherheit ist in der Systemadministration immer ein wichtiges Thema - dies gilt auch für Scripte. Der ILOVEYOU-Virus war nicht so erfolgreich, weil er Sicherheitslücken im Windows Script Host ausgenutzt hat, sondern durch menschliches Fehlverhalten: Menschen sind von natur aus neugierig. Wenn Sie mit der Frage konfrontiert werden 'Wollen Sie dieses Script ausführen', und keine weiteren Informationen zur Verfügung stehen, dann entscheiden sich viele Menschen dafür mit 'Ja' zu antworten.

Der WSH 5.6 hilft den Benutzern intelligentere Entscheidungen zu treffen. Sie können den WSH zum Beispiel so konfigurieren, dass er eine Nachricht wie 'Der Autor dieses Scripts ist unbekannt. Sind Sie sicher, dass Sie fortfahren wollen?' anzeigt, wenn ein Benutzer versucht ein Script auszuführen. Alternativ kann der Administrator den Benutzern diese Entscheidung auch abnehmen - der WSH kann so konfiguriert werden, dass er nur Scripte ausführt, die digital signiert und freigegeben wurden.

In diesem Abschnitt werden mehrere Techniken untersucht, mit der Sie die Sicherheit Ihrer Scripte verbessern können:

• Signieren von Scripten.
• Den Benutzer in der Scriptausführung einschränken.
• Den Windows Script Host deaktivieren.

Zum Seitenanfang

Signieren von Scripten

Digitale Signaturen (eingeführt mit WSH 5.6) bieten Ihnen einen Weg, den Autoren eines Scripts zu überprüfen und zu garantieren, dass das Script seit seiner Erstellung und Signierung nicht verändert wurde. Das bedeutet nicht zwingend, dass das Script 'sicher' ist - auch Virenautoren können Signaturen verwenden. Die Signatur bietet Ihnen jedoch zwei Vorteile:

• Sie können definieren, welchen Scriptautoren vertraut wird und welchen nicht. Zum Beispiel könnten Sie festlegen, dass nur die Scripte ausgeführt werden, die mit einem vertrauenswürdigen Zertifikat signiert wurden.
• Sie können sicherstellen, dass ein Script seit seiner Signierung nicht verändert wurde. Wenn Sie wissen, dass das Script ThirdPartyScript.vbs sicher ist, dann können Sie das Script in dem sicheren Wissen verwenden, dass es von niemandem manipuliert wurde. Wenn ein Script signiert wird, dann wird ein 'Hash' für dieses Script ermittelt. Mit diesem Hash kann die Signatur des Scripts überprüft werden. Wenn das Script verändert wurde, dann ist der Hash nicht mehr gültig.

Wenn ein Script signiert wird, dann wird am Ende des Scripts eine digitale Signatur als Kommentar angehängt. Eine solche Signatur kann zum Beispiel so aussehen:

'' SIG '' Begin signature block
'' SIG '' MIIC8AYJKoZIhvcNAQcCoIIC4TCCAt0CAQExDjAMBggq
'' SIG '' hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG
'' SIG '' AQQBgjcCAR4wJAIBAQQQTvApFpkntU2P5azhDxfrqwIB
'' SIG '' AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEEPC2
'' SIG '' QdSn0Xnjl7nT/Xwadl2gggF6MIIBdjCCASCgAwIBAgIQ
'' SIG '' NeMgQmXo1o1F8M6hs6TX1jANBgkqhkiG9w0BAQQFADAW
'' SIG '' MRQwEgYDVQQDEwtSb290IEFnZW5jeTAeFw0wMDEyMjEy
'' SIG '' MzUxMTJaFw0zOTEyMzEyMzU5NTlaMBUxEzARBgNVBAMT
'' SIG '' Ck15IENvbXBhbnkwXDANBgkqhkiG9w0BAQEFAANLADBI
'' SIG '' AkEAx/bBOOqOzdHk2EfxXloUaGo9PtI/HSJ9LQSXkhF7
'' SIG '' neEf4Qy+oyA7NImnOacI+1HDCOAPeKgGJIvaFcZs0BuM
'' SIG '' iQIDAQABo0swSTBHBgNVHQEEQDA+gBAS5AktBh0dTwCN
'' SIG '' YSHcFmRjoRgwFjEUMBIGA1UEAxMLUm9vdCBBZ2VuY3mC
'' SIG '' EAY3bACqAGSKEc+41KpcNfQwDQYJKoZIhvcNAQEEBQAD
'' SIG '' QQA6/fIIDKycSp2DdBT/A3iUSxoiu2BqmEEpVoGKE5yY
'' SIG '' CA3MDWuI29RRvgNJ2oQasb8rZiD5dEexGK3rWEQGV6r+
'' SIG '' MYHhMIHeAgEBMCowFjEUMBIGA1UEAxMLUm9vdCBBZ2Vu
'' SIG '' Y3kCEDXjIEJl6NaNRfDOobOk19YwDAYIKoZIhvcNAgUF
'' SIG '' AKBOMBAGCisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJ
'' SIG '' AzEMBgorBgEEAYI3AgEEMB8GCSqGSIb3DQEJBDESBBCV
'' SIG '' t6owbn7YLnkAnCqiDdINMA0GCSqGSIb3DQEBAQUABECe
'' SIG '' xmfNlmrIls2kFkyhXOWKicnpOk5iW4twTRNAc4LAkO8M
'' SIG '' uk0ZBCBgR5XC8F7slEMfWCG9R7129EUF4vFhZToK
'' SIG '' End signature block

Die Verwendung von signierten Scripten erzwingen

Um die Sicherheitseinstellung für signierte und unsignierte Scripte zu konfigurieren, müssen Sie den Registrierungsschlüssel HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\TrustPolicy bearbeiten. Die folgenden Werte können Sie verwenden:

• 0 - alle Scripte werden ohne Warnung ausgeführt (die Standardeinstellung).
• 1 - bevor ein Script ausgeführt wird, wird eine Sicherheitswarnung mit dem Sicherheitsstatus des Scripts angezeigt (signiert und überprüft, signiert und nicht überprüft und unsigniert). Der Benutzer hat jedoch unabhängig vom Status des Scripts die Möglichkeit das Script auszuführen. Außerdem kann er sich weitere Informationen zur Signierung des verwendeten Zertifikats anzeigen lassen.
• 2 - bevor ein Script ausgeführt wird, wird dessen Signatur überprüft. Es wird geprüft, ob das Script aus einer vertrauenswürdigen Quelle stammt. Wenn dies der Fall ist, dann wird das Script automatisch ausgeführt. Wenn das Script unsigniert ist oder nicht aus einer vertrauenswürdigen Quelle stammt, dann wird das Script nicht ausgeführt. Der Benutzer hat in so einem Fall keine Möglichkeit die Ausführung des Scripts zu erzwingen. Er erhält stattdessen die folgende Nachricht:
• Ausführung des Windows Script Host fehlgeschlagen. (Keine Signatur vorhanden.)

Scripte über ein mit Hilfe eines Scripts signieren

Der WSH 5.6 stellt ein Objekt mit dem Namen Scripting.Signer zur Verfügung, über das Sie ein Script mit Hilfe eines Scripts signieren können. Hierzu gehen Sie folgendermaßen vor:

• Erstellen Sie eine Instanz des Objekts Scripting.Signer.
• Verwenden Sie die Methode SignFile. Diese erwartet als Parameter den Dateinamen des zu signierenden Scripts und den Namen des Zertifikats, mit dem das Script signiert werden soll.

Das folgende Script verwendet zum Beispiel das Zertifikat mit dem Namen IT Department und das Script C:\Scripts\CreateUsers.vbs zu signieren:

set objSigner = WScript.CreateObject("Scripting.Signer")
objSigner.SignFile "C:\Scripts\CreateUsers.vbs", "IT Department"

Sie können auch mehrere Scripte auf einmal signieren. Das folgende Script verwendet eine Schleife, um alle Scripts im Ordner C:\Scripts zu signieren (es geht allerdings davon aus, dass in diesem Ordner nur Scripte gespeichert sind):

set objSigner = WScript.CreateObject("Scripting.Signer")
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder("c:\scripts")
Set colListOfFiles = objFolder.Files
For each objFile in colListOfFiles
    objSigner.SignFile objFile.Name, "IT Department"
Next

Eine Signatur mit Hilfe eines Scripts überprüfen

Das Objekt Scripting.Signer kann auch zur Überprüfung einer Signatur verwendet werden. Hierzu verwenden Sie die Methode VerifyFile mit den folgenden Parametern:

• Dem Dateinamen des Scripts, dessen Signatur Sie überprüfen möchten.
• Einen Boolean-Wert, der angibt ob, Sie eine Sicherheitsmeldung anzeigen möchten, wenn die Signatur nicht überprüft werden kann. Wenn der Wert auf False gesetzt ist, dann wird keine Meldung angezeigt.

Das folgende Script überprüft die Signatur von Script C:\Scripts\CreateUsers.vbs und unterdrückt die Sicherheitswarnung. Es gibt einen von zwei möglichen Werten zurück: True bedeutet, dass die Signatur überprüft wurde, und False bedeutet, dass das Script nicht signiert ist oder die Signatur nicht überprüft werden konnte:

set objSigner = WScript.CreateObject("Scripting.Signer")
blnShowGUI = False

blnIsSigned = objSigner.VerifyFile("C:\Scripts\CreateUsers.vbs", blnShowGUI)
    If blnIsSigned then
        WScript.Echo objFile.Name & " wurde signiert."
    Else
        WScript.Echo objFile.Name & " wurde nicht signiert."
    End If
End If

Natürlich können Sie auch mit der Methode VerifyFile mehrere Signaturen auf einmal prüfen. Das folgende Script überprüft die Signaturen aller Scripte im Ordner C:\Scripts (es geht auch diesmal wieder davon aus, dass im Ordner nur Scripte gespeichert sind):

set objSigner = WScript.CreateObject("Scripting.Signer")
blnShowGUI = False

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder("C:\Scripts")
Set colListOfFiles = objFolder.Files
For each objFile in colListOfFiles
    blnIsSigned = objSigner.VerifyFile(objFile.Name, blnShowGUI)
    If blnIsSigned then
        WScript.Echo objFile.Name & " wurde signiert."
    Else
        WScript.Echo objFile.Name & " wurde nicht signiert."
    End If
Next

Zum Seitenanfang

Die Ausführung von Scripten einschränken

Standardmäßig wird ein Script mit einem Doppelklick auf eine .vbs-Datei sofort ausgeführt. Über die Registrierung können Sie dieses Verhalten jedoch ändern. Der Benutzer wird hierdurch jedoch nicht daran gehindert, dass Script auszuführen. Er kann zum Beispiel einfach die Option Öffnen mit im Kontextmenü auswählen und das Script dann über Wscript.exe oder Cscript.exe ausführen. Außerdem kann er über die folgenden Befehle das Script in der Kommandozeile starten:

wscript.exe DeleteFiles.vbs

cscript.exe DeleteFiles.vbs

Trotzdem gibt Ihnen die Methode ein wenig zusätzliche Sicherheit - die Benutzer haben immerhin die Möglichkeit, die Ausführung eines potentiell gefährlichen Scripts abzubrechen. Ohne diese Option würde das Script einfach ohne Warnung gestartet.

Die Registrierungsanpassung können Sie mit der folgenden Batchdatei vornehmen:

reg copy HKCR\VBSFile\Shell HKCR\VBSFile\bkupShell /s /f
reg delete HKCR\VBSFile\Shell /f
reg add HKCR\VBSfile\ /v NoOpen /t REG_SZ /d " Führen Sie dieses Script nicht aus, wenn 
es nicht von der IT-Abteilung freigegeben wurde."

Die Standardfunktionalität können Sie mit der folgenden Batchdatei wiederherstellen:

reg copy HKCR\VBSFile\bkupShell HKCR\VBSFile\Shell /s /f
reg delete HKCR\VBSFile\bkupShell /f
reg delete HKCR\VBSFile /v NoOpen /f

Die Batchdatei führt die folgenden Schritte durch:

1. Sie verwendet Reg.exe (zum Beispiel aus den Windows 2000 Support Tools), um den Registrierungspfad HKEY_CLASSES_ROOT\VBSFile\Shell nach HKEY_CLASSES_ROOT\VBSFile\bkupShell zu kopieren (der gesamte Pfad wird gesichert, damit die Originaleinstellungen bei Bedarf wiederhergestellt werden können).
2. Sei löscht HKEY_CLASSES_ROOT\VBSFile\Shell.
3. Sie erstellt einen neuen Eintrag (NoOpen) in HKEY_CLASSES_ROOT\VBSFile und konfiguriert die gewünschte Warnmeldung als Wert für diesen Eintrag - in dieser Beispiel-Batchdatei lautet diese Warnmeldung 'Führen Sie dieses Script nicht aus, wenn es nicht von der IT-Abteilung freigegeben wurde.' (die Länge der Warnmeldung ist auf 140 Zeichen begrenzt).

Eine Beschränkung für andere Scriptdateien (zum Beispiel .VBE, .JS, .JSE und .WSF) können Sie auf ähnliche Weise konfigurieren.

Deaktivieren des Windows Script Host

Wenn erforderlich, können Sie den Windows Script Host auch deaktivieren - so können Sie sicherstellen, dass keine Scripte mehr ausgeführt werden, die vom WSH abhängig sind (inklusive VBScript und JScript).

Um den Windows Script Host zu deaktivieren, erstellen Sie einen der beiden folgenden Registrierungseinträge (REG_DWORD) und setzen seinen Wert auf 0. Um den WSH für einen bestimmten Benutzer zu deaktivieren, verwenden Sie den folgenden Eintrag:

HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings\Enabled

Um den WSH für alle Benutzer des Computers zu deaktivieren, verwenden Sie diesen Eintrag:

HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings\Enabled

Wenn der WSH deaktiviert ist, sehen Sie die folgende Fehlermeldung, wenn Sie versuchen ein WSH-Script zu starten:

Der Zugriff auf Windows Script Host wurde auf diesem Computer deaktiviert. 
Für weitere Informationen wenden Sie sich an Ihren Administrator.

Die Meldung wird auch dann angezeigt, wenn der Benutzer versucht, ein Script über die Kommandozeile zu starten (zum Beispiel über den Befehl cscript.exe c:\scripts\myscript.vbs).

Zum Seitenanfang

| Home | Technische Artikel | Community