As customers prepare for the final phase of Exchange Web Services (EWS) retirement in Exchange Online, many are asking the same practical question: how can I prove that EWSAllowedAppIDs is working be...
Updated Sep 09, 2026
Version 2.0
Blog Post
Nino_Bilic What if we do not have test tenant to test this scenario?
We simply use Set-Organizatoinconfig -EWSTrue = True and Set-ewsallowedappid -Appid (Appname) to allow.
I see EWSAllowList and EWSBlocklist is null in my org and I believe this has nothing to do with this EWS excercise for now.
- Nino_Bilic
Microsoft
You are correct that EWSAllowList and EWSBlocklist are really not related to the overall EWS deprecation (this is really a feature to filter EWS requests based on user agents - there is nothing new here).
The safest way to test AppID allow list is to:
- Have EWSEnabled = Null (this allows all EWS and ignores the AppID allow list)
- Set your AppID allow list using EWSAllowedAppIDs; verify it was set as you intended
- Let that sit for 24 hours (this takes 24 hours)
- Change EWSEnabled = True (this will "enable" your AppID allow list to take effect)
- Let that sit for 1 hour (this takes up to an hour to take effect)
- Check if everything works as expected
If yes = good. If no = set EWSEnabled = Null. This change takes max 1 hour and will then start ignoring your AppID allow list. Then, you can figure out what is going on with your AppID allow list, modify it or what not.
Just remember:
- AppID allow list (EWSAllowedAppIDs) = 24 hours for changes to really take
- EWSEnabled = 1 hour for changes to take
- Before October comes, if you need EWS to keep working, your EWSEnabled setting should be set to True. If it is set to Null, starting October, we will be changing Null to False. By having it set to True, you are guaranteeing that we do not turn your EWS off.
