Nach der EWS-Abschaltung in Exchange Online beginnt die Fehlersuche

Seit dem 1. Oktober 2026 ist EWS in Exchange Online endgültig blockiert. Eigentlich hätten wir Admins uns lange darauf vorbereiten sollen, in vielen Tenants ist das aber natürlich nicht geschehen. Gerade in den letzten Wochen erreichen mich ständig Anfragen, warum eine Anwendung plötzlich keine Kalenderdaten mehr abruft oder nicht mehr auf Postfächer zugreifen kann. Oft stellt sich heraus, dass alte Integrationen, Tools von Drittanbietern oder interne Skripte nie daraufhin geprüft wurden, ob sie migriert werden müssen. Jetzt steht die Fehlersuche nach der EWS-Blockade an, und die ist kniffliger, als man zunächst denkt.

Nach der EWS-Blockierung fallen zuerst Scanner und Fachanwendungen aus

Meist bemerkt man den Ausfall erst, wenn wichtige Prozesse stillstehen. Nutzer oder Applikationsverantwortliche melden dann Kalender, die nicht mehr synchronisieren, fehlgeschlagene Service-Checks oder Benachrichtigungen, die einfach ausbleiben. In den Fehlermeldungen tauchen häufig „401 Unauthorized“, „403 Forbidden“ oder ganz allgemein „Failed to connect to Exchange Online“ auf, ein klarer Hinweis auf EWS fehlt dabei meistens. In Outlook selbst merkt man übrigens fast nie etwas davon, weil moderne Clients längst MAPI oder Graph verwenden. Es trifft vielmehr Scanner, Tools für Raumbuchung und Zeiterfassung oder Monitoring-Dienste. In mehreren Projekten bin ich außerdem auf Servicekonten mit ApplicationImpersonation-Rechten gestoßen, die noch immer existieren und jetzt ins Leere laufen. Für einen schnellen Überblick sucht man im Entra Admin Center nach solchen Service Principals und prüft, ob sie in letzter Zeit fehlgeschlagene Anmeldeversuche hatten.

Die Entra-Sign-in-Logs führen am schnellsten zur betroffenen Anwendung

Für eine genauere Analyse ist im Moment das Entra Admin Center → Überwachung & Integrität → Anmeldeprotokolle → Anmeldungen von Dienstprinzipalen die beste Adresse. Dort lässt sich gezielt nach Anwendungen filtern, zum Beispiel nach den fehlgeschlagenen Anmeldeversuchen der vergangenen Tage. Das setzt einen aktiven Entra-ID-P1- oder -P2-Plan voraus, außerdem muss die Protokollierung für Service-Principal-Sign-ins eingeschaltet sein. In der Detailansicht erscheinen dann Anmeldeversuche, die /EWS/ oder /ews/exchange.asmx aufrufen und mit „interaktive Anmeldung nicht möglich“, „Client not allowed“ oder „Blocked due to EWS deprecation“ abgewiesen werden. Ein typischer Suchfilter im Portal sieht so aus:

Service-Principal-Anmeldungen nach dem 1. Oktober mit dem Status „Fehlgeschlagen“, deren Anwendungspfad „EWS“ enthält. Damit hat man Zeitpunkt und App-Objekt schnell gefunden und kann klären, wem das Objekt gehört.

Weitere Details liefert die offizielle Dokumentation Sign-in logs overview. Mit ihrer Hilfe identifiziert man die betroffene App und kann zugleich klären, ob die Blockade wirklich auf EWS zurückgeht oder noch andere Ursachen mitspielen.

# PowerShell 7, Entra ID PowerShell-Modul, Rolle: Identity Reader oder höher
Get-MgAuditLogSignIn -Filter "ResourceDisplayName eq 'Exchange Online' and AppDisplayName ne null and Status/ErrorCode ne 0 and DateTime gt 2026-10-01"

Im Zweifel hat man damit sehr schnell alle fehlgeschlagenen Anmeldeversuche gegen Exchange Online vor sich, die nicht von Benutzeranmeldungen stammen. Wer lieber im Portal arbeitet, sucht im Feld „App-Name“ nach verdächtigen Einträgen, die etwa durch alte Namen oder EWS-Pfade auffallen.

Erst der Anwendungseigentümer kann sagen, was eine App wirklich tut

Sind die betroffenen Anwendungen gefunden, stellt sich gleich die nächste Frage: Wer ist für die App eigentlich zuständig, und was genau macht sie? In vielen Umgebungen ist das App-Objekt in Entra ID seit Jahren verwaist oder kaum dokumentiert. Ein erster Blick gilt dem Besitzer, der in der App-Übersicht im Entra Admin Center hinterlegt ist. Hilft das nicht weiter, fragt man im IT-Team herum oder durchsucht Teams und E-Mails nach dem ursprünglichen Entwickler. Gerade hinter alten Servicekonten mit ApplicationImpersonation stecken oft Mitarbeitende, die das Unternehmen längst verlassen haben. Dann bleibt nichts anderes übrig, als die Nutzung zu dokumentieren und die App notfalls abzuschalten.

Aus der Praxis noch ein Tipp:

Wer bei der Fehlersuche nach der EWS-Blockade Zeit sparen will, legt einen Katalog aller App-Registrierungen mit Mail-, Kalender- oder EWS-Berechtigungen an und prüft ihn regelmäßig. In vielen Tenants wurde das Thema immer wieder verschoben, und genau das rächt sich jetzt.

Neben den Logs hilft dabei auch das Microsoft-Graph-Portal, in dem sich App-Objekte gezielt filtern lassen.

Microsoft gewährt für EWS-Anwendungen keine Ausnahme mehr

Nach der aktuellen Ankündigung gibt es für EWS-Integrationen in Exchange Online keine Ausnahmeregelung mehr. Auch über eine Supportanfrage lässt sich EWS nicht vorübergehend wieder einschalten. Die Sperre gilt vollständig und für den gesamten Tenant. Wer noch Anwendungsfälle mit EWS hat, muss mit dem Anbieter reden oder die Funktion vorerst abschalten. In meinen Projekten gab es dabei so manche Überraschung. Einige Anbieter liefern zügig Updates oder unterstützen Exchange Online über Microsoft Graph, andere stellen ihr Produkt einfach ein. Bei Eigenentwicklungen bleibt oft nur, die betroffenen Skripte oder Schnittstellen stillzulegen, bis eine echte Alternative bereitsteht. Ausgenommen ist lediglich On-Premises-Exchange, und damit ist den meisten Organisationen heute kaum geholfen.

Dauerhaft hilft nur die Migration auf Microsoft Graph

Nachhaltig ist allein der vollständige Umstieg auf moderne APIs, allen voran Microsoft Graph. Die Umstellung ist technisch anspruchsvoll (neue Authentifizierung, komplexere Abfragen, oft andere Rechte) und verlangt häufig auch, den Umgang mit Servicekonten und App-Rechten grundsätzlich zu überdenken. Wer noch ApplicationImpersonation oder alte EWS-Flows einsetzt, muss jetzt Zeit und Kapazitäten in die Migration stecken. Die offizielle Anleitung von Microsoft gibt es hier: Migrate from EWS to Microsoft Graph. Es braucht Geduld und eine klare Abstimmung mit den Fachbereichen, damit plötzliche Ausfälle niemanden kalt erwischen. Wie es schon ab Januar zu ersten Störungen kommen konnte, beschreibe ich im Beitrag EWS-Abschaltung in Exchange Online aufspüren und migrieren. Meine Checkliste für den Endspurt im September steht unter Checkliste zur EWS-Abschaltung mit allen anstehenden Aufgaben.

Bevor die Migration startet, lohnt sich ein Blick auf dieses kleine Ablaufdiagramm mit den wichtigsten Schritten:

flowchart TD
Anwendung["Alte Anwendung nutzt EWS"] --> Fehler["Fehler nach Blockierung"]
Fehler --> Loganalyse["Sign-In Logs prüfen"]
Loganalyse --> Besitzer["App-Besitzer ermitteln"]
Besitzer --> Migration["Migration auf Graph planen"]
Migration --> Fertig["Anwendung wieder funktionsfähig"]

Abbildung: Typischer Weg von der Fehlersuche nach der EWS-Blockade bis zur Migration auf Microsoft Graph.

Aufräumen bringt jetzt mehr als die Suche nach Ausnahmen

Die EWS-Blockierung in Exchange Online ist endgültig, Kompromisse gibt es keine, und viele Applikationsverantwortliche wachen erst jetzt auf. Ich rate dazu, fehlgeschlagene Service-Principal-Anmeldungen ab sofort regelmäßig zu kontrollieren und alte App-Registrierungen aufzuräumen, bevor das Support-Ticket auf dem Tisch landet. Wer weiterhin an alten EWS-Integrationen festhält, riskiert Ausfälle und darüber hinaus echten Datenverlust oder Probleme mit der Compliance. Das Aufräumen kostet Mühe, eine Abkürzung gibt es aber nicht mehr. Wer langfristig Ruhe haben will, muss auf Microsoft Graph migrieren, und zwar gründlich.