PowerShell (auch PowerShell Core) ist ein plattformübergreifendes Framework von Microsoft zur Automatisierung, Konfiguration und Verwaltung von Systemen, das einen Kommandozeileninterpreter inklusive Skriptsprache bietet.PowerShell Readme-Datei auf Github
Windows PowerShell ist eine das .NET Framework nutzende und daher nur unter Microsoft Windows funktionierende Version, die seit Version 5.1 nicht mehr weiterentwickelt wird. Sie basiert auf der Common Language Runtime (CLR) des .NET Frameworks und wird mit Windows als Teil des Windows Management Frameworks (WMF) unter einer proprietären Lizenz ausgeliefert.blogs.msdn.microsoft.com: PowerShell on Linux and Open Source Von Version 5.1 gibt es parallel eine auf .NET Core basierende Core Edition für Windows Nano Server und Windows IoT.
Seit Version 6 basiert PowerShell auf der Core Common Language Runtime (CoreCLR) und ist als plattformübergreifendes Open-Source-ProjektPowerShell auf Github unter der MIT-LizenzPowerShell Lizenz auf Github für Linux, macOS und Windows verfügbar.
Entstehungsgeschichte Eingabeaufforderung Jede veröffentlichte Version von MS-DOS und Windows enthielt eine Kommandozeile oder Eingabeaufforderung (siehe auch Kommandozeileninterpreter). Diese sind COMMAND.COM (in DOS bzw. DOS-basierten Betriebssystemen wie Windows 9x) und cmd.exe (in Betriebssystemen der Windows-NT-Familie). Die Eingabeaufforderung bietet einige Standardbefehle und ermöglicht das Ausführen weiterer Konsolenanwendungen. Darüber hinaus gibt es eine Skriptsprache, um Aufgaben zu automatisieren (siehe Stapelverarbeitungsdatei). Da jedoch nicht alle Funktionalitäten der grafischen Benutzeroberfläche über die Eingabeaufforderung erreichbar sind, können nicht alle Aufgaben automatisiert werden und auch die Skriptsprache ist aufgrund ihrer Einfachheit in der Funktionalität beschränkt. Mit Windows Server 2003 waren die meisten Funktionen auch per Eingabeaufforderung verfügbar, dennoch bleiben die Limitierung der Skriptsprache sowie Inkonsistenzen in der Bedienung unterschiedlicher Konsolenanwendungen.
Microsoft versuchte bereits 1998 einige dieser Limitierungen mit der Einführung von Windows Script Host (cscript.exe) und dessen Unterstützung von JScript und VBScript in Windows 98 zu überwinden. Mit Windows Script Host ist es möglich, alle COM-Komponenten anzusprechen, was die Automatisierung von weiten Teilen des Betriebssystems ermöglicht. Darüber hinaus gibt es in unterschiedlichen Windows-Versionen weitere Kommandozeileninterpreter für spezielle Einsatzgebiete (z. B. netsh zur Netzwerkkonfiguration oder das Windows Management Instrumentation Command-line (WMIC)).
Monad Manifest Jeffrey Snover – ein Verfechter von Kommandozeilen, der 1999 bei Microsoft anfing – unterstützte zunächst Microsoft Windows Services for UNIX (SFU), um Unix-Tools unter Windows nutzen zu können. Da Windows aber nicht wie Unix textorientiert, sondern API-orientiert arbeitet, konnte es letztlich nicht umfassend verwaltet werden (z. B. Setzen von Registry-Werten). Snover entwickelte außerdem die Windows Management Instrumentation Command-line (WMIC).PowerShell.org auf YouTube: Snover Monad Manifesto Revisited 2002 beschrieb er einen neuen Ansatz für die Automatisierung in Windows als Monad Manifest. Darin beschreibt Snover Monad als mächtige, konsistente, erweiterbare und nützliche „Plattform der nächsten Generation“ auf Basis von .NET, mit der der Aufwand für Administratoren reduziert und das Leben von Nicht-Programmierern deutlich vereinfacht werden könne.jsnover.com: Monad Manifesto (PDF; 371 kB) Dies sollte unter anderem durch folgende Punkte erreicht werden: Administratoren können Befehle schneller und einfacher programmieren, da Monad viele Standardaufgaben von Befehlen übernimmt und durch einen einheitlichen Parser Konsistenz bietet. Anstatt Text (unstrukturierte Daten) werden Objekte (strukturierte Daten) an die Pipe übergeben, was die Weiterverarbeitung vereinfacht. Ausführung von Skripts auf einer Vielzahl von entfernten Computern Die Idee von Monad wurde weiterentwickelt. 2003 bei der Professional Development Conference in Los Angeles wurde erstmals die Monad Shell (MSH) gezeigt. 2005 wurden Beta-Versionen veröffentlicht.
PowerShell entsteht und wird Teil von Windows 2006 verkündete Microsoft, dass Monad in PowerShell umbenannt werde. Gleichzeitig wurde verkündet, dass Exchange Server 2007 per PowerShell administriert werde und auch die GUI auf PowerShell aufsetze.blogs.msdn.microsoft.com: Windows PowerShell (Monad) Has Arrived Noch im gleichen Jahr wurde PowerShell 1.0 veröffentlicht und zum Download angeboten.blogs.msdn.microsoft.com: It’s a Wrap! Windows PowerShell 1.0 Released!
Durch die Unterstützung der Exchange- und Datacenter-Verantwortlichen bei Microsoft konnte die PowerShell im Konzern etabliert werden.YouTube: Jeffrey Snover 2015 auf dem DevOps Enterprise Summit über The Cultural Battle To Remove Windows from Windows Server 2007 wurde PowerShell Teil von Microsofts Common Engineering Criteria für 2009, einer Liste von Kriterien, der jedes Microsoft Server-Produkt entsprechen soll. Das bedeutete effektiv, dass ab 2009 jedes Server-Produkt von Microsoft PowerShell unterstützen sollte.blogs.msdn.microsoft.com: PowerShell To Be Added to Common Engineering Criteria Dies war der endgültige Durchbruch für PowerShell als zentrale Verwaltungs- und Automatisierungseinheit in Windows.
2008 wurde Windows Server 2008 das erste Betriebssystem, das mit PowerShell ausgeliefert wird – jedoch noch als optionale Komponente.
2009 wurde PowerShell 2.0 als fester Bestandteil von Windows 7 und Windows Server 2008 R2 veröffentlicht.blogs.msdn.microsoft.com: Windows PowerShell 2.0 RTM Anfang 2010 stand PowerShell 2.0 auch für ältere Betriebssysteme als optionales Update per Windows Update bereit.blogs.msdn.microsoft.com: Windows PowerShell 2.0 on Windows Update
PowerShell wird Open Source und plattformübergreifend 2016 verkündete Microsoft, dass PowerShell unter der MIT-Lizenz Open Source und plattformübergreifend entwickelt wird.azure.microsoft.com: PowerShell is open sourced and is available on Linux Gleichzeitig wurde ein GitHub Repository erstellt und die Alpha-Version von PowerShell Version 6.0 für Windows, Linux und macOS veröffentlicht. Der Hersteller begründete diesen Schritt in seiner Cloud-Strategie. In Microsoft Azure werden nicht nur Windows-, sondern auch eine Vielzahl von Linux-Systemen bereitgestellt. Microsoft bietet PowerShell als universelles Werkzeug für alle Administratoren an, ganz gleich welches Betriebssystem oder welche Anwendung administriert werden soll.
Aufbau Grundsätzliches PowerShell wurde speziell für die Systemverwaltung und -automatisierung entworfen.
Sie verbindet die aus Unix-Shells bekannte Philosophie von Pipes und Filtern mit dem Paradigma der objektorientierten Programmierung. Der Benutzer kann wie bisher einfache Befehle an einer Kommandozeile ausführen und miteinander verknüpfen oder aber auch komplexe Skript-Programme mit der eigens dafür entwickelten PowerShell Scripting Language schreiben.
Die PowerShell erlaubt Zugriff auf WMI-Klassen, COM-Objekte sowie auf das gesamte .NET Framework.
PowerShell Engine Die PowerShell Engine (auch Shell, PowerShell Class oder PowerShell Runtime) ist der Kommandozeileninterpreter, der die Eingaben verarbeitet und damit das Herz der PowerShell. Die Engine ist eine Sammlung von .NET-Klassen, die in einer DLL (System.Management.Automation.dll) gespeichert sind.
PowerShell Host Der PowerShell Host ist die Benutzerschnittstelle zur PowerShell Engine. In Windows steht standardmäßig die Windows PowerShell (auch Konsole) (powershell.exe, bereitgestellt durch conhost.exe) und Windows PowerShell ISE (Integrated Scripting Environment, kurz ISE) (powershell_ise.exe) zur Verfügung. Die ISE ist ein modernes Eingabefenster mit unter anderem integriertem Skripteditor, Debugger und IntelliSense. Beide Hosts erlauben es auch, herkömmliche Kommandozeilenanwendungen auszuführen, wie beispielsweise ipconfig.exe. Jedoch erlaubt die ISE keine Interaktion, wie zum Beispiel bei nslookup.exe. Die ISE kann durch Add-ons erweitert werden; eine bekannte Erweiterung ist ISESteroids. Auch Verwaltungskonsolen, wie etwa die Exchange Management Console (EMC) seit Exchange Server 2007, sind ein Host. Darüber hinaus gibt es auf dem Markt weitere Hosts, wie PowerShell Plus von Idera. Zwar nutzen alle Hosts dieselbe Engine, doch da die Implementierung unterschiedlich sein kann, ist es auch möglich, dass sich die Hosts untereinander unterschiedlich verhalten.
PowerShell Scripting Language (PSL) Die PowerShell Scripting Language (PSL) ist die Sprache um Skripte für die PowerShell Engine zu entwickeln. Ab Version 2.0 kann die Skriptsprache auch verwendet werden, um eigene Cmdlets zu erstellen.
Die PowerShell-Sprache basiert auf dem IEEE 1003.2 POSIX Shell Standard und die Syntax ist an der Programmiersprache C# angelehnt.Bruce Payette, Richard Siddaway: Windows PowerShell in Action. 3. Ausgabe. Manning, Shelter Island 2018, ISBN 978-1-63343-029-7, S. 17–18. Mit Version 5 wurde die Skriptsprache um Klassen erweitert.Bruce Payette, Richard Siddaway: Windows PowerShell in Action. Shelter Island 2018, S. 762.
Anders als bei bisher existierenden objektorientierten Skript-Interpretern (BeanShell, Smalltalk, Python Shell) ist die Syntax der PowerShell-Skriptsprache, welche sich unter anderem Anleihen bei Perl, Unix-Shells, SQL und C nimmt, darauf ausgelegt, auch für den täglichen interaktiven Gebrauch als Shell für administrative Aufgaben wie etwa Dateiverwaltung geeignet zu sein.
Cmdlets Cmdlets (gesprochen Commandlets) werden die Befehle in einer PowerShell-Umgebung genannt. Der Begriff soll verdeutlichen, dass es sich um sehr kleine, spezielle Befehle handelt, etwa wie in Befehlchen. Im Gegensatz zu herkömmlichen Befehlen sind Cmdlets keine Standalone-Anwendungen, das heißt, sie können nicht ohne die PowerShell ausgeführt werden. Cmdlets können .NET-Klassen oder PowerShell-Skripte sein und mit wenigen Zeilen Programmcode geschrieben werden. Cmdlets parsen Eingaben in der Regel nicht selber, stellen Fehler nicht selbst dar und geben Ergebnisse unformatiert als Objekt wieder. Die PowerShell-Engine bzw. Standard-Cmdlets nehmen Cmdlet-Entwicklern Arbeit von Standardaufgaben ab und vereinfachen und beschleunigen die Entwicklung. Gleichzeitig wird die Nutzbarkeit und Lesbarkeit von Skripten und Befehlen durch sehr strikte und ausführliche Namenskonventionen gewährleistet.
Die Anzahl der vorinstallierten Cmdlets steigt mit jeder Version. Sie liegt in der Version 5.1 der Legacy-PowerShell bei 489 Cmdlets und 766 mitgelieferten Funktionen und in der Core-Version 6.1 bei 287 Cmdlets und 145 mitgelieferten Funktionen im Kernpaket und 1900 Cmdlets mit zusätzlichen Modulen.
Cmdlets folgen dem Namensschema Verb-Substantiv, also beispielsweise Get-Help oder Set-Location. Cmdlets sind durch das vorangestellte Verb aufgabenorientiert, sollen genau eine spezifische Aufgabe erfüllen und nur einen Objekttyp ausgeben, wie zum Beispiel Get-Process, das alle laufenden Prozesse auflistet und als Objekt vom Typ System.Diagnostics.Process ausgibt. Das Beenden von Prozessen ist eine eigene Aufgabe und ist daher ein eigenes Cmdlet (Stop-Process). Das Auflisten von Diensten gibt andere Eigenschaften als bei Prozessen aus und hat daher ein anderes Substantiv (Get-Service). Die resultierenden Objekte können über die Pipe (|) von anderen Cmdlets weiterverarbeitet werden. So ist es möglich, übergebene Objekte zu filtern (z. B. Select-Object -Property Name,Status, Where-Object -Property Status -EQ -Value Stopped), zu konvertieren (z. B. Converto-Json) oder auszugeben (z. B. Out-File, Out-GridView) (siehe auch Objekte und die Pipe).