Wer sich in Microsoft-365-Tenants regelmäßig um Identitäten kümmert, kennt die PowerShell-Module MSOnline und AzureAD nur zu gut. Viele Admins arbeiten seit Jahren täglich damit, sei es für eine schnelle Benutzerauswertung, für Lizenzzuweisungen oder für automatisierte Abläufe in geplanten Tasks. Seit dem 30. März 2024 sind beide Module allerdings offiziell abgekündigt. Microsoft rät unmissverständlich zum Umstieg auf das Microsoft Graph PowerShell SDK (bzw. auf das Modul Microsoft Entra PowerShell, das sich zu diesem Zeitpunkt noch in der Preview befindet).

Betroffene Skripte lassen sich über Code und Anmeldeprotokolle aufspüren

In vielen Umgebungen stecken MSOnline- und AzureAD-Befehle tief in Automatisierungen und Monitoring-Jobs, manchmal sogar in den Workflows, mit denen neue Benutzer angelegt werden. Schwierig ist vor allem, diese Abhängigkeiten vollständig zu finden. Für den Anfang genügt es, Skript-Repositories oder Fileserver nach typischen Cmdlets wie Connect-MsolService und Connect-AzureAD zu durchsuchen. Mehr verraten allerdings die Anmeldeprotokolle in Entra ID. Im Microsoft Entra Admin Center filtert man dazu unter Überwachung → Anmeldeprotokolle nach der Anwendung „Azure Active Directory PowerShell“. Auf diese Weise kommen auch geplante Tasks und Servicekonten zum Vorschein, die sich interaktiv oder automatisiert per PowerShell anmelden.

flowchart TD
    Skripte["Skripte durchsuchen"] --> Cmdlets["MSOnline/AzureAD Cmdlets finden"]
    Cmdlets --> Anmeldeprotokolle["Entra Anmeldeprotokolle prüfen"]
    Anmeldeprotokolle --> Aufgaben["Geplante Tasks identifizieren"]
    Aufgaben --> Migration["Migration auf Graph PowerShell"]

Abbildung: So läuft die Suche nach MSOnline- und AzureAD-Skripten und deren Migration typischerweise ab.

In älteren Umgebungen kommen dabei nicht selten mehrere Dutzend produktive Skripte zusammen, die alle umgestellt werden müssen.

Eine Mapping-Tabelle von Microsoft übersetzt die alten Cmdlets nach Graph

Microsoft lässt keinen Zweifel daran, dass neue Automatisierungen mit dem Microsoft Graph PowerShell SDK gebaut werden sollen. Praktisch heißt das, vertraute Cmdlets wie Get-MsolUser oder Set-AzureADUser durch neue Befehle wie Get-MgUser oder Update-MgUser zu ersetzen. Für die meisten Admin-Aufgaben findet man die passende Entsprechung direkt in der Mapping-Tabelle, die Microsoft dafür bereitstellt. Am Lizenzmanagement merkt man den Unterschied anfangs am deutlichsten. Lizenzen werden etwa mit Set-MgUserLicense zugewiesen, und an diese Syntax muss man sich erst gewöhnen.

So sieht die Lizenzzuweisung an einen Benutzer typischerweise aus:

# Voraussetzung: PowerShell 7, Microsoft.Graph-Modul installiert, Rolle User Administrator oder höher
Connect-MgGraph -Scopes User.ReadWrite.All
$user = Get-MgUser -UserId "[email protected]"
Set-MgUserLicense -UserId $user.Id -AddLicenses @{SkuId = "{Lizenz-GUID}"} -RemoveLicenses @()

Praktischer Tipp: Für Lizenzabfragen setzen viele Skripte noch auf MSOnline, weil Get-MsolUser so bequem zu bedienen war. Schon die besseren Filter- und Exportmöglichkeiten machen den Wechsel zu Graph aber lohnenswert. Ist die Umstellung erledigt, kann man die Skripte über die Authentifizierungsbefehle für Graph wesentlich flexibler absichern, zum Beispiel mit App-only-Authentifizierung und Zertifikat.

Geplante Tasks melden sich künftig per App-only-Authentifizierung an

Bei geplanten Tasks oder Automatisierungen, die unter einem Servicekonto laufen, scheidet eine interaktive Anmeldung aus. Das Graph PowerShell SDK beherrscht App-only-Authentifizierung mit Zertifikaten, was gegenüber den alten Modulen ein echter Fortschritt ist. Man legt dafür in Entra ID eine App-Registrierung an und erteilt ihr die erforderlichen Anwendungsberechtigungen, für die Benutzerverwaltung etwa User.ReadWrite.All. Anschließend hinterlegt man ein Zertifikat und meldet sich mit Connect-MgGraph und der Application-ID an. Lokale Passwortspeicher oder riskante Zugangsdaten im Klartext braucht das Skript danach nicht mehr.

In echten Projekten tauchen immer wieder dieselben Stolpersteine auf

Auf dem Papier wirkt die Umstellung simpel, in vielen realen Umgebungen kostet sie dann doch mehr Aufwand als erwartet. Diese Probleme begegnen mir regelmäßig:

  • Die alten Cmdlets sind fest im Code verdrahtet, und die Skripte sind nicht modular aufgebaut – dann bleibt oft nur, sie neu zu schreiben, statt per Suchen und Ersetzen zu arbeiten.
  • Das Graph-SDK prüft Berechtigungen strenger, vor allem in App-only-Szenarien.
  • In vielen Automatisierungsumgebungen (z. B. Runbooks) ist das Modul „Microsoft.Graph“ noch nicht von Haus aus installiert.

Nach der Umstellung geplanter Aufgaben lohnt sich zusätzlich ein Blick ins Entra-Portal (unter Monitoring → Anmeldeprotokolle). Dort sieht man, ob die Anmeldung sauber klappt oder ob Berechtigungsfehler protokolliert werden. Wer sich für die Migration genug Zeit nimmt, hat später keinen Ärger mit abgekündigten Modulen und ist auch für kommende Änderungen gut gerüstet.

Eine saubere Inventur bringt mehr als jede schnelle Notlösung

Die Außerbetriebnahme von MSOnline- und AzureAD-PowerShell ist zwar „nur“ angekündigt, doch gerade in größeren Tenants sollte man trotzdem keine Zeit verschenken. Mit Graph ändert sich mehr als die Syntax, denn es kommen neue Authentifizierungsmodelle und eine andere Berechtigungslogik hinzu. Am schnellsten ist am Ziel, wer planvoll vorgeht. Zuerst gehören alle betroffenen Skripte und Automatisierungen auf eine Liste, danach arbeitet man sie mit Cmdlet-Mapping, Testumgebung und Dokumentation ab. Hastige Notlösungen kosten am Ende mehr Zeit.
Wer an anderer Stelle ebenfalls modernisieren möchte, etwa beim bedingten Zugriff oder bei Gastberechtigungen, findet dazu weitere Praxistipps hier im Blog, zum Beispiel unter /blog/conditional-access-entra-id-best-practices und /blog/gastkonten-aufraeumen-access-reviews-entra-id.