EWS endet in Exchange Online am 1. April 2027: Ihre Integrationen auf Microsoft Graph umstellen

Microsoft hat begonnen, die Exchange Web Services (EWS) in Exchange Online abzuschalten. Die ersten Durchsetzungsschritte laufen in diesem Monat, danach werden Mandanten, die ihre EWS-Einstellungen nie angefasst haben, nacheinander abgeschaltet, und ab dem 1. April 2027 ist EWS für jeden Microsoft-365-Mandanten verschwunden. Microsoft hat klar gesagt, dass es nach April 2027 keine Ausnahmen geben wird.

Wenn etwas, das Ihr Unternehmen gebaut hat, über EWS mit Microsoft-365-Postfächern spricht, funktioniert es spätestens ab diesem Datum nicht mehr, möglicherweise schon viel früher. Die üblichen Verdächtigen: ein CRM, das Kunden-E-Mails den Accounts zuordnet, ein Archivierungs- oder Aufbewahrungsskript, ein Bildschirm zur Buchung von Besprechungsräumen, ein Ticketsystem, das ein gemeinsames Support-Postfach liest, ein Berichtsjob, der E-Mails pro Team zählt. Die Lösung ist eine Neuentwicklung gegen Microsoft Graph, und manches, was EWS konnte, hat in Graph überhaupt keine Entsprechung.

Was passiert, Datum für Datum

Microsoft steuert EWS je Mandant über die Einstellung EWSEnabled, die drei Werte hat: Null (der Standard), True und False. Daneben gibt es jetzt eine zweite Einstellung, EWSAllowedAppIDs: eine Liste von Anwendungs-IDs, die EWS weiter nutzen dürfen. Die aktuelle Seite auf Microsoft Learn nennt die Grundzüge: „Oktober 2026: EWS wird global für alle Organisationen deaktiviert“ und „April 2027: EWS ist vollständig deaktiviert.“

Die Einzelheiten stehen im Beitrag des Exchange-Teams vom 1. Oktober, EWS Deprecation Is Here. Für die weltweite kommerzielle Cloud gilt:

• 2. Oktober 2026, Tagesende pazifischer Zeit: Microsoft erfasst jeden Mandanten, bei dem EWSEnabled auf True steht, aber keine Zulassungsliste existiert.
• 8. und 9. Oktober 2026: Für diese Mandanten legt Microsoft die Zulassungsliste an und füllt sie mit den Anwendungs-IDs, die EWS in den vorangegangenen 60 Tagen genutzt haben.
• Ab 10. Oktober 2026: Steht EWSEnabled auf True, ist die Zulassungsliste Pflicht. Eine App, die nicht darauf steht, wird abgewiesen.
• Zweite Phase, danach: Bei Mandanten, die noch auf Null stehen, wird EWSEnabled auf False gesetzt, was EWS für jede Anwendung sperrt. Jeder erhält im Message Center eine Vorwarnung von 7 Tagen, und Microsoft füllt kurz zuvor eine Zulassungsliste aus 60 Tagen Nutzung, damit ein Administrator EWS mit True wieder einschalten kann.
• 1. April 2027: EWS ist „vollständig und dauerhaft deaktiviert“, und Mandantenadministratoren können EWSEnabled überhaupt nicht mehr ändern.

Mandanten in den anderen Clouds von Microsoft erhalten ihre eigenen Zeitpläne über das Message Center.

Die Zulassungsliste verschafft Zeit, keine Lösung

Die automatische Liste wird aus 60 Tagen Datenverkehr erstellt, und Microsofts eigene Anleitung vom 4. September warnt, dass sie „Anwendungen übersehen kann, die selten laufen“. Ein Export zum Quartalsende oder ein Archivjob zum Jahresende steht nicht darauf und scheitert beim nächsten Lauf.

Änderungen an der Zulassungsliste brauchen 24 Stunden, bis sie wirken, Änderungen an EWSEnabled etwa eine Stunde. Jede Korrektur nach einem Ausfall kostet Sie mindestens einen Tag.

Um zu sehen, wo Ihr Mandant steht, kann ein Administrator mit Exchange Online PowerShell Folgendes ausführen:

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Für wen das gilt und wer aufhören kann zu lesen

Exchange Server vor Ort ist nicht betroffen. Microsoft sagt, die Abkündigung gelte „nur für Microsoft 365 und Exchange Online“ und es gebe „keine Änderungen an EWS in Exchange Server“. Wenn alle Ihre Postfächer auf Ihren eigenen Servern liegen, können Sie hier aufhören.

Hybride Umgebungen brauchen einen genaueren Blick. Postfächer vor Ort können EWS weiter nutzen; Postfächer in der Cloud müssen auf Graph umziehen. Microsofts Beitrag zu hybriden Umgebungen vom 30. September behandelt zwei Fälle, die jetzt Handeln verlangen, darunter Postfächer vor Ort mit Archiven in Exchange Online. Dort lautet der Rat vorerst, EWS eingeschaltet zu lassen und die Hybridanwendung auf die Zulassungsliste zu setzen.

Standardsoftware ist Sache des Anbieters. Wenn das, was EWS aufruft, ein kommerzielles Produkt ist, muss der Anbieter eine Graph-Version liefern, und Ihre Aufgabe ist, ihm einen Termin abzuverlangen und das Update einzuspielen. Bei Microsofts eigenen Clients ist es nicht anders: Einige tauchen noch in den Nutzungsberichten auf und brauchen die Zulassungsliste, bis sie aktualisiert sind.

Eigener Code ist Ihre Sache. Skripte, interne Dienste, angepasste Open-Source-Werkzeuge und Integrationen, die eine Agentur vor Jahren gebaut hat, haben niemanden, der sie stromaufwärts repariert. Dort liegt die Arbeit. Zur Größenordnung: exchangelib, eine Python-Bibliothek für die Kommunikation mit Exchange über EWS, wurde im vergangenen Monat 1.174.625 Mal von PyPI heruntergeladen. Ein Teil davon ist Nutzung vor Ort, aber es zeigt, wie viel Code direkt EWS spricht.

Schritt eins: alles finden, was EWS nutzt

Beginnen Sie mit dem EWS-Nutzungsbericht im Microsoft 365 Admin Center (Berichte, Nutzung, Exchange, dann die Registerkarte für die EWS-Nutzung). Für jede Anwendung listet er die Anwendungs-ID in Microsoft Entra, jede SOAP-Aktion, die diese Anwendung aufgerufen hat, das Aufrufvolumen und das Datum der letzten Aktivität. Sie können 7, 30 oder 90 Tage zurückschauen und als CSV exportieren.

Drei Dinge sollten Sie darüber wissen:

• Die Daten werden wöchentlich aggregiert, und es kann bis zu 10 Tage dauern, bis sie erscheinen.
• Eine Anwendungs-ID ist kein Verantwortlicher. Gleichen Sie jede ID mit den Unternehmensanwendungen in Microsoft Entra ab und finden Sie dann die Person oder das Team, das sie betreibt. Rechnen Sie mit ein paar IDs, die niemand kennt.
• Die Spalte mit den SOAP-Aktionen zeigt, wie groß jede Aufgabe ist. Eine App, die nur FindItem und GetItem aufruft, ist schnell erledigt. Eine, die SyncFolderItems, Subscribe und ExportItems aufruft, ist ein Projekt.

Selbst 90 Tage übersehen Jahresjobs, prüfen Sie also auch die andere Seite: geplante Aufgaben und Cron-Einträge sowie Code-Repositories, durchsucht nach dem EWS-Endpunkt (Exchange.asmx), der EWS Managed API für .NET und exchangelib. Die Abkündigungsseite von Microsoft verlinkt außerdem einen EWS-Analyzer für .NET-Code (er markiert EWS-Aufrufe in Visual Studio und VS Code und schlägt Graph-Entsprechungen vor) und ein Tutorial zum KI-gestützten Refactoring.

Schritt zwei: entscheiden, was aus jeder Integration wird

Jede Anwendung auf der Liste bekommt eine von vier Antworten:

1. Stilllegen. Manche Integrationen existieren nur, weil niemand sie abgeschaltet hat.
2. Aktualisieren. Anbieterprodukte bekommen ein Upgrade vom Anbieter. Vereinbaren Sie den Termin jetzt.
3. Gegen Microsoft Graph neu schreiben. Der Normalfall für eigenen Code.
4. Neu entwerfen. Für alles, was auf einer Fähigkeit beruht, die Graph nie haben wird (siehe unten).

Microsoft nennt außerdem die Power Platform als Weg, einen Arbeitsablauf neu umzusetzen. Für ein Skript, das Anhänge in einen Ordner weiterleitet, kann das die günstigste Antwort sein.

Was eine Neuentwicklung gegen Graph tatsächlich bedeutet

Die meisten EWS-Operationen haben ein direktes Gegenstück in Graph, und Microsoft pflegt eine Zuordnung von EWS zu Graph. Die Zuordnung ist der einfache Teil. Die schwierigeren Teile sind die, die sie nicht zeigt.

Berechtigungen werden enger, und das ist gut so

Eine App, die EWS ohne angemeldeten Benutzer nutzt, besitzt die EWS-Anwendungsberechtigung, die Microsoft als „Vollzugriff auf alle Postfächer“ beschreibt. Graph teilt das in einzelne Berechtigungen auf: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read und so weiter.

Sie können auch einschränken, welche Postfächer eine App erreicht. RBAC for Applications in Exchange Online weist eine Berechtigung für einen Verwaltungsbereich oder eine Verwaltungseinheit zu und ersetzt die älteren Application Access Policies. Ein Bildschirm zur Raumbuchung kann die Kalender von zwölf Raumpostfächern lesen und sonst nichts. Eine Falle: Auf diesem Weg erteilte Berechtigungen kommen zu jeder mandantenweiten Berechtigung in Microsoft Entra hinzu. Wenn Mail.Read dort noch erteilt ist, schränkt Ihr Bereich also nichts ein. Entfernen Sie die Berechtigung in Entra.

Verwenden Sie zur Authentifizierung von Apps nach Möglichkeit Zertifikate statt geheimer Clientschlüssel, und halten Sie Zugangsdaten aus Skripten und Repositories heraus.

Synchronisierung und Benachrichtigungen werden neu gebaut, nicht übersetzt

Das ist meist die größte Änderung für alles, was eine lokale Kopie von Postfachdaten führt.

Synchronisierung. SyncFolderItems entspricht der Delta-Abfrage für Nachrichten in Graph, SyncFolderHierarchy der Delta-Abfrage für Mailordner. Das Nachrichten-Delta arbeitet ordnerweise, eine vollständige Postfachsynchronisierung heißt also, den Ordnerbaum zu verfolgen und je Ordner einen eigenen Delta-Link zu speichern. Die Filtermöglichkeiten sind begrenzt (nur nach Empfangsdatum), und die Ergebnisse enthalten Löschungen, Verschiebungen aus dem Ordner und Änderungen des Lesestatus, auch wenn sie nicht zu Ihrem Filter passen.

Benachrichtigungen. Streaming- und Push-Abonnements aus EWS werden zu Änderungsbenachrichtigungen in Graph, zugestellt an einen Webhook, den Sie betreiben, oder an Azure Event Hubs oder Event Grid. Ein Webhook muss von Microsofts Seite aus erreichbar sein. Für ein Skript, das bisher eine Verbindung von hinter der Firewall offen hielt, ist das eine Änderung der Architektur. Abonnements für E-Mail, Kalender und Kontakte halten höchstens 10.080 Minuten (knapp sieben Tage) oder 1.440 Minuten, wenn die Benachrichtigung die Daten mitliefert, also muss etwas sie erneuern. Jedes Postfach erlaubt höchstens 1.000 aktive Abonnements über alle Anwendungen hinweg.

Das Muster, das sich bewährt: Behandeln Sie eine Benachrichtigung als Hinweis, führen Sie die Delta-Abfrage aus, um zu sehen, was sich geändert hat, und führen Sie sie zusätzlich zeitgesteuert aus, um alles abzufangen, was eine verpasste Benachrichtigung verloren hätte.

Daten, IDs und Durchsatz

• Gespeicherte IDs. Wenn Ihr CRM oder Ticketsystem EWS-Element-IDs gespeichert hat, um E-Mails mit Datensätzen zu verknüpfen, müssen diese Verknüpfungen umgewandelt werden. Graph hat genau dafür die Funktion translateExchangeIds. Planen Sie die Umwandlung als eigenen Migrationsschritt.
• Nachschlagen. ResolveNames entspricht der People API, GetUserAvailability entspricht getSchedule, Abwesenheitseinstellungen entsprechen den Postfacheinstellungen. Nahe Entsprechungen, keine identischen.
• Drosselung. Graph begrenzt jedes Paar aus App und Postfach auf 10.000 Anfragen pro 10 Minuten, vier gleichzeitige Anfragen und 150 MB Uploads pro 5 Minuten. Ein Massenjob, der Dutzende parallele EWS-Threads gegen ein Postfach laufen ließ, muss um diese Zahlen herum neu entworfen werden.

Die Lücken und was nie kommen wird

Microsoft veröffentlicht eine Roadmap der EWS-Fähigkeiten, die in Graph noch fehlen. Dazu gehören vollständiger Import und Export für Archiv-, Öffentliche-Ordner- und Gruppenpostfächer, der Zugriff auf In-Place-Archive, Ordnerberechtigungen über die Exchange Admin API und das Erstellen von Nachrichten, die keine Entwürfe sind, aus MIME. Die meisten Ziele liegen im vierten Quartal 2026. Einige waren für das dritte Quartal angesetzt, das inzwischen vorbei ist. Prüfen Sie also, was tatsächlich ausgeliefert wurde, bevor Sie darauf aufbauen. Microsofts eigene Warnung: Wenn eine Fähigkeit nicht auf der Roadmap steht, sollten Sie „nicht damit planen“, dass es vor der Abschaltung von EWS eine Graph-Entsprechung gibt.

Drei Fähigkeiten kommen bestätigt nie nach Graph:

• Allgemeiner Zugriff auf öffentliche Ordner (Erstellen, Lesen, Aktualisieren und Löschen von Ordnern und Elementen).
• Allgemeiner Zugriff auf Postfächer von Microsoft-365-Gruppen. Graph deckt stattdessen Gruppenunterhaltungen, Threads und Beiträge ab.
• Zugriff auf Discovery-Postfächer. Microsoft verweist stattdessen auf Purview eDiscovery.

Wenn ein Werkzeug von einer dieser Fähigkeiten abhängt, reicht es nicht, den Code zu portieren: Erst müssen die Daten oder der Arbeitsablauf woandershin umziehen, und das dauert länger als eine Neuentwicklung.

Ein Sechsmonatsplan

Von heute bis zum 1. April 2027 sind es knapp sechs Monate. Eine realistische Reihenfolge:

Oktober 2026: Lage klären. Prüfen Sie EWSEnabled und die Zulassungsliste. Exportieren Sie 90 Tage des Nutzungsberichts. Prüfen Sie die Liste, die Microsoft gefüllt hat, entfernen Sie, was nicht darauf gehört, und ergänzen Sie die seltenen Jobs, die Sie kennen. Wenn Ihr Mandant noch auf Null steht, erwägen Sie, die Liste und True selbst zu setzen, statt auf Microsofts Umstellung auf False zu warten und dann herauszufinden, was kaputtgeht.

November 2026: Triage. Weisen Sie jeder Anwendungs-ID einen Verantwortlichen und eine Antwort zu (stilllegen, aktualisieren, neu schreiben, neu entwerfen). Durchsuchen Sie den Code. Markieren Sie alles, was öffentliche Ordner, Gruppenpostfächer oder Discovery-Postfächer berührt, und beginnen Sie jetzt mit dem Neuentwurf. Legen Sie die App-Registrierungen für Graph mit eingeschränkten Berechtigungen an.

Dezember 2026 bis Januar 2027: Umsetzung. Beginnen Sie mit der Integration, die das Geschäft zuerst vermissen würde. Bauen Sie die Infrastruktur für Synchronisierung und Benachrichtigungen einmal und verwenden Sie sie wieder. Wandeln Sie die gespeicherten IDs um.

Februar 2027: beides parallel betreiben. Solange EWS noch funktioniert, lassen Sie alte und neue Versionen gegen dieselben Postfächer laufen und vergleichen die Ergebnisse. Sobald eine Version abgenommen ist, nehmen Sie ihre ID von der Zulassungsliste. Das ist zugleich der Test: Warten Sie die 24 Stunden ab und bestätigen Sie, dass sonst nichts ausgefallen ist.

März 2027: EWS selbst abschalten. Setzen Sie EWSEnabled deutlich vor dem 1. April auf False. Was Sie übersehen haben, scheitert dann, solange Sie EWS noch wieder einschalten können. Nach dem 1. April ist diese Möglichkeit weg. Geben Sie auch Quartals- und Jahresjobs vorher einen bewussten Testlauf: Ein Job, der zum Abschluss des ersten Quartals läuft, läuft sonst zum ersten Mal, nachdem EWS verschwunden ist.

Wo Sie Hilfe bekommen

Der schwierige Fall ist die Integration, deren ursprünglicher Entwickler nicht mehr da ist. Dafür ist unsere Wartung von Bestandssystemen gebaut: Wir lesen den bestehenden Code, schreiben die EWS-Teile gegen Microsoft Graph neu (Berechtigungen, Synchronisierung, Benachrichtigungen, Migration der IDs) und lassen Alt und Neu parallel laufen, bis die Zahlen übereinstimmen. Wenn Sie stattdessen Ingenieure brauchen, die in Ihrem eigenen Team arbeiten, sehen Sie sich unsere Leistung zur Personalverstärkung an.

Wenn Ihr Nutzungsbericht voller Anwendungs-IDs ist, die niemand kennt, schreiben Sie an office@c9group.dev.