Cut-paper collage: a kraft paper envelope holding a green checklist card with checkmarks, a navy shield emblem, and a paper calendar page with one date circled in red

On October 10, setting EwsEnabled to $true in Exchange Online stops meaning what it used to mean. From that date, per Microsoft 365 Message Center post MC1485116, the switch alone no longer grants any application access to Exchange Web Services. Only applications listed in your tenant's EwsAllowedAppIDs allow list get through. Everything else is blocked.

Microsoft will auto-populate a list for some tenants on October 8-9, based on 60 days of observed EWS activity. That sounds helpful until you think about which apps run less than once every 60 days. Your monthly export. Your quarterly reporting job. The tool someone opens twice a year. None of those make the cut, and they will quietly stop working.

So build the list yourself. This week.

The dates that matter

The timeline kept shifting (October 1, then "on or soon after" October 1), but the current Message Center post pins it down:

Date What happens
October 2, 2026 Microsoft snapshots which tenants have EwsEnabled set to $true with no allow list
October 8-9 For those tenants, Microsoft auto-builds EwsAllowedAppIDs from 60 days of EWS activity
October 10 Enforcement begins: EwsEnabled=$true plus an empty or missing list means no EWS access for any app
Later (phased) Tenants that never configured EwsEnabled get a 7-day warning, then are flipped off, with a list pre-populated for them
April 1, 2027 EWS is permanently disabled. No exceptions

Plan for April 1, 2027. The Exchange team has been clear about that date even when other wording wobbles.

Step 1: see where your tenant stands

Connect to Exchange Online PowerShell and run:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDs

The -RetrieveEwsOperationAccessPolicy switch is not optional. Without it, the allow list comes back empty even when one is configured, and you will chase a phantom.

Now find your row:

EwsEnabled EwsAllowedAppIDs What you do
$true Your own list Validate it is complete. Microsoft will not touch a list you built.
$true (was set before October 2) Not configured Microsoft builds one for you on October 8-9, but build your own anyway.
$true (set after October 2) Not configured Nobody builds one for you. Build it today.
$null (never configured) Ignored You are in the second phase. Watch Message Center, or take control now.
$false Any EWS is blocked. Nothing to do unless something turns out to need it.

Step 2: build the list yourself

Do not rely on the October 8-9 auto-population. A list built from 60 days of usage has a built-in blind spot: anything that runs less often than that. You know your tenant's infrequent jobs better than a usage snapshot does.

Start by listing what is currently on the allow list, and save a copy before you change anything. The list is a replacement operation, not an additive one. Run Set-OrganizationConfig with only your new AppIDs and you have just wiped whatever was there:

$config    = Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy
$allowList = @($config.EwsAllowedAppIDs -split ',' | ForEach-Object { $_.Trim() } | Where-Object { $_ })
$allowList | Set-Content -Path ".\EwsAllowedAppIDs-Backup-$(Get-Date -Format 'yyyyMMdd-HHmm').txt"

Next, find the apps that hold the full_access_as_app permission on Exchange Online. These are your background services: the ones that may hold the EWS permission whether they used it last week or last quarter. Pull them from Microsoft Graph and compare them against your allow list:

Connect-MgGraph -Scopes "Application.Read.All"

$exo = Get-MgServicePrincipal -Filter "appId eq '00000002-0000-0ff1-ce00-000000000000'"
$permApps = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $exo.Id -All |
Where-Object { $_.AppRoleId -eq 'dc890d15-9560-4a4c-9b7f-a736ec74ec40' } |
ForEach-Object { Get-MgServicePrincipal -ServicePrincipalId $_.PrincipalId -Property AppId, DisplayName }

$permApps | Where-Object { $_.AppId -notin $allowList } |
Select-Object AppId, DisplayName

Every app in that output has the EWS permission but no allow-list entry. That is your review queue. A few notes on interpreting it:

  • Having the permission is not the same as using it. Some apps picked up the permission years ago and moved to Graph since. Check with the vendor before adding.
  • Microsoft's own apps need entries too. Apple Mail on macOS (f8d98a96-0999-43f5-8af3-69971c7bb423) and the Office app ID (d3590ed6-52b3-4102-aeff-aad2292ab01c) are common ones, and Microsoft 365 admin center health probes have their own.
  • Use the Application ID (client ID), never the Object ID of the enterprise application. They look identical in the portal. Only the Application ID works in the list.

To merge new AppIDs into the existing list without wiping it, read the current list, append, deduplicate, and write the whole thing back in one Set-OrganizationConfig call. And remember that changes to the allow list take up to 24 hours to take effect. If you find a missing app on October 9, it may sit without EWS for most of October 10.

Step 3: mind the blind spots

A few things do not fit the clean model:

  • Classic Outlook for Mac explicitly needs the Office AppID on the list. New Outlook for Mac does not. If you still have classic Outlook users, that is a helpdesk ticket waiting to happen on October 10. Apple Mail users can also lose M365 sync as EWS is disabled in phases.
  • Power Query and Power BI. Microsoft points Power Query users to its retirement guidance, and the Power BI update is still "coming soon." If either shows up in your EWS usage report, it needs to be on the list.
  • Exchange hybrid. Hybrid scenarios are a documented source of EWS traffic to Exchange Online, and only Exchange SE supports Graph for those calls. Check your hybrid connectors before October 10.
  • The old EwsApplicationAccessPolicy and EwsAllowList. If you configured these years ago, they are still active and they still run after the AppID allow list. An app can be on your new list and still get blocked by a forgotten User-Agent check. Run Get-OrganizationConfig | Format-List EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList and look.

The trap to avoid

Here is the one that will catch people this week. If your tenant is on $null and you read that setting $true keeps Microsoft from flipping your tenant, you might set it now as a defensive move. Two problems: you missed the October 2 snapshot, and you are no longer a $null tenant either. Nobody builds a list for you. On October 10, every app that is not on your nonexistent list loses access.

So the rule is simple: if you set EwsEnabled to $true from this point on, set the list in the same command, never alone:

Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "f8d98a96-0999-43f5-8af3-69971c7bb423,<your-app-id>"

The durable point

Retirement deadlines always have this shape. The permissive default dies, the allow list becomes the gate, and the vendors' automated migration handles the common case while quietly dropping the rare ones. The rare ones are always your least visible integrations: the monthly export, the quarterly job, the script that runs twice a year.

The fix is always the same shape. Inventory before the deadline, not after the outage. Build the list yourself instead of trusting the 60-day snapshot. Save a copy before you touch anything. Then keep pruning apps as they move to Graph, because April 1, 2027 is not moving.

Sources