Leistungen
Leistungen
Überblick
Leistungsangebot
Kernkompetenzen
Schulungsthemen
In-House-Schulungen
Offene .NET-Seminare
Offene WPS-Seminare
Beratung
Coaching
Support
Softwareentwicklung
Entwickler-Vermittlung
.NET/Visual Studio
TFS/ALM/Scrum
Webprogrammierung
PowerShell
Konditionen
Anfrage/Kontakt
Beratung/Coaching
Beratung/Coaching
Beratungsthemen
Coaching
Unsere Berater
Referenzkunden
Konditionen
Angebotsanfrage
In-House-Schulungen
In-House-Schulungen
Überblick
Themen/Fachgebiete
Schulungskonfigurator
Konzepte
.NET/Visual Studio
C#
VB.NET
ASP.NET
Moderne Webanwendungen
TFS/ALM/Scrum
PowerShell
Konferenzvortraege
Referenzkunden
Unsere Trainer
Konditionen
Angebotsanfrage
Offene Schulungen
Offene Schulungen
Überblick .NET-Seminare
.NET/C#-Basisseminar
WPF (Desktop)
ASP.NET/AJAX (Web)
WCF/WF (SOA)
ADO.NET/EF (Data)
Windows PowerShell
.NET, C#, VB, Visual Studio
.NET, C#, VB, Visual Studio
Startseite
Beratung/Training
Offene .NET-Seminare
Einführung
Lexikon
Artikel
Bücher
Klassenreferenz
Programmiersprachen
Entwicklerwerkzeuge
Softwarekomponenten
World Wide Wings Demo
Codebeispiele
Scripting
ASP.NET
.NET 2.0
.NET 3.0/3.5
.NET 4.0/4.5
Community
Forum
Kommerzielle Leistungen
ASP.NET
ASP.NET
Startseite
Lexikon
Sicherheit
Konfiguration
Global.asax
Tracing
Technische Beiträge
Klassenreferenz
Programmiersprachen
Entwicklerwerkzeuge
Softwarekomponenten
PowerShell
PowerShell
Überblick
Beratung
In-House-Schulungen
Öffentliche Schulungen
Codebeispiele
Commandlet Extensions
Offene PowerShell-Seminare
Inhouse-Seminare
Windows
Windows
Startseite
Windows Runtime (WinRT)
Windows PowerShell
Windows Scripting
Windows-Schulungen
Windows-Lexikon
Windows-Forum
Windows Scripting
Windows Scripting
Startseite
Lexikon
FAQ
Buecher
Architektur
Skriptsprachen
Scripting-Hosts
Scripting-Komponenten
COM/DCOM/COM+
ADSI
WMI
Scripting-Tools
WSH-Editoren
Codebeispiele
ASP.NET
.NET-Scripting
Forum
Links
Kommerzielle Leistungen
Service
Service
Website-FAQ
Anmeldung/Login
Leser-Registrierung
Gast-Registrierung
Nachrichten/RSS
Newsletter
Foren
Weblog
Lexikon
Downloads
Support
Kontakt
Site Map
Suche
Literaturtipps
Publikationen
Publikationen
Redaktionsbüro
Bücher
Fachartikel
Leser-Portal
Autoren gesucht!
Rezensionen
Über uns
Über uns
Holger Schwichtenberg
Team
Referenzkunden
Kundenaussagen
Referenzprojekte
Partner
Site Map
Suche
Weitere Websites
Tag Cloud
Impressum
Rechtliches
Datenschutzerklärung

Windows Scripting FAQ

Fragen

  • Was ist der Windows Script Host (WSH)?

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

  • Wird der WSH weiterentwickelt werden?

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

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

  • Welche Version des WSH ist die aktuellste Version?

  • Welche WSH-Version ist in welchem Betriebssystem enthalten?

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

  • Was unterscheiden den WSH 2.0 vom WSH 1.0?

  • Was unterscheiden den WSH 5.6 vom WSH 2.0?

  • Was unterscheidet wscript.exe und csript.exe?

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

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

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

  • Was ist eine .wsf-Datei?

  • Wie wird die Programmiersprache bei einem WSH-Skript festgelegt?

  • Wie kann man ein WSH-Skript starten?

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

  • Wie kann ich den WSH deaktivieren?

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

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

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

  • Was ist neu im WSH 5.7 in Windows Vista?
  • Antworten

    Was ist der Windows Script Host (WSH)?

    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 - mit Ausnahme von Fehlerkorrekturen. Nachfolger ist die Windows PowerShell.


    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.