Blog Post

Exchange Team Blog
4 MIN READ

The way to control EWS usage in Exchange Online is changing

The_Exchange_Team's avatar
Feb 20, 2025

In our ongoing commitment to enhance the security and control mechanisms of Exchange Web Services (EWS), we are announcing a significant change in the behavior of the EWSEnabled tenant-wide switch in Exchange Online. This modification provides a more robust framework for managing EWS access within organizations, ensuring both flexibility and security, and is necessary as we continue to work on our plan to disable EWS starting October 2026.

Current Behavior

The EWSEnabled flag can be set at both the tenant (organization) level and the user (mailbox) level. Currently, when the flag is set to true at the user level, it takes precedence over the organization-level setting. If the setting is Null, it means the setting is not enforced at that level. If Org and user-level are both Null, the default behavior is to allow. This hierarchical structure means that if the organization-level flag is set to false, but the user-level flag is set to true, EWS requests from that user are still allowed. In other words:

Organization Level

User Level

EWS Requests

True or <null>

True or <null>

Allowed

True or <null>

False

Not Allowed

False

True

Allowed

False

False or <null>

Not Allowed

This approach has led to inconsistencies and security concerns. It can be challenging for administrators to ensure uniform policy enforcement across their organization, particularly in large and complex environments.

New Behavior

To address these issues, we are altering the behavior so that EWS will only be allowed if both the organization-level and user-level EWSEnabled flags are true. Here's a simplified view of the new logic:

Organization Level

User Level

EWS Requests

True or <null>

True or <null>

Allowed

True or <null>

False

Not Allowed

False

True or <null>

Not Allowed

False

False

Not Allowed

In short, EWS will be permitted only if both the organization and user-level allow it. This change ensures that administrators have better control over EWS access and can enforce policies more consistently across their entire organization.

This change will rollout worldwide starting April 2025.

Tenant-level setting

The first thing to check is your tenant setting. To do this, simply run this command in Exchange Online PowerShell

Get-OrganizationConfig | fl EWSEnabled
EwsEnabled :

If the EWSEnabled flag is empty (the default), or set to True – this change won’t affect you, but we still advise you read the per-user settings information below to make sure it matches your expected settings.

If your EWSEnabled flag is set to False, you might see some impact when we enforce this new logic change on your tenant unless you take action now. We encourage you to review the section below to ensure your per-user settings reflect your desired state for who can and cannot use EWS, and then proactively change the tenant wide switch to True to ensure uninterrupted access for users and apps.

User-level setting

As discussed earlier, even if your tenant-wide EWSEnabled switch has been set to False, it’s currently still possible to use EWS, if the per-user setting is set to True (default setting for every mailbox).

To check if EWS is Enabled or Disabled for a specific mailbox, you can run:

Get-CASMailbox User1| fl EWSEnabled
EwsEnabled : True

Does This Change Affect You?

We recognize that this change may impact tenants who have relied on the previous behavior. Specifically, if your organization-level flag is set to False, but you have user-level flags set to true, EWS requests will start to be blocked when this change rolls out, which was not the case before. Therefore, we advise you to review and adjust your settings to ensure continuity of service.

Going forward, if you want to restrict EWS to specific mailboxes (and we think this is a good idea broadly speaking), you need to ensure those are the only mailboxes with the mailbox specific property set to True, and ensure everyone else has it set to False, and then you can set the Org Wide setting to True.

Conclusion

This change to the EWSEnabled tenant-wide setting represents our dedication to providing better administrative control and improving security within Exchange Web Services. We believe this change will lead to more consistent policy enforcement and a more secure environment for all users.

We encourage administrators to review their current settings and prepare for this update.

We have sent this information out to all tenants via the Message Center (MC1015893 or MC1015890, depending on the cloud you are in), but we’ve also sent out an additional post to tenants we see have the tenant wide switch set to False, but still have successful EWS usage too (meaning they likely have been using this switch in some way) - MC1015906.  

If you have any questions, please post them below and we’ll do our best to help.

Thank you for your continued partnership and commitment to enhancing the security and functionality of our services.

The Exchange Team

Updated Feb 26, 2025
Version 2.0
  • Dan_Snape's avatar
    Dan_Snape
    Steel Contributor

    I disagree that this makes management easier and gives more control. For an environment where I want it disabled by default, with the old method I could disable it at the tenant level to capture everyone, then enable it on individual mailboxes to allow. With the new experience, I now have to enable it at the tenant level, disable it specifically on every mailbox, and enable it for those few mailboxes I may want it enabled for. This also doesn't capture new mailboxes, where my understanding is the default setting at the mailbox level is Null (thus EWS will be enabled for all new mailboxes due to the tenant setting!).

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft

      Well, hmm. A few things:

      • The blog states that the default on the mailbox level is TRUE (not NULL)

      Today, therefore, unless the admin touched every mailbox to set it to FALSE on mailbox level we have the following situation:

      • The Admin sets the tenant to FALSE, thinking that this will do something (this is a deliberate action, presumably taken with a reason to want to block EWS for the tenant)
      • But because mailboxes have this set to TRUE, EWS keeps working for all the mailboxes, even though the Admin flipped the tenant setting to FALSE (presumably, this was done on purpose)
      • niehweune's avatar
        niehweune
        Brass Contributor

        Ok, makes a bit more sense that way, the default for mailboxes is indeed TRUE...

        But the tables in this post are confusing, since in practice no mailboxes have NULL for EWSEnabled (except apparently the Discovery Mailbox).
        Documentation for Set-CASMailbox doesn't even have $null as an option for -EWSEnabled (although apparently you can specify it and it is effectively set).

        Still, would make a lot more sense if the default on new mailboxes were set to NULL, i.e. 'take orgwide setting', a NULL on the orgwide setting would be equivalent to FALSE, and explicitly setting it on a single mailbox would mean 'override the orgwide setting'.

         

    • niehweune's avatar
      niehweune
      Brass Contributor

      Same reflection here, previously the most secure policy was to disable EWS orgwide and just enable it on the handful of mailboxes that really really needed it.

      With this change, if there's even a single mailbox still needing EWS for some reason, you are now forced to enable EWS orgwide and disable it on each individual mailbox (and don't forget to explicitly disable it when new mailboxes are created).

      Might be trivial if you have an org with a few 100 mailboxes, but in complex orgs with multiple admin tiers that's a different story.

      This actually will make it a lot harder to prepare for the decomissioning of EWS in 2026 (since people can and will forget to disable EWS).

      Would actually make a lot more sense if the default (null) orgwide setting would change to False and leave the user setting as it is (i.e. an override of the orgwide setting), since that would force people who just leave everything at the default to start thinking about this...