Microsoft Graph on DR.365

Auf Menschentempo ausgelegt: Was Anthropics neue Versionskontrolle für die IT-Strategie bedeutet

Wed, 14 Oct 2026 07:00:00 +0200

Im Mai 2026 hat Anthropic rund 2.500 Code-Änderungen pro Tag in sein Monorepo gemergt. Im September waren es über 30.000. Git und die Mirror-Infrastruktur drumherum kamen nicht mehr hinterher, also hat ein Team aus sieben Leuten ein eigenes Versionskontrollsystem gebaut und das komplette Monorepo in fünf Monaten migriert (Anthropic Engineering).

Kaum jemand, der das hier liest, wird ein Versionskontrollsystem bauen. Darum geht es bei der Geschichte auch nicht. Jede Organisation hat Prozesse, die auf das Tempo von Menschen ausgelegt sind: Change Advisory Boards, Vier-Augen-Freigaben, Access Reviews, CI-Pipelines, Budgets in Personentagen. Sobald Agents einen großen Teil der Arbeit erledigen, werden genau diese Prozesse zum Engpass. Die Frage ist, welche davon du umbaust, bevor sie brechen.

Kurz gesagt

Agents werden zu den Hauptnutzern deiner Systeme. Architekturentscheidungen sollten von Maschinen-Clients ausgehen, die immer online sind und APIs in hoher Frequenz aufrufen.
Review und Freigabe müssen weg von „ein Mensch hat alles angesehen“ hin zu Regeln, die festlegen, wo ein Mensch hinsehen muss.
Jeder Agent braucht eine Identität, eine verantwortliche Person und eine Kostenstelle. Ohne diese drei kannst du Agentenarbeit weder steuern noch budgetieren.

Was Anthropic tatsächlich geändert hat

In den Schlagzeilen heißt es „Anthropic hat Git rausgeworfen“. Der Engineering-Beitrag selbst ist vorsichtiger. Das neue System heißt Scion, das Review-Werkzeug Antique. Anthropic schreibt ausdrücklich, dass Scion kein allgemeiner Ersatz für Git ist, weil dafür die gesamte Entwicklungs-Toolchain ersetzt werden müsste. Veröffentlicht wurde das Design, damit Git-Plattformen Teile davon übernehmen können.

Warum sie es trotzdem gemacht haben, zeigen die Zahlen. Die Historie des Main-Branch umfasst fast 100 GB, eine komprimierte Arbeitskopie über 25 GB, und die CI zieht rund 25 Millionen Checkouts pro Tag. Git ist für verteilte Clients gebaut, die offline arbeiten. Die Clients bei Anthropic sind fast ausschließlich Agents und Jobs, die immer online sind. Scion verlagert die teure Arbeit auf den Server: Commits, Merges, Rebases, Historie und Blame laufen dort, Clients bekommen schlanke, virtualisierte Checkouts, die Dateien bei Bedarf nachladen, und vieles ist per API ganz ohne lokales Repository nutzbar. Laut Beitrag braucht die neue Infrastruktur etwa 200-mal weniger CPU und Speicher als die alten Git-Mirrors, CI-Checkouts dauern Sekunden statt Minuten.

Drei Entscheidungen aus dem Beitrag sind über Versionskontrolle hinaus relevant:

Es gibt keine Merge Queue mit globalem Lock. Anthropic hat stattdessen in Tests nach dem Merge und vor dem Deployment investiert. Konflikte zwischen parallelen Änderungen kommen vor, und Claude behebt sie meist schneller, als ein Mensch sie bemerken würde.
Antique kann semantische Regeln für Freigaben abbilden. Eine Änderung nur an Kommentaren wird anders behandelt als eine Änderung an sensibler Logik, damit menschliche Reviewer ihre Zeit dort verbringen, wo es zählt.
Zugriffssteuerung auf Repository- und Verzeichnisebene war von Anfang an eingebaut, nicht nachträglich ergänzt.

Agents sind die neuen Hauptnutzer

Die erste Lehre betrifft die Architektur. Die meisten Unternehmenssysteme gehen von einem Menschen vor einem Bildschirm aus. Agents verhalten sich anders: Sie pollen, sie laufen parallel, und Mittagspause machen sie auch keine.

In Microsoft 365 sieht man das heute schon am Throttling von Microsoft Graph. Microsoft nennt zwei typische Ursachen: viele Anfragen über alle Anwendungen eines Tenants hinweg und viele Anfragen einer Anwendung über alle Tenants hinweg. Regelmäßiges Abfragen einer Ressource und wiederholtes Durchsuchen von Collections werden ausdrücklich als Muster genannt, die zu Throttling führen. Empfohlen werden stattdessen Delta Queries und Change Notifications, für große Datenmengen verweist Microsoft auf Graph Data Connect statt der REST-APIs (Microsoft Learn). SharePoint Online geht noch einen Schritt weiter: Eine Anwendung, die Limits dauerhaft überschreitet, kann komplett blockiert werden (Microsoft Learn).

Diese Hinweise wurden für Integrationsentwickler geschrieben. Inzwischen gelten sie für jeden Agent, der im Auftrag von jemandem Postfächer, Sites oder Teams-Kanäle liest. Wenn ich ein Agent-Szenario bewerte, frage ich deshalb zuerst, wie es Änderungen erkennt, und erst danach, was es tut. Ein Agent, der alle zehn Minuten eine Dokumentbibliothek komplett durchsucht, läuft im Pilot einwandfrei und wird zum Problem, wenn 40 Abteilungen ihn kopieren.

Für eigene Systeme gilt dasselbe in umgekehrter Richtung. Wenn Agents die Hauptnutzer einer internen Plattform werden, braucht sie eine ordentliche API, Change Feeds und Limits pro Client. Eine Weboberfläche mit einem Scraping-Agent davor ist der Git-Mirror deiner Organisation: Sie funktioniert, bis das Volumen sich verzehnfacht.

Review nach Absicht statt Zeile für Zeile

Die zweite Lehre betrifft Kontrollprozesse. Das Team bei Anthropic prüft weiterhin jede Änderung, aber es prüft die Absicht und nicht jede Zeile. Ihre wichtigste Aufgabe ist nach eigener Beschreibung, Claude „Nein“ zu sagen: wenn Systemgrenzen verletzt werden oder Claude wegen hypothetischer Bedenken überkonstruiert.

In regulierten Umgebungen ist das der unbequeme Teil. Viele Change-Prozesse versprechen implizit, dass eine qualifizierte Person alles geprüft hat. Bei 30.000 Änderungen am Tag lässt sich dieses Versprechen nicht halten, und ehrlich gesagt wurde es oft schon bei 30 pro Woche nicht gehalten. Das CAB, das in 45 Minuten einen Stapel Changes durchwinkt, prüft vor allem, ob das Formular vollständig ist.

Nach meiner Erfahrung wollen Auditoren Belege dafür sehen, dass Änderungen kontrolliert und nachvollziehbar sind. NIS2 verlangt Risikomanagementmaßnahmen, zu denen auch Sicherheit bei Entwicklung und Wartung gehört; dass ein Mensch jede Zeile liest, schreibt die Richtlinie nicht vor. Damit bleibt Raum für ein Modell, das ITIL als Standard Changes kennt, angewendet auf die Arbeit von Agents:

Geringes Risiko (Dokumentation, Tests, Formatierung, Konfiguration innerhalb definierter Leitplanken): automatische Prüfungen, kein verpflichtendes menschliches Review, vollständige Protokollierung.
Mittleres Risiko (Geschäftslogik, Integrationen): menschliches Review von Absicht und Testnachweisen, mit der Zusammenfassung des Agents als Grundlage.
Hohes Risiko (Authentifizierung, Berechtigungen, Datenflüsse über Vertrauensgrenzen, alles Regulierte): Review Zeile für Zeile durch eine benannte Person, wie bisher.

Was über die Stufe entscheidet, muss eine Regel sein und kein Bauchgefühl. Anthropic bildet das im Review-Werkzeug ab, du kannst es in Branch Protection Rules, CODEOWNERS-Dateien oder einem Genehmigungsflow in Power Automate abbilden. Die Regel selbst ist die Kontrolle, die ein Auditor sehen will.

Bei einem Teil des Anthropic-Ansatzes wäre ich vorsichtig: Prüfungen hinter den Merge zu verlegen. Für eine interne Entwicklerplattform ist das ein vertretbarer Tausch. Für ein System in einer KRITIS-Umgebung, bei dem eine fehlerhafte Änderung direkt in Produktion landen kann, würde ich das nicht machen. Die Absicherung muss vor dem Deployment sitzen, auch wenn sie nicht mehr vor dem Merge sitzt.

Jeder Agent braucht eine Identität und einen Verantwortlichen

Anthropic hat die Zugriffssteuerung in Scion vom ersten Tag an eingebaut, bis auf Verzeichnisebene. In Microsoft 365 entspricht dem die Identitätsschicht für Agents. Microsoft Entra Agent ID gibt Agents eigene Identitäten im Verzeichnis, erzeugt aus Agent Identity Blueprints. Jede Agent-Identität braucht einen menschlichen Sponsor, der für Zweck, Lebenszyklus und Access Reviews verantwortlich ist. Verlässt der Sponsor das Unternehmen, geht die Verantwortung auf seine Führungskraft über. Conditional Access und Access Packages aus dem Entitlement Management gelten auch für Agents (Microsoft Learn). Stand Oktober 2026 ist Identity Governance für Agents als Preview gekennzeichnet, und die Lizenzierung hängt an Microsoft 365 E7 oder Agent 365. Prüf die aktuellen Bedingungen, bevor du damit planst.

Darüber liegt in Microsoft Agent 365 die Registry als gemeinsames Inventar für Microsoft- und Fremd-Agents, inklusive der Anzahl an Agents ohne Besitzer (Microsoft Learn). Die Governance-Seite habe ich ausführlicher im Beitrag zum Agent Lifecycle beschrieben.

Strategisch heißt das: Ein Agent, der unter einem geteilten Dienstkonto oder mit den delegierten Rechten einer Person läuft, lässt sich im Audit-Log nicht unterscheiden, nicht separat drosseln und nicht separat abrechnen. Das später für Hunderte Agents nachzuziehen, ist genau die Art Projekt, für die niemand Budget freigibt.

Agentenarbeit messen

Beim Budget bricht es an derselben Stelle. Das Controlling rechnet in den meisten IT-Organisationen noch in Personentagen, und für Agentenarbeit gibt es in diesem Modell keine Zeile. Ein praktikabler Weg ist, Agent-Sitzungen über ein AI Gateway zu leiten. Dann lässt sich jedes Token und jede Stunde Laufzeit einem Projekt und einem Repository zuordnen und mit echten Preisen bewerten.

Ein Feature, das letztes Jahr 20 Tage gebraucht hat und dieses Jahr 3 Tage Review plus Agentenlaufzeit, passt nicht in dieses Modell. Agentenstunden zu zählen ist ein Anfang, aber Stunden sind eine Input-Kennzahl. Wissen willst du die Kosten pro akzeptierter Änderung: Tokens und Laufzeit plus die menschliche Zeit für Review, Nacharbeit und die Fälle, in denen jemand „Nein“ sagen musste. Ohne den menschlichen Anteil sieht Agentenarbeit billiger aus, als sie ist.

Für Microsoft-Agents sammelt die Observability in Agent 365 Aktivitätsdaten und soll Kennzahlen wie Nutzung und Zeitersparnis liefern (Microsoft Learn). Das deckt einen Teil des Bildes ab. Coding-Agents außerhalb von Microsoft 365 brauchen eine eigene Zuordnung, und dort kommt der Gateway-Ansatz ins Spiel.

Entscheidungen für die nächsten zwölf Monate

Anthropic erwartet, dass andere Organisationen in den nächsten sechs bis zwölf Monaten auf diese Art Problem stoßen. Auch wenn dein Zeitplan länger ist, diese Entscheidungen würde ich jetzt treffen:

Menschlich getaktete Kontrollen erfassen. Liste jede Freigabe, jedes Review und jeden Pipeline-Schritt auf, der von einer Person und einem Arbeitstag ausgeht. Markiere, was beim zehnfachen Volumen bricht.
Risikostufen für Änderungen einführen. Schreib auf, welche Änderungen einen Menschen brauchen, welche nur eine Prüfung der Absicht und welche nur Protokollierung. Mach die Regel maschinenlesbar.
Agents eigene Identitäten geben. Keine geteilten Dienstkonten, jeder Agent mit Sponsor, Berechtigungen über Access Packages mit Ablaufdatum.
Integrationen für Maschinen-Clients auslegen. Delta Queries, Change Notifications und API-Budgets statt Polling und Scraping.
Agentenkosten zuordnen. Tokens und Laufzeit pro Projekt plus die menschliche Review-Zeit, ab dem ersten produktiven Agent.

Was ich nicht tun würde: Anthropics Werkzeuge nachbauen. Deren Problem waren 25 Millionen Checkouts am Tag. Deins ist wahrscheinlicher ein Change-Prozess, der zwei Wochen für eine Konfigurationsänderung braucht, die ein Agent in zehn Minuten vorbereitet hat. Dort fängst du an.

Quellen

Anthropic Engineering: Redesigning source control at Anthropic (13. Oktober 2026)
Microsoft Learn: Microsoft Graph throttling guidance
Microsoft Learn: Avoid getting throttled or blocked in SharePoint Online
Microsoft Learn: Governing agent identities
Microsoft Learn: Manage agent registry in Microsoft 365 admin center
Microsoft Learn: Agent 365 observability
EUR-Lex: Richtlinie (EU) 2022/2555 (NIS2), Artikel 21

PowerShell oder Microsoft Graph? Die passende Schnittstelle wählen und Modulkonflikte beheben

Sun, 11 Oct 2026 07:00:00 +0200

Hinter „Machen wir das mit PowerShell oder mit Graph?“ stecken zwei Fragen: Welche Schnittstelle bietet überhaupt, was ich brauche? und Wie läuft das Ding in sechs Monaten, wenn keiner mehr draufschaut? Und wer schon einmal das Graph-PowerShell-SDK mit PnP.PowerShell oder dem Exchange-Online-Modul in einem Skript kombiniert hat, kennt die dritte Frage, die erst gestellt wird, wenn es knallt: Laufen diese Module überhaupt zusammen?

Kurz gesagt

Exchange Online PowerShell für Exchange-Administration (Postfachberechtigungen, Transportregeln, Organisationseinstellungen). Graph deckt das größtenteils nicht ab.

Microsoft Graph für Identitäten, dienstübergreifende Daten und alles, was eine Anwendung tut: Integrationen, Mailversand, Reporting. Für den Postfachzugriff durch Anwendungen ist Graph die Schnittstelle, auf die du baust.

Die klassische Falle beim Kombinieren: Assembly-Konflikte (Microsoft.Identity.Client, Microsoft.Graph.Core, Azure.Core …) zwischen Microsoft.Graph, PnP.PowerShell, ExchangeOnlineManagement und Az. Die Verbindungsreihenfolge ist Glückssache; Prozess-Isolation und weniger Module sind die eigentliche Lösung.

Wofür du dich tatsächlich entscheidest

Das Microsoft-Graph-PowerShell-SDK ist PowerShell und ruft unter der Haube Graph auf. Gewählt wird also zwischen zwei Arten von Schnittstellen:

Dienstspezifische Admin-Module: ExchangeOnlineManagement, MicrosoftTeams, PnP.PowerShell für SharePoint. Sie sprechen mit den Admin-Schnittstellen eines Workloads und bieten Dinge, die es in Graph schlicht nicht gibt.
Microsoft Graph: eine REST-API für Entra ID, Mail, Kalender, Dateien, Teams, Planner und vieles mehr, aufrufbar von überall: Graph-PowerShell-SDK, Invoke-RestMethod, C#, Python, Logic Apps oder ein Ticketsystem.

Welches von beiden passt, hängt zuerst davon ab, welche Schnittstelle das überhaupt kann.

Wo was gewinnt

Aufgabe	Meine Wahl	Warum
Full Access / Send As, Transportregeln, organisationsweite Exchange-Einstellungen	Exchange Online PowerShell	Dafür gibt es keine Graph-Endpunkte. Die neue Exchange Online Admin API (Preview) deckt nur einen kleinen Ausschnitt ab, etwa Ordnerberechtigungen und Send on Behalf.
Benutzer, Gruppen, Lizenzen, App-Registrierungen in Entra ID	Graph (SDK oder REST)	Das ist Graphs Heimspiel.
Eine Anwendung sendet oder liest Mails (Ticketsystem, Workflows)	Graph	`sendMail` bzw. Message-Endpunkte mit OAuth, eingegrenzt über RBAC for Applications.
Site-Provisioning, Templates, SharePoint-Berechtigungen	PnP.PowerShell	Für Admin-Aufgaben deutlich mächtiger als Graphs SharePoint-Schnittstelle.
Teams-Richtlinien (Besprechungen, Telefonie, Messaging)	MicrosoftTeams-Modul	Richtlinien leben in der Teams-Admin-Schnittstelle, nicht in Graph.
Dienstübergreifendes Reporting (Benutzer + Lizenzen + Anmeldungen + Gruppen)	Graph	Eine API, ein Auth-Modell, Paging und `$select` inklusive.

Meine Faustregel: Führt ein Mensch es aus, nimm das Modul, das am nächsten am Workload ist. Führt eine Anwendung es aus, nimm Graph – und gib dieser Anwendung genau die Rechte, die sie braucht, und keine mehr.

Praxisbeispiel: Mail-Integrationen

Der LinkedIn-Post, der diesen Artikel angestoßen hat, beschreibt die Modernisierung einer ServiceNow-Mailintegration, die Mails jetzt über Microsoft Graph sendet und empfängt. Hier arbeitet eine Anwendung mit Postfächern, kein Mensch, und genau da passt Graph: OAuth, granulare Berechtigungen und ein sauberer Audit-Trail. Eine Mail zu senden ist ein einziger Aufruf:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Microsoft Graph v1.0 – send mail as the service mailbox (app-only)
# Required application permission: Mail.Send (scoped via RBAC for Applications, see below)
$message = @{
 message = @{
 subject = 'Ticket INC0012345 updated'
 body = @{ contentType = 'Text'; content = 'Your ticket has been updated.' }
 toRecipients = @(@{ emailAddress = @{ address = 'adele.vance@contoso.com' } })
 }
 saveToSentItems = $true
}

Invoke-MgGraphRequest -Method POST `
 -Uri 'https://graph.microsoft.com/v1.0/users/servicedesk@contoso.com/sendMail' `
 -Body ($message | ConvertTo-Json -Depth 10) -ContentType 'application/json'

Was ich aus Sicht regulierter Umgebungen ergänzen würde: Eine App mit der Anwendungsberechtigung Mail.Send darf standardmäßig als jedes Postfach im Tenant senden. Das möchtest du keinem Auditor erklären. Mit RBAC for Applications in Exchange Online grenzt du den Service Principal auf die Postfächer ein, die er wirklich braucht:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Exchange Online PowerShell – scope a ticketing app to its service mailboxes only
# Prerequisite: the Entra app has NO tenant-wide Mail.Send consent (otherwise permissions add up)
# IDs from "Enterprise applications" in Entra, not from "App registrations"
New-ServicePrincipal -AppId '<app-id>' -ObjectId '<service-principal-object-id>' -DisplayName 'Ticketing'

New-ManagementScope -Name 'Ticketing-Mailboxes' `
 -RecipientRestrictionFilter "CustomAttribute10 -eq 'Ticketing'"

New-ManagementRoleAssignment -App '<service-principal-object-id>' `
 -Role 'Application Mail.Send' `
 -CustomResourceScope 'Ticketing-Mailboxes'

# Verify before you go live
Test-ServicePrincipalAuthorization -Identity '<service-principal-object-id>' -Resource 'servicedesk@contoso.com'

Die Ironie dabei: Graph-Berechtigungen konfigurierst du mit Exchange-PowerShell. Genau das meint der Original-Post mit „beides zusammen“.

Modulkonflikte zwischen Graph, PnP und EXO

Angenommen, du schreibst ein völlig vernünftiges Skript: Graph für Benutzerdaten, PnP für SharePoint, EXO für Postfächer. Auf deinem Rechner läuft es. In der nächsten Sitzung scheitert es dann mit etwas wie:

1
2


Could not load type 'Microsoft.Identity.Client.BaseAbstractApplicationBuilder`1'
from assembly 'Microsoft.Identity.Client, Version=4.50.0.0'

oder

1

Method not found: '!0 Microsoft.Identity.Client.BaseAbstractApplicationBuilder`1.WithLogging(...)'

Warum das passiert

Jedes dieser Module ist ein Binärmodul und bringt eigene Kopien gemeinsam genutzter .NET-Bibliotheken mit – allen voran MSAL (Microsoft.Identity.Client.dll), aber auch Azure.Core, Azure.Identity, Microsoft.Graph.Core oder System.Text.Json. PowerShell lädt Assemblies pro Prozess in einen gemeinsamen Kontext, und dort kann von einer Assembly mit gegebenem Namen nur eine Version geladen sein. Wer zuerst lädt, gewinnt; das andere Modul läuft dann gegen eine Version, für die es nie gebaut wurde.

Microsofts eigene PowerShell-Dokumentation beschreibt genau das: Das Ergebnis hängt davon ab, welches Modul zuerst geladen wurde, welcher Codepfad lief und ob die Abhängigkeit beim Import oder erst bei der ersten Nutzung geladen wird. Deshalb funktioniert dasselbe Skript mal, mal nicht, je nachdem, was du vorher in der Sitzung gemacht hast.

Bekannte Kombinationen, die Ärger gemacht haben:

PnP.PowerShell + Microsoft.Graph: Ältere PnP-Versionen brachten ein veraltetes Microsoft.Graph.Core (1.25.x) und ältere MSAL-Versionen mit, wodurch Connect-MgGraph und Invoke-MgGraphRequest nach dem Laden von PnP scheiterten.
ExchangeOnlineManagement + Microsoft.Graph: eine lange Geschichte. EXO 3.5.1 brachte einen Konflikt mit System.Text.Json; im Juni 2026 berichtete Tony Redmond, dass mit Graph SDK 2.38 und EXO 3.10 in PowerShell 7 keine Verbindungsreihenfolge zuverlässig funktionierte: Die eine scheitert mit dem Method not found oben, die andere mit einer NullReferenceException beim Token-Abruf.
Az.Accounts + Microsoft.Graph: dasselbe Muster mit Azure.Core / Azure.Identity.

So erkennst du es

Erste Prüfung: Was ist in der aktuellen Sitzung tatsächlich geladen?

1
2
3
4
5
6
7
8


# Which version of the usual suspects is loaded in this session – and from which module folder?
$suspects = 'Microsoft.Identity.Client', 'Microsoft.Graph.Core', 'Azure.Core', 'Azure.Identity', 'System.Text.Json'

[System.AppDomain]::CurrentDomain.GetAssemblies() |
 Where-Object { $_.GetName().Name -in $suspects } |
 Select-Object @{ n = 'Assembly'; e = { $_.GetName().Name } },
 @{ n = 'Version'; e = { $_.GetName().Version } },
 Location

Zeigt Location in den PnP-Ordner, während du Connect-MgGraph aufrufst, hast du den Übeltäter.

Zweite Prüfung: Welche Versionen bringen deine installierten Module mit? Diese Inventur macht Konflikte sichtbar, bevor sie in Produktion zuschlagen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


$modules = 'Microsoft.Graph.Authentication', 'PnP.PowerShell', 'ExchangeOnlineManagement', 'Az.Accounts', 'MicrosoftTeams'
$dlls = 'Microsoft.Identity.Client.dll', 'Microsoft.Graph.Core.dll', 'Azure.Core.dll', 'Azure.Identity.dll'

Get-Module -ListAvailable -Name $modules | ForEach-Object {
 $module = $_
 Get-ChildItem -Path $module.ModuleBase -Recurse -Include $dlls -File -ErrorAction SilentlyContinue |
 ForEach-Object {
 [pscustomobject]@{
 Assembly = $_.BaseName
 Version = [System.Reflection.AssemblyName]::GetAssemblyName($_.FullName).Version
 Module = "$($module.Name) $($module.Version)"
 Path = $_.FullName
 }
 }
} | Sort-Object Assembly, Version | Format-Table Assembly, Version, Module -AutoSize

Manche Module enthalten getrennte Builds für .NET Framework und .NET, du siehst also eventuell zwei Einträge pro Modul. Spannend wird es, wenn dieselbe Assembly modulübergreifend in unterschiedlichen Versionen auftaucht.

So löst du es

In dieser Reihenfolge:

1. Lade nicht, was du nicht brauchst. Ist PnP.PowerShell ohnehin verbunden, brauchst du das Graph-SDK oft gar nicht. Invoke-PnPGraphMethod ruft Graph über die PnP-Verbindung auf (sofern deine PnP-App-Registrierung die nötigen Graph-Berechtigungen hat). Und wenn du das SDK brauchst: Microsoft.Graph.Authentication plus die ein, zwei Submodule installieren, die du wirklich nutzt (oder nur Invoke-MgGraphRequest), statt des kompletten Metamoduls Microsoft.Graph.

2. Pro Prozess isolieren. Assemblies gelten pro Prozess, getrennte Prozesse können also nicht kollidieren. In PowerShell 7 läuft Start-Job in einem Kindprozess:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Graph work in its own process – app-only auth with a certificate
# Required application permission: User.Read.All
$auth = @{ ClientId = '<app-id>'; TenantId = 'contoso.onmicrosoft.com'; Thumbprint = '<cert-thumbprint>' }

$users = Start-Job -ArgumentList $auth -ScriptBlock {
 param($a)
 Connect-MgGraph -ClientId $a.ClientId -TenantId $a.TenantId -CertificateThumbprint $a.Thumbprint -NoWelcome
 Get-MgUser -Filter 'accountEnabled eq true' -All -Property id, userPrincipalName, department |
 Select-Object Id, UserPrincipalName, Department
} | Receive-Job -Wait -AutoRemoveJob

# Main session: PnP only – Graph's assemblies were never loaded here
Connect-PnPOnline -Url 'https://contoso.sharepoint.com/sites/hr' `
 -ClientId $auth.ClientId -Tenant $auth.TenantId -Thumbprint $auth.Thumbprint

Der Job liefert deserialisierte Objekte zurück (Eigenschaften ja, Methoden nein), genau richtig, um Daten zwischen Schritten weiterzureichen. Wichtig: Start-ThreadJob und ForEach-Object -Parallel isolieren nicht. Sie laufen im selben Prozess und teilen sich die geladenen Assemblies.

3. Runbooks und Pipelines aufteilen. In Azure Automation getrennte Runtime Environments (PowerShell 7.4) pro Modulkombination statt einer „Alles drin“-Umgebung. In CI/CD ein Job pro Workload. Das bringt nebenbei sauberere Berechtigungen pro Identität, also Least Privilege gleich mit.

4. Versionen bewusst pinnen. #Requires -Modules @{ ModuleName = 'ExchangeOnlineManagement'; RequiredVersion = '<tested-version>' } am Skriptanfang macht aus „nach dem Update kaputt“ ein „startet gar nicht erst“ – der deutlich bessere Fehlerfall. Module gezielt aktualisieren, nach einem Smoke-Test, der jede genutzte Modulkombination importiert und verbindet.

5. Notlösung: Verbindungsreihenfolge und DLL-Tausch. Eine bestimmte Reihenfolge beim Verbinden oder eine neuere Microsoft.Identity.Client.dll in den Ordner eines anderen Moduls kopieren: Beides kursiert in der Community. Das hilft vielleicht über einen Tag, ist aber nicht supportet, wird beim nächsten Update-Module überschrieben und hört, wie der EXO/Graph-Fall von 2026 zeigt, ohne Vorwarnung auf zu funktionieren. Produktive Automatisierung würde ich darauf nicht bauen.

Weitere Fallstricke

Windows PowerShell 5.1 und PowerShell 7 verhalten sich unterschiedlich. .NET Framework und .NET laden Assemblies anders; eine Kombination, die in 7 scheitert, kann in 5.1 funktionieren und umgekehrt. PnP.PowerShell 3.x setzt ohnehin PowerShell 7.4 oder neuer voraus – „dann eben 5.1“ ist für SharePoint keine Option.
-DisableWAM ist keine Lösung. Seit EXO 3.7.0 ist der Web Account Manager der Standard-Broker für interaktive Anmeldungen. Connect-ExchangeOnline -DisableWAM umgeht Konflikte manchmal, Microsoft beschreibt es aber ausdrücklich als vorübergehende Maßnahme.
App-only schlägt interaktiv. Zertifikatsbasierte Anmeldung umgeht die meisten WAM-/Broker-Probleme und ist für geplante Automatisierung ohnehin das Mittel der Wahl.
Berechtigungen addieren sich. Bei RBAC for Applications wirken Entra-Consent und Exchange-Rollenzuweisung additiv. Ein tenantweiter Mail.Send-Consent in Entra ID hebelt deine eingegrenzte Zuweisung stillschweigend aus.
Die Exchange Online Admin API ist Preview und bewusst schmal. Sie ergänzt EXO PowerShell, ersetzt es aber nicht.

Fazit

Die Admin-Module liefern die Tiefe des jeweiligen Workloads, Graph gibt Anwendungen einen einheitlichen, nachvollziehbaren Zugang und ist damit der natürliche Ort für jede Postfach-Integration. Wenn du Module kombinierst, behandle sie wie Komponenten mit Abhängigkeiten: weniger laden, pro Prozess isolieren, Versionen pinnen und Updates testen, bevor deine Runbooks es für dich tun.

Quellen

Inspiriert von einem LinkedIn-Post von Anthony Samuel.