Zahlreiche Aufgaben, die Sie mit dem Windows Server 2003 erledigen, erfolgen automatisch. Dazu gehört zum Beispiel das automatisierte Verteilen von IP-Adressen, Gateway-Adressen und DNS-Server-Adressen mit Hilfe der DHCP-Server-Komponente. Andere Aufgaben werden von Diensten ganz automatisch erledigt. Dazu zählt zum Beispiel der Dienst für Volumenschattenkopien, der Dienst für die Dateireplikation oder der Dienst für das verteilte Dateisystem. All diese Dienste müssen Sie im Wesentlichen starten und konfigurieren, danach läuft der Rest der Arbeit ganz von alleine ab.
Natürlich gibt es Aufgaben, für die es keine eigenen Dienste gibt. Wollen Sie beispielsweise ein Mal am Tag ein Backup über das Netzwerk starten oder eine bestimmte Datei anlegen, löschen oder kopieren, dann gibt es dafür keinen "fertigen" Dienst. Windows bringt zwar die grundlegenden Fähigkeiten für die benötigten Aufgaben mit, hat aber keine fertigen Programme dafür. In solch einem Fall ist der Administrator gefragt und muss selbst Hand anlegen.
Arbeiten automatisch ablaufen lassen
Um einen Vorgang automatisch ablaufen zu lassen, muss der Administrator diesen Vorgang natürlich spezifizieren. Das kann im einfachsten Fall der Start eines einzelnen Programms sein. In aufwendigeren Fällen sind mehrere Prozesse hintereinander zu starten oder der Administrator muss tatsächlich Programmlogik in Form eines Scripts zusammenbauen.
Dazu stehen Ihnen unter dem Windows Server 2003 mehrere Möglichkeiten zur Verfügung. Im einfachsten Fall verwenden Sie den Windows 2003 Kommandointerpreter CMD.EXE. Mit dem Kommandointerpreter schreiben Sie Batch-Programme, die im Wesentlichen genauso aussehen, wie Batches auch unter MS-DOS aussahen. Im Vergleich zum MS-DOS Kommandointerpreter beherrscht CMD.EXE zwar einige ganz nette Tricks, ist aber letztlich nur für sehr einfache Aufgaben zu gebrauchen. Wenn Sie nur eine Datei kopieren, löschen oder anlegen wollen, dann sind Sie mit der Kommandozeile gut bedient. Wird die Sache komplizierter, reichen deren Fähigkeiten einfach nicht aus.
In einem solchen Fall greifen Sie auf den Windows Scripting Host (WSH) zurück. Diesen gibt es in zwei Geschmacksrichtungen, die sich nicht stark voneinander unterscheiden: script.exe ist rein für die Kommandozeile gedacht, wscript.exe zeigt dagegen seine Meldungen mit Dialogboxen an.
Im Gegensatz zu den einfachen Batches können WSH-Programme durchaus den Umfang kompletter Anwendungen annehmen, mit Hilfe von etwas HTML können Sie sogar komplette eigene grafische Oberflächen damit stricken.
WSH-Objekte
Von Haus aus bietet der WSH Zugriff auf einen Satz von Objekten, mit denen Sie relativ einfach in das System eingreifen können. So ist es möglich, dass Sie mit diesen Objekten zum Beispiel Dateien kopieren oder löschen, Textdateien schreiben und auf den Inhalt der Registry zugreifen. Auch Anwendungen, die per Script steuerbar sind, wie beispielsweise Microsoft Office, lassen sich mit dem WSH von außen automatisieren.
So kann man per Script auch direkt auf das Active Directory zugreifen. Wenn Sie beispielsweise die Liste aller Computer in Ihrem Active Directory benötigen, weil für jeden Computer eine bestimmte Aufgabe erledigt werden soll, verwenden Sie doch einfach das folgende kurze Beispiel, um die Computernamen zu ermitteln:
Const ADS_SCOPE_SUBTREE = 2
Set objConnection = CreateObject("ADODB.Connection")
Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCOmmand.ActiveConnection = objConnection
objCommand.CommandText = "Select Name from 'LDAP://DC=MUC, DC=local' Where objectClass='computer'"
objCommand.Properties("Page Size") = 100
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
Set objRecordSet = objCommand.Execute
objRecordSet.MoveFirst
Do Until objRecordSet.EOF Wscript.Echo "Computer: " & objRecordSet.Fields("Name").Value objRecordSet.MoveNext
Loop
Computer im Active Directory ermitteln
Das Active Directory verhält sich für ein Script einfach wie eine Datenbank, und so brauchen Sie für die Abfrage auch eine Datenbankverbindung. Im Beispiel-Script handelt es sich dabei um das Objekt "objConnection", das in den ersten Zeilen des Scripts erzeugt und konfiguriert wird.
Für die Abfrage selbst benötigen Sie ein Kommando-Objekt, im Script ist das "objCommand". Dem Kommando-Objekt übergeben Sie einen SQL-ähnlichen Abfrage-String. Dieser enthält die zu befragende Domäne (hier MUC.local), die zu erfragenden Eigenschaften (hier der "Name") sowie eine Filterbedingung, mit der Sie die eigentlich gesuchten Informationen auswählen: Hier geht es beispielsweise darum, alle AD-Objekte der Klasse "Computer" zu finden.
Diese Abfrage produziert Ihnen einen Satz an Ergebnissen, über die Sie mit einer Schleife iterieren können. Im Beispiel wird dann in der Schleife der Name des Computers ausgegeben.
Zugriff auf WMI
Wie Sie sehen, ist der Scripting Host durch den Zugriff auf andere Objekte im System sehr mächtig. Es wird aber noch besser, denn der WSH hat auch Zugriff auf ein anderes, für Administratoren wichtiges Element: WMI -Windows Management Instrumentation. Bei WMI handelt es sich um eine Sammlung von Objekten und Funktionen, die speziell für die Verwaltung des Systems geschaffen wurden. Unter anderem ermitteln Sie mit WMI praktisch alle Informationen, die überhaupt über Ihr System ermittelbar sind.
Auch hier gibt es eine einfache, SQL-ähnliche Abfragesprache. Das zweite Beispiel-Script demonstriert das Auslesen des Ereignisprotokolls mit Hilfe von WMI:
strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colLoggedEvents = objWMIService.ExecQuery ("Select * from Win32_NTLogEvent Where Logfile = 'Application'")
For Each objEvent in colLoggedEvents
Wscript.Echo "Category: " & objEvent.Category
Wscript.Echo "Computer Name: " & objEvent.ComputerName
Wscript.Echo "Event Code: " & objEvent.EventCode
Wscript.Echo "Message: " & objEvent.Message
Wscript.Echo "Record Number: " & objEvent.RecordNumber
Wscript.Echo "Source Name: " & objEvent.SourceName
Wscript.Echo "Time Written: " & objEvent.TimeWritten
Wscript.Echo "Event Type: " & objEvent.Type
Wscript.Echo "User: " & objEvent.User
Next
Und zu guter Letzt gibt es noch das echte Power-Werkzeug für das Schreiben von administrativen Scripts: Microsofts Monad, das wir in einem separaten Beitrag auf tecChannel.de behandeln.
Zeitgesteuerte Prozesse startet der Taskplaner
Wie auch immer Sie Ihre Prozessabläufe beschreiben: Damit diese automatisch ablaufen können, brauchen Sie eine Möglichkeit, Ihre Programme zum gewünschten Zeitpunkt zu starten. Im einfachsten Fall ist das der Zeitpunkt, an dem sich ein Benutzer am System anmeldet. Für diesen Fall sieht Windows nämlich von Haus aus vor, dass ein Anmelde-Script gestartet werden kann. Mit einem Anmelde-Script lassen sich dann zum Beispiel die vom angemeldeten Benutzer benötigten Laufwerke mappen.
Das reicht natürlich nicht aus. Für viele Aufgaben benötigen Sie eine Möglichkeit, Prozesse zu starten, ganz ohne dass eine Person am System angemeldet ist. Schließlich soll die Arbeit ja automatisch, also ohne Eingriff erledigt werden.
Dafür bietet Windows den Taskplaner-Dienst. Welche Prozesse der Dienst wann und wie starten soll, teilen Sie ihm mit Hilfe der Systemsteuerung mit. Dort finden Sie das Icon "Geplante Tasks", mit dem Sie vorhandene Aufgaben bearbeiten oder neue anlegen.
Beim Einrichten einer neuen Aufgabe wählen Sie zunächst das Programm aus, das automatisch ausgeführt werden soll. Windows bietet dazu eine Liste der installierten Programme an, aber das eigene Script befindet sich natürlich nicht in der Liste. Sie müssen also den Pfad zu diesem Script selbst angeben. Danach können Sie einen Namen für die Aufgabe festlegen und zunächst ein einfaches Intervall auswählen. Windows bietet "tägliche", "wöchentliche" und ähnliche Intervalle an. Wenn Sie das Intervall festgelegt haben, geben Sie noch einen zum Intervall passenden Zeitpunkt an.
Danach kommt der eigentlich wichtige Teil: Sie müssen einen Benutzer-Account angeben, mit dessen Rechten das Programm ausgeführt werden soll. Wenn die Ausführung fehlschlägt, dann liegt das fast immer daran, dass der verwendete Account schlicht und ergreifend nicht die notwendigen Rechte hat, um die Aufgabe auszuführen.
Automatische Server-Überwachung mit Perfmon
Für das Überwachen Ihres Systems bietet der Windows Server schon immer den Performance-Monitor. Oft übersehen wird allerdings die Tatsache, dass Sie mit Hilfe des Performance-Monitors die Überwachung auch automatisieren können. Dazu öffnen Sie im Konsolenstamm des Performance-Monitors den Ast "Leistungsprotokolle und Warnungen". Darin finden Sie den Ast "Warnungen", in dem Sie neue Objekte anlegen.
Der Performance-Monitor kann eine ganze Reihe an Werten überwachen, die eine Aussage über den Zustand des Systems zulassen. Interessant ist zum Beispiel die Auslastung der CPU oder auch der verbrauchte oder noch zur Verfügung stehende Plattenplatz.
Mit Hilfe einer Warnung weisen Sie Perfmon an, einen oder mehrere solcher Werte zu überwachen und bei Eintreten einer bestimmten Bedingung eine Benachrichtigung einzuleiten. Mit anderen Worten: Perfmon kann Sie darüber informieren, wenn die Festplatte bedrohlich voll wird.
Perfmon als Warnmelder
Die Benachrichtigung erfolgt von Haus aus per Eintrag im Ereignisprotokoll. Das ist natürlich nicht besonders hilfreich, insbesondere dann nicht, wenn das Ereignisprotokoll übers Netzwerk nicht eingesehen werden kann. Wenn Sie sich nämlich erst am System anmelden müssen, um einen Blick ins Protokoll zu werfen, dann können Sie stattdessen auch einfach nachsehen, wie voll die Platte ist.
Statt einen Eintrag im Ereignisprotokoll zu hinterlassen, kann Perfmon aber auch ein externes Programm starten. Diesem Programm übergibt Perfmon außerdem einen von Ihnen festgelegten Parameter, zum Beispiel den Text "Die CPU-Auslastung ist zu hoch".
Welches Programm aufgerufen wird, können Sie selbst bestimmen. Das wiederum bedeutet, dass Sie auch ein Programm verwenden können, das E-Mails versendet. Kurz gesagt: Perfmon kann Sie per E-Mail benachrichtigen, wenn die Leistungsdaten (oder sonstige vom Performance Monitor überwachbare Zähler) bedenkliche Werte erreichen.
E-Mails per Kommandozeile
Dazu benötigen Sie allerdings ein Programm, das per Kommandozeile E-Mails versendet. Nun kann der Windows Server zwar prima mit SMTP umgehen, nur bietet er leider kein fertiges Programm zum Versand vom E-Mails von der Kommandozeile. Das ist jedoch nicht besonders schlimm, weil der Zugriff auf SMTP auch per Script funktioniert. Ein Beispiel-Script zum Versenden von E-Mails finden Sie zum Beispiel bei Microsoft:
' Emails über den lokalen SMTP-Dienst mittels CDONTS verschicken
' Benutzung:
' sendmail -t <an> -f <von> -s "<betreff>" -b "<nachricht>"
' sendmail [-help|-?]
Option Explicit
On Error Resume Next
Dim objSendMail, oArgs, ArgNum
Dim strTo, strFrom, strSubject, strBody
Set oArgs = WScript.Arguments
ArgNum = 0
While ArgNum < oArgs.Count
Select Case LCase(oArgs(ArgNum))
Case "-to","-t":
ArgNum = ArgNum + 1
strTo = oArgs(ArgNum)
Case "-from","-f":
ArgNum = ArgNum + 1
strFrom = oArgs(ArgNum)
Case "-subject","-s":
ArgNum = ArgNum + 1
strSubject = oArgs(ArgNum)
Case "-body","-b":
ArgNum = ArgNum + 1
strBody = oArgs(ArgNum)
Case "-help","-?":
Call DisplayUsage
Case Else:
Call DisplayUsage
End Select
ArgNum = ArgNum + 1
Wend
If oArgs.Count=0 Or strTo="" Or strFrom="" Or strSubject="" Or strBody="" Then Call DisplayUsage
Else
Set objSendMail = CreateObject("CDONTS.NewMail")
objSendMail.From = strFrom
objSendMail.To = strTo
objSendMail.Subject = strSubject
objSendMail.Body = strBody
objSendMail.Send
Set objSendMail = Nothing
End If
Sub DisplayUsage
WScript.Echo "Benutzung:"
WScript.Echo "sendmail -t <an> -f <von> -s " & Chr(34) & "<betreff>" & Chr(34) & " -b " & Chr(34) & "<nachricht>" & Chr(34)
WScript.Echo "sendmail [-help|-?]"
WScript.Echo ""
WScript.Quit End Sub
Automatisch auf Ereignisse reagieren
Anders als der Performance Monitor erlauben viele Systemkomponenten nicht die Konfiguration externer Programme, mit denen man auf Ereignisse automatisiert reagieren könnte. Stattdessen findet sich lediglich ein Hinweis im Eventlog von Windows, dass irgendetwas Ungewöhnliches passiert ist.
Genau hier setzt das Tool eventtriggers.exe an, das von vielen Anwendern und Administratoren völlig unbemerkt sein Dasein im Windows-Verzeichnis fristet. Im Prinzip ist das lediglich ein Frontend, das im System einer Event-ID ein auszuführendes Programm zuweist. Tritt nun ein Event mit der spezifizierten ID auf, startet Windows das konfigurierte Programm.
Eventtrigger nutzen
Die grundsätzliche Syntax von eventtriggers.exe ist:
eventtriggers /create /tr "Name des Triggers" /l "Ereignisprotokoll" /eid "Event-ID" /tk "Programm"
Beim Parameter /tr können Sie einen aussagekräftigen Namen vergeben, damit Sie sich später in der Liste Ihrer Eventtrigger noch zurechtfinden. Ansonsten hat dieser Parameter keine Bedeutung.
Mit /l spezifizieren Sie das zu überwachende Protokoll. Geben Sie APPLICATION für das Anwendungsprotokoll, SYSTEM für das Systemprotokoll oder SECURITY für das Sicherheitsprotokoll an.
Der Parameter /eid selektiert die zu überwachende Event-ID. Werfen Sie am besten einen Blick in das Ereignisprotokoll, um die richtige ID zu ermitteln.
Und via /tk legen Sie letztlich fest, welches Programm ausgeführt werden soll, wenn das Event auftritt.
eventtriggers /create /tr "Demonstration" /l APPLICATION /eid 100 /tk "msg mhartmann Test"
In diesem Beispiel erzeugen wir einen Trigger mit dem Namen Demonstration, der bei Auftreten des Events 100 im Anwendungsprotokoll per msg.exe eine Mitteilung an den Benutzer mhartmann schickt. Da es jetzt wenig sinnvoll ist, auf ein entsprechendes Event zu warten, erzeugen wir es kurzerhand über das Tool eventcreate:
eventcreate /T INFORMATION /SO Demo /ID 100 /L APPLICATION /D Test
Jetzt taucht beim Benutzer mhartmann eine entsprechende Nachricht per Pop-up auf. Genauso gut könnte man das vorher vorgestellte Script einsetzen, um eine automatisierte Mail zu versenden.
Ereignisse selektieren
Da verschiedene Anwendungen dieselben Event-IDs verwenden, lassen sich bei eventtriggers.exe zusätzliche Filterparameter angeben. Zwar behauptet die Online-Hilfe, diese Parameter seien nicht mit /eid kombinierbar, in der Praxis funktioniert das allerdings fehlerfrei.
Verwenden Sie den Parameter /t "Eintragstyp", um nur Einträge vom Typ ERROR, INFORMATION, WARNING, SUCCESSAUDIT oder FAILUREAUDIT zu selektieren.
Über /so "Quelle" können Sie die Auswahl auf Ereignisse von einer bestimmten Quelle beschränken. Von welchen Quellen die Einträge stammen, können Sie in der Ereignisanzeige einsehen. Beispielsweise sind Einträge, die das Starten oder Beenden von Diensten betreffen, meistens vom "Service Control Manager".
Zusätzlich unterstützt eventtriggers.exe noch weitere Parameter, die das Ausführen des konfigurierten Befehls unter anderen Anmeldeinformationen oder auf entfernten Rechnern ermöglichen. Weitere Informationen dazu erhalten Sie in der Online-Hilfe. (mha)