PowerShell-7.6-LTS-Migration: sicher von 5.1 zu pwsh.exe

PowerShell 7.6 LTS läuft auf .NET 10 LTS und eignet sich als Zielversion, wenn du Admin-Skripte aus Windows PowerShell 5.1, PowerShell 7.4 LTS oder PowerShell 7.5 in einen länger gepflegten Produktionsbetrieb überführen willst.

Die PowerShell-7.6-LTS-Migration endet nicht beim Austausch von powershell.exe gegen pwsh.exe. Windows PowerShell 5.1 nutzt .NET Framework, PowerShell 7.x nutzt .NET. Diese Trennung betrifft vor allem Module, Remoting, Encoding und native Befehle. Prüfe Profile und Scheduled Tasks zusätzlich, weil sie häufig feste Host-Pfade enthalten.

Warum PowerShell 7.6 LTS 2026 die Produktionsbasis ist

PowerShell 7.6 LTS erhält Support bis zum 14. November 2028. PowerShell 7.4 LTS und PowerShell 7.5 erreichen am 10. November 2026 ihr Support-Ende. Danach gibt es für die jeweilige Version keine Security-Updates mehr. Für produktive Automatisierung zählt deshalb auch, ob für die Runtime im geplanten Betriebszeitraum Updates bereitstehen.

Plane Windows PowerShell 5.1 als Ausnahme für Altlasten mit .NET-Framework-Abhängigkeiten, COM-Automatisierung oder Windows-spezifischen Modulen. Starte neue Runbooks, CI-Jobs und migrierte Administrationsskripte unter pwsh.exe mit PowerShell 7.6 LTS.

PowerShell 5.1 vs 7: Was vor der Migration ins Inventar gehört

Beginne bei den Stellen, an denen Automatisierung wirklich startet. Notiere Skriptpfade, Repositories, Task-Definitionen und CI-Pipeline-Dateien. Ergänze je Eintrag die verantwortliche Person, den Ausführungszeitpunkt, die verwendeten Credentials und die Kritikalität für Betrieb oder Reporting.

• Du erfasst alle .ps1-, .psm1- und .psd1-Dateien mit Pfad, Repository und Ausführungsort
• Du markierst Jobs, die powershell.exe, -Version 5.1 oder WindowsPowerShell explizit verwenden
• Du dokumentierst Modulabhängigkeiten, zum Beispiel für Active Directory, Exchange, Microsoft Graph oder Azure
• Du prüfst Remoting-Endpunkte, gespeicherte Credentials und Execution-Policies
• Du notierst abweichende Profile, Pfade und Umgebungsvariablen
• Du notierst native Befehle wie robocopy.exe, netsh.exe, sc.exe und herstellerspezifische CLIs

Eine einfache Suche deckt viele hartcodierte 5.1-Abhängigkeiten auf. Starte in Repositories, Fileshares und lokalen Task-Verzeichnissen der Automatisierungsserver.

Get-ChildItem -Path \\fileserver\scripts -Include *.ps1,*.psm1,*.psd1 -Recurse |
  Select-String -Pattern 'powershell\.exe','WindowsPowerShell','-Version 5.1','System\.Web','Add-Type' |
  Select-Object Path, LineNumber, Line

Wenn dein Team Skriptpflege, Module und Fehleranalyse vereinheitlichen will, findest du die passenden Grundlagen in den PowerShell-Schulungen. Servernahe Themen wie Active Directory, File Services und Windows Admin Center bündelt cmt unter Windows-Server-Schulungen.

Kompatibilität mit pwsh.exe testen

Der erste Testlauf gehört auf ein Pilot-System mit denselben Modulen, denselben Berechtigungen und vergleichbaren Eingabedaten wie in Produktion. Starte kritische Skripte manuell mit pwsh.exe -NoProfile, damit Benutzerprofile keine Fehler überdecken.

pwsh.exe -NoProfile -ExecutionPolicy Bypass -File .\Invoke-AdminJob.ps1 -Verbose *> .\logs\Invoke-AdminJob.pwsh.log

Prüfe Module getrennt vom Fachskript. Ein Modul, das in Windows PowerShell 5.1 lädt, läuft nicht automatisch in PowerShell 7.6. Einige Windows-Module funktionieren über Windows-PowerShell-Kompatibilitätssitzungen, andere benötigen eine neuere Modulversion oder bleiben bei 5.1.

$RequiredModules = 'ActiveDirectory','Microsoft.Graph','ExchangeOnlineManagement'
foreach ($Module in $RequiredModules) {
    Import-Module $Module -ErrorAction Stop
    Get-Module $Module | Select-Object Name, Version, CompatiblePSEditions, Path
}

Pester-Tests senken das Risiko bei späteren Patch-Versionen. Schreibe Tests für Parameterbindung, Rückgabeobjekte, Fehlerfälle und Dateiausgaben. Besonders wichtig sind Skripte, die Objekte an Monitoring-Systeme, Ticket-Systeme oder CSV-Reports übergeben.

Definiere den Rollback vor dem ersten Produktionswechsel. Ein Scheduled Task muss bei Bedarf wieder den alten Programmpfad, die alten Argumente und das alte Arbeitsverzeichnis erhalten. Exportiere deshalb die alte Task-Definition als XML und speichere die geprüfte neue Definition separat.

pwsh vs powershell: Parallelbetrieb sauber planen

Windows-Systeme behalten Windows PowerShell 5.1 als powershell.exe. PowerShell 7.6 installiert pwsh.exe als eigenen Host. Damit stellst du einzelne Tasks um, ohne den 5.1-Bestand global zu verändern.

Passe Scheduled Tasks vollständig an. Der Programmpfad zeigt häufig auf C:\Program Files\PowerShell\7\pwsh.exe. Die Argumente enthalten -NoProfile, den Skriptpfad und die benötigten Parameter. Das Arbeitsverzeichnis muss stimmen, weil relative Pfade in der Aufgabenplanung sonst unter C:\Windows\System32 aufgelöst werden.

$Action = New-ScheduledTaskAction `
  -Execute 'C:\Program Files\PowerShell\7\pwsh.exe' `
  -Argument '-NoProfile -File "D:\Automation\Invoke-AdminJob.ps1"' `
  -WorkingDirectory 'D:\Automation'

CI-Systeme brauchen dieselbe Klarheit. Verwende in Pipeline-Definitionen einen expliziten PowerShell-Host und prüfe, welche Shell der Runner startet. Ein erfolgreicher Test in Windows PowerShell 5.1 sagt nichts über das Verhalten unter PowerShell 7.6 aus.

PowerShell 7 über WSUS, Configuration Manager und Intune verteilen

PowerShell 7.6 lässt sich über Microsoft Update, WSUS, Microsoft Configuration Manager (SCCM), Intune oder signierte MSI-Pakete verteilen. Für Serverumgebungen mit Change-Fenstern ist ein freigegebenes MSI-Paket oder eine genehmigte WSUS-Freigabe besser nachvollziehbar als eine automatische Aktualisierung ohne Testfreigabe.

Microsoft Update hält LTS-Installationen im LTS-Kanal und Stable-Installationen im Stable-Kanal. Eine neue PowerShell-Version erscheint dort nicht zwingend am selben Tag wie im GitHub-Release. Plane bei PowerShell-7-Updates über WSUS, Configuration Manager und Intune eine zeitliche Lücke zwischen Veröffentlichung, Synchronisierung, Test und Freigabe ein.

Starte mit wenigen Pilot-Systemen, auf denen du Module, Task-Pfade und Berechtigungen bereits inventarisiert hast. Danach folgen Admin-Workstations, Automatisierungsserver und weitere Servergruppen. Jede Phase braucht eine definierte PowerShell-Version, einen Testumfang und eine Freigabe. Jede Patch-Version kann Installationspakete, Abhängigkeiten oder Modulpfade berühren. Lies die Version aus, lade Kernmodule, starte einen repräsentativen Scheduled Task und vergleiche die Logausgaben.

Typische Migrationsfehler, die du vermeiden solltest

Viele Fehler entstehen an Stellen, die vor der Migration unauffällig wirken. Hartcodierte Pfade zu C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe verhindern den Wechsel auf pwsh.exe. Modulpfade unter Documents\WindowsPowerShell\Modules unterscheiden sich von PowerShell-7-Profilen und PowerShell-7-Modulverzeichnissen.

• Du prüfst Module, die .NET Framework, COM-Objekte oder Windows-spezifische APIs verwenden
• Du vergleichst Ausgaben nativer Befehle, weil Argumentübergabe, Streams und Exit-Codes unter PowerShell 7 anders ausfallen können
• Du validierst UTF-8, ANSI und BOM-Verhalten bei Dateien, die andere Systeme weiterverarbeiten
• Du testest Remoting mit Windows-PowerShell-5.1-Endpunkten und PowerShell-7.x-Endpunkten getrennt
• Du startest Scheduled Tasks mit demselben Service-Account, der später in Produktion läuft
• Du kontrollierst Profile, Execution-Policy und Modul-Autoloading in Konsolen, Tasks und CI-Runnern separat

Bei Microsoft 365, Exchange Online und Graph hängt die Migration stark an den Modulversionen und Authentifizierungsflüssen. Admin-Teams vertiefen die dafür nötigen Cloud-Verwaltungsgrundlagen in den Microsoft-365-Schulungen für Administratoren.

Checkliste für deinen Produktions-Rollout

• Du setzt PowerShell 7.6 LTS als Zielversion für neue und migrierte Produktionsautomatisierung
• Du inventarisierst Skripte, Module, Scheduled Tasks, CI-Pipelines, Runbooks und Remoting-Endpunkte
• Du testest jedes kritische Skript mit pwsh.exe -NoProfile und dokumentierst notwendige Änderungen
• Du aktualisierst Task-Definitionen, technische Dokumentation, Monitoring-Regeln und Betriebs-Runbooks
• Du planst Updates über Microsoft Update, WSUS, Configuration Manager, Intune oder kontrollierte MSI-Paketverteilung
• Du behältst Windows PowerShell 5.1 nur für Workloads, die Windows-spezifische Module oder .NET-Framework-Abhängigkeiten benötigen
• Du prüfst Support-Termine, bevor PowerShell 7.4 LTS und PowerShell 7.5 am 10. November 2026 aus dem Support laufen

FAQ zur PowerShell-7.6-LTS-Migration

Welche PowerShell-Version sollte ich 2026 in Produktion verwenden?

2026 verwendest du PowerShell 7.6 LTS für neue und migrierte Produktionsautomatisierung. Windows PowerShell 5.1 bleibt dort sinnvoll, wo Module oder APIs noch an .NET Framework oder Windows-spezifische Schnittstellen gebunden sind.

Was ist der Unterschied zwischen pwsh und powershell?

pwsh.exe startet PowerShell 7.x, während powershell.exe Windows PowerShell 5.1 startet. Diese Trennung erlaubt Parallelbetrieb und verhindert, dass ein migrierter Task versehentlich unter der alten Runtime läuft.

Wie verteile ich PowerShell 7 über WSUS?

Du verteilst PowerShell 7 über WSUS, indem du PowerShell-Updates aus Microsoft Update in WSUS synchronisierst und die Freigabe wie bei anderen Server-Updates steuerst. Prüfe vorher, ob deine PowerShell-Installation Updates über Microsoft Update erhält und ob der richtige Kanal genutzt wird.

Wann endet der Support für PowerShell 7.4 LTS?

Der Support für PowerShell 7.4 LTS endet am 10. November 2026. Plane die Migration auf PowerShell 7.6 LTS vor diesem Datum, wenn 7.4 noch produktive Jobs ausführt.

Nächster Schritt

Starte mit einem kleinen Inventar der zehn wichtigsten produktiven Skripte und führe jedes Skript unter pwsh.exe -NoProfile aus. Dokumentiere die ersten Unterschiede bei Modulen, Encoding, Remoting und Task-Definitionen. Daraus baust du eine wiederholbare Migrationsvorlage für weitere Automatisierungsjobs.