Nächste Woche ist es so weit. Am 1. Oktober beginnt Microsoft, die Exchange Web Services in Exchange Online Tenant für Tenant abzuschalten. Das Thema ist nicht neu, die Ankündigung stammt aus 2023, und trotzdem sehe ich bei Kunden aktuell zwei Muster: Entweder hat niemand den Tenant angefasst und EwsEnabled steht noch auf $null, oder jemand hat vor Monaten schnell EwsEnabled = $true gesetzt und sich danach gedacht, das Thema sei damit erledigt.
Beides kann ab Oktober wehtun. Backup, Archivierung, Signaturlösungen, CRM-Konnektoren und die eine selbstgeschriebene Anwendung aus der Buchhaltung, von der niemand mehr weiß, wer sie gebaut hat. Wenn die noch per EWS auf Postfächer in Exchange Online zugreifen, hört das je nach Konfiguration in den nächsten Tagen oder Wochen einfach auf zu funktionieren.
Links
- Skript im Exchange for IT Pros GitHub Repo
- Exchange Online EWS, Your Time is Almost Up
- Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement
- Notes from the field: testing EWSAllowedAppIDs safely
- MC1447678 - Microsoft Exchange Online: Prepare for Exchange Web Services retirement with EWSAllowedAppIDs
In diesem Artikel schauen wir uns an, was genau ab dem 1. Oktober passiert, wie EwsEnabled und die neue AppID Allow List zusammenspielen und wie ihr mit einem Skript aus unserem GitHub Repo schnell herausfindet, welche Enterprise Apps in eurem Tenant überhaupt EWS-Berechtigungen haben.
Hintergrund
Microsoft führt die Abschaltung in zwei Phasen durch. Ab dem 1. Oktober 2026 werden Tenants, die EwsEnabled nicht explizit konfiguriert haben, auf den Status „blockiert“ gesetzt. Die endgültige Abschaltung erfolgt am 1. April 2027 (kein Aprilscherz). Zwischen diesen beiden Terminen liegt also ein Übergangsfenster, das ihr aber aktiv nutzen müsst.
Wichtig für alle Hybrid-Umgebungen: Die Abschaltung betrifft ausschließlich Microsoft 365 und Exchange Online. EWS bleibt für Postfächer auf lokalen Exchange Server-Systemen weiterhin vollständig unterstützt. Eure Anwendungen, die mit On-Premises-Postfächern arbeiten, sind also nicht betroffen. Sobald dieselbe Anwendung auch Cloud-Postfächer bedient, gilt dasselbe wie in reinen Cloud-Szenarien.
Das zentrale Werkzeug für das Übergangsfenster ist EwsAllowedAppIDs. Das ist eine Allow List auf Tenant-Ebene, in der ihr anhand der App ID festlegt, welche Anwendungen weiterhin EWS nutzen dürfen, sofern EwsEnabled auf Tenant-Ebene auf True steht. Verwechselt das bitte nicht mit der alten EwsAllowList. Die basiert auf dem User-Agent und nicht auf der App-ID und gilt nicht nur für EWS, sondern auch für REST und Graph.
Was sich ab dem 1. Oktober ändert
Die drei Zustände von EwsEnabled
Der Schlüssel zum Verständnis liegt im Zusammenspiel der beiden Einstellungen. EwsEnabled kennt drei Werte: $true, $false und $null. Solange ihr nichts angefasst habt, steht der Wert auf $null. Jeder Tenant, bei dem EwsEnabled am 1. Oktober noch auf Null steht, bekommt im Zuge des Rollouts den Wert False, und damit ist EWS für sämtliche Anwendungen im Tenant blockiert. Wer EWS gar nicht mehr braucht, lehnt sich an dieser Stelle zurück und lässt Microsoft die Arbeit machen.
Spannender ist der Fall $true. Bisher war EwsEnabled = $true gleichbedeutend mit „alles erlaubt“. Das ändert sich. Nach Beginn der Durchsetzung führt EwsEnabled = $true ohne AppID-Allowlist faktisch zu einer Block-All-Konfiguration. Microsoft macht das bewusst, um euch zu zwingen, explizit zu bestätigen, welche Anwendungen EWS wirklich noch brauchen.
Die Belohnung für die Mühe: Tenants mit EwsEnabled = True und einer konfigurierten EwsAllowedAppIDs-Liste werden von Microsoft vor April 2027 nicht mehr angefasst.
Die automatisch befüllte Allow List
Microsoft baut euch ein Sicherheitsnetz, und genau das halte ich für gefährlich, wenn man sich darauf verlässt. Für Tenants mit EwsEnabled = True, die keine eigene Allow List haben, füllt Microsoft die Allow List kurz vor der Logikänderung automatisch. Die Grundlage ist die Nutzung der letzten 60 Tage. Selten laufende Anwendungen können dabei fehlen, und gleichzeitig landen Apps auf der Liste, denen ihr eigentlich keinen Zugriff mehr gewähren wollt. Bei Tenants, die noch auf Null stehen, passiert das nur, wenn es keine eigene Liste gibt, und zwar wenige Tage, bevor EwsEnabled auf False gesetzt wird.
Denkt an den Quartalsabschluss, der einmal pro Vierteljahr per EWS-Kalenderdaten läuft, oder an das Archivierungstool, das nur monatlich einen Lauf macht. Die fallen bei einem 60-Tage-Fenster womöglich durch. Und umgekehrt landet vielleicht die Testanwendung eines ehemaligen Dienstleisters auf der Liste, nur weil sie im August noch einmal lief.
Die gute Nachricht: Wenn ihr selbst eine Liste pflegt, überschreibt Microsoft sie nicht. Die vom Kunden verwaltete Liste bleibt maßgeblich. Meine klare Empfehlung lautet deshalb: Erstellt die Liste selbst.
Organization Relationships und Cross-Tenant Free/Busy
Ein Sonderfall sind Cross-Tenant-Szenarien. Bei EwsEnabled = True und konfigurierter Allow List dürfen neben den gelisteten Apps auch Cross-Tenant Organization Relationships weiterhin EWS nutzen. Für diese Flows braucht ihr keine App-ID in der Liste, da sie ohne OAuth arbeiten. Steht EwsEnabled auf True, laufen diese Cross-Tenant-Flows bis April 2027 unabhängig vom Zustand der Allow List weiter. Das ist aber nur ein Aufschub. Der Umzug auf Cross-Tenant Access Policies steht trotzdem noch aus und ist ein eigenes Thema für einen eigenen Artikel.
Laufzeiten beachten
Plant Puffer ein. Änderungen an EwsAllowedAppIDs brauchen rund 24 Stunden, bis sie im Tenant vollständig greifen. Änderungen an EwsEnabled treten mit einer Verzögerung von etwa einer Stunde in Kraft. Wer die Liste am 30. September um 17 Uhr setzt, testet frühestens am späten Nachmittag des 1. Oktober.
Praxisbeispiel
Schritt 1: Ist-Zustand im Tenant prüfen
Bevor ihr irgendetwas ändert, verschafft euch einen schnellen Überblick. Verbindet euch mit der Exchange Online Management Shell und führt diese Zeile aus:
Get-OrganizationConfig | Format-List DisplayName,EWS*,WhenChanged; Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs
Der erste Teil liefert euch den Tenant-Namen, alle EWS-relevanten Eigenschaften der Organisationskonfiguration sowie das Datum der letzten Änderung. Neben EwsEnabled seht ihr auch die klassischen Einstellungen wie EwsApplicationAccessPolicy, EwsAllowList und EwsBlockList. Die sind insofern relevant, als eine alte User Agent Blockliste parallel weiterhin wirkt und euch bei der Fehlersuche sonst in die Irre führt. WhenChanged hilft dabei, einzuschätzen, ob hier kürzlich jemand etwas konfiguriert hat.
Der zweite Teil ist wichtig und wird gern vergessen. Der Switch -RetrieveEwsOperationAccessPolicy ist zwingend erforderlich, um EwsAllowedAppIDs auszulesen, da Microsoft die Liste aus Performancegründen nur auf ausdrückliche Anforderung abruft. Ohne den Switch seht ihr also nichts und glaubt womöglich, es gäbe keine Liste.
Schritt 2: Apps mit EWS Berechtigungen ermitteln
Jetzt braucht ihr die App-IDs. Dafür haben wir im Exchange for IT Pros GitHub Repo das Skript Get-AppsPermissionsReport.ps1 veröffentlicht. Es liest per Microsoft Graph die Enterprise Apps eures Tenants samt ihrer Berechtigungen aus und erzeugt eine CSV und einen HTML-Report. Mit dem Switch -OutputEwsAppIds gibt es zusätzlich alle App-IDs mit EWS-Berechtigungen aus und baut euch direkt den passenden Set-OrganizationConfig Befehl zusammen.
Ein Lauf für unseren Beispielkunden Varunagroup sieht so aus:
.\Get-AppsPermissionsReport.ps1 -AuthMode AppCertificate -HighlightCategories HighPrivilege,Exchange,SharePoint -ConfigPath .\config-varunagroup.json -OutputEwsAppIds
-AuthMode AppCertificate sorgt für eine App-Only-Anmeldung per Zertifikat, was sich für wiederholbare Läufe und den Einsatz über mehrere Kundententen anbietet. Mit -HighlightCategories markiert ihr im HTML-Report die Berechtigungskategorien, die euch besonders interessieren. Die tenant-spezifischen Verbindungsdaten liegen in der JSON-Datei, die ihr über -ConfigPath übergebt.
Die Ausgabe (anonymisiert):
Connecting to Microsoft Graph...
Fetching tenant information...
Tenant: Varunagroup GmbH (varunagroup.de)
Fetching service principals for permission name resolution...
Permission filter active: False
Processing app permissions...
Fetching enterprise apps...
Default filter active: third-party enterprise apps only.
Enterprise apps in scope: 412
Report data rows: 887
EWS-enabled app IDs:
1a7c3e52-4b8d-4f6a-9c21-7e3d5f8a0b14
3f9e1d27-8c5a-4e3b-b6d4-2a1f9c7e5d38
5b2d8f41-6e7c-4a9d-8f13-c4e2a7b9d061
7c4a9e16-2d3f-4b8e-a5c7-9f1e3d6b2a84
9e6b2c73-5a1d-4f7e-b8a2-1d4c7f9e3b56
b3d8f5a2-7e4c-4d1b-9a6f-5c2e8b1d7f39
d5f1a7c4-9b2e-4c6d-8e3a-7b9d2f4c1e62
Set-OrganizationConfig -EwsAllowedAppIDs "1a7c3e52-4b8d-4f6a-9c21-7e3d5f8a0b14,3f9e1d27-8c5a-4e3b-b6d4-2a1f9c7e5d38,5b2d8f41-6e7c-4a9d-8f13-c4e2a7b9d061,7c4a9e16-2d3f-4b8e-a5c7-9f1e3d6b2a84,9e6b2c73-5a1d-4f7e-b8a2-1d4c7f9e3b56,b3d8f5a2-7e4c-4d1b-9a6f-5c2e8b1d7f39,d5f1a7c4-9b2e-4c6d-8e3a-7b9d2f4c1e62"
Generating CSV report...
CSV saved: C:\Scripts\Get-AppsPermissionsReport\Reports\Varunagroup_GmbH_EnterpriseApps_20260924_091422.csv
Generating HTML report...
HTML saved: C:\Scripts\Get-AppsPermissionsReport\Reports\Varunagroup_GmbH_EnterpriseApps_20260924_091422.html
FileSystem delivery: reports saved in C:\Scripts\Get-AppsPermissionsReport\Reports
Done! Reports stored in: C:\Scripts\Get-AppsPermissionsReport\Reports
Schritt 3: Berechtigung ist nicht gleich Nutzung
Das Skript zeigt euch, welche Apps EWS-Berechtigungen haben. Es zeigt nicht, welche Apps EWS tatsächlich nutzen. Genau deshalb solltet ihr die Liste im Microsoft 365 Admin Center mit dem EWS Usage Report abgleichen. Apps mit Berechtigung, aber ohne Nutzung, sind Kandidaten für einen kritischen Blick und gegebenenfalls für den Entzug der Berechtigung. Apps mit Nutzung, aber ohne Treffer im Skript, sind in der Regel First-Party-Apps oder fallen durch den Standardfilter heraus. Aus diesen beiden Quellen ergibt sich eure finale, bewusst freigegebene Liste.
Schritt 4: Allow List und EwsEnabled setzen
Wenn die Liste steht, setzt ihr sie zusammen mit EwsEnabled. Achtet darauf, dass Set-OrganizationConfig -EwsAllowedAppIDs die vorhandene Liste überschreibt. Falls aus Schritt 1 bereits Einträge vorhanden waren, prüft, ob sie in eurer neuen Liste enthalten sein sollen.
Set-OrganizationConfig -EwsEnabled $true
Set-OrganizationConfig -EwsAllowedAppIDs "1a7c3e52-4b8d-4f6a-9c21-7e3d5f8a0b14,3f9e1d27-8c5a-4e3b-b6d4-2a1f9c7e5d38,5b2d8f41-6e7c-4a9d-8f13-c4e2a7b9d061,7c4a9e16-2d3f-4b8e-a5c7-9f1e3d6b2a84,9e6b2c73-5a1d-4f7e-b8a2-1d4c7f9e3b56,b3d8f5a2-7e4c-4d1b-9a6f-5c2e8b1d7f39,d5f1a7c4-9b2e-4c6d-8e3a-7b9d2f4c1e62"
Anschließend führt ihr die Prüfzeile aus Schritt 1 erneut aus. EwsEnabled sollte True sein und EwsAllowedAppIDs sollte eure Liste enthalten. Die funktionale Prüfung macht ihr frühestens nach 24 Stunden, am besten mit den betroffenen Anwendungsverantwortlichen, die einen tatsächlichen Zugriff auf ein Cloud-Postfach haben.
Falls etwas schiefgeht und ihr schnell zurückschwenken müsst: Die Allow List wird ignoriert, solange EwsEnabled auf Null steht. Der schnellste Weg zurück zu unbeschränktem EWS ist daher, EwsEnabled wieder auf Null zu setzen. Seid euch aber bewusst, dass das nur in der Testphase ein sinnvoller Notausgang ist, denn genau diesen Null-Zustand kippt Microsoft im Rollout auf False.
Fazit
Die Abschaltung von EWS in Exchange Online ist kein Stichtag, sondern ein Prozess, der in einer Woche beginnt. Die Allow List ist ein Werkzeug, um das Übergangsfenster kontrolliert zu nutzen, und keine Einladung, EWS dauerhaft weiterlaufen zu lassen. Über April 2027 hinaus wird es keine Ausnahmen geben.
Meine Empfehlung ist eindeutig: Prüft heute den Ist-Zustand eures Tenants mit der Einzeiler-Prüfung, ermittelt die App-IDs mit Get-AppsPermissionsReport.ps1, gleicht sie mit dem Usage Report ab und erstellt die Liste selbst, bevor Microsoft sie aus 60 Tagen Telemetrie zusammenwürfelt. Und dann nutzt die gewonnenen Monate, um mit den Herstellern und internen Entwicklern über den Umstieg auf Microsoft Graph zu sprechen. Jede App-ID auf eurer Liste ist ein offenes Ticket mit einer Deadline am 1. April 2027.
