On October 5, 2021, the Microsoft Exchange Team BLOG posted a notice about Upcoming API Deprecations for EWS in Exchange Online. The article included some API commands becoming end of life. However, the true shock was a statement that on September 30, 2022, no new Application Registrations would be allowed.
The key statement was this:
“We will also remove the ability to register new apps in Azure with EWS permissions starting September 30, 2022. Apps registered before this date, any API not mentioned in this, or subsequent announcements, will not be impacted.”
This essentially meant that EWS in Exchange Online was going to be turned off. You do not always know that a migration is going to occur. For Migration Administrators and Software Vendors, this created quite a bit of panic.
Recently the BLOG has been updated and the news is very good for many of us. The BLOG has been updated to read:
“We previously announced that we planned to prevent registration of new apps in Azure with EWS permissions, but based on your feedback we have decided to postpone this plan for the time being.”
What does this mean to administrators?
On the outside, this looks like big news for Migration ISVs and less importantly, to administrators. While Migration ISVs (which in full disclosure includes me) are happy for this change, there are a few key things to be aware of.
In time EWS is going to go away. Not today or right away, but in time. This has been the main backup and migration protocol for Exchange, and Exchange Online, since inception. It is quick and has no added cost. These days will change in time and requires everyone to monitor both the changes and their vendors to ensure they will be ready when that time comes, including any potential costs that may get added on.
Today there is not a 1:1 replacement for EWS. This has been the main challenge in shifting off of EWS. Until we have a full feature replacement, with acceptable throughput, it makes it very difficult to design solutions for these Exchange data migrations.
Why is EWS so hard to replace?
Exchange Webservices was launched with Exchange 2007. It was the primary API for many solutions from Blackberry Enterprise Services to Migration Services. To be fair, it remains the primary API for data migrations today.
Whilst we have seen the MRS Migration Preview Program and Graph APIs expand options for mail migrations, none have fully replaced the EWS speed and function. The MRS Services moves entire mailboxes, something that is great for Exchange Mailbox Migrations, but does not help when single item migrations are needed or where MRS is not an option.
So, what is happening to EWS?
We have had some warning shots on this for some time. There has been some shared frustration where we do not have a true replacement for EWS as of this writing. On July 3, 2018, we got a warning that no new development would be taking place on EWS. (https://techcommunity.microsoft.com/t5/exchange-team-blog/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/ba-p/608055) Inside this, we also saw Basic Auth being turned off, something I think we all are grateful for.
Microsoft has to constantly balance function, access, and stability in their cloud offerings. With mailboxes being an extreme size these days, suddenly pumping terabytes of data into a database across thousands of accounts creates issues. It is sometimes hard for us to remember that these cloud systems are the on-prem systems at scales that are hard to imagine. However, too many functions against a database can make for stability issues. This is where Service Protection, or more commonly called, throttling, comes in. For a very long time EWS has remained our primary highway in and out of mailboxes. Even today, I continue to find the fastest performance with a well-planned and controlled EWS migration.
That said, there are signs of this changing. To be fair, outside of data migration, nearly every single command in the EWS stack has a replacement in Graph or somewhere else. The main issue continues to be the performance of export and upload of data. This news gives more space and time until valid replacements are available.
Am I going to get charged in the future?
We can’t cover this topic without covering the elephant in the room. EWS has been a “free” method of migrating data in and out of Exchange. As most EWS functions move to Graph, one can worry that this will not be without cost. Those that have done migration work in Microsoft Teams will be familiar with this. As new Microsoft Teams Graph commands have come out, they have had some significant costs. Microsoft outlines this in their article here: https://docs.microsoft.com/en-us/graph/teams-licenses . Many of us foresee this is going to be the new norm with new API options.
Conclusion
For most, the changes to EWS will not be a big deal. However, for organizations doing a lot of migration and backup activity, the changes and related fees could really add up. Some would argue that charging is fair as clients not using the feature are paying for others that do. However, for a service that has been included for such a long time, this new expense may catch organizations off guard. For those that backup Exchange from Office 365, something that Tony Redmond covers here in good detail, if this is a charge-based API, you will need to be prepared for it.
