EWS Shutdown, Updated: What Microsoft Changed on 4 September and Your Last Three Weeks Before October

If you built your Exchange Web Services allowlist after reading the coverage in late August, you did the right thing at the time. What you probably have not done is gone back to check whether the page you built it from still says what it said three weeks ago. It does not. Microsoft's EWS deprecation page carries an updated_at timestamp of 4 September 2026, and the section that decides how much risk your remaining EWS callers carry — the parity-gap roadmap — was rewritten, not just refreshed.

This matters because ews disablement October 2026 is no longer three weeks away in the abstract; it is three weeks away with a different set of named gaps, different dates attached to some of them, and a second discovery tool most admins never noticed sitting on the same page as the one everyone bookmarked. If you already have the full timeline, the allowlist cmdlets, and the original gap list memorized, read our EWS retirement and Graph migration plan for that groundwork — this piece assumes it and picks up from 4 September.

Three things changed enough to affect a project plan: which gaps now carry a committed delivery quarter, which gap disappeared from the page entirely, and which second tool Microsoft named for tenants that cannot rely on the admin center report alone. None of that shows up unless you read the page again, not the summary you saved.

The Page Microsoft Quietly Rewrote

The previous structure sorted parity gaps into two soft buckets: "preview only, not GA" and "no committed destination." The 4 September version replaces both with a single table of thirteen named gaps, each carrying a Q3 CY2026 or Q4 CY2026 target, plus a short, blunt rule that was not there before: "If an EWS capability isn't listed in this roadmap table, don't plan on a corresponding Microsoft Graph or Exchange Admin API capability being available before EWS is fully disabled." That sentence does more work than any individual date change — it converts every capability Microsoft has not explicitly promised into "assume permanent" by default, rather than "assume eventual."

Here is what moved, using the same page as the source for both columns:

Two rows deserve a caveat rather than a verdict. The recurring-event-delta gap did not get a written "resolved" notice — it simply stopped appearing, and the page's own instruction tells you how to treat that: as unplanned, not as fixed. The no-attendee calendar event restriction is the same story from the opposite direction — its removal from the confirmed-won't-add list is not the same claim as "now supported," and nothing on the page states that it is. Treat both as open questions to raise with your Microsoft contact, not as settled either way.

The rest of the diff is good news with a delivery date attached. Archive access, Microsoft 365 Groups import/export, and sticky notes all moved from "we don't know" to "Q3 or Q4 2026," which is the kind of change that actually lets you tell a business owner when their dependency gets a real answer.

A Second Usage Tool Hiding in Plain Sight

The EWS Usage Report in the Microsoft 365 admin center is the tool everyone already knows: Reports → Usage → Exchange → EWS usage, with the now-familiar "It can take up to 10 days for usage to show in the report" caveat from Microsoft's own documentation. What the 4 September page adds is a name for a second tool that has existed for a while but rarely gets mentioned alongside it: the EWS Usage Reporting tool, distributed as Ews.App.Usage inside the same EWS Migration Tools repository that hosts the EWS Code Analyzer.

Where the admin center report is a canned view you cannot query further, Ews.App.Usage pulls directly from your tenant's Microsoft Graph audit logs and writes the result to files you own. According to the tool's setup documentation, it needs its own Entra app registration with two application-level Graph permissions:

{
  "TenantId": "<tenant-id>",
  "ClientId": "<client-id>",
  "ClientSecret": "<client-secret>",
  "OutputPath": ".\\Usage-Data"
}

The app registration behind those credentials needs AuditLog.Read.All and Application.Read.All. Running Collect-EWS-App-Usage.ipynb pulls the raw activity; Report-EWS-App-Usage.ipynb turns it into EWS-Usage.csv and a matching Power BI file, EWS-Usage.pbix. That is worth setting up specifically if the admin center report is thin for you — sovereign cloud tenants, for instance, since "Sovereign Cloud availability" for the underlying Exchange workload APIs is itself one of the Q4 CY2026 roadmap gaps, or any tenant that wants a repeatable, scriptable pull instead of a monthly export-and-pivot ritual.

Neither tool tells you who owns an Application ID — that step is still yours, and it is worth doing with Microsoft Graph PowerShell rather than a manual Entra lookup once your list runs past a handful of GUIDs:

# Requires: Connect-MgGraph -Scopes "Application.Read.All"
# $appIds comes from either the admin center CSV export or EWS-Usage.csv
$appIds = Import-Csv .\EWS-Usage.csv | Select-Object -ExpandProperty ApplicationId -Unique

foreach ($appId in $appIds) {
    $sp = Get-MgServicePrincipal -Filter "appId eq '$appId'" -Property Id, DisplayName, AppId
    $owners = if ($sp) { Get-MgServicePrincipalOwner -ServicePrincipalId $sp.Id } else { @() }

    [PSCustomObject]@{
        AppId       = $appId
        DisplayName = if ($sp) { $sp.DisplayName } else { 'UNRESOLVED' }
        OwnerCount  = $owners.Count
    }
}

An UNRESOLVED row is not a dead end — it is a finding. An App ID with no matching service principal and no recent activity is a strong decommission candidate; one with recent activity and no resolvable owner is exactly the kind of orphaned integration that generates a ticket on 1 October instead of a plan.

Sorting What's Left Into Four Buckets

Once you have real owners attached to real App IDs, every remaining caller falls into one of four outcomes, and the roadmap table above is what decides which one:

The branch worth sitting with is the second one. A caller that depends on generic Public Folder CRUD, generic Microsoft 365 Group mailbox CRUD, or Discovery Mailbox access has no destination coming, committed or otherwise — those three are the confirmed permanent gaps as of 4 September. A caller that depends on the recurring-event delta or the no-attendee calendar restriction sits in the same bucket by the page's own default rule, even without a formal "won't be added" label. Put both categories in front of whoever owns the budget now; an allowlist entry buys you until April 2027, not a redesign.

Three Weeks Before EWS Disablement in October 2026

Week of 14 September. Pull a fresh EWS Usage Report export and remember the ten-day lag — what you pull today reflects usage through roughly 4 September, not this morning. If you have not already, stand up Ews.App.Usage for a second, queryable view, particularly if any of your workloads touch a sovereign cloud tenant. Pull the current allowlist Microsoft's telemetry pre-populated for you and diff it against your own export; gaps in either direction are findings, not confirmation either list is complete.

Week of 21 September. Run every unresolved App ID through the owner-resolution snippet above and assign a named person to each result, including the UNRESOLVED ones. Sort every resolved caller through the decision-matrix flow: bridge, decommission, vendor-escalate, or re-architect. Anything landing in the last two buckets that touches a confirmed or default-permanent gap goes to your change advisory board this week, not next month — there is no runway left to discover a business-critical dependency on 29 September.

Week of 28 September. Confirm EwsEnabled is set explicitly and your EwsAllowedAppIDs list reflects this week's decisions, not August's guess. Verify any RBAC for Applications scoping you rely on for bridged callers is still correct — see our Graph SDK PowerShell guide if you are still scripting this by hand. Expect 1 October itself to be the start of a phased rollout rather than an instant flip for every tenant simultaneously, and treat the days immediately after as a monitoring window, not a closed chapter. EWS disablement is scheduled for October 2026, not a single midnight cutover, so the monitoring window matters as much as the date on the calendar.

Where This Still Trips Admins Up

Nothing in the 4 September rewrite touches the ground rules our EWS retirement and Graph migration plan already covers — the pre-populated allowlist's blind spots, the on-premises Exchange Server exemption, and the org-level-beats-mailbox-level precedence on EwsEnabled. Re-read that piece if you have not internalized those three; they still decide whether 1 October is uneventful for you. What the rewrite does add is scope: the Skype for Business Server hybrid deadline sits on top of those rules unchanged, and it is worth a second look now that the parity-gap picture underneath it has shifted.

Related Articles

• EWS Retirement: Your Exchange Online Graph Migration Plan
• Exchange Online Message Trace vs Mail Flow Rules: Diagnosing Delivery Failures Step by Step
• Microsoft 365 Reporting in 2026: Usage Reports, Graph API, and Entra Logs