EWSAllowedAppIDs before October 10: find and test every EWS app

On Saturday I opened Message Center in my test tenant and found a post that went up on October 1. It is called Exchange Web Services (EWS) enforcement update for EWSAllowedAppIDs. Its ID is MC1485116.

The short version sits in one line of a small table. On October 10, 2026, EWSAllowedAppIDs “becomes required when EWSEnabled=True.” Apps that are not on the list may lose access to EWS.

That is one week away. Most of the admins I talk to did the right thing in September. They set EWSEnabled to True so Microsoft would not switch EWS off for them. Many of them stopped there, and that is the gap.

The real problem is that True no longer means “on”

Through September, EWSEnabled = True with no list meant every app could use EWS. That changes on October 10. From then on, True with no list blocks every app. True only works as a gate with a list of app IDs behind it.

The question worth asking now is which apps your tenant lets through, and whether you picked them or Microsoft did.

Click to zoomTap to zoom

Which of three groups is your tenant in?

Everything depends on the current value of one setting. Connect to Exchange Online PowerShell and run these two lines:

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

The -RetrieveEwsOperationAccessPolicy switch is not optional. Without it, the list does not come back at all. Microsoft only fetches it when you ask, for performance reasons.

True with a list of app IDs is where you want to be. It is also the only state where you chose the apps.

Why the list Microsoft builds for you is not good enough

Microsoft will not leave you with an empty list. It looks back over the last 60 days of EWS calls in your tenant and adds every app it saw. That sounds kind, and it will stop most outages. Here is where it falls short.

1. It misses rare jobs. A quarter-end export, a yearly archive script, a mailbox tool someone runs at audit time. If it did not call EWS in the last 60 days, it is not on the list.
2. It keeps apps you forgot. An old backup trial or a vendor you dropped last spring still shows up if it is still calling in. Now it has your blessing.

Build your own list and Microsoft’s automated process skips your tenant. The Exchange team’s blog confirms it won’t change a list an admin already created.

Find every app still calling EWS

I check three places, because each one catches something the others miss.

1. The EWS usage report

In the Microsoft 365 admin center, go to Reports › Usage. Pick Exchange in the left menu, then the EWS usage tab. Set the period to the longest one on offer.

Each row is an Application ID, the SOAP action it called, the call volume and the last date it was seen. The application ID is the value that goes on your list.

Click to zoomTap to zoom

My tenant shows zero apps, because nothing in it uses EWS. A real company will not look like this. Expect Microsoft’s own apps in there too.

2. Message Center

Search Message Center for Update active Exchange Web Services Applications. Microsoft has been sending these tenant-specific summaries to every tenant since late December 2025. If you have none, the Exchange team says you likely have no EWS use at all.

3. The app usage script

The usage report gives you an app ID, with no owner attached. Microsoft’s Exchange-App-Usage-Reporting project on GitHub fills that gap. Its Find-EwsUsage.ps1 lists every app registration with EWS permissions, plus when each one last signed in. Sort by last sign-in. Recent ones are the ones that will break.

Don’t forget Microsoft’s own apps

MC1485116 names the Microsoft apps that can still make EWS calls:

• Outlook for Windows (it should be on build 16.0.20430.20092 or later)
• Classic Outlook for Mac (add the Microsoft Office app ID if you still use it)
• Excel Power Query and Power BI
• Exchange Server hybrid setups

New Outlook for Mac is not affected. If any of the others show up in your report and you still need them, they go on the list too.

The naming trap: EWSAllowedAppIDs is not EWSAllowList

There is an older pair of settings called EWSAllowList and EWSBlockList. They belong to a feature called EwsApplicationAccessPolicy, and they match on user agent strings, not app IDs. Despite the name, that policy also affects REST traffic.

Microsoft says it directly in MC1485116: EWSAllowList “is unrelated to EWS retirement.”

The two controls are checked one after the other. A request has to pass the app ID list first, then any user agent policy you have. So a passing app ID test proves nothing about your old user agent rules. Test each one on its own.

Add to the list, never overwrite it

Set-OrganizationConfig -EwsAllowedAppIDs writes the whole list every time. There is no add or remove. If you set it to one app ID, every other app ID is gone.

Read the list, add yours, write it back. This is the pattern from Microsoft’s own field notes:

$appId   = "00000000-0000-0000-0000-000000000000"  # the app to add
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy).EwsAllowedAppIDs
$updated = @($current -split "," | ForEach-Object { $_.Trim() } | Where-Object { $_ }; $appId) |
           Select-Object -Unique
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

Then run the Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy line again and check that every ID is still there. Save the old value in your change ticket before you start. It is your undo.

Prove it works with one app in and one app out

I would not trust a list until I had seen it block something. Microsoft’s field notes describe a two-part test using its Test-EWSAppAccess.ps1 script. You check that a listed app gets in, then that an unlisted app is turned away.

The test only means something when all of these are true:

• The test app can get an OAuth token.
• It has the EWS application permission, with admin consent for the whole tenant.
• EWSEnabled is True for the test.
• The test mailbox has at least one item in its Inbox. The script reads the first one.
• At least 24 hours have passed since the last change to the list.

Test 1: the app is allowed

1. Add the test app ID to the list, using the pattern above.
2. Wait 24 hours. Exchange Online servers only refresh this list once a day.
3. Set EWSEnabled to True with Set-OrganizationConfig -EWSEnabled $true. This usually lands in under an hour, but can take up to 4 hours.
4. Run the script with the app’s credentials:

.\Test-EWSAppAccess.ps1 -AppId $appId -TenantId $tenantId -Mailbox $mailbox -SecretKey $secretKey

A pass prints that the application accessed the mailbox, and $LASTEXITCODE is 0. Save the output with your change record.

Test 2: the app is removed

1. Remove only the test app ID, keeping every other entry.
2. Wait 24 hours again. A pass right after the change means nothing. Some server still has the old list cached.
3. Run the same command. This time it should fail, with exit code 1.
4. Put the app ID back, wait, and run Test 1 once more.

If Test 1 failed as well, the list is not your problem. Check the token, the permission, the consent and the mailbox before you blame the list.

The fastest way back if you block the wrong app

Say the test goes badly and a real app stops working. Changes to the list take up to 24 hours. Changes to EWSEnabled take about an hour. And when EWSEnabled is Null, the list is ignored completely.

So the quickest undo is this one line:

Set-OrganizationConfig -EWSEnabled $null

About an hour later, EWS is wide open again. Use it to stop the bleeding and then rebuild the list, because a tenant on Null is back in the main rollout, and Microsoft will flip it to False when its turn comes.

If EWS already stopped in your tenant

The main rollout began on October 1, 2026, so some of you are reading this after the fact. A line-of-business app failed on Thursday, and when you checked, EWSEnabled said False.

You can turn it back on. Microsoft’s own post says an admin can set EWSEnabled to True after Microsoft has blocked it. Do it in this order, so you don’t swap one outage for another:

1. Read the list first with the -RetrieveEwsOperationAccessPolicy line. Microsoft may already have filled it from your last 60 days.
2. Add any app IDs that are missing, using the add pattern above.
3. Then run Set-OrganizationConfig -EWSEnabled $true. Allow about an hour, and up to 4 hours.

If you set True with an empty list after October 10, 2026, you get nothing. True with no list blocks every app. If you need EWS back right now and the list is not ready, Null is the faster route, with the catch I covered above.

Mistakes I would check for first

1. Running the “removed” test straight after removing the app, before the 24 hours are up.
2. Writing one app ID and wiping the rest of the list.
3. Testing against an empty Inbox, then blaming the list for the failure.
4. Reading a login or consent error as proof the list blocked the app.
5. Adding app IDs to EWSAllowList by mistake. It takes user agents, and it is a different gate.

What this does not fix

A good list buys you a few months, until the final shutdown.

• April 1, 2027 still comes. On that date EWS in Exchange Online is switched off for good, and admins lose the EWSEnabled setting. Microsoft says there will be no exceptions past April 2027. Every app on your list is a migration you still owe.
• It does not move anything to Microsoft Graph. Some EWS features have no Graph match yet, and a few never will. Check Microsoft’s parity gap table before you promise a vendor date.
• It does not test your old user agent policy. If you use EWSAllowList or EWSBlockList, those need their own test.
• It does not touch Exchange Server. EWS on your own servers is not being retired. Hybrid setups are the messy middle, and need their own plan.

The bottom line

Before October 10, 2026, open the EWS usage report, write down every app ID you still need, and set the list yourself, adding to it, never replacing it. Test one app in and one app out, with a full day between changes. If it goes wrong, set EWSEnabled to Null and you are back to open EWS in about an hour.