Disclaimer: Dies ist eine (ziemlich stümperhafte) Kopie von https://www.msxfaq.de/code/vbscript.htm, die hier aus Gründen von "Das Internet vergisst nicht" mit freundlicher Genehmigung des Autors gespiegelt wurde.

VBScript und Exchange

Für die Nutzung von Outlook aus VBScript finde Sie auf Outlook VBScript weitergehende Informationen.

Ein Häufiger Fehler beim Programmieren ist Unachtsamkeit bei der Verwendung von Variablen. Siehe Auch VBScript Falle "ByVAL/ByRef"

Windows Script 5.7 for Windows XP
http://www.microsoft.com/downloads/details.aspx?FamilyID=47809025-D896-482E-A0D6-524E7E844D81&displaylang=en
Windows Script 5.7 for Windows 2000
http://www.microsoft.com/downloads/details.aspx?familyid=C03D3E49-B40E-4CA1-A0C7-CC135EC4D2BE&displaylang=en

VBScript wurde von vielen Administratoren noch gar nicht richtig entdeckt, da wird es schon wieder das Ende beschworen. Fakt ist aber, dass VBScript auf allen Windows Betriebssystemen ab NT4 verfügbar ist und zusammen mit vorhandenen COM-Objekten auch sehr leistungsfähige Skripte (nicht Programme) erlaubt. Jeder Administrator, der noch mit BATCH-Dateien herum wirbelt, erkennt schnell dass viele Funktionen nur über den Aufruf externer Programme (SORT, FIND, WMIC, IPCONFIG etc.) oder gar nicht möglich sind.  Der Weg zu einem "richtigen" kompilierten Programm aber doch zu weit ist. Daher ist eine leistungsfähige Skriptsprache für eine effektive Administration erforderlich.

Programmieren mit VBScript

VBScript wurde etwa zur Zeit von Windows NT4 und WMI eingeführt um Windows auch per Script administrierbar zu machen. Damals konnten Administratoren eigentlich nur mit Batches und Programmen aus dem Windows NT Ressource Kit ein paar Dinge automatisieren. Auch wenn VBScript seit ca. 2003 nicht mehr aktiv weiter entwickelt wird, (Der Windows Scripting Host 5.6 ist die letzte Version) und es keine Entwicklungsumgebung von Microsoft gibt, so ist VBScript weiterhin das Werkzeug für Administratoren. VBScript selbst kann sehr wenig, aber durch die Einbindung von COM-Objekten ist fast alles möglich.

Aber Programmieren mit VBScript ist wirklich "Programmieren". Wenn Sie nicht einige Grundregeln des Programmierens kennen, dann wird aus einem VBScript sehr schnell unlesbarer Spaghetti-Code. Daher möchte ich ihnen nahe legen, nicht nur Skriptschnipsel aus dem Internet oder Tools wie ADSI-Scriptomatic, WMI-Scriptomatic oder Tweakomatic aneinander zu kleben, sondern zumindest Grundbegriffe der objektorientierten Programmierung sich anzueignen. Hier ein paar Regeln:

Ich will Sie aber nicht davon abhalten, ihre ersten Schritte in VBScript oder einer anderen Programmiersprache (z.B. .NET) zu unternehmen. Nur sollten Sie rechtzeitig eben auch das Handwerkszeug dazu erlernen, damit Sie nicht sprichwörtlich absaufen.

VBScript und Sicherheit

Natürlich haftet VBScript der Ruf an, dass es "unsicher" wäre. Das ist vor allem ein Ergebnis vieler Viren der Vergangenheit. Gerade bösartige Personen hatten die Mächtigkeit von VBScript erkannt um damit viel Schindluder zu treiben. Das ist nach meiner Ansicht aber nicht als Problem von VBScript als solches anzulasten. Genauso gut könnte ein Schadprogramme als BAT, CMD, Perl, PHP-Datei verteilt und aktiv werden. Natürlich ist diesen Viren entgegen gekommen, dass VBScript per "default" installiert ist, aber eine SHELL auf Unix ist ebenso verfügbar wie die DOS-Box unter Windows. Solange ein Anwender einfach "ausführbaren" Code auch ohne Zögern startet, ist das Problem vorhanden. Aber es betrifft alle Sprachen.

Als Administrator können Sie dem etwas Einhalt gebieten, indem die natürlich gleich den kompletten Windows Scripting Host entfernen. Aber damit nehmen Sie sich auch selbst jede Möglichkeit mit Skripten erforderliche Lösungen zu schaffen.

Sie könnten alternativ die Verbindung von "VBS" zum Scripting Host lösen und z.B.: auf Notepad verbinden. und damit zumindest den "Doppelklick" verhindern. Ein Aufruf mit WSCRIPT.EXE oder CSCRIPT.EXE ist dann immer noch möglich.

Der sichere Weg ist aber einfach über eine Gruppenrichtlinie vorzuschreiben, dass nur noch digital signierte Skripte ausgeführt werden dürfen. Mit einer eigenen Zertifizierungsstelle ist des nicht sonderlich schwer, dies zu regeln. Folgende KB-Artikel beschreiben zwar die Signierung von VBA aber das ist nicht weit weg von VBS.

Für mich ist also nicht VBScript ein Sicherheitsproblem, sondern der Mensch und Administrator davor. Als Administrator einer mittleren und größeren Umgebung benötige ich aber die Möglichkeiten einer leistungsfähigen Skriptumgebung. Und dafür ist VBScript wie geschaffen.

VBScript editieren

Der Spruch des "Visual Notepad" wird häufig für VBScript genannt. Notepad ist in der Tat ein oft benutzter Editor, um schnell ein mal ein paar Skripte zu erstellen. Aber ziemlich schnell kommen Sie an die Grenze, wo ein Editor mit Sprachunterstützung ein flüssigeres Arbeiten erlaubt.

Hier eine Auswahl an Programmen, mit denen Sie VBS-Dateien mit etwas mehr Komfort erstellen können. Meine beiden Favoriten sind

Wenn Sie professionell mit Unterstützung entwickeln, dann lohnt sich die Investition in kommerzielle Produkte wie:

Weitere Editoren sind:

Mein persönlicher Favorit ist der SystemScripter von Dr. Tobias Weltner (www.scriptinternals.com), da er die meisten Objekte auf meinem PC erkennt und mir bei der Eingabe schon vorschlägt. Die meisten kostenfreien Werkzeuge beschränken sich auf die farbliche Hervorhebung von Schlüsselworten etc. aber wissen doch nicht, dass es sich um VBScript handelt. Von diesen ist mir SC1 am sympathischsten, da der Editor eine einzige 350 kByte Datei ist und ohne Installation gestartet werden kann.

VBScript debuggen

Wer programmiert weiß, dass Fehler nicht zu vermeiden sind. Oft ist die Suche nach dem Fehler gar nicht so einfach und es geht tief in das Debugging hinein. Einfache Fehler im Skript erkennt der Windows Scripting Host schon beim Aufruf. Das Skript startet erst gar nicht. Einige Fehler werden erst zur Laufzeit erkannt wie z.B. der Zugriff auf ein Property eines Objekt, dass nicht vorhanden ist. Hier bricht das Script in der Regel an. Aber Microsoft hilft hierbei mit mehreren Programmen:

Einmal ist es mir passiert, dass trotz Installation des Microsoft Skript Debuggers dieser nicht gestartet wurde. Selbst ein Aufruf mit "cscript.exe //D //X scriptname.vbs" erbrachte keine Lösung. Letztlich lag es an einem Eintrag in der Registrierung, welcher nicht auf den Scriptdebugger gesetzt war:

REGEDIT4

[HKEY_CLASSES_ROOT\CLSID\{834128A2-51F4-11D0-8F20-00805F2CD064}]
@="ScriptDebugSvc Class"
"AppID"="{A87F84D0-7A74-11D0-B216-080000185165}"

[HKEY_CLASSES_ROOT\CLSID\{834128A2-51F4-11D0-8F20-00805F2CD064}\LocalServer32]
@="c:\\Program Files\\Microsoft Script Debugger\\msscrdbg.exe"

[HKEY_CLASSES_ROOT\CLSID\{834128A2-51F4-11D0-8F20-00805F2CD064}\ProgID]
@="ScriptDebugSvc.ScriptDebugSvc.1"

[HKEY_CLASSES_ROOT\CLSID\{834128A2-51F4-11D0-8F20-00805F2CD064}\VersionIndependentProgID]
@="ScriptDebugSvc.ScriptDebugSvc"

Warum auch immer hat das Setup des Skript Debuggers diesen Eintrag nicht vorgenommen. Die Fehler müssen Sie aber immer noch selbst suchen. Hierzu kann ihnen auch folgendes helfen:

VBScript Errorbehandlung

Wer Code schreibt, macht Fehler und einige Entwickler schätzen den Aufwand für Code zum Abfangen von Fehlern auf 30-40% des gesamten Codes. Auch bei VBScript gilt, dass ein Laufzeitfehler das Script ohne weitere Aktion beendet, es sei denn Sie arbeiten mit "ON ERROR RESUME NEXT". Sobald diese Zeile eingesetzt wird, sollten Sie aber im Script selbst prüfen, ob vielleicht ein Error aufgetreten ist, da sonst auch ein Schaden auftreten kann. Mit "ON ERROR GOTO 0" können Sie das Ignorieren von Fehlern wieder abschalten. Einen eigenen "Errorhandler" wie in Visual Basic mit "ON ERROR GOTO Funktionsname" ist leider nicht möglich.

Allerdings müssen sie auch noch beachten, dass "ON ERROR RESUME NEXT" bei der Nutzung von Unterfunktionen und Prozeduren einen Scope hat. Das folgende Beispiel soll das beleuchten.

Wenn Sie dieses Script starten, dann erhalten Sie folgende Ausgabe:

Die Ausgabe von "Test2 nach Error" unterbleibt, da die Funktion "Test2" keine eigenes explizites "ON ERROR RESUME NEXT" hat. Der in Zeile 21 provozierte Fehler führt daher direkt zu einem Ende dieser Funktion und einem Rücksprung zu Zeile 8.

onerrorscope.vbs
Das VBScript zum selbst experimentieren.

Praktisch bedeutet dies, dass Sie am besten eine Fehlerbehandlungsroutine schreiben, die im Rahmen der Debugausgabe sehr oft aufgerufen wird und sie in jeder Funktion und Prozedur ein "ON ERROR RESUME NEXT" einfügen.

VBScript und HTA

VBScript ist primär eine Skriptsprache für die Kommandozeile. Die normalen Ausgaben beschränken Sich auf das Schreiben von Textzeilen auf die Konsole (wscript.echo) oder in das Eventlog und die Ausgabe über  Mitteilungsfenster (msgbox "Meldung"). Erst über die Einbindung z.B. des Internet Explorers als COM-Objekt kann VBScript auch formatierte Ausgaben erstellen. VBScript kann dann über das Document Object Model (DOM) des Browsers im Betrieb eine Webseite erstellen und so als formatierte Ausgabe nutzen.

Nahe verwandt sind dabei auch die HTA-Dateien. Genau genommen sind das auch "nur" VBScript-Dateien,  die aber in einer HTML-Datei eingebettet sind. Der Internet Explorer startet die HTA-Datei und zeigt die HTML-Inhalte an. So können Sie Eingabemasken etc. z.B. mit Frontpage erstellen und hinter die Buttons entsprechende Skriptfunktionen zu hinterlegen. Damit wird der Internet Explorer dann zum Ersatz für die Windows Forms einer Anwendung. Microsoft selbst nutzt diese HTA-Dateien auch für verschiedene Assistenten (z.B.: Scriptomatic)

VBScript und ASP

Sie dazu die eigene Seite MSXFAQ.DE - ASP

VBScript und TCP/IP und SMTP

So leistungsfähig VBScript auch sein kann, es ist nichts ohne entsprechende COM-Module, die instanziert und genutzt werden können. Zwei wesentliche Funktionen fehlen bei VBScript:

Allerdings gibt es eine Menge von Drittherstellern, die eben diese fehlenden WINSOCK und SMTP-Objekte als kommerzielle Produkte oder auch als Freeware bereit stellen.

VBScript und "Lokalität"

Als alter Pascal Programmierer war es problemlos möglich, an eine Funktion oder Prozedur entsprechende Parameter zu übergeben. Diese konnten in der Prozedur ohne Risiko geändert werden, da sie "lokal" waren. Bei VBScript wird erst mal alles "byRef" übergeben. Das ist zwar schneller, aber bedeutet auch, dass sie eine übergebene Variable in einer Funktion nicht einfach verändern sollten, weil sich damit auch der Inhalt der Variable im darüber liegenden Programm ändert.

Das gleiche gilt, wenn man Klassen (Objektorientierte Entwicklung) nutzt. folgendes Beispiel instanziert eine Klasse, füllt diese mit einem Wert und über die Zeile "set o2=o1" kopiert man die Klasse.

option explicit

dim o1, o2

set o1 = new Testclass
o1.test="1"
wscript.echo "o1:" & o1.gettest

set o2 = o1
wscript.echo "o2:" & o2.gettest
o2.test="2"

wscript.echo "o1:" & o1.gettest
wscript.echo "o2:" & o2.gettest


class Testclass

    dim strtest

    public property let test(wert)
        strtest = wert
    end property
   
    function gettest
        gettest = strtest
    end function
end class

In Realität ist es aber keine Kopie, sondern nur eine Referenz. Wenn man nun die Instanz "o1" verändert, dann ändert sich damit auch o2. Zerstört man nun o1, dann ist auch o2 nicht mehr gültig. Um eine echte Kopie zu erzeugen, muss man eine neue Instanz mit "set o2 = new testclass" erzeugen und die Eigenschaften manuell übernehmen.

Beachten Sie auch die Probleme von MSXFAQ.DE - VBScript Falle "ByVAL"

VBScript und Errors

Manchmal glauben Sie, ihr Skript ist 100% fehlerfrei und es tut dennoch nicht, was es soll. Dann kann es sein, dass Sie auf "besondere" Felder gestoßen sind. Angenommen Sie möchten den Inhalt des Felds "Company" eines Benutzers prüfen, dann könnten Sie folgende Zeile programmieren. 

if (currentobj.Fields("company") <> "MSXFAQ") then
	wscript.echo "Company ist nicht korrekt"
endif

Wenn das Feld "company" dann den falschen Wert enthält, dann wird auch sauber "Company ist nicht korrekt" angezeigt. Ist aber das Feld "company" gar nicht belegt (also NULL), dann ist es mit schon passiert, dass der THEN-Teil trotzdem nicht aufgerufen wurde, obwohl "NULL <> "MSXFAQ" ist. Seit dem prüfe ich lieber auf Gleichheit und nutze den Else-Zweig, also:

if (currentobj.Fields("company") = "MSXFAQ") then
	wscript.echo "Company ist korrekt"
else
	wscript.echo "Company ist nicht korrekt"
endif

Tückisch und eigentlich nur über den Debugger zu finden, wenn der Code nicht dort einspringt.

VBScript und Include

Je mehr Programme man schreibt, desto mehr baut man sich eine Library von Codeteilen auf, die man immer wieder verwendet. Ich habe mir z.B.: Klassen für Debugging, CSV-Lesen, CSV-Schreiben etc. gebaut. Natürlich kann ich bei einem neuen Skript auch einfach wieder diese Klasse per Copy&Paste in den neuen Code übernehmen. Das ist aber ungeschickt da eine Korrektur oder Erweiterung der Klasse sich nicht auf alle Programme auswirken, die diese Klasse nutzen, es sei denn ich ersetze die alte Version durch die neue Version in jedem Programm. Warum nicht auch Codeteile einfach "auslagern" in eigene Dateien. Leider kenn VBScript keine "Include"-Anweisung. ASP kann über die "#include file=name"-Anweisung anderen ASP-Code einbinden. Bei VBScript kann man sich das aber auch selbst schreiben. Hier ein Beispiel, dass Programm main.vbs die include1.vbs einfach einbindet und ausführt.

' Inhalt von main.vbs
wscript.echo "Main gestartet"

includecode("include1.vbs")
call include1
wscript.echo "Main beendet"


sub IncludeCode (fname)
    dim strcode
   
    wscript.echo "IncludeCode loading " & fname
    Dim fso, f
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set f = fso.OpenTextFile(fname, 1) ' forreading
    strcode = f.ReadAll
    executeglobal strcode ' muss global sein, da sonst nur in dieser SUB erreichbar
end sub

' Inhalte von include1.vbs
sub include1
   wscript.echo "include1 gestartet"
end sub

Der Trick über "ExecuteGlobal" führt den Inhalt des Strings einfach aus.

VBScript kompilieren und verschlüsseln

Schon immer war es für Firmen besonders wichtig, ihre Leistung zu schützen. Daher ist es natürlich gar nicht gerne gesehen, wenn Wettbewerber den Code einer Firma in Klartext erhalten, anpassen und weiter verwenden könnten. Natürlich gibt es auch genau die andere Seite, die Als "Open Source" gerade jeden Quellcode offen legt und die Lizenzbedingungen z.B. fordern, dass davon abgeleiteter Code ebenfalls "offen" sein muss. Fakt ist aber, dass jeder Code von einer CPU ausgeführt werden muss und dazu "lesbar" ist. Natürlich ist ein kompilierter Maschinensprachecode nicht wirklich lesbar, aber es gibt Disassembler, die es schon vereinfachen, die ein oder andere Logik zu dekodieren.

VBScript hingegen ist quasi immer Sourcecode, da der Windows Scripting Host diesen erst im Moment des Aufrufs "kompiliert". Das macht ja gerade die Flexibilität aus, aber macht es natürlich auch schwer, die Vorgänge zu verbergen. Seit es aus Schutzbedarf aber auch einfach um z.B.  Kennworte zu verbergen, die in dem ein oder anderen Code enthalten sind.

Für VBScript gibt es einen "Script Encoder", durch den aus einer VBS-Datei dann eine VBE-Datei wird, die verschlüsselt ist. Allerdings kann nicht nur CSCRIPT.EXE und WSCRIPT.EXE diesen Code entschlüsseln, sondern auch einige Programme von Drittherstellern.

Insofern können Sie sich das Verschlüsseln auch einfach sparen, da es kein echter Schutz ist. Nur wenn Sie ihren Code direkt auf eine sehr niedrige Abstraktionsebene kompilieren, wird es möglichen Interessenten sehr schwer gemacht. Das Problem der Dekompilierung ist auch bei .NET vorhanden, da die "Intermediate language" noch sehr abstrakt ist und durch aus "gelesen" werden kann.

VBScript signieren

Gerade im Einsatz innerhalb von Firmen sind Makros und Viren immer ein besondert kritisches Thema. Dazu zählen natürlich auch Skripte, die mit Berechtigungen des Benutzers oder sogar eines Administrators gestartet werden. Skripte sind ja sehr einfach zu ändern und ein Angreifer könnte daher einem Administrator ein verändertes Skript unterschieben. Um dies zu verhindern, können Sie als Administrator natürlich die Ausführung von Skripten in ihrem Netzwerk über Gruppenrichtlinien steuern. So könnten Sie erzwingen, dass nur signierte VBScripte von Benutzern ausgeführt werden dürfen. Diesen "Schutz" sollten Sie für Installationskonten nicht aktivieren, da einige Installationsprogramme ebenfalls VBS-Dateien nutzen. In Kürze geht dies durch folgende Schritte

makecert.exe -n "cn=Testzertifikat" -ss my -eku 1.3.6.1.5.5.7.3.3

Setreg.exe 1 true

signcode.exe -cn "Testzertifikat" -t http://timestamp.verisign.com/scripts/timstamp.dll meinskript.vbs

chktrust.exe hello.vbs

Eine ausführliche Beschreibung der Zertifizierungsprozedur finden Sie auch auf http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx.

Scriptomatic Helfer

Microsoft Script Links

Exchange/Outlook und Scripting

Andere Links zu Scripting

Keywords: Code VBScript SDK VBS ASP