Wer jemals in Microsofts "Exchange" unter Windows NT ein Benutzerkonto mit Mail-Postfach angelegt hat, kennt das Problem: Die Modifikation komplexer Einträge in den mitunter äußerst unübersichtlichen Konfigurationsdateien läßt sich effektiv nur mit grafischen Administrationswerkzeugen wie NT-Benutzer-Manager oder Exchange-Administrator meistern.
Doch in vielen Fällen gilt es nicht einen, sondern Dutzende oder Hunderte dieser Accounts einzurichten. Diese Anforderungen finden sich häufig bei Web-Service-Providern, DV-Schulungsanbietern und in Migrationsprojekten - für die jeweiligen Administratoren eine Sisyphusarbeit.
Einrichten von Accounts beibt Handarbeit
Während Unix an dieser Stelle mit mächtigen Shells für die Automatisierung von Aufgaben per Script aufwartet, stellt die DOS- Box mit ihren MS-DOS-Batch-Files unter Windows NT kein brauchbares Pendant dar. Sofern die entsprechenden Softwareprodukte überhaupt eine Schnittstelle bieten, blieb unter NT bis dato ein Programmieren eigener Routinen, die auf die proprietären, heterogenen APIs der verschiedenen Softwareprodukte zugreifen, nicht erspart.
Dies soll künftig anders werden: Microsoft offeriert seit kurzem eine Scripting-Lösung für Windows NT, 98, 95. Die Architektur besteht aus drei Bausteinen: Ablaufumgebungen für Scriptsprachen, sogenannte Scripting Hosts, die den Shells unter Unix entsprechen, sowie verschiedene Scripting Engines (Sprach-Interpreter) und Objektbibliotheken, die einen Proxy für den Zugriff auf die verschiedenen Betriebssystem- und Applikationsfunktionen darstellen oder aber eigene Routinen enthalten.
Als Scripting Hosts stehen derzeit der "Internet Explorer", "Microsoft Outlook", "Windows Scripting Host" (WSH), die "Active Server Pages" (ASP) im "Internet Information Server" und der "Event Scripting Agent" im Exchange Server zur Verfügung. Beide letzteren lassen sich allerdings lediglich auf einem NT-Server verwenden. Der Windows Scripting Host ist der leichtgewichtigste unter den Scrip- ting-Shells. Er existiert sowohl in einer Windows- (wscript) als auch einer DOS-Version (cscript). Das eigentliche Script wird entweder in einer eigenen Datei abgelegt oder aber ist in ein anderes File wie etwa eine HTML-Seite oder ein Outlook-Formular eingebettet.
Die in den Scripting Hosts verwendete Scriptsprache ist dabei variabel. Bei der Scripting Engine handelt es sich um eine Active- X-Komponente, wobei der Scripting Host jede Scripting Engine benutzen kann, die über eine sogenannte Iactive-Script-Parse- Schnittstelle verfügt. Somit lassen sich auch Interpreter-Sprachen wie "Perl" und "TCL" einbinden. Ein Scripting Host unterstützt beliebig viele Scripting Engines.
Microsoft selbst liefert zusätzlich zwei Script-Interpreter: VB Script, eine Light-Version der hauseigenen Sprache Visual Basic, und Jscript, eine Variation des von Netscape entwickelten Javascript. Beide Script Engines können unter bestimmten Bedingungen auch in selbstprogrammierten Scripting Hosts verwendet werden.
Der konkrete Zugriff auf die Optionen und Funktionalitäten von Betriebssystem und Anwendungen erfolgt über Objektbibliotheken. Die Objektbibliotheken sind Softwarekomponenten gemäß dem ebenfalls von Microsoft entwickelten Component Object Model (COM). Die Arbeit mit COM-Objekten verläuft objektorientiert mit instanzierbaren Klassen und Objekten, die aus Methoden und Attributen bestehen. Die verteilte Variante von COM, das Distributed Component Object Model (DCOM), läßt sich beim NT- Scripting derzeit noch nicht direkt verwenden, sondern setzt eine lokal installierte Proxy-Komponente voraus.
Zusammen mit dem Windows Scripting wird eine Wscript- Objektbibliothek ausgeliefert, die einen Zugriff auf Systemeigenschaften, Registry, Dateiverküpfungen, Netzlaufwerke, Netzdrucker und Systemordner ermöglicht. Sie beschränkt sich auf die Administration des Rechners, auf dem das Script ausgeführt wird. Vor allem eignet sie sich für Logon-Scripts, nicht jedoch für die zentrale Administration eines Netzwerkes.
Mit dem Active Directory Service Interface (ADSI) bietet Microsoft eine Objektbibliothek für den Zugriff auf in Verzeichnisbäumen organisierte Informationen. ADSI ist ein Vorgriff auf den Active Directory Service (ADS), der mit NT 5.0 eingeführt werden soll, bei dem das flache Domain-Modell durch eine hierarchische Verzeichnisstruktur abgelöst wird. Darüber hinaus stellt ADSI eine allgemeine Schnittstelle zu Verzeichnisdiensten dar.
Unter der Voraussetzung, daß ein ADSI-Provider für den jeweiligen Verzeichnisdienst existiert, bietet ADSI dem Programmierer eine einheitliche Schnittstelle zum Zugriff auf alle Verzeichnisobjekte, zu welchem Verzeichnisdienst sie gehören und egal wo sie sich im Netz befinden. Mit der derzeit aktuellen ADSI- Version 2.0 werden ADSI-Provider für NT 4.0, Novells Netware 3.x, die Novell Directory Services, Microsofts "Internet Information Server 4.0" und das Lightweight Directory Access Protocol (LDAP) ausgeliefert. ADSI eröffnet beispielsweise den Zugriff auf Benutzer und Benutzergruppen, NT-Services, Druckerwarteschlangen und einzelne Druckjobs sowie Verzeichnisfreigaben.
ADSI erlaubt in der vorliegenden Version hingegen noch nicht, auf Dateien und Verzeichnisse des NT-Filesystems zuzugreifen. Dafür stehen Objekte in Microsofts "Scripting Runtime Library" bereit. Ebenso mangelt es dem ADSI-NT-Provider bislang an Möglichkeiten, die Access Control Lists (ACL) zu manipulieren, die die Zugriffsrechte auf Ressourcen regeln.
Die größte Bedeutung für die Zukunft besitzt zweifelsohne der LDAP-Provider, denn er ermöglicht den Zugriff auf Verzeichnisdienste, die das Lightweight Directoy Access Protocol (LDAP) unterstützen. Dabei handelt es sich um eine abgespeckte Version des im X.500-Standard spezifizierten Directory Access Protocol (DAP). NT 5 soll LDAP-fähig werden, heißt es aus dem Hause Microsoft. Heute sind dies schon der Exchange Server 5.5 sowie der Netscape Directory Server. So kann das Anlegen, Verändern und Löschen von Mail-Konten im Exchange Server mit der bevorstehenden Version 2.5 von ADSI vollständig automatisiert werden.
LDAP ermöglicht jedoch nur die Manipulation der Verzeichnisstruktur und -einträge, nicht der Inhalte der Mail- Postfächer. Dafür stand bisher die MAPI-Schnittstelle zur Verfügung, die inzwischen ebenfalls in eine Objektbibliothek gekapselt wurde, die "Colloboration Data Objects" (CDO). Sie erlauben das Verwalten von elektronischen Nachrichten in jede Art von MAPI-fähigen E-Mail-Systemen.
Als universelle Datenbank-Schnittstelle hat Microsoft inzwischen die "Active X Data Objects" (ADO) eingeführt, die die früheren Bibliotheken Data Access Objects (DAO) und Remote Data Objects (RDO) ablösen sollen. ADO basiert auf dem OLE-DB-Konzept, das einen Zugriff auf SQL- ebenso wie auf Nicht-SQL-fähige Datenspeicher (zum Beispiel strukturierte Textdateien, Messaging- Speicher) ermöglicht. Ebenso wie bei ADSI wird dies über ein Provider-Konzept realisiert. Einen OLE-DB-Provider, der die Datenbankabfrage über Verzeichnisdienste erlaubt, gibt es auch für ADSI. Für ADO stellt sich der Verzeichnisdienst wie eine objektorientierte Datenbank dar, mit dem Vorteil, daß nunmehr auch ein mengenmäßiger Zugriff möglich ist, im Kontrast zu dem Einzel- Objekt-Zugriff bei der direkten ADSI-Programmierung.
Der generelle Vorteil der Kapselung in COM-Objekten ist die Unterstützung des objektorientierten Paradigmas zur Wiederverwendbarkeit. COM-Objekte können aus allen Programmiersprachen angesprochen werden, die COM unterstützen. Dazu gehören neben C++, J++ und Visual Basic auch dessen zweiter Ableger, Visual Basic for Applications (VBA). Die erwähnten Objektbibliotheken lassen sich also auch aus Anwendungen heraus nutzen, die VBA unterstützen, wie zum Beispiel MS Office oder Visio. Ebenso können die Scripting Hosts auf die Objekte von Anwendungen zurückgreifen, die in COM-Komponenten zerlegt sind. Die neuen Möglichkeiten der NT-Automatisierung sind vielfältig, deshalb hängt es besonders von Scriptsprache und Objektbibliotheken ab, wie aufwendig ein Automatisierungs-Projekt wird.
Holger Schwichtenberg ist Diplom-Wirtschaftsinformatiker und leitet den Bereich Infrastruktur-Development bei der BOV Computersysteme GmbH Microsoft Solution Provider Partner aus Essen.