Windows- und BackOffice-Scripting

Transkript

1 Windows- und BackOffice-Scripting 1 Einführung 1.1 Der Automatisierungsbedarf Microsoft spielt auf dem Weltmarkt der Betriebssysteme eine zentrale Rolle. Das gilt nicht nur für den Heimbereich (mit Windows 95, Windows 98 und z.t. auch NT-Workstation), sondern zunehmend auch für den professionellen Anwendungsbereich mit der NT-Produktreihe. Windows NT hat sich in den letzten Jahren auch als Serverbetriebssystem gegenüber Unix in einigen Bereichen durchgesetzt. Ein Grund dafür sind die grafischen Benutzeroberflächen (engl. Graphical User Interfaces, kurz GUI), die eine sehr einfache Bedienung ermöglichen. Fast alle administrativen Funktionen des Windows-Betriebssystems lassen sich durch ein GUI verwalten. Die Windows- GUIs zeichnen sich durch eine hohe Konsistenz aus, d.h., sie sind nach dem gleichen Prinzip aufgebaut; sie haben alle ähnliche Menüs, Symbolleisten und Dialogfenster. Die Installation und Konfiguration eines Windows-Systems ist daher vergleichsweise einfach und intuitiv. Sofern grundsätzliche Erfahrung in der Administration eines Windows-Systems besteht, ist die Einarbeitung in neue Aufgaben einfach. Auch Personen, die nur selten administrative Aufgaben ausführen müssen, können diese schnell erledigen, ohne komplexe Befehle beherrschen zu müssen. Ein gutes GUI ist aber nur ein Aspekt der Administration. Auf der anderen Seite der Medaille stehen Aufgaben, die sich nicht oder nur schlecht durch ein GUI lösen lassen: Zum einen sind dies Aufgaben, die unbeaufsichtigt, d.h. ohne Beisein eines Menschen von der Maschine automatisch ausgeführt werden sollen (z.b. Überwachungsaufgaben, Systemstart-Skripte, rechenintensive Prozesse, die nur nachts ausgeführt werden können). Zum zweiten sind dies wiederkehrende Administrationsaufgaben, die in definierten Intervallen ausgeführt werden sollen (z.b. Backup, Datenabgleich, Login-Skripte). In die dritte Gruppe gehören Administrationsaufgaben, die zu einem bestimmten Zeitpunkt in großer Menge anfallen (z.b. Benutzereinrichtung bei einer Systemumstellung). Schließlich will ein Administrator auch bestimmte Aufgaben an andere Personen delegieren. Diesen Personen möchte er eine Routine zur Verfügung stellen, die abseits der vielfältigen Möglichkeiten eines GUIs in einem fest vorgeschriebenen Dialogpfad eine bestimmte isolierte Aufgabe erledigt. GUIs Automatisierungsbedarf 27

2 1 Einführung Derartige Aufgaben können unter Windows durch DOS-Batch-Prozesse oder Skripte automatisiert werden. 1.2 Die DOS-Batchsprache DOS-Batch Schwachpunkte APIs Die DOS-Batchsprache, die in Einzelbefehlen im Befehlszeilenfenster oder in Form von.bat-dateien ausgeführt werden kann, gibt es seit den Anfängen von MS-DOS. Sie war damals zu einer Zeit, als es noch keine grafische Benutzeroberfläche namens Windows gab ein adäquates Instrument zur Systemadministration. Sie ist auch heute noch in allen Windows-Versionen integriert. Die DOS-Batchsprache hat in all diesen Jahren allerdings nur wenige Veränderungen erfahren, obwohl die Anforderungen stets gestiegen sind. Windows war daher in diesem Bereich gegenüber Unix lange Zeit im Nachteil. In Unix gibt es mächtige Shells, in denen so genannte Shell-Scripts ausgeführt werden können, mit denen sich alle administrativen Aufgaben durchführen lassen. Die wesentlichen Schwachpunkte der DOS-Batchprogrammierung sind: Die DOS-Batchsprache ist keine vollständige Programmiersprache. Es gibt keine Funktionen zur Verarbeitung von numerischen Werten und Zeichenketten. Die Ein- und Ausgabe ist zeilenorientiert. Es gibt keine Möglichkeit, Programmierschnittstellen (weder komponentenbasierte noch nichtkomponentenbasierte) anzusprechen. Die Sprache ist nur über neue.cmd- oder.exe-dateien erweiterbar. Die DOS-Befehle decken zwar die Anforderungen der DOS-Ebene ab, auf viele GUI-Funktionen gibt es jedoch keinen Zugriff. Sofern die zu automatisierenden Softwareprodukte überhaupt ein Application Programming Interface (API) boten, mussten die Zugriffe auf diese proprietären, heterogenen APIs in DOS-Befehle oder eigenständige Anwendungen (.EXE) gekapselt werden. Die Kommunikation mit einer Batchdatei erfolgte dann über Textzeilen. Lange Zeit wurden diese Schwachstellen in den Windows-Betriebssystemen von Microsoft gar nicht beachtet. Skriptsprachen für Windows waren nur von Drittanbietern (z.b. KiXtart32, PERL und REXX) verfügbar. Interessanterweise hat sich Microsoft des Themas Windows Scripting erst im Zuge der Besinnung auf das Internet und der dortigen Popularität von Skriptsprachen angenommen. Inzwischen stellt Microsoft jedoch eine eigene modulare Scripting-Architektur für Windows bereit. 28

3 Was ist Scripting? 1.3 Was ist Scripting? Scripting ist das Schreiben eines Programms mit Hilfe einer Skriptsprache; das Programm wird in diesem Zusammenhang Skript genannt. Diese Definition führt zu der Frage, was eine Skriptsprache ist. Die Antwort darauf ist jedoch nicht einfach. [FIS99] nennt folgende Kriterien zur Unterscheidung einer Skriptsprache von anderen Sprachen: Die Sprache dient dem Ad-hoc-Gebrauch. Die Sprache wird interpretiert. Die Syntax ist einfach. Es gibt nur ein sehr schwaches Typsystem. Die Abstraktion von technischen Details wie z.b. Zeigern ist hoch. Beispiele für Skriptsprachen sind REXX, Perl, Python, AppleScript, PHP, JavaScript/JScript und VBScript. Gemäß obiger Definition sind auch die Unix-Shellsprachen wie sh und csh als Skriptsprachen zu betrachten. Skriptsprachen kommt in Zusammenhang mit komponentenorientierter Softwareentwicklung oft die Rolle zu, als Verbindung (so genannter Glue Code) zwischen Komponenten zu fungieren. Diese Rolle nehmen die Skriptsprachen auch beim ActiveX Scripting ein. Scripting und Skriptsprachen Glue Code für Komponenten 1.4 Die Windows Scripting-Architektur Die Windows Scripting-Architektur heißt bei Microsoft auch ActiveX Scripting, Active Scripting oder Windows Script. In diesem Buch wird vorzugsweise der Begriff Windows Scripting verwendet. Grundlage der gesamten Architektur ist Microsofts Komponentenarchitektur das Component Object Model (COM). ActiveX Scripting Das Component Object Model ist Microsofts Technologie für die Entwicklung und Nutzung von objektorientierten Softwarekomponenten, die COM-Komponenten genannt werden. ActiveX ist ein Marketingbegriff für einen Teil dieser Komponentenarchitektur. COM wird ausführlich in Kapitel 2 vorgestellt. Die Windows Scripting-Architektur besteht aus folgenden drei Bausteinen: ActiveX Scripting Hosts sind die Ablaufumgebungen für Skripte. ActiveX Scripting Engines stellen einen Sprachinterpreter für eine bestimmte Skriptsprache bereit. Automationsfähige COM-Komponenten ermöglichen den Zugriff auf Systemkomponenten oder stellen in gekapselter Form bestimmte Funktionalitäten bereit. 29

4 1 Einführung Active Script Ein Skript, das innerhalb der ActiveX Scripting-Architektur ausgeführt wird, heißt Active Script. Abbildung 1.1: Die ActiveX Scripting-Architektur von Microsoft "#! Plug&Play COM versus ActiveX Die Scripting-Architektur ist so konzipiert, dass die einzelnen Bausteine untereinander austauschbar sind: Jeder Scripting Host kann jede Scripting Engine verwenden. Jede automationsfähige COM-Komponente kann von jedem Scripting Host und jeder Skriptsprache benutzt werden. Dies wird über wohldefinierte Schnittstellen sichergestellt. Damit ist Plug&Play zwischen Hosts und Engines verschiedener Hersteller möglich. Die Skriptsprache kann auch innerhalb eines einzigen Skripts variieren; so können etwa einzelne Unterroutinen in einer anderen Sprache als das Hauptprogramm geschrieben werden, wenn die besten Features der jeweiligen Sprache genutzt werden sollen. Auch Scripting Hosts und Scripting Engines sind COM-Komponenten, die spezielle Schnittstellen implementieren. Dass die Architektur ActiveX Scripting und nicht COM Scripting heißt, beruht darauf, dass Microsoft aus Marketinggründen den Begriff ActiveX gefördert hat. ActiveX wurde eine Zeit lang mit dem Begriff COM sogar völlig gleichgesetzt. In Kapitel 2 erhalten Sie eine detaillierte Einführung in COM. Die Trennung in Host und Sprache ist in vielen Skriptsprachen nicht gegeben. So steht der Begriff Personal Home Page Tools (PHP) sowohl für eine Sprache als auch für einen Scripting Host. Gleiches gilt für die Unix- Shells. 30

5 Die Windows Scripting-Architektur Die neuen Möglichkeiten der NT-Automatisierung sind vielfältig, deshalb kommt es besonders auf die Auswahl von Skriptsprache und Komponenten an, wenn es um die Frage geht, wie aufwendig ein Automatisierungsprojekt wird. Eine intensive Recherche nach vorhandenen COM-Komponenten ist ein entscheidender Erfolgsfaktor. Mit der zunehmenden Verbreitung des Komponentengedankens werden Make-or-Buy-Entscheidungen zu einem ständigen Begleiter im Softwareentwicklungsprozess. Entwickler werden sich fragen lassen müssen, ob es notwendig war, eigene Routinen zu entwickeln, anstatt auf dem Markt verfügbare Komponenten zu einer Anwendung zusammenzubauen. Gerade der Windows-Scripting-Bereich zeigt, dass eine unterlassene Internet-Recherche dazu führt, dass man sich tagelang mit Problemen beschäftigt, die andere mit wesentlich geringeren Kosten längst gelöst haben. Vielfältige Möglichkeiten Scripting Hosts Ein Scripting Host ist die Ablaufumgebung für ein Skript und insofern vergleichbar mit den Shells unter Unix. Der Internet Explorer war der erste Scripting Host überhaupt; mit dem Windows Scripting Host (WSH) gibt es inzwischen einen eigenständigen Scripting Host für die Windows-Plattform. Der Windows Scripting Host (WSH) sollte keineswegs mit dem allgemeinen Begriff Scripting Host verwechselt werden. Der WSH ist nur einer von vielen ActiveX Scripting Hosts. Wohl aus Gründen der besseren namentlichen Abgrenzbarkeit nennt Microsoft diesen Scripting Host seit Version 2.0 Windows Script Host. Microsoft integriert Scripting Hosts in immer mehr Produkte, insbesondere in solche aus der Backoffice-Reihe: Active Server Pages im Internet Information Server (IIS) ab Version 3.0 Event Scripting Agent im Exchange Server ab Version 5.5 Server-Agent im SQL Server 7.0 Data Transformation Scripts im SQL 7.0-Data Transformation Service Dynamic HTML-Scripting im Internet Explorer ab Version 3.0 Outlook Forms in Microsoft Outlook ab Version 8.0 XSL-Scripting im Microsoft XSL-Processor Installer Scripts im Windows Installer Scripting Hosts werden inzwischen auch von anderen Anbietern bereitgestellt. Mit dem Script Control bietet Microsoft zudem die Möglichkeit, auf einfache Weise in eigene Anwendungen einen Scripting Host zu integrieren. Zwar sind die VBA-Umgebungen (VBA steht für Visual Basic for Applications) (noch) nicht nach der Windows Scripting-Architektur konstruiert, in der Praxis sind sich die Architekturen aber sehr nahe: Ein Skriptprogrammierer, der auf Visual Basic Script (VBScript) setzt, kann mit Cut&Paste des Quelltexts sowie mit ein paar einfachen Änderungen seine Skripte auch in VBA laufen lassen. Mit anderen Skriptsprachen geht das allerdings nicht. Ablaufumgebung Verfügbare Scripting Hosts VBA 31

6 1 Einführung Sprachinterpreter Verfügbare Skriptsprachen VBScript Scripting Engines Eine ActiveX Scripting Engine ist ein Sprachinterpreter für eine Skriptsprache mit der Nebenbedingung, dass der Interpreter in Form einer COM-Komponente vorliegt, bestimmte Schnittstellen implementiert und für eine der entsprechenden Komponentenkategorien registriert ist. Verfügbare Skriptsprachen Microsoft selbst hat bislang zwei ActiveX Scripting Engines veröffentlicht: VBScript (eine abgespeckte Version der Programmiersprache Visual Basic) JScript (eine Erweiterung der auf Netscape JavaScript basierenden Sprachspezifikation ECMA 262). Weitere Sprachen sind im Bereich der Free- und Shareware zu finden: PerlScript (ActiveX Scripting-fähige Perl-Implementierung der Firma ActiveState, siehe [ACT00]) PScript (ActiveX Scripting-fähige Perl-Implementierung der Firma MKS, siehe [MKS00]) PythonScript (ActiveX Scripting-fähige Version von Python [PYT00a] und [PYT00b], Open Source) HaskellScript (ActiveX Scripting-fähige Version der funktionalen Skriptsprache Haskell, siehe [HAS00], Open Source). Gerüchte um die ActiveX Scripting-fähigen Implementierungen von Lisp, REXX und TCL konnten zum Zeitpunkt des Redaktionsschlusses dieses Buchs nicht bestätigt werden. In diesem Buch wird durchgängig VBScript benutzt. VBScript ist die am häufigsten verwendete Sprache beim Windows Scripting. Auch auf Grund der weitgehenden Kompatibilität mit der Vollversion von Visual Basic ist VBScript die erste Wahl bei den Skriptsprachen unter Windows. Kapitel 3 stellt die Sprache ausführlich vor. Ansicht der installierten Skriptsprachen Installierte Skriptsprachen Skriptsprachen werden bei der Installation in der Registry unter einer speziellen Kategorie von Komponenten registriert. Am einfachsten können Sie die auf Ihrem System installierten Skriptsprachen mit Hilfe des Tools COM-Viewer (siehe Kapitel 6) einsehen. Es gibt dort mehrere Einträge unter ACTIVE SCRIPTING ENGINE, die die Sprachen nach ihren Fähigkeiten kategorisieren. 32

7 Die Windows Scripting-Architektur Abbildung 1.2: Anzeige der installierten Skriptsprachen im COM Object Viewer Zu jeder Sprache werden Sie einen Eintrag ProgID finden. Diese ProgID (Programmatic Identifier) ist in einigen Scripting Hosts wichtig zur Identifizierung der Skriptsprache. Visual Basic Script hat die ProgID VBScript, JScript die ProgID JScript. ProgID der Sprache COM-Komponenten Ein Skript benötigt den Zugriff auf das das Skript umgebende System, um administrative Aufgaben und die Interaktion mit dem Anwender durchführen zu können. Grundsätzlich gibt es für eine Skriptsprache zwei Möglichkeiten, wie sie diesen Zugriff herstellen kann: Zum einen können in der Sprache selbst Sprachkonstrukte und Funktionen integriert sein, die den Zugriff auf das System ermöglichen. Zum anderen kann die Sprache aber auch einen Mechanismus bereitstellen, um vorhandene Programmierschnittstellen (Application Programming Interfaces APIs) anzusprechen. Die erste Möglichkeit wird von fast allen Skriptsprachen hinsichtlich rudimentärer Ein- und Ausgabebefehle genutzt. Die Bereitstellung darüber hinausgehender Systemfunktionen bereitet jedoch Unannehmlichkeiten. Zum einen kann die Sprache kaum plattformunabhängig sein, da jedes Betriebssystem seine eigenen spezifischen Systemfunktionen bereitstellt. Zum anderen muss die Sprache ständig erweitert werden, um mit den Veränderungen der System-APIs Schritt halten zu können. Beliebter ist daher die zweite Möglichkeit (Bereitstellung eines API-Zugriffsmechanismus), die jedoch dann beschwerlich ist, wenn unterschiedliche Arten von Programmierschnittstellen unterstützt werden müssen. Microsoft geht in der ActiveX Scripting-Architektur den zweiten Weg mit der Prämisse der Einschränkung auf eine einzige Art von Programmierschnittstellen, nämlich automationsfähige COM-Komponenten. Verfahren für den System-Zugriff Zugriffsmöglichkeiten auf APIs 33

8 1 Einführung COM- Komponenten Sie werden in Kapitel 2 den Unterschied zwischen automationsfähigen und nicht-automationsfähigen COM-Komponenten genauer kennen lernen. So viel vorweg: COM-Automation ist in etwa gleichzusetzen mit einem späten Binden zur Laufzeit. Die Arbeit mit COM-Objekten verlangt einer Programmiersprache die Unterstützung einiger grundlegender Mechanismen ab. Sofern diese jedoch implementiert sind, kann die Sprache mit einer Vielzahl unterschiedlicher COM-Objekte aus unterschiedlichen COM-Komponenten zusammenarbeiten. Die Arbeit mit COM-Objekten ist objektbasiert mit instanziierbaren Klassen, die aus Methoden und Attributen bestehen. Die Klassen sind in der Regel in hierarchischen Objektmodellen angeordnet, für das Skript ist die Komponente eine Objektbibliothek. Auf einen Zugriff auf Nicht-COM-APIs (z.b. DLLs, die keine COM-Komponenten sind) hat Microsoft ausdrücklich verzichtet. Es gibt jedoch inzwischen Ansätze, dies zu ermöglichen (vgl. die Ausführungen zu DynaWrap in Kapitel 5). Auch wenn viele COM-Komponenten COM-Automation unterstützen, gibt es Komponenten, die den Dienst nicht anbieten und daher im Windows Scripting nicht verwendbar sind. Typisierung Zahlreiche Komponenten Komponententypen Komponenten erweitern also die eingebauten Funktionen der Skriptsprachen und lassen sich aus Scriptingsicht in zwei Typen einteilen: Einige Komponenten kapseln den Zugriff auf bestehende APIs von Betriebssystem und Anwendungen. Die Komponenten sind hier Stellvertreter, die die (komplexen) API-Funktionen kapseln. Als positiver Nebeneffekt entsteht dabei in der Regel ein einfaches Objektmodell als Ersatz für komplexe Reihen von API-Aufrufen. Andere Komponenten implementieren eigenständige Funktionalitäten, für die keine weiteren Anwendungen nötig sind. Es sind bereits zahlreiche Komponenten für den Zugriff auf unterschiedliche Betriebssystem- und Anwendungsfunktionen verfügbar: So ermöglichen COM-Komponenten unter Windows beispielsweise den Zugriff auf Betriebssystemfunktionen wie Windows-Benutzeroberfläche, Verzeichnisdienste, Dateisystem, Registry, Eventlog, Hardware, Scheduler, MTS/ COM+, Dokumente (z.b. Text, HTML, XML) und Netzwerkprotokolle (z.b. TCP, IP, HTTP, FTP) Anwendungen wie Microsoft Office, Microsoft Exchange Server, Microsoft SQL Server, Internet Information Server, aber auch auf Produkte wie Lotus Notes, Corel Draw und SAP R/3. Nicht alle Komponenten stammen von Microsoft selbst: Es gibt inzwischen unzählige Komponenten anderer Anbieter zum Teil auch als Share- und Freeware. Auch selbstentwickelte COM-Komponenten können unabhängig 34

9 Die Windows Scripting-Architektur von der Programmiersprache, in der sie implementiert wurden, verwendet werden. Anwendungen, die direkt komponentenbasiert entwickelt werden, können sehr einfach per Skript angesteuert werden. Kapitel 1.6 liefert einen Überblick über die wichtigsten Komponenten. Windows Script Components (WSCs) sind in Skriptsprachen geschriebene COM-Komponenten. Der Begriff WSC steht weder allgemein für Komponenten, die von Skripten aus genutzt werden können, noch für die Bausteine der Windows Scripting-Architektur. WSC Intrinsic Objects Viele Scripting Hosts besitzen so genannte Intrinsic Objects (auch: Built-In Objects oder Internal Objects) für den Zugriff auf den Scripting Host und dessen direkte Umgebung. Intrinsic Objects sind COM-Objekte, die zu Beginn beim Start des Scripting Hosts oder beim Start eines konkreten Skripts automatisch durch den Scripting Host instanziiert werden. Dem Skript steht die so erzeugte Instanz in Form eines bestimmten Bezeichners als Intrinsic Object zur Verfügung. Die Active Server Pages (ASP) stellen eine Reihe von Intrinsic Objects zur Kommunikation mit dem Webserver zur Verfügung (z.b. Request, Response, Server). Der Windows Scripting Host (WSH) liefert ein WScript-Objekt zum Zugriff auf den Host und Informationen über das aufgerufene Skript. Der Exchange Event Agent bekommt über das Objekt EventDetails Zugriff auf die , die seinen Aufruf getriggert hat, und auf den Ordner, in dem die Nachricht steht. Ein Transformation Script im Data Transformation Service (DTS) hat über die Objekte DTSSource und DTSDestination die nötigen Informationen über die an der Transformation beteiligten Daten. Jeder Scripting Host hat andere Intrinsic Objects. Oft stehen die dazugehörigen Klassen nur diesem Scripting Host zur Verfügung, so dass eine Instanziierung durch andere Scripting Hosts oder Anwendungen unmöglich ist. Es kann aber natürlich auch vorkommen, dass eine Klasse, welche in einem Scripting Host ein Intrinsic Object ist, in einem anderen Scripting Host durch explizite Instanziierung erzeugt wird. Eingebaute Objekte Beispiele für Intrinsic Objects in verschiedenen Scripting Hosts Werkzeugunterstützung Die Werkzeugunterstützung der Skriptentwicklung unter Windows ist noch verbesserungswürdig. Mit Visual InterDev liefert Microsoft zwar eine Skriptentwicklungsumgebung; diese unterstützt aber bislang fast nur die Skriptprogrammierung im Web. In vielen Scripting Hosts (z.b. SQL Server Agent, Microsoft Outlook) stehen nur sehr primitive Editoren bereit, so dass die Skriptprogrammierung sehr mühsam ist. Editoren, Debugger und Tools 35

10 1 Einführung Auch hinsichtlich des Debuggings ist die Werkzeugunterstützung noch nicht optimal, wenn man die Entwicklungsumgebungen wie Visual C und Visual Basic 6.0 als Maßstab nimmt. Inzwischen gibt es zum Teil bessere Lösungen von Drittanbietern. Einen Überblick über die verfügbaren Werkzeuge liefert Kapitel Scripting-Schnellstart WSH 2.0 und IE ab 4.0 Wenn Sie noch nie ein Skript unter Windows erstellt haben, werden Ihnen die folgenden beiden Beispiele erste Erfolgserlebnisse bereiten. Voraussetzung für das erste Beispiel ist, dass Sie den Windows Scripting Host in der Version 1.0 oder 2.0 installiert haben. Sie sollten in Ihrem Windows-Verzeichnis eine Datei WSCRIPT.EXE finden. Wenn Sie Windows 2000 benutzen, können Sie fast sicher sein, dass Sie den WSH 2.0 auf Ihrem System haben. Unter Windows 98 ist der WSH in der Version 1.0 eine Installationsoption, unter NT4 gibt es den WSH nur als separates Add-on. Wenn der WSH 2.0 nicht vorhanden ist, installieren Sie ihn bitte von der Buch-CD aus dem Verzeichnis /INSTALL/HOSTS/WSH. Voraussetzung für das zweite Beispiel ist ein installierter Internet Explorer in der Version 5.0. Die beiden Skripte befinden sich natürlich auch auf der Buch-CD [CD:/ code/einfuehrung/schnellstart/]. Jedoch sollten Sie sich an dieser Stelle durchaus die Mühe machen, die Skriptdateien selbst zu erstellen Ein einfaches WSH-Skript Ihr erstes Skript So erstellen Sie Ihr erstes Skript für den Windows Scripting Host in der Sprache Visual Basic Script: Legen Sie eine Textdatei an, indem Sie irgendwo auf dem Desktop oder in einem Verzeichnis im Dateisystem im Kontextmenü NEU TEXTDATEI wählen. Es erscheint eine Datei NEUE TEXTDATEI.TXT. Benennen Sie die Datei in ERSTESSKRIPT.VBS um. Bestätigen Sie die Nachfrage des Betriebssystems, ob die Dateiextension wirklich geändert werden soll. Wählen Sie aus dem Kontextmenü der Datei BEARBEITEN, so dass sich der Notepad öffnet. (Sofern Sie einen anderen Editor installiert haben, mag jetzt dieser gestartet werden.) Geben Sie Folgendes in die erste Zeile ein: MsgBox "Ab heute kann ich skripten!" Speichern Sie die Änderungen ab. Sie können den Editor schließen, müssen es aber nicht. 36

11 Scripting-Schnellstart Doppelklicken Sie auf die Datei ERSTESSKRIPT.VBS. Wenn Sie alles richtig gemacht haben und das System Ihnen wohlgesonnen ist, wird die nachstehend abgebildete Dialogbox erscheinen. Abbildung 1.3: Ausgabe des Skripts»ErstesSkript.vbs«1.5.2 Ein komplexeres Skript mit zwei Sprachen für den IE Das zweite Beispiel wird Ihnen bereits zeigen, wie Sie zwei Skriptsprachen innerhalb einer Skriptdatei mischen können. Als Scripting Host wird der Internet Explorer (Version 5.0) eingesetzt. Ihr zweites Skript Legen Sie eine Textdatei an, indem Sie irgendwo auf dem Desktop oder in einem Verzeichnis im Dateisystem im Kontextmenü NEU TEXTDATEI wählen. Es erscheint eine Datei NEUE TEXTDATEI.TXT. Benennen Sie die Datei um in ZWEITESSKRIPT.HTM. Bestätigen Sie die Nachfrage des Betriebssystems, ob die Dateiextension wirklich geändert werden soll. Wählen Sie aus dem Kontextmenü ÖFFNEN MIT und dort NOTEPAD. (Wenn Sie einen HTML-Quellcodeeditor auf Ihrem System haben, können Sie auch diesen nutzen.) Geben Sie die folgenden Zeilen ein: <HTML>Beispiel für die Mischung von ActiveX-Sprachen <SCRIPT language="javascript"> // Unterroutine in JScript function jadd(a,b) { return(a+b) } </script> <script language="vbscript"> ' Hauptprogramm in VBScript x = 5 y = 6 Ergebnis = jadd(x,y) ' JScript zur Addition nutzen msgbox x & " + " & y & " = " & ergebnis </SCRIPT></HTML>" Speichern Sie die Änderungen ab. Sie können den Editor schließen, müssen es aber nicht. Doppelklicken Sie auf die Datei ZWEITESSKRIPT.HTM. Wenn Sie alles richtig gemacht haben und das System Ihnen wohlgesonnen ist, wird der Internet Explorer mit nachstehend abgebildeter Dialogbox erscheinen. 37

12 1 Einführung Abbildung 1.4: Ausgabe des Skripts im Internet Explorer Überblick WSH Runtime, MSHTML, Internet Controls WMI WSH Runtime, STMAdmin, ACES 1.6 Komponentenüberblick Dieses Kapitel unternimmt einen Streifzug durch die administrativen Aufgaben, die derzeit durch Komponenten automatisiert werden können. Sofern die Komponenten in diesem Buch besprochen werden, finden Sie die entsprechenden Kapitelnummern in Klammern. Benutzeroberfläche Für die Manipulation der Benutzeroberfläche ist in erster Linie die WSH Runtime-Komponente (Kapitel 5.1) zuständig. Ergänzende Funktionen bieten die Shell Objects (Kapitel 5.3). Hilfreich ist oft der Einsatz der Microsoft Internet Controls-Komponente (Kapitel 5.4) und der MSHTML-Komponente (Kapitel 5.5), die zusammen die Funktionalität des Internet Explorers verkörpern. Systemmanagement Das Windows Management Instrumentation (WMI) ist ein übergreifender Ansatz zum Zugriff auf alle möglichen Arten von System- und Netzwerkinformationen (Kapitel 5.11). WMI ermöglicht auch den Zugriff auf Informationen aus Quellen wie Registry, Dateisystem und Ereignisprotokollen, die durch andere Einzelkomponenten bereits abgedeckt sind. Während WMI den Vorteil der Einheitlichkeit bietet, sind die speziellen Komponenten im konkreten Anwendungsfall oft etwas einfacher zu handhaben. Ereignisprotokolle Die WSH Runtime-Komponente (Kapitel 5.1) kann Einträge in das EventLog nur erzeugen. Die Freewarekomponente STMAdmin kann Einträge über ein Objektmodell auch lesen (Kapitel 5.9.1). Die Firma ACES bietet im Rahmen des ACES WinNT Automation Kit auch die Möglichkeit, auf das EventLog wie auf eine Datenbanktabelle zuzugreifen (Kapitel 5.9.2). 38

13 Komponentenüberblick Registry Wieder bietet die WSH Runtime-Komponente (Kapitel 5.1) nur rudimentäre Zugriffsmöglichkeiten auf die Registry. Als bessere Alternative wird in diesem Buch die Komponente RegCol (Kapitel 5.8) vorgestellt. Rechte auf Registry-Schlüssel können nur mit der ADsSecurity-Komponente (Kapitel ) geändert werden. Scheduler Auch der Windows-Schedule-Dienst kann durch WMI automatisiert werden; einfacher in der Benutzung ist jedoch die Taskscheduler-Komponente (Kapitel 5.7) aus dem Site Server 3.0. Komponentenkonfiguration Die Basiskonfiguration der auf dem System installierten COM-Komponenten ist entweder über direkte Registry-Manipulation oder durch WMI möglich. Für die erweiterten Einstellungen im Zusammenhang mit dem Microsoft Transaction Server und COM+ gibt es eigene Komponenten (Kapitel 5.12). Dateisystem Den Zugriff auf das Dateisystem ermöglichen in erster Linie die File System Objects (FSO), vorgestellt in Kapitel 5.2. Zum Teil ergänzt, zum Teil redundant abgebildet werden die Funktionen von FSO in den Shell Objects (Kapitel 5.3). Zum Zugriff auf die Rechte in NTFS-Dateisystemen benötigen Sie die ADsSecurity-Komponente (Kapitel ). Zum Zugriff auf entfernte Dateisysteme via FTP gibt es neben der Internet-Transfer-Komponente von Microsoft zahlreiche interessante Lösungen von Drittanbietern (Kapitel 5.18). Netzwerkkommunikation TCP/IP-Kommunikation auf Transportebene ermöglicht die Microsoft Winsock-Komponente (Kapitel ). Auf Anwendungsebene bietet Microsoft die Internet Transfer-Komponente zur HTTP- und FTP-Kommunikation (Kapitel ). Gerade in diesem Bereich gibt es auch viele andere Anbieter, z.b. ASPInet (Kapitel ) und Mabry FTPX (Kapitel ). Komponenten zur SMTP-Kommunikation (JMAIL, CDONTS, CDOSYS) stellt Kapitel 5.17 vor. Messaging und Groupware Für die Verarbeitung von elektronischen Nachrichten stellt Microsoft mit den Collaboration Data Objects (CDO) inzwischen eine ganze Familie von Komponenten zur Verfügung (Kapitel 5.15 und ). Es gibt auf dem Freeund Sharewaremarkt zahlreiche Komponenten für das Handling von SMTP- Nachrichten (z.b. JMAIL, Kapitel ). Einige CDO-Versionen beherrschen darüber hinaus aber die Nachrichtenkommunikation via MAPI. Auch die Firma Lotus bietet mit den Notes OLE Objects eine COM-Komponente für den Zugriff auf ihr Groupware-System an. WSH Runtime, RegCol Taskscheduler- Komponente WMI, MTS Objects, COM+ Objects FSO, Internet Transfer Winsock CDO, Notes Objects 39

14 1 Einführung ADO, MSXML, TOM ADO, ADOX, ADOMD ADSI ADSI ADSI ADsSecurity, ACL CDO, Rule, ESConfig Textdateien Beliebige Textdateien können mit der Scripting Runtime-Komponente (Kapitel 5.2) bearbeitet werden. Für INI- und CSV-Dateien gibt es u.a. die Komponente WindowsScripting (Kapitel 5.20). Die ActiveX Data Objects (ADO) können auf strukturierte Textdateien zugreifen (Kapitel 5.6). XML-strukturierte Textdateien werden mit Hilfe der MSXML-Komponente verarbeitet (Kapitel 5.5). ADO kann Datenbanktabellen in XML-Dateien umwandeln. Das Text Object Model (TOM) für den Zugriff auf Rich-Text-Dateien wird in diesem Buch nicht vorgestellt. Datenbanken und andere Datenquellen Die ActiveX Data Objects (ADO) (Kapitel 5.6) sind allgemeine Komponenten für den Zugriff auf Datenquellen. Dazu gehören neben Datenbanken auch Textdateien und Verzeichnisdienste. Neben der ADO-Kernkomponente gibt es inzwischen zwei Erweiterungen: Microsoft ADO Extensions for DDL and Security (ADOX) und ADO Multi Dimensional (ADOMD) für die OLAP- Dienste. Verzeichnisdienste Eine der wichtigsten Komponenten ist das Active Directory Service Interface (ADSI) (Kapitel 5.10), mit dem Verzeichnisdienste unterschiedlicher Art verwaltet werden können. Neben der Verwaltung des Active Directory unter Windows 2000 gehört dazu auch die Benutzer- und Ressourcenverwaltung unter NT4. Internet Information Server (IIS) Der IIS wird über seine Metabase konfiguriert, die wie ein Verzeichnisdienst behandelt wird; die Automatisierung erfolgt hier also über das Active Directory Service Interface (ADSI) (Kapitel ). Exchange Server 5.5 Für den Zugriff auf den Exchange Server gibt es inzwischen mehrere Lösungen, die zum Teil redundant sind. Da der Exchange- Verzeichnisdienst LDAP-fähig ist, kann auch hier das Active Directory Service Interface (ADSI) (Kapitel ) eingesetzt werden. Für die Konfiguration der Rechte auf Exchange-Verzeichnisobjekte benötigen Sie die ADsSecurity-Komponente (Kapitel ). Eine Ausnahme bilden auch hier die öffentlichen Ordner, deren Rechte Sie nur über die ACL-Komponente aus dem Exchange Resource Kit setzen können. Die ebenfalls mit dem Exchange Resource Kit gelieferte AcctCrt-Komponente bietet dagegen nur Funktionen, die sich auch mit ADSI und der ADsSecurity-Komponente erledigen lassen. Primär auf die Inhalte, also den Message Store, fokussiert die Komponente Collaboration Data Objects (CDO) (Kapitel 5.15 und ). Zum Teil kann CDO aber auch auf den Verzeichnisdienst zugreifen. Für spezielle, ver- 40

15 Komponentenüberblick steckte Nachrichten wie Regeln und Event Agents gibt es eigene Automatisierungskomponenten in Form der Rule-Komponente sowie der ESConfig- Komponente. Öffentliche Ordner können nur mit CDO, nicht aber mit ADSI eingerichtet werden. Abbildung 1.5: Komponenten für die Automatisierung des Exchange Servers 5.5 #$&'!"# %$$ $!" #$ Exchange Server 2000 An dieser Aufteilung der Automatisierungsschnittstellen hat sich mit Exchange 2000 einiges geändert. Die Collaboration Data Objects 3.0 haben sich gegenüber den CDO-Versionen für Exchange 5.5 stark verändert (Kapitel ). Das Active Directory Service Interface (ADSI) spielt auf Grund der Integration von Exchange 2000 in das Active Directory weiterhin eine zentrale Rolle. Hinzugekommen ist einerseits der Zugriff auf den Exchange Infostore via ActiveX Data Objects (ADO) und zum anderen eine neue Komponente mit dem Namen CDO for Exchange Management (CDOEXM), beschrieben in Kapitel Für den Bereich der Workflow-Funktionen bietet Exchange 2000 die Komponente Microsoft CDO Workflow Objects for Microsoft Exchange (CDOWF). Einige Funktionen von Exchange 2000 können auch über WMI überwacht und gesteuert werden. Das komplexe Thema der Automatisierung von Exchange 2000 wird in Kapitel 5.16 zusammenhängend behandelt. CDO 3.0, ADSI, ADO, CDOEXM, CDOWF, WMI SQL Server Der Zugriff auf den Inhalt von SQL Server-Datenbanken ist mit den ActiveX Data Objects (ADO) möglich (Kapitel 5.6). Die Konfiguration des SQL Servers und der Datenbanken selbst wird dagegen durch die SQL Server Distributed Management Objects (SQL-DMO; Kapitel 5.13) abgebildet. Für die Administration der OLAP-Dienste gibt es die Decision Support Objects (DSO). ADO, ADOX, ADOMD, DMO, DSO 41

16 1 Einführung DTS Ein weiterer abgeschlossener Bereich innerhalb des SQL Servers ist der Data Transformation Service (DTS). Dieser kann über die Microsoft DTSPackage Object Library (Kapitel 5.14) automatisiert werden. 42