Seminar: IT-Administration Windows-Scripting

Transkript

1 1 Seminar: IT-Administration Windows-Scripting Qian Xiong Alexander Fiebrich Philipps-University Marburg Fachbereich Mathematik und Informatik Abstract Diese Seminararbeit stellt verschiedene Konzepte der Automatisierung von systemadministrativen Aufgaben auf der Windowsplattform vor. Da dieses Thema sehr komplex ist, wird sich hierbei auf den Kommandozeileninterpreter cmd.exe, sowie auf die Scriptsprachen VBScript und die Windows PowerShell beschränkt. An verschiedenen Anwendungsbeispielen sollen die unterschiedlichen Prinzipien der Sprachen verglichen werden. Index Terms Scripting, cmd.exe, Component Object Model, Activ Scripting, Windows Script Host, vbscript,.net Framework, Windows PowerShell DOS-Kommandozeilenprogrammierung veröffentlicht. Der WSH ist Teil der sogenannten Active Scripting Achitektur, zu der Beispielsweise auch das Scripting im Internet Explorer. gehören. In Windows 7 ist der WSH in der Version 5.8 enthalten. Das neueste Lösungskonzept von Microsoft ist eine Adaption der Unix-Shells und heisst Windows PowerShell. Erstmals erschienen 2006 unter dem Namen Monad, für Windows XP [2], war im Standardinstallationsumfang von Windows XP jedoch noch nicht enthalten, sonder muss nachträglich installiert werden. I. EINLEITUNG In der Systemadministration ist der Automatisierungsbedarf sehr hoch. So gibt es beispielsweise Aufgaben, welche unbeaufsichtigt von statten gehen sollen (Überwachungsaufgaben oder sehr rechenintensive Prozesse, welche nur nachts laufen). zu einem regelmässigen Zeitpunkt immer wieder ausgeführt werden (Backup, Datenabgleich). zu einem bestimmten Zeitpunkt in grosser Menge auftreten (Benutzereinrichtung bei Systemumstellungen). individuelle Wunsche, an das Betriebssystem oder eine Anwendung, erfüllen sollen. Solche Aufgaben sollen üblicherweise durch ein Command Line Interface (CLI), nach Möglichkeit automatisiert, ausgeführt werden. In diesem Bereich war Windows im Vergleich zu Unix lange im Nachteil. Obwohl die Anforderungen stetig gestiegen sind, setzte Microsoft lange Zeit auf die DOS-Batchsprache und versuchte die mangelnden Fähigkeiten dieser Sprache durch Kommandozeilenwerkzeuge auszugleichen, während es in Unix längst schon mächtige Shells gab, wie etwa die Bourne-Shell (sh 1978), C-Shell (csh 1979) oder die Bourne-Again-Shell (bash 1987).[1] In diesen Shells können Scripte ausgeführt werden, die ihrerseits alle administrativen Aufgaben erfüllen können. Ende der Neunzigerjahre (1998) hat Microsoft mit dem Windows Script Host (WSH) eine Alternative zur II.LÖSUNGSANSÄTZE Microsoft bietet folgende Lösungsansätze für die Automatisierung administrativer Aufgaben: A. Die cmd.exe Seit Windows NT, ist die cmd.exe der Kommandozeileninterpreter von Windowssystemen. Die native Win32-Anwendung ist eine Erweiterung der command.com, dem Kommandozeileninterpreter von MS- DOS. Zahlreiche Kommandos und Funktionen wurden der cmd.exe hinzugefügt. Außerdem stehen dem Anwender noch weitere Programme in Form von Exe-Dateien oder Batch- Scripten zur Verfügung. Allerdings ist die DOS-Batchsprache ist keine vollständige Programmiersprache und daher sind viele Aufgaben nur umständlich umsetzbar. Die Kommunikation zwischen Befehlen ist textorientiert. Ein- und Ausgaben sind zeilenorientiert. Es gibt keine Möglichkeit Programmierschnittstellen (APIs) des Betriebssystems oder von Anwendungen anzusprechen. Zwar werden die Anforderungen der DOS-Ebene abgedeckt, auf viele GUI- Funktionen des Windows-Betriebssystem kann jedoch nicht zugegriffen werden.[3] Die cmd.exe unterstützt auch das Pipelineing, also den Ausgabestrom eines Programmes weiterzuleiten in den Eingabestrom eines anderen.

2 2 B. Active Scripting Grundlage der Windows Scripting Architektur, welche auch Active Scripting oder ActiveX Scripting genannt wird, ist Microsofts Componet Object Model (COM). Das COM dient der Entwicklung und Nutzung von objektorientierten Softwarekomponenten, den sogenannten COM-Komponenten. Zusammen mit den Active Scripting Hosts, die Ablaufumgebungen für Scripte, und den Achtive Scripting Engines, also den Sprachinterpretern einer bestimmten Sprache, bilden diese die drei Bestandteile die Active Scripting Architektur. Der erste Scripting Host war der Internet Explorer, doch mit dem Windows Script Host (WSH) gibt es inzwischen einen eigenständigen Scripting Host für Windows-Plattformen.[4] Weitere verfügbare Scripting Hosts sind beispielsweise: Active Server Pages (ASP) im Internet Information Server (IIS) Event Scripting Agent im Exchange Server Job Scripting im Server-Agent im SQL Server-Agent Dynamic HTML-Scripting im Internet Explorer Outlook Forms in Microsoft Outlook Der Windows Script Host Der Windows Script Host (WSH) ist eine Laufzeitumgebung für Scripte, welche sich zur Automatisierung von Administrationsaufgaben einsetzen lässt. Scripte, die in der WSH-Umgebung ausgeführt werden, können die vielen Möglichkeiten der WSH-Objekte und anderer COM-basierter Objekte, wie zum Beispiel WMI (Windows Management Instrumentation) und ADSI (Active Directory Service Interfaces), nutzen. Der WSH besitzt keine eigene Programmiersprache, sondern arbeitet mit zahlreichen verschiedenen Programmiersprachen zusammen. Microsoft liefert die Sprachen Visual Basic Script (VBScript) und Jscript. Von anderen Herstellern kann man Perl, REXX, Python, Haskell und Ruby in Versionen bekommen, die jeweils mit dem WHS kooperieren. Anders als beim Kommandozeileninterpreter gibt es beim WSH keinen interaktiven Modus, d.h. Skripte müssen immer zur Stapelverarbeitung in Textdateien abgelegt und dann gestartet werden. Eine direkte Ausführung einzelner Befehle in einem Eingabefenster ist nicht möglich. Auch wenn der WSH primär als 'Container' zur Verwendung anderer Scriptsprachen oder -technologien dient, ist es doch möglich, "reine" WSH-Scripte zu nutzen. Mit dem WSH können Sie zum Beispiel Netzlaufwerke und Drucker verbinden. Doch außer diesen Möglichkeiten gibt es nur wenig, was Sie noch mit dem WSH alleine durchführen können. Sie können über den WSH nicht die Hardware eines Computers abfragen oder feststellen, welche Software installiert ist. Doch die Lösung hierfür ist einfach: Man bindet ein COM-Objekt in ein Script ein, welches die Funktionen für Anwendungen oder Programmbibliotheken verfügbar macht, sodass der WSH diese Funktionen nutzen kann. Beispielsweise bietet WMI die Möglichkeit Eigenschaften von Diensten abzufragen, Dienste anzuhalten, zu starten oder Einstellungen zu konfigurieren. Statt also eigene Methoden zur Verwaltung von Diensten zur Verfügung zu stellen, verwendet der WSH einfach die von WMI. [5] C. Die Windows PowerShell Das DOS-ähnliche Kommandozeilenfenster der PowerShell ist eine Adaption des Konzepts von Unix-Shells auf Windows unter Verwendung des.net Framework und mit Anbindung an die Windows Management Instrumentation (WMI), die den Zugang zu allen Systemobjekten bereitstellt. Erstmal erschienen ist die PowerShell 2006 für Windows XP und höher. Sie gehört jedoch nicht zum Lieferumfang des Windows XP Betriebssystem und muss daher nachträglich installiert werden. [2] Sie besitzt zahlreiche eingebaute Funktionen, welche cmdlets (gesprochen: Command-lets) genannt werden und unterstützt insbesondere den Datenaustausch durch Pipelines. Neben der cmdlet-struktur bietet die PowerShell auch eine eigene Scriptsprache. Die sogenannte PowerShell Language (PSL). Sie bietet übliche Programmkonstrukte, wie Schleifen und Bedingungen, sodass auch komplexe Befehlsabfolge definierbar sind. Zwar kann man auch ohne Kenntnisse über das.net Framework schnelle Erfolge mit der PowerShell erzielen, doch lässt sich ihre Mächtigkeit nur dann voll ausnutzen, wenn man ein gutes Verständnis über objektorientiertes Programmieren und etwas Erfahrung mit dem.net Framework besitzt..net Framework Das.NET Framework ist eine plattform- und programmiersprachenunabhängige Softwareentwicklungsplattform, welche Microsoft 2002 als Nachfolger für das COM eingeführt hat. Es besteht aus einer Laufzeitumgebung, sowie einer Sammlung von Klassenbibliotheken, Programmierschnittstellen und Dienstprogrammen. Plattformunabhängig bedeutet, dass.net - Anwendungen ohne neu Kompilierung auf jedem Prozessor und jedem Betriebssystem laufen. Die.NET Anwendungen liegt dabei normalerweise nicht im Maschinencode, sondern einem Zwischencode, der Common Intermediate Language (CIL), vor und wir erst zur Laufzeit von einem Just-in-time-Compiler der.net-laufzeitumgebung (Common Language Runtime CLR) in plattformspezifischen Maschinencode umgewandelt. Programmiersprachenunabhängig heisst, dass.net- Anwendungen in verschiedenen Programmiersprachen geschrieben werden können (z.b. C#, j#, ect.). Die Sprachcompiler müssen sich dazu nur an gewisse Regelwerke

3 3 halten, welche Common Type System (CTS) und Common Language Specification (CLS) heißen. Innerhalb von Anwendungen können verschiedene Programmiersprachen gemischt werden. [6] In Windows 7 ist das.net Framework in den Versionen 2.0, 3.0 und 3.5 im Standardinstallationsumfang des Betriebssystem enthalten. III. ANWENDUNGSBEISPIELE Hier sollen die Sprachunterschiede an verschiedenen einfachen Anwendungsbeispielen dargestellt werden. A. Datei-Operationen Problem: Das folgende Script kopiert die Datei Quelle.txt, welche sich auf C:\ befindet, nach C:\ und benennt diese Kopie.txt. Danach wird die Kopie nach C:\Verzeichnis verschoben und im Anschluss die Quell-Datei gelöscht. Lösung : 1) Batch (bsp_datei.bat) COPY "C:\Quelle.txt" "C:\Kopie.txt" MOVE "C:\Kopie.txt" "C:\Verzeichnis\" DEL "C:\Quelle.txt" Voraussetzung für das Script ist die Existenz der Datei Quelle.txt und des Ordners Verzeichnis auf C:\. Außerdem muss das Script als Administrator ausgeführt werden um die nötigen Rechte zum schreiben und löschen zu gewährleisten. Der erste Befehl, in der ersten Zeile, bewirkt lediglich, dass die folgenden Befehle nicht auf der Kommandozeile ausgegeben werden. 2) VBScript (bsp_datei.vbs) Dim objfso Set objfso = _ CreateObject("Scripting.FileSystemObject") objfso.copyfile "C:\Quelle.txt","C:\Kopie.txt" objfso.movefile "C:\Kopie.txt","C:\Verzeichnis\" objfso.deletefile "C:\Quelle.txt" Auch hier sind die Voraussetzungen des Scripts die Existenz der Quelle-Datei und des Verzeichnis-Ordners, in das die kopierte Datei verschoben werden soll. Außerdem müssen auch hier die nötigen Rechte vorhanden sein Dateien erstellen, verschieben und löschen zu dürfen. Führt man die cmd.exe als Administrator aus, so lässt sich das VBScript mit dem Befehl bsp_datei.vbs starten. Im Unterschied zum Batch-Script sieht man in diesem Beispiel ganz deutliche, dass es sich bei VBS um eine objektorientierte Programmiersprache handelt. Die erste Zeile im Script deklariert die verwendeten Variablen, dies ist jedoch nicht zwingend notwendig, dient aber der Übersichtlichkeit. Mit dem Befehl set objfso = CreateObject("Scripting.FileSystemObject") wird ein sogenanntes FileSystemObject erzeugt, welches die die nötigen Datei-Operationen bereitstellt. Näheres dazu und weitere Methoden finden Sie auf der Microsoft Developer Network Seite [7]. 3) PowerShell (bsp_datei.ps1) Copy-Item C:\Quelle.txt C:\Kopie.txt Move-Item C:\Kopie.txt C:\Verzeichnis\Quelle.txt Remove-Item C:\Quelle.txt Damit die Befehl Copy-Item und Remove-Item funktionieren, müssen die nötigen Rechte vorhanden sein um auf C:\ schreiben zu dürfen. Dies kann man zum Beispiel dadurch erreichen, dass man die PowerShell als Administrator startet. Außerdem muss für den Befehl Move-Item der Pfad C:\Verzeichnis existieren. PowerShell selbst legt den Ordner nicht selbstständig an. Natürlich muss auch die Quelle.txt auf C:\ existieren. Das Ausführen des Scripts, in diesem Beispiel, innerhalb der PowerShell erfolgt dann durch den Befehl.\bsp_datei.ps1. Man beachte das vorangestellte.\, dies ist nötig, da die PS bsp_datei.ps1 sonst als cmdlet interpretieren würde. Standardmäßig wird das Ausführen von Scripten auf der PowerShell durch die ExecutionPolicy verhindert. Sie müssen entweder Ihre Scripte signieren oder aber die ExecutionPolicy mit dem set- ExecutionPolicy Befehl ändern. Die kann zum Beispiel durch set-executionpolicy unrestricted geschehen. VORSICHT: Dabei können natürlich auch schädliche Scripte ausgeführt werden, da mit diesem Befehl alle Sicherheitsrichtlinien aufgehoben werden, bzw. keine Signaturen der Scripte verlangt werden. Mit get-executionpolicy können Sie die aktuelle Einstellung prüfen. Die Standardeinstellung ist restricted. Wscript.quit

4 4 B. Text-Operationen Problem: Das Script liest die C:\Quelle.txt ein sucht und ersetzt das Wort Name durch Hans. Lösung: 1) Batch (bsp_text.bat) SET "Quelle=C:\Quelle.txt" FOR /F "DELIMS=" %%i IN (%Quelle%) DO SET zeile=%%i & CALL :Zeilen GOTO :eof :Zeilen SET zeile=%zeile:name=hans% ECHO %zeile% >> C:\Ausgabe.txt Bemerkung: FOR /F "DELIMS=" %%i IN (%Quelle%) DO SET zeile=%%i & CALL :Zeilen muss in einer Zeile stehen. Das Script ließt zeilenweise die Quell-Datei ein und speichert diese in der Variablen zeile durch die Zuweisung zeile = %%i, wobei %%i die Lauf-Variable der For-Schleife ist, also die aktuelle Zeile im Text. Anschließend wird in jeder Zeile durch den Befehl SET zeile=%zeile:name=hans% das Wort Name (auch als Substring) durch Hans ersetzt. In einer weiteren Batch-Datei müsste nun noch die alte Quelle.txt durch Ausgabe.txt ersetzet werden. Dies auch noch in die bsp_text.bat zu schreiben oder Quelle.txt direkt zu überschrieben wäre sehr umständlich. Das Script muss als Administrator ausgeführt werden, da der Befehl ECHO %zeile% >> C:\Ausgabe.txt eine neue Text-Datei mit dem Namen Ausgabe erstellt und somit die entsprechenden Rechte vorhanden sein müssen. Echo ist der Standardausgabebefehl der cmd.exe und mit > wird diese Ausgabe an die Text-Datei weitergeleitet. Mit >> wird die Ziel-Datei nicht überschrieben, sondern die Ausgabe von Echo angehängt. Das ganze ist nicht zu verwechseln mit dem Pipeline-Symbol. 2) VBScript (bsp_text.vbs) Dim alt, neu, tmp, quelle alt = "Name" neu = "Hans" Set objfso = _ CreateObject("Scripting.FileSystemObject") Set File = objfso.opentextfile("c:\quelle.txt", 1) quelle = File.ReadAll File.Close tmp = Replace(quelle, alt, neu) Set File = objfso.opentextfile("c:\quelle.txt", 2) File.Write tmp File.Close Nachdem zunächst die verwendeten Variablen deklariert und die Werte für alt und neu gesetzt wurden, wird ein FileSystemObject erzeugt, welches die hier nötigen Funktionen bereitstellt. Mit Set File = objfso.opentextfile("c:\quelle.txt", 1) wird die Quell-Datei in die Variable File geladen. Der Parameter 1 bedeutet, dass die geöffnete Datei nur gelesen werden kann. D.h. in File kann nicht geschrieben werden. quelle = File.ReadAll liesst nun die Datei und speichert sie in der Variablen quelle, anschließen wird File geschlossen und nicht weiter verwendet. Jetzt wird die VBScript-Funktion Replace auf quelle angewendet und das Ergebnis in tmp gespeichert. Set File = objfso.opentextfile("c:\quelle.txt", 2) Wie oben wird erneut die Quell-Datei in File geladen, diesmal allerdings mit dem Parameter 2, womit das schreiben in die Datei ermöglicht wird. Dies wird durch File.Write tmp erreicht. 3) PowerShell (bsp_text.ps1) $Quelle="C:\Quelle.txt" $Ziel="C:\Ausgabe.txt" Get-Content -Path $Quelle foreach {$_ -replace "Name","Hans"} Out-File -FilePath $Ziel -encoding Default -Append Get-Content -Path $Quelle Ruft den Inhalt des Elements am angegebenen Speicherort ab. Das Ergebnis dieses Aufrufs wird durch das Pipeline-

5 5 Symbol an die foreach-schleife weitergegeben. An dieser Stelle ist zu bemerken, dass sich das Pipeline-Symbol auch zum line-break eignet. Innerhalb der Schleife wird nun jeder Substring Name durch Hans ersetzt und die Ausgabe davon wiederum an den Out-File -Befehl weitergegeben. Mit dem Cmdlet "Out-File" wird die Ausgabe an eine Datei gesendet. -Encoding Default Gibt den Typ der Zeichencodierung an, die in der Datei verwendet wird. Der Standardwert ist Unicode. -Append sorgt dafür, dass die vorhandene Datei nicht überschrieben, sondern die Ausgabe an diese angehängt wird. C. Prozess-Operationen Problem: In diesem Script wird ein Prozess (calc.exe) gestartet. Die Prozess-ID (PID) wird gespeichert und am Ende benutzt um den Prozess wieder zu beenden. Anschließend soll die Prozessliste ausgegeben werden. Lösung: 1) Batch (bsp_prozess.bat) TASKLIST FINDSTR /i "calc.exe" > tmp.txt START calc.exe TASKLIST FINDSTR /i "calc.exe" > tmp2.txt FOR /F "eol=- tokens=2" %%i IN ('FC tmp.txt tmp2.txt^ FIND "calc.exe"') DO SET pid=%%i & CALL :ProzessID GOTO :eof :ProzessID DEL tmp.txt DEL tmp2.txt ECHO Neuer Prozess mit PID %pid% gestartet. PAUSE TASKKILL /PID %pid% TASKLIST PAUSE Bemerkung: FOR /F "eol=- tokens=2" %%i IN ('FC tmp.txt tmp2.txt^ FIND "calc.exe"') DO SET pid=%%i & CALL :ProzessID muss in einer Zeile stehen. Zwar lässt sich die calc.exe auch mit dem Befehl TASKKILL /IM calc.exe oder TASKKILL /FI imagename eq calc.exe beenden, Problem hierbei ist allerdings, dass alle Prozesse mit dem Namen calc.exe beendet werden. In unserem Beispiel wollen wir jedoch, dass vorher gestartete Prozesse (mit gleichen Namen) auch weiterhin laufen und nur der von uns gestartete Prozess beendet wird. Um dies zu erreichen benutzt man in der Regel die PID, welche eindeutig bestimmt ist. Um an die PID unseres Prozesses zu gelangen vergleichen wir, welche Prozesse vor dem Start von calc.exe laufen (genauer interessieren wir uns nur für die gleichnamig laufenden Prozesse) mit der Liste der Prozesse nach dem Start. TASKLIST FINDSTR /i "calc.exe" > tmp.txt TASKLIST listet alle laufenden Prozesse auf, diese werden dann mit FINDSTR gefiltert und in die tmp.txt geschrieben. Nun Starten wir die calc.exe mit START calc.exe und listen erneut alle Prozesse mit dem Namen calc.exe auf, welche wir dann in tmp2.txt speichern. D.h.: TASKLIST FINDSTR /i "calc.exe" > tmp2.txt Nun müssen wir nur die beiden Text-Dateien vergleichen und schauen, welcher Prozess in tmp2.txt neu hinzugekommen ist. Die geschieht über den Befehl FC tmp.txt tmp2.txt Allerdings steht in der Ausgabe von FC mehr Information als wir benötigen, daher greifen wir mit Hilfe einer For- Schleife und ihren Optionen genau die Information heraus, die wir brauchen. Die Parameter /F "eol=- tokens=2" liefern genau diese. Mit eol=- werden Zeilen, welche mit - beginnen von der For-Schleife ignoriert (hängt mit der Ausgabe von FC zusammen). Mit tokens=2 bekommen wir die PID, während zum Beispiel tokens=1 der Prozessname wäre. Diese speichern wir nun mit DO SET pid=%%i in die Variable pid und rufen anschließend :ProzessID auf. Hier werden nun die tmp-dateien gelöscht und die PID auf der Konsole ausgegeben. PAUSE hält das Script an, solange bis eine beliebige Taste gedrückt wird. TASKKILL /PID %pid% beendet jetzt unseren Prozess mit der entsprechenden PID. Der Befehl GOTO :eof (eof end of file) am Ende der For-Schleife sorgt dafür, dass das Script beendet wird ohne den Rest auszuführen. Am Ende des Script wird nochmal die Prozessliste ausgegeben, um zu überprüfen ob unser Prozess auch wirklich beendet wurde.

6 6 2) VBScript (bsp_prozess.vbs) Dim objwmiservice,colprocess Dim objprocess, objprogram Dim strcomputer, strexe, strshell, strliste strcomputer = "." strexe = "calc.exe" 'Mit WMI Service verbinden Set objwmiservice = GetObject("winmgmts:" & _ "{impersonationlevel=impersonate}!\\" & _ strcomputer & "\root\cimv2") 'starten der calc.exe Set objprocess = objwmiservice.get("win32_process") Set objprogram = objprocess.methods_("create"). _ InParameters.SpawnInstance_() objprogram.commandline = strexe Set strshell = objwmiservice.execmethod _ ("Win32_Process", "Create", objprogram) WScript.Echo "Neuer Prozess mit PID " & _ strshell.processid & " gestartet." 'suchen und beenden des Prozess mit bestimmter PID ("Select * from Win32_Process Where ProcessID= " & _ strshell.processid ) For Each objprocess in colprocess objprocess.terminate() Next 'Prozessliste nach Beendignung der calc.exe ("Select * from Win32_Process") For Each objprocess in colprocess strliste = strliste & vbcr & _ objprocess.name & " " & objprocess.processid Next WScript.Echo strliste WScript.Quit Bemerkung: Line-breaks werden in VBS durch _ erzielt. Zunächst deklarieren wir mit Dim die verwendeten Variablen und mit strcomputer = "." wird auf den localhost verwiesen. Da WSH selbst keine Methoden besitzt Prozesse abzufragen, zu starten oder zu beenden, benötigen wir ein WMI-Objekt, welches diese Methoden bereitstellt. Dies geschieht über Set objwmiservice = GetObject("winmgmts:" & _ "{impersonationlevel=impersonate}!\\" & _ strcomputer & "\root\cimv2") Mit Hilfe dieses Objekts wird nun der entsprechende Prozess gestartet. Set objprocess = objwmiservice.get("win32_process") Set objprogram = objprocess.methods_("create"). _ InParameters.SpawnInstance_() objprogram.commandline = strexe Set strshell = objwmiservice.execmethod _ ("Win32_Process", "Create", objprogram) Mehr dazu finden Sie auf der Microsoft Developer Network Seite. [8] WScript.Echo "Neuer Prozess mit PID " & _ strshell.processid & " gestartet." Öffnet ein Ausgabefenster mit der angegebenen Nachricht und der PID. Man beachte, dass an dieser Stelle das Script anhält und auf Bestätigung durch OK wartet, bevor es weiterläuft. Um jetzt den Prozess wieder zu beenden, erstellen wir eine Liste der laufenden Prozesse und speichern diese in colprocess, gleichzeitig filtern wir diese Liste schon und suchen unseren Prozess mit der entsprechenden PID, welche in strshell.processid steht. D.h.: ("Select * from Win32_Process Where ProcessID= " & _ strshell.processid ) Mit einer For-Each-Schleife beenden wir nun die Prozesse, welche in der Liste colprocess stehen. (In unserem Beispiel wird nur ein Prozess in der Liste stehen.) Das beenden erfolgt über den Befehl objprocess.terminate() Um eine Prozessliste zu erstellen benutzen wir, wie oben, auch das WMI-Objekt. ("Select * from Win32_Process") legt wieder eine Sammlung der Win32-Prozesse an. Diese speichern wird mit Hilfe der For-Each-Schleife in strliste. strliste = strliste & vbcr & _ objprocess.name & " " & objprocess.processid Bei vbcr handelt es sich um einen Zeilenumbruch. 3) PowerShell (bsp_prozess.ps1) $tpid = [diagnostics.process]::start("calc.exe") Write-host "Neuer Prozess mit PID" $tpid.id "gestartet" Start-Sleep -s 10 Stop-Process -id $tpid.id Um die calc.exe in PowerShell zu starten würde es genügen Start-Process calc.exe in die Konsole einzugeben. Eine elegantere Methode jedoch ist die Verwendung der.net Klasse System.Diagnostics.Process. Sie liefert zudem alle

7 7 Informationen die wir benötigen um den Prozess auch wieder zu beenden. Diese Informationen speichern wir zunächst in der Variablen $tpid durch $tpid = [diagnostics.process]::start("calc.exe") Wir können nun durch $tpid.id sofort auf die Prozess-ID zugreifen und mit Stop-Process -id $tpid.id den Prozess beenden. Leider verfügt PowerShell über keinen Pause Befehl, wie die cmd.exe, damit in diesem Beispiel die calc.exe nicht sofort wieder geschlossen wird, habe ich zwischen Prozess-Start und Prozess-Ende einen Sleep von 10 Sekunden mit Start-Sleep -s 10 eingebunden. IV. FAZIT Zwar lässt sich mit der cmd.exe schon eine Menge erreichen, doch sind die Grenzen der Batch-Sprache schnell erkennbar. So lassen sich komplexe Probleme nur durch Erweiterungen mit Tools, wie etwa den Resource-Kit-Tools, oder mit sehr viel Aufwand lösen. Einfache administrative Aufgaben, wie das Anlegen von Benutzerkonten und dem damit verbundenen setzen von Passwörtern und Benutzerrechten sind allerdings schnell und schön lösbar. Zudem ist die Sprache schnell lernbar. Das arbeiten mit dem WSH und VBScript setzt gute Kenntnisse über objektorientiertes Programmieren voraus. Erfahrungen mit den COM-Bibliotheken und der WMI sind ebenso von Vorteil. Besitzt man dieses Wissen und hat darüber hinaus schon mit Visual Basic Sprachen gearbeitet kann man sicher schnell Erfolge erzielen. Ohne dieses Wissen ist der Aufwand zum Erlernen dieser Sprache, meiner Meinung nach, etwas höher als Beispielsweise das Erlernen der PowerShell Language. Positiv zu erwähnen ist, dass sich VBScripte einfach in HTML-Code einbinden lassen. Außerdem ist es sehr leicht Fenster für Ein- und Ausgaben zu erstellen. Beachten muss man an dieser stelle jedoch, dass bei einer Textausgabe in einem Fenster das Script anhält und erst bei Bestätigung durch OK weiterläuft. Für automatisierte Abläufe sollte man also genau darauf achten, ob die Ausführung des Script in WScript (Ausführung des Scripts als Windows-Anwendung mit Ausgaben in Dialogboxen) oder CScript (Ausführung des Scripts im Kontext einer Kommandozeile) erfolgt. Beherrscht man VBScript, so ist ein Vorteil der Sprache, dass sich die Scripte mit nur wenigen Änderungen in VBA (Visual Basic for Applications) umschreiben lassen. Wer gerne mit Kommandozeile arbeitet wird mit der Windows PowerShell sicher Spaß haben. Doch auch mit ihr sind Kenntnisse des objektorientierten Programmieren von Vorteil. Anders als bei VBScript ist das OOP jedoch nicht überall zwingend erforderlich. Die cmdlets der PowerShell sind gut dokumentiert und auch über die get-help Funktion lassen sich einige Beispiele ansehen, sodass die Sprache recht schnell zu erlernen ist [9]. Außerdem liefert Microsoft eine Entwicklungsumgebung, die Windows PowerShell Integrated Scripting Environment (ISE), welche das Entwickeln und Debuggen von Scripen erleichtert. LITERATURVERZEICHNIS [1] Weißl, Johannes Einführung in die GNU Bourne-Again Shell ( Seite 5 [2] Dr. Schwichtenherg, Holger Windows PowerShell 2.0 Das Praxisbuch Addison-Wesley, 2. Auflage, Seite 51 [3] Dr. Schwichtenberg, Holger Windwos Scripting Addison-Wesley 4.Auflage, Seite 50 [4] Dr. Schwichtenberg, Holger Windwos Scripting Addison-Wesley 4.Auflage, Seite 52 ff [5] O.A.: Microsoft Windows 2000 Scripting-Handbuch (Teil 1) ( mspx) [6] Dr. Schwichtenberg, Holger Windwos Scripting, Addison-Wesley 6.Auflage, Seite 931 ff [7] O.A.: FileSystemObject ( [8] O.A.: Create Method of the Win32_Process Class ( [9] O.A.: Windows PowerShell Cmdlet-Hilfethemen (