Microsofts EWS deprecation is driving me mad...
Posted by hehe123exde@reddit | sysadmin | View on Reddit | 4 comments
Hello everyone,
I’m trying to get some clarity around the upcoming EWS retirement in Exchange Online, specifically the October 1, 2026 enforcement and the new AppID-based allow-listing Microsoft has mentioned.
From what I understand, Microsoft has communicated roughly the following:
- EWS in Exchange Online starts being blocked from October 1, 2026
- Final EWS shutdown is planned for April 1, 2027
- If EWSEnabled is left as $null, Microsoft will automatically set it to $false during the rollout
- To keep EWS working temporarily after October 1, 2026, the tenant must have:
- EWSEnabled = $true
- an AppID-based EWS AllowList
My confusion is around what actually happens in this scenario:
EWSEnabled = $true
…but no AppID AllowList is configured.
Does Microsoft still change EWSEnabled to $false, or does the setting remain $true but EWS calls are blocked because no AppIDs are allow-listed?
Also, has anyone actually found a working way to create/manage the new AppID-based EWS AllowList yet?
I am not talking about the old User-Agent based method:
Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceAllowList
Set-OrganizationConfig -EwsAllowList @{Add="SomeUserAgent"}
That method is not really useful for this case. Microsoft has talked about an AppID-based allow list, but I cannot find any clear working documentation or PowerShell example for creating an allow list based only on AppID / Client ID.
The EWS Usage Report in the Microsoft 365 admin center gives us AppIDs, but not always friendly app names. I can map some AppIDs manually through Entra Enterprise Applications / App registrations, but the missing piece is:
How do we actually allow-list EWS access by AppID only?
Questions:
- Is the AppID-based EWS AllowList available in Exchange Online yet?
- If yes, what is the exact PowerShell command/property to configure it?
- If it is not available yet, is Microsoft still planning to release it before October 1, 2026?
- Does setting only EWSEnabled=$true prevent Microsoft from auto-disabling EWS, or is the AppID AllowList also required to avoid that?
- After October 1, 2026, does
EWSEnabled=$truemean “EWS is enabled for all apps”, or only “EWS is enabled for allow-listed AppIDs”?
I’m trying to document this properly internally and avoid making assumptions based on vague Microsoft wording. Right now the public communication seems to say that EWSEnabled=True + AppID AllowList is required, but I cannot find a real working AppID allow-list configuration method yet.
Has anyone received a clear answer from Microsoft support/product group or successfully configured this already? According to a Microsoft article that was released early 2026 they were going to release a new allow-list (in "early 2026) where you could configure the list based ONLY on the AppID, but I can't find ANY information as to when or IF it's released already...
Thanks in advance!
SVD_NL@reddit
Only null values will be overridden, if it's manually set to true it will remain as true. (This is usually the case with exchange, if a value is not set manually, it'll fail over to the default value, and they just change the default value).
https://techcommunity.microsoft.com/blog/exchange/exchange-online-ews-your-time-is-almost-up/4492361 see the table on this page. Very useful info, wasn't very easy to find for some reason.
Also note these questions on that same page:
hehe123exde@reddit (OP)
Thanks for the thorough reply.
So, correct me if I'm wrong. Since my org. can't create an allow-list as of today, Microsoft will create an automated allow-list for us provided that we have set the 'EWSEnabled = True" in time?
I feel like I've been walking around in circles on this topic with all the different sources and articles that I've read... :')
SVD_NL@reddit
Yeah it's typical Microsoft communication...
These deprecations are always messy, timelines constantly change, and it's not unheard of for them to enforce a feature before they finish admin controls for it. (Not too long ago they forced indirect resellers to enforce a certain security posture for their customer tenants. The page where we can actually see the status, which was already finished for direct resellers, was only available to us a few months after they "started enforcing" it.)
I can't find anything about that allow list being added, the Exchange Online Powershell module doesn't mention it being added, so i'm assuming it's not released yet. ("early 2026" is relative i guess).
So from that article, i'd infer that if you set EWSEnabled to true, it will not include you in the scream tests, and it will automatically add the allow lists for you. "based on usage" is also pretty vague.
I guess the best you can do is hope that the information they provided is accurate, and keep monitoring their communication around the subject.
hehe123exde@reddit (OP)
Yeah I feel like Microsofts way of communicating very often is very vague.
The allow-list that they supposedly are going to add is mentioned in the article that you sent.
"How will EWS be disabled?
We’ll disable EWS tenant-by-tenant using the EWSEnabled property, which supports three values: True, False, and Null (the default today). A new feature arriving in early 2026 will allow admins to define an AppID Allow List. When enabled, only apps on that list can access EWS."
But like you said, the best way to go for us is to just set the "EWSEnabled = $true" and hope for the best while the apps using EWS gets migrated from EWS. The irony in all of this is that some apps that use EWS seem to still be Microsofts own apps even though this deprecation has been in the loop for a long time...<.<
Again, thank you for the help and clarity on the matter!