Take control of your EWSAllowedAppIDs list before EWS access changes

I see that post Sept 30th, the value for EwsOperationAccessPolicyPopulated has been set to True, however when I run 

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object EwsAllowedAppIDs OR 

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs, we dont' see any appID listed.  Is there a another method to confirm if we haven't manually popluated them?

Hi Nino_Bilic​ Greg Taylor - EXCHANGE​ 

Could you differentiate what's the difference between these two commands? which one Microsoft would be looking on 1st October 2026 on AllowList?

Get-OrganizationConfig | Format-List EwsAllowedAppIDs

EwsAllowedAppIDs :(Blank)

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs

d3590ed6-52b3-4102-aeff-aad2292ab01c, b52893c8-bc2e-47fc-918b-77022b299bbc, a672d62c-fc7b-4e81-a576-e60dc46e951d, f8d98a96-0999-43f5-8af3-69971c7bb423

Thanks

Ismail khan

After successfully configuring EwsAllowedAppIDs and switching to EnforceAllowList, I noticed that Teams and Outlook calendar integration stopped working.

My current configuration is:

EwsEnabled : True

EwsAllowedAppIDs : <AppID1>,<AppID2>,<AppID3>,<AppID4>

EwsApplicationAccessPolicy : EnforceAllowList

EwsAllowList : {SkypeSpaces/, Teams/, MicrosoftNinja/, SchedulingService}

EwsBlockList :

The App IDs above represent the third-party applications in my environment that still require EWS access.

While the documentation does an excellent job covering how to identify and permit third-party applications, it is less clear which Microsoft services still require EWS access when moving to an allow-list model.

It would be helpful if Microsoft could provide additional guidance covering:

Microsoft-managed services that still depend on EWS

Recommended EwsAllowList entries for Microsoft 365 workloads

Requirements for Teams calendar integration

Requirements for Outlook calendar and scheduling functionality

Any known dependencies for Scheduling Assistant, Teams meeting scheduling, and related services

As organisations move to EnforceAllowList, understanding which Microsoft services require EWS exemptions will help avoid unexpected loss of functionality while still reducing the EWS attack surface.

Has Microsoft published, or does it plan to publish, a definitive list of Microsoft workloads and user-agent strings that should be permitted when implementing EWS allow-listing?

Make sure you don’t overlook the need to add your Dedicated Exchange Hybrid App into your EWSAllowedAppIDs list.

While reviewing our EWS usage reports in preparation for enabling EWS allow‑listing, we discovered that the Dedicated Exchange Hybrid App — the service principal Microsoft instructs hybrid organizations to deploy — is still actively using EWS for core coexistence features (free/busy, MailTips, availability lookups).

Microsoft’s documentation mentions transitioning hybrid features to Graph, but no Graph permission list, migration steps, or parity guidance has been published, and the Dedicated Hybrid App continues to rely on EWS in production environments.

If EWS is restricted without adding this AppID to your allow‑listing, hybrid coexistence will break.

Because this app is not labeled or named in a recognizable way in the Enterprise Applications list, I wanted to remind everyone: don’t forget to include it if you’re running a hybrid Exchange environment. 😊

I have a question about the automatic population behavior of EwsAllowedAppIDs.

I first set:

Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "<some App IDs>"

Later, because I cannot confidently identify every application in my tenant that still uses EWS, I remove the manually configured list:

Set-OrganizationConfig -EwsAllowedAppIDs $null

When the October 2026 enforcement logic reaches my tenant, will Microsoft automatically populate EwsAllowedAppIDs based on my tenant’s recent EWS usage?

Or, because I previously configured the list manually, will it remain customer-managed and therefore not be auto-populated even after I set it to $null?

I would appreciate clarification, as I need to avoid disrupting existing EWS workloads that may not yet be fully inventoried.

Has anyone seen MSFT auto-populate the EWSAllowedID yet?

Quick reality check before I continue sacrificing goats to the Microsoft feature rollout gods.

I came across a Reddit post claiming that write access to EwsAllowedAppIDs is still gated for some tenants. Is that actually true, or is Reddit doing what Reddit does best? https://www.reddit.com/r/PowerShell/comments/1uxeryd/ewsallowedappids_why_no_work/

So before I spend another hour questioning my life choices:

• Is EwsAllowedAppIDs still being enabled tenant-by-tenant or blocked during the rollout?
• Does the parameter only appear once Microsoft has blessed your tenant?
• Or am I being a complete noob and missing something painfully obvious?

Drafted with AI tag: fun and jokey :D

PS 7.6.6 & EXO Module 3.10.1 

Set-OrganizationConfig: A parameter cannot be found that matches parameter name 'EwsAllowedAppIDs'.

get-help -name Set-OrganizationConfig -Parameter EwsAllowedAppIDs

Get-Help: No parameter matches criteria EwsAllowedAppIDs.

So i've been working on EWS app retirement for a while now in preparation.    I'm planning to set EWSEnabled to True.   I'm happy that the auto populated list Microsoft create will cover what I have left.    Will EWS remain enabled for these apps until April 2027? 

The_Exchange_Team​  

If we don't define the EWSAllowedAppIDs manually, when will it be created (so we can check if the entries are correct). Will that be on October 1ste?

Nevermind, I see that the comments on the other article are more active, so asked the question in 

Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement | Microsoft Community Hub

Hi all
Can someone telling us the insights behind the MS AppID "d3590ed6-52b3-4102-aeff-aad2292ab01c". In https://learn.microsoft.com/en-us/power-platform/admin/apps-to-allow we can find the Description "Microsoft Office". This AppID is listed in most of our customer tenants M365 EWS usage Report. How do we get rid of this MS App from EWS? Is legacy Outlook the originator? Which function of MS Office will no longer functional after we set EWSEnabled to $false?
Best regards, Marco