Microsoft Clamps Down on EWSEnabled Tenant Setting to Enable Exchange Web Services

Exchange Web Services (EWS) is scheduled for retirement on October 1, 2026. Although October 2026 is still 19 months away, retiring an API that was heavily used at one time requires time and patience to expunge every trace of the API. Microsoft has already removed EWS from clients like Outlook for Mac and is working through the steps to remove EWS from its other applications.

Independent software developers have received clear directions that they should replace EWS with the Microsoft Graph. The acknowledged gaps in functionality that currently exist in the Microsoft Graph are being closed, with the latest example being the introduction of the Exchange mailbox import-export API (see MVP Glen Scales’ commentary on the new API).

Now Microsoft is preparing for the final removal by clamping down on the organization setting which controls whether EWS is enabled or disabled within a tenant. In a February 20, 2025 post, Microsoft says that the organization-level EWSEnabled flag will play a more significant role than it has done in the past. The change is being made to make it easier for Microsoft to disable EWS across Microsoft 365.

Enabling EWS for a Mailbox

In the past, it was sufficient for administrators to set the EWSEnabled flag for a mailbox to $true to allow the mailbox to use EWS in apps and clients. This condition existed because the mailbox setting has precedence over the setting in the Exchange Online organization configuration and, by default, the organization setting is null.

Get-OrganizationConfig | Select-Object EWSEnabled

EwsConfig
---------

The only time administrators set the organization-level EWSEnabled setting is if they wanted to block EWS throughout the tenant. Usually, this need didn’t arise because it was sufficient to set EWSEnabled to $true on the mailboxes that needed access to EWS. For instance, because EWSEnabled is $true for the James Ryan mailbox, that mailbox can use EWS even though the organization setting is null.

Get-CasMailbox -Identity James.Ryan | Select-Object EWSEnabled

EwsEnabled
----------
      True

The Big Change

What’s changing is that Exchange Online will only permit a mailbox to use EWS if both the organization and mailbox settings are $true. The old situation where the default null value at the organization level is sufficient to allow access is no longer in force. Tenants that want to use EWS to the bitter end must now explicitly enable EWS in the Exchange Online organization configuration:

Set-OrganizationConfig -EWSEnabled $true

You can see where Microsoft is going. By forcing the relatively small number of tenants to explicitly allow EWS by updating the organization configuration, Microsoft is preparing for the big turn-off when they will update the organization configuration to set EWSEnabled to $False and block any further changes to the setting. It’s an elegant and effective way of making sure that the turnoff happens on October 1, 2026.

Problems might arise for tenants that have the organization configuration set to $false already and still have a small number of mailboxes enabled for EWS. The precedence enjoyed by the mailbox setting allows these mailboxes to access EWS, but once Microsoft removes the precedence, those mailboxes will lose the ability to use EWS.

The solution is to update the organizational setting back to $true. It might seem counterintuitive to allow EWS for the tenant, but the existing access setting for mailboxes will then kick in and only those mailboxes enabled for EWS can continue making EWS API requests.

Check Mailboxes Enabled for EWS

Given that we’re on the final glidepath to the retirement of EWS, it’s a good idea to validate that the set of mailboxes enabled for EWS declines over time. That way you’ll know if the dependency on EWS within the organization is reducing and understand why some mailboxes continue to need EWS. To help, I put together an Azure automation runbook that looks for EWS-enabled mailboxes and emails the details using Exchange High Volume Email (HVE). The email (Figure 1) serves as a nagging reminder for tenant administrators to minimize the set of mailboxes enabled for EWS. Using Azure Automation means that it’s easy to schedule the job to run weekly (or whatever period makes sense) as the clock ticks down to October 1, 2026.

You can download the code from the Office 365 for IT Pros GitHub repository. See this article for more details about running Exchange Online PowerShell in Azure Automation, and this article about using HVE in Azure Automation.

I chose HVE rather than using the Send-MgUserMail cmdlet from the Microsoft Graph PowerShell SDK because there’s an odd bug that stops the latest version of Exchange Online PowerShell module working in version 7.2 runbooks. My Graph setup is based on PowerShell 7, so mixing and matching Exchange Online and the Graph SDK doesn’t work as smoothly as it should for now. Microsoft is aware of the issue. I believe it will be fixed in the next release.

You don’t need to use Azure Automation as a standard script will do the job too. It just seems to make sense to me to have Azure Automation run the job without human intervention. After all, I might forget to check…