# EWSAllowedAppIDs before October 10: find and test every EWS app > On October 10, 2026, turning EWS on stops being enough. Exchange Online will want a list of the exact apps allowed to use it, and any app missing from that list can lose access. Here is how to find every app still calling EWS, build the list without wiping it, and prove it works before the date. [Home](https://tenantcraft.ca/) [Insights](https://tenantcraft.ca/insights) Governance Validate Oct 4, 2026 9 min read Geri Crroj Microsoft 365 consultant, Niagara, Ontario 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. ![Message Center post MC1485116 showing the rollout schedule and a three row milestone table. October 2, 2026, Microsoft identifies affected tenants. October 8 and 9, Microsoft creates and populates EWSAllowedAppIDs from 60 days of EWS activity. October 10, 2026, the list becomes required when EWSEnabled is True, and that row is circled in red.](https://tenantcraft.ca/images/ews-02-mc1485116.png) Message Center · MC1485116 The milestone table from MC1485116, published October 1. The October 10 row is the one that breaks things. Checked in a live tenant in October 2026. ## 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. | What you see | What happens next | | --- | --- | | **EWSEnabled** is blank (Null) | You are in the main rollout that started on October 1, 2026. Microsoft fills your list from usage, then a few days later flips EWSEnabled to False. EWS stops. | | **EWSEnabled** is True, list is empty | You are the group MC1485116 is about. Microsoft identified these tenants on October 2. It builds a list for you on October 8 or 9, and enforces it on October 10, 2026. | | **EWSEnabled** is True, list has app IDs | Microsoft leaves your list alone. It also says it won’t change your EWSEnabled setting before April 2027. | | **EWSEnabled** is False | All EWS is already blocked. Nothing changes on October 10. | 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. ![Microsoft 365 admin center Usage page with Exchange selected and the EWS usage tab circled in red. The report covers the past 30 days, September 4 to October 3, 2026, and shows 0 active apps and a daily average call volume of 0, with an empty usage details table below.](https://tenantcraft.ca/images/ews-01-usage-report.png) Admin center · Reports › Usage My test tenant shows zero active apps, which is what a clean tenant looks like. Yours will list one row per app and action. Checked in a live tenant in October 2026. 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. Count the days Each list change needs a full day to settle. A clean in, out and back in cycle takes about three days. If you start on October 7, you will not finish before October 10. Run it in a test tenant now if you can, and run only Test 1 in production. ## 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. Every app ID on your EWS list is an app with standing access to mailboxes. The permissions cleanup checklist walks you through who has access, who approved it, and when it should end. Permissions Cleanup & Governance Prep Checklist PDF · 7 pages · 45 checkpoints [Email me the PDF](https://tenantcraft.ca/resources/guides/permissions-cleanup-prep) TWENTY MINUTES, NO PITCH ## Tell me what is stuck. I will tell you what it takes. Same consultant from the first email to the last cutover. If I am not the right fit, I will refer you to someone who is. [Book a 20-min call](https://tenantcraft.ca/contact) [See published rates](https://tenantcraft.ca/pricing) --- _Canonical HTML: https://tenantcraft.ca/insights/ewsallowedappids-find-test-ews-apps · Agent guide: https://tenantcraft.ca/llms.txt · Site map: https://tenantcraft.ca/sitemap-index.xml_