Exchange Online EWS, Your Time is Almost Up

One unresolved migration gap: access to the master category list of Microsoft 365 Group mailboxes. We have no confirmed Graph replacement for our EWS implementation.

• Graph has /users/{id}/outlook/masterCategories for user mailboxes, with application permissions.
• There is no documented Group equivalent. Our current route is EWS GetUserConfiguration ("CategoryList") on the Group mailbox.
• Microsoft Support tested the preview userConfiguration Graph API for us: it works on a user mailbox and fails on a Group mailbox.
• Our design change request (DCR 720928901, Microsoft Support case 2609230040001732) was closed on 3 November as not planned.

After EWS retirement, applications using this route need another way to retrieve the Group master category list, including its colours. This is one settings object per Group mailbox, not generic Group mailbox CRUD. Graph already serves this exact list for user mailboxes — why are Group mailboxes left out? And if it will not come to Graph, what supported migration path does the Exchange team recommend?

Feature request: https://feedbackportal.microsoft.com/feedback/idea/9bc115fa-51d8-f111-bda1-7c1e52baf49b

Hi Microsoft team,

I'm currently investigating the migration of an integration from Exchange Web Services (EWS) to Microsoft Graph and looking for clarification on the remaining parity gaps to help inform our technical design.

According to the parity roadmap referenced in the FAQ above, several capabilities, including Contact Lists, Additional Contact Properties and Notes, had target availability dates of Q3 2026.

As those dates have now passed, could the team provide an update on their current status and revised ETAs?

Our primary interest is Contact Lists, which we're investigating as a key dependency for our proposed design, and potentially Additional Contact Properties, depending on the functionality available.

With EWS disablement already underway and the final shutdown scheduled for 1 April 2027, we're trying to establish what functionality we can reliably plan around and whether there will be sufficient time for implementation, testing and migration.

I'd appreciate clarification on the following:

1. Contact Lists and Additional Contact Properties

• What is the current release status of each capability?
• When are they expected to reach general availability and be supported for production use?
• Are there any known limitations or outstanding functionality that could affect migration from EWS?

2. Roadmap commitments and EWS retirement

The published roadmap states:

If an EWS capability isn't listed in this roadmap table, don't plan on a corresponding Microsoft Graph or Exchange Admin API capability being available before EWS is fully disabled.

Can we conversely expect that capabilities included in the roadmap will be available before the April 2027 shutdown?

If not, how should developers plan for dependencies on those capabilities?

3. Migration timelines and alternatives

If these capabilities become generally available close to the retirement deadline, there may be limited time to implement, test and deploy a replacement.

• Is there an expected migration window between general availability and EWS retirement?
• If either capability isn't production-ready in sufficient time, is there a recommended alternative or supported migration approach?

4. Updated parity roadmap

Are revised ETAs available for the remaining capabilities whose Q3 2026 targets have passed?

If there are existing updates, documentation, release notes or other official resources that address these questions, links to those would also be greatly appreciated.

We're looking to make an informed technical design decision based on the expected availability of these capabilities, rather than make assumptions about the published target dates.

Nino_Bilic​ Greg Taylor - EXCHANGE​ , I've seen your helpful responses to other EWS retirement questions. Would either of you be able to clarify the current position on these outstanding parity gaps, or point us towards the relevant product team?

We're looking to progress our technical design as soon as possible, so any initial guidance or direction within the next two business days would be greatly appreciated.

Thanks in advance,

Tim

Greg Taylor - EXCHANGE​ It seems that the enforcement has been delayed to 10th of October, I believe the blog post should be updated.

I have to disagree with some of Greg's statements, yes people should and have started to migrate when the announcement came out and if they have waited to the lat minute then that's on them.  However Microsoft haven't addressed all their 1st party services and haven't provided the expected level of detail to easily identify client versions affected.  Microsoft also added external calendar sharing to the impacted scope very late in the day, the new cross site policy method wasn't released globally until just over a week ago and people are still reporting it isn't fully working.

We were in a position where all our applications had been migrated months ago and were fully expecting Microsoft to be managing there 1st part apps and clients, then the new in-scope announces came and we had to kick off a load more unexpected work.

To try and frame this as just customers not being prepared is disingenuous, I fully except that this is the case for some but others will have taken this seriously only to have additional requirements added late in the day.

My opinion is that a lot of us are trying to do the right thing within serve financial and resource constraints and this is far from the only Microsoft, and other vendor, changes in flight.

I'm not trying to start an argument, only trying to put another perspective forward whilst recognising some of what has been said is also true.

Just make sure Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c) is in your whitelist because it's not going to be fixed by Oct 1st if they haven't had the ability to publish documentation yet...

I keep reading comments like this from various sources and it's super confusing: "The most important behavioral change for administrators is that after enforcement begins in October 2026, setting EWSEnabled=True without an allow list effectively becomes a block-all configuration for EWS application traffic."

Can't I just set EWSEnabled=True right now and then let Microsoft address my empty AppID Allow List by adding apps that have usage in the last 60 days or whatever?  This way I can see if Microsoft identified any apps that I did not?  Or am I misunderstanding the process somehow?

Dear Microsoft team, we are building multiple end-user facing email apps, including Thunderbird Owl, ExQuilla, Parula and Mustang. We have tens of thousands of users on Owl alone, and good part of them use EWS protocol on Office 365. We have implemented Graph in most of our products, but after having finished development, we find that we cannot actually deploy it, because Microsoft blocks access to Graph email for all applications by default . This was a change that happened in October 2025 (less than 1 year ago), and we were not aware of that.

So, now we have an existing userbase that we're forced to migrate to a new protocol, we have invested into implementing it, we implemented a smooth migration path for end users, are about to deploy it, and find that it's categorically impossible for users to log in, because you're blocking it.

Only a very short list of very popular email applications, including Apple Mail and Thunderbird are on that list. We are actually co-authors of Thunderbird, but as Open-Source, so not the same organization. Note that any solution that requires explicit admin approval will not work in practice for a public client with many users as ours.

How can we get on that list of approved email clients allowed by default? This is URGENT, we were about to deploy and found out only in our QA phase that login is now blocked. Please help us TODAY at parula (dot) support (at) beonex.com . Thank you.

Just as a heads up, some M365 managers from other organisations that I'm in a mailing list with have been reporting issues with the EWS report, no new data was being reported since 30/08/2026, I also saw this in our environment.

A Microsoft support call was raised and newer data is now being reported, however people are still reporting gaps.  In our EWS report ran yesterday I've lost a lot of calls that were previously reported on 30/08/2026 and now have a considerably larger amount of calls than I would normally expect being reported on 06/09/2026, there are no other call's reported in September, only on 06/09/2026.

It looks like the report may be aggregating calls over a longer period of multiple days into a single day, 06/09/2026 in our case.

This may not be the case, but there does appear to have been an issue with the EWS report and I'm not convinced it's currently reporting correctly.

Can I get a clarification on the Windows Outlook versions and use of EWS.  Specifically, does Outlook (Classic) require EWS if it is fully patched and up to date?  If so, what features rely on EWS as a requirement vs use EWS as a default?

I'm currently catching up with the M365 Message Centre after returning from leave and have seen an update to this EWS retirement under MC1447678 published on 24/08/2026.

This states:

2.Create and validate an allow list

Create an EWSAllowedAppIDs allow list containing applications that must continue using EWS.

Important considerations:

• Applications appearing in EWS usage reports that you intend to continue using should be included in the allow list.
• Microsoft first-party applications that continue to rely on EWS must also be included if they appear in your usage reporting.
• Setting EWSAllowedAppIDs replaces the existing list. Ensure all required App IDs are included when updating the configuration.

I find this statement alarming:

• Microsoft first-party applications that continue to rely on EWS must also be included if they appear in your usage reporting.

Shouldn't Microsoft have finished updating their own applications before starting to enforce this?  And if not why is it up to individual tenants to allow these to prevent disruption?

I was under the impression that reported Microsoft first party applications being reported in the EWS usage report could be ignored as it was Microsoft's responsibility to update these before the deadline.

The required application being reported as still using EWS is Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c), so please can you clarify that the official position is that I will need to add this to the EWSAllowedAppIDs allow list in my tenant so this continues to work after 1st October?