Reference · last verified 7 September 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

Before 1 October 2026

Prepare before phased disablement

Define and review the customer-managed App ID allow list before updated EWS behavior reaches the tenant. Microsoft says it will not overwrite or change an administrator-configured list; this does not establish a tenant-specific schedule or a permanent exception.

Microsoft source

1 October 2026

Phased disablement begins

Exchange Online begins rolling out updated EWS behavior tenant by tenant. The effect depends on EwsEnabled and whether an App ID allow list exists; 1 October is the programme start, not a known switch date for every tenant.

Microsoft source

1 April 2027

EWS fully disabled

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

Microsoft source

The state matrix

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

EWS behaviour by configuration state
EwsEnabled	Allow-list state	Before enforcement	When updated behavior reaches the tenant
null	any or absent	allow list ignored, EWS works	If missing, Microsoft creates a list a few days beforehand; it then changes the tenant to false and all EWS is blocked
true	absent	EWS works	Microsoft first creates a list from the previous 60 days of observed usage, then only listed App IDs work
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.

Microsoft also documents a second way back to unrestricted EWS: clearing EwsEnabled back to null through Exchange Online PowerShell. In that state EWS is fully allowed again and the allow list is ignored entirely. A later post from the same team, on EwsAllowedAppIDs (June 2026), states that tenants left in null will eventually be moved to false as the phased rollout proceeds — a direct tension with the first claim. How long a cleared null actually lasts is not published. This is not a strategy to plan around; it is worth knowing about as an emergency lever.

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.

The two independent EWS allow-list mechanisms
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 EwsApplicationAccessPolicy to EnforceAllowList with an empty EwsAllowList means 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

Beginning 1 October 2026, Microsoft rolls out updated EWS behavior tenant by tenant rather than changing every tenant on one known day.

EwsEnabled=true: For EwsEnabled=true, if EwsAllowedAppIDs is absent, Microsoft creates a list shortly before the new logic reaches that tenant, using observed usage from the previous 60 days.
EwsEnabled=null: For EwsEnabled=null, Microsoft creates a missing list a few days before changing that tenant to EwsEnabled=false; the list may not appear until later in October.
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.

Source checked 7 September 2026: Take control of your EWSAllowedAppIDs list before EWS access changes — Exchange Team Blog.

If the method is clear but the portfolio work does not fit your September capacity, the September 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, 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 updated behavior reaches the tenant if you want the customer-managed list to remain authoritative.
Re-check the tenant’s Message Center for tenant-specific notices.
If no list was configured, watch for its tenant-specific creation and diff it as soon as it appears; EwsEnabled=null tenants may not show one until later in October.
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

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. Official notice: Message Center MC1446796; the detailed walkthrough is the Exchange Team Blog post of 7 August 2026. The replacement becomes available from September 2026: worldwide rollout begins in August 2026 and is expected to complete by 1 September 2026; GCC rolls out from mid-August to mid-September 2026; GCC High and DoD from early September to end of September 2026. Missing the 1 October 2026 deadline is recoverable here too — setting EwsEnabled=true keeps the current path working until 1 April 2027, and no App ID needs to be added for this exception.
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?

Not as a general EWSAllowedAppIDs milestone. Microsoft's 4 September guidance says updated behavior begins rolling out tenant by tenant from 1 October 2026. The explicit end-of-August wording remains relevant to the separate Skype for Business Server hybrid guidance, so check that workload independently.

Set-OrganizationConfig says EwsAllowedAppIDs is not a valid parameter. What is wrong?

Nothing is broken on the administrator's side, and the ExchangeOnlineManagement module is not the cause. Write access to EwsAllowedAppIDs rolls out tenant by tenant. Microsoft states that Get-OrganizationConfig returns the parameter for every tenant on read, but Set-OrganizationConfig rejects it as invalid until the write rollout reaches that specific tenant. A successful read and a rejected write are therefore both expected at the same time. This is a server-side capability: updating the ExchangeOnlineManagement module does not bring it closer. To check where you stand, read the value with Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy. If the property comes back but the write is still rejected, the rollout has not reached you yet. Plan on it arriving late.

When will Microsoft create a missing EwsAllowedAppIDs list?

It is tenant-specific, not a calendar-wide September event. For EwsEnabled=true, Microsoft creates a missing list shortly before updated behavior reaches that tenant, using observed usage from the previous 60 days. For EwsEnabled=null, it creates a missing list a few days before changing the tenant to EwsEnabled=false, so the list may not appear until later in October. Microsoft says it will not overwrite or change a customer-managed list. A generated list can still miss infrequent applications or retain unwanted ones and therefore needs review.

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 are the "scream tests" and can we be excluded from them?

Microsoft has warned that it may run temporary EWS disable-then-re-enable tests ahead of the final deadline to surface unknown dependencies. Tenants that already have EwsEnabled set to true are excluded from those tests. That exclusion is not a permanent exception: as updated behavior rolls out, EwsEnabled=true still requires a populated, reviewed App ID list for continued access, and EWS is fully disabled on 1 April 2027. Microsoft has not published when the temporary tests run.

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.