Exchange Online EWS 2026: Graph-Migration

01.11.2026 · IT-Wissen

Exchange Online EWS 2026 – aktueller Leitfaden für Unternehmen.

Seit Oktober 2026 wird eine wichtige Veränderung in Exchange Online schrittweise wirksam: Die bisherige Exchange-Web-Services-Schnittstelle (EWS) wird zurückgebaut. Für betroffene Microsoft-365-Tenants reicht EWSEnabled=True nicht mehr aus, um jede EWS-Anwendung zuzulassen. Stattdessen müssen Administratoren die ausdrücklich erlaubten Application IDs kontrollieren. Microsoft plant, EWS in Exchange Online bis April 2027 vollständig abzuschalten. Das betrifft nicht nur selbst programmierte Kalenderintegrationen, sondern möglicherweise auch Archivierung, CRM, Ticketing und ältere Drittanbieterprodukte. Dieser ausführliche Leitfaden zu Exchange Online EWS 2026 zeigt, wie Unternehmen die tatsächlichen Abhängigkeiten prüfen, den Übergang sicher organisieren und Datenzugriffe auf Microsoft Graph migrieren, ohne geschäftliche Abläufe unnötig zu unterbrechen.

Autor: Salman Dolatpanah Gortlar · GORTNET IT-Dienstleistungen · 1. November 2026

Kurzüberblick: EWS-Inventar ermitteln, die Application-ID-Allowlist prüfen, 403-Fehler sicher diagnostizieren und rechtzeitig auf Microsoft Graph migrieren.

Warum die EWS-Änderung für Unternehmen jetzt dringend ist

EWS ist eine ältere API für Exchange-Daten wie E-Mails, Kalender und Kontakte. Über viele Jahre haben Hersteller und interne Entwickler Anwendungen darüber mit Microsoft 365 verbunden. Die Oberfläche war praktisch, aber häufig mit historisch gewachsenen Berechtigungen, komplexen Zugriffsmustern und wenig transparenten Servicekonten verknüpft. Ein funktionierender Client kann daher seit Jahren im Hintergrund arbeiten, ohne dass der IT-Betrieb seine verwendete Schnittstelle genau dokumentiert hat.

Microsoft kündigte das Ende der Weiterentwicklung bereits 2018 an und veröffentlichte später konkrete Abschaltpläne. Im Oktober 2026 beginnt die globale Einschränkung; bis April 2027 soll EWS in Exchange Online vollständig deaktiviert sein. Der Rollout erfolgt stufenweise und kann je nach Tenant unterschiedlich weit fortgeschritten sein. Genau deshalb ist die Aussage „Bei uns funktioniert es heute noch“ kein belastbarer Nachweis für langfristige Kompatibilität. Verantwortliche müssen Anwendungen, Hersteller und geplante Updates jetzt zusammenführen.

Exchange Online EWS 2026: Meilensteine richtig verstehen

Im Herbst 2026 veränderte Microsoft die Bedeutung der EWS-Steuerung. Für betroffene Tenants, die EWSEnabled auf True gesetzt haben, wird eine Liste erlaubter Anwendungs-IDs benötigt. Die Unternehmensmeldung vom 1. Oktober beschreibt eine automatische Ermittlung bestimmter bisher aktiver Anwendungen und die Übernahme ihrer App-IDs in die Allowlist bei ausgewählten Tenants. Bereits von Administratoren selbst gepflegte Listen sollen dabei nicht überschrieben werden.

Die technische Durchsetzung begann am 10. Oktober und wird je nach Cloudumgebung über einen längeren Zeitraum ausgerollt. Daraus folgt kein automatisches Freigabeversprechen für jede Anwendung: Ein selten genutztes System kann in einer historischen Nutzungsanalyse fehlen. Die im Microsoft-Lifecycle genannten Schritte – Einschränkungen im Oktober 2026 und komplette Abschaltung bis April 2027 – sind getrennte Termine. Wer nur eine Application ID ergänzt, behebt eventuell ein aktuelles Zugriffsproblem, ersetzt damit aber nicht die spätere Migration.

EWSAllowedAppIDs: Was die neue Allowlist tatsächlich bedeutet

Die Exchange-Online-Einstellung EwsAllowedAppIDs definiert die Anwendungen, denen unter den vorgesehenen Bedingungen EWS-Zugriff erlaubt werden kann. Mit Get-OrganizationConfig lässt sich die aktuelle Organisationskonfiguration prüfen. Welche App-IDs tatsächlich erforderlich sind, muss aus den EWS-Berichten, Azure- beziehungsweise Entra-App-Registrierungen und der technischen Dokumentation der Hersteller abgeleitet werden. Nicht jede ältere Integration verwendet eine sofort erkennbare oder sauber benannte App-Identität.

Die Allowlist sollte nach dem Prinzip minimaler Rechte gepflegt werden. Ein nicht mehr verwendeter Connector gehört nicht aus Bequemlichkeit dauerhaft in die Freigaben. Microsoft dokumentiert zudem, dass ältere User-Agent-basierte EWS-Allow- oder Blocklisten parallel ausgewertet werden können. Eine Anwendung muss unter Umständen beide Prüfungen bestehen. Ändern Sie deshalb nicht nur einen Wert, wenn bereits EWSApplicationAccessPolicy, EwsAllowList oder EwsBlockList eingerichtet sind.

Bestandsaufnahme: Welche Anwendungen nutzen noch EWS?

Beginnen Sie mit den offiziellen EWS Usage Reports und dem vom Exchange-Team beschriebenen Reporting-Werkzeug. Ermitteln Sie App-ID, Anzahl der Requests, betroffene Postfächer, Zeitraum der letzten Nutzung und verantwortlichen Fachbereich. Ergänzen Sie technische Quellen wie Konfigurationsdateien, Herstellerdokumentation, alte Integrationstickets und registrierte Enterprise Applications. Manche Geschäftsprozesse laufen nur zum Monatsabschluss, andere nur bei einer Personaländerung oder einem Archivierungsereignis.

Erstellen Sie ein Register mit folgenden Mindestdaten: Anwendung, Hersteller, Besitzer, EWS-Endpunkt, Authentifizierungsart, benötigte Berechtigungen, kritischer Geschäftsprozess und zugesagter Migrationsstand. Prüfen Sie Cloud-Archivierungssoftware, elektronische Signaturprozesse, Kalendersynchronisation, CRM, Ticketing und Reporting besonders sorgfältig. Eine App, die im letzten Monat keine EWS-Abfrage erzeugt hat, ist nicht automatisch entbehrlich. Erst der fachliche Funktionstest zeigt, welche Abhängigkeiten bestehen.

Sichere PowerShell-Prüfung ohne sofortige Änderung

Eine Bestandsaufnahme sollte lesend beginnen. Der Exchange-Online-PowerShell-Befehl Get-OrganizationConfig | Format-List EwsEnabled,EwsAllowedAppIDs,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockList zeigt zentrale Einstellungen. Einzelne Postfächer können zusätzliche EWS-Steuerungen besitzen. Dokumentieren Sie die resultierenden Werte, bevor ein neues Regelwerk aufgebaut wird. Verwenden Sie dafür ein angemessen geschütztes Administratorkonto und exportieren Sie keine Zugangsdaten in Berichte.

Änderungen über Set-OrganizationConfig gehören in ein freigegebenes Wartungsfenster. Microsofts Dokumentation zur EWS-Zugriffskontrolle enthält konkrete Syntaxbeispiele und beschreibt die gegenseitige Wirkung der Listen. Kopieren Sie keine beliebige Beispiel-App-ID in eine produktive Freigabe: Eine App-ID ist nur dann geeignet, wenn ihre Identität und ihr Einsatzzweck zuvor nachvollziehbar bestätigt wurden. Nach jeder Änderung muss die betroffene Fachanwendung tatsächlich getestet werden.

HTTP 403 und fehlgeschlagene Kalender- oder Mailzugriffe einordnen

Ein HTTP-403-Fehler kann auftreten, wenn EWS aufgrund einer Richtlinie blockiert wird. Microsoft dokumentiert für diesen Fall den Header X-EWS-Policy-Reason, der Hinweise auf die Ursache geben kann. Eine blockierte Application ID oder eine weiterhin geltende User-Agent-Regel können ähnlich wirken. Auch eine generelle Deaktivierung auf Tenant- oder Postfachebene ist zu unterscheiden. Die Fehlersuche sollte deshalb die exakte Antwort, die App-ID, die Identität und den betroffenen Tenant berücksichtigen.

Vermeiden Sie eine breite globale Freigabe, nur um den Fehler schnell verschwinden zu lassen. Prüfen Sie zunächst, ob die Anwendung überhaupt noch unterstützt und für den Geschäftsprozess notwendig ist. Bei geschäftskritischen Ausfällen können dokumentierte temporäre Ausnahmen helfen, soweit die Microsoft-Vorgaben dies zulassen. Sie müssen jedoch einen Endtermin und einen verantwortlichen Produktbesitzer haben. Die Fehlermeldung ist gleichzeitig ein Anlass, den tatsächlichen Migrationsplan zum unterstützten Ersatz zu beschleunigen.

Microsoft Graph ist der strategische Zielweg

Für viele EWS-Szenarien ist Microsoft Graph der vorgesehene Ersatz. Die API verwendet andere Endpunkte, Berechtigungsmodelle und Datenstrukturen. Es reicht daher nicht, nur eine EWS-URL durch eine Graph-URL zu ersetzen. Anwendungen müssen ihre Abfragen, Fehlerbehandlung, Paginierung, Zeitfenster, Throttling und die Behandlung von Datenänderungen überprüfen. Je nach Anwendungsfall können neue Berechtigungs- oder Architekturentscheidungen erforderlich werden.

Nicht für jede EWS-Funktion existiert sofort eine vollständig identische Graph-Alternative. Microsoft veröffentlicht eine Roadmap für verbleibende funktionale Lücken und weist darauf hin, dass nicht aufgeführte Funktionen nicht automatisch rechtzeitig verfügbar sein werden. Prüfen Sie daher den konkreten Fachprozess vor einer Migration. Für manche Anwendungen ist eine Modernisierung beim Hersteller sinnvoller als die Entwicklung einer eigenen provisorischen Schnittstelle. In anderen Fällen müssen Import-/Export- oder Verwaltungsfunktionen neu entworfen werden.

App-Berechtigungen in Microsoft Graph gezielt begrenzen

Bei der Umstellung wird oft auch das Identitätsmodell geändert. Graph kann delegierte Berechtigungen im Benutzerkontext und App-Berechtigungen für Hintergrunddienste verwenden. Eine automatische Integration benötigt möglicherweise Rechte für Postfächer, darf aber nicht automatisch auf alle Daten eines gesamten Tenants zugreifen. Die zentrale Frage lautet: Welche Postfächer, Ordner und konkreten Operationen werden wirklich benötigt?

Nutzen Sie die aktuell von Microsoft dokumentierten Scoping- und Berechtigungsmechanismen für Exchange Online. Prüfen Sie Zertifikatsauthentifizierung oder eine geeignete verwaltete Identität, statt neue langjährig gültige Client-Secrets in Skripten zu hinterlegen. Halten Sie Consent, App-Registrierung und Berechtigungserteilung getrennt nachvollziehbar fest. Die Migration ist eine Gelegenheit, überprivilegierte Altintegrationen konsequent zu verkleinern.

Kalender, Kontakte und Hintergrundjobs praxisnah testen

Ein erfolgreich abgesetzter Graph-Testrequest beweist noch nicht, dass ein ganzer CRM- oder Terminprozess funktioniert. Prüfen Sie wiederkehrende Termine, Zeitzonen, Teilnehmeränderungen, freigegebene Kalender und eventuelle Synchronisationskonflikte. Bei Mailverarbeitung müssen Empfang, Verarbeitung, Fehlerbehandlung, Anhänge und Berechtigungen berücksichtigt werden. Bei Export und Archivierung sind zudem Vollständigkeit, Aufbewahrungsanforderungen und mögliche Compliance-Sperren relevant.

Führen Sie eine Pilotmigration auf Testkonten mit kontrollierten Daten durch. Vergleichen Sie Ergebnisse zwischen alter EWS- und neuer Graph-Integration und dokumentieren Sie Unterschiede. Beobachten Sie danach mehrere Geschäftszyklen, nicht nur einen Arbeitstag. Eine Synchronisation, die täglich korrekt läuft, aber bei einem Monatswechsel doppelte Ereignisse erzeugt, gilt noch nicht als abgenommen. Planen Sie eine begrenzte Koexistenzphase, sofern der Anbieter das technisch unterstützt.

Herstellerkommunikation und Vertragsrisiken

Bei Drittanbieterprodukten trägt nicht allein die interne IT Verantwortung. Der Hersteller muss eine kompatible Version liefern oder einen unterstützten Ersatzweg beschreiben. Verlangen Sie ein konkretes Datum, die benötigten Microsoft-Graph-Berechtigungen, bekannte Funktionslücken und einen Testplan. Aussagen wie „Unser Produkt unterstützt Microsoft 365“ reichen nicht aus, wenn unklar bleibt, ob die aktuelle Version EWS nutzt.

Erstellen Sie für wichtige Anbieter Eskalationskontakte und eine Risikobewertung. Was passiert, wenn ein Archivierungsdienst ab April 2027 keine neuen Elemente mehr abruft? Welche gesetzlichen oder vertraglichen Verpflichtungen sind betroffen? Dokumentieren Sie kurzfristige Ausnahmen und prüfen Sie Alternativprodukte, wenn der Hersteller keinen belastbaren Plan liefert. Achten Sie auch darauf, dass eine Integrationsumstellung keine unerwartete Änderung bei Datenschutz, Speicherung oder Unterauftragsverarbeitung verursacht.

Monitoring während der Umstellung etablieren

Ein gutes Monitoring prüft die Geschäftsleistung der Integration: Werden Termine übertragen, neue Tickets erstellt oder Nachrichten archiviert? Ein grüner HTTP-Status auf der allgemeinen Microsoft-365-Anmeldung genügt dafür nicht. Protokollieren Sie Anfrageraten, API-Fehler, Berechtigungsfehler und ausstehende Verarbeitungsschritte. Verknüpfen Sie Warnungen mit dem technischen Besitzer und dem betroffenen Fachverfahren.

Im Security-Monitoring sollten ungewöhnliche Zugriffe einer neu registrierten App genauso sichtbar sein wie plötzlich ausbleibende EWS-Aufrufe. Nach einer erfolgreichen Migration sind alte Application IDs, Secrets und Berechtigungen zu entfernen, soweit sie nicht mehr benötigt werden. Prüfen Sie die Ausschaltung der Altintegration und behalten Sie historische Protokolle gemäß internen Anforderungen. Ein geplanter EWS-Abschied ist auch ein sauberer Rückbau alter Angriffsflächen.

90-Tage-Migrationsplan bis 2027

Phase eins: EWS Usage Reports, Organisationsrichtlinien und Fachanwendungen erfassen. Kritische Integrationen ohne benannten Eigentümer sofort zuordnen. Phase zwei: Herstellerstände prüfen, Graph-Migrationspfade entwerfen und neue Berechtigungen mit minimalem Scope vorbereiten. Phase drei: Repräsentative Anwendungen migrieren, Messwerte vergleichen und Fehlerfälle simulieren. Phase vier: Restanwendungen priorisieren, nicht mehr benötigte EWS-Zugriffe sperren und die Ergebnisse dokumentieren.

Bewerten Sie den Fortschritt anhand der Zahl verbleibender EWS-Anwendungen, geschäftlicher Kritikalität, validierter Graph-Alternativen und ungeklärter Herstellerzusagen. Ein Tenant kann technisch noch EWS-Zugriffe erlauben und zugleich bereits einen Großteil seiner künftigen Betriebsfähigkeit gefährden. Deshalb gehört die Migration als festes Projekt mit Aufgaben, Eigentümern und Deadline in die IT-Roadmap.

Häufige Fragen zu Exchange Online EWS 2026

Ist EWS seit dem 10. Oktober 2026 komplett abgeschaltet?

Nein. Seit Oktober greifen stufenweise neue Zugriffsbeschränkungen. Die vollständige Abschaltung von EWS in Exchange Online ist für April 2027 vorgesehen.

Reicht EWSEnabled=True künftig aus?

In betroffenen Tenants nicht. Es müssen die jeweils erforderlichen erlaubten App-IDs und gegebenenfalls zusätzliche User-Agent-Regeln berücksichtigt werden.

Kann man EWSAllowedAppIDs als Dauerlösung verwenden?

Nein. Die Liste kann einen begrenzten Übergang erleichtern, ersetzt aber nicht die notwendige Ablösung von EWS.

Ist die Migration zu Microsoft Graph nur eine URL-Änderung?

Nein. Datenmodelle, Berechtigungen, Funktionsumfang, Fehlerbehandlung und Synchronisationslogik müssen für den konkreten Geschäftsprozess geprüft werden.

Fazit: EWS-Abhängigkeiten jetzt kontrolliert abbauen

Exchange Online EWS 2026 sollte als verbindliches Migrationsprojekt behandelt werden. Eine kurzfristig korrekte Allowlist ist hilfreich, aber der eigentliche Sicherheits- und Betriebsgewinn entsteht durch inventarisierte Schnittstellen, minimal berechtigte Graph-Integrationen und getestete Geschäftsprozesse vor dem Ende der EWS-Unterstützung. Wer heute Hersteller, Verantwortliche und Testfälle benennt, reduziert das Ausfallrisiko im Jahr 2027.

Über den Autor

Salman Dolatpanah Gortlar veröffentlicht bei GORTNET technische Leitfäden zu Microsoft 365, Identitätssicherheit und verlässlicher Unternehmens-IT. Die Beispiele dienen der fachlichen Planung und sind keine Untersuchung eines konkreten Kunden-Tenants.

Weiterführende GORTNET-Artikel

Für eine Bestandsaufnahme Ihrer Exchange-Integrationen und eine sichere Modernisierung GORTNET kontaktieren.

Offizielle Quellen

Redaktionsstand 1. November 2026. Die tatsächliche Aktivierung der Microsoft-Richtlinien erfolgt tenantabhängig; vor produktiven Änderungen die aktuellen Microsoft-Informationen prüfen.

Exchange Online EWS 2026: EWSAllowedAppIDs und Graph-Migration