Reference · last verified 7 August 2026

The MSP guide to the Exchange Online EWS retirement

Everything below is drawn from Microsoft’s primary sources, each one linked, with the date we last re-read them. Where this page and Microsoft’s current documentation disagree, Microsoft is correct and this page is out of date — tell us.

The timeline

End of Aug 2026
Optional proactive configuration

A tenant that sets EwsEnabled to true and defines its own App ID allow list is excluded from the automatic switch. Microsoft's newest notices phrase this as “before 1 October”; the explicit end-of-August wording is in the Skype for Business hybrid guidance.

source · 21 days from this page build
Sep 2026
Microsoft populates unconfigured lists

For tenants that have not configured a list, Microsoft plans to populate one based on observed usage. An administrator-created list is not planned to be changed. Reviewing whatever list results remains the administrator's responsibility.

source · 51 days from this page build
1 Oct 2026
Phased disablement begins

Exchange Online begins gradually disabling EWS. Tenants without a timely explicit opt-in are progressively set to EwsEnabled = false. Access after that point depends on the allow list.

source · 52 days from this page build
1 Apr 2027
EWS fully disabled

EWS in Exchange Online is disabled completely. Microsoft states no exceptions after this date, and EwsEnabled stops being a workaround.

source · 234 days from this page build

The state matrix

Two values decide each tenant’s fate: EwsEnabled and EwsAllowedAppIDs, both read with Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy.

EWS behaviour by configuration state
EwsEnabledAllow listBefore enforcementFrom 1 Oct 2026
nullanyallow list ignored, EWS worksworks only until Microsoft’s phased rollout flips the tenant to false
trueemptyEWS worksall EWS blocked — the state that surprises people
truepopulatedonly listed App IDs workonly listed App IDs work
falseanyall EWS blockedall EWS blocked

Exemption added by Microsoft on 6 August 2026: EWS traffic for Organization Relationships (cross-organization free/busy and related sharing) is not governed by the allow-list state. If your allow-list plan was built before that date, re-read the updated post.

What September auto-population actually does

For tenants that have not configured their own list, Microsoft plans to populate EwsAllowedAppIDs in September 2026 based on the usage it observed. Three properties of that list matter operationally:

  • It encodes observation, not intent. An application you were retiring gets allow-listed because it was still calling EWS. An application that was quiet during Microsoft’s measurement window can be left off.
  • It does not overwrite an administrator-created list. Configuring your own list first keeps the decision yours.
  • Reviewing it is explicitly your job. Microsoft’s own guidance leaves verification of the resulting list to the administrator.

The minimum sensible action for any managed tenant, even with zero budget: diff whatever list exists on 1 October against a 90-day usage export and your own application inventory — and record who made each keep/remove call.

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 — short windows can lag reality.
  • 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.

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, before 1 October 2026:

  • Export the EWS usage report, 90-day window, and keep the original file.
  • Snapshot EwsEnabled and EwsAllowedAppIDs (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.
  • Set EwsEnabled=true with your own reviewed list before September if you want to pre-empt auto-population.
  • Re-check the tenant’s Message Center for tenant-specific notices.
  • Diff the live list against your intended list after September, and again after 1 October.
  • 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

Three tracks run alongside the general retirement and are easy to miss:

  • 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 (Message Center MC1446796, 3 August 2026): the replacement capability rolls out in September 2026 with the same 1 October deadline.
  • Kiosk/F1/F3 licensing plans have a separate EWS block that was rescheduled to 1 October 2026 (MC1191578).

Questions we keep getting

Does the end-of-August 2026 date still matter?
Yes, with nuance. A tenant that sets EwsEnabled to true and defines its own allow list before Microsoft's September auto-population keeps full control of what is on that list. Microsoft's most recent notices phrase the hard deadline as before 1 October 2026; the explicit end-of-August wording remains in the Skype for Business hybrid guidance. Treat August as the comfortable window, October 1 as the wall.
Will the list Microsoft auto-populates in September be wrong?
Not wrong — unreviewed. It reflects the usage Microsoft observed, not the decisions you made. An application you intended to retire gets allow-listed because it was still calling EWS; an application that was quiet during the measurement window can be missed. Microsoft explicitly leaves reviewing the resulting list to the administrator.
If an app does not appear in the EWS usage report, is it safe to leave it off the allow list?
No. The report covers at most 90 days, aggregates weekly, and records successful calls only. Quarterly jobs, year-end exports and rarely used integrations can be invisible in any given window. Absence from a report window is not evidence of absence of a dependency.
Does this retirement affect Exchange Server on-premises?
No. The retirement applies to EWS in Exchange Online (Microsoft 365). Microsoft states separately that EWS in on-premises Exchange Server is not being disabled by this change. Hybrid configurations have their own workload-specific guidance.
Can I just re-enable EWS if something breaks in October?
Temporarily, yes: after a tenant is switched off, an administrator can set EwsEnabled back to true, subject to the allow list, and Microsoft warns that service interruption is possible around the change. On 1 April 2027 this stops working entirely — EWS is disabled with no exceptions.
Is writing EwsAllowedAppIDs incremental?
No, and this is the sharpest operational edge in the whole retirement: Set-OrganizationConfig writes the complete list every time. There is no documented add or remove operation. Any existing App ID missing from the value you write is silently removed. Read the current list, compute the full new list, then write it — every time.

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.