Jetzt wird es ernst. Microsoft beginnt, Exchange Web Services (EWS) in Exchange Online tenantweise abzuschalten. Nicht irgendwann, sondern jetzt, Tenant für Tenant. Wer in den letzten Monaten die Ankündigungen zum EWS-Retirement mit einem Schulterzucken abgetan hat, weil “das ja noch Zeit hat”, wird in den nächsten Wochen vermutlich ziemlich unsanft geweckt. Und zwar nicht von einer Mail aus Redmond, sondern vom Helpdesk, weil Apple Mail plötzlich dauerhaft nach dem Kennwort fragt, Outlook für Mac keine Kalender mehr synchronisiert oder das Backup der Postfächer seit drei Tagen fehlschlägt.
Hintergrund: Warum EWS gehen muss
EWS ist seit Exchange 2007 die universelle Schnittstelle für alles, was weder MAPI noch ActiveSync noch IMAP unterstützt. Entsprechend breit ist die Nutzung. Apple Mail und Kalender unter macOS, Outlook für Mac in der klassischen Variante, zahlreiche Outlook-Add-ins, veraltete Outlook-Versionen unter Windows sowie ein bunter Zoo an Drittanbieterlösungen hängen an EWS. Gerade Backup-Produkte, Archivlösungen, Signaturtools und Synchronisationsdienste haben EWS jahrelang für den bequemen Vollzugriff auf Postfachinhalte genutzt.
Genau das ist aus Sicherheitsgründen das Problem. EWS bietet plattformübergreifenden API-Zugriff auf E-Mails, Termine und Kontakte. Eine kompromittierte Anwendung mit EWS-Zugriff ist für Angreifer ein Jackpot: Daten abgreifen, Phishing-Mails im Namen echter Benutzer versenden, Identitäten fälschen. Microsoft hat EWS deshalb seit Jahren nicht mehr weiterentwickelt und verweist stattdessen auf Microsoft Graph als Nachfolger. Die Abschaltung ist also keine Überraschung, sondern der lange angekündigte letzte Schritt.
Neu ist, dass dieser Schritt nun tatsächlich bei den Tenants ankommt.
So läuft die Abschaltung ab
Der Ablauf ist klar definiert, und es lohnt sich, ihn zu kennen, weil er dir zeigt, wo du gerade stehst. Betroffen sind zunächst Tenants, in denen EwsEnabled in der Organisationskonfiguration auf $null gesetzt ist. Der Parameter wurde also nie explizit gesetzt. Das dürfte die überwiegende Mehrheit sein.
Zuerst erhältst du im Message-Center einen Eintrag mit einer 7-tägigen Vorwarnung. Der Betreff lautet sinngemäß “Action may be required: EWS will be disabled in your tenant in 7 days”. Zwei Tage vor Ablauf dieser Frist befüllt Microsoft in deinem Tenant die Liste EwsAllowedAppIDs. Grundlage dafür sind die EWS-Anwendungen, die in den letzten 60 Tagen in deinem Tenant tatsächlich genutzt wurden. Danach folgt ein zweiter Message-Center-Post mit dem Betreff “EWS has been disabled in your tenant”, und EwsEnabled wird von $null auf $false gesetzt.
Ab diesem Moment ist EWS für die gesamte Organisation tot. Und das, obwohl die Allow List bereits befüllt ist. Die Liste greift nämlich nur dann, wenn EWS auf Organisationsebene grundsätzlich erlaubt ist. Mit EwsEnabled = $false ist sie wirkungslos.
Microsoft betont übrigens ausdrücklich, dass der Microsoft-Support die Wiederherstellung nicht für dich übernimmt. Das ist Aufgabe des Tenant-Admins. Ein Supportticket bringt dich hier also nicht weiter, sondern kostet nur Zeit.
Die Symptome erkennen
Die Fehlerbilder sind leider alles andere als eindeutig. Manche Anwendungen melden korrekt, dass das EWS-Protokoll nicht verfügbar ist. Andere, allen voran Apple Mail, fragen einfach in einer Endlosschleife nach Benutzername und Kennwort. Das führt im Helpdesk erfahrungsgemäß zu Kennwortresets, MFA-Neuregistrierungen und Conditional-Access-Debugging, obwohl das eigentliche Problem auf eine einzige Eigenschaft in der Organisationskonfiguration zurückzuführen ist.
Wenn also in den nächsten Wochen plötzlich ein Backup-Job auf breiter Front scheitert, schau als Erstes ins Message Center. Such dort nach den beiden oben genannten Betreffzeilen. Findest du sie, weißt du, was los ist.
EWS wieder einschalten
Für das Wiedereinschalten gibt es zwei Wege. Einen über die Oberfläche und einen über PowerShell.
Beide führen zum gleichen Ergebnis: EwsEnabled = $true in Kombination mit der befüllten Allow List.
Weg 1: Baseline Security Mode im Microsoft 365 Admin Center
Im Microsoft 365 Admin Center findest du unter Baseline Security Mode den Eintrag “Block access to Exchange Web Services”. Und jetzt kommt der Teil, über den du garantiert stolperst: Um EWS wieder einzuschalten, entfernst du zuerst den Haken bei “Block your entire organization from using EWS“ und klickst auf “Apply change“. Danach setzt du denselben Haken wieder und klickst erneut auf “Apply change“.
Ja, richtig gelesen. Der Haken bei “Block” ist am Ende gesetzt, und trotzdem ist EWS wieder aktiv. Die zugrunde liegende Einstellung lautet nach dieser Aktion EwsEnabled = $true mit einer Allow-Liste, die die bisher genutzten Anwendungen enthält. “Block” bedeutet in dieser Oberfläche also eigentlich “alles blockieren außer den Apps in der Ausnahmeliste”. Die Ausnahmen findest du im Bereich Scope Summary; über “Exclude specific apps“ kannst du sie bearbeiten.
Ich halte diese UI für ziemlich unglücklich, weil sie das Gegenteil dessen suggeriert, was technisch passiert. Wenn du das im Team dokumentierst, schreib dazu, was im Hintergrund gesetzt wird. Sonst kommt in drei Monaten ein Kollege auf die Idee, den “Block“ doch mal zu entfernen, weil er EWS ja eigentlich erlauben will.
Weg 2: Exchange Online PowerShell
Mir persönlich ist der PowerShell-Weg lieber, weil er transparent ist und du genau siehst, was du änderst. Wie das konkret aussieht, siehst du unten.
Wie lange dauert es?
Nach dem Wiedereinschalten funktionieren die meisten Anwendungen innerhalb einer Stunde wieder. In seltenen Fällen kann es laut Microsoft bis zu vier Stunden dauern. Änderungen an der Allow List selbst brauchen deutlich länger, hier rechnet Microsoft mit etwa 24 Stunden, bis sie greifen. Plan das ein, bevor du jemandem versprichst, dass “das gleich wieder geht“.
Praxisbeispiel: Prüfen, wieder einschalten, Allow List kontrollieren
Verbinde dich wie gewohnt mit Exchange Online Management-PowerShell und schau dir zuerst den aktuellen Zustand an:
Connect-ExchangeOnline -UserPrincipalName user@yourdomain.dev
Get-OrganizationConfig | Format-List EwsEnabled
Steht dort EwsEnabled : False? Dann hast du die Ursache gefunden.
Steht dort nichts, also $null, ist dein Tenant noch nicht umgestellt worden, und du hast noch etwas Zeit für eine Bestandsaufnahme. Das ist übrigens der ideale Zeitpunkt, um diesen Befehl in allen Tenants, die du betreust, auszuführen.
EWS schaltest du anschließend mit einem einzigen Befehl wieder ein:
Set-OrganizationConfig -EwsEnabled $true
Danach prüfst du, welche Anwendungen Microsoft in die Allow List eingetragen hat:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs
Die Ausgabe enthält die App-IDs der Anwendungen, die in den letzten 60 Tagen in deinem Tenant über EWS zugegriffen haben. Wenn nach dem Wiedereinschalten alles funktioniert, musst du an dieser Liste nichts ändern. Interessant wird es bei Anwendungen, die nur selten laufen, etwa Jahresabschlussjobs, quartalsweise Exporte oder eine Migrationslösung, die seit drei Monaten nicht mehr angefasst wurde. Die sind in der 60-Tage-Betrachtung nicht enthalten und bleiben auch nach dem Wiedereinschalten blockiert. Solche Apps musst du selbst nachtragen; die Details dazu verlinkt Microsoft im oben genannten Artikel. Denk an die 24-Stunden-Vorlaufzeit.
Vergiss außerdem nicht, dass die Postfachebene weiterhin mitspielt. Wenn einzelne Benutzer trotz aktivem EWS auf Organisationsebene Probleme haben, lohnt ein Blick auf das Postfach:
Get-CASMailbox -Identity anwender@yourdomain.dev | Format-List EwsEnabled
Die Uhr tickt: April 2027
Und jetzt der Teil, der in vielen Gesprächen gern überhört wird. Das Wiedereinschalten ist eine Übergangslösung. Wir befinden uns in der ersten Phase der EWS-Abschaltung, in der Kunden die EWS noch selbst reaktivieren können. Ab April 2027 funktioniert das nicht mehr. Dann ist EWS in Exchange Online endgültig keine Option mehr, egal was in deiner Organisationskonfiguration steht.
Das heißt konkret: Jede Anwendung, die du jetzt durch Wiedereinschalten rettest, ist ein offenes Ticket mit Ablaufdatum. Für gekaufte Software brauchst du eine Version vom Hersteller, die kein EWS mehr verwendet. Für Eigenentwicklungen bedeutet das, den Code auf Microsoft Graph umzustellen. Und wer noch Outlook-Versionen im Einsatz hat, die auf EWS angewiesen sind, hat ein ohnehin überfälliges Lifecycle-Problem.
Fazit
Meine Empfehlung ist eindeutig: Warte nicht auf den Message-Center-Post. Prüf jetzt in allen Tenants, die du verantwortest, den Wert von EwsEnabled und den Inhalt der Allow List, sobald sie befüllt ist. Mach eine Inventur aller Anwendungen, die EWS nutzen, und frag die Hersteller aktiv nach, wann eine graphbasierte Version verfügbar sein wird. Wenn es knallt, weißt du jetzt, wie du EWS innerhalb einer Stunde wieder zum Laufen bringst. Aber nutze diese Option als Pflaster, nicht als Lösung.
Die eigentliche Frist ist April 2027, und die ist näher, als sie klingt. Wer die verbleibenden Monate nutzt, um seine EWS-Abhängigkeiten sauber abzubauen, erlebt im nächsten Frühjahr einen entspannten Stichtag. Alle anderen erleben ihn im Krisenmodus.
