Exchange Web Services (EWS) haben in Exchange Online nicht mehr lange. Ab dem 1. Oktober 2026 blockiert Microsoft in der Cloud jede EWS-Anfrage. Davon sind viele Integrationen betroffen, die jahrelang ohne Murren liefen. In fast jedem Tenant, den ich betreue, finden sich noch ein paar hartnäckige EWS-Consumer. Die verbleibenden neun Monate solltet ihr deshalb nutzen, um sie aufzuspüren, Alternativen zu klären und auf Microsoft Graph umzuziehen. Exchange On-Premises ist übrigens nicht betroffen.

Die EWS-Abschaltung trifft weit mehr als nur Entwickler

Viele halten das Ende von EWS für ein Thema, das nur Entwickler oder Softwarehersteller angeht. So einfach ist es leider nicht. Häufig hängen unauffällige Drittsysteme an der EWS Managed API, etwa E-Mail-Archivierung, CRM-Plug-ins, Raumverwaltung, Signaturtools oder ältere Automatisierungsskripte. Interne Webanwendungen und Monitoring-Tools können ebenfalls betroffen sein, vor allem wenn sie mit den Berechtigungen „EWS.AccessAsUser.All“ oder „full_access_as_app“ arbeiten. In Projekten staune ich jedes Mal, wie viele Integrationen still im Hintergrund mitlaufen, ohne dass jemand davon weiß.

Mein Tipp: Fangt sofort an, die EWS-Rechte systematisch zu inventarisieren. Fällt erst in einer späteren Migrationsphase plötzlich eine Integration aus, lässt sich die Ursache oft nur mühsam zurückverfolgen.

Entra Admin Center und Anmeldeprotokolle verraten die meisten EWS-Consumer

Meine Suche nach EWS-Verbindungen startet immer im Entra Admin Center unter „Enterprise-Anwendungen“. Dort filtere ich nach Anwendungen, denen EWS-Berechtigungen ausdrücklich erteilt wurden. Entscheidend sind „EWS.AccessAsUser.All“ (delegierter Zugriff) und „full_access_as_app“ (ApplicationImpersonation). Die Spalte „Berechtigungen“ verschafft hier schnell einen Überblick. Klickt man eine verdächtige App an, sieht man, wer sie nutzt und wann sie sich zuletzt angemeldet hat. Wer genauer hinschauen will, sollte zusätzlich die Anmeldeprotokolle (Sign-in Logs) auswerten. Damit kommen auch selten genutzte oder längst vergessene Integrationen zum Vorschein.

Das folgende Diagramm skizziert, wie eine EWS-Integration im Tenant typischerweise abläuft. Es macht die beteiligten Rollen und Pfade etwas greifbarer:

flowchart TD
    User["Benutzer"] --> App["EWS-Clientanwendung"]
    App --> Entra["Microsoft Entra ID"]
    Entra --> Exchange["Exchange Online EWS Endpoint"]
    Exchange --> Data["Postfachdaten"]

Abbildung: Die EWS-Clientanwendung authentifiziert sich über Entra ID und greift dann auf Exchange Online zu.

Besonders heikel sind Apps mit ApplicationImpersonation, weil sie sehr weitreichende Rechte haben. Wie ihr solche Zugriffe bewertet und welche Alternativen es gibt, habe ich in einem eigenen Beitrag ausführlich beschrieben: /blog/exchange-online-ews-applicationimpersonation-abloesen.

Einige Systemklassen hängen fast immer an EWS und müssen zu Graph wechseln

In meinen Projekten tauchen diese Kandidaten fast immer auf:

  • E-Mail-Archivierungslösungen (Journalexport, Compliance-Archiv)
  • CRM- und ERP-Systeme mit E-Mail- und Kalenderintegration
  • Buchungssysteme für Besprechungsräume
  • Signaturmanagement (z. B. serverseitige E-Mail-Signaturen)
  • Eigene Automatisierungsskripte mit der EWS Managed API (mehr dazu in der Microsoft-Dokumentation)

Viele Hersteller unterstützen Microsoft Graph inzwischen, längst aber nicht alle. Da bleibt nur, den Anbieter direkt anzusprechen und nach Roadmap und geplanten Updates zu fragen. Bei Eigenentwicklungen solltet ihr prüfen, ob sich alle benötigten Funktionen mit Graph umsetzen lassen. Als Einstieg eignet sich die offizielle Migrationsübersicht von Microsoft.

Die Anmeldeprotokolle zeigen, welche Apps EWS noch wirklich nutzen

Welche Service Principals tatsächlich noch EWS-Aufrufe absetzen, prüfe ich regelmäßig in den Anmeldeprotokollen unter Entra Admin Center → Überwachungsprotokolle → „Anmeldungen“. Dort lässt sich nach Anwendungen filtern und die API-Nutzung ablesen. Mit dem Filter „Anwendungsberechtigungen“ sucht ihr gezielt nach EWS. Am aussagekräftigsten ist das Zeitfenster „letzte 90 Tage“: Daran erkennt man, ob eine Integration noch aktiv genutzt wird oder schon lange brachliegt.

Eigene Skripte und Automatisierungen müssen auf Microsoft Graph umziehen

Für selbst geschriebene PowerShell- oder .NET-Skripte gibt es keine Alternative zum Wechsel auf Microsoft Graph. Wie aufwendig das wird, hängt vom Funktionsumfang ab. Für viele EWS-APIs gibt es in Graph aber längst ein Gegenstück, etwa für Postfachzugriffe, Kalender, Kontakte oder Raumbuchungen. Die Authentifizierung erfolgt anschließend nur noch über Entra ID und OAuth 2.0. In PowerShell sieht der Einstieg typischerweise so aus (PowerShell 7, Graph PowerShell SDK, Rolle: Exchange Administrator):

# Verbindung zum Microsoft Graph
Connect-MgGraph -Scopes "Mail.ReadWrite.All", "Calendars.ReadWrite.All"
# Beispiel: Liste der letzten 10 E-Mails aus dem Posteingang
Get-MgUserMailFolderMessage -UserId "[email protected]" -MailFolderId "inbox" -Top 10

Wer komplexere Szenarien umsetzen will, findet weitere Hinweise in meinem älteren Beitrag Microsoft 365 mit dem Microsoft Graph PowerShell SDK automatisieren – der Alltag nach AzureAD und MSOnline.

Neun Monate reichen nur, wenn ihr sofort mit dem Aufräumen beginnt

Neun Monate klingen nach viel Zeit, sind in der IT aber schnell verbraucht, sobald Migrationen, Abstimmungen mit Softwareherstellern und Testzyklen anstehen. Wer in Exchange Online noch von EWS abhängt, sollte deshalb jetzt anfangen. Bestandsaufnahme, Bewertung und Migration schiebt man besser nicht bis in die Sommerpause. Ein sauber geplanter Umstieg bewahrt euch vor Ausfällen und bringt oft auch bei der Sicherheit etwas, denn Graph und OAuth sind gegenüber EWS und Basic Auth ein klarer Fortschritt. Weitere Details zur Migrationsplanung findet ihr wie immer in der Microsoft-Dokumentation und im Message Center.