EWS retirement in Exchange Online: find EWS apps and set EWSAllowedAppIDs

To keep critical applications working while Microsoft disables Exchange Web Services (EWS) in Exchange Online, identify the apps that still call EWS, put their Microsoft Entra application IDs in the tenant-level EWSAllowedAppIDs list with Set-OrganizationConfig, and then set EWSEnabled to $true. Since October 2026, EWSEnabled = True with an empty list blocks all EWS traffic, so the list is what keeps approved apps alive. This buys time only until April 1, 2027, when EWS is switched off for every tenant and the apps must already be on Microsoft Graph.

Who this is for and what you will have

This guide is for Exchange Online and Microsoft 365 administrators who own the tenant configuration and need to stop the EWS retirement from breaking line-of-business integrations, backup products, migration tools or hybrid features. At the end you will have:

• A list of every application that called EWS in your tenant, with its App ID, the SOAP actions it uses and its owner.
• A decision for each app: allow temporarily, migrate to Microsoft Graph, or retire.
• An EWSAllowedAppIDs list that contains only the apps you approved, with EWSEnabled set to True.
• A way to add or remove App IDs later without wiping the list, and a troubleshooting routine for apps that return HTTP 403.

How the EWS retirement works

Microsoft announced in 2018 that EWS would receive no more feature updates and in 2023 that it would be disabled in Exchange Online in October 2026. The retirement applies to Microsoft 365 and Exchange Online only; EWS in Exchange Server on-premises is not changing.

Microsoft controls the shutdown with the existing organization setting EWSEnabled, which can be True, False or Null (the historical default), together with the new EWSAllowedAppIDs AppID allow list. The behavior after the October 2026 change reaches a tenant is:

Key dates and rules from the Exchange Team announcements:

• From October 1, 2026, tenants that still have EWSEnabled at Null see it changed to False as the rollout reaches them. The exact timing depends on when the rollout reaches your tenant.
• Tenants that set True with a list by the end of September 2026 were excluded from the automatic change to False. Microsoft honors a True value that was set before it starts changing Null values.
• If EWS is blocked and you still need it, you can set EWSEnabled back to True with a list, but Microsoft notes there will be a service interruption until you do. Setting it back to Null with PowerShell also re-enables EWS without restrictions until the final shutdown, and the list is ignored in that state.
• On April 1, 2027, EWS is fully disabled and the ability to change EWSEnabled is removed. There are no extensions.

Microsoft also pre-populates the list for tenants that have not created one. For tenants with EWSEnabled = True, it does this shortly before the logic change, based on the previous 60 days of usage. For tenants left at Null, it happens a few days before the value is changed to False. Because a 60-day window can miss jobs that run quarterly and can include apps you no longer want, Microsoft recommends that you create the list yourself. Once you create your own list, the automated process does not change it.

Two related changes are worth knowing about. From October 2026 Microsoft also blocks EWS for users whose licenses don't include EWS rights, such as certain Kiosk and Frontline Worker licenses, so an integration can fail for those mailboxes even when the app is on your list. And in hybrid deployments, Microsoft states that between October 2026 and April 2027 you can enable EWS and add your dedicated hybrid app to EWSAllowedAppIDs to keep rich coexistence over EWS working; after April 2027, only Exchange Server SE (with the May 2026 update or later) supports Graph for rich coexistence calls to Exchange Online.

Prerequisites

• An account that can run Set-OrganizationConfig in Exchange Online PowerShell, and the ExchangeOnlineManagement module.
• Access to Reports in the Microsoft 365 admin center to read the EWS usage report, and the Global Administrator or Privacy Reader role to read the tenant-specific EWS messages in Message center.
• Read access to Microsoft Entra ID (for example through Microsoft Graph PowerShell with Application.Read.All) to turn App IDs into application names.
• A contact for every application owner and vendor. You will need them to confirm whether each app is still required.

Connect and check the current state first:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
 
Get-OrganizationConfig | Format-List EwsEnabled,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockList
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

The second command is required to see the list: EwsAllowedAppIDs is only returned when you add -RetrieveEwsOperationAccessPolicy, which Microsoft does for performance reasons. If EwsAllowedAppIDs already contains values and you did not create them, Microsoft has probably pre-populated the list for you, and the review below matters even more.

Step 1: Inventory EWS usage

Use the EWS usage report

The EWS usage report lists, for each application calling EWS, the SOAP actions it uses and the number of successful calls.

1. Open the Microsoft 365 admin center and select Reports. If you don't see it, select Show all first.
2. Select Usage, then under Reports select Exchange.
3. Select the EWS usage tab and choose a period of 7, 30 or 90 days. Use 90 days.
4. Select Export to download the data as a .csv file.

The usage details table has four columns: Application ID, SOAP Action, Call Volume and Last Activity date (UTC). Usage is aggregated weekly, and it can take up to 10 days for activity to appear, so an app that started recently or runs rarely may be missing. The report is a worldwide-cloud feature; tenants in other clouds should rely on the script described below.

Check Message center and the reporting script

Microsoft sends tenant-specific EWS usage summaries through Message center. Search Message center (Inbox and Archive) for "Update active Exchange Web Services Applications"; the Exchange Team notes that reading these messages needs the Global Administrator or Privacy Reader role. Microsoft started sending these messages to all tenants in late December 2025, and the Exchange Team notes that a tenant without such messages likely has no EWS usage.

For more identity context, the Exchange team published a script, Find-EwsUsage.ps1, in its Exchange-App-Usage-Reporting solution. It finds app registrations with EWS-related permissions, correlates them with sign-in activity and audit logs, and can produce a license report to spot Kiosk and Frontline users. It runs as its own app registration with read permissions for audit log queries, applications, sign-in logs and directory data; the post links to a readme that lists them and explains how to create the registration. Sort its output by last sign-in: recently active apps are your highest risk, and apps with no sign-in data need validation rather than being assumed safe.

Turn App IDs into names

The report shows GUIDs. Match them to service principals with Microsoft Graph PowerShell:

Connect-MgGraph -Scopes 'Application.Read.All'
 
$report = Import-Csv 'C:\Temp\EWSUsage.csv'
$appIds = $report.'Application ID' | Sort-Object -Unique
 
foreach ($id in $appIds) {
    $sp = Get-MgServicePrincipal -Filter "appId eq '$id'"
    [pscustomobject]@{
        AppId       = $id
        DisplayName = $sp.DisplayName
        Publisher   = $sp.PublisherName
    }
}

Check the exported column header in your file and adjust the property name if it differs. For Microsoft first-party apps, Microsoft points to the list "Commonly used Microsoft first-party services and portal apps"; anything still unknown can be searched by Application ID under Enterprise applications in Microsoft Entra ID.

Step 2: Decide what stays on EWS

Build a simple register with one row per App ID and agree a decision with each owner:

Microsoft states that if an app shows up in your usage report and you want to keep using it, you need to add it to the list. Treat every entry as a short-term exception with an owner and an end date. Microsoft's deprecation page also lists capabilities that will never get a Graph equivalent, including generic public folder CRUD, generic Microsoft 365 Group mailbox CRUD and Discovery Mailbox access, so apps built on those need a redesign, not a wait.

If you are planning a tenant-to-tenant move or a migration from another platform, ask the tool vendor explicitly whether it calls EWS against Exchange Online and which App ID it uses. The cross-tenant migration architecture guide covers the wider planning.

Step 3: Set EWSAllowedAppIDs and EWSEnabled

Write the list first, then set EWSEnabled to True. The value is a single comma-separated string of App IDs:

$allowed = @(
    'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee'   # Contoso backup service
    '11111111-2222-3333-4444-555555555555'   # Contoso HR integration
)
 
Set-OrganizationConfig -EwsAllowedAppIDs ($allowed -join ',')
Set-OrganizationConfig -EwsEnabled $true

Microsoft's cmdlet reference also shows both settings in one command:

Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,11111111-2222-3333-4444-555555555555"

Three rules apply to this parameter:

• It replaces the whole list. Any App ID you leave out of the command is removed.
• It applies only to direct EWS (SOAP) connections. Microsoft Graph and REST requests are not affected by it.
• Changes take up to 24 hours. Exchange Online servers refresh the list from an in-memory cache once a day, so an immediate test can still reflect the old list.

The cmdlet reference describes $null as removing all App IDs and the App ID restriction, but the Exchange Team's behavior table for October 2026 onwards treats EWSEnabled = True with an empty or null list as block all. Don't use $null as a cleanup step unless blocking EWS is the intent.

Check the user-agent policy as well

If your tenant also uses EwsApplicationAccessPolicy with EnforceAllowList, each request must pass both checks: its App ID must be in EwsAllowedAppIDs and its user agent must match EwsAllowList. Microsoft's example is Microsoft Teams: when the Teams App ID cc15fd57-2c6c-4117-a88c-83b1d56b4bbe is allowed, the user-agent allow list must still include Teams CalendarSkypeSpaces/1.0a$*+, otherwise the Teams calendar is blocked.

Mind the mailbox-level setting

Set-CASMailbox -EwsEnabled controls EWS per mailbox. Enabling EWS on a mailbox does not override an organization-wide disable, and a mailbox with EwsEnabled set to False stays blocked even when the app is on the list. Service accounts used by allowed apps need EWS enabled at both levels.

Step 4: Verify

1. Confirm the stored values:

Get-OrganizationConfig | Format-List EwsEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs
Get-CASMailbox -Identity svc-backup@contoso.com | Format-List EwsEnabled

2. Wait 24 hours, then run each allowed application through a normal job and confirm it completes.
3. Re-run the EWS usage report after a few weeks. Applications that you did not allow should disappear from the call volume, and allowed ones should keep reporting activity until they are migrated.
4. Keep watching Message center for the monthly EWS usage summaries.

Maintain the list without wiping it

Set-OrganizationConfig has no add or remove operation for this parameter, so read the current value, change it, and write the full value back. To add an App ID:

$current = Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
    Select-Object -ExpandProperty EwsAllowedAppIDs
$newAppId = '99999999-8888-7777-6666-555555555555'
 
$updated = @($current -split ',' | Where-Object { $_ }) + $newAppId |
    Sort-Object -Unique
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ',')

To remove one:

$current = Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
    Select-Object -ExpandProperty EwsAllowedAppIDs
$removeAppId = '99999999-8888-7777-6666-555555555555'
 
$updated = $current -split ',' | Where-Object { $_ -and $_ -ne $removeAppId }
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ',')

Export the value to a file before each change so you can restore it if a command goes wrong.

Troubleshooting blocked EWS requests

When an EWS access control blocks a request, Exchange Online returns HTTP 403 Forbidden with an X-EWS-Policy-Reason header. Ask the app owner or vendor for that header from their logs; it is more reliable than the response body.

HTTP/1.1 403 Forbidden
X-EWS-Policy-Reason: EWS is disabled for this user or tenant

"EWS is disabled for this user or tenant". The organization or mailbox EwsEnabled setting is blocking the call. Check both with Get-OrganizationConfig and Get-CASMailbox. Changing the App ID list does not help while EWS is disabled. If Microsoft's rollout changed your tenant from Null to False, set the list and then EWSEnabled to True.

"EWS is blocked by policy for this user or tenant". Either the App ID is not in EwsAllowedAppIDs or the user agent fails EwsApplicationAccessPolicy. The header does not say which, and passing one check does not bypass the other, so review both. If you just added the App ID, wait for the 24-hour refresh.

Everything broke after you set EWSEnabled to True. The list is empty or missing the app. Since October 2026, True with no list means block all. Populate the list.

An allowed app works for most users but fails for some. Check whether those mailboxes have EwsEnabled set to False, or whether the users hold Kiosk or Frontline licenses without EWS rights.

A plain 403 without the header. Microsoft notes that other access restrictions can also return 403, so a 403 alone does not prove the EWS controls caused it.

Checklist

• Exported 90 days of the EWS usage report and searched Message center for EWS usage messages.
• Every App ID resolved to an application name, owner and decision (migrate, allow temporarily, retire).
• EWSAllowedAppIDs written with your own list, including Microsoft first-party apps you still need.
• EWSEnabled set to True only after the list is populated.
• User-agent allow list (EwsAllowList) updated if EnforceAllowList is in use.
• Service account mailboxes have EWS enabled at mailbox level.
• Allowed apps tested 24 hours after each change.
• A Graph migration date before April 1, 2027 agreed for every remaining entry.

EWS is one of several legacy mail paths being closed this year. The same tenant review is a good moment to check apps that send mail with Basic authentication over SMTP, covered in SMTP AUTH with OAuth client credentials.

References

• Deprecation of Exchange Web Services in Exchange Online
• Exchange Online EWS, Your Time is Almost Up
• Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement
• Take control of your EWSAllowedAppIDs list before EWS access changes
• Notes From the Field: Finding and Remediating EWS App Usage Before Retirement
• Exchange Web Services (EWS) usage report
• Control access to EWS in Exchange
• Set-OrganizationConfig
• Get-MgServicePrincipal