Upcoming API Deprecations in Exchange Web Services for Exchange Online

Way to go! Are there any plans to provide insights if these particular API:s are in use in our tenant(s) so we know if we will be affected of these depreciations?

This is a major announcement and has the potential to impact every Microsoft customer from the point onward where no new EWS App Registrations are possible.

Right now, the Exchange Web Services API is the only way to get full-fidelity (preserving all properties) email information into and out of Office 365 (see MS-OXWSBTRF). Without this capability, 3rd Party applications addressing backup, eDiscovery, and migration (including Tenant-to-Tenant) will simply not be possible anymore! Also, even if the Graph API is extended to support the missing methods, will MSFT switch to the same "paid" model to use the Graph API as with Teams?  

Imagine the implications of an acquisition or divestiture scenario, where one needs to consolidate tenants and/or on- or offboard legacy data. Cost and Time implications might get enormous, and a lot of restructuring projects will never reach an ROI if suddenly the project costs and timelines multiply.

I agree with Jonas, Microsoft needs to provide reporting so that we can easily identify the apps that are utilising the impacted EWS APIs (and EWS more generally). I don’t think we can rely on the Azure AD Sign-In logs as they only allow you to filter on Client App, which for EWS is only listed for Basic Authentication connections.

Also how do these changes impact the Outlook for Windows and Outlook for Mac clients, since it’s my understanding that both clients still utilise EWS to connect to Exchange Online for some functionality (especially Outlook for Mac - current version, not the new UI version which uses Microsoft Sync Technology).

From my Point of View the impact of this is huge. In my little world almost every 3rd Party ExO solution I can think of uses these EWS permissions. 

When it comes to the EWS API itself (which will still be there but you cant register the app) and the ability to just replace it with graph API is just not true. 

We believed in graphAPI as a replacement for EWS in 2018 and ended up with a lot of issues which - to my knowledge  - are still not sorted. EWS is complete. graphAPI is not when it comes to a full featured Exchange API.

So, when you depend on streaming subscriptions and full featured object handling (create, update, delete notes, contacts, appointments, stickynotes and folders, etc) 

you end up with a mixture of graphAPI and Outlook REST API and still miss features.   This can all be true because of my limited knowledge, so if anyone at MS is reading this: 

a real migration guide which EWS feature can be (fully)  replaced with which graphAPI feature and how to do it with samples and stuff would be incredibly great.

Also a clear statement what’s just not available atm. Or take the easy way and just drop the idea of deprecating the EWS APP registration.

So just to confirm again as WGroenestein asked earlier (and I do see it was responded to), after the stated date, no new apps will be able to be granted the EWS.AccessAsUser.All API permission?  Seeing as that permission is so universal and we're only talking about a small portion of API's being deprecated, this particular step seems like going too far, and in parallel, barely calling attention to this.

When I'm using EWS Managed API, I'm doing all kinds to basic EWS stuff that isn't part of any one of those API's.  Like Folder.FindItems, or ExchangeService.FindItems, or Folder.Emtpy, etc.  I don't even know what sub-API these fall into.  My understanding was the the API in this case is Exchange Web Services, though I realize EWS (the web service) has the SOAP/XML interface that is the main function (as opposed to the 'managed API').

I just don't get why you're selling this as though you're deprecating a few of the EWS API's, but then you're taking away any net new ability to setup new apps to use the non-deprecated API's.  Seems less than open book and more like trying to pull something off without getting called out before it happens.

What does that mean, "Today, we are announcing that we are going to remove the ability to create new EWS apps starting September 30, 2022."?

You mean you can't create Azure AD apps anymore with EWS permissions? You're kidding, right?

stukey ,  Tom_R_ , JonasBack  - We will send Message Center posts to impacted tenants with a list of applications using any of these 25 EWS APIs mentioned in the blog post. As for the question on Outlook usage – currently we have announced only a small subset of EWS APIs for upcoming deprecation, not EWS all up. Outlook very much still uses EWS, but none of the APIs included in this announcement. Outlook (win and mac) moving off EWS is beyond the scope of this announcement.

MichelZCF , WGroenestein - As mentioned in the blog, creation of new apps using EWS is planned to be blocked from September 30th, 2022. So, yes, new Azure AD apps can’t be created using EWS permission scopes. Existing apps using EWS apps permissions will however continue to function beyond this date & not be impacted. This is only relevant for Exchange Online.

Apps running on Exchange On-Prem won’t be affected by any of this announcement and will not need to change. New solutions should actively look into on-boarding to Microsoft Graph directly for Exchange Online.

Hello, the main issue we face today is that graph API does not cover all methods covered by EWS. It will be easier to move to graph API if we did not miss some of it. We are now in a situation where we need to do heavy developments using Graph API and EWS. knowing that we will need to do some more developments when those missing features will be covered by graph API. Hope we can use Graph API fully soon. thanks

Renaud_B If you could add what particular methods are missing, I think that would help. Not only Microsoft but also us who talk to customers and vendors so we are aware what is missing and not. Since there is actually no "User Voice" anymore and this Tech Community is one place where Microsoft wants us to provide feedback.

Completely agree wit JonasBack and stukey 

Microsoft needs to provide reporting so that we can easily identify the apps that are utilizing the impacted EWS APIs (and EWS more generally). I don’t think we can rely on the Azure AD Sign-In logs as they only allow you to filter on Client App, which for EWS is only listed for Basic Authentication connections.