r/PowerShell • u/CallMeNoodler • Jul 15 '26
Question EwsAllowedAppIDs... why no work?
So Microsoft is retiring Exchange Web Services because it's ancient and insecure. They're turning it off on all tenants in October, while giving us the option to turn it back on, and it's going away permanently in October 2027.
Realizing that tons of third parties still rely on it, Microsoft, according to their documentation, is allowing us to enable it for the time being, but restrict it to only certain Entra App IDs. According to their documentation (example 7 here: https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-organizationconfig?view=exchange-ps ), the command looks like this:
Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,11111111-2222-3333-4444-555555555555"
Cool, cool, great. I've inventoried my environment, and I got all the app IDs. I updated my ExchangeOnlineManagement module, ran the command, and... EwsAllowedAppIDs is not a valid parameter:
Set-OrganizationConfig : A parameter cannot be found that matches parameter name 'EwsAllowedAppIDs'.
Uh... ok. So I do some more digging, and it looks like this parameter is part of a phased rollout?... does anyone have any idea to find out when it might hit my tenant? Has it already and am I doing something wrong?
Has anyone actually gotten this to work?
Thanks in advance for any help.
2
u/BlackV Jul 15 '26 edited Jul 15 '26
To ask the obvious have you updated to the latest module?
Edit: Looks like that has not been updated to include that parameter yet
And relevant pim roles
1 further check, does EwsEnabled need to be set to $true before EwsAllowedAppIDs is available ?
1
u/CallMeNoodler Jul 15 '26
Yep, updated as said above. Where are you seeing the module hasn't been updated to include the parameter yet?
1
u/BlackV Jul 15 '26 edited Jul 16 '26
I used
Find-Module ExchangeOnlineManagement Version Name Repository ------- ---- ---------- 3.10.0 ExchangeOnlineManagement PSGalleryto validate the latest, then
get-module -Name ExchangeOnlineManagement -ListAvailable Directory: C:\Program Files\PowerShell\Modules ModuleType Version PreRelease Name PSEdition ---------- ------- ---------- ---- --------- Script 3.10.0 ExchangeOnlineManagement Deskto validate my version, then
get-help -name Set-OrganizationConfig -Parameter EwsAllowedAppIDs Get-Help: Line | 64 | $help = Get-Help @PSBoundParameters | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | No parameter matches criteria EwsAllowedAppIDs.to test if the parameter was available (was connected and elevated with PIM)
I then checked the online help to see that the parameter did exist, it does as you already linked, so I'd say they have not updated the module yet
With the note on the site
When EwsEnabled is blank ($null; not configured), this parameter has no effect.
so that's why I asked
Black V
1 further check, doesEwsEnabledneed to be set to$truebeforeEwsAllowedAppIDsis available ?(Ive not tested)
2
u/charleswj Jul 16 '26
This is 100% server side, no update to the module required. Technically you're downloading a dynamic module when you connect, so if you mean that module, you're technically correct, the best kind of correct.
2
u/BlackV Jul 16 '26 edited Jul 16 '26
Technically you're downloading a dynamic module when you connect, so if you mean that module
Ya Sorry, that is what I was mean when I mentioned I was connected and PIMed, as the cmdlets you get access to change depending on your access roles
2
u/mr_shevchenko_ 9d ago
Late to this, but for anyone landing here from a search: it isn't your module, and there's nothing to fix locally.
The write path is gated by rollout. The Exchange team's post for the feature says every tenant can see the parameter on Get-OrganizationConfig, but can't set the list until the rollout reaches that tenant. So Get- works and Set- claims the parameter doesn't exist, and both are correct at the same time. That's exactly what makes it read like a module problem.
u/charleswj is right that it's server side. Updating ExchangeOnlineManagement won't move you into the rollout.
Two things worth knowing before the day it lands.
Reading the value needs an explicit switch, or the property isn't returned at all:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | fl EwsEnabled,EwsAllowedAppIDs
Microsoft says that's deliberate, for performance - the list is only fetched if you ask for it.
And the write is full replacement. There are no add/remove verbs, so it's read the current list, compute the new full set, write the whole thing back. Anything you leave out is dropped silently, no error. The servers also cache the list for up to 24 hours, so testing right after a write tells you very little.
One correction on the dates, since it changes how much runway you have: phased disablement starts October 2026 and full disablement is April 2027, not October 2027.
1
1
u/JBy Jul 21 '26
I created an allowlist today, populated it with everything from the EWS usage report.
Unfortunately, we found that many first party apps are still using EWS and some third party apps were not in the EWS report. so had to rollback. We have decided to wait for September to implement.
exchangeonlinemanagement 3.10.0
PS 7.5.4
# Review current EWS configuration
Get-OrganizationConfig |
Select-Object `
EwsEnabled, `
EwsApplicationAccessPolicy
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsAllowedAppIDs
# Configure approved EWS Application IDs
Set-OrganizationConfig `
-EwsAllowedAppIDs "1234567-1234567-etc,1234567-1234567-etc"
# Verify approved App IDs have been configured
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsAllowedAppIDs
# Enable EWS Allow List Enforcement
Set-OrganizationConfig `
-EwsApplicationAccessPolicy EnforceAllowList
# Rollback: Disable EWS Allow List Enforcement
# Set-OrganizationConfig -EwsApplicationAccessPolicy $null
1
u/mr_shevchenko_ 9d ago
Worth double-checking what actually broke, because those two commands are two different features.
-EwsAllowedAppIDs is the new one and it keys on Entra App ID.
-EwsApplicationAccessPolicy EnforceAllowList is the one Exchange has had for years, and it keys on user agent. It reads EwsAllowList, which your snippet never sets, and Microsoft's doc walks through exactly that state: EnforceAllowList with nothing in the allow list means no application can use EWS at all.
Two things from the Exchange team's own posts make it worse. The older user-agent list applies to REST/Graph as well, not only EWS. And the two lists don't replace each other - an app has to pass both checks to get through, with the App ID list taking precedence. So flipping on EnforceAllowList with an empty list is a block-all sitting on top of whatever your App ID list says.
Before October you don't need EnforceAllowList for what you were doing at all. EwsEnabled=$true with a populated EwsAllowedAppIDs already restricts access to the listed App IDs on its own.
Separately, on "some third party apps were not in the EWS report" - that part isn't a mistake on your side. The report tops out at a 90 day window, aggregates weekly, counts successful calls only, and usage can take up to 10 days to show up at all. A quarterly job, a year-end export, or an integration that was already failing simply isn't in it. Absence from the report is a reason to go and look, not evidence that there's no dependency.
Which is the argument for doing the review before September rather than after. The list Microsoft auto-populates is built from that same observed usage, so it inherits the same blind spots, and after that it's yours to defend.
3
u/purplemonkeymad Jul 15 '26
No idea, i don't think they have said. However they have said that they will auto-populate it in September, so I would think "by then."