Was ist Windows Powershell? Shell-Power von und für Microsoft

Die Veröffentlichung der Powershell 1.0 im Jahr 2006 verhalf Microsofts Server-Betriebssystem zu einer mächtigen Skriptsprache, die Windows erstmals vollständig automatisierbar machte. Microsofts Kommandoschnittstelle hat seitdem mächtig an Popularität gewonnen und ist nunmehr Open Source.

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

Microsoft Deutschland GmbH

Das modulare Konzept von Powershell hat sogar im Nicht-Microsoft-Umfeld enormen Anklang gefunden. So gehört etwa VMware mit seiner als Powershell-Modul realisierten „PowerCLI“ zu den frühesten Adaptoren der Microsoft-Technologie und muss sich gefallen lassen, dass VMware-Administratoren die PowerCLI heute den älteren, VMware-eigenen und Perl-basierten Automatisierungsschnittstellen den Vorzug geben.

Wo Powershell drin ist

Bei der Windows Powershell handelt es sich genau wie beim jüngeren Powershell Core (PSCore) um ein plattformübergreifendes Framework von Microsoft, das vor allem der Automatisierung, aber auch der Konfiguration und Verwaltung von Windows-Systemen dient. Die Powershell besteht aus einem Kommandozeileninterpreter UND einer sehr mächtigen Skriptsprache, die sowohl objektorientierte Merkmale, als auch Konzepte aus der Unix-Welt wie zum Beispiel „Pipelining“ vereint.

Konkret basiert Powershell Core auf der .NET Core Common Language Runtime (CoreCLR), die Microsoft im Jahr 2016 als plattformübergreifendes Open-Source-Projekt unter der MIT-Lizenz für Linux, MacOS X und Windows verfügbar machte. Demgegenüber beruht die klassische Windows Powershell auf der Common Language Runtime (CLR) des .NET Framework und wird von Microsoft zusammen mit Windows als Komponente des „Windows Management Framework“ (WMF) unter einer proprietären Lizenz ausgeliefert.

Irritierende Gerüchteküche

Zudem liefert Microsoft die seit 2016 existierende „Windows Powershell Core Edition“, die genau wie Powershell Core auf .NET Core basiert, als Teil von „Windows Nano Server“ und „Windows IoT“ aus. Glaubt man aktuellen Blog-Mitteilungen von Microsoft, plant das Unternehmen allerdings in Zukunft ganz auf die CoreCLR-Runtime zu setzen, was dann recht gravierende Auswirkungen für bestehende Produkte hätte.

So ist die .NET-basierte Windows Powershell inzwischen so tief in Windows verankert, dass sogar GUI-Applikationen wie „Active Directory Administrative Center“ intern auf Powershell-CMDlets basieren. Auch Anwendungen wie „MS Exchange 2007“ sind vollständig nur über die Powershell administrierbar, wobei die funktional eingeschränkte GUI ebenfalls auf Powershell basiert. Auch die Windows Server-, Core- und Nano-Editionen sind auf Powershell angewiesen.

Was vorher war

Auch wenn sich Windows gegenüber Unix und Linux von je her durch die grafische Benutzeroberfläche abzuheben versucht, brachte jede Version eines Microsoft-Betriebssystems seit MS-DOS einen Kommandozeileninterpreter mit. Bei DOS und Windows 9x waren das COMMAND.COM und ab der Windows-NT-Familie CMD.EXE. Letztere bietet jedoch nur eine Handvoll Standard-Befehle, erlaubt aber das Starten weiterer Konsolen-Anwendungen und verfügt über eine einfache Skriptsprache, die bei einem Server zwingend notwendig ist, um Aufgaben automatisieren zu können.

Allerdings ließen sich mit CMD bei weitem nicht alle vorstellbaren Aufgaben automatisieren und das historisch gewachsene Konstrukt krankte an der inkonsistenten Bedienung der einzelnen Konsolen-Anwendungen. Zwar versuchte Microsoft ab 1998 mit Windows Script Host Windows 98 skriptfähig zu machen, allerdings adressierte die Lösung vorrangig Entwickler und war kaum zur direkten Administration von Windows via CLI geeignet. Automatisierung an sich war aber immerhin schon im größeren Umfang möglich, weil Script Host sämtliche COM-Komponenten ansprechen konnte.

Daher erarbeitete man bei Microsoft im Jahr 2002 einen völlig neuen Ansatz für die vollständige Automatisierung von Windows im Rahmen des so genannten Monrad-Projekts, das einige herausragende Eigenschaften haben sollte. So sollten Administratoren schnell und einfach eigene Befehle programmieren können, was beispielsweise eine einheitliche Parser-Konsistenz erfordert.

Eine weitere Forderung bestand darin, das von Unix inspirierte Pipelinig-Konzept zu übernehmen, wobei im Gegensatz zu Unix stets Objekte, also strukturierte Daten anstelle von Text übergeben werden sollten, was einer Vereinfachung der Weiterverarbeitung dient. Ferner sollten sich Skripte auf einer Vielzahl von Remote-Computern ausführen und sich auch grafische Oberflächen einbinden lassen.

Geschichte der Powershell

Microsoft führte das im Monrad.Projekt formulierte Konzept weiter und zeigte im Jahr 2003 die so genannten Monrad-Shell (MSH). Die mündete im Jahr 2005 in eine erste Beta-Version von Monrad, welche Microsoft 2006 anlässlich der Veröffentlichung der Version 1.0 in Powershell umbenannte und zum Herunterladen freigab. „Microsoft Exchange Server 2007“ war das erste Produkt, das voll und ganz für die neue Powershell konzipiert wurde.

Das erste (optional) mit Powershell 1.0 ausgelieferte Microsoft-Betriebssystem war „Windows Server 2008“. Die Powershell-Version 2.0 war dann 2009 bereits eine feste Komponente von Windows Server 2008 R2 beziehungsweise Windows 7 und stand erstmals auch als Download-Variante für ältere Windows-Versionen bereit. Aktuelle Windows Versionen (Windows Server 2016 und Windows 10) werden mit der Powershell-Version 5.1 ausgeliefert.

Aufbau und Konzept

Konzeptionell kombiniert Powershell Unix-inspirierte Technologien wie Pipes und Filter mit dem Paradigma objektorientierter Programmierung. So kann der Nutzer wahlweise sowohl simple Kommandos an einer Eingabeaufforderung absetzen und auch miteinander verknüpfen, als auch komplexe Skript-Programme in der Powershell Scripting Language verfassen. Dabei erlaubt die Powershell Zugriff auf WMI-Klassen, COM-Objekte und das vollständige .NET Framework.

Die so genannte Powershell Engine (Powershell Runtime) fungiert dabei als Kommandozeileninterpreter, der die Nutzereingaben entgegennimmt. Intern ist die Powershell-Engine eine Sammlung von .NET-Klassen, die in einer DLL verpackt sind. Als Benutzerschnittstelle zur Powershell-Engine fungieren so genannte Powershell Hosts.

Im Auslieferungszustand stellen aktuelle Windows-Versionen als Powershell Host die Konsolen-Anwendung „Windows Powershell“ (powershell.exe) und die „Windows Powershell ISE“ (Integrated Script Environment, powershell_ise.exe) zur Verfügung. Bei Letzterer handelt es ich um ein, an klassische grafische Entwicklungsumgebungen angelehntes Eingabe-Fensters, das einen Skripteditor, einen Debugger und IntelliSense integriert. In beiden Varianten kann der Nutzer sowohl CLI-Anwendungen wie „ipconfig“ ausführen, als auch echte Powershell-Cmdlets.

Außerdem lässt sich die ISE durch Addons erweitern. Darüber hinaus stellen auch Verwaltungskonsolen wie das oben erwähne Active Directory Administrative Center oder die Exchange Management Console (EMC) intern Powershell-Hosts dar. Hinzu kommt die Powershell Scripting Language, eine Skriptsprache, mit der Anwender Skripte für die Powershell Engine entwickeln können. Zudem lässt sich die Scripting Language auch zum Erstellen eigener Cmdlets einsetzen. Mit Version 5 hat Microsoft die Skriptsprache zudem um Klassen erweitert.

Die Syntax der Powershell...

Die Syntax der Powershell bietet Elemente von C#, SQL, Perl oder Unix und ist primär für den interaktiven Gebrauch als Shell für administrative Aufgaben optimiert. Die Befehle in einer Powershell-Umgebung heißen Cmdlets. Die Bezeichnung mit der „Verniedlichungsform“ bringt zum Ausdruck, dass es sich um meist sehr kleine, spezialisierte Befehle handelt, die sich nur im Powershell-Kontext ausführen lassen.

Die Cmdlets selbst können also aus wenigen Zeilen Programmcode bestehen oder selbst Powershell-Skripte, beziehungsweise .NET-Klassen sein. Eine weitere Besonderheit vom Cmdlets besteht darin, dass sie Eingaben nicht selber parsen und Fehler nicht selbst darstellen, sondern Ergebnisse als Objekt ausgeben.

Cmdlets sind stets nach dem Schema „Verb-Substantiv“ konstruiert, zum Beispiel „Get-Help“. Das vorangestellte Verb bringt auch die Aufgabenorientierung der Powershell zum Ausdruck. Von der Idee her soll jedes Cmdlet immer genau eine spezifische Aufgabe erfüllen und immer nur einen Objekttyp zurückliefern. Die ausgegebenen Objekte lassen sich dann weiterverarbeiten. So liefert „Get-Command“ eine Liste aller aktuell verfügbaren CMDlets.

...macht eine Menge möglich

Außerdem lassen sich Objekte filtern, etwa mit „…Select-Object -Property Name, Status, Where-Object -Property Status -EQ -Value Stopped“ konvertieren, ausgeben (Out-File, Out-GridView) oder zur Weiterverarbeitung an ein anderes Kommando „pipen“. So errechnet Get-Command | Measure-Object die „Anzahl“ verfügbarer Cmdlets. In Version 5.1 sind es 1829. Alternativ kann man sämtliche „erlaubten“ Verben beispielsweise mit Get-Verb ermitteln. Misst man die Anzahl wieder mit Get-Verb | Measure-Object kommt man aktuell auf 98.

Ferner lassen sich Cmdlets mit Aliasen verknüpfen, was vorrangig dazu dient, Kompatibilität zu alten Skripten oder zur CMD herzustellen. Klassische CMD-Kommandos sind damit auch in der Powershell verfügbar. Darüber hinaus gibt es noch „Parameter“, die verschiedene Eigenschaften haben können, darunter immer einen Standardwert. Parameter können zudem „erforderlich“ sein und akzeptieren selbst auch wieder Werte aus einer Pipe. Welche Parameter für ein Cmdlet verfügbar sind, liefert „Get-Help“, also zum Beispiel Get-Help -Name Get-Command.

Darüber hinaus gibt es noch so genannte Module. Bei Modulen handelt es sich um die von Microsoft bevorzugte Methode zum Veröffentlichen und Laden von Cmdlets in Powershell. Module enthalten immer den Cmdlet-Programmcode (entweder als .NET-Klasse oder Powershell-Skript) sowie ein „Manifest“, das den Inhalt des Moduls beschreibt. Während es bei Powershell 1.0 ausschließlich mit Hilfe von PSSnapins möglich war, Cmdlets zu laden, kommen hierfür aktuellen nur noch Module zum Einsatz.

Möchte man beispielsweise in Windows Server 2012 R2 Core den kompletten Server Manager per Powershell steuern, muss zunächst das Modul „ServerManager“ geladen werden: Import-Module ServerManager. Anschließend stehen die meisten Server-Manager-Kommandos lokal und/oder remote auch in der Powershell zur Verfügung und lassen sich nutzen, etwa …

Get-WindowsFeature

Zukunft der Powershell

Als Microsoft die Öffnung der Powershell für andere Betriebssysteme sowie die quelloffene Freigabe angekündigt hatte, war nicht absehbar, ob und wie sich der Schritt auf Windows auswirken würde. Aufgrund eines Blog-Beitrags von Anfang 2017 scheint nun aber sicher, dass Microsoft die Core-Version künftig auf sämtlichen Plattformen bevorzugen wird.

Die neue Plattformstrategie für die Powershell sorgt demnach nicht nur für die Portierung der Powershell auf Linux und Mac OS. Offenbar zielt Microsoft vorrangig darauf ab, auf allen Systemen einschließlich Windows eine einheitliche Implementierung zu haben. Demnach soll die Windows Powershell, die aktuell in der Version 5.1 noch in Windows 10 und Server 2016 enthalten ist, offenbar nicht mehr weiterentwickelt werden und nur noch Bugfixes erhalten.

(ID:44845217)