Der Windows Script Host (WSH) ist der Scripting_Host.aspx'>Scripting Host, der direkt auf dem Betriebssystem ausgeführt wird. Außer dem Scripting_Host.aspx'>Scripting Host (zwei EXE-Dateien) und den zugehörigen DLLs ist keine weitere (BackOffice-)Anwendung notwendig. Der WSH ist daher der unkomplizierteste Scripting_Host.aspx'>Scripting Host. Andererseits ist er der komplexeste, weil er viele Features (z.B. XML-Strukturierung, COM-Eventhandling) bietet, die in anderen Scripting_Host.aspx'>Scripting Hosts (noch) nicht verfügbar sind.

Mache reden von Windows Scripting Host, andere von Windows Script Host. Was ist der Unterschied?

Zwischen Version 1.0 und Version 2.0 hat Microsoft eine kleine, aber entscheidende Namensänderung von Scripting_Host.aspx'>Scripting.aspx'>Windows Scripting Host zu Windows Script Host vollzogen, die wohl der Abgrenzung zwischen dem allgemeinen Begriff Scripting_Host.aspx'>Scripting Host und dem WSH dienen soll.

Wird der WSH weiterentwickelt werden?

Nein, es wird keine bedeutenden neuen Version des WSH mehr geben. Der WSH wird ab Windows Longhorn durch die Microsoft Shell (MSH) abgelöst werden. Die MSH ist eine Shell im Unix-Stil.

Ich kenne den WSH 1.0, 2.0 und 5.6. Was ist mit den anderen Versionen?

Das Microsoft Einmaleins geht so: 1.0, 2.0, 5.6. Aber es gibt eine Erklärung: Schon der WSH 1.0 verstand sich intern als Version 5.0. Der WSH 2.0 antwortete auf eine Anfrage nach seiner Versionsnummer mit "WSH 5.5". Jetzt hat Microsoft dieses Kuriosum aufgelöst: Das Produkt hat intern und extern die gleiche Versionsnummer.

Ich habe in einem Microsoft-Vortrag den Begriff "Wish" gehört. Was ist "Wish"?

Im Englischen werden Abkürzungen gerne mit Vokalen aufgefüllt, um sie sprechbar aussprechen zu machenkönnen. Insider nennen den WSH daher "Wish".

Welche Version des WSH ist die aktuellste Version?

Die aktuellste Version ist 5.6. WSH 5.6 ist in Windows XP und Windows Server 2003 enthalten und als Add-on für ältere Windows-Versionen verfügbar.

Welche WSH-Version ist in welchem Betriebssystem enthalten?

Windows 95:
WSH nicht enthalten; WSH 1.0, 2.0 oder 5.6 können nachträglich installiert werden

Windows 98:
WSH 1.0, Update auf 2.0 oder 5.6 möglich

Windows ME:
enthält WSH 2.0, Update auf 5.6 möglich

Windows NT 4.0:
WSH nicht enthalten; WSH 1.0, 2.0 oder 5.6 können nachträglich installiert werden

Windows 2000:
enthält WSH 2.0, Update auf 5.6 möglich

Windows XP:
enthält WSH 5.6

Windows Server 2003:
enthält WSH 5.6

Windows Vista:
enthält WSH 5.7

Windows Server 2008:
enthält WSH 5.7

Wie kann ich ermitteln, welche Version des WSH installiert ist?

Die WSH-Version kann mit einem Einzeiler getestet werden. Das Attribut Version aus dem Intrinsic Object WScript enthält die Versionsnummer. Das Codebeispiel ist in VBS geschrieben.

Erstellen Sie eine Textdatei mit der Extension .VBS und hinterlegen Sie dort den nachfolgenden Code. Starten Sie das Skript dann per Doppelklick.

' WSH-Test-Skript (VBS)
WScript.Echo "Dies ist der " & WScript.Name & _
" Version " & WScript.Version

Was unterscheiden den WSH 2.0 vom WSH 1.0?

Gegenüber dem WSH 1.0 sind imbietet der WSH 2.0 folgende neue Möglichkeiten bzw. verbessertVerbesserungen:

- XML-Strukturierung der Dateien
- Mehrere Skripte pro Datei
- Mehrere Sprachen pro Skript
- Einbindung anderer Skriptdateien
- Einbindung von Typbibliotheken
- Drag&Drop-Unterstützung

In dem Intrinsic Object WScript wurde Folgendes verbessert:
- Warteschleife mit Sleep()
- Zugriff auf Standard-I/O-Kanäle (StdIn, StdOut, StdErr)

Was unterscheiden den WSH 5.6 vom WSH 2.0?

Die zentralen Neuerungen im WSH 5.6 sind:
- Digitale Signierung von Skripten
- Entfernte Ausführung von Skripten
- Selbstbeschreibende Parameter für XML-strukturierte WSH-Dateien

Was unterscheidet wscript.exe und csript.exe?

Der WSH ist genau genommen nicht nur ein Scripting_Host.aspx'>Scripting Host, sondern umfasst zwei eng verwandte Scripting_Host.aspx'>Scripting Hosts: WScript und CScript. Beide Scripting_Host.aspx'>Scripting Hosts sind hinsichtlich ihres Befehlsumfangs fast gleich. Sie unterscheiden sich lediglich darin, wohin die Ausgaben gehen. Außerdem sind die Intrinsic Objects von CScript ein klein wenig mächtiger als die von WScript.

WScript.exe

Bei WScript (implementiert in WSCRIPT.EXE) erfolgt die Ausführung als Windows-Anwendung. Alle Ausgaben werden in Form von Dialogboxen dargestellt. Wenn das Skript viele Ausgaben macht, kann dies sehr lästig sein, da jede Dialogbox einzeln bestätigt werden muss. Zudem ist jede Dialogbox modal: Das Skript hält an und wartet auf die Bestätigung. WScript eignet sich also für die unbeaufsichtigte Ausführung nur dann, wenn das Skript keine Ausgaben macht. Gut geeignet ist WScript jedoch dann, wenn der Benutzer über jeden einzelnen Schritt informiert werden und dabei die jeweils erfolgten Veränderungen überprüfen möchte (also beispielsweise beim Debugging von Skripten).
Standard
WScript ist der Standard: Bei der Installation des WSH werden die WSH-Dateiextensionen mit WScript verknüpft. Diese Verknüpfungen können in der Registry, in den Optionen des Windows Explorers oder mit der WSH-Kommandozeilenoption //H: geändert werden.

CScript.exe

Bei CScript (implementiert in CSCRIPT.EXE) erfolgt die Ausführung des Skripts im Kontext einer Kommandozeile (auch: Konsole oder DOS-Box). Die Form der Ausgabe hängt von den verwendeten Ausgabebefehlen ab: Alle Ausgaben über die Methode Echo() aus dem WSH-Intrinsic Object WScript erfolgen in die DOS-Box. Alle Ausgaben über die spracheigenen Ausgabemethoden (z.B. MsgBox() in VBScript) werden weiterhin als modale Dialogboxen dargestellt. Ein Vorteil von CScript ist, dass es mit der Methode WScript.StdIn.ReadLine() das Einlesen von Eingaben des Benutzers im DOS-Fenster unterstützt. Ausgaben können mit dem DOS-Befehl für Umleitungen (>) in eine Textdatei oder an einen Drucker umgeleitet werden.

CScript hat außerdem den Vorteil, dass die Skriptausführung mit (STRG)+(C) jederzeit vom Benutzer abgebrochen werden kann. Bei WScript hilft – wenn modale Dialogboxen angezeigt werden – nur das Beenden der Anwendung mit dem Windows Task-Manager.

Wie kann die den "Vorspan" bei cscript.exe aussschalten?

Normalerweise gibt CScript beim Skriptstart immer den Vorspann aus, der über den WSH informiert:
Microsoft (R) Windows Script Host, Version 5.1 für Windows
Copyright (C) Microsoft Corporation 1996-1999. Alle Rechte vorbehalten.

Sie können diesen Vorspann mit der Kommandozeilenoption //Nologo ausschalten. Die Grundeinstellung für die Anzeige des »Logos« lässt sich in der Registry ändern: HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS SCRIPT HOST\SETTINGS\DISPLAYLOGO. »1« bedeutet, das Logo wird angezeigt, »0« unterbindet die Anzeige.

Wie erreiche ich, dass alle WSH-Skripte mit cscript.exe als DOS-Skripte ausgeführt werden?

Um CScript zum Standard für die Ausführung der Skripte zu machen, geben Sie nachfolgendes Kommando in der DOS-Box ein:

C:\>cscript //H:cscript

Darauf antwortet der WSH mit:
"CScript.exe" ist jetzt Script Host-Standard.
Logo

Ich starte ein Skript in der DOS-Box. Dennoch werden meine Ausgaben in Dialogfenster angezeigt. Was mache ich falsch?

Diesem Irrtum unterliegen viele: Ein Skript wird nicht automatisch deshalb mit CScript gestartet, weil Sie es an der Kommandozeile starten. CScript muss entweder voreingestellt sein oder aber der Aufruf muss
CScript.exe <Skriptname>
lauten, sonst wird die Windows-Version (wscript.exe) gestartet.

Was ist eine .wsf-Datei?

Im WSH 2.0 sind die allgemeinen WSH-Skriptdateien mit der Extension .WSF hinzugekommen (in der Beta-Version des WSH 2.0 trugen sie noch die aus zwei Buchstaben bestehende Extension .WS).

WSF-Dateien können mehrere Skripte in verschiedenen Sprachen enthalten und werden durch die Extensible Markup Language (XML) auf der Grundlage eines Satzes vordefinierter Elemente strukturiert. Eine WSF-Datei enthält genau ein Package. Jedes Package besteht aus einem oder mehreren Jobs. Jeder Job umfasst einen oder mehrere Skriptblöcke.

Das nachfolgende Listing zeigt die Grundstruktur einer WSF-Datei.
<?xml version="1.0"?>
<package id="WSFGrundStruktur">
   <job id="Job_1">
   <script language="VBScript">
   </script>
   </job>
   <job id="Job_2">

   <script language="VBScript">
   </script>
   </job>
</package>

Regeln

Während die XML-Processing Instruction in der ersten Zeile und die Definition eines Packages optional sind, ist der Aufbau aus mindestens einem Job- und einem Skriptblock zwingend. Im letzteren Fall ist dann <job> das Root-Element. Ein Job kann beliebig viele Skriptblöcke enthalten, die in unterschiedlichen ActiveX_Scripting.aspx'>ActiveX Scripting Engines implementiert wurden. Gemäß den XML-Konventionen muss jedes geöffnete Element auch wieder geschlossen werden. Eine Ausnahme bildet nur die XML-Processing Instruction.

Alle Elementnamen müssen klein geschrieben werden. Eine Ausnahme ist die Processing Instruction, die wahlweise in Groß- oder Kleinbuchstaben geschrieben werden kann. Wenn andere Elemente nicht komplett klein geschrieben werden, dann werden diese Elemente einfach ignoriert. So kommt der Ausgabebefehl in dem folgenden Skript nicht zur Ausführung, weil <Script> mit großem Anfangsbuchstaben geschrieben wurde. Der WSH liefert aber keine Fehlermeldung, weil die Bedingung erfüllt ist, dass Start- und Ende-Tag zueinander passen.

<?XML version="1.0"?>
<package id="falsche_Schreibweise">
   <job id="Job_1">
   <Script language="VBScript">
   msgbox "OK"
   </Script>
   </job>
</package>

Durch das Weglassen der Processing Instruction <?xml version="1.0"?> wird der WSH in einen Modus versetzt, der weniger strenge Anforderungen an die Wohlgeformtheit von XML stellt. So würde nachfolgende WSF-Datei akzeptiert, obwohl die Groß-/Kleinschreibung nicht stimmt und die Anführungszeichen bei der Attribut-Wert-Zuweisung fehlen.

<job ID="test">
<SCRIPT language=vbscript>
msgbox "OK"
</script>
</JOB>

Mehrere Jobs

Sofern von der Möglichkeit Gebrauch gemacht wird, durch die Definition eines Packages mehrere Jobs in einer WSF-Datei zu vereinen, kann der Skriptbenutzer über die Kommandozeilenoption //job:jobname den auszuführenden Job auswählen. Fehlt die Angabe, wird der erste in der WSF-Datei enthaltene Job gestartet.

Wie wird die Programmiersprache bei einem WSH-Skript festgelegt?

Im WSH 1.0 konnte eine Skriptdatei nur genau ein Skript in einer Skriptsprache beinhalten. Die Skriptsprache wurde durch die Dateiextension festgelegt, z.B.:
.VBS für Visual Basic Script
.JS für JScript
.PLS für PerlScript.aspx'>PerlScript (sofern PerlScript.aspx'>PerlScript installiert ist)

Sprachidentifizierung per Kommandozeilenoption

Wenn eine Datei eine andere Extension hat, können Sie sie dennoch mit einem bestimmten Sprachinterpreter starten. Dazu müssen Sie die Skriptdatei explizit mit einer der beiden Umgebungen (WSCRIPT.EXE oder CSCRIPT.EXE) starten und hinter der Kommandozeile //E die ProgID der gewünschten ActiveX_Scripting.aspx'>ActiveX Scripting Engine angeben.
WScript.exe "ich-bin-eine-Skriptdatei.txt" //E:VBScript
Sie finden dazu ein Beispiel auf der Buch-CD [CD:/code/hosts/WSH/Skriptdatei mit anderer Extension/], in dem eine Datei mit der Extension .TXT als VBS-Skript gestartet wird.

Diese beiden Formen der Sprachidentifizierung werden in WSH 2.0 und WSH 5.6 auch weiterhin unterstützt. In .wsf-Dateien wird die Sprache pro Skriptblock durch ein XML-Attribut festgelegt.

Wie kann man ein WSH-Skript starten?

Skripte können wie eine normale Anwendung gestartet werden, also:
- an der Kommandozeile
- durch Doppelklick auf die Skriptdatei bzw. auf ÖFFNEN im Kontextmenü
- durch Drag&Drop beliebiger Dateien auf das Icon einer Skriptdatei (seit WSH 2.0)
- über das Kontextmenü einer jeden Datei im Windows Explorer oder auf dem Desktop
- automatisiert durch den Taskscheduler.

Kann ein Skript prüfen, ob es mit Wscript oder mit Cscript gestartet wurde?

Welche Variante des WSH das Skript ausführt, ist eine wichtige Frage, da einige Features (insbesondere der Zugriff auf die Standardein- und –ausgabe) nur in CScript zur Verfügung stehen. Leider gibt es kein Attribut, das direkt zwischen den beiden Varianten unterscheidet. Das Attribut FullName enthält aber den kompletten Pfad zum aktuellen Host. Durch Extraktion der letzten elf Zeichen der Zeichenkette kann geprüft werden, ob CSCRIPT.EXE oder WSCRIPT.EXE ausgeführt wird.

if UCASE(right(wscript.fullname,11)) = "CSCRIPT.EXE" then
   variante = "CScript"
else
   variante = "WScript"
end if

if variante = "CScript" then
   Msgbox "Dieses Skript läuft mit der
   Kommandozeilenversion des WSH!"
else
   Msgbox "Dieses Skript läuft mit der Windows-Version des WSH!"
end if

Wie kann ich den WSH deaktivieren?

Den Zugriff auf den WSH insgesamt können Sie reglementieren, indem Sie die NTFS-Rechte auf die Dateien WSCRIPT.EXE und CSCRIPT.EXE beschränken. In diesem Fall müssen Sie die Startberechtigung über das Recht »Datei ausführen« steuern.
Wenn Sie WSH-Skripte für alle Benutzer (auch lokale Administratoren) verbieten wollen, können Sie diese beiden Dateien auch einfach löschen.

Eine noch bessere Möglichkeit zur Deaktivierung des WSH ist der Registry-Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS SCRIPT HOST\SETTINGS\ENABLED. Mit der Zuweisung des Werts 0 ist der Start des WSH nicht mehr möglich – auch nicht, wenn der Benutzer sich WSCRIPT.EXE oder CSCRIPT.EXE an einem anderen Ort auf sein System gelegt hat, um die Sicherheitseinstellungen zu umgehen.

Wie kann die Ausführung auf bestimmte WSH-Skripte beschränken?

Microsoft hat die Sicherheitseinstellungen des Internet Explorers als Muster für ein neues Sicherheitsfeature in Windows XP und Windows .NET Server verwendet. Der Internet Explorer erlaubt die Beschränkung von Programmcode (Skripte, ActiveX-Steuerelemente, Java) auf Basis der Herkunft des Programmcodes (Internet, Intranet, lokale Festplatte etc.).
Mit Windows XP wurde dann auch für Programmcode außerhalb des Internet Explorers eine Sicherheitskontrolle eingeführt: Mit Software Restriktion Policies (SRP) kann Programmcode auf Basis seiner Herkunft gesperrt werden. Per Lokaler Richtlinie oder Gruppenrichtlinie kann man Sicherheitsbeschränkungen für Programmcode einführen. Der Begriff WinSafer ist ein Alias für SRP.
Das Sicherheitssystem der SRP besteht aus genau einer Grundeinstellung und einer beliebigen Anzahl von Regeln.

Grundeinstellung

In der Grundeinstellung lässt sich zunächst festlegen, ob grundsätzlich jeder Programmcode erlaubt werden soll oder verboten sein soll. Als Programmcode gelten alle Arten von ausführbaren Dateien, einschließlich Skripte. Die Grundeinstellung ist, dass die Ausführung erlaubt ist.

Die Grundeinstellung kann durch weitere Eigenschaften angepasst werden:
- Es kann festgelegt werden, ob die SRP auch für DLLs gelten soll.
- Es kann festgelegt werden, welche Dateitypen ausführbare Dateien enthalten.
- Es kann festgelegt werden, ob die SRP für Administratoren nicht gelten sollen.

Regeln

Alle verbieten/einiges erlauben
Mit der Grundeinstellung "Disallowed" wäre es unmöglich, Windows zu benutzen, weil man keine Programme starten kann. Daher ist es notwendig, dass man Regeln definieren kann, für welche Software die Beschränkung nicht gelten soll.

Kriterien für die Beschränkung sind:
- Hash-Wert einer ausführbaren Datei
- In der ausführbaren Datei enthaltenes Zertifikat gemäß dem Microsoft Authenticode-Verfahren (vgl. Kapitel "Fortgeschrittene Techniken/Digitale Signatur für Skripte")
- Internet Explorer-Zone
- Dateisystempfad
- Dateiextension

In Windows Server 2003 sind vier Regeln vordefiniert, die die wichtigsten Pfade (Windows, System32, Programme) zum Start von Programmen zulassen. Man kann beliebig viele weitere Regeln hinterlegen.

Eine Regel kann auch den Start von Software aus einer bestimmten Quelle verbieten. Dies macht sind, wenn die Grundeinstellung "Alles erlauben" ist. Diese Variante hat den Vorteil, dass man weniger Regeln hinterlegen muss. Es besteht aber die Gefahr, dass man Quellen übersieht. Beispielsweise kann ein Benutzer eine SRP, die den Start von Anwendungen von Laufwerk D: verbietet, dadurch umgehen, dass er einen anderen Laufwerksbuchstaben der Platte zuordnet, sich mit dem DOS-Befehl subst einen Alias für das Laufwerk anlegt oder eine Laufwerksverknüpfung zu einer lokalen Freigabe auf seinem eigenen Rechner anlegt.

Man kann bei der SRP nur zwischen "nicht erlaubt" und "nicht eingeschränkt" wählen, d.h., die Anwendung startet oder startet nicht. Es ist nicht möglich, einer Anwendung Zugriffsrechte auf einzelne Ressourcen zu geben oder zu entziehen.

Hash-Regeln

Mit einer Hash-Regel kann man einzelne Anwendungen/Skripte erlauben oder verbieten, unabhängig davon, wo sie liegen. Beim Anlegen einer Hash-Regel muss man eine Datei auswählen. Über diese Datei wird ein Hash-Wert gebildet. Der Algorithmus für den Hash-Wert ist so, dass jede kleinste Änderung an der Datei zu einem anderen Hash-Wert führt. Windows startet die Anwendung nur, wenn der Hash-Wert stimmt.

Wenn man zahlreiche Anwendungen und Skripte im Unternehmen verwendet, ist es lästig, für jede dieser ausführbaren Dateien eine Hash-Regel anzulegen. Außerdem muss man bedenken, dass die Hash-Regel nach jeder Änderung an einem Skript erneuert werden muss. Es gibt noch keine Möglichkeit, das Anlegen von SRP-Regeln zu scripten. Eine Lösung für diese Herausforderung sind Zertifikats-Regeln.
Zertifikats-Regeln

Gruppen von Anwendungen

Das Microsoft Authenticode-Verfahren ermöglicht es, ausführbare Dateien digital zu signieren. Mit einer Zertifikats-Regel kann man definieren, dass mit einem bestimmten digitalen Zertifikat signierte Anwendungen/Skripte ausgeführt werden dürfen. Damit entfällt die Definition für jede einzelne Datei.

Wie kann ich den Quellcode von Skripten vor unbefugten Einblicken schützen?

Ein Kennwort im Klartext irgendwo abzulegen, ist grundsätzlich ein Sicherheitsrisiko – nicht nur für Administrator-Konten. Sofern das Skript nicht unbeaufsichtigt laufen muss, sollten Sie daher während der Skriptausführung nach dem Kennwort fragen (z.B. mit InputBox() oder der Scripting Password-Komponente).

Ungeeignet ist die Kennworteingabe natürlich dann, wenn das Skript entweder unbeaufsichtigt laufen soll oder aber im Kontext eines normalen Benutzers gestartet werden soll, dann aber eine Impersonifizierung als Administrator notwendig wird. Dann ist es natürlich keine Alternative, den Benutzer das Kennwort des Administrators eingeben zu lassen.

Script Encoding

Leider kann man auch bei WSH-Dateien nicht zwischen den Rechten "Ausführung" und "Lesen" unterscheiden. Das Starten einer WSH-Datei erfordert immer Leserechte auf eine Datei und damit ist auch immer die Einsicht in den Quellcode möglich. Eine Möglichkeit – zumindest gegen weniger erfahrene Benutzer – ist dann nur das Script Encoding. Dabei wird der gesamte Quellcode einer Datei unkenntlich gemacht. Leider ist das Verfahren mit im Internet kursierenden Tools reversibel.

ASP

Eine wirklich wirksame Sicherung vor dem Betrachten des Quellcodes bietet der WSH überhaupt nicht. Eine grundsätzliche Alternative sind ASP-Skripte: Sie laufen auf einem Webserver und der Benutzer kann den Quellcode nicht betrachten, sofern er keinen Zugriff auf das Dateisystem des Webservers hat. In der Vergangenheit gab es zwar einige Bugs im IIS, die die Anzeige des Quellcodes ermöglicht haben, doch diese Lücken sollten nach der Sicherheitsinitiative von Microsoft inzwischen gestopft sein.

Wie kann ich festlegen, unter welcher Benutzeridentität ein Skript ausgeführt wird?

Ein WSH-Skript, das von einem Benutzer manuell gestartet oder im Rahmen des Login/Loff-Vorgangs wird, läuft automatisch unter dessen Benutzerkontext. Der WSH selbst unterstützt nicht die Impersonifizierung, d.h. den Ablauf unter einem anderen Benutzerkontext als dem des Aufrufers.

Windows bietet jedoch verschiedene Möglichkeiten, eine ausführbare Datei unter einem anderen Benutzerkontext als unter dem des gerade angemeldeten Benutzers laufen zu lassen.

Diese Möglichkeiten hat auch ein WSH-Skript:
1. Das Skript läuft als geplanter Vorgang im Taskscheduler, dem ein dezidiertes Benutzerkonto zugewiesen wurde (nur unter NT4/Windows 2000).
2. Sie können in Windows ab Windows 2000 integrierte Werkzeuge runas.exe bzw. das Tool su.exe aus den Resource Kits zu NT 4.0 nutzen, um WSCRIPT.EXE bzw. CSCRIPT.EXE unter einem anderen Benutzerkontext auszuführen.
3. Ab Windows 2000 können Sie einen Benutzerkontext auch in einer Dateisystemvernüpfung festlegen und so eine Vernüpfung zu einem Skript definieren.

In all diesen Fällen erfolgt die Festlegung des Benutzerkontextes statisch, d.h. einheitlich für das gesamte WSH-Skript. Ein WSH-Skript ist – genauso wie andere Scripting_Host.aspx'>Scripting Hosts – nicht in der Lage, während seines Programmablaufs den Benutzerkontext zu wechseln.

Einige Komponenten, z.B. das Active Directory Service Interface, die Windows Management Instrumentation und die ISPSignup-Komponente, unterstützen die Impersonifizierung für die Operationen auf diesen Komponenten. Diese Impersonifizierung gilt dann aber nur für alle Methodenaufrufe in diesen Komponenten. Alle anderen Operationen laufen weiterhin unter dem Benutzerkontext, unter dem das Skript gestartet wurde.

Was ist neu im WSH 5.7 in Windows Vista?

Der Windows Script Host (WSH) trägt in Vista die Versionsnummer 5.7 (gegenüber 5.6 in Windows XP und Windows Server 2003). Neue Funktionen sind aber nicht dokumentiert und laut einer Auskunft des Windows-Entwicklungsteams in Redmond auch nicht enthalten. Es hat lediglich eine interne Anpassung an Veränderungen in Vista stattgefunden. Die Skriptsprachen VBScript und JScript haben in Vista analog die Versionsnummern 5.7 erhalten. Neuerungen sind hier aber ebenfalls nicht enthalten.