Windows PowerShell 5.1 ist in der Regel vorinstalliert und der Standard – lohnt sich ein Wechsel auf PowerShell 7, oder führt das eher zu Mehraufwand und Problemen?

2018 wurde PowerShell Core in Version 6 veröffentlicht und brachte frischen Wind in die PowerShell-Welt: Plattformunabhängigkeit! Dank .NET Core läuft die PowerShell nun nicht nur unter Windows, sondern auch unter MacOS und Linux.

Der Haken? Trotzdem bleibt Windows PowerShell 5.1 in vielen Unternehmen der Standard, weil es vorinstalliert ist. Die Unterstützung von PowerShell 5.1 ist an die jeweilige Windows-Version gebunden. Das bedeutet, PowerShell 5.1 wird uns noch eine Weile begleiten, obwohl keine neuen Features mehr hinzukommen. Viele Administratoren fragen sich daher, ob ein Umstieg auf PowerShell 7 überhaupt notwendig ist, da dieser im Zweifelsfall zu einem erhöhten Administrationsaufwand (Installation und Wartung von PowerShell 7 auf Clients und Servern) oder zu Kompatibilitätsproblemen mit bestehenden Skripten führen kann.

Installation von PowerShell 7

Die neueste PowerShell Version lässt sich unter Windows, Linux und MacOS einfach installieren. Ein Trostpflaster für die fehlende Vorinstallation der neuesten PowerShell-Version auf Windows-Systemen: Seit der Version 7.2 (ab Windows Version 1709) kann die PowerShell über WSUS aktualisiert werden, was den Verwaltungsaufwand für Administratoren deutlich reduziert. Nachfolgend die Befehle zur Installation auf den jeweiligen Betriebssystemen:

Windows mit winget:

winget install --id Microsoft.Powershell --source winget

MacOS mit homebrew:

brew install --cask powershell

Debian Linux:

###################################



# Prerequisites



# Update the list of packages

sudo apt-get update



# Install pre-requisite packages

sudo apt-get install -y wget



# Get the version of Debian

source /etc/os-release



# Download the Microsoft repository GPG keys

wget -q https://packages.microsoft.com/config/debian/$VERSION_ID/packages-microsoft-prod.deb



# Register the Microsoft repository GPG keys

sudo dpkg -i packages-microsoft-prod.deb



# Delete the Microsoft repository GPG keys file

rm packages-microsoft-prod.deb



# Update the list of packages after we added packages.microsoft.com

sudo apt-get update



###################################



# Install PowerShell

sudo apt-get install -y powershell



# Start PowerShell

pwsh

Unterschiede zur Windows PowerShell 5.1

Unabhängig vom verwendeten Betriebssystem kann die PowerShell 7 mittels "pwsh" aus dem Terminal heraus gestartet werden. Zur Überprüfung der aktuellen Version kann weiterhin $PSVersionTable verwendet werden:

Windows PowerShell 5.1 vs. PowerShell 7

Auch wenn PowerShell 7 viele Vorteile und neue Funktionen bietet, wollen wir zunächst einen Blickt auf die Aspekte werfen, die gegen einen Umstieg sprechen könnten. Hier sind die wichtigsten Punkte, die du bedenken solltest.

Fehlende Cmdlets

Ein wesentlicher Nachteil von PowerShell 7 ist das Fehlen bestimmter Cmdlets, die in Windows PowerShell 5.1 verfügbar sind. Dies betrifft vor allem Cmdlets, die spezifisch für Windows sind und nicht auf anderen Plattformen wie macOS oder Linux unterstützt werden. Hier einige Beispiele:

• Cmdlets, die auf WMI basieren, sind auf macOS und Linux nicht verfügbar, da die Schnittstellen Windows-nativ sind.
• Um einen gemeinsamen Nenner zwischen den unterstützen Plattformen zu finden, wurde auf die Implementierung von Cmdlets für Windows-exklusive Tools verzichtet. Das Betrifft beispielsweise die Windows-Firewall oder das EventLog.
• Trotz der Existenz eines TCP-Stacks fehlen einige Netzwerkkommandos wie Resolve-DNSName.

Eine vollständige Liste der entfernten Cmdlets kann auf der offiziellen Microsoft-Dokumentationsseite eingesehen werden: Unterschiede zwischen Windows PowerShell 5.1 und PowerShell 7.

Kompatibilität mit Windows-Cmdlets

Im Gegensatz zu Linux und MacOS stehen auf Windows-Systemen in der Regel dieselben Cmdlets zur Verfügung. Nicht etwa, weil auf Windows eine andere Version von PowerShell 7 ausgeliefert wird, sondern da PowerShell 7 das System durchsucht und die Cmdlets von PowerShell 5.1 findet. Um dies zu erleichtern, wurde der Parameter UseWindowsPowerShell zum Import-Module-Cmdlet hinzugefügt. Dieser Parameter erstellt in PowerShell 7 ein Proxymodul, das einen lokalen Windows PowerShell-Prozess verwendet, um alle in diesem Modul enthaltenen Cmdlets implizit auszuführen. Weitere Informationen dazu gibt es in der offiziellen Dokumentation zu Import-Module.

Keine integrierte Scripting-Umgebung (ISE)

Ein weiterer Nachteil ist das Fehlen einer nativen ISE-Alternative in PowerShell 7. Viele Administratoren und Entwickler sind an die ISE von Windows PowerShell 5.1 gewöhnt. PowerShell 7 setzt hingegen auf Visual Studio Code (VSCode) als primäre Entwicklungsumgebung. VSCode bietet zwar viele Vorteile und ist sehr mächtig, aber der Umstieg kann eine gewisse Lernkurve erfordern und ist nicht immer so nahtlos wie die klassische ISE. Aufgrund der verbesserten Features, Community-Extensions, direkter Git-Integration und der deutlich hochwertigeren Developer-Experience, empfehle ich die Verwendung von Visual Studio Code aber grundsätzlich. Visual Studio Code unterstützt nämlich ebenfalls die Windows PowerShell 5.1 und bietet sich als versionsübergreifendes Werkzeug für PowerShell-Coding an.

Vorteile von PowerShell 7

Nachdem wir uns die Nachteile von PowerShell 7 angeschaut haben, sollten wir uns jetzt auf die zahlreichen Vorteile konzentrieren. Es gibt viele gute Gründe, warum sich ein Umstieg auf die neueste Version lohnt.

Bessere Performance

PowerShell 7 ist in vielerlei Hinsicht schneller als sein Vorgänger. Besonders spürbar ist dies bei den Cmdlets Group-Object und Sort-Object, die nun deutlich schneller arbeiten. Wer oft große Datenmengen verarbeitet, wird die gesteigerte Effizienz schnell zu schätzen wissen.

Folgender Beispiel-Code führt einen kleinen Benchmark durch, der den immensen Performance-Boost in PowerShell 7 verdeutlich. Dazu wird mit dem zunächst ein großes Objekt erstellt und anschließend mittels Group-Object gruppiert. Dieser Gruppier-Vorgang wird mithilfe der StopWatch-Klasse gemessen:

$AllFiles = Get-ChildItem -Path $home -File -Recurse -Force -ErrorAction SilentlyContinue



$stopwatch = [Diagnostics.StopWatch]::StartNew()

$suspicious = $AllFiles | Group-Object -Property Length 

$stopwatch.Stop()



$duration = $stopwatch.Elapsed.TotalSeconds

Write-Output "duration: $duration seconds"

Der Code ist sowohl mit der Windows PowerShell 5.1 also auch mit PowerShell 7 ausführbar – probiere es gerne selbst. Auf meiner virtuellen Maschine erhalte ich die folgenden Ergebnisse:

Windows PowerShell 5.1: 23 Sekunden

PowerShell 7: 0,4 Sekunden

Das Beispiel zeigt, dass PowerShell 7 um den Faktor 57 schneller arbeitet. Gerade in großen Infrastruktur-Umgebungen oder bei der Verwendung großer Datensammlungen kann ein Upgrade auf PowerShell 7 einen massiven Performance-Boost ermöglichen.

Parallelisierung leicht gemacht

Eine der stärksten Neuerungen ist die Möglichkeit zur Parallelisierung. Mit dem foreach-Cmdlet und dem ThreadJobs-Modul kannst du Aufgaben parallel ausführen. Das bedeutet, dass du mehrere Aufgaben gleichzeitig erledigen kannst, was dir viel Zeit spart. Hier ein Beispiel:

$procs = Get-Process

$procs | ForEach-Object {

    Write-Host $_.Id

    Start-Sleep -Seconds 1

}

In diesem Fall werden alle laufenden Prozesse gesammelt und deren ID stückweise ausgegeben. Nach jeder Ausgabe wartet das Skript eine Sekunde. Die Prozesse werden dabei sequenziell abgearbeitet. Ohne großen Aufwand lassen sich aber auch mehrere Prozess-IDs gleichzeitig abarbeiten – das Zauberwort heißt in diesem Fall nicht "Bitte", sondern "Parallel":

$procs = Get-Process

$procs | ForEach-Object -ThrottleLimit 20 -Parallel {

    Write-Host $_.Id

    Start-Sleep -Seconds 1

}

Hierbei werden in einem Rutsch 20 Prozess-IDs ausgegeben, eine Sekunde pausiert und danach wieder 20 Prozesse ausgegeben und so weiter. Die Anzahl der gleichzeitigen Jobs wird mittels ThrottleLimit bestimmt.

Neue und verbesserte Cmdlets für Web-Requests

PowerShell 7 bringt auch viele neue und verbesserte Cmdlets mit, die deine Arbeit erleichtern. Invoke-WebRequest und Invoke-RestMethod sind jetzt leistungsfähiger und flexibler, was dir das Arbeiten mit Web-APIs erleichtert. Das Cmdlet Test-Connection -AsJob ermöglicht es dir, Verbindungsprüfungen als Hintergrundaufgaben auszuführen, was deine Prozesse effizienter macht. Und mit Test-Json kannst du ganz einfach die Syntax von JSON-Daten überprüfen, was besonders nützlich ist, wenn du viel mit JSON-Dateien und APIs arbeitest. Weitere Infos findest du in der offiziellen Microsoft-Dokumentation.

Fazit

In vielen Unternehmen wird oft das bevorzugt, was bereits vorhanden ist. Das bedeutet, dass Windows PowerShell 5.1 aufgrund seiner vorinstallierten Präsenz auf den meisten Windows-Systemen nach wie vor weit verbreitet ist. Diese Bequemlichkeit führt dazu, dass der Umstieg auf eine neue Version, wie z.B. PowerShell 7, hinausgezögert wird.

Optimal wäre eine direkte Integration von PowerShell 7 in Windows, ähnlich wie bei Version 5.1. Dies würde die Akzeptanz und Verbreitung in Unternehmen deutlich erhöhen, da keine zusätzlichen Installationsschritte notwendig wären und IT-Administratoren sofort auf die neuen Funktionen zugreifen könnten. Solange dies nicht der Fall ist, wird der Einsatz von PowerShell 7 in vielen Unternehmen auf spezialisierte Anwendungsfälle und fortgeschrittene IT-Abteilungen beschränkt bleiben.

Trotz der vielen Vorteile hat sich PowerShell 7 in der breiteren DevOps-Community jenseits von Windows und Azure noch nicht vollständig durchgesetzt. Viele Anwender setzen nach wie vor auf PowerShell 5.1, insbesondere wegen der bereits vorhandenen Infrastruktur und Skripte. Ein pragmatischer Ansatz ist daher, beide Versionen nebeneinander einzusetzen. Solch eine Side-by-Side-Verwendung ermöglicht es, die neuen Funktionen und Performance-Verbesserungen von PowerShell 7 dort zu nutzen, wo es sinnvoll ist, während bestehende Skripte und Prozesse in der gewohnten Umgebung weiterlaufen können.

Meine Empfehlung lautet daher: Wo immer möglich, PowerShell 7 einsetzen! Microsoft wird möglicherweise irgendwann den Support für PowerShell 5.1 einstellen. Spare den Aufwand und vermeide eine spätere, aufwendige Migration, indem Skripte schon jetzt in Version 7 geschrieben werden. Die Investition in die neue Version zahlt sich langfristig aus, da PowerShell 7 zukunftssicherer ist und eine bessere Performance sowie erweiterte Funktionen bietet.

Weiterführende Links

• Unterschiede zwischen Windows PowerShell 5.1 und PowerShell 7 (Microsoft | Learn)
• Dokumentation zu Import-Module (Microsoft | Learn)
• Dokumentation zu Test-Json (Microsoft | Learn)
• Hier kannst du ScriptRunner kennenlernen?