Die Visual Basic Scripting-Umgebung
In diesem Abschnitt will ich Ihnen kurz den Rahmen erklären, in dem wir unsere Skripte für die Verzeichnis-Manipulation entwickeln.
Da Visual Basic Script eine leicht zu erlernende Variante des Scriptings darstellt und fast alle nur denkbaren Möglichkeiten für den Zugriff auf einen Verzeichnis-Dienstes bietet, werden wir uns im SelfADSI Projekt auf diese Scripting-Sprache konzentrieren.
Folgende Abschnitte stehen auf dieser Seite zur Verfügung:
Der Windows Scripting Host
Unter Windows benötigt man für die Ausführung von ADSI-Skripten die Laufzeitumgebung des Windows Scripting Host (WSH). Dieser stellt sozusagen das Grundgerüst für den Ablauf von Scripts dar - entweder als Standalone-Script oder als Teil eines HTML-Dokumentes innerhalb eines Web Browser.
Dabei kann der Windows Scripting Host nicht nur Visual Basic Skripte ausführen,
sondern es ist prinzipiell auch die Ausführung von JavaScript, Perl,
REXX oder Phyton denkbar. Zum diesem Zweck laufen dann unter der Regie
des WSH diverse Script-Engines. Moderne Windows-Versionen enthalten neben
dem WSH auch bereits die Script-Engines für VBScript und JavaScript
(JScript). Die neueste Version der Script-Umgebung inklusive VBScript und
JScript können Sie von der MSDN-Seite herunterladen:
Download-Seite für dir Windows Script Umgebung (WSH / VBScript Engine / JScript Engine) Version 5.6
Download-Seite für die Dokumentation zur Windows Script Version 5.6
Scripte erstellen - Script-Editoren
VB-Scripte können sie mit jedem Text-Editor erstellen, z.B. im Notepad-Editor. Speichern Sie hier Ihr erstelltes Script einfach als *.vbs-Datei ab.
Bequemere Script-Erstellung (so dass z.B. die Schlüsselworte der Script-Sprache oder Kommentare andersfarbig markiert werden) ist mit diversen kommerziellen Script-Editoren möglich, einige Beispiel hierfür seien exemplarisch erwähnt.
Der ASE Editor (Admin Script Editor) beherrscht z.B. Syntax-Einfärbung des Quellcodes:
VBSEdit kann mittels Intellisense bei der Eingabe von Befehlen das Kommando oder die Parameter automatisch vervollständigen und bringt eine Integration des Microsoft Script Debuggers mit. Der Object-Browser ermöglicht es, Methoden und Eigenschaften von Objekten zu untersuchen. Sehr empfehlenswert und nicht teuer:
Der Klassiker PrimalScript kann über die die Fähigkeiten von VBSEdit hinaus noch Strukturen wie z.B. "If Then - Else - End If" Konstrukte auf- und zuklappen, so dass man einen schnellen Überblick auch über komplexe Skripte gewinnt:
Bedenken Sie bei der Auswahl Ihres Script-Editors, dass es auch kein Fehler sein kann, an den Editor gewöhnt zu sein, den man auf jedem Windows System vorfindet: Notepad. Ein echter Vorteil bei der Entwicklung komplexer Scripts ist es jedoch, wenn der Editor gleich den Microsoft Debugger aufrufen kann.
Scripts ausführen
Scripts können ausgeführt werden, indem man sie in eine HTML-Page einlagert und diese Webseite von einem Web Browser geöffnet wird. Für administrative Aufgaben sind jedoch Standalone-Scripte zweckmäßiger, die per Kommando-Zeile aufgerufen werden. Dies geschieht mit folgendem Befehl:
C:>cscript[//WSH-Parameter] <Pfad zur Script-Datei>[Script-Parameter]
also z.B.
C:>cscript//nologo n:\admin\create-user.vbs/u:phil /d:"cn=Philipp,dc=Betrieb,dc=kashmir,dc=net"
Sie können Scripte auch mit der "Geschwister-Tool" wscript aufrufen - der Unterschied zwischen den beiden besteht in der Art, wie Ausgaben behandelt werden, die im Script z.B. mit der Funktion WScript.Echo ausgelöst werden.
- cscript gibt die Ausgaben in dem Terminal-Fenster (cmd-Kommandozeile) aus, in dem das Script aufgerufen wurde.
- wscript gibt die Ausgaben in einer Windows-Messagebox aus.
Stellen Sie sich folgendes einfaches Script vor, dass in der Datei hello.vbsabgespeichert wird:
Aufruf mit cscript hello.vbs:
Aufruf mit wscript hello.vbs:
Die Aufrufparameter der beiden Utilities cscript und wscript sind übrigens identisch:
MSDN-Info über die Commandline Parameter für cscript und wscript
In den meisten Fällen verwenden wir cscript, so werden alle Ausgaben einfach jede für sich in einer neuen Zeile im Terminal-Fenster wiedergegeben, bei wscript muss man sich gegebenenfalls durch viele aufploppende Windows-Messagebox-Fenster klicken. Außerdem lassen sich cscript-Ausgaben in Dateien mit normalen Pipelining umlenken.
Scripts direkt ausführen wie Programme
Man kann die Windows-Oberfläche auch dazu bringen, in einer Kommando-Shell VBS-Dateien direkt auszuführen, so dass man nicht extra den Aufruf
C:>cscript[//WSH-Parameter] <Pfad zur Script-Datei>[Script-Parameter]
benötigt. Wenn Sie den Script-Namen einfach wie ein Programm in der Eingabeaufforderung starten wollen, dann müssen Sie folgenden Registry-Parameter setzen:
HKEY_CLASSES_ROOT\
VBSFile\
Shell\
Open\
Command\
(Standard) REG_EXPAND_SZ:
cScript.exe //nologo "%1" %*
Danach können Sie das "Hello World"-Script von oben wie
folgt öffnen:
Eine entsprechende Registry-Import-Datei finden sie hier:
 |
Download vbsfile.reg |
Scripts debuggen
Mit dem Microsoft Script Debugger lassen sich Visual Basic Scripts schrittweise debuggen.
Download-Seite für den Microsoft Script Debugger
Der Debugger ist eigentlich nur für HTML-eingebettete Skripte gedacht. Um ein Visual Basic Script direkt im Debugger auszuführen, schreiben Sie im Quellcode an der Stelle, an der Sie das Script anhalten wollen, den Befehl "Stop" und rufen dann das Script mit dem cscript/wscript-Parameter //x auf:
C:>cscript //x test.vbs
Allerdings kann man hier keine konfortablen Debugger-Funktionen wie das einfache Einsehen der Variablen-Inhalte erwarten. Außerdem kann man bei Script-Fehlern nicht den Quelltext nicht direkt im Debugger-Fenster editieren. Insgesamt empfehle ich einen dafür spezialisierten Editor wie z.B. VBSEdit:
Scripts verschlüsseln
Unter Umständen möchten Sie ihr Script weitergeben, wollen aber nicht, dass der Ausführende des Script auch dessen Inhalt sehen kann. Eine einfache (wenn auch relativ plumpe) Verschlüsselung Ihrer Scripts bietet der Microsoft Script Encoder. Fertige VB Scripts lassen sich damit per Kommandozeilenaufruf in eine verschlüsselte, aber nach wie vor lauffähige Variante umwandeln.
Download-Seite für Mcrosoft Script Encoder
ADSI Versionen
Momentan ist das ADSI-Interface in der Version 2.5 verfügbar. Diese Version bietet Zugriff nicht nur auf generische LDAP-Server wie Active Directory, sondern auch auf andere Verzeichnisdienste. Es sind deshalb sogenannte Provider für NT 4.0, Novell NetWare 3.x, Netware Directory Service sowie für die Metabase des Microsoft Internet Information Service vorhanden.
Um zu ermitteln, welche ADSI-Version an einem Rechner installiert ist, muß man sich in die Registry begeben. Dort steht die Version unter folgendem Schlüssel:
HKEY_LOCAL_MACHINE\
SOFTWARE\
Microsoft\
Active Setup \
Installed Components\
{E92B03AB-B707-11d2-9CBD-0000F87A369E}
Version REG_SZ
Seltsamerweise steht dort bei Windows-Versionen, die ADSI in der Version 2.5 bereits mitgelifert bekommen, als Version "5,0,00,0". Es handelt sich jedoch trotzdem um die ADSI Version 2.5 Dieser Effekt tritt ab Windows 2000 der Fall (siehe unten im nächsten Abschnitt).
Eine genaue Anleitung zum Ermittlen der ADSI-Version auch aufgrund der Versionen der beteiligten DLL-Dateien gibt Microsoft im Knowledge Base Artikel Q216290.
ADSI nutzen unter Windows 2000/XP/Vista/7 und Windows 2003/2008
Unter diesen Betriebssystemen stehen die Libraries der ADSI-Schnittstelle automatisch zu Verfügung. Hier können Sie also ein Script, dass ADSI-Objekte erzeugt und benutzt und damit auf die diversen Verzeichnisdienste zugreift, ohne weitere Vorbereitung verwenden. Um der Version von ADSI auf einem Rechner zu ermitteln, verfolgen Sie die Schritte, die im vorletzten Abschnitt beschrieben wurden.
ADSI nutzen unter Windows 9x und Windows NT
Unter diesen Betriebssystemen stehen die Libraries der ADSI-Schnittstelle nicht automatisch zu Verfügung. Ein Script, das AD-Objekte und -Methoden verwendet, wird einen Laufzeitfehler erzeugen, der so oder so ähnlich aussieht:
Um die ADSI-Schnittstelle unter Windows 9x oder Windows NT nutzen zu können, benötigen Sie die sogenannten Active Directory Erweiterungen für Windows NT 4.0. Es handelt sich dabei um einen kostenlosen Treiber, mit dem der NT- und W9x-Client z.B. auch DFS-fähig wird und Drucker im Active Directory suchen kann. Und einer der Vorteile dieser Erweiterung ist es nun, dass dadurch die ADSI-Schnittstelle auf diese Rechner kommt. Dieser Treiber ist auch unter der Bezeichnung "DSClient" bekannt. Die Installation erfordert einen Neustart des betreffenden Rechners.
Download-Seite für die Active Directory Erweitungen für W9x und NT