Vor der EWS-Abschaltung bleiben Admins noch vier Wochen für offene Punkte

Vor ziemlich genau neun Monaten habe ich hier im Blog meinen ersten Praxisleitfaden zur EWS-Abschaltung in Exchange Online veröffentlicht (/blog/ews-abschaltung-exchange-online-oktober-2026). Seitdem hat sich einiges getan. Trotzdem halten sich in vielen Tenants, die ich in Projekten begleite, ein paar Altlasten hartnäckig in der Inventarliste. In einem Monat, am 1. Oktober 2026, blockiert Microsoft Exchange Web Services (EWS) für Exchange Online endgültig. Wer dann noch offene Baustellen hat, muss jetzt zügig und geordnet handeln. Für die letzten Wochen vor dem Stichtag habe ich meine persönliche Checkliste zusammengestellt.

Die offenen Punkte aus der Januar-Inventur brauchen jetzt eine Entscheidung

In Projekten hat mich oft überrascht, wie viele Drittanbieter-Tools und alte Skripte tatsächlich noch EWS nutzen. Manche davon galten längst als stillgelegt und tauchten erst nach dem ersten Scan oder durch konkrete Anfragen aus den Fachbereichen wieder auf. Vier Wochen vor der Abschaltung sollten die letzten offenen Einträge der Bestandsaufnahme erledigt sein. Für jede Applikation muss feststehen, ob sie migriert wurde, ob eine schriftliche Bestätigung des Anbieters vorliegt oder ob der Betrieb offiziell eingestellt ist. Bei kleinen Eigenentwicklungen und selten genutzten Schnittstellen lohnt sich ein weiterer Blick ins Log. Nicht selten findet sich dort ein vergessener Dienst oder Benutzer, den die Abschaltung dann unerwartet trifft.

Jede Zusage eines Anbieters gehört schriftlich in die Dokumentation

In mehreren Projekten kamen Aussagen wie „Ja, unsere App ist jetzt auf Graph umgestellt“ nur mündlich oder per E-Mail. Das reicht nicht. Für jede Lösung, die noch läuft, braucht es eine schriftliche und nachvollziehbare Bestätigung, am besten im Systemticket oder in der zentralen Projektdokumentation. Sie hilft im Oktober, wenn plötzlich eine Anwendung ausfällt, und erleichtert später die Nachverfolgung. Bei Audits oder Sicherheitsprüfungen kommt sonst schnell die Frage auf, warum eine App weiterhin auf EWS gesetzt hat. Auch bei selbst geschriebenen Skripten gehört in die Dokumentation, ob und wie sie migriert oder abgeschaltet wurden.

Skripte und PowerShell-Workflows müssen auf Microsoft Graph umziehen

In vielen Projekten wurde unterschätzt, wie viele Automatisierungen noch EWS verwenden, vor allem mit ApplicationImpersonation oder für Kalenderabfragen. Je nach Umfang kann die Migration auf Microsoft Graph PowerShell sehr aufwendig werden. Microsoft hat die wichtigsten Unterschiede und das Vorgehen unter anderem hier zusammengefasst: https://learn.microsoft.com/en-us/graph/migrate-exchange-web-services-overview. Für typische PowerShell-Workflows mit Postfachzugriff gibt es inzwischen meist funktionale Alternativen in Microsoft Graph. Berechtigungsmodelle und Authentifizierungswege unterscheiden sich allerdings oft deutlich. Wer zum Beispiel Reports zu Postfächern oder Kalendern erzeugt, sollte die neuen Graph-Scopes und die Authentifizierung über Service Principals in Entra ID gründlich testen.

Praxistipp: Automatisierte Skripte sollten mindestens einmal in einer produktionsnahen Umgebung mit Multi-Faktor-Authentifizierung (MFA) laufen. Gerade in Nischen-Jobs stecken manchmal noch „Service Accounts“ mit Basic Auth.

Ein Testplan legt fest, wer den Ausfall zuerst bemerkt

Nun geht es um die Organisation. Es muss feststehen, wer am 1. Oktober zuständig ist, wenn ein Dienst plötzlich nicht mehr läuft. Ich empfehle, für jedes abgelöste System einen konkreten Testfall zu dokumentieren, etwa einen manuellen oder automatisierten Test, der prüft, ob die Funktion nach dem Stichtag noch gegeben ist. Ebenso sollten jetzt die Kommunikationspläne stehen, über die Fachbereiche und IT-Hotline informiert werden. Gut gefahren bin ich damit, die Verantwortlichen der betroffenen Applikationen vorab zu informieren und sie zum Testen aufzufordern. Dann hält sich der Supportaufwand am Stichtag in Grenzen.

Am 1. Oktober richtet sich der Blick auf Monitoring und Support

Am Tag der EWS-Abschaltung muss die Fehlersuche schnell gehen. Das Monitoring sollte deshalb gezielt auf typische Fehlerbilder ausgerichtet sein. Dazu zählen Fehlermeldungen, die in der Flut der Helpdesk-Tickets auftauchen, vor allem aber deutlich steigende Anmeldefehler von Service Principals oder Applikationen. In Entra ID sind die Anmeldeprotokolle die wichtigste Quelle, um fehlgeschlagene Anfragen mit EWS als Client herauszufiltern. Dabei hilft die folgende KQL-Abfrage (Voraussetzung: Entra ID P1/P2, Sign-In-Logs nach Log Analytics exportiert, Rolle: Security Reader):

SigninLogs
| where AppDisplayName contains "Exchange Web Services"
| where ResultType != 0
| project UserPrincipalName, AppDisplayName, ClientAppUsed, ResultDescription, TimeGenerated

Die Abfrage läuft im Log Analytics Workspace → Logs und zeigt fehlgeschlagene Anmeldeversuche über EWS in Echtzeit.

Der Helpdesk sollte die typischen Fehlerbilder und Meldungen kennen, damit er sie schnell erkennt und weiterleitet. Eine Rückfrage kommt erfahrungsgemäß immer wieder, deshalb hier noch einmal deutlich: EWS in Exchange Server (On-Premises) ist von der Abschaltung nicht betroffen.

Das folgende einfache Flussdiagramm zeigt, wie die letzten Schritte bis zum 1. Oktober ablaufen sollten:

flowchart TD
    Inventur["EWS App-Inventur abgeschlossen?"] -->|"ja"| Migration["Migration/Abschaltung durchgeführt?"]
    Migration -->|"ja"| Test["Testfall dokumentiert?"]
    Test -->|"ja"| Kommunikation["Fachbereiche informiert?"]
    Kommunikation --> Monitoring["Monitoring am Stichtag aktiv?"]

Abbildung: Die letzten Wochen vor der EWS-Abschaltung, von der Inventur bis zum Echtzeit-Monitoring.

Beim letzten Durchgang darf man ruhig pingelig sein

Die vergangenen Monate haben mir gezeigt, dass man die wirklich kritischen EWS-Nutzer selten auf Anhieb findet. Fast immer taucht noch irgendwo ein alter Connector, ein vergessenes Skript oder ein Dienstkonto auf, besonders in dezentral aufgestellten Organisationen. Eine App oder einen User prüft man besser einmal zu oft als einmal zu wenig. Am Stichtag selbst braucht es einen klaren Kommunikations- und Notfallplan. Wer die Checkliste heute noch einmal konsequent durchgeht, kann dem 1. Oktober recht gelassen entgegensehen. Und falls doch noch jemand EWS braucht, ist das On-Premises weiterhin möglich. Dann sollte man sich aber erklären lassen, warum das wirklich nötig ist.