Bevor wir in die technischen Details einsteigen, ist die wichtigste Frage: Welche PowerShell-Version sollte auf Ihren Produktivsystemen laufen? Microsoft verfolgt eine zweigleisige Strategie mit LTS- und Current-Releases, die sich an der .NET-Versionierung orientiert:

PowerShell 7.5 bringt keine einzelne bahnbrechende Neuerung, dafür aber eine beeindruckende Sammlung von über 100 Verbesserungen, die in Summe den Arbeitsalltag spürbar vereinfachen. Fünf Highlights verdienen besondere Aufmerksamkeit:

ConvertTo-CliXml und ConvertFrom-CliXml: Diese beiden neuen Cmdlets schließen eine langjährige Lücke. Bisher konnte PowerShell Objekte nur über Export-CliXml und Import-CliXml in Dateien serialisieren. Die neuen Cmdlets ermöglichen die Konvertierung direkt im Arbeitsspeicher, ohne eine physische Datei erzeugen zu müssen. Das ist besonders nützlich für Caching-Szenarien, Pipeline-Verarbeitung und die Übergabe komplexer Objekte zwischen Runspaces.

Massive Performance-Verbesserung für Array-Operationen: Die += Operation für Arrays wurde grundlegend optimiert. In PowerShell 7.4 war das Anhängen an Arrays noch notorisch langsam bei großen Datenmengen, da jedes Mal ein neues Array allokiert wurde. PowerShell 7.5 verbessert dieses Verhalten deutlich – wenngleich die Verwendung von [System.Collections.Generic.List[object]] weiterhin die schnellste Methode bleibt.

Verbessertes Test-Path: Die Parameter -OlderThan und -NewerThan funktionieren jetzt korrekt in Kombination mit -PathType. Bisher wurde -OlderThan in bestimmten Kombinationen schlicht ignoriert – ein subtiler Bug, der in Cleanup-Scripts für Log-Rotation oder Archivierung zu falschen Ergebnissen führen konnte.

PSResourceGet mit ACR-Support: Das PSResourceGet-Modul – der Nachfolger von PowerShellGet – unterstützt jetzt Azure Container Registries (ACR) als Gallery-Typ. Das ist ein wichtiger Schritt für Unternehmen, die ihre PowerShell-Module in privaten Registries verwalten und über CI/CD-Pipelines bereitstellen wollen.

Tab-Completion-Verbesserungen: Zahlreiche Ergänzungen bei der Tab-Vervollständigung machen die interaktive Arbeit effizienter. Parameter, Werte und Pfade werden jetzt intelligenter vorgeschlagen – eine Verbesserung, die besonders in täglichen Admin-Workflows auffällt.

Microsoft nutzt experimentelle Features als Staging-Mechanismus: Neue Funktionen werden zunächst als experimentell eingeführt und müssen explizit aktiviert werden. In PowerShell 7.5 haben mehrere dieser Features den Sprung in den Mainstream geschafft:

PSNativeWindowsTildeExpansion: Die Tilde (~) wird jetzt auch für native Windows-Anwendungen zum Home-Verzeichnis aufgelöst. Wer aus der Linux-Welt kommt, kennt dieses Verhalten – nun funktioniert es konsistent auch bei Aufrufen von nativen Executables unter Windows.

PSSerializeJSONLongEnumAsNumber: ConvertTo-Json behandelt große Enums jetzt standardmäßig als Zahlen statt als Strings. Das klingt nach einem Randfall, kann aber in API-Integrationen und Konfigurationsmanagement erhebliche Auswirkungen haben, wenn nachgelagerte Systeme numerische Werte erwarten.

Die Migration von Windows PowerShell 5.1 auf PowerShell 7.5 ist für die meisten Skripte unkompliziert – aber „die meisten” ist nicht „alle”. Die wichtigsten Unterschiede, die zu Inkompatibilitäten führen können:

Encoding: PowerShell 7.x verwendet standardmäßig UTF-8 ohne BOM als Textcodierung. Windows PowerShell 5.1 nutzte abhängig vom Cmdlet verschiedene Codierungen, oft UTF-16 LE. Wenn Ihre Skripte Dateien erzeugen, die von Legacy-Systemen gelesen werden, sollten Sie das Encoding explizit angeben, beispielsweise mit -Encoding UTF8BOM.

Entfernte Module: PowerShell Workflow, ISE-spezifische Module und einige Windows-exklusive Cmdlets sind in PowerShell 7.x nicht mehr enthalten. Der Parameter -UseWindowsPowerShell bei Import-Module schafft hier eine Brücke: Er erzeugt ein Proxy-Modul, das Windows PowerShell 5.1 im Hintergrund für die betreffenden Cmdlets nutzt.

String-Vergleiche: Seit .NET 5 ignorieren kulturinvariante String-Vergleiche nicht druckbare Steuerzeichen. Das bedeutet, dass Vergleiche, die unter Windows PowerShell 5.1 noch unterschiedliche Ergebnisse lieferten, unter PowerShell 7.x als identisch bewertet werden können. In sicherheitsrelevanten Skripten, die auf exakte String-Matches angewiesen sind, sollte dieses Verhalten getestet werden.

AllScope-Entfernung bei Aliases: PowerShell 7 hat das AllScope-Attribut von den meisten Standard-Aliases entfernt, was in verschachtelten Scopes zu unerwartetem Verhalten führen kann. Wer eigene Funktionen oder Module mit denselben Namen wie Standard-Aliases verwendet, sollte explizite Alias-Definitionen nutzen.

PowerShell 7 wird nicht automatisch mit Windows installiert – es existiert parallel zu Windows PowerShell 5.1. Für die Verteilung im Unternehmen stehen mehrere Wege zur Verfügung:

MSI-Paket: Das klassische MSI-Installationspaket lässt sich über SCCM, Intune oder Gruppenrichtlinien verteilen. Es installiert PowerShell 7.x in ein separates Verzeichnis, sodass Windows PowerShell 5.1 unangetastet bleibt. Die aktuellen MSI-Pakete unterstützen sowohl die Silent-Installation als auch die Konfiguration über Kommandozeilenparameter.

Windows Update: Seit PowerShell 7.2 kann das Update über Microsoft Update ausgerollt werden. Das vereinfacht die Pflege erheblich, da Updates über bestehende WSUS- oder Windows-Update-for-Business-Infrastrukturen verteilt werden können. Viele Administratoren haben bemerkt, dass PowerShell 7.5-Updates bereits still im Hintergrund über Windows Update eingespielt wurden.

Winget und dotnet tool: Für Entwicklermaschinen und kleinere Umgebungen eignen sich winget install Microsoft.PowerShell oder die Installation als .NET Global Tool. Beide Methoden sind für automatisierte Einrichtung von Entwicklungsumgebungen geeignet, aber weniger für großflächige Enterprise-Deployments.

Die Migration auf PowerShell 7.5 ist nicht nur eine Feature-Entscheidung – sie ist auch eine Sicherheitsentscheidung. Windows PowerShell 5.1 erhält nur noch kritische Sicherheitspatches und basiert auf dem .NET Framework, das seinerseits in den Maintenance-Modus übergegangen ist.

PowerShell 7.5 profitiert von der aktuellen .NET-9-Runtime mit deren Sicherheitsverbesserungen: moderne TLS-Unterstützung, gehärtete Kryptografie-APIs und zeitgemäße Behandlung von Zertifikaten. Die Entfernung des veralteten BinaryFormatter-Serializers in aktuellen Patches eliminiert einen bekannten Angriffsvektor für Deserialisierungs-Angriffe. Darüber hinaus wurde der Windows PowerShell ETW-Provider-ID aus der CodeBase entfernt und das PSDiagnostics-Modul aktualisiert, um nativ mit PowerShell 7 zu arbeiten.

Besonders relevant für sicherheitsbewusste Umgebungen: Die verbesserte ConciseView-Fehleranzeige und das Get-Error-Cmdlet erleichtern das Debugging erheblich. In Kombination mit Constrained Language Mode und Script Block Logging bietet PowerShell 7.5 ein deutlich robusteres Sicherheitsmodell als sein Vorgänger.

Mit PowerShell 7.6 steht das nächste LTS-Release in den Startlöchern. Es basiert auf .NET 10 und wird voraussichtlich die nächste langfristig unterstützte Version sein. Aktuell befindet sich 7.6 in Preview 5 und bringt unter anderem die Umbenennung des ThreadJob-Moduls zu Microsoft.PowerShell.ThreadJob – eine Bereinigung, die keine funktionalen Änderungen mit sich bringt, aber die Namenskonventionen vereinheitlicht.

Für Unternehmen, die aktuell PowerShell 7.4 LTS einsetzen, zeichnet sich folgender Migrationspfad ab: Von 7.4 LTS direkt auf 7.6 LTS, sobald das GA-Release erscheint. PowerShell 7.5 kann in diesem Szenario als Testplattform für kommende Änderungen dienen, muss aber nicht in der Produktion eingesetzt werden.

Ein wachsender Trend ist die Integration von KI-gestützten Agenten in PowerShell-Workflows. MCP-Server (Model Context Protocol), AI-gesteuerte Automatisierung und die Kombination aus PowerShell mit Visual Studio Code und GitHub Copilot verändern die Art, wie Administratoren Skripte entwickeln und Aufgaben automatisieren. PowerShell 7.6 wird voraussichtlich weitere Grundlagen für diese Integration schaffen.

Best Practices: PowerShell 7.5 im Enterprise-Betrieb

Fazit: Jetzt ist die richtige Zeit zum Umstieg

PowerShell 7.5 mag kein Revolutionsrelease sein, aber es ist ein ausgereiftes, stabiles und deutlich sichereres Werkzeug als Windows PowerShell 5.1. Die über 100 Verbesserungen, der .NET-9-Unterbau und die Unterstützung moderner Deployment-Methoden machen den Umstieg lohnend. Wer heute noch ausschließlich auf Windows PowerShell 5.1 setzt, lässt nicht nur Performance und Features auf dem Tisch – er geht auch ein wachsendes Sicherheitsrisiko ein. Mit dem nahenden Support-Ende von 7.5 im Mai 2026 und PowerShell 7.6 LTS am Horizont ist jetzt der ideale Zeitpunkt, die Migration zu planen und die eigene Skript-Infrastruktur fit für die Zukunft zu machen.

Quellen & weiterführende Informationen

• Microsoft Learn – What’s New in PowerShell 7.5
• Microsoft DevBlog – Announcing PowerShell 7.5 GA
• GitHub – PowerShell Releases
• 4sysops – PowerShell 7.5 New Features
• Adam the Automator – Migrating from PowerShell 6 to 7.5
• PowerShell is fun – PowerShell v7.5.3 and v7.4.12 Releases

© IT-Service Walter – Ihr Partner für IT-Sicherheit und Infrastruktur