Windows PowerShellEin tieferer Einblick
Don Jones
Windows PowerShell steckt voller Features, die von vielen Administratoren oft übersehen werden. Wenn Sie sich näher damit befassen, werden Sie auf einige erstaunliche Funktionen stoßen. Tatsächlich entdecke ich selbst oft neue Features bei einem bestimmten Cmdlet, das ich meiner Meinung nach bereits in- und auswendig kannte.
In den Windows PowerShellTM-Kursen, die ich unterrichte, empfehle ich Administratoren, einen Kalender für das Cmdlet des Tages zu erstellen, ähnlich den Kalendern mit einem Wort des Tages, die man kaufen kann. So können sie sich am Morgen eines jeden Wochentags (das Wochenende gebe ich ihnen frei) ein paar Minuten lang mit den vollständigen Funktionen eines Cmdlets vertraut machen. Windows PowerShell enthält ungefähr 130 Cmdlets, sodass Sie praktisch alle Funktion der Windows PowerShell in etwa sechs Monaten kennenlernen können, wenn Sie sich an diesen Zeitplan halten. Dann können Sie sich den ganzen Exchange Server 2007-Cmdlets zuwenden.
Im Artikel dieses Monats erhalten Sie Beispiele für eine Reihe Entdeckungen, die Sie dabei möglicherweise machen. Es wird veranschaulicht, was Sie in einigen wenigen Minuten erreichen können, wenn Sie die Funktionen verschiedener Cmdlets eingehender untersuchen.
Schönere HTML-Berichte
Ein Cmdlet, das nicht ausreichend genutzt wird, ist ConvertTo-HTML. Dieses intelligente Cmdlet kann eine Sammlung von Eingabeobjekten – Dienste, Prozesse, Objekte der Windows®-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) oder anderes – annehmen und sie in eine HTML-Tabelle verwandeln. Dann können Sie die HTML-Tabelle nach Out-File leiten, und schon verfügen Sie über eine HTML-Seite, die zum Bereitstellen auf einem Intranetwebserver geeignet ist. Sie könnten beispielsweise die Ausführung dieser einfachen Zeile jeweils am Morgen planen:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML | Out-File C:\ServiceAlert.html
Auf diese Weise wird ein HTML-Bericht der Dienste erstellt, die automatisch gestartet werden sollen, aber nicht ausgeführt werden, wie in Abbildung 1 dargestellt.
Abbildung 1** Ein HTML-Bericht der Dienste, die nicht ausgeführt werden **(Klicken Sie zum Vergrößern auf das Bild)
Doch möglicherweise möchten Sie einen Bericht erstellen, der etwas attraktiver ist. Glücklicherweise erstellt das ConvertTo-HTML-Cmdlet sauberen HTML-Code, das heißt, in den erstellten HTML-Code wird keine Formatierung eingebettet. Gemäß den HTML-Regeln sollten Sie nie Formatierung in den HTML-Code stellen (oder zumindest so wenig wie möglich). Stattdessen wird die Formatierung in ein externes Cascading Style Sheet (CSS) gestellt und das CSS mit der HTML-Datei verknüpft. Diese Verknüpfung kann mit ConvertTo-HTML erstellt werden.
CSS ist mit dem <HEAD>-Abschnitt einer HTML-Datei verknüpft. Wenn Sie sich die Hilfe für ConvertTo-HTML ansehen, werden Sie feststellen, dass die Syntax einige Parameter enthält, die Sie möglicherweise übersehen haben.
ConvertTo-Html [[-property] <Object[]>]
[-inputObject <psobject>] [-body <string[]>]
[-head <string[]>] [-title <string>] [<CommonParameters>]
Der –head-Parameter ermöglicht das Festlegen von zusätzlichem HTML-Code, der in den <HEAD>-Abschnitt des Skripts eingefügt werden soll. Jetzt kann der Einzeiler leicht geändert werden, sodass er mit einer vorhandenen CSS-Datei verknüpft wird, die die auf die HTML-Tabelle anzuwendende Formatierung enthält:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML -title "Services" -head "<link
rel='stylesheet' href='styles.css' type='text/
css' />" | Out-File C:\ServiceAlert.html
Hier wurde der –head-Parameter zum Einfügen einer Verknüpfung mit einer CSS-Datei verwendet, die sich im selben Ordner wie die Ausgabe-HTML-Datei befindet. Zudem wurde der –title-Parameter zum Festlegen des Titels der Webseite verwendet. Das Ergebnis ist in Abbildung 2 dargestellt. Der Text der verwendeten Style.CSS-Datei sieht folgendermaßen aus:
Abbildung 2** Ein mit einer CSS-Datei formatierter HTML-Bericht **(Klicken Sie zum Vergrößern auf das Bild)
body { background-color:#EEEEEE; }
body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt }
th { font-weight:bold; background-color:#CCCCCC; }
td { background-color:white; }
Leichteres Filtern
Cmdlet des Monats
In diesem Monat geht es um ein Cmdlet-Paar: Start-Transcript und Stop-Transcript. Beide dienen zur Steuerung von Windows PowerShell-Aufzeichnungsprotokollen, d. h. alles, was im Konsolenfenster angezeigt wird, wird in eine von Ihnen angegebene Textdatei geschrieben. Es ist ziemlich einfach. Führen Sie zunächst Start-Transcript aus, und legen Sie einen Dateinamen fest. Führen Sie anschließend Stop-Transcript aus, um die Protokollierung zu beenden, und schließen Sie die Datei. Dies ist eine hervorragende Möglichkeit, von der Ad-hoc-Shellverwendung zur formellen Skripterstellung überzugehen. Wenn erst einmal einzelne Befehlszeilen in der Shell arbeiten, können Sie diese einfach aus der von Ihnen erstellten Protokolldatei kopieren und einfügen. Selbstverständlich können Sie auch einfach das Protokoll so bearbeiten, dass nur noch das eigentliche Skript vorhanden ist. Jeffery Hicks, ein Kollege bei MVP, hat sogar ein Skript geschrieben, das Protokolle analysiert und sie in Windows PowerShell PS1-Dateien verwandelt. Dieses Skript finden Sie unter blog.sapien.com/current/2006/11/28/powershell-transcripts.html.
Im Folgenden wird das Get-WMIObject-Cmdlet nähere betrachtet. Seine Syntax, die in der integrierten Hilfe der Windows PowerShell aufgeführt wird, deutet auf ungenutzte Funktionen hin:
Get-WmiObject [-class] <string> [[-property]
<string[]>] [-namespace <string>]
[-computerName <string[]>] [-filter <string>]
[-credential <PSCredential>]
[<CommonParameters>]
Ein häufiger Fehler von neuen Windows PowerShell-Benutzern besteht darin, dass sie einen WMI-Befehl wie diesen ausgeben:
Gwmi Win32_NTLogEvent –comp Server2
Dieser Befehl ruft die Ereignisprotokolleinträge von Server2 ab, und zwar alle Ereignisprotokolleinträge. Es dauert eine Weile, bis Server2 diese Aufgabe verarbeitet und überträgt, und Windows PowerShell braucht ebenfalls einige Zeit, um mit einer so großen Sammlung etwas Nützliches anzustellen.
Ein besserer Ansatz besteht darin, dass Server2 die Ereignisse, die wirklich wichtig sind, sucht und sendet. Dies könnte durchaus mit einer Abfrage in der WMI-Abfragesprache (WMI Query Language, WQL) erfolgen. Manche empfinden diese Abfragesyntax als schwierig, doch in der Windows PowerShell können Sie mithilfe des –filter-Parameters einfach nur den Filteranteil einer WQL-Abfrage angeben.
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Auf diese Weise werden alle Ereignisse (aus beliebigen Protokollen) mit der Ereignis-ID 1024 abgerufen. Beachten Sie, dass das Filterkriterium = als Vergleichsoperator anstelle des –eq-Operators der Windows PowerShell verwendet. Der Grund besteht darin, dass der Filter einfach nur an den WMI-Dienst des Remotecomputers zur Verarbeitung übergeben wird. Daher muss das Kriterium in der WMI-Syntax und nicht in der Windows PowerShell-Syntax vorliegen.
Es gibt auch einen –filter-Parameter in anderen Cmdlets, beispielsweise Get-ChildItem, das Cmdlet hinter Aliasen wie Dir und Ls. In den meisten Fällen übergibt der –filter-Parameter Ihr Filterkriterium direkt an die zugrunde liegende Technologie. Dies führt zu etwas, das ich gerne als Quellfilterung bezeichne, und das oft viel schneller ist, als alle Objekte zu übertragen und diese durch das Where-Object-Cmdlet laufen zu lassen, um die nicht erwünschten herauszufiltern.
Übersehene Cmdlets
Der Ansatz, bei dem Sie sich mit einem Cmdlet pro Tag befassen, wird Ihnen durchaus helfen, Cmdlets besser zu verstehen, die Sie Ihrer Meinung nach bereits kannten. Doch ein weiterer guter Grund für einen Kalender mit einem Cmdlet pro Tag besteht darin, dass Sie auf diese Weise keine Cmdlets übersehen, die Sie sonst vielleicht überhaupt nicht entdecken würden. Eins meiner Lieblings-Cmdlets, das von vielen nicht verwendet wird, ist Resolve-Path. Bei einem Platzhalterpfad gibt es eine Sammlung von Datei- und Ordnernamen zurück, die dem Pfad entsprechen. Es ähnelt dem Get-ChildItem-Cmdlet (d. h. die vertrauten Dir- oder Ls-Aliase), doch statt eine ganze Datei und Ordnerobjekte zurückzugeben, gibt es einfache Zeichenfolgen zurück, die zur weiteren Filterung oder Verarbeitung an andere Cmdlets geleitet werden können. Seine Verwendung ist einfach:
Resolve-Path C:\P*
Diese einfache Zeile gibt Pfade wie C:\Programme, C:\Processes.txt und so weiter zurück. Abbildung 3 zeigt zwei Beispiele für die Verwendung dieses Cmdlets.
Abbildung 3** Verwendung des praktischen, aber oft übersehenen Resolve-Path-Cmdlets **(Klicken Sie zum Vergrößern auf das Bild)
Beginnen Sie ganz am Anfang
Wenn Sie damit anfangen wollen, sich pro Tag mit einem Cmdlet zu beschäftigen, führen Sie Gcm aus, ein Alias für Get-Command. Sie erhalten eine Liste aller Cmdlets, die die Windows PowerShell kennt, einschließlich jener, die Sie über Snap-Ins wie beispielsweise die Exchange Server 2007-Verwaltungsshell, die PowerShell-Communityerweiterungen und so weiter hinzugefügt haben. Wählen Sie einfach das erste auf der Liste aus – bei mir war es Add-Content – und lesen Sie die entsprechende Hilfe:
Help Add-Content –full
Sie brauchen die vollständige Hilfe, nicht die knappere Standardhilfe, um eine vollständige Beschreibung der einzelnen Parameter zu erhalten, einige Beispiele der Verwendung des Cmdlets zu sehen und weitere ausführliche Informationen herauszufinden. Nehmen Sie sich etwas Zeit, um mit dem Cmdlet zu experimentieren. (Sie könnten einen virtuellen Computer verwenden, damit Sie nicht mit der Produktionsumgebung arbeiten müssen.) Ich empfehle, jeden Wochentag 10 Minuten darauf zu verwenden, am besten immer zur selben Tageszeit, damit es zur Gewohnheit wird. In kürzester Zeit werden Sie alle Merkmale und Funktionen von Windows PowerShell gründlich kennenlernen.
Don Jones ist der führende Experte für die Skripterstellung bei SAPIEN Technologies und Mitverfasser von Windows PowerShell: TFM (SAPIEN Press, 2007). Sie erreichen ihn unter www.ScriptingAnswers.com.
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.