Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsEwsAllowedAppIDs is an Exchange Online, organization-wide allow list for application IDs that may make direct EWS SOAP requests. It only takes effect when the organization’s EwsEnabled setting is $true; it does not grant OAuth permissions or control Microsoft Graph. The Exchange Online administrator configures the list, while each integration’s owner should identify and validate its Entra application ID.
There is an important timing change: Microsoft’s retirement guidance says it changed EwsEnabled from $null to $false on October 1, 2026, for tenants that had not opted in. Check your tenant’s current settings rather than assuming EWS remains enabled.
How EwsAllowedAppIDs controls EWS access
Microsoft documents EwsAllowedAppIDs as a parameter of Exchange Online’s Set-OrganizationConfig cmdlet. It takes one or more Azure AD (now Microsoft Entra) application IDs in GUID format. With EwsEnabled set to $true, only applications whose IDs are listed are allowed to access EWS. Applications not listed are blocked. See Microsoft’s Set-OrganizationConfig reference.
EwsEnabled = $true: EWS is enabled, subject to the application-ID policy.EwsEnabled = $false: EWS is blocked for all applications, regardless of the list.EwsEnabled = $null: the cmdlet reference saysEwsAllowedAppIDshas no effect. Microsoft’s October 2026 retirement action means affected tenants should inspect their current value instead of relying on the earlier null behavior.
Separate multiple application IDs with commas. Setting EwsAllowedAppIDs to $null removes this app-ID restriction; it does not enable EWS if EwsEnabled is false.
#1 Best Overall
Which requests it covers—and which it does not
This setting applies only to direct EWS SOAP connections. Microsoft explicitly says it does not affect Microsoft Graph API requests or the REST endpoint. It is therefore not a general Microsoft 365 API allow list. If an integration uses Graph rather than EWS SOAP, this setting does not govern its access.
EWS has another, distinct access control: EwsApplicationAccessPolicy, together with EwsAllowList or EwsBlockList, can evaluate user-agent strings. When both the application-ID policy and user-agent policy are configured, both must permit the connection. An application ID on the allowed list is not enough if the user-agent policy blocks the request. Microsoft describes these controls in its EWS access-control guidance.
Rank #2
Who should configure the list
Exchange Online tenant administrator
The tenant administrator owns the organization-wide setting and should assess it if the organization still needs EWS and wants to restrict EWS access to approved applications. Because the policy is organization-wide, changing the list can affect integrations used across the tenant. Read the existing value before changing it and preserve entries that remain necessary.
EWS integration and identity owners
Owners of EWS integrations, together with application or identity administrators, should identify the correct Entra application ID for each integration and confirm it before the Exchange administrator updates the list. An application’s display name is not a substitute for its application ID.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteAllow-listing an ID is not OAuth setup. An EWS application using OAuth must also be registered with Entra and granted the appropriate permissions. The permission model differs depending on whether the application acts for a signed-in user or runs as a background service; Microsoft explains the distinction in its EWS OAuth authentication guidance.
Mailbox administrators
Mailbox-level EWS controls may also need review. Microsoft documents Get-CASMailbox and Set-CASMailbox for mailbox settings, and Get-OrganizationConfig and Set-OrganizationConfig for organization settings. Organization-level EwsEnabled can block EWS across the organization regardless of mailbox-level settings. The controls and their scopes are described in Microsoft’s access-control guidance.
How to inspect and update EwsAllowedAppIDs
- Read the current organization policy. In Exchange Online PowerShell, run
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicyand inspectEwsAllowedAppIDs. Microsoft documents this retrieval switch for the configured app IDs; do not assume an ordinaryGet-OrganizationConfigoutput will always show the property. - Check whether EWS is enabled. Inspect
EwsEnabledas well as the allow list. A populated list does not enable EWS when the organization setting is$false. - Confirm the required IDs with integration owners. Verify each Entra application ID and determine which applications still need direct EWS SOAP access.
- Set the organization list deliberately. For example, run
Set-OrganizationConfig -EwsAllowedAppIDs "<app-guid-1>,<app-guid-2>", replacing the examples with verified GUIDs and retaining other required entries. - Verify the resulting policy. Retrieve the policy again with
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicyand check the configured IDs andEwsEnabledstate.
To remove only the app-ID restriction, use Set-OrganizationConfig -EwsAllowedAppIDs $null. Do this only when removing the restriction is intended; it does not override a disabled organization-level EWS setting.
What changed with Microsoft’s EWS retirement transition
Microsoft’s EWS retirement preparation guidance for Skype for Business Server hybrid says that on October 1, 2026, it automatically changed EwsEnabled from $null to $false for tenants that had not opted in. Since that date has passed, inspect the tenant’s present configuration before diagnosing or planning around EWS availability.
The same guidance describes a specific continuity case for Skype for Business Server hybrid: administrators were told to set tenant EwsEnabled to $true and allow both the deployment’s Skype for Business Server application ID and the Skype desktop client application ID. To find the server ID, Microsoft specifies Get-CsOAuthConfiguration | Format-List ServiceName. The desktop client ID shown in that guidance is d3590ed6-52b3-4102-aeff-aad2292ab01c. Follow the current guidance for the deployment and preserve existing required entries when changing the list.
Microsoft’s page also describes a later migration from EWS to Microsoft Graph before EWS is permanently retired, including an April 1, 2027 deadline for a Skype for Business Server update. That date is specific to the scenario in Microsoft’s guidance, not a general deadline for every EWS integration; consult the current documentation for the applicable retirement schedule.
Quick Recap
Diagnose an application that cannot connect
- Confirm the API path. Determine whether the client makes direct EWS SOAP requests. Graph and REST requests are outside
EwsAllowedAppIDs. - Check organization EWS state. If
EwsEnabledis$false, changing the app-ID list will not restore EWS access. - Check the exact application ID. Verify the GUID used by the integration against the IDs returned by the policy retrieval command.
- Check user-agent controls. If an application-ID policy and user-agent policy are both present, both must allow the connection.
- Check mailbox-level controls and OAuth separately. Organization policy, mailbox settings, Entra registration, and OAuth permissions are distinct checks; an allowed ID alone does not satisfy the others.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
