The MSP guide to the Exchange Online EWS retirement
The rollout rules below reflect Microsoft’s 26 October update. Other reference notes retain their 7 September 2026 source baseline unless separately dated. Where this page and Microsoft’s current documentation disagree, Microsoft is correct and this page is out of date — tell us.
The timeline
This was the preparation target, not a current deadline. Review the tenant's actual configuration against the current rollout guidance; do not wait for automatic list creation after the published Worldwide cutoff.
Exchange Online began phased EWS retirement. Worldwide list population and tenant disablement now have state-specific rules; 1 October was the programme start, not a universal tenant switch date.
EWS in Exchange Online is disabled completely. Microsoft states no exceptions after this date, and EwsEnabled stops being a workaround.
The state matrix
Two values decide each tenant’s fate: EwsEnabled and EwsAllowedAppIDs, both read with Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy.
The current access column is for Worldwide multi-tenant cloud. The before-enforcement column is historical, not a way to predict another cloud’s current state. Microsoft’s no-further-availability-change statement for existing true tenants does not remove the App ID and other access checks already in effect.
| EwsEnabled | Allow-list state | Before enforcement | Current Worldwide access and rollout |
|---|---|---|---|
| null | any or absent | allow list ignored, EWS works | For null with a missing list, the process has started: a 7-day Message Center warning precedes list population and the change to false. An existing list alone does not establish the tenant’s schedule. |
| true | absent | EWS works | Microsoft reports list population on 10-11 October 2026. Administrators setting true after 11 October must populate the list themselves; do not wait for automatic creation. |
| true | empty | EWS works | all EWS blocked — if the list remains empty when updated behavior reaches the tenant |
| true | populated | only listed App IDs work | only listed App IDs work |
| false | any | all EWS blocked | all EWS blocked |
Exemption added by Microsoft on 6 August 2026 (Message Center MC1447678 — a separate notice from MC1446796, below): EWS traffic for Organization Relationships (cross-organization free/busy and related sharing) is exempt regardless of the allow list’s contents, because these flows do not use OAuth and need no App ID added. The exemption still requires EwsEnabled=true; setting EwsEnabled=false stops the cross-tenant exchange. For a two-way relationship, both organizations — yours and the partner’s — must set EwsEnabled=true. The exemption holds until 1 April 2027. Re-read the updated post.
Do not treat a reset to null as a supported escape from retirement. Microsoft’s 21 October recovery guidance is for the tenant administrator. An EwsEnabled change usually takes less than one hour, but can take up to four hours; an App ID list change takes 24 hours. Any recovery is temporary, not a permanent exception or an emergency service offered by SHEV.
Two different allow lists
Exchange Online has two separate allow-list mechanisms with similar names. They are routinely confused, and they do not do the same job.
| Allow list | Keyed on | Parameters | What it is |
|---|---|---|---|
| App ID list | Entra application ID (GUID) | EwsEnabled + EwsAllowedAppIDs | the retirement mechanism this page describes |
| User-agent list | User-Agent string | EwsApplicationAccessPolicy + EwsAllowList / EwsBlockList | a long-standing Exchange feature |
- An application must pass both checks. The two lists do not replace each other. Microsoft states the App ID list takes priority, but an application reaches EWS only if it passes both checks. A restrictive setting on either mechanism alone is enough to block it.
- EnforceAllowList with an empty allow list blocks everything. This follows directly: setting
EwsApplicationAccessPolicytoEnforceAllowListwith an emptyEwsAllowListmeans no application can call EWS. This is documented behaviour, not a misconfiguration. - The user-agent list is not limited to EWS. Microsoft documents EWS and REST behavior directly, and separately states that many Graph APIs accessing Exchange Online are also subject to these EWS application policies.
Before 1 October 2026, restricting access by App ID only needs EwsEnabled=true with a populated EwsAllowedAppIDs. Turning on EnforceAllowList is not required for that.
How missing-list creation follows the tenant rollout
Microsoft's 26 October 2026 update describes the current Worldwide multi-tenant cloud rollout. Sovereign cloud timing is separate; do not apply the Worldwide cutoff to those clouds.
EwsEnabled=true: For EwsEnabled=true with a missing list, Microsoft reports that it populated EwsAllowedAppIDs on 10-11 October 2026. Administrators setting EwsEnabled=true after 11 October must populate the list themselves. For tenants already set to true, Microsoft says it will not change EWS availability until April 2027; this is not a guarantee that an application or its configuration works.EwsEnabled=null: For EwsEnabled=null with a missing list, the disablement process has started. A 7-day Message Center warning precedes list population based on the previous 60 days of usage and the change to EwsEnabled=false. A tenant administrator may temporarily re-enable EWS subject to the App ID list; full retirement in April 2027 remains unchanged.- Customer-managed list: Microsoft says it will not overwrite or change a customer-managed list. That list remains authoritative for the tenant.
- Observation is not intent: A Microsoft-generated list may omit infrequent applications and retain applications the administrator does not want, so it is evidence to review rather than a business decision.
The minimum sensible action for any managed tenant, even with zero budget: monitor the tenant’s actual state, then diff the list that exists against a 90-day usage export and your own application inventory — and record who made each keep/remove call. The 90-day report is broader audit evidence; it is not the same as Microsoft’s 60-day list-generation window.
Rollout source checked 27 October 2026: EWS Deprecation Is Here — Exchange Team Blog (updated 26 October 2026, v11).
If the method is clear but the portfolio work does not fit your capacity, the EWS Allow-List Review turns the supplied evidence into a dated written decision record at a fixed scope and price.
Reading the usage report correctly
The admin-center EWS usage report (Reports → Usage → Exchange Web Services) documents four logical columns: Application ID, SOAP Action, Call Volume and Last Activity date (UTC), over a selectable 7/30/90-day window.
- Aggregation is weekly, not daily, and Microsoft states that activity can take up to 10 days to appear — recent windows can lag reality.
- Treat every export as a dated observation. It covers a selected historical window; it is not a live configuration snapshot and does not prove that an application is safe to remove.
- It counts successful calls. A failing integration is invisible.
- Absence proves nothing. Quarterly billing jobs, year-end exports and monthly services can miss any window entirely. “Not in the report” is a reason to investigate, never a reason to remove.
- Export hygiene: keep the original download. Opening and re-saving in Excel rewrites the file’s physical shape (encoding, quoting, dates) and destroys its value as evidence. Microsoft does not document the exact physical CSV serialization, so the original bytes are the only authoritative record.
- Usage ≠ permission. The report shows what called EWS; your Entra app inventory shows what is allowed to. Reconciling the two — per tenant — is the actual work.
- Message Center adds a second signal. Microsoft also posts a monthly Message Center summary of that tenant’s own EWS usage, independent of the report itself.
The full-replacement write trap
Set-OrganizationConfig -EwsAllowedAppIDs writes the whole list, every time. There is no documented incremental add or remove. The failure mode writes itself: an engineer “adds” one App ID from a ticket without reading the current value first, and every other entry is silently removed. Nothing errors. Things stop working later — Microsoft’s notices say changes can take up to 24 hours to apply.
- Read-modify-write, every time: read the current list, compute the full new set, write it whole.
- Keep the intended list per tenant under change control; treat the live value as a deployment target, not the source of truth.
- Record who approved each entry and why — the question your client asks is “who decided this”, not “what is the value”.
A multi-tenant checklist
Per tenant, using its current configuration and cloud-specific rollout:
- Export the EWS usage report, 90-day window, and keep the original file.
- Snapshot
EwsEnabledandEwsAllowedAppIDs(read-only), with a date. - Reconcile: observed usage vs current list vs your app inventory.
- Name an owner for every observed application — the unknown-owner queue is the real work.
- Decide keep / migrate / remove / investigate per application, and record who decided.
- Keep the intended App ID list under the administrator’s review; enabling EWS alone is not sufficient when an App ID list is required.
- Re-check the tenant’s Message Center for tenant-specific notices.
- Do not wait for automatic list creation when setting
EwsEnabled=trueafter 11 October in Worldwide cloud; the administrator must populate it. For a null/null tenant, follow the 7-day Message Center notice. - Re-check after the rollout reaches the tenant; 1 October is the programme start, not a universal per-tenant switch date.
- Keep the evidence: exports, snapshots, decisions. Your client will ask.
- Plan the endgame: everything still on the list is technical debt due 1 April 2027.
Workload-specific tracks
These workload-specific notes retain their September source baseline. Published rollout targets are historical plans, not evidence that your tenant completed a migration:
- Skype for Business Server hybrid has its own instruction with the explicit end-of-August deadline and named application IDs to allow-list — the dedicated Learn page is the authority for that workload.
- Cross-tenant Free/Busy, MailTips and Calendar Sharing move to Cross-Tenant Access Policy. Official notice: Message Center MC1446796; the detailed walkthrough is the Exchange Team Blog post of 7 August 2026. The published plan targeted worldwide rollout from August to 1 September, GCC from mid-August to mid-September, and GCC High/DoD during September 2026. Those dates do not establish completion or readiness for a particular tenant; check the current workload guidance and Message Center. An App ID review alone does not verify the separate sharing configuration.
- Kiosk/F1/F3 licensing plans have a separate EWS block that was rescheduled to 1 October 2026 (MC1191578).
Questions we keep getting
What this page cannot tell you
- The exact day a specific tenant will be switched after 1 October — Microsoft does not publish per-tenant schedules.
- Whether a specific application in your estate depends on EWS — only reconciliation against your own evidence answers that.
- The physical byte-level format of the usage CSV export — Microsoft documents the logical columns, not the serialization.
- Whether Microsoft will revise this guidance again — it has done so more than once; the dates above carry our last verification date for exactly that reason.
That last mile — your tenants, your evidence, reviewable decisions your client can hold — is the audit this site offers: fixed scope, run entirely in writing, no credentials, nothing changed in any tenant. What it includes · start a written scoping.