PowerShell für die Windows-Administration: Ein kompakter und praxisnaher Überblick

Von Peter Monadjemi

Das Buch stellt die Windows PowerShell als vielseitiges Werkzeug für die Administration von Windows Server 2008 R2/2012/2012 R2 vor. Es beschreibt zunächst die Kernkonzepte wie Cmdlets, Pipeline und Objekte und stellt danach die PowerShell in der Praxis vor, wobei typische Einsatzszenarien bei der Windows Server-Administration im Mittelpunkt stehen.

• Sprache: Deutsch
• Herausgeber: Springer Vieweg
• Erscheinungsdatum: 13. Nov. 2014
• ISBN: 9783658029647

Buchvorschau

© Springer Fachmedien Wiesbaden 2014

Peter MonadjemiPowerShell für die Windows-AdministrationX.systems.press10.1007/978-3-658-02964-7_1

1. Einleitung

Peter Monadjemi¹  

(1)

ActiveTraining, Esslingen, Deutschland

Peter Monadjemi

Email: [e-mail]

1.1 Und was geht es in diesem Buch?

1.2 Welche Version wird verwendet?

1.3 Ist die PowerShell schwer zu lernen?

1.4 Wenn ein Thema in diesem Buch nicht vorkommt

1.5 Ein Wort zu den Schreibkonventionen für Beispiele

1.6 Wo gibt es die Beispielskripte?

1.7 Kontakt zum Autor

1.8 Danksagungen

Die PowerShell ist ein universelles Werkzeug, das sich im Alltag eines Windows-Administrators an vielen Stellen sinnvoll einsetzen lässt. Für Ad hoc-Abfragen, für Konfigurationsänderung, für das Zusammenfassen kleiner Befehlsfolgen zu einem Skript und für die Umsetzung komplexerer Automatisierungen, die z. B. über einen längeren Zeitraum ausführen und eine große Anzahl an Servern betreffen. Die PowerShell ist ein wahres Allround-Werkzeug, das sich sowohl an den Gelegenheitsanwender als auch an „Scripting-Profis" richtet, die ein leistungsfähiges und robustes Werkzeug benötigen. Als im Herbst 2006 die Version 1.0 offiziell freigegeben wurde, war eine der Fragen, die mit ihrer Einführung einhergingen, an welche Zielgruppe sie sich richten soll und welche Aufgaben mit ihr gelöst werden sollten. Immerhin gab es zu diesem Zeitpunkt bereits eine breite Palette an Skriptsprachen und Automatisierungstools. Alleine von Microsoft gab es mit den Stapeldateien und dem Windows Scripting Host, die auch bei der aktuellen Windows Server-Version dabei sind, zwei Alternativen.

Heute muss diese Frage nicht mehr gestellt werden. Im Zeitalter der Virtualisierung und der „IT-Dienstleistung aus der Steckdose, die von den großen Herstellern und ihren gigantischen Rechenzentren aus der „Cloud angeboten wird, ergibt sich die Notwendigkeit für ein Werkzeug, mit dem sich administrative Abläufe automatisieren lassen, von ganz alleine. Die Stärken der PowerShell liegen aber weniger darin, dass sie neu ist (bzw. war) oder durch die .NET-Laufzeit, auf der sie aufsetzt, von Anfang an eine reichhaltige Funktionalität zu bieten hat. Ihre Stärken liegen in Bereichen, die zunächst nicht besonders attraktiv erscheinen mögen: Konsistenz, Einfachheit in der Bedienung, Vollständigkeit und Erweiterbarkeit. Anforderungen, die in der Theorie zwar jedes Tool erfüllen sollte, doch wie jeder Administrator sicher bestätigen kann, dies in der Praxis nur selten tut. Microsoft hat nach der Einführung von Windows NT im Jahr 1993 relativ lange gebraucht, bis es ein solches Werkzeug den Administratoren zur Verfügung stellen konnte. Inzwischen hat sich die PowerShell mit der Version 4.0 im Windows Server-Umfeld nicht nur etabliert, sie ist fester Bestandteil jeder Windows-Installation, sondern hat sich zu einem ausgereiften Werkzeug entwickelt, das sich vielseitig einsetzen lässt und daher jedem Administrator empfohlen werden kann.

1.1 Und was geht es in diesem Buch?

In diesem Buch geht es um die Grundlagen, die im Praxisalltag mit der PowerShell erfahrungsgemäß zu kurz kommen. Es beginnt mit einem Überblick über die Grundlagen, die man für den gelegentlichen Einsatz der PowerShell im administrativen Alltag kennen muss und stellt in den Folgekapiteln die wichtigsten Bereiche vor, in denen die PowerShell eingesetzt wird. Ab Kap. 18 wird es etwas spezieller. Ab diesem Kapitel kommen die fortgeschritteneren Themen, wie Workflows, der Zugriff auf Datenbanken und die in Zukunft vermutlich sehr wichtig werdende Desired State Configuration (DSC) an die Reihe. Abgerundet wird das Buch mit einem Kapitel, das sich an Software-Entwickler richtet, die die PowerShell erweitern oder als Werkzeug für die Software-Entwicklung, etwa im Rahmen einer Build-Automatisierung, benutzen möchten. Auch der Spaß kommt nicht zu kurz, denn wie jede Skript- und Programmiersprache lässt sich auch die PowerShell für Aufgaben einsetzen, die mit dem Thema Server-Administration nur indirekt etwas zu tun haben.

Das Buch richtet sich daher sowohl an den klassischen Einsteiger als auch an erfahrene PowerShell-Anwender, die ihr Wissen vertiefen möchten.

Benötigt man überhaupt noch ein Buch, um den Umgang mit der PowerShell zu lernen, man findet doch alles im Internet? Und es gibt bei der PowerShell ja noch eine ausführliche Hilfe (die „Man Pages), die dem PowerShell-Neuling alle Fragen beantwortet. Die kurze Antwort ist Ja. Auch wenn sich für nahezu jedes denkbare „PowerShell-Problem eine funktionierende Lösung im Internet finden lässt und viele PowerShell-Experten ihr Wissen in Blogs ausführlich ausbreiten, das Thema Grundlagen kommt naturgemäß dabei zu kurz. Natürlich kann ein Buch nicht alle Fragen beantworten. Vor allem dann nicht, wenn es nicht den Umfang einer mittleren Enzyklopädie annehmen soll. Das Buch, das Sie in den Händen halten, hat daher ein klar definiertes Anliegen: Es soll Ihnen die Grundlagen der PowerShell praxisnah und leicht verständlich erläutern und darüber hinaus die wichtigsten Einsatzgebiete für die PowerShell vorstellen. Ergänzende und vertiefende Informationen, spezielles Know-how und „jede Menge PowerShell-Skripte finden Sie natürlich an vielen Stellen im Internet. Zum Beispiel im Blog des PowerShell-Teams bei Microsoft, in der von Microsoft-Mitarbeiter Ed Wilson betreuten „Hey, Scripting Guy-Kolumne oder im Portal der deutschsprachigen PowerShell-Community unter http://​www.​powershell-group.​eu.

1.2 Welche Version wird verwendet?

Dieses Buch basiert auf der PowerShell 4.0, die zu dem Zeitpunkt der Drucklegung dieses Buches die aktuelle Version war. Seit Mai 2014 gibt es eine Vorabversion der Version 5.0 als Teil des „Windows Management Framework 5.0 Preview. Diese Version wird (Stand: August 2014) lediglich zwei Neuerungen mitbringen: Verbesserungen bei der Desired State Configuration (DSC) und ein universeller Paketmanager (OneGet) für das Installieren von (beliebigen) Anwendungen als auch, als separates Modul (PowerShellGet), für das Hinzufügen von PowerShell-Modulen. Das PowerShell-Team bei Microsoft hat in diesem Zusammenhang in Aussicht gestellt, dass es in Zukunft neue Releases in kürzeren Abständen „out of band geben soll, die dann in die nächste Windows Server-Version eingefügt werden. Neu ist auch ein DSC-Client für Linux, so dass sich auch Linux basierende Server per PowerShell-Skript (das allerdings auf einem Windows Server gestartet wird) konfigurieren lassen. Für PowerShell-User gibt es daher in den kommenden Jahren viel zu tun, um mit den zu erwartenden Neuerungen Schritt zu halten. Dieses Buch soll Sie dabei unterstützen.

1.3 Ist die PowerShell schwer zu lernen?

Ja und Nein. Nein, weil man sich nur ein paar einfache Regeln und eine gewisse Vertrautheit im Umgang mit der Befehlszeile aneignen muss, um damit PowerShell-Befehle ausführen zu können. Ja, weil einige Konzepte aus dem Bereich der Programmierung stammen, und sich Administratoren ohne jegliche Vorkenntnisse in diesem Bereich erfahrungsgemäß mit abstrakten Begriffen wie Objekten, Members, Typen oder Hashtable etwas schwer tun.

Im Vergleich zu Stapeldateien, dem Windows Scripting Host (WSH) oder auch einer Unix-Shell wie Bash ist die PowerShell aber (deutlich) einfacher zu erlernen, denn eine ihrer positiven Eigenschaften ist, dass sie eine Reihe von „Komforteinrichtungen" bietet, die das Erlernen erleichtern. Dazu gehören eine einheitliche Namensgebung, der Umstand, dass die Hilfe (sofern sie einmalig vom Microsoft-Server heruntergeladen wurde) immer zugänglich, verständlich formuliert und mit vielen Beispielen ausgestattet ist, und die Kleinigkeit, dass sich Befehlsnamen per [Tab]-Taste vervollständigen und in der PowerShell ISE aus Auswahllisten auswählen lassen. Alleine in diesem Punkt ist die PowerShell ein großer Fortschritt, der auch die Einarbeitung deutlich vereinfacht.

Dass sich in der PowerShell auch kryptische Befehlsfolgen eingeben lassen, macht das folgende kleine Beispiel deutlich:

A316308_1_De_1_Figa_HTML.gif

Das ist ein gültiger und vollständiger PowerShell-Befehl. Selbst viele erfahrene PowerShell-Anwender dürften nicht auf Anhieb erkennen, was dieser Befehl bewirkt: Er gibt den nächsten freien Laufwerksbuchstaben aus (der Befehl stammt aus einem kleinen Wettbewerb, der vor einiger Zeit vom PowerShell Magazine – http://​www.​powershellmagazi​ne.​com – veranstaltet wurde). Wenn Sie das Buch gewissenhaft lesen und alle Beispiele ausprobieren, werden Sie den Befehl in kurzer Zeit nicht nur verstehen, sondern sich selber solche Konstruktionen ausdenken können.

1.4 Wenn ein Thema in diesem Buch nicht vorkommt

Sie arbeiten beruflich mit Citrix Xen Desktop, VMWare, NetApp oder Exchange Server und möchten mehr über die „PowerShell-Anbindung" bei diesen Produkten lernen, doch diese Themen werden in diesem Buch nicht behandelt. Ist das Buch daher trotzdem etwas für Sie? Ja, denn wenn Sie das allgemeine Konzept der Befehlsausführung verstanden haben, können Sie dieses Wissen auf alle Bereiche übertragen, in denen die PowerShell eingesetzt wird. Ob Sie sich per Get-Process die Details zu allen laufenden Prozessen oder per Get-Mailbox die Details zu allen Mailboxen eines Exchange Servers ausgeben lassen, ist nur eine Frage der Schreibweise, nicht der generellen Vorgehensweise. Die Konsistenz der PowerShell gilt auch für alle Erweiterungen und ist eine der Stärken der PowerShell.

1.5 Ein Wort zu den Schreibkonventionen für Beispiele

Sie finden in diesem Buch viele Beispiele. Die meisten Beispiele bestehen aus Befehlen, die Sie direkt in die PowerShell-Befehlszeile eingeben können. In den ersten Kapiteln geht vielen Befehlen ein „PS C:\PSKurs> voraus. Dies ist der PowerShell-Prompt, der in dem (fiktiven) PowerShell-Host, in dem die Befehle ausgeführt werden, angezeigt wird. Das „PS steht für PowerShell, „C:\PSKurs ist das aktuell eingestellte Verzeichnis und „> ist lediglich ein weiterer Teil des Eingabeprompts. Den Eingabeprompt, er wird auf Ihrem Computer eventuell etwas anders aussehen, geben Sie nicht mit ein, sondern nur den Befehl, der auf den Prompt folgt. Befehle, denen kein Prompt vorausgeht, können Sie in der Regel ebenfalls in die Befehlszeile eingegeben. Der Umstand, dass kein Prompt vorangeht, soll in erster Linie andeuten, dass der Befehl primär in einem Skript eingegeben wird. PowerShell-Befehle werden in diesem Buch in einer eigenen Schriftart abgebildet:

A316308_1_De_1_Figb_HTML.gif

Alle Befehle sind, bis auf wenige Ausnahmen, so aufgebaut, dass sie direkt in die PowerShell-Konsole eingegeben werden können.

1.6 Wo gibt es die Beispielskripte?

Größere Skripte müssen Sie nicht eintippen. Sie finden sie auf der Webseite des Verlages, können Sie aber auch vom Autor per E-Mail erhalten bzw. über dessen Blog herunterladen (http://​www.​powershell-knowhow.​de).

1.7 Kontakt zum Autor

Ich freue mich stets, von meinen Lesern zu hören. Sie erreichen mich über meinen Blog (http://​www.​powershell-knowhow.​de) oder per E-Mail unter [e-mail]. Falls Sie an einem PowerShell-Training interessiert sind, auch zu speziellen Themen wie dem Einsatz der PowerShell in der Software-Entwicklung, können Sie mich gerne kontaktieren.

1.8 Danksagungen

Ein Buch ist immer das Ergebnis vieler Monate (teilweise intensiver) Arbeit, an der mehrere Menschen beteiligt sind. Ich möchte mich beim Verlag für die gute und angenehme Zusammenarbeit bedanken und für die Möglichkeit, dieses Buches im Rahmen der Reihe X.systems.press schreiben zu können. Das Buch widme ich meiner Frau Andrea – ohne ihre liebevolle Unterstützung und ihre Inspiration wäre es vermutlich nur bei dem Wunsch ein weiteres PowerShell-Buch zu schreiben geblieben.

Ich wünsche Ihnen viel Spaß beim Lesen, Lernen und Ausprobieren der zahlreichen Beispiele.

Peter Monadjemi, Esslingen am Neckar, August 2014

© Springer Fachmedien Wiesbaden 2014

Peter MonadjemiPowerShell für die Windows-AdministrationX.systems.press10.1007/978-3-658-02964-7_2

2. Ein erster Überblick

Peter Monadjemi¹  

(1)

ActiveTraining, Esslingen, Deutschland

Peter Monadjemi

Email: [e-mail]

2.1 Wie alles anfing – ein kurzer Blick zurück

2.2 Die Stärken der PowerShell

2.2.1 Beispiele für die Konsistenz der PowerShell-Befehle

2.3 Ein technischer Überblick über die PowerShell

2.3.1 Die Rolle des.NET Frameworks (.NET-Laufzeit)

2.3.2 PowerShell als Interpreter

2.3.3 PowerShell für andere Plattformen?

2.3.4 Die Rolle des PowerShell-Hosts

2.4 Download und Installation

2.5 Zielgruppe und Anwendungsbereiche

2.6 PowerShell lernen

2.6.1 RT(F)M

2.6.2 Die Neuerungen der Version 4.0

2.7 Zusammenfassung

In diesem Kapitel lernen Sie die Windows PowerShell von Microsoft (im Folgenden einfach nur „PowerShell genannt) als eine moderne Alternative zur klassischen Windows-Befehlszeile, den Stapeldateien und dem Windows Scripting Host (WSH) kennen. Es wird deutlich werden, dass die PowerShell sehr viel mehr ist als eine klassische „Command-Shell und Administratoren durch sie Möglichkeiten erhalten, die über das Eingeben von Befehlen und Ausführen von Skripten hinausgehen. Diese Möglichkeiten bestehen z. B. in dem Einbeziehen unterschiedlicher Datenquellen als Teil einer Befehlskette (etwa Daten, die das Betriebssystem liefert, die Ergebnisse von Datenbankabfragen, Rückgabewerte von Webservice-Aufrufen usw.), dem Verknüpfen der abgerufenen Daten und dem Umwandeln in Standardformate (CSV, HTML, XML oder JSON), die eine Weiterarbeitung und Darstellung der abgerufenen Daten in anderen Anwendungen erlauben. Die PowerShell ist zudem weniger eine klassische Konsolenanwendung, sondern eher ein „Funktionsbaustein, der in unterschiedliche Host-Anwendungen eingebaut wird. Die PowerShell ist daher ein „polymorphes Werkzeug, das sich in unterschiedlichen Situationen und Umgebungen einsetzen lässt. Als klassische Command-Shell genauso wie als Teil einer Windows- oder Webanwendung oder als ein Windows-Workflow, der über einen längeren Zeitraum eine festgelegte Folge von Anweisungen ausführt. Über PowerShell-Remoting besteht die Möglichkeit, einen PowerShell-Prozess auf anderen Computern im Netzwerk zu starten und damit Befehle und Skripte auf diesen Computern auszuführen. Dank PowerShell-Remoting wird die Reichweite einer administrativen Lösung daher auf das gesamte Netzwerk erweitert. Anders als die klassische Command-Shell Cmd.exe, die seit ihrer Einführung mit Windows NT im Jahr 1993 lediglich ein Zubehörprogramm unter vielen ist, besitzt die PowerShell bei Microsoft auch eine strategische Bedeutung. Es ist ein erklärtes Ziel des Konzerns, dass ein Großteil der Funktionalität von Windows Server per PowerShell ansprechbar sein soll. Damit lassen sich Automatisierungsszenarien auch auf jene Bereiche ausweiten, wie z. B. das Bereitstellen von Windows-Installationen im Unternehmensnetzwerk, die bislang nur mit speziellen Befehlszeilentools oder über die GUI abbildbar waren. Es spricht daher vieles dafür, dass die PowerShell schnell zu einem Werkzeug werden wird, dass Sie viele Jahre begleiten wird.

2.1 Wie alles anfing – ein kurzer Blick zurück

Am Anfang stand eine Vision. Jeffrey Snover , ein Entwicklungsingenieur bei Microsoft in Redmond, hatte eine klare Vorstellung davon, wie ein Verwaltungswerkzeug aussehen müsste, das auch in Zukunft allen Ansprüchen der modernen Windows Server-Administration gerecht werden würde. Motiviert wurde er vermutlich durch die in diesem Jahr erschienene Anwendungsplattform.NET Framework¹ und den Umstand, dass Microsoft diesen wichtigen Bereich viele Jahre vernachlässigt hatte und die Konkurrenz, vor allem in Gestalt von Linux, in diesem Punkt einiges mehr zu bieten hatte.

Die fünf Forderungen, die Mr. Snover bereits im Jahre 2002 formuliert hatte, hat er in seinem Monad-Manifesto zusammengefasst („Monad " war der erste Codename der späteren PowerShell²), das unter http://​www.​jsnover.​com/​blog/​2011/​10/​01/​monad-manifesto als PDF-Datei zur Verfügung steht. In seinem Papier beschreibt Mr. Snover fünf Punkte, die eine künftige „Universal-Shell" als Eigenschaften besitzen sollte:

1.

Ein Automatisierungsmodell (das auf dem.NET Framework basiert).

2.

Eine Command Shell (die ebenfalls auf dem.NET Framework basiert).

3.

Ein Managementmodell, das Klassen zur Verfügung stellt, mit deren Hilfe sich im Alltag häufig auftretende Anforderungen (z .B. Authentifizierung bei einem Remote-Zugriff) umsetzen lassen.

4.

Remote-Scripting auf der Basis von Webservice-Aufrufen.

5.

Eine (natürlich auf dem.NET Framework) basierende Managementkonsole als Nachfolger der mit Windows 2000 eingeführten Computermanagementkonsole.

Von den fünf Punkten sind vier in der aktuellen Version der PowerShell bereits umgesetzt. Lediglich ein Nachfolger der betagten Computermanagementkonsole (MMC) wurde bis heute nicht realisiert³. Da Mr. Snover inzwischen als „Lead Architect" die Windows Server-Gruppe bei Microsoft leitet, könnte aus einer neuen Managementkonsole auf der Basis von PowerShell-Befehlen vielleicht noch etwas werden.

Die erste Version der PowerShell erschien im November 2006. Auch wenn sich am Kern bis heute nichts grundsätzlich geändert hat, dürfte damals noch nicht abzusehen gewesen sein, welchen Funktionsumfang die PowerShell ein paar Jahre später besitzen würde. Umfasste die Version 1.0 bescheidene 129 interne Befehle (Cmdlets), stehen bei Windows Server 2012 R2 und Windows 8.1 aktuell ca. 2500 PowerShell-Befehle als Teil des Betriebssystems zur Verfügung (wenn alle Features des Betriebssystems installiert wurden). Auch wenn Quantität nicht automatisch Qualität bedeuten muss, macht die Zahl eindrucksvoll deutlich, wie funktional reichhaltig die PowerShell als Werkzeug für Administratoren in der aktuellen Windows-Version geworden ist. Dabei muss berücksichtigt werden, dass jeder PowerShell-Befehl eine einheitliche Syntax besitzt, die Hilfe zu jedem Befehl Beispiele umfasst und automatisch zur Verfügung steht, sobald das entsprechende Windows Feature hinzugefügt wurde. Der Einarbeitungsaufwand ist damit deutlich geringer als es die große Zahl an Befehlen eventuell suggeriert Tab. 2.1.

Tab. 2.1

Die Versionsgeschichte der Windows PowerShell

aWenn Sie diese Zeilen lesen, könnte die Version bereits offiziell verfügbar sein

2.2 Die Stärken der PowerShell

Als die Version 1.0 der PowerShell im Herbst 2006 auf der Bildfläche erschien, war es nicht so, dass es bis dahin ein Mangel an Administrationswerkzeugen gegeben hätte. Mit Cmd.exe, den darauf aufbauenden Stapeldateien und dem Windows Scripting Host (WSH) waren zwei Automatisierungswerkzeuge bei Windows bereits fest eingebaut. Durch populäre Tools wie AutoIt und Kixtart, und verschiedene proprietäre Tools wurde das Angebot abgerundet. Wem das nicht genügte, der konnte PerlScript, ooREXX oder die Unix-Tools im Rahmen von CygWin benutzen. Eine weitere Alternative zu den etablierten Werkzeugen musste daher ein paar innovative Eigenschaften besitzen.

Es sind genau drei Stärken, die die PowerShell attraktiv machen:

1.

Die Entwickler der PowerShell haben sich einfache, aber wirksame Konventionen ausgedacht, z. B. für die Namensvergabe von Befehlen, die das Einarbeiten in die PowerShell deutlich erleichtern. Diese tragen zur Konsistenz bei der Befehlssyntax bei, die wiederum die Einarbeitung erleichtert.

2.

Viele Funktionen sind „selbst entdeckbar (im Original heißt dieses Merkmal „Auto Discovery). Darunter fallen Kleinigkeiten wie der Umstand, dass die Namen von Befehlen, deren Parameter und teilweise auch deren mögliche Werte per [Tab]-Taste abgefragt werden können. Dazu zählt der Umstand, dass Befehle durch Metadaten ergänzt werden, über die sich z. B. Informationen über ihre Parameter abrufen lassen.

3.

Anders als die vielen kleinen Befehlszeilentools, die es bei Windows Server seit vielen Versionen gibt, besitzt die PowerShell auch eine strategische Bedeutung. Das bedeutet unter anderem, dass die PowerShell Bestandteil aller Windows Server-Produkte ist und kontinuierlich weiterentwickelt wird.

Ein weiterer Aspekt, der inzwischen für die PowerShell spricht, ist der Umstand, dass es sehr viel Know-how im Internet gibt. Um es einmal überspitzt zu formulieren: Es dürfte schwer sein auf eine Problemstellung zu kommen, für die nicht irgendjemand aus der weltweiten PowerShell-Community, die aber eher ein loser Verbund als ein organisiertes Gebilde ist, bereits eine Lösung gefunden und im Rahmen seines Blogs oder auf den bekannten PowerShell-Skriptportalen veröffentlicht hat.

Tipp

Eine sehr gute Informationsquelle ist das englischsprachige PowerShell-Magazine (http://​www.​powershellmagazi​ne.​com).

2.2.1 Beispiele für die Konsistenz der PowerShell-Befehle

Wie vorteilhaft sich die Konsistenz der PowerShell-Befehlssyntax auswirkt, in dem sie die Eingabe von Befehlen und das Erlernen der Befehlssyntax erleichtert, sollen die folgenden Beispiele für Systemabfragen deutlich machen. Im Folgenden werden eine Reihe von Abfragen vorgestellt, die sich auf unterschiedliche Themenbereiche beziehen. Dabei geht es nur um den allgemeinen Aufbau eines Befehls. Die Details werden in den folgenden Kapiteln vorgestellt.

Der erste Befehl gibt die Eckdaten zu allen Prozessen zurück, die aktuell mehr als 50 MB Arbeitsspeicher belegen:

A316308_1_De_2_Figa_HTML.gif

Der nächste Befehl gibt die Eckdaten zu allen Systemdiensten zurück, die aktuell nicht laufen:

A316308_1_De_2_Figb_HTML.gif

Der folgende Befehl listet alle Hyper-VMs auf, die aktuell ausführen:

A316308_1_De_2_Figc_HTML.gif

Der folgende Befehl listet ebenfalls virtuelle Maschinen auf, dieses Mal aber basierend auf einer VMWare-Virtualisierung:

A316308_1_De_2_Figd_HTML.gif

Wenn die vier vorgestellten Befehle eines gemeinsam haben, dann dass sie sich bezüglich ihrer Schreibweise sehr ähnlich sind.

Der folgende Befehl entspricht dem ersten Befehl, nur dass dieses Mal die erweiterte Abfragesyntax verwendet wird, die bei der PowerShell 2.0 die einzige Option war:

A316308_1_De_2_Fige_HTML.gif

Ab der Version 3.0 steht bei Where-Object alternativ die bereits vorgestellte vereinfachte Schreibweise zur Auswahl.

Auch wenn die Details zu den einzelnen Befehlen an dieser Stelle noch keine Rolle spielen sollen, haben die Beispiele eines deutlich gemacht: Die Schreibweise ist in allen Fällen ähnlich bis sogar identisch, da es für PowerShell-Commands eine Reihe von Konventionen gibt. Dazu gehört vor allem die Namensregel, nach der sich der Name jedes Cmdlets aus zwei Bestandteilen zusammensetzt, die immer mit einem Bindestrich getrennt werden: Einem Verb bzw. verbähnlichen Wort, das eine Aktion bezeichnet, und einem Hauptwort, das den Gegenstand der Aktion benennt. Einfach und effektiv. Mehr zu den Konventionen erfahren Sie in Kap. Kap.  4, in dem die PowerShell-Commands vorgestellt werden.

2.3 Ein technischer Überblick über die PowerShell

Für reine Anwender (Administratoren, IT-Pros und alle, die die PowerShell in erster Linie als Anwendungswerkzeug sehen) ist die PowerShell eine Host-Anwendung (z. B. PowerShell-Konsole oder PowerShell ISE), die sie als klassische Blackbox verwenden. Man gibt Befehle ein, führt Skripte aus, das Innenleben spielt keine Rolle. Aus der Perspektive eines Software-Entwicklers besteht die PowerShell aus mehreren.NET Framework-Assemblies (Dateien mit der Erweiterung.Dll, die sog. „Managed Code enthalten, der von der.NET-Laufzeit ausgeführt wird), die von einem Host-Programm geladen werden. Microsoft stellt mit Powershell.exe (Konsole) und Powershell_ISE.exe (eine Windows-Anwendung) gleich zwei Hosts als Teil von Windows zur Verfügung. Auch andere Hersteller, kleine Softwarefirmen, Administratoren mit Entwicklerkenntnissen und theoretisch auch jeder „Hobby-Programmierer kann die PowerShell-Assemblies mit wenig Aufwand in seine C#- oder Visual Basic-Programme einbauen und damit die PowerShell-Befehle als Teil seiner Anwendung ausführen. Dieses „Hosting" der PowerShell-Engine wird in Kap. Kap.  25 („PowerShell für Entwickler") an einem kleinen Beispiel vorgestellt.

2.3.1 Die Rolle des.NET Frameworks (.NET-Laufzeit)

Das.NET Framework , auch mit.NET-Laufzeit oder einfach nur.NET bezeichnet (wobei der unscheinbare Punkt wie „dot" ausgesprochen wird), ist der Unterbau der PowerShell. Das.NET Framework ist eine Laufzeitumgebung, die von Microsoft als Antwort auf die Bedrohung des Windows-Monopols durch Java entwickelt und im Jahr 2002, begleitet von einer großen Marketingkampagne, veröffentlicht wurde⁴.. Heute verfolgt der Konzern bekanntlich andere Interessen (Stichwort: „Mobile and Cloud first) und setzt auf andere Techniken, das.NET Framework gibt es als festen Bestandteil jeder Windows-Version aber nach wie vor. Es besteht im Kern aus einer virtuellen Maschine, der Common Language Runtime (CLR), die „Managed Code ausführt. Managed Code besteht aus Befehlen der Microsoft-Programmiersprache IL (Intermediate Language) und ist in einer Assembly-Datei enthalten. Die PowerShell basiert auf einer Reihe solcher Assemblies (u. a. System.Management.Automation.dll), womit sich der Kreis schließt. Die Entwickler der PowerShell haben sich damals für das.NET Framework als Unterbau entschieden, da mit der.NET-Laufzeit von Anfang an eine reichhaltige Anwendungsfunktionalität zur Verfügung steht, die sowohl von der PowerShell als auch von PowerShell-Skripten genutzt werden kann. Außerdem ist das direkte Einbetten von z. B. Programmbefehlen der Programmiersprachen C# oder Visual Basic in einem PowerShell-Skript möglich. Dies erweitert zum einen die Möglichkeiten von PowerShell-Anwendern und macht die PowerShell zum anderen auch für Entwickler attraktiv. Die Abhängigkeit der PowerShell zur.NET-Laufzeit war in der Anfangszeit insofern ein Problem, da die.NET-Laufzeit damals noch separat verteilt werden musste und nicht als gegeben vorausgesetzt werden konnte. Spätestens seit Windows Server 2008 R2 und Windows 7 ist sie ein fester Bestandteil des Betriebssystems und steht damit immer zur Verfügung.

Tabelle 2.2 stellt die PowerShell-Versionen der Version des.NET Framework gegenüber, auf der die jeweilige Version aufsetzt. Diese Abhängigkeit muss bei der Installation der PowerShell berücksichtigt werden.

Tab. 2.2

Die PowerShell-Versionen und die erforderlichen.NET Framework-Versionen

2.3.2 PowerShell als Interpreter

PowerShell-Skripte werden grundsätzlich interpretiert ausgeführt. Das bedeutet konkret, dass ein PowerShell-Skript Befehl für Befehl abgearbeitet wird. Es gibt keinen Compiler, der aus PowerShell-Befehlen vor der Ausführung IL-Code oder gar Maschinencode macht (auch nicht von anderen Firmen). Allerdings ist die PowerShell seit der Version 3.0 kein klassischer Interpreter mehr. Jeder Befehl wird bereits während der Eingabe in einen sog. „Abstrakten Syntaxbaum (engl. „Abstract Syntax Tree, kurz AST) zerlegt, der die Bestandteile des Befehls als Tokens (Symbole) enthält und bei der Ausführung Token für Token abgearbeitet wird. Bei der PowerShell ISE macht sich dieser Aspekt u. a. dadurch bemerkbar, dass Befehle bereits unmittelbar nach der Eingabe angezeigt und z. B. auch fehlende geschweifte Klammern in einem Skript als Fehler angezeigt werden.

2.3.3 PowerShell für andere Plattformen?

Die PowerShell gibt es für Windows ab Version XP SP3 und Windows Server 2003 in der Version 2.0 bzw. ab Windows 7 und Windows Server 2008 R2 für alle übrigen Versionen. Es gibt sie außerdem für Windows RT. Andere Plattformen werden nicht unterstützt. Ein vor vielen Jahren begonnenes Open Source-Projekt mit dem Namen „Pash", das das Ziel hatte, die PowerShell (auf der Basis des zum.NET Framework kompatiblen Open Source Frameworks Mono) nach Linux zu portieren, kam über erste Ansätze nicht hinaus⁵. Von Microsoft gibt es zur Zeit (Stand: Mai 2014) keinerlei Bestrebungen, die PowerShell auf andere Plattformen zu portieren⁶. Eine Ausnahme ist das Thema „Desired State Configuration" (DSC).

Im Zusammenhang mit der Open Management Infrastructure-Initiative (OMI) hat Microsoft bereits vor einigen Jahren den Quellcode für einen CIM-Manager freigegeben, mit dem sich (WMI-) Abfragen und Befehle gegen alle Geräte ausführen lassen, auf denen dieser CIM-Manager implementiert wurde. Auf der Grundlage eines solchen OMI-CIM-Server hat Microsoft im Mai 2014 „Windows PowerShell Desired State Configuration for Linux" angekündigt. Damit lassen sich im Rahmen der mit PowerShell 4.0 eingeführten Desired State Configuration (Kap. 20) Konfigurationseinstellungen auch auf Linux-Server übertragen.

2.3.4 Die Rolle des PowerShell-Hosts

Der (PowerShell-) Host ist die Anwendung, die die einzelnen PowerShell-Bibliotheken (Assemblies) unter einem Dach zusammenfasst und damit für den Anwender zugänglich macht. Abbildung 2.1 stellt den Zusammenhang zwischen dem PowerShell-Host und dem Unterbau in einer Übersicht dar. Microsoft stellt mit Powershell.exe (Konsole) und PowerShell_ISE.exe (Windows) zwei Hosts zur Verfügung. Es gibt eine Reihe weiterer Hosts, bei denen es sich in erster Linie um Alternativen zur PowerShell ISE handelt, wie Power GUI, PowerGUI Script Editor, PowerShell Plus und PowerShell Studio.

A316308_1_De_2_Fig1_HTML.gif

Abb. 2.1

Das Zusammenspiel zwischen Host und PowerShell-Funktionalität

Jede Host bietet dieselbe PowerShell-Funktionalität an, implementiert aber unter Umständen nicht denselben Funktionsumfang, was z. B. die Möglichkeiten der Ausgabe betrifft.

2.4 Download und Installation

Microsoft stellt die Versionen 2.0 bis (aktuell) 4.0 als Updates zur Verfügung, die aber nicht automatisch verteilt, sondern von der Microsoft-Webseite heruntergeladen werden müssen. Der Download heißt aber nicht „PowerShell, sondern „Windows Management Framework (WMF), das neben der PowerShell weitere Komponenten, wie Windows Remoting (WinRM), umfasst(Abb  2.2). Tabelle 2.3 stellt die einzelnen Downloads mit ihren KB-Nummern zusammen.

Tab. 2.3

PowerShell-Downloads im Überblick

A316308_1_De_2_Fig2_HTML.gif

Abb. 2.2

Die Bestandteile des Windows Management Framework 3.0

Der Umstand, dass man zwischen mehreren Versionen der PowerShell (in erster Linie 3.0 und 4.0) wählen kann und daher auf mehreren Arbeitsplätzen im Unternehmen unterschiedliche Versionen installiert sein können, wirft natürlich zahlreiche Fragen auf. Diese werden im Folgenden im Stile eines FAQ beantwortet. Soviel bereits vorab: „Probleme" sollte der Umstand, dass ein Skript auf einem Arbeitsplatz von einer Version 2.0, auf dem anderen Arbeitsplatz von einer Version 4.0 der PowerShell ausgeführt wird, nur in seltenen Ausnahmefällen bereiten (und dann lassen sie sich auch mit einfachen Mitteln lösen).

Frage

Kann ein mit der PowerShell 2.0 erstelltes Skript unter den Nachfolgeversionen ausgeführt werden?

Antwort

Grundsätzlich ja. Mit jeder Nachfolgeversion gibt es eine Reihe von kleineren „breaking changes (also Änderungen, die dazu führen können, dass ein Skriptbefehl nicht mehr so funktioniert wie unter der Vorgängerversion und daher zu einem Fehler führen kann), doch sind dies Spezialfälle, die im Praxisalltag nur selten auftreten. Die „breaking changes werden von Microsoft in einer Begleitdatei der aktuellen Version dokumentiert.

Frage

Kann ein mit der PowerShell 4.0 erstelltes Skript von der PowerShell 2.0 ausgeführt werden?

Antwort

Grundsätzlich ja, es darf nur keine Befehle und Operatoren verwenden, die erst mit einer Nachfolgeversionen eingeführt wurden. Die PowerShell bietet für diesen Fall das Schlüsselwort #requires , über das die Versionsnummer angegeben wird, die für die Ausführung eines Skripts vorausgesetzt wird. Dadurch kann der Fall nicht auftreten, dass ein Skript, das Befehle verwendet, die es bei der PowerShell 2.0 noch nicht gibt, von einem PowerShell 2.0-Host ausgeführt wird und die Fehler erst im Verlauf der Skriptausführung auftreten.

Frage

Spielt die Plattform (32 und 64 Bit) für die Ausführung eines PowerShell-Skripts eine Rolle?

Antwort

Nein, sofern keine plattformspezifischen Merkmale angesprochen werden.

2.5 Zielgruppe und Anwendungsbereiche

Wer ist die anvisierte Zielgruppe der PowerShell? Die PowerShell versteht sich als universelles Werkzeug, das für jeden Windows-Anwender gedacht ist, der Befehle über die Tastatur eingegeben und/oder beliebige Abläufe mit Hilfe von Skripten automatisieren möchte. Die Zielgruppe sind daher nicht nur die klassischen Windows-Administratoren (wenngleich sich dieses Buch auf genau jene Zielgruppe fokussiert), sondern auch „IT-Pros, die eine Alternative zur GUI oder zum Remote Desktop für eine Fernwartung suchen und theoretisch auch Studenten und Hobby-Programmierer, die am Beispiel der ab Windows 7 fest eingebauten „Skriptsprache das Programmieren erlernen möchten⁷. Dieser Hinweis ist dem Autor wichtig: Die PowerShell ist kein Entwicklerwerkzeug. Wer die PowerShell effektiv für „alles Mögliche" einsetzen möchte, benötigt daher keine Programmierkenntnisse, denn es gibt nichts zu programmieren. Natürlich sind Vorkenntnisse in der Programmierung hilfreich, um bestimmte Zusammenhänge und Fachbegriffe zu verstehen, erforderlich sind sie nicht. Und natürlich gibt es einen fließenden Übergang zwischen einem PowerShell-Skript, das ein paar (Dutzend) Befehlszeilen enthält, und einem großen PowerShell-Skript mit mehreren Tausend Zeilen, das bereits die Aufgaben einer klassischen Anwendung übernimmt. Die primäre Zielgruppe der PowerShell sind Administratoren und IT-Pros, keine Entwickler.

Es ist daher wichtig zu verstehen, dass Microsoft die PowerShell für eine breite Palette an Anwenderprofilen konzipiert hat. Diese reicht vom Gelegenheitsanwender, der die PowerShell nur gelegentlich aufruft, bis zum „Power-User", der sie jeden Tag verwendet und damit komplexere Automatisierungsanforderungen umsetzt. Auch für Software-Entwickler kommt die PowerShell natürlich in Frage. Zum einen ist sie seit Visual Studio 2012 in Gestalt des Paket-Managers ein fester Bestandteil von Visual Studio, zum anderen gibt es eine Projektvorlage für Visual Studio 2013 von PowerShell-Experte Adam Driscoll, so dass sich PowerShell-Skripte auch in Visual Studio eingeben und ausführen lassen (weitere Infos erhalten Sie unter http://​csharpening.​net/​?​p=​1697 und in Kap. 25)⁸.

Es ist wichtig zu verstehen, dass die PowerShell trotz ihres Potentials kein Spezialwerkzeug ist, das hohe Anforderungen an die Fähigkeiten seiner Anwender stellt. Dass Microsoft mit der PowerShell auch Administratoren ansprechen möchte, die die PowerShell nur gelegentlich benötigen und keine Zeit oder Interesse haben, sich in die Details einzuarbeiten, machen verschiedene Vereinfachungen deutlich, die bereits mit der Version 3.0 eingeführt wurden.

Auch wenn es aufgrund der universell angelegten Natur der PowerShell keine Anwendungsgebiete gibt, für die sie hauptsächlich geschaffen wurde, gibt es natürlich Einsatzgebiete, für die sie aufgrund ihrer Eigenschaften sehr gut geeignet ist.

Die folgende Aufzählung erhebt keinen Anspruch auf Vollständigkeit:

Ad hoc-Administration, z. B. Abfragen des Status von Diensten, lokal wie im Netzwerk.

Automatisieren von Abläufen durch Skripte. Dieser Bereich wird ab Windows Server 2012 durch den Umstand erleichtert, dass ein Großteil der Server-Funktionalität über PowerShell-Commands angesprochen werden kann.

Auswerten von Daten, die z. B. im CSV- oder XML-Format vorliegen.

Konfigurations- und Login-Skripte.

Alle Aktivitäten, die etwas mit dem Active Directory zu tun haben.

Implementieren länger laufender Abläufe über Workflows.

Eine Frage, die man als Administrator gleich zu Beginn klären sollte, ist: Brauche ich die PowerShell überhaupt? Zwar ist es relativ einfach mit der PowerShell zu beginnen und ein paar Abfragen auszuführen. Wer die PowerShell für komplexere Abläufe einsetzen möchte, muss sich darüber im Klaren sein, dass sowohl die Einarbeitung als auch die Umsetzung eines solchen Ablaufs eine (relativ) zeitintensive Angelegenheit ist.

Es gibt (mindestens) drei Situationen, in denen die PowerShell als Werkzeug im administrativen Alltag wirklich benötigt wird:

1.

Wenn ein flexibles Abfragetool (auf der Basis einer Befehlszeile) benötigt wird.

2.

Wenn die Notwendigkeit für eine Automatisierung von Abläufen gegeben ist (oft als Ablöse für Stapeldateien oder WSH-Skripte).

3.

Wenn ein spezielles „Admintool" umgesetzt werden soll (auch mit GUI-Oberfläche).

Ist mindestens eine der drei Voraussetzungen erfüllt, ist die PowerShell im Allgemeinen die beste Wahl.

Die Entscheidung für die PowerShell bedeutet nicht eine Entscheidung gegen andere Tools. Befehlszeilentools, die Sysinternals-Tools, WSH-Skripte, JavaScript-Skripts, Stapeldateien usw. können alle innerhalb eines PowerShell-Befehls oder -Skripts hervorragend aufgerufen werden.

2.6 PowerShell lernen

Es gibt mehrere Wege, die PowerShell zu lernen und zu einem PowerShell-Experten zu werden. Es gibt die umfangreichen Hilfedateien, die Teil der PowerShell sind (und vor dem ersten Aufrufen per Update-Help-Befehl aktualisiert werden müssen), es gibt unzählige Webseiten mit PowerShell-Know-how. Auch dieses Buch soll dazu beitragen, dass Sie die PowerShell anwenden und die Hintergründe verstehen. Eine Empfehlung des Autors ist das Online-Schulungsangebot, das Microsoft unter dem Namen Microsoft Virtual Academy (MVA) seit einigen Jahren betreibt, und dessen Angebot stetig erweitert wird. Hier finden Sie auch Kurse zur PowerShell, mit deren Hilfe Sie sich zusätzliches Wissen aneignen und Ihr erworbenes Wissen mit Hilfe von Quiz-Fragen überprüfen können. Die Adresse ist http://​www.​microsoftvirtual​academy.​com .

Der offizielle MOC-Kurs (Microsoft Official Curriculum) für die PowerShell ist 10961A „Windows PowerShell 3.0 für Administratoren".

2.6.1 RT(F)M

RTM („Read the Manual) ist eine in der IT-Szene bekannte Abkürzung. Bei der PowerShell bedeutet sie „Lies einfach einmal die Hilfe. RTFM ist eine moderne Abwandlung des bekannten Akronyms⁹. Damit ist zum einen natürlich die Beschreibung zu den wichtigsten Befehlen gemeint, vor allem aber die allgemeinen Hilfethemen, in denen die Grundlagenthemen der PowerShell anschaulich beschrieben werden. Zu den Pflichtthemen gehören:

About_Window_PowerShell_4.0

About_Command_Syntax

About_Pipelines

About_PowerShell.exe

About_Objects

About_Modules

und

About_Parsing

2.6.2 Die Neuerungen der Version 4.0

Mit der Version kamen eine Reihe interessanter Neuerungen hinzu:

Die wichtigste Neuerung ist die Desired State Configuration (DSC). Sie wird in Kap. Kap.  20 vorgestellt.

Bei Windows Server 2012 R2 ist die Voreinstellung für die Ausführungsrichtlinie „RemoteSigned und nicht mehr „Restricted und damit etwas gelockert worden.

Beim Cmdlet Get-Process gibt es den Parameter IncludeUserName, der in einer als Administrator gestarteten PowerShell den Besitzer des Prozesses anzeigt.

Die praktische neue Function Get-FileHash berechnet für eine Datei den Hashwert aus den Byte-Werten des Inhalts.

In der Manifestdatei eines Moduls kann über die Einstellung DefaultCommandPrefix ein Präfix festgelegt werden, der automatisch jedem importierten Command vorangestellt wird.

Im Rahmen eines Workflows wurde der Befehl foreach um den Parameter ThrottleLimit erweitert, über den sich im Zusammenspiel mit dem Parallel-Parameter die Anzahl der gleichzeitig ausführenden Threads festlegen lässt (bislang wurden nicht mehr als 5 Threads gleichzeitig ausgeführt).

Mit PipelineVariable gibt es einen neuen allgemeinen Parameter, über den der aktuelle Inhalt der Pipeline einer Variablen zugewiesen werden kann, damit er im weiteren Verlauf der Pipeline-Verarbeitung der Befehlskette zur Verfügung steht.

Über die Direktive #requires –runasadministrator kann in einem Skript angegeben werden, dass ein Skript nur ausführt, wenn es mit Administratorberechtigungen gestartet wurde.

Das Import-CSV-Cmdlet lässt Leerzeilen aus (und macht daraus keine leeren Objekte).

Das Get-Job-Cmdlet listet auch beendete terminierte Jobs in einer Remoting-Session auf.

Beim Remove-Item-Cmdlet funktioniert der Recurse-Parameter richtig, indem auch die Elemente in den Unterverzeichnissen entfernt werden.

Das Get-Module-Cmdlet zeigt die Versionsnummer eines (Manifest-) Moduls an. Über die Parameter MinimumVersion und RequiredVersion kann eine bestimmte Version eines Moduls angefordert werden. Damit lässt sich erreichen, dass eine Abhängigkeit zu einer bestimmten Version eines Moduls hergestellt wird. Ist diese Version nicht vorhanden, ist beim Laden eine Fehlermeldung die Folge.

2.7 Zusammenfassung

Die Windows PowerShell wurde im Herbst 2006 von Microsoft in der Version 1.0 freigegeben. Seit Windows Server 2008 R2 und Windows 7 ist sie sowohl ein fester Bestandteil des Betriebssystems als auch ein freier Download für alle Windows-Versionen, die die Anforderungen der jeweiligen Version erfüllen.

Die PowerShell in einem Satz erklärt: „Die PowerShell ist eine Anwendung zur Ausführung von Befehlen, bei denen Objekte und eine Objekt-Pipeline im Mittelpunkt stehen".

Fußnoten

1

Microsofts Antwort auf Java.

2

Namensähnlichkeiten zum Namen des Autors dieses Buches sind rein zufällig.

3

Zeitweise war ein solcher Nachfolger unter dem Codenamen „Aspek" in Arbeit, doch das Projekt wurde offenbar wieder eingestellt.

4

Java ist eine Kombination von Programmiersprache und Laufzeitumgebung, die Mitte der 90er Jahre von der Firma Sun veröffentlicht wurde und heute zu Oracle gehört. Java versprach damals, dass eine Anwendung nur einmal entwickelt werden musste und danach auf allen Plattformen und im Browser ausführen konnte. Wären alle Anwender auf Java umgestiegen, wäre Windows überflüssig geworden. Wie wir heute wissen, hat Java am „Windows-Monopol" nicht allzu viel geändert.

5

Inzwischen hat das von Igor Moochnik ursprünglich gestartete Projekt einen neuen Besitzer und unter GitHub ein neues zu Hause gefunden und wird offenbar weiterentwickelt – https://​github.​com/​Pash-Project/​Pash.

6

Wenngleich PowerShell-Erfinder Jeffrey Snover auf