Windows PowerShell 5.1 und PowerShell 7 auf Servern: unter welcher Version ein Skript tatsächlich läuft

Worum es geht

Windows Server liefert Windows PowerShell 5.1 (powershell.exe) als Teil des Betriebssystems mit. PowerShell 7.x (pwsh.exe) ist dagegen eine eigenständige, plattformübergreifende Installation unter MIT-Lizenz. Laut dem Migrationsleitfaden von Microsoft läuft sie parallel zu 5.1 und ersetzt diese nicht; sie hat einen eigenen Installationspfad, einen eigenen $PSModulePath, versionsspezifische Profile und eigene Ereignisprotokolle. Wird aus einem Skript die eine Version aufgerufen, obwohl das Verhalten der anderen erwartet wird, ist das eine häufige Ursache für Meldungen der Art «interaktiv funktioniert es, in der geplanten Aufgabe nicht».

Warum es wichtig ist

Die beiden Engines unterscheiden sich in mehr als der Versionsnummer:

• Ausführbare Datei und PATH: powershell.exe (in System32\WindowsPowerShell\v1.0) ist auf einem unveränderten Server immer 5.1; pwsh.exe ist nur vorhanden, wenn 7.x separat installiert wurde. Das MSI-Paket trägt $Env:ProgramFiles\PowerShell\7 in den PATH ein. Prozesse, die vor der Installation gestartet wurden (etwa langlaufende Dienste), sehen den neuen PATH jedoch nicht, und bei ZIP- oder Store-Installationen fehlt der Eintrag im systemweiten PATH unter Umständen ganz.
• Modulkompatibilität: Die meisten Module, darunter das aktuelle Active-Directory-Modul, funktionieren unter 7.x, einige reine Windows-PowerShell-Module lassen sich aber nicht nativ laden. Import-Module -UseWindowsPowerShell löst dies, indem es laut Microsoft «loading module using Windows PowerShell Compatibility functionality» (das Modul über die Windows-PowerShell-Kompatibilitätsfunktion lädt): Das Modul läuft in einem versteckten 5.1-Prozess, und die Befehle werden per Proxy weitergereicht, wobei deserialisierte Objekte zurückkommen. Das ist langsamer und unterstützt nicht jede Funktion. PowerShell 7 wendet diesen Ersatzmechanismus implizit nur auf Module im Systemmodulordner von 5.1 an, die nicht als Core-kompatibel markiert sind (und nicht auf der Sperrliste stehen).
• Remoting-Endpunkte: Über WinRM landen Enter-PSSession und Invoke-Command ohne ausdrückliches -ConfigurationName auf dem Windows-PowerShell-5.1-Endpunkt Microsoft.PowerShell, selbst wenn der Client pwsh ausführt. PowerShell 7 erhält eigene Endpunkte (PowerShell.7, PowerShell.7.x.y) erst, nachdem unter 7.x Enable-PSRemoting mit erhöhten Rechten ausgeführt wurde; der Migrationsleitfaden führt diese unter den «new remoting endpoints» auf.
• Geplante Aufgaben: Die Aktion -Execute des Moduls ScheduledTasks ist ein einfacher Pfad zu einer ausführbaren Datei. Eine mit -Execute 'powershell.exe' erstellte Aufgabe läuft deshalb immer unter 5.1, unabhängig davon, mit welcher Shell sie angelegt wurde.

So wird es angewendet

• Das Skript zu Beginn eines Laufs $PSVersionTable.PSVersion und $PSVersionTable.PSEdition ausgeben lassen, damit die Logs zeigen, welche Engine es tatsächlich ausgeführt hat.
• In der Automatisierung (geplante Aufgaben, CI-Runner, Remoting-Skripte) den vollständigen Pfad der vorgesehenen ausführbaren Datei fest hinterlegen, statt sich auf die Reihenfolge im PATH zu verlassen.
• Funktioniert ein Modul nur unter 5.1, -UseWindowsPowerShell ausdrücklich angeben, statt sich auf den impliziten Ersatzmechanismus zu verlassen, der Module ausserhalb des Systemmodulordners nicht abdeckt.
• Beim Remoting -ConfigurationName PowerShell.7 angeben (oder den Namen, den Enable-PSRemoting unter pwsh registriert hat), wenn das Ziel PowerShell 7 sein muss, und dies auf dem Zielsystem mit Get-PSSessionConfiguration prüfen.

Stolpersteine

• Die Annahme, die Installation von PowerShell 7 aktualisiere Windows PowerShell 5.1 oder entferne sie; beide bleiben bestehen, und powershell.exe funktioniert unverändert weiter.
• Ein Skript interaktiv in einem pwsh-Fenster testen, es dann aber in einer geplanten Aufgabe einsetzen, die weiterhin powershell.exe aufruft.
• Übersehen, dass -UseWindowsPowerShell pro Sitzung einen zusätzlichen Hintergrundprozess startet, was Leistung und Fehlerverhalten gegenüber einem nativen 7.x-Modul verändert.