PhinIT.DE – Graph PowerShell SDK: Aus für Windows PowerShell 5.1

Unterstützung für PowerShell 5.1 läuft aus

Wer M365-Automatisierung heute noch unter powershell.exe betreibt, hat seit dem 16. September 2026 eine Frist. Microsoft hat für die Module des Microsoft Graph PowerShell SDK eine zwölfmonatige Retirement-Phase für Windows PowerShell 5.x gestartet.

Entwicklung, Tests und neue Funktionen laufen ab sofort nur noch gegen PowerShell 7.x. Am selben Tag erschien Version 2.40.0 in der PowerShell Gallery.

Was Microsoft angekündigt hat

Die Ankündigung im Microsoft 365 Developer Blog trennt zwischen Wartung und Kompatibilität. Die v2.x-Module deklarieren während der rund zwölf Monate weiterhin Kompatibilität mit Windows PowerShell 5.1 und erhalten bei Bedarf Sicherheitsupdates. Fehler, die nur unter 5.x auftreten, untersucht und behebt Microsoft dagegen nicht mehr.

Die Gallery bestätigt den Stand: Microsoft.Graph 2.40.0 nennt weiterhin 5.1 als minimale PowerShell-Version. PowerShell Gallery | Microsoft.Graph 2.40.0

Der harte Schnitt kommt mit Version 3.0.0, angekündigt für das vierte Quartal 2026. Ab diesem Release erscheinen keine neuen v2-Versionen mehr, Sicherheitsfixes ausgenommen. v3 unterstützt ausschließlich PowerShell 7.x. Wer Skripte auf 5.1 behalten will, friert sich damit auf einem v2-Stand ein, der keine neuen Cmdlets und keine Fehlerkorrekturen mehr bekommt.

Warum Microsoft diesen Schritt geht

Windows PowerShell 5.1 läuft auf dem .NET Framework, PowerShell 7 auf aktuellem .NET. Das SDK muss für beide Laufzeiten Abhängigkeiten ausliefern und testen, und genau dort entstehen die Assembly-Konflikte, die Admins seit Jahren kennen. Microsoft begründet den Schritt damit, dass PowerShell 7 viele dieser Lade- und Abhängigkeitsprobleme behebt.

Erledigt ist das Thema damit nicht. In den Kommentaren zur Ankündigung bestätigt Gavin Barron, Engineering Manager für die Graph SDKs, dass v2 unter PowerShell 7 bereits Assembly Load Contexts nutzt und diese keine perfekte Lösung sind. Konflikte mit den Exchange- und Teams-Modulen in derselben Sitzung bleiben also möglich. Für v3 kündigt Barron an, dass bestehende Cmdlet-Aufrufe möglichst unverändert funktionieren sollen, gezielte Abweichungen will Microsoft dokumentieren. Im Kern tauscht v3 die Werkzeugkette aus, mit der die Cmdlets generiert werden.

Passend dazu: PowerShell V5.1 zu V7: Vorteile & Herausforderungen ordnet die typischen Stolpersteine beim Versionswechsel ein, die du bei der Umstellung deiner Graph-Skripte einplanen musst, PowerShell 7: Vergleich zu PowerShell 5 zeigt mit Codebeispielen, welche Unterschiede zwischen beiden Versionen im Skriptalltag auffallen.

Der zweite Termin, den du nicht übersehen solltest

Unabhängig von der Retirement-Phase plant Microsoft eine Änderung an der Standard-App für die delegierte Anmeldung. Laut GitHub-Issue 3629 vom 1. Juni 2026 können Versionen vor 2.36.1 sich danach delegiert nur noch über WAM anmelden. Barron präzisiert in den Blog-Kommentaren: Betroffen ist die Anmeldung per Interactive Browser Credential, App-only und Device Code Flow funktionieren weiter. Wer Connect-MgGraph mit eigener ClientId aufruft, ist nicht betroffen.

Einen Stichtag nennt Microsoft bisher nicht, empfohlen ist ein Update auf mindestens 2.37.0. Diese Änderung kann also deutlich vor dem Ende der zwölf Monate greifen und trifft genau die Umgebungen, die ältere SDK-Versionen bewusst festhalten.

Was du jetzt tun solltest

Der Aufwand liegt weniger im Code als in der Inventur. Graph-Cmdlets bleiben gleich, Probleme entstehen eher durch veraltete .NET-Assemblies und durch Aufrufer, die fest powershell.exe starten. Diese zwei Abfragen liefern auf einem Server einen ersten Überblick:

# Skripte mit Graph-SDK-Bezug finden
Get-ChildItem -Path 'D:\Scripts' -Recurse -Filter *.ps1 |
    Select-String -Pattern 'Connect-MgGraph' -List |
    Select-Object Path

# Geplante Tasks, die Windows PowerShell 5.1 starten
Get-ScheduledTask |
    Where-Object { $_.Actions.Execute -match 'powershell\.exe' } |
    Select-Object TaskPath, TaskName

Jeder Treffer der zweiten Abfrage ist ein Kandidat für pwsh.exe. Runbooks in Azure Automation, die in einer 5.1-Laufzeitumgebung laufen, stellst du auf eine PowerShell-7-Laufzeitumgebung um und testest sie dort, bevor du die alte Umgebung abschaltest.

Tony Redmond empfiehlt, den Wechsel zu nutzen und geplante Tasks durch Azure Automation mit Managed Identity zu ersetzen. Die Empfehlung ist schlüssig, weil damit Zertifikate und Client Secrets vom Server verschwinden und jeder Lauf zentral protokolliert wird. Jobs, die lokale Ressourcen wie das AD brauchen, laufen weiter über einen Hybrid Runbook Worker.

Für Geschäftsführung und CISO zählt eine andere Sicht: Am Stichtag fällt nichts aus, aber jede Störung unter 5.1 bleibt ab dann ungelöst, und ab v3 fehlen neue Cmdlets für neue Graph-Endpunkte. MSPs sollten die Inventur pro Kundenumgebung einplanen, weil gerade dort alte Aufgabenplanungen auf Servern überleben.

Passend dazu: M365 EntraID | Gastkonten per PowerShell aufräumen zeigt an einem Graph-Skript, warum ein geplanter Task keinen MFA-Prompt bedienen kann und wie eine maschinelle Identität den unbeaufsichtigten Lauf absichert.

Fazit

Unter 5.1 hören die Graph-Module am Stichtag nicht auf zu arbeiten, Microsoft stellt nur die Pflege ein. Dringender ist die Änderung an der delegierten Anmeldung für Versionen vor 2.36.1, weil sie ohne festen Termin kommt. Aktualisiere deshalb jetzt auf den aktuellen v2-Stand, inventarisiere deine 5.1-Aufrufer und stelle sie bis zum v3-Release auf PowerShell 7 um.

Weiterlesen: PowerShell 7: Vergleich zu PowerShell 5 liefert die Grundlagen, die du für die Umstellung deiner Automatisierungsserver auf pwsh.exe brauchst.

Graph PowerShell SDK: Aus für Windows PowerShell 5.1