Exchange Online EWS Shutdown Begins: Configure AppID Allow Lists Before April 2027

This isn't a sudden ambush. It's the last stage of a retirement that has been on the calendar for years. For any tenant that still depends on EWS without knowing it, though, the next six months are likely to arrive as a series of support tickets.

What changes starting today​

The Register reports that Microsoft now begins disabling EWS in Exchange Online. In practice, Microsoft changes the tenant-level EwsEnabled setting from its default $null to $false, which blocks EWS for that tenant. Admins who need more time can set the value to $true and list approved applications in EwsAllowedAppIDs. Any application not on that list is blocked.

Microsoft's Message Center notice MC1227454 put it simply: "Beginning October 1, 2026, EWS will be blocked unless the tenant configures an AppID AllowList and sets EWSEnabled=True." The notice also says this change only impacts Exchange Online; Exchange Server (on-premises) is not affected.

This is a rollout, not a single switch. Microsoft's Learn documentation on the deprecation says EWS "starts to be disabled globally" in October 2026 and is fully disabled in April 2027. Atriomail, summarising Microsoft's September notice MC1469960, reports that Microsoft describes the rollout as starting in early October 2026 and finishing in late April 2027. So a tenant that still works this morning may not be in the same state next week.

Summary: If your tenant left EwsEnabled at $null, expect EWS to be blocked when the rollout reaches you. Setting it to $true only helps if a properly filled allow list goes with it.

The trap: $true alone no longer allows everything​

This is the detail most likely to catch admins out. Before October, setting EwsEnabled to $true with no allow list let all EWS traffic through. After today, the same setting does the opposite.

According to MC1447678, beginning in October 2026, if EWSEnabled=True and no allow list is configured, all EWS traffic except Cross-tenant org relationships will be blocked. Microsoft's Exchange Team said the same thing when it introduced the feature: enabling EWS without configuring an AppID allow list will no longer act as an unrestricted "allow everything" mode.

4sysops summarises the change in plain terms: before October 2026, setting EwsEnabled to $true with an empty allow list still permits all EWS traffic; after that date, the same combination becomes a block-all setting.

Here is how the settings now behave:

There's one reassurance in MC1447678: organizations that have EWSEnabled=True and a configured EWSAllowedAppIDs allow list will not have their EWSEnabled setting modified by Microsoft before April 2027. Microsoft's Skype for Business hybrid guidance adds that the organisation-level setting overrides per-mailbox EWS settings. If it's $false, EWS is blocked for every mailbox, whatever the individual mailbox configuration says.

Don't confuse the two allow lists. EwsAllowedAppIDs takes Microsoft Entra application IDs. The older EwsAllowList, used with EwsApplicationAccessPolicy, matches user-agent strings. Microsoft's Exchange Team updated its post on September 1 specifically to make clear it means the "AppID Allow List" (the allow list that takes Application IDs, as opposed to user agent strings used by EwsApplicationAccessPolicy and it's EWSAllowList setting).

Microsoft's auto-built allow lists may miss things​

Microsoft has offered to build allow lists for tenants that didn't make their own, using each tenant's EWS usage telemetry. That sounds helpful, but there's a catch. Atriomail reports that MC1469960 says Microsoft will not overwrite a list you configured, but where none exists it may build one from the last 60 days of usage, and it warns that such a list may omit applications that run infrequently.

Think about the quarterly compliance export, the year-end archive job or the disaster-recovery script that only runs during a drill. None of those may show up in 60 days of telemetry. Compare Microsoft's list against your application owners' records, not just against what the logs saw.

Timing matters too. Microsoft's own advice was to have the allow list in place by the end of August 2026. In Atriomail's words, a client tenant that is not done yet is behind Microsoft's schedule, not early. If you're making changes today, check what your tenant actually shows. Don't assume a new change will undo a block that has already been applied.

How to check and fix your tenant​

Microsoft's guidance for hybrid Skype for Business Server includes a PowerShell procedure for Exchange Online PowerShell (the EXO V3 module) that works as a general pattern. Here are the steps, adapted to the general case:

• Check your current state. Run Get-OrganizationConfig | Format-List EwsEnabled, EwsApplicationAccessPolicy, then run Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs to see the allow list.
• Collect app IDs. Use the Entra application (client) IDs of the apps that genuinely still need EWS. 4sysops describes the list as a tenant-wide list of Microsoft Entra application IDs (the client IDs of app registrations) that may still call EWS when you set EwsEnabled to $true.
• Enable EWS at the tenant level with Set-OrganizationConfig -EwsEnabled:$true. Only do this together with step 4.
• Update the list without deleting entries. Read the current list, split it on commas, add only the IDs that are missing, then write the combined list back with Set-OrganizationConfig -EwsAllowedAppIDs. This matters because, as Atriomail puts it, setting the list replaces the existing one, so every required App ID has to go in at once, and changes can take up to 24 hours to apply. Microsoft's Skype guidance uses exactly this read-modify-write approach so that rerunning the script doesn't remove existing entries or add duplicates.
• Wait before you test. MC1447678 advises admins to allow sufficient time after updating the allow list before validating application access or troubleshooting connectivity issues.
• Check the result. Run the two Get-OrganizationConfig commands again and confirm that each listed application actually connects.

Success looks like this: EwsEnabled shows True, EwsAllowedAppIDs lists every required ID and nothing extra, and the approved apps work once the change has propagated.

Common failure points:

• You set $true but left the list empty. That's now block-all.
• You overwrote the list and dropped existing entries.
• You tested too soon after a change.
• You entered user-agent strings in the AppID list.
• You only noticed an infrequent job when it failed.

A worked example: hybrid Skype for Business Server​

Microsoft's Skype guidance shows how specific this can get. It only affects hybrid deployments, meaning Skype for Business Server on-premises with mailboxes in Exchange Online. Purely on-premises Skype and Exchange deployments aren't affected. Two IDs need to be on the list:

• the server's own app ID, which is the ServiceName returned by Get-CsOAuthConfiguration
• the Skype desktop client's well-known first-party ID, d3590ed6-52b3-4102-aeff-aad2292ab01c

Microsoft also says an upcoming Skype for Business Server update will replace EWS calls to Exchange Online with Microsoft Graph, and that update must be installed before April 1, 2027. The allow list keeps you running for now. The update is what keeps you running after the deadline.

Graph is the destination, but not every feature has made it​

Microsoft's position is clear: move to Microsoft Graph. MC1227454 describes Graph as offering improved security, modern authentication, and broader capability support. Microsoft's Graph migration documentation adds that Graph's OAuth-based, granular permissions replace the all-or-nothing access model of EWS. It also warns that Graph isn't supported for on-premises Exchange.

The Register notes that some capability gaps remain, and Microsoft's own roadmap confirms it. Its deprecation page lists features still due, with targets that "might change":

• Q3 CY2026: mailbox notes (IPM.StickyNote), personal contact lists, and additional contact properties
• Q4 CY2026:
• full-fidelity import/export for archive, public folder and Microsoft 365 Group mailboxes
• generic CRUD (create, read, update, delete) access to in-place archives
• Exchange Admin APIs for selected mailbox settings, including folder permissions
• sovereign-cloud availability
• reporting messages as junk or phishing
• creating or updating non-draft messages with MIME content
• user configuration objects
• marking all items in a folder as read in one operation

Microsoft also lists three capabilities that will never come to Graph: generic public folder CRUD, generic Microsoft 365 Group mailbox CRUD, and access to legacy Discovery Mailboxes. Microsoft points to Graph's group conversation APIs and to Purview eDiscovery as the alternatives. Its own instruction is blunt: if a feature isn't on the roadmap, don't plan on it arriving before EWS is turned off.

That's already showing up in vendor products. Atriomail reports that Veeam's KB4820 still needs EWS for Exchange Online backups while it waits on Microsoft Graph features. MailStore says Exchange Online archive mailboxes and public folders cannot be archived after April 2027. If your backup or archiving depends on those features, ask your vendor directly what their plan is.

Finding what you don't know you have​

Markus M??ller, global field CTO for API management at Boomi, told The Register that one of the hardest parts is simply finding every place EWS is used. In his view, quick integration rollouts and thin documentation mean many organisations don't have a full inventory of their EWS dependencies. He also warned that translation layers, which convert EWS calls into Graph requests, can bridge the gap for a while. But they add another component to maintain, and you still have to migrate. That's one industry executive's view, and it fits Microsoft's own advice.

Microsoft's suggested toolkit:

• EWS Usage Reports to see which apps are calling EWS
• The EWS Analyzer to inspect code
• An AI-assisted tutorial for analysing and refactoring EWS code
• Rebuilding simpler workflows in Power Platform or as a Copilot agent
• Vendor pressure to get third-party products moved off EWS

None of these replace testing. And as noted above, telemetry only shows what ran recently.

Microsoft hasn't said how many organisations or processes still use EWS in Exchange Online. The honest prediction, which The Register also makes, is that integrations nobody noticed will reveal themselves as the blocking reaches each tenant, usually when a workflow that has always worked suddenly stops.

The bottom line​

Microsoft stopped adding features to EWS in Exchange Online in 2018, announced the October 2026 date in 2023, and treated the change as more urgent after the January 2024 Midnight Blizzard incident, which involved EWS. Today is when that long notice turns into enforcement.

The allow list buys time, not a permanent exemption. After April 1, 2027, Microsoft says there will be no exceptions. Check your EwsEnabled value and allow list today. Go through the apps that run rarely and the ones built by vendors. Then use the next six months to move to Graph, rather than finding the gaps when things break.

Update: Microsoft sets October 10 start for EWS allow-list enforcement (October 2, 2026)​

Microsoft’s Exchange Team has published a more precise rollout schedule, correcting the earlier implication that an empty AppID allow list became block-all on October 1. Enforcement will begin October 10, 2026, in Microsoft’s worldwide multi-tenant (WW) cloud. Other clouds will receive separate timelines through Message Center.

At the end of October 2, Pacific Time, Microsoft will record tenants with EwsEnabled=True and no EwsAllowedAppIDs list. For those tenants, it will create lists on October 8–9 using application IDs observed during the preceding 60 days. Admins who enable EWS after the October 2 cutoff must populate their own lists rather than expect this automatic provisioning.

The Exchange Team also confirms that disabling EWS for untouched tenants is a subsequent phase, not an immediate blanket switch. Tenants with EwsEnabled still Null and no AppID allow list will receive seven days’ warning in Message Center when selected. Microsoft will populate their lists shortly before setting EwsEnabled=False. Admins needing continued access must then explicitly restore True. Changes to EwsEnabled take approximately one hour to apply; allow-list changes take 24 hours.

Microsoft also clarifies that its own applications are not automatically exempt: those still appearing in EWS usage reports need allow-list entries to continue working. For Outlook for Windows, Microsoft specifies build 16.0.20430.20092 or higher and recommends testing whether the Office client AppID can be blocked without disruption. Classic Outlook for Mac requires the Microsoft Office AppID to remain allowed; new Outlook for Mac is unaffected by this change.