Scripting Tools für Windo ws-Admins

23.05.2006
Von Thomas Wölfer
Für die Automatisierung von administrativen Vorgängen kann man gar nicht genug Tools haben. Microsoft bietet eine erstaunlich große Anzahl von Helferlein für administrative Skripte an. Die wichtigsten lernen Sie in diesem Beitrag kennen.

Von Thomas Wölfer, tecChannel.de

Eine Skriptsprache für die schnelle Erstellung von einfachen Tools zu haben ist das eine. Ein anderes ist es aber, über entsprechende Tools zu verfügen, die das Erstellen von Skripten vereinfachen.

Gerade der Zugriff auf die Windows Management Instrumentation (WMI) stellt beispielsweise immer wieder ein Problem dar. Werden hier die Parameter nicht richtig gesetzt, kommt es zu falschen Ergebnissen. Aber auch das Debuggen fällt nicht gerade leicht, wenn man nur kryptische Fehlermeldungen auf der Konsole erhält und man dann händisch im Source nach der Ursache suchen muss.

Wir haben eine Reihe von Tools für Sie zusammengestellt, mit denen sich leicht Skripte erstellen und testen lassen.

WSH - Der Windows Scripting Host

Der "Windows Scripting Host" ist momentan das flexibelste Instrument, um Scripte für die Administration von Windows-Rechnern zu erstellen. Von Haus aus kann man mit dem WSH Skripte in VBscript und JavaScript programmieren. Wer andere Sprachen mag, kann aber auch diese verwenden. So gibt es bei ActiveState beispielsweise auch Implementierungen von Python und Perl für Windows.

Einige der anderen in diesem Beitrag erwähnten Tools setzen auf den WSH auf: So erzeugt das Programm Scriptomatic beispielsweise WMI-Scripte, die dann mit dem ScriptingHost ausgeführt werden.

Der Scripting Host selbst bietet im Wesentlichen die Möglichkeit, Skripte von der Kommandozeile aus auszuführen. Diese Skripte können dann auf Objekte zugreifen, die für Scripting exportiert wurden, und deren Funktionalität verwenden. So gibt es beispielsweise das "FileSystemObject", das direkt zum WSH gehört und elementare Operationen im Dateisystem erlaubt. Ebenso können aber auch Objekte von anderen Anwendungen verwendet werden - zum Beispiel die von Microsoft Office.

Editor für WSH

Neben dem Ausführen von Skripten bietet der Host aber wenige Möglichkeiten: Es gibt keine echte Entwicklungsumgebung oder auch nur einen Editor für Skripte. Dem kann aber abgeholfen werden. Im einfachsten Fall braucht der Admin also zumindest ein Werkzeug wie "Notepad2". Bei diesem Programm handelt es sich um einen Editor, der als Ersatz für Notepad dient und einige für Skripte wichtige und interessante Features bietet: In erster Linie ist das ein Syntax-Highlighting für verschiedenste Sprachen.

Besser als Notepad2 ist aber der "Script Debugger". Auch der bietet Syntax-Highlighting, kann aber noch wesentlich besser eingesetzt werden: nämlich als Single-Step Debugger für Skripte. Da Administratoren meist nicht über einen Hintergrund als Softwareentwickler verfügen, ist dieses Konzept vermutlich erklärungsbedürftig.

Script Debugger

Auch Skripte müssen natürlich getestet und auf Fehler untersucht werden. Der "klassische" Weg bei Scripten ist dabei der, das das Skript an verschiedenen Stellen Texte am Bildschirm ausgibt. Auf diese Weise kann der Admin erkennen, welche Stellen im Script bereits abgearbeitet sind, und was für Werte die verwendeten Variablen angenommen haben.

Das ist schön - aber extrem unhandlich. Und genau an dieser Stelle setzt der Script Debugger an. Mit diesem Programm lässt sich ein Script auch ausführen, dabei wird aber jede Skriptzeile einzeln nacheinander ausgeführt. Der Benutzer des Debuggers kann dabei per Mausklick Stellen im Skript festlegen, an denen die Ausführung angehalten werden soll. Befindet sich ein Skript im angehaltenen Zustand, kann der Admin die Inhalte von Variablen einsehen und bei Bedarf auch verändern. Auch andere Informationen über den Zustand des Skriptes stehen zur Verfügung - so zum Beispiel der Call-Stack, der Aufschluss darüber gibt, auf welchem Weg das Skript an die aktuelle Stelle gelangt ist.

Debugging

Sind die gewünschten Informationen abgelesen, kann das Skript weiter ausgeführt werden. Das Anhalten und Betrachten von Variablen-Inhalten findet dabei in einem Editor-Fenster innerhalb des Script Debuggers statt. Taucht ein Fehler auf, kann dieser also direkt im Debugger korrigiert werden - und der nächste Testlauf des Skriptes kann beginnen. Wer häufiger Scripte schreibt, der sollte auf dieses Tool auf keinen Fall verzichten.

Es gibt dabei allerdings eine kleine Einschränkung: Der Script Debugger ist eigentlich dafür gedacht, Web-Seiten zu debuggen. Um ein Skript zu debuggen, ist es also notwendig, das Script zunächst in einem Script-Block einer lokalen HTML-Seite unterzubringen. Diese Seite lädt man in den Internet Explorer - und der überträgt dann die Kontrolle an den Script Debugger, sobald ein Fehler aufgetreten ist (und das Script-Debugging in den Optionen des IE nicht ausgeschaltet ist) oder wenn ein passendes Statement im Script auftaucht. Bei JavaScript ist das beispielsweise das "debugger;"-Statement. Wem das zu umständlich ist, der kann zum Debuggen das "Visual Studio" verwenden: Der Visual Studio Debugger kann auch ganz normale Scripte debuggen.

Scriptomatic 2.0

Bei "Scriptomatic" handelt es sich um ein Werkzeug, das speziell für Skripte gedacht ist, die mit WMI-Objekten arbeiten. Mit WMI lassen sich alle Informationen über den lokalen Rechner (oder bei passenden Rechten auch über entfernte Rechner) ermitteln.

Das Problem mit WMI ist allerdings die etwas kryptische Schreibweise: Zunächst muss immer ein WMI-Namespace ausgewählt werden, dann erfolgt die Abfrage einer WMI-Klasse mit Hilfe von SQL-artigen Ausdrücken. So richtig gut dokumentiert sind WMI-Klassen im Allgemeinen nicht.

Hier kommt Scriptomatic ins Spiel. Das Programm verfügt über zwei Combo-Boxen. Mit der einen kann der Admin den WMI-Namespace auswählen, aus dem die gewünschte Klasse stammen soll. Man kann diese Combo-Box also als Browser über die verfügbaren WMI-Namespaces verstehen. Ist ein Namespace ausgewählt, dann füllt Scriptomatic die zweite Combo-Box mit allen WMI-Klassen dieses Namespaces auf. Diese Combo-Box ist also eigentlich ein Klassen-Browser für einen WMI-Namespace.

Automatische Skript-Erzeugung

Hat man eine Klasse ausgewählt, erzeugt Scriptomatic automatisch ein Skript, das über alle Instanzen der ausgewählten Klasse iteriert. Dabei werden alle Eigenschaften dieser Klasse zusammen mit dem aktuellen Wert der Eigenschaft ausgegeben. Wer mag, kann dabei auch eine Liste an Computern angeben - die Iteration erfolgt dann zusätzlich über alle angegebenen Computer.

Das Skript wird dabei in der vom Admin ausgewählten Sprache erzeugt. Zur Auswahl stehen VBScript, Perl, JScript und Python. Die Ausgabe des Skriptes landet dabei entweder auf der Kommandozeile oder in einer Datei als Text-, HTML, Excel oder im XML-Format.

Natürlich lassen sich die so erzeugten Skripte auch speichern. Der hauptsächliche Zweck von Scriptomatic ist allerdings der, dass erzeugter Code direkt aus dem Skriptfenster per Cut und Paste in das eigentliche Zielskript kopiert wird: Alle Eigenschaften eines WMI-Objektes werden den Admin nur selten interessieren - der Trick besteht also darin, dass einfach ein Script für alle Eigenschaften zur Verfügung gestellt wird, aus dem dann der wirklich benötigte Teil einfach herauskopiert werden kann.

WMI Code Creator

Beim "WMI Code Creator" handelt es sich eigentlich um den großen Bruder von Scriptomatic. Auch der WMI Code Creator kommt mit seinem eigenen Quellcode (als C# Programm) - und auch der WMI Code Creator dient der Arbeit mit WMI.

Dabei kann der Code Creator deutlich mehr als Scriptomatic - allerdings in anderen Sprachen, von denen einige nicht gängigerweise als Scriptsprachen eingesetzt werden. Das Programm erzeugt Code für VBScript, VB.Net oder C#.

Der Code-Creator verfügt über vier Reiter. Der erste der Reiter bietet dabei in etwa die gleiche Funktionalität wie Scriptomatic - den Zugriff auf Werte von WMI-Instanzen. Als Admin kann man dort einen Namespace und eine Klasse auswählen. Anders als bei Scriptomatic werden dann aber die einzelnen Eigenschaften der Klasse aufgelistet. Aus dieser Liste wählt man dann diejenigen Eigenschaften aus, die ausgelesen werden sollen. Das Skript wird dann nur für die ausgewählten Eigenschaften erzeugt. Zusätzlich ist es auf diesem Reiter möglich, die aktuellen Werte einfach direkt auszulesen und anzeigen zu lassen.

Methoden von WMI-Objekten aufrufen

Wirklich umfangreicher wird es dann auf dem zweiten Reiter. Was Scriptomatic nämlich nicht kann, der Code-Generator aber schon, ist der Aufruf von Methoden eines WMI-Objektes.

Das funktioniert ähnlich wie das Auslesen eines Wertes: Zunächst werden ein Namespace und eine Klasse ausgewählt. Der Code-Generator liefert dann eine Liste aller Methoden dieser Klasse. Aus dieser Liste wählen Sie dann eine Methode aus. Erwartet diese Methode Parameter, zeigt das Programm diese an, und Sie können für jeden Parameter einen Wert festlegen.

Benötigt man also zum Beispiel ein Script, um alle Print-Jobs auf einem Printserver zu verwerfen, so wählt man zunächst den passenden Namespace ("root\CIMV2"), dann die passende Klasse ("WIN32_Printer"), ferner die richtige Methode ("CancelAllJobs"). Ferner wählt man in diesem Fall noch die Instanz (also den Drucker) aus, auf den das Script angewendet werden soll - und der Code-Creator erzeugt dann ein passendes WMI-Script, mit dem die Aufgabe ausgeführt werden kann. Hier handelt es sich also tatsächlich um "Point und Click"-Programmierung.

WMI-Events

Der Code-Creator kann noch mehr: Er unterstützt auch WMI-Events. WMI-Events sind Ereignisse, die von WMI-Objekten ausgelöst werden. Über ein solches Event kann ein Skript eine Benachrichtigung erhalten und darauf reagieren. Diese Events werden auf dem dritten Reiter des Code-Creators unterstützt.

Auch hier ist zunächst ein Namespace auszuwählen. Statt dann aber alle Klassen des Namespace aufzulisten, listet der Code-Creator nur die Klassen auf, die von der Event-Klasse abgeleitet sind: Das sind diejenigen, die die eigentlichen Ereignisse darstellen. In dieser Liste der Ereignisse wählen Sie dann das gesuchte Ereignis aus - zum Beispiel die Erschaffung eines neuen Prozesses mit dem Win32_ProcessStartTace-Ereignis.

Das führt bereits dazu, dass passender Code generiert wird. Der generierte Skript-Code kann dabei entweder asynchron ablaufen oder nicht. Handelt es sich um synchronen Code, so wird ununterbrochen auf das Ereignis gewartet - der asynchrone Code hingegen überprüft nur, ob ein passendes Ereignis anliegt, und wird ansonsten in den Schlaf versetzt. Er verbraucht also deutlich weniger Rechenzeit der CPU.

Auf dem vierten Reiter bietet der Code-Creator noch einen "richtigen" WMI-Browser. Für jede WMI-Klasse können hier alle Eigenschaften und Methoden angezeigt werden - und für jede Klasse, jede Eigenschaft und jede Methode wird auch eine Beschreibung angezeigt. Man muss also nicht an der Bedeutung von CIM_BootService herumraten, sondern erhält eine Beschreibung in Klartext - allerdings auf Englisch.

ADSI Scriptomatic

"ADSI Scriptomatic" ist ein enger Verwandter von Scriptomatic - aber trotzdem recht unterschiedlich. Das Programm kommt wie auch die anderen bisher vorgestellten Tools mit Quellcode, und es erzeugt auch Skripte. Im Fall von ADSI Scriptomatic sind das VBScript-Scripte, die mit dem Active Directory Service Interface (ADSI) arbeiten. Das ADSI ist das Scripting-Interface fürs Active Directory. Damit kann der der Administrator zum Beispiel neue Gruppen oder User anlagen, oder vorhandene bearbeiten und aus dem Directory entfernen.

Anders als beim eigentlichen Scriptomatic kann man die von ADSI Scriptomatic erzeugten Skripte aber nicht direkt immer wieder weiterverwenden. Der Grund dafür ist der, dass ADSI Scriptomatic von sich aus keinerlei Informationen über das Active Directory hat. Das Programm sammelt diese zur Startzeit nicht ein. Daher verwendet ADSI Scriptomatic für viele Vorgänge Default-Werte. Wenn Sie zum Beispiel die Daten eines Benutzers auslesen wollen, dann verwendet ADSI Scriptomatic einfach den Namen "EzAdUser". Das ist in der Praxis natürlich nicht wirklich hilfreich.

Die erzeugten Skripte müssen also manuell an die tatsächlichen Belange angepasst werden. Das macht ADSI Scriptomatic allerdings relativ einfach. Für jedes erzeugte Skript gibt es eine kleine Online-Hilfe, die erläutert, welche Variablen im Skript an die tatsächlichen Bedürfnisse angepasst werden müssen.

Davon abgesehen ist das Programm auch eher als Lernhilfe für Administratoren gedacht, die per Skript mit dem Active Directory kommunizieren wollen: Längst nicht alle Objekte des AD sind mit den Skripten des ADSI Scriptomatic erreichbar. Allerdings: Das prinzipiell benötigte Vorgehen wird deutlich. Für Details wie etwa die Namen der anderen verfügbaren Objekte im Directory wendet man sich am besten an den ADSI Scripting Primer auf Technet.

Tweakomatic

Bei "Tweakomatic" handelt es sich um den großen Scripting-Bruder von TweakUI. Mit dem Programm kann ein Administator Skripte erzeugen, die die Einstellungen von Windows und dem Internet Explorer verändern. Die erzeugten Skripte schreiben also Werte in die Registry. Dabei lassen sich die erzeugten Skripte auch in einem Master-Skript zusammenfassen. Dieses Skript können Sie dann zum Beispiel als Logon-Script eintragen, um ein System für einen bestimmten Benutzer zu konfigurieren, oder Sie verwenden das Tool, um einfach den lokalen oder einen entfernten Rechner im LAN einzustellen.

Dazu wählen Sie aus der Liste die zu bearbeitende Komponente aus und dann die Kategorie, zu der die Einstellung gehört. Kategorien der Windows-Einstellungen sind zum Beispiel die Einstellungen für das Kommandozeilen-Fenster und auch Einstellungen für die Taskbar.

Danach zeigt Tweakomatic eine Liste möglicher Vorgänge an - zum Beispiel "Lock the Taskbar". Aus dieser Liste wählen Sie dann den gewünschten Vorgang aus - und das Programm erzeugt zwei Skripte. Das eine Script dient dem Setzen der zugehörigen Werte in der Registry, das andere liest die Werte aus der Registry aus.

Prinzipiell können die Einstellungsmöglichkeiten von Tweakomatic in einer AD-Domäne auch per Group Policy vorgenommen werden, aber in vielen Fällen - oder wenn man sich nicht innerhalb einer solchen Domäne befindet - ist die Verwendung des Skripts deutlich einfacher.

Log Parser

Beim "Log Parser" handelt es sich um ein sehr wertvolles Hilfsmittel für das Schreiben von Überwachungsscripten. Mit Hilfe des Programms können Sie diverse Datenquellen unter Windows mit Hilfe einer SQL-ähnlichen Sprache nach Informationen befragen. Als Datenquelle können dabei textbasierte Dateien wie Logfiles eines Servers, XML- und CSV-Dateien, aber auch das Event-Log, die Registry, das Active Directory oder das Dateisystem dienen.

Als Ausgabeformat bietet der Log Parser eine Vielzahl von Möglichkeiten: Neben XML, CSV und SQL stehen noch sieben weitere mögliche Formate zur Verfügung. Der Parser kann direkt innerhalb eines Skriptes verwendet werden, da er dafür ein COM-Objekt zur Verfügung stellt.

Fazit und Ausblick

Es muss nicht immer gleich eine komplette Anwendung sein, wenn man mal schnell ein paar Dinge automatisieren muss. Und es muss auch nicht immer gleich ein EXE sein. Für viele Aufgaben reichen ein paar schnell zusammengezimmerte Zeilen Code durchaus. Und vorgestellte Tools erleichtern derartige Aufgaben ungemein.

Aber die Zukunft hat schon begonnen: Mit der "Monad Shell" (MSH) möchte Microsoft Administratoren auch unter Windows eine Shell an die Hand geben, mit der sie ganz nach Herzenslust Skripts schreiben und ihr System kontrollieren können. Dabei verfolgt Monad ein von Grund auf anderes Konzept, als das bei textorientierten Shells wie der Bash oder auch Cmd.exe der Fall ist.

Monad arbeitet vollständig objektorientiert. Anders als bei üblichen Shells handelt es sich bei den Ergebnissen jedes Kommandos von Monad also nicht um einen Text, sondern um ein Objekt. Ähnlich wie bei bisher bekannten Shells gibt es allerdings eine Pipeline, in der die Resultate der einzelnen Befehle weitergereicht und weiterverarbeitet werden können. Nur sind die Eingabewerte sowie die Resultate eben Objekte und keine Texte.

Zur Startseite