Microsoft Windows 2000 - Scripting-Handbuch (Teil 1) Scripting-Konzepte und -Technologien zur Systemadministration: Kapitel 1 - Einführung in die Windows-Scripting-Technologien

Veröffentlicht: 26. Apr 2004

(Engl. Originaltitel: Introduction to Windows Script Technologies)

Dieses Kapitel des "Microsoft Windows 2000 - Scripting-Handbuchs" bietet eine

Einführung in das Thema Scripting im Allgemeinen und in die Windows-Scripting-Technologien im Speziellen. Zudem erläutert es Aufbau, Inhalt und Zielsetzung des Handbuchs sowie die Systemanforderungen, die für die im Buch beschriebenen Muster-Scripte erfüllt sein müssen.

Zurück zur Übersichtsseite

Dies ist ein Buch über das Scripting für Systemadministratoren. Wie die meisten Systemadministratoren wundern Sie sich möglicherweise, warum sich dieses Buch an Sie wendet. Im Allgemeinen gehört Scripting nicht zu den Dingen, mit denen sich Systemadministratoren beschäftigen. Jeder weiß: Scripting ist schwer, Scripting ist zeitaufwendig und für Scripting müssen Sie alle möglichen Abkürzungen lernen - WSH, WMI, ADSI, CDO, ADO, COM. Systemadministratoren verfügen weder über die Zeit noch über den Hintergrund, um Scripte schreiben zu können. Oder doch? Eines der Hauptziele dieses Buches ist es, Missverständnisse wie diese zu beseitigen. Ist Scripting schwer? Möglicherweise. Andererseits - werfen Sie doch einmal einen Blick auf das folgende Script. Es führt eine häufig auftretende administrative Aufgabe durch.

Set objNetwork = CreateObject("WScript.Network")
objNetwork.MapNetworkDrive "X:", "\\atl-fs-01\public"

Auch wenn Sie nichts über Scripting wissen und fassungslos auf die erste Zeile blicken, werden Sie trotzdem erkennen, dass das Script die Freigabe \\atl-fs-01\public zu Laufwerk X zuordnet. Wenn Sie sich mit der Systemadministration auskennen - das bedeutet, Sie wissen was eine Freigabe, ein gemapptes Netzlaufwerk und ein UNC-Pfad (Universal Naming Convention) ist - dann ist der Schritt vom Mappen eines Laufwerks über die grafische Benutzeroberfläche oder die Kommandozeile zum Mappen eines Laufwerks über ein Script nicht mehr sehr groß.

Anmerkung:

• Wenn Sie jetzt schon den Faden verloren haben - zum Beispiel, weil Sie sich nicht sicher sind, was Scripting überhaupt sein soll - dann stellen Sie sich Scripte so vor:
• Stellen Sie manchmal fest, dass Sie immer dieselben Befehle für dieselben Aufgaben verwenden? Erwischen Sie sich dabei, wie Sie oft auf die gleichen Schalter in den gleichen Assistenten klicken, um einen Vorgang auf vielen Computern oder für viele Benutzer durchzuführen?
• Scripte helfen Ihnen dabei, solche wiederholenden Arbeiten zu automatisieren. Ein Script ist eine Datei, die die zur Durchführung einer Aufgabe notwendigen Schritte beschreibt. Nachdem Sie das Script erstellt haben, können Sie es "ausführen" - es führt die Schritte dann für Sie durch und spart Ihnen viel Zeit und Energie. Sie müssen das Script nur einmal erstellen und können es dann so oft wie nötig benutzen.

Zugegebenermaßen sind nicht alle Scripte so einfach und intuitiv, wie das eben gezeigte. Wenn sie dieses Buch durcharbeiten, werden Sie feststellen, dass die meisten der gezeigten Scripte nicht mehr als 15 bis 20 Zeilen lang sind - und sie führen alle nützlichen administrativen Aufgaben aus. Viele der Scripte können Sie untersuchen, und über den Scriptcode können Sie herausfinden, was das Script macht - hierzu ist es ganz egal, wie groß Ihre Scripting-Erfahrung ist.

Erfordert Scripting viel Zeit? Kann sein. Wenn Sie ein Script schreiben, dass 500 Zeilen lang ist (das könnte durchaus passieren), dann wird schon das Eingeben des Scriptes eine Menge Zeit kosten. Wichtiger ist es aber, die Entwicklungszeit des Scriptes und die Zeiteinsparung durch die Verwendung des Scriptes zu berücksichtigen. Unten finden Sie beispielsweise ein Script, das alle Ereignisprotokolle eines Computers sichert und löscht.

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate, (Backup, Security)}!\\" _
        & strComputer & "\root\cimv2")
Set colLogFiles = objWMIService.ExecQuery _
    ("Select * from Win32_NTEventLogFile")
For Each objLogfile in colLogFiles
    strBackupLog = objLogFile.BackupEventLog _
        ("c:\scripts\" & objLogFile.LogFileName & ".evt")
    objLogFile.ClearEventLog()
Next

Zugegeben, dieses Script ist nicht so intuitiv wie das erste Script. Außerdem werden Sie zur Entwicklung eines solchen Scripts etwas mehr über Scripting und über WMI lernen müssen. Und Sie müssen das Script ja auch noch in Notepad eingeben - die ganzen 11 Zeilen.

Aber überlegen Sie Folgendes: Wie lange würde es dauern, die Ereignisprotokolle eines Computers manuell zu sichern und zu löschen? (Wenn Sie dies überhaupt manuell durchführen - da das manuelle Löschen und Sichern so mühsam und zeitaufwändig ist, wird der Vorgang oft einfach vergessen.) Mit einem Script können Sie diese Aufgabe in wenigen Minuten durchführen. Und wie wäre es, wenn Sie eine weitere halbe Stunde investieren, um das Script so zu ändern, das es die Ereignisprotokolle auf allen Computern sichert und löscht? Möglicherweise müssen Sie etwas Zeit und Energie investieren, aber es wird nicht lange dauern, bis sich diese Investition auszahlen wird.

Noch nicht überzeugt? Auch wenn Scripting nicht schwer und zeitaufwändig ist, so müssen Sie doch noch immer den ganzen technischen Krimskrams lernen? Sicherlich - wenn Sie ein Experte im Scripting werden wollen. Schauen Sie sich doch einmal das folgende Script an. Es gibt die Namen aller auf einem Computer installierten Dienste zurück.

strComputer =  "."
Set objWMIService = GetObject("winmgmts:" & _
"{impersonationLevel=Impersonate}!\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_Service")
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next

Das ist ein recht kompliziertes Script. Neben anderen Dingen verwendet es:

• Objekt-Methoden und -Attribute
• Sprachelemente von Microsoft® Visual Basic® Scripting Edition (VBScript), wie zum Beispiel eine For-Each-Loop-Schleife um die Elemente einer Collection aufzulisten
• Einen COM-Moniker (Component Object Model)
• WMI-Objektpfade, -Namensräume und –Klassen
• Eine WMI-Abfrage

Um dieses sieben Zeilen lange Script schreiben zu können, müssen Sie also über eine ziemlich große Menge an Wissen verfügen. Kein Wunder, dass viele Leute denken, dass Scripting schwer ist.

Die Wahrheit ist aber, um ein Script wie dieses schreiben zu können, müssen Sie COM und Automatisation nicht vollständig verstehen. Nehmen Sie an, dass, was Sie wirklich möchten, ist ein Script, dass die Namen aller im Moment auf einem Computer ausgeführten Prozesse zurückgibt statt die Namen aller installierten Dienste. Ein solches Script sieht so aus:

strComputer =  "."
Set objWMIService = GetObject("winmgmts:" & _
"{impersonationLevel=Impersonate}!\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_Process")
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next

Was hat sich im Vergleich zum vorherigen Script geändert? Nichts - und genau darum geht es. Schauen Sie genau hin - es gibt einen fett gedruckten Eintrag (Win32_Process). Das ist der einzige Teil, der sich gegenüber dem vorherigen Script geändert hat. Haben Sie schon mehr über COM-Monikers oder WMI-Objektpfade gelernt? Wahrscheinlich nicht. Sie können jetzt aber dieses grundlegende Script nehmen und es so verändern, dass es die von Ihnen gewünschten Informationen zurückgibt. Wie wäre es mit den installierten Grafikkarten? Versuchen Sie dieses Script:

strComputer =  "."
Set objWMIService = GetObject("winmgmts:" & _
"{impersonationLevel=Impersonate}!\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_VideoController")
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next

Sind alle Scripte so einfach? Nein, leider nicht. Und in diesen Beispielen werden einige Probleme einfach nicht beachtet (zum Beispiel "Woher weiß ich, dass es Win32_VideoController und nicht Win32_VideoCard heißt?' oder 'Was ist, wenn ich mehr als nur den Namen der Grafikkarte wissen möchte?'). Der Punkt ist nicht, dass Sie Scripte schreiben können ohne irgendetwas zu wissen. Der Punkt ist, Sie können Scripte schreiben ohne alles wissen zu müssen. Wenn Sie sich mit COM-Monikern und WMI-Objektpfaden auskennen, bevor Sie Ihr erstes Script schreiben, dann ist das super. Wenn Sie es vorziehen, sich einfach mit dem Schreiben von Scripten beschäftigen möchten - zum Beispiel indem Sie auf den Beispielen dieses Buches aufbauen - dann ist das ebenso in Ordnung.

Wodurch hat sich Scripting einen so schlechten Ruf erworben?

Wenn Scripting so einfach ist, warum hat es dann einen so schlechten Ruf? Und wenn es so nützlich ist, warum nutzen es nicht mehr Systemadministratoren? Schließlich würden die meisten Systemadministratoren etwas, dass ihnen das Leben einfacher macht, nicht wissentlich ignorieren.

Es gibt wahrscheinlich viele Gründe für diesen schlechten Ruf - die meisten von ihnen gehen aber auf die ersten Versionen der Microsoft® Windows® Script-Technologie zurück. VBScript und Microsoft® JScript® (die zwei Scriptsprachen, die mit Microsoft® Windows® zur Verfügung stehen) wurden für clientseitiges Scripting für Webseiten entwickelt. Für Internet-Entwickler waren sie sehr nützlich - für Administratoren eher nicht. Daher wurde Scripting oft eher mit der Entwicklung von Webseiten in Verbindung gebracht (auch heute ist noch eine Menge des Bespielcodes aus der offiziellen Microsoft VBScript-Dokumentation in eine Webseite eingebettet).

Später wurde der Windows Script Host (WSH) entwickelt. Der WSH ermöglichte die Verwendung von Scriptsprachen und -Technologien außerhalb von Internet Explorer; tatsächlich wurde der WSH sogar für Systemadministratoren entwickelt. Trotzdem konnte sich Scripting in der Systemadministration nicht umfassenden durchsetzen.

Dies lag möglicherweise anfangs an der fehlenden Dokumentation. Es war schwer, Informationen zur Verwendung von VBScript oder JScript als Systemadministrationstool zu finden, und Informationen zu Technologien wie WMI oder Active Directory Service Interfaces (ADSI) zu finden war so gut wie unmöglich. Auch als diese endlich dokumentiert waren (typischerweise über Software Development Kits), war diese Dokumentation für Programmierer gedacht. Codebeispiele waren typischerweise in C++ statt in einer Scriptsprache geschrieben. Stellen Sie sich vor, Sie sind ein typischer Systemadministrator (mit guten Kenntnissen zu Windows und minimalen Kenntnissen zur Programmierung). Stellen Sie sich nun vor, Sie suchen auf der Microsoft-Website nach Informationen über Script und finden den folgenden Beispielcode:

int main(int argc, char **argv)
{
   HRESULT hres;
   hres =  CoInitializeEx(0, COINIT_MULTITHREADED); // Initialize COM.
  if (FAILED(hres))
  {
     cout << "Failed to initialize COM library. Error code = 0x"
          << hex << hres << endl;
     return 1;                  // Program has failed.
  }
   hres =  CoInitializeSecurity(NULL, -1, NULL, NULL,
        RPC_C_AUTHN_LEVEL_CONNECT,
        RPC_C_IMP_LEVEL_IDENTIFY,
        NULL, EOAC_NONE, 0
        );

Mit einem solchen Beispiel gibt es wohl kaum sehr viele Systemadministratoren, die glauben, dass WMI oder ADSI praktische Werkzeuge sind.

Heutzutage besteht natürlich kein Mangel mehr an Literatur zum Thema Scripting. Eine kürzliche Suche bei einem großen Online-Buchversender nach dem Schlüsselwort 'VBScript' ergab 339 Treffer. Das sind die guten Nachrichten. Die schlechten Nachrichten sind, dass die meisten dieser Titel nach einem von zwei möglichen Ansätzen arbeiten: Entweder betrachten sie Scripting weiterhin als Werkzeug für Webentwickler, oder sie konzentrieren sich fast ausschließlich auf VBScript und WSH. Natürlich sind VBScript und WSH wichtige Scripting-Technologien, aber für sich alleine sind dieses beiden Technologien nicht in der Lage, sehr viele nützliche Administrationsaufgaben zu erledigen. Von den 339 gefunden Scripting-Büchern behandelten nur eine Handvoll Scripting als Administrationswerkzeug, und nur einige von diesen deckten die Schlüsseltechnologien - WMI und ADSI - umfassend ab. Ein Systemadministrator, der sich ein oder zwei zufällige Scripting-Bücher anschaut, wird wahrscheinlich nicht erkennen, dass Scripting zur Verwaltung von Windows-basierten Computern extrem nützlich sein kann.

Zum Seitenanfang

Über dieses Buch

Ist das Microsoft Windows 2000 - Scripting-Handbuch also nur Buch Nummer 340, oder unterscheidet es sich irgendwie von seinen Vorgängern? Dieses Buch stellt in vielerlei Art einen neuen Ansatz zum Scripting für die Systemadministration dar. Tatsächlich gibt es vier eindeutige Punkte, durch die dieses Buch sich von vielen anderen Büchern auf dem Markt unterscheidet:

• Es konzentriert sich auf Scripting aus der Sicht eines Systemadministrators. In diesem Buch finden Sie viele Kapitel, die es auch in anderen Scripting-Büchern gibt; Es gibt zum Beispiel ein Kapitel über VBScript. Der Unterschied besteht darin, dass sich das Kapitel in diesem Buch auf die VBScript-Elemente konzentriert, die für Systemadministratoren wichtig sind. Systemadministratoren müssen viel mit COM arbeiten - daher erfahren Sie eine Menge über die Verwendung von COM-Objekten in einem Script. Systemadministratoren haben aber zum Beispiel wenig Verwendung für die Berechnung von Kosinus-Werten. Daher werden solche Themen gar nicht angesprochen - auch wenn es möglich ist, solche Berechungen mit VBScript durchzuführen.
• Dieses Buch ist aufgabenorientiert und nicht scriptbezogen. In vielen Fällen wurden die Scripte in diesem Buch nachträglich erstellt. Manchmal erstellt ein Buchautor eine Menge Scripte und produziert dann einen Text um diese Scripte herum. Diese Buch verwendet einen ganz anderen Ansatz: Statt mit Scripten zu beginnen, stellen die Autoren erst einmal fest, welche Schlüsselaufgaben täglich von einem Systemadministrator erledig werden müssen. Erst dann stellen wir fest, wie diese Aufgaben über Scripte erledig werden können. Daher ist dieses Buch nicht unbedingt ein Buch über Scripting, sondern ein Buch über die effiziente Verwaltung von Windows-Computern.
• In diesem Buch werden Tutorials mit praktischen Elementen kombiniert. Einige Bücher versuchen, Ihnen Scripting beizubringen - daher konzentrieren sie sich eher auf die Konzepte hinter Scripting. Oft beschränkt sich der praktische Teil auf reine Lippenbekenntnisse. Andere Bücher verfolgen einen komplett anderen Ansatz: Sie konzentrieren sich auf den praktischen Teil. Diese Bücher stellen Ihnen eine Menge nützlicher Scripte zur Verfügung, helfen Ihnen aber nicht dabei diese Scripte auch zu verstehen. Sie sind also nicht in der Lage, die Scripte zu verändern. In dem vorliegenden Buch versuchen wir das Beste aus beiden Ansätzen zu kombinieren. Wenn zum Beispiel ein nützliches Script zur Systemadministration präsentiert wird, dann wird dieses Script auch Schritt für Schritt erklärt. Sie erfahren, wie dieses Script arbeitet und wie Sie es an Ihre persönlichen Bedürfnisse anpassen können.
• Dieses Buch berücksichtigt, dass mit der Größe einer Organisation auch der Bedarf an der Automatisierung von Prozessen wächst. Die Scripte in diesem Buch können sogar dann für Sie von Nutzen sein, wenn Sie Systemadministrator in einer Organisation mit nur einem Computer sind. Um ehrlich zu sein, werden Sie es aber wohl einfacher finden, Ihren einzelnen Computer über die Benutzeroberfläche zu verwalten. Wenn Sie 100 oder 1000 Computer verwalten, dann wird der Nutzen von Scripten und Scripting jedoch auf einmal dramatisch ansteigen. Um dies zu berücksichtigen, gibt es in diesem Buch extra ein eigenes Kapitel - Creating Enterprise Scripts - in dem besprochen wird, wie Sie die Beispiele für eine Organisation mit vielen Computern anpassen können.

Zum Seitenanfang

Woher weiß ich, ob das Buch für mich geeignet ist?

Offiziell wurde dieses Buch für Systemadministratoren in mittleren bis großen Organisationen geschrieben, die sich mit der Verwaltung von Windows-Computern beschäftigen. Diese Gruppe wird wahrscheinlich den Großteil der Leser darstellen, ganz einfach, weil sich das Buch mit der Systemadministration beschäftigt und weil Systemadministratoren in mittleren und großen Organisationen die Personen sind, die die gezeigten Scripte nutzen.

Das Buch sollte jedoch auch für alle Anderen nützlich sein, die das Entwickeln von Scripten lernen möchten. Obwohl sich die in diesem Buch besprochenen Techniken auf mittlere bis große Organisationen konzentrieren, können Sie in den meisten Fällen auch in kleinen Organisationen effektiv eingesetzt werden. Bei diesen Techniken handelt es sich typischerweise um administrative Aufgaben, sie können jedoch auch von Anwendungsprogrammierern und Web-Entwicklern umgesetzt werden. Die Verwaltung von Microsoft Exchange Server über Scripting wird in diesem Buch nicht besprochen; Microsoft Exchange Server kann allerdings über WMI verwaltet werden. Daher könnte für Exchange-Administratoren nicht nur das Kapitel WMI Scripting interessant sein, sondern auch das Kapitel VBScript - in diesem werden grundlegende Techniken zur Arbeit mit Automatisationsobjekten besprochen.

Auch Personen, die bereits über unterschiedliche Erfahrungsstufen im Scripting-Bereich verfügen, werden das Buch nützlich finden. Es wird jedoch keinerlei Erfahrung im Scripting-Bereich vorausgesetzt. Wenn Sie das Buch von Anfang bis Ende durchlesen, werden Sie mit den fundamentalen Grundlagen des Scripting beginnen und sich dann zu den komplexeren Szenarien hocharbeiten. Was ist, wenn Sie sich bereits mit VBScript auskennen, jedoch nicht viel über ADSI wissen? Springen Sie direkt zum Kapitel ADSI-Scripting. Sie kennen die grundlegenden Prinzipien von WMI, möchten aber wissen, wie Sie über WMI Prozesse erstellen und beenden? Springen Sie direkt zum Abschnitt Processes.

In diesem Buch gibt es für jeden interessante Informationen. Es wird kein Wissen vorausgesetzt. Dies heißt jedoch nicht, dass nicht gelegentlich eine Aufgabe oder eine Technik besprochen wird, die fortgeschrittene Kenntnisse erfordern.

Zum Seitenanfang

Aufbau des Buches

Das Microsoft Windows 2000 - Scripting-Handbuch ist in drei Teile aufgeteilt:

• Konzeptuelle Kapitel. Diese Kapitel geben Ihnen einen umfassenden Überblick zu den primären Microsoft-Scripting-Technologien, inklusive Windows Script Host (WSH), VBScript, WMI, ADSI und der Script-Laufzeitbibliothek (Runtime library). Die Kapitel haben Tutorial-Charakter, und sind alle vom Standpunkt eines Systemadministrators aus geschrieben. Sie gehen alle davon aus, dass der Leser über keine oder nur geringe Erfahrung mit Scripting verfügt.
• Aufgabenbasierte Kapitel. In diesem Kapitel werden die Kernbereiche der Systemadministration identifiziert, inklusive solcher Dinge, wie dem Verwalten von Diensten, Druckern und Ereignisprotokollen. Für jeden Kernbereich werden ca. 25 häufige Aufgaben identifiziert, zum Beispiel das Starten und Anhalten von Diensten, die Änderung von Dienstkonten-Passwörtern und das Feststellen der ausgeführten Dienste. Zu jeder Aufgabe erhalten Sie eine genaue Beschreibung der Aufgabe und warum diese wichtig ist, ein Beispielscript, das diese Aufgabe ausführt, und eine Schritt-für-Schritt-Anleitung zur Arbeitsweise des Scriptes. Außerdem erfahren Sie, wie Sie das Script an Ihre eigenen Bedürfnisse anpassen können.
• Unternehmens-Kapitel. Diese Kapitel decken einen großen Themenbereich ab, inklusive der Einrichtung einer Scripting-Infrastruktur und der Scripterstellung in einem administrativen Team. Außerdem erfahren Sie mehr dazu, wie Sie ein Script in ein Unternehmens-Script umwandeln können - zum Beispiel ein Script, dass eine bestimmte Aktion auf allen Domänencontrollern oder für alle Benutzerkonten ausführt, oder ein Script, das Argumente aus einer Textdatei oder Datenbank entgegennimmt.

Sie müssen nicht auf Seite Eins beginnen und das gesamte Buch bis zu Ende durchlesen. Es ist so gestaltet, dass Sie die Möglichkeit haben, nur die Teile zu lesen, die Sie interessieren. Wenn Sie jedoch noch nicht über Erfahrung im Scripting-Bereich verfügen, dann sollten Sie als Erstes die Kapitel über VBScript und WMI lesen.

Wenn Sie sich mehr für die Verwendung von Scripten als für deren Entwicklung interessieren, dann können Sie mit den aufgabenbasierten Kapiteln beginnen. Lesen Sie ein Kapitel, kopieren Sie die Scripte und führen Sie diese aus, um zu sehen, was passiert. Wenn Sie genauer verstehen möchten, wie diese Scripte arbeiten, dann springen Sie zu den konzeptionellen Kapiteln zurück.

Die in diesem Buch verwendeten Scripte

Die meisten Personen, die eine Vorab-Kopie dieses Buches gesehen haben, stellten überrascht - und dankbar - fest, dass die Scripte sehr kurz sind. Viele hatten Scripting-Bücher gelesen, in denen die Beispielscripte über zwei oder drei Seiten gingen, und waren überrascht, dass Scripting so einfach sein kann.

Es gab allerdings auch Personen, die darüber schockiert waren, dass die Scripte so einfach gehalten sind. Nur sehr wenige der Beispielscripte verwenden zum Beispiel eine Fehlerbehandlung. Warum verwenden wir also keine Beispielscripte, wie sie auch in einer echten Produktionsumgebung vorkommen würden?

Die Antwort ist einfach: Die Scripte aus diesem Buch sind nicht für eine Verwendung in einem Produktionssystem vorgesehen. Stattdessen sind sie zu Lernzwecken gedacht. Sie sollen Ihnen zeigen, wie Sie mit den unterschiedlichen Scripting-Technologien und -Techniken umgehen. Die meisten der Scripte können zwar durchaus zur Systemadministration verwendet werden, dabei handelt es sich aber eher um einen glücklichen Zufall; dieses Buch und die enthaltenen Scripte wurden entwickelt, um Ihnen das Schreiben von Scripten beizubringen. Sie selbst sind nicht zu Verwaltung gedacht.

Wo lassen sich die fehlenden Teile finden?

Nur weil die Scripte einfach gehalten wurden, heißt das nicht, dass Konzepte, wie zum Beispiel die Fehlerbehandlung oder die Verarbeitung von Parametern, ignoriert werden. Solche Techniken werden in den Kapiteln Creating Enterprise Scripts und Scripting Guidelines dieses Buches besprochen. Auch wenn Sie in diesem Buch keine Fünfhundert-Zeilen-Scripte finden, die jede nur denkbare Scripting-Technik verwenden, werden doch alle diese Techniken irgendwo in diesem Buch beschrieben. Indem solche Dinge wie eine Fehlerbehandlung weggelassen werden, werden die Scripte aus diesem Buch so kurz wie möglich. Sie konzentrieren sich auf die jeweilige Aufgabe. Nehmen wir zum Beispiel einmal das erste Script aus diesem Kapitel, das zum Mappen eines Netzlaufwerkes verwendet wird:

Set objNetwork = CreateObject("WScript.Network")
objNetwork.MapNetworkDrive "X:", "\\atl-fs-01\public"

Dieses Script ist so einfach gehalten, wie nur möglich. Sie brauchen es nicht lange studieren, bevor Sie sagen können: 'Oh, so werden also Netzlaufwerke über ein Script gemappt". In einer Produktionsumgebung werden Sie das Script zugegebenermaßen anpassen wollen. Zum Beispiel so, dass der Benutzer einen Laufwerksbuchstaben und eine Freigabe angeben kann. Dies ist kein Problem, Sie benötigen jedoch einigen zusätzlichen Script-Code. So würde aus einem einfachen zweizeiligen Script ein Script mit mindestens 22 Zeilen. Die Grundidee - ein einfache Script, das das Mappen von Laufwerken demonstriert - wäre so verloren.

Ein Hinweis zu VBScript

Alle Scripte in diesem Buch sind in VBScript geschrieben. Die Einscheidung für VBScript und gegen andere Scriptsprachen wurde aufgrund von drei Faktoren getroffen:

• Mit Ausnahme von Perl, ist VBScript die populärste Scriptsprache zur Erstellung von administrativen Scripten. Es macht Sinn, eine Sprache auszuwählen, mit der die Leser bereits möglichst vertraut sind.
• Im Gegensatz zu Perl wird VBScript auf allen Windows 2000-Computern automatisch installiert (Jscript übrigens auch). Daher sind mit VBScript keine Anschaffungen oder Installationen notwendig.
• VBScript ist einfacher zu lernen als Jscript. Als kleiner Bonus ist VBScript Visual Basics sehr ähnlich. Visual Basic ist eine Programmiersprache, mit der einige Systemadministratoren möglicherweise bereits erste Erfahrungen gesammelt haben.

In anderen Worten: VBScript ist einfach zu verwenden, erfordert keine zusätzlichen Investitionen und es muss nichts heruntergeladen oder installiert werden.

Um ehrlich zu sein, ist in vielen Fällen die verwendete Scriptsprache irrelevant. VBScript selbst bietet relativ wenig Unterstützung zur Systemadministration. Es bietet die meisten Möglichkeiten, wenn es mit WSH, WMI, ADSI und anderen Scripting-Technologien eingesetzt wird. Hier unterscheidet sich VBScript nicht von anderen Scriptsprachen. Der allergrößte Teil der Scripte aus diesem Buch verwendet WMI oder ADSI - die Scriptsprache ist hier eigentlich irrelevant. Möchten Sie lieber mit JScript oder ActiveState ActivePerl arbeiten? Kein Problem - alles, was Sie lernen müssen, ist, wie Sie sich mit diesen Sprachen mit WMI oder ADSI verbinden.

Das nächste Script ist ein WMI-Script. Es fragt den Namen des installierten BIOS ab, und zeigt diesen an. Das Script ist in VBScript geschrieben.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\ " _
    & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery _
    ("Select * from Win32_BIOS")
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next

Das nächste Script entspricht dem vorherigen. Es ist nur in JScript geschrieben. Wie Sie sehen können, sind Syntax und Sprachkonventionen unterschiedlich, aber die Schlüsselelemente (fett dargestellt) bleiben gleich - Verbinden mit WMI, Abfragen der Informationen über die Klasse Win32_BIOS, Ausgabe des BIOS-Namens. Sie sehen also, die Auswahl der Sprache ist mehr eine Frage des persönlichen Geschmacks.

var strComputer = ".";
var objWMIService = GetObject("winmgmts:\\\\ " +
    strComputer + "\\root\\cimv2");
var colItems = objWMIService.ExecQuery
    ("Select * from Win32_BIOS");
var e = new Enumerator(colItems);
for (;!e.atEnd();e.moveNext()) { var objItem = e.item();
WScript.Echo(objItem.Name);
}

Anmerkung:

• In der Realität gibt es einige kleine Unterschiede zwischen den Scriptsprachen. Diese wirken sich auf das aus, was Sie mit den Scripten durchführen können oder nicht durchführen können. Diese Unterschiede sind jedoch nicht wirklich einer Diskussion wert.

Zum Seitenanfang

Systemanforderungen

Dieses Buch setzt Computer voraus, die unter einem der Microsoft® Windows® 2000-Betriebssysteme oder höher ausgeführt werden. Zusätzlich zu Windows 2000 sollte die Windows Script Host-Version 5.6 installiert werden. Diese wurde nach Windows 2000 veröffentlicht. Einige Scripte dieses Buches benötigen Features der Version 5.6. Weitere Informationen zur Version 5.6 des WSH finden Sie im Kapitel DerWSH dieses Buches.

Anmerkung:

• Wenn Sie nicht die Version 5.6 des WSH installiert haben, finden Sie die Installationsdateien unter https://www.microsoft.com/windows/reskits/webresources. Wenn Sie nicht sicher sind, welche Version installiert ist, dann finden Sie weitere Informationen im Kapitel Der WSH.

Wenn Sie mit mehreren Betriebssystemen arbeiten - zum Beispiel Windows 2000 und Windows XP - sollten Sie außerdem Windows 2000 Service Pack 2 installieren. Ohne dieses Server Pack könnten Scripte unter Windows 2000 keine Informationen von Windows XP-Computern abfragen.

Außerdem ist es für die meisten der Scripte erforderlich, dass Sie mit administrativen Rechten angemeldet sind - zum Beispiel für die meisten WMI- und ADSI-Scripte. Wenn Sie mit einem Script einen Remotecomputer abfragen möchten, dann benötigen Sie auch auf diesem administrative Rechte.

Außer diesen Voraussetzungen benötigen Sie keine phantasievollen Scripting-Tools, Editoren oder Entwicklungsumgebungen (IDE - Integrated Development Environment). Wenn Sie Notepad installiert haben, dann reicht dies schon aus, um Scripte zu schreiben.

Zum Seitenanfang

| Home | Technische Artikel | Community