Ein geplanter Task mit powershell.exe bleibt bei Windows PowerShell 5.1, auch wenn PowerShell 7.6 installiert ist. Die Installation allein ist deshalb kein Migrationsnachweis: Erst Startpfad, Skriptergebnis und Modulrückgaben zeigen, ob der produktive Job unter 7.6 funktioniert. Vier Prüfungen liefern diese Antwort.
Warum die Migration von PowerShell 7.4 jetzt planen?
Der Support für PowerShell 7.4 LTS endet am 10. November 2026. PowerShell 7.5 erreicht sein Supportende bereits am 12. Mai 2026; PowerShell 7.6 LTS wird bis zum 14. November 2028 unterstützt. Wer geplante Jobs umstellt, braucht vor dem Wechsel einen Test mit den Skripten und Modulen, die diese Jobs tatsächlich verwenden.
Ein Inventar erfasst für jeden relevanten Job den auslösenden Task oder Dienst, den Programmpfad, die Argumente und das Benutzerkonto. $PSVersionTable.PSVersion zeigt dagegen nur die Version der aktuellen Sitzung. Auch ein SQL-Server-Agent-Job oder ein CI-Runner kann PowerShell unabhängig von der interaktiven Admin-Sitzung starten.
PowerShell 7.x und Windows PowerShell 5.1 können auf demselben Windows-System installiert sein. Das Inventar muss sie auseinanderhalten. Mit den erfassten Startprogrammen beginnt die erste Prüfung.
Prüfung 1: Welches Programm startet jedes Skript?
PowerShell 7 startet über pwsh.exe, Windows PowerShell 5.1 über powershell.exe. Die Installation von PowerShell 7 ersetzt Windows PowerShell 5.1 nicht und ändert bestehende Task-Aktionen nicht. Steht in einer Aktion weiterhin powershell.exe, läuft das Skript dort unter Windows PowerShell 5.1.
In der Windows-Aufgabenplanung steht der Interpreter im Feld „Programm/Skript“, die übrigen Aufrufparameter stehen unter „Argumente hinzufügen“. Bei einem CI-Runner oder einem Dienst liegt der Aufruf in dessen Konfiguration. Ein bloßes pwsh wird über den Suchpfad aufgelöst; ein vollständiger Dateipfad macht die Auswahl des Programms überprüfbar. Welche Version an diesem Pfad installiert ist, muss der gestartete Prozess selbst melden.
Get-Command -Name pwsh.exe,powershell.exe -All |
Select-Object Name,Source
$PSVersionTable.PSVersion.ToString()Die erste Abfrage zeigt Programme, die in der aktuellen Umgebung auffindbar sind; die zweite nennt die Version der aktuellen Sitzung. Für den nächtlichen Job gehört die Versionsausgabe in dessen eigenes Protokoll. Erst wenn der tatsächliche Interpreter feststeht, lassen sich Skriptläufe unter 7.4 und 7.6 vergleichen.
Prüfung 2: Admin-Skripte vor dem produktiven Wechsel testen
Ein Vergleichslauf verwendet dieselbe Skriptdatei, dieselben Aufrufparameter und geeignete Testdaten wie der bisherige Job. Die PowerShell-7.6-Umgebung bleibt vom produktiven Task getrennt. Ein zusätzlicher Lauf mit -NoProfile deckt Abhängigkeiten von Funktionen oder Variablen im Benutzerprofil auf; er ersetzt den Vergleich mit den bisherigen Startparametern nicht.
& 'C:\Program Files\PowerShell\7\pwsh.exe' -NoProfile -File 'C:\Ops\Jobs\Beispiel.ps1'Der Beispielpfad muss zur getesteten Installation passen. Bei einem Export zählen etwa die erzeugten Spalten, ihre Datentypen und die Verarbeitung durch das nachgelagerte Programm. Bei einem Skript, das Systeme verändert, sind die protokollierten Änderungen und der tatsächliche Zustand dieser Systeme aussagekräftiger als die Meldung „erfolgreich“.
Ein Prozessrückgabewert von null genügt nicht: Ein PowerShell-Befehl kann einen nicht terminierenden Fehler ausgeben, während das Skript weiterläuft. Das Testprotokoll hält daher Fehlerausgabe, Rückgabewert und fachliches Ergebnis getrennt fest. Stimmen die Ergebnisse, gehören die verwendeten Module in denselben Vergleich.
Prüfung 3: Modulverhalten unter PowerShell 7.6 prüfen
Ein erfolgreiches Import-Module zeigt zunächst nur, dass das Modul geladen wurde. Ob die vom Skript verwendeten Befehle unter PowerShell 7.6 dieselben Parameter und Rückgabeobjekte liefern, bleibt offen. Der Test muss deshalb auch die Eigenschaften und Methoden erfassen, auf die spätere Pipeline-Schritte zugreifen.
Get-Module -ListAvailable -Name ActiveDirectory |
Select-Object Name,Version,Path,CompatiblePSEditions
Import-Module ActiveDirectory -ErrorAction StopActiveDirectory dient hier als Beispiel für ein installiertes Modul. Weder die angezeigte Version noch CompatiblePSEditions beweisen, dass jeder benötigte Befehl funktioniert. Aufschluss gibt erst ein Lauf mit den Abfragen und Verarbeitungsschritten des betreffenden Admin-Skripts.
Warum ein erfolgreicher Import nicht genügt
PowerShell 7 kann manche älteren Module über eine Sitzung mit Windows PowerShell 5.1 ausführen. Bei der Übertragung in die PowerShell-7-Sitzung werden Rückgabeobjekte serialisiert. Eigenschaften sind dann oft noch lesbar, Methoden des ursprünglichen Objekts stehen jedoch möglicherweise nicht mehr zur Verfügung. Ein Skript kann deshalb die erste Eigenschaft auslesen und erst beim späteren Methodenaufruf scheitern.
$obj.PSObject.TypeNames zeigt die Typnamen eines Rückgabeobjekts. Beginnt ein Typname mit Deserialized., weist das auf ein übertragenes statt auf das ursprüngliche Live-Objekt hin. Wer solche Unterschiede in Administrationsskripten vertiefen möchte, findet dazu die Schulung zur Administration mit PowerShell. Sind auch die benötigten Modulbefehle getestet, kann die Task-Aktion geändert werden.
Prüfung 4: Geplante Tasks auf PowerShell 7.6 umstellen
Die Task-Aktion wird erst geändert, wenn Skript und Module den Vergleich bestanden haben. Zum neuen Aufruf gehören der vollständige Pfad zu pwsh.exe und die getesteten Argumente; ein benötigtes Arbeitsverzeichnis muss ebenfalls erhalten bleiben. Der erste kontrollierte Task-Lauf findet unter dem vorgesehenen Benutzerkonto statt, weil dessen Zugriffsrechte von denen der interaktiven Admin-Sitzung abweichen können.
Nach dem Lauf belegen Task-Verlauf und Skriptprotokoll, welcher Interpreter gestartet wurde und welches Ergebnis der Job erzeugt hat. Die bisherige Task-Aktion bleibt für einen befristeten Rückweg dokumentiert. Wegen des Supportendes am 10. November 2026 ist PowerShell 7.4 jedoch keine dauerhafte Rückfallversion.
Der Wechsel ist erst abgeschlossen, wenn der geplante Job unter 7.6 das erwartete Ergebnis liefert. Beginne mit einem repräsentativen Task: Halte seine bisherige Aktion fest und vergleiche einen kontrollierten Lauf unter 7.6 mit dem bisherigen Ergebnis.