PowerShell 2.0 – Microsoft entfernt älteres Shell-Programm

PowerShell 2.0 – ältere Shell-Programm-Version wird entfernt

Microsoft entfernt Windows PowerShell 2.0 endgültig aus Windows. Den Anfang macht Windows 11, Version 24H2, ab August 2025. Windows Server 2025 folgt im September 2025. In Insider-Vorabversionen fehlt die Komponente bereits seit Juli 2025. Die Änderung beendet eine seit 2017 bestehende Übergangsphase. Wenn alte Skripte explizit Version 2 anfordern, startet künftig standardmäßig PowerShell 5.1. Prüfen und modernisieren Sie jetzt Altlasten, damit produktive Abläufe weiterlaufen.

Zeitplan und Reichweite der Entfernung

Microsoft hat den Fahrplan präzisiert: Ab August 2025 entfernt ein späteres Release von Windows 11 (Version 24H2) die optionale Windows PowerShell 2.0-Komponente aus dem System. Windows Server 2025 erhält die Änderung im September 2025. Alle nachfolgenden Releases der genannten Betriebssysteme enthalten PowerShell 2.0 nicht mehr. Bereits seit Juli 2025 spiegeln Insider-Builds diesen Zustand wider.

Für die meisten Umgebungen bleibt der Eingriff unauffällig, weil moderne PowerShell-Versionen bereitstehen. Dennoch betrifft die Entfernung Geräte im Lebenszyklus, Testumgebungen und Installationsroutinen. Planen Sie Rollout-Fenster und Regressionstests ein, insbesondere in Umgebungen mit strengen Change-Kontrollen. Dokumentieren Sie Abhängigkeiten in Konfigurationsmanagement und Inventar, damit spätere Upgrades reibungslos verlaufen.

Gründe: Sicherheit, Wartbarkeit und weniger Legacy-Code

Windows PowerShell 2.0 gilt seit 2017 als veraltet. Das Alter zeigt sich technisch deutlich: Neuere Schutzmechanismen wie erweiterte Protokollierung und AMSI-Integration existieren in 2.0 nicht. Microsoft reduziert mit der Entfernung Angriffsflächen und vereinfacht den Plattform-Unterbau, weil weniger veralteter Code gepflegt werden muss. Gleichzeitig führt die Bereinigung zu klareren Support-Grenzen zwischen Windows PowerShell 5.1 und dem plattformübergreifenden PowerShell 7.x.

Für Unternehmen bedeutet das: weniger Varianten, konsistentere Policies und weniger Sonderfälle in Audits. Wer heute noch 2.0 nutzt, trägt ein unnötiges Betriebs- und Sicherheitsrisiko. Der Schritt folgt damit konsequent Microsofts Strategie, veraltete Komponenten zu entfernen und Administrationswerkzeuge auf einen aktuellen, abgesicherten Stand zu bringen.

Auswirkungen: Was passiert mit Skripten und Tools?

Wenn ein Skript oder geplante Aufgabe PowerShell 2.0 explizit anfordert (zum Beispiel per -Version 2 oder #requires -version 2), steht diese Laufzeit künftig nicht mehr bereit. Windows startet dann die Standard-Engine, üblicherweise PowerShell 5.1. Viele Skripte laufen dadurch unverändert, weil 5.1 weitgehend rückwärtskompatibel ist. Es gibt jedoch Ausnahmen, etwa wenn Skriptabläufe alte 2.0-Eigenheiten ausnutzen (nicht zu verwechseln mit PowerShell Workflows, die erst ab PowerShell 3.0 eingeführt wurden) oder .NET 2.0/3.5-gebundene Assemblies hosten. Auch ältere Produktversionen von Exchange, SQL Server oder SharePoint konnten historisch 2.0 erwarten.

Prüfen Sie deshalb gezielt Installer, Legacy-Module, Scheduled Tasks und Automationsjobs. Notieren Sie dabei, welche Systeme 5.1 oder 7.x voraussetzen, und welche Anpassungen (Parameter, Module, Policies) nötig werden. So verhindern Sie Überraschungen in Batch-Fenstern und nächtlichen Läufen.

Bestandsaufnahme: So identifizieren Sie 2.0-Abhängigkeiten

Starten Sie mit einer technischen Inventur. Auf Windows-Clients prüfen Sie, ob die optionale Komponente überhaupt installiert ist: Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2. Auf Servern liefert Get-WindowsFeature PowerShell-V2 den Installationsstatus. Suchen Sie in Skript-Repos nach -Version 2 oder #requires -version 2. Filtern Sie geplante Aufgaben nach entsprechenden Parametern. In Eigenentwicklungen mit eingebetteter PowerShell prüfen Sie, ob .NET 2.0/3.5 (CLR2) genutzt wird.

Dokumentieren Sie Funde, bewerten Sie Business-Kritikalität und planen Sie Tests. Ergänzen Sie Ihre Baselines/Hardening-Vorlagen, damit 2.0 auch in Build-Pipelines und auf Neuinstallationen nicht wieder auftaucht. Diese strukturierte Vorgehensweise schafft Transparenz und verkürzt die Migrationszeit.

Migration: Von 2.0 zu 5.1 oder PowerShell 7.x

Microsoft empfiehlt klar die Aktualisierung auf PowerShell 5.1 oder, wo möglich, gleich auf PowerShell 7.x. Beginnen Sie mit einer funktionsäquivalenten Portierung: Entfernen Sie die Versionserzwingung, aktualisieren Sie Module und prüfen Sie APIs, die sich verändert haben. Testen Sie Skripte mit produktionsnahen Daten und restriktiven Ausführungsrichtlinien. Aktualisieren oder ersetzen Sie Software, deren Installer noch versucht, 2.0 zu aktivieren. Standardisieren Sie anschließend auf ein Ziel: 5.1 für klassische Windows-Automatisierung, 7.x für moderne, plattformübergreifende Workloads und DevOps-Toolchains.

Dokumentieren Sie das Zielbild in Richtlinien, CI/CD-Pipelines und Admin-Guides. Planen Sie begleitende Schulungen, damit Teams neue Diagnostik- und Sicherheitsfunktionen gezielt nutzen.

Fazit: Jetzt handeln, Risiken vermeiden

Die Entfernung von PowerShell 2.0 ist beschlossen und terminiert. Wer heute noch Abhängigkeiten hat, sollte sofort mit einer fokussierten Bereinigung starten. Mit einer kurzen Inventur, klaren Tests und einem definierten Zielstack vermeiden Sie Ausfälle und Sicherheitslücken. Berücksichtigen Sie dabei auch Lieferanten: Fordern Sie aktualisierte Versionen von Tools an, die 2.0 voraussetzen, oder ersetzen Sie sie. Legen Sie fest, welche PowerShell-Version in welcher Domäne Standard ist, und passen Sie Monitoring sowie Logging an.

So schaffen Sie einen stabilen, wartbaren Zustand für die kommenden Windows-Releases – ohne hektische Hotfixes kurz vor dem nächsten Patchfenster.