An October failure does not prove its cause
A calendar synchronization or business application failure may involve Exchange Web Services. Before changing settings, confirm the API being called, target mailbox, and returned error. EWS retirement applies to Exchange Online; this schedule does not automatically disable on-premises Exchange Server EWS.
Disablement starts rolling out in October 2026, with complete disablement announced for April 2027. Behavior depends on the phase reached by the tenant. Review its Message center and service health rather than assuming every tenant changed simultaneously.
Capture evidence before enabling anything
Record UTC time, application and version, owner, tenant, mailbox, App ID, and failing operation. Ask the vendor whether the component still uses EWS even if it authenticates through OAuth. OAuth does not turn an EWS API into Microsoft Graph.
Preserve HTTP status, request identifier, and approved diagnostic headers. Do not export Authorization tokens, cookies, secrets, or message contents into a public ticket. A sanitized capture is often sufficient to open a vendor case.
Compare working and failing scenarios: same application with another mailbox, or another operation on the same mailbox. Avoid bulk retries that create noise or duplicates.
Inventory actual dependencies
In the Microsoft 365 admin center, open Reports, Usage, Exchange, then EWS usage. Review App ID, SOAP actions, and last activity. Available windows are 7, 30, or 90 days; aggregation is weekly and reporting can lag by up to ten days. It is not a real-time incident log.
Cross-check the report with owners, scheduled jobs, connectors, and backup or migration software. No recent activity does not prove a monthly job is abandoned. Record criticality, required mailboxes, available Graph-based version, and retirement deadline for each dependency.
Understand the two application lists
EwsAllowedAppIDs uses application identifiers. The older EwsAllowList and EwsBlockList use User-Agent strings. Do not paste a User-Agent into the App ID list. These controls can apply together.
Under retirement behavior rolling out from October, EwsEnabled=True with an empty App ID list no longer means unrestricted access: application EWS calls are blocked. A populated list limits access to approved applications; EwsEnabled=False blocks at organization level. Mailbox enablement does not bypass that block.
Microsoft announced telemetry-based list preparation for some tenants. An existing list is not an inventory approved by your team: review each entry and owner. Do not delete a customer-managed list in an attempt to trigger automatic population.
Read-only PowerShell collection
Use a supported ExchangeOnlineManagement version and an identity with the RBAC read roles required by these commands. Microsoft 365 report permissions are separate; prefer an appropriate read role. Do not grant Global Administrator merely to collect settings.
RetrieveEwsOperationAccessPolicy is needed to retrieve the App ID list. If the parameter is absent from the session, check module, Exchange Online connection, and permissions before concluding the list is empty. This example targets a fictional mailbox and changes no settings.
# READ ONLY: Exchange Online; fictional mailbox
Connect-ExchangeOnline -ShowBanner:$false
Get-OrganizationConfig |
Format-List EwsEnabled,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockList
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsAllowedAppIDs
Get-CASMailbox -Identity 'integration@contoso.com' |
Format-List EwsEnabled,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockListInterpret denial without hiding another failure
Inspect X-EWS-Policy-Reason when present: Microsoft distinguishes EWS disablement from policy blocking. The latter alone does not distinguish App ID from User-Agent restrictions. HTTP 403 by itself does not prove EWS retirement caused the failure.
If policies do not explain the failure, inspect application certificate expiry, consent, mailbox authorization, token audience, and Entra logs. For HTTP 429, handle throttling according to API guidance rather than enabling EWS as a remedy.
Fictional example: a room integration is denied after App ID enforcement reaches the tenant. Its approved application is missing from the list. Another listed integration also fails because its User-Agent does not satisfy an existing policy. These incidents require different corrections.
Temporary exception: a governed change
Change: if a legitimate dependency cannot migrate immediately, document its validated App ID, accessible mailboxes, owner, exception expiry, and replacement version. The App ID list does not grant permissions and does not by itself restrict an application to one mailbox.
Before any Set-OrganizationConfig command, preserve existing values and review the intended outcome. Manage EwsAllowedAppIDs without overwriting already approved applications. Organization-level enablement can restore several allowed applications: it is not a change confined to a pilot mailbox.
Do not deploy an automatic global re-enablement script. Have an authorized RBAC identity perform the change in an approved window. Plan positive and negative tests, then reread configuration. List caching can delay effect for up to 24 hours; avoid successive contradictory changes.
Migrate functions, not merely the URL
Microsoft Graph is not a transparent SOAP replacement. Map each EWS operation to documented APIs: reading, sending, calendars, attachments, notifications, and synchronization. Separate delegated and application permissions, then restrict scope to actual requirements.
Verify capabilities actually available for your cloud and vendor version. A roadmap target is not an availability guarantee. Some scenarios have no equivalent; generic public-folder operations in particular require another strategy.
For commercial software, obtain a supported version and migration plan from the vendor. Check Exchange Online licensing, product costs, and rights required for each scenario; do not assume an extra license extends EWS. Microsoft Graph does not provide universal access to on-premises Exchange mailboxes.
Pilot, validation, and exception removal
Test with fictional data: a test folder, shared calendar if needed, notifications, and error handling. Verify an out-of-scope mailbox remains inaccessible. For sending, use approved test recipients and avoid running two engines that create duplicates.
Preserve synchronization checkpoints, monitor errors and queues, then cut over a pilot group. Rollback to the old version must be time-limited and remains subject to EWS restrictions: it cannot bypass final disablement.
After migration, remove the unnecessary exception and obsolete permissions or secrets through change control. Recheck infrequent jobs before closing the case. Microsoft 365 troubleshooting can help sort these dependencies; this guide does not replace a full assessment.
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →