EWS-Abschaltung in Exchange Online: Was Unternehmen jetzt vorbereiten sollten

Microsoft beendet die Exchange Web Services in Exchange Online. Am 1. Oktober 2026 beginnt die technische Durchsetzung, am 1. April 2027 wird EWS endgültig abgeschaltet.

Der entscheidende Termin liegt jedoch früher: Wer bis Ende August 2026 eine geprüfte Zulassungsliste konfiguriert und EWSEnabled auf True setzt, wird von der automatischen Abschaltung am 1. Oktober ausgenommen. Wer die Frist verstreichen lässt, gibt die Kontrolle über den Zeitpunkt aus der Hand.

Für Unternehmen bedeutet das: bestehende Anwendungen, Integrationen und Dienste mit EWS-Zugriff müssen jetzt identifiziert und bewertet werden. Andernfalls können geschäftskritische Lösungen ab Oktober 2026 unerwartet den Zugriff auf Exchange Online verlieren.

Mit EWSAllowedAppIDs steht seit Sommer 2026 die passende Konfigurationsmöglichkeit bereit. Sie ermöglicht es Administratoren, gezielt festzulegen, welche Anwendungen EWS vorübergehend weiterhin verwenden dürfen.

Ein wichtiger Hinweis zum Geltungsbereich: Die Abschaltung betrifft ausschließlich Exchange Online. Exchange Server in lokalen Installationen ist nicht betroffen und behält EWS unverändert.

Warum die EWS-Abschaltung relevant ist

EWS wird seit fast zwanzig Jahren für den Zugriff auf Exchange-Daten eingesetzt. Dazu gehören unter anderem Postfächer, Kalender, Kontakte und weitere Exchange-Funktionen.

In vielen Umgebungen wird EWS noch durch ältere Anwendungen, Archivlösungen, Backup-Produkte, Workflow-Systeme oder individuelle Integrationen verwendet. Häufig sind diese Abhängigkeiten nicht vollständig dokumentiert.

Genau darin liegt das Risiko. Eine Anwendung kann technisch unauffällig funktionieren und dennoch von EWS abhängig sein. Wird der Zugriff im Rahmen der Abschaltung blockiert, fällt die Abhängigkeit möglicherweise erst durch eine Störung auf.

Unternehmen sollten daher nicht bis 2027 warten. Die ersten konkreten Auswirkungen können bereits ab Oktober 2026 auftreten — und die Vorbereitungsfrist endet noch früher.

Die wichtigsten Termine im Überblick

Termin	Was passiert
Juni 2026	EWSAllowedAppIDs wird ausgerollt und kann konfiguriert werden
Ende August 2026	Letzte Frist: Allow List konfigurieren und EWSEnabled=True setzen, um von der Umstellung am 1. Oktober ausgenommen zu werden
September 2026	Microsoft befüllt Allow Lists automatisch für Mandanten, die selbst keine erstellt haben — auf Basis der erkannten Nutzung
1. Oktober 2026	Beginn der technischen Durchsetzung. Mandanten mit EWSEnabled=Null werden auf False umgestellt, EWS wird blockiert
1. April 2027	Endgültige Abschaltung. Die Steuerung über EWSEnabled wird Administratoren entzogen. Keine Ausnahmen

Die automatische Befüllung durch Microsoft im September ist ausdrücklich kein Ersatz für eigene Arbeit. Microsoft übernimmt keine Verantwortung für die Richtigkeit der Liste, und es können Anwendungen enthalten sein, die man gar nicht zulassen möchte. Die Verantwortung für den Inhalt bleibt beim Administrator.

Sollte die August-Frist verpasst werden, ist die Lage nicht aussichtslos: EWS lässt sich nach dem 1. Oktober durch Setzen von EWSEnabled=True wieder aktivieren. Dabei kommt es allerdings zu einer Serviceunterbrechung, und diese Option besteht nur bis zum 1. April 2027.

Was ist EWSAllowedAppIDs?

EWSAllowedAppIDs ist eine mandantenweite Zulassungsliste für Anwendungs-IDs aus Microsoft Entra ID.

Administratoren können damit festlegen, welche Anwendungen weiterhin über EWS auf Exchange Online zugreifen dürfen. Anwendungen, die nicht in dieser Liste enthalten sind, werden ab Beginn der Durchsetzung blockiert.

Die Funktion unterstützt Unternehmen in drei Bereichen. Sie hilft dabei, vorhandene EWS-Abhängigkeiten sichtbar zu machen, sie begrenzt den Zugriff auf ausdrücklich genehmigte Anwendungen, und sie reduziert das Risiko ungeplanter Ausfälle während der Abschaltungsphase.

Abgrenzung zur bestehenden EwsAllowList

Wichtig ist die Unterscheidung von der EwsAllowList, die Exchange schon seit vielen Jahren kennt. Diese arbeitet auf Basis des User-Agent-Strings, also einer Textkennung im HTTP-Header, die sich leicht fälschen lässt. EWSAllowedAppIDs stützt sich dagegen auf die in Entra ID registrierte Anwendungs-ID und ist damit deutlich belastbarer.

Beide Mechanismen können parallel wirksam sein. Eine Anwendung muss beide Prüfungen bestehen, um Zugriff zu erhalten, wobei die neue AppID-Liste Vorrang hat. Wer bereits eine EwsApplicationAccessPolicy konfiguriert hat, sollte diese Konstellation vor der Umstellung gezielt prüfen.

Geltungsbereich des Parameters

EWSAllowedAppIDs wirkt ausschließlich auf direkte EWS-Verbindungen über SOAP. Anfragen über Microsoft Graph oder den REST-Endpunkt sind davon nicht betroffen.

Was ändert sich ab Oktober 2026?

Verhalten vor Oktober 2026

Das aktuelle Verhalten ist bewusst durchlässig gestaltet, damit Administratoren die Konfiguration testen können, ohne den Produktivbetrieb zu gefährden.

Ist EWSEnabled nicht konfiguriert (Null), wird der gesamte EWS-Datenverkehr zugelassen. Eine konfigurierte Zulassungsliste hat in diesem Fall keinerlei Wirkung.
Ist EWSEnabled auf True gesetzt und keine Zulassungsliste vorhanden, wird ebenfalls der gesamte EWS-Datenverkehr zugelassen.
Ist EWSEnabled auf True gesetzt und eine Zulassungsliste konfiguriert, sind grundsätzlich nur die eingetragenen Anwendungen vorgesehen. Die Durchsetzung ist in dieser Phase jedoch noch nicht vollständig scharf geschaltet.
Ist EWSEnabled auf False gesetzt, wird EWS vollständig blockiert.

Verhalten ab Oktober 2026

Ist EWSEnabled auf True gesetzt, aber keine Zulassungsliste konfiguriert, wird der gesamte EWS-Datenverkehr blockiert.
Ist EWSEnabled auf True gesetzt und eine Zulassungsliste vorhanden, dürfen ausschließlich die enthaltenen Anwendungen EWS verwenden.
Ist EWSEnabled auf False gesetzt, bleibt EWS vollständig blockiert.
Bei Mandanten, deren EWSEnabled am 1. Oktober 2026 noch auf Null steht, wird der Wert im Rahmen des stufenweisen Rollouts auf False geändert. Damit wird EWS für alle Anwendungen des Mandanten blockiert.

Die wichtigste Änderung lautet daher:

EWSEnabled=True reicht ab Oktober 2026 nicht mehr aus, um EWS-Zugriff allgemein zu erlauben. Aus einer Konfiguration, die heute „alles erlauben“ bedeutet, wird dann „nichts erlauben“.

Unternehmen, die EWS nach diesem Zeitpunkt weiterhin benötigen, müssen eine vollständige und geprüfte EWSAllowedAppIDs-Liste konfigurieren.

Scream Tests: Störungen vor dem eigentlichen Stichtag

Microsoft hat angekündigt, vor der endgültigen Abschaltung sogenannte Scream Tests durchführen zu können. Dabei wird EWS für kurze Zeiträume deaktiviert und anschließend wieder aktiviert, um versteckte Abhängigkeiten sichtbar zu machen.

Für Unternehmen ist das ein weiteres Argument für frühzeitiges Handeln: Wer EWSEnabled bereits jetzt auf True setzt, ist von diesen Tests nicht betroffen.

Welche Unternehmen sind betroffen?

Betroffen sind grundsätzlich alle Organisationen, die Exchange Online einsetzen und Anwendungen oder Dienste mit EWS-Zugriff betreiben.

Dazu zählen häufig:

Archivierungslösungen
Backup-Anwendungen
Kalender- und Terminlösungen
Workflow-Systeme
CRM- und ERP-Integrationen
Individuell entwickelte Anwendungen und Skripte
Ältere Microsoft-365-Integrationen
Multifunktionsgeräte und Raumbuchungssysteme

Auch Microsoft-Erstanbieter-Anwendungen können weiterhin EWS verwenden. Microsoft nennt hier ausdrücklich Beispiele wie Office-Clients oder Power Query für Excel. Werden sie im EWS-Nutzungsbericht angezeigt und weiterhin benötigt, müssen auch deren Anwendungs-IDs in die Liste aufgenommen werden.

Verantwortlich für die Vorbereitung sind nicht nur Exchange-Administratoren. Ebenso eingebunden werden sollten Application Owner, Software-Hersteller, interne Entwickler, Betriebsteams und externe Dienstleister.

Schritt 1: EWS-Nutzung erfassen

Der erste Schritt besteht darin, alle aktiven EWS-Abhängigkeiten im Mandanten zu identifizieren. Dafür stehen mehrere Quellen zur Verfügung:

Der EWS-Nutzungsbericht im Microsoft 365 Admin Center
Die monatlichen Message-Center-Beiträge, in denen Microsoft mandantenspezifische Nutzungszusammenfassungen bereitstellt
Die Anmeldeprotokolle in Microsoft Entra ID, gefiltert auf EWS-Aktivität
Die von Microsoft veröffentlichten Skripte aus dem Beitrag „Notes From the Field: Finding and Remediating EWS App Usage Before Retirement“

Die Nutzungsberichte liefern Anwendungs-IDs, aber nicht immer verständliche Namen. Zur Auflösung eignet sich das Microsoft Graph PowerShell-Modul:

powershell

Get-MgServicePrincipal -Filter "appId eq '11111111-2222-3333-4444-555555555555'" |
    Select-Object DisplayName, AppId

Einzelne IDs gehören zu internen Microsoft-Komponenten und lassen sich darüber nicht immer sinnvoll auflösen. Microsoft pflegt eine Referenzliste der Erstanbieter-Anwendungs-IDs, die in diesen Fällen weiterhilft.

Für jede gefundene Anwendung sollten mindestens folgende Fragen beantwortet werden:

Wer ist für die Anwendung verantwortlich?
Welche Geschäftsprozesse hängen von ihr ab?
Welche Funktionen werden über EWS genutzt?
Ist die Anwendung weiterhin erforderlich?
Gibt es bereits eine Version mit Microsoft-Graph-Unterstützung?
Ist eine Migration geplant?

Ohne diese Zuordnung besteht die Gefahr, Anwendungen vorschnell zuzulassen oder kritische Abhängigkeiten zu übersehen.

Schritt 2: Anwendungen bewerten

Nicht jede EWS-Anwendung sollte automatisch in die Zulassungsliste aufgenommen werden.

Zunächst sollte geprüft werden, ob die Anwendung noch benötigt wird. Anschließend ist zu klären, ob eine aktuelle Version oder eine alternative Lösung verfügbar ist, die Microsoft Graph verwendet.

Microsoft Graph ist für die meisten Exchange- und Microsoft-365-Szenarien die strategisch vorgesehene Schnittstelle. Für einzelne administrative Aufgaben kommen alternativ die Exchange Online Admin API oder Exchange Online PowerShell in Frage. EWSAllowedAppIDs sollte in keinem Fall als dauerhafte Zukunftslösung verstanden werden.

Die Zulassungsliste schafft vor allem Zeit für eine kontrollierte Migration. Sie verhindert kurzfristige Ausfälle, ersetzt aber nicht die Modernisierung bestehender Integrationen.

Ein besonderer Hinweis zu Herstellern: Ein Software-Hersteller, der lediglich empfiehlt, seine Anwendungs-ID auf die Liste zu setzen, hat damit noch keine Migrationsperspektive geliefert. Ein tragfähiger Plan umfasst einen konkreten Migrationspfad, betroffene Produktversionen, benötigte Graph-Berechtigungen und dokumentierte Funktionslücken. Fehlt das bei einer geschäftskritischen Anwendung, sollte jetzt eskaliert werden — nicht erst während einer von Microsoft gesteuerten Abschaltungswelle.

Schritt 3: EWSAllowedAppIDs konfigurieren

Alle Anwendungen, die vorübergehend weiterhin EWS verwenden müssen, werden mit ihrer Anwendungs-ID in EWSAllowedAppIDs eingetragen.

Ein zentraler Punkt vorab: Die Zulassungsliste ist wirkungslos, solange EWSEnabled nicht auf True gesetzt ist. Bei EWSEnabled=Null hat der Parameter keinerlei Effekt. Beide Einstellungen gehören daher zusammen.

Die einfachste Variante, wenn die vollständige Liste bereits bekannt ist:

powershell

Set-OrganizationConfig -EwsEnabled $true `
    -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

Dabei ist ein wichtiger Punkt zu beachten:

Eine Änderung an EWSAllowedAppIDs ersetzt die vorhandene Liste vollständig. Es gibt keine Operation zum einzelnen Hinzufügen oder Entfernen. Wird eine bestehende ID versehentlich weggelassen, verliert die zugehörige Anwendung den Zugriff auf EWS.

Für Ergänzungen ist deshalb immer das Muster Auslesen, Ändern, Zurückschreiben erforderlich:

powershell

# Neue Anwendungs-ID, die ergänzt werden soll
$neueAppId = "22222222-3333-4444-5555-666666666666"

# Bestehende Liste auslesen
$aktuell = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
    Select-Object -ExpandProperty EwsAllowedAppIDs)

# In Einzelwerte zerlegen (leere Liste, falls noch nichts gesetzt ist)
if ([string]::IsNullOrWhiteSpace($aktuell)) {
    $bestehend = @()
} else {
    $bestehend = $aktuell -split "," | ForEach-Object { $_.Trim() }
}

# Nur ergänzen, wenn die ID noch nicht enthalten ist
if ($bestehend -notcontains $neueAppId) {
    $bestehend += $neueAppId
    Write-Host "$neueAppId wurde ergaenzt"
} else {
    Write-Host "$neueAppId ist bereits enthalten"
}

# Vollständige Liste zurückschreiben
Set-OrganizationConfig -EwsAllowedAppIDs ($bestehend -join ",")

Vor jeder Änderung sollte die aktuelle Konfiguration ausgelesen, exportiert und dokumentiert werden. Die Zulassungsliste ist eher wie ein Regelwerk einer Firewall oder eine Conditional-Access-Richtlinie zu behandeln als wie eine beiläufige Exchange-Einstellung — inklusive Change-Prozess und Freigabe.

Soll die Einschränkung nach Anwendungs-ID vollständig aufgehoben werden, wird der Parameter auf $null gesetzt. Zu beachten ist, dass genau diese Konfiguration ab Oktober 2026 in Kombination mit EWSEnabled=True zu einer vollständigen Blockade führt.

Als Alternative zur PowerShell-Konfiguration lässt sich die Einstellung auch über den Baseline Security Mode verwalten.

Schritt 4: Konfiguration kontrollieren

Die konfigurierte Zulassungsliste lässt sich über Exchange Online PowerShell abrufen:

powershell

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Der Parameter RetrieveEwsOperationAccessPolicy ist zwingend erforderlich. Die Liste wird aus Performancegründen nur geladen, wenn sie ausdrücklich angefordert wird. Ohne diesen Parameter erscheint das Feld leer, obwohl eine Konfiguration vorhanden ist — eine häufige Fehlerquelle bei der Prüfung.

Ergänzend sollte auch der zugehörige Schalter kontrolliert werden:

powershell

Get-OrganizationConfig | Format-List EwsEnabled, EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList

Ein leerer Wert bei EwsEnabled bedeutet Null und damit die Standardkonfiguration, die im Oktober automatisch auf False umgestellt wird.

Schritt 5: Zugriff testen

Nach der Konfiguration sollte jede zugelassene Anwendung technisch getestet werden.

Dabei ist eine Besonderheit der aktuellen Phase entscheidend: Ein Negativtest ist vor Oktober 2026 nicht aussagekräftig. Da das Verhalten bis dahin bewusst durchlässig bleibt, werden nicht gelistete Anwendungen noch nicht blockiert — auch dann nicht, wenn EWSEnabled auf True steht und eine Liste konfiguriert ist.

Wer daraus schließt, die Konfiguration greife nicht, konfiguriert unter Umständen unnötig nach. Wer umgekehrt daraus schließt, es sei alles in Ordnung, erlebt im Oktober eine Überraschung.

Sinnvoll ist deshalb ein zweistufiges Vorgehen:

Vor Oktober 2026: Prüfen, ob alle freigegebenen Anwendungen weiterhin funktionieren, und die Vollständigkeit der Liste gegen die Nutzungsberichte abgleichen. Der eigentliche Zweck dieser Phase ist Bestandsaufnahme, nicht Absicherung.

Ab Beginn der Durchsetzung: Prüfen, ob nicht freigegebene Anwendungen tatsächlich blockiert werden, und ob die freigegebenen Anwendungen weiterhin vollständig arbeiten.

In beiden Fällen gilt: Eine erfolgreiche Anmeldung allein bestätigt nicht, dass jede benötigte EWS-Funktion verfügbar ist. Getestet werden sollten die tatsächlichen Geschäftsprozesse — vollständige Postfachsynchronisation, Kalenderzugriffe, Berechtigungslogik, Fehlerbehandlung.

Änderungen an der Konfiguration sollten nach Möglichkeit zunächst in einem Testmandanten erprobt werden, bevor sie in der Produktion angewendet werden.

Dokumentation nicht vergessen

Die finale EWSAllowedAppIDs-Liste sollte nicht nur technisch hinterlegt, sondern auch nachvollziehbar dokumentiert werden.

Für jede Anwendung sollten mindestens folgende Informationen festgehalten werden:

Name der Anwendung
Anwendungs-ID
Application Owner
Technischer Ansprechpartner
Herstellerkontakt, sofern relevant
Verwendete EWS-Funktionen
Geschäftliche Relevanz
Geplantes Migrationsdatum
Zieltechnologie
Letzter erfolgreicher Test
Nächster Überprüfungstermin

Diese Dokumentation wird besonders wichtig, wenn mehrere Teams oder Dienstleister an der Exchange-Online-Umgebung arbeiten. Da jede Änderung die gesamte Liste überschreibt, ist ein aktueller Stand die Voraussetzung dafür, dass eine Anpassung nicht versehentlich andere Anwendungen aussperrt.

Empfehlenswert ist außerdem, die Einträge in regelmäßigem Abstand zu überprüfen. Jede Zeile auf der Liste ist eine Ausnahme mit Ablaufdatum, kein Dauerzustand.

EWSAllowedAppIDs ist keine langfristige Lösung

Die Zulassungsliste reduziert das Risiko kurzfristiger Störungen. Sie ändert jedoch nichts daran, dass EWS am 1. April 2027 vollständig außer Betrieb genommen wird. Zu diesem Zeitpunkt entfällt auch die Möglichkeit, über EWSEnabled noch einzugreifen.

Unternehmen sollten EWSAllowedAppIDs deshalb als kontrollierten Übergangsmechanismus betrachten, der maximal sechs Monate zusätzliche Zeit verschafft.

Das eigentliche Ziel bleibt die Migration auf Microsoft Graph oder eine andere unterstützte Schnittstelle. Anwendungen ohne realistische Migrationsperspektive sollten kritisch bewertet und gegebenenfalls ersetzt werden.

Empfohlenes Vorgehen für Unternehmen

Ein strukturiertes EWS-Projekt sollte vier Arbeitspakete umfassen:

Analyse: Die tatsächliche EWS-Nutzung im Mandanten erfassen und jeder Abhängigkeit einen Verantwortlichen zuordnen.
Bewertung: Anwendungen technisch und fachlich bewerten und über Migration, Ablösung oder befristete Freigabe entscheiden.
Konfiguration: EWSAllowedAppIDs konfigurieren, EWSEnabled auf True setzen und die Konfiguration testen. Dieses Paket sollte bis Ende August 2026 abgeschlossen sein.
Migration: Für jede verbleibende Abhängigkeit eine Migration oder Ablösung planen und umsetzen.

Besonders wichtig ist die Zusammenarbeit zwischen IT-Betrieb, Fachbereichen, Application Ownern, Entwicklern und Software-Herstellern. Die technische Analyse allein reicht häufig nicht aus, um die geschäftliche Bedeutung einer Integration zu verstehen.

Typische Risiken in Kundenumgebungen

In der Praxis treten bei solchen Umstellungen häufig ähnliche Herausforderungen auf:

Anwendungen sind technisch vorhanden, aber keinem verantwortlichen Team zugeordnet.
EWS wird durch eine ältere Softwareversion verwendet, obwohl eine aktuelle Version bereits Microsoft Graph unterstützt.
Eine Integration wurde vor Jahren eingerichtet und ist nicht mehr dokumentiert.
Test- und Produktionsumgebungen verwenden unterschiedliche Anwendungs-IDs.
Eine Änderung an EWSAllowedAppIDs überschreibt versehentlich vorhandene Einträge.
Die Liste ist konfiguriert, EWSEnabled steht aber weiterhin auf Null — die Konfiguration ist damit wirkungslos.
Die Konfiguration wird ohne den Parameter RetrieveEwsOperationAccessPolicy geprüft und erscheint fälschlich als leer.
Aus dem durchlässigen Verhalten vor Oktober wird geschlossen, die Konfiguration sei bereits wirksam.
Eine bestehende EwsApplicationAccessPolicy auf Basis von User Agents blockiert eine Anwendung, obwohl deren Anwendungs-ID freigegeben ist.
Eine Anwendung wird zugelassen, aber es existiert kein Plan für die spätere Migration.

Diese Risiken lassen sich durch eine frühzeitige Bestandsaufnahme und eine saubere Dokumentation deutlich reduzieren.

Fazit

Die Abschaltung von EWS in Exchange Online ist keine Ankündigung mehr, sondern ein laufender Prozess mit festen Terminen.

Der wichtigste Termin ist nicht der 1. April 2027 und auch nicht der 1. Oktober 2026, sondern das Ende August 2026. Bis dahin entscheidet sich, ob ein Unternehmen die Umstellung selbst steuert oder ob Microsoft sie im Oktober übernimmt.

Der erste Schritt ist eine vollständige Analyse der vorhandenen EWS-Nutzung. Anschließend sollten nur noch notwendige Anwendungen gezielt freigegeben, technisch getestet und mit einem konkreten Migrationsplan versehen werden.

Wer diese Arbeiten frühzeitig beginnt, reduziert das Risiko von Betriebsunterbrechungen und schafft gleichzeitig eine gute Grundlage für die weitere Modernisierung der eigenen Microsoft-365-Landschaft.