Table of Contents
Use the Exchange Web Services Usage Report to Track Down the Apps Still Using EWS
On April 22, I wrote about the steps Microsoft is taking to prepare for the removal of Exchange Web Services (EWS) from Exchange Online through the introduction of a dedicated app for hybrid interoperability. Essentially, the new app will take over as the fulcrum for fetching data such as free/busy information from on-premises mailboxes, first using EWS before moving to Graph API requests later this year.
This is an example of Microsoft preparing first-party apps before retiring EWS. Third-party apps running in tenants might also still use EWS. It’s important to check if such apps exist so that contact can made with the app vendor to ascertain their plans for EWS retirement. To help with the process, the reports section of the Microsoft 365 admin center has an EWS usage report (Figure 1).
Validating Apps Listed in the EWS Usage Report
The report details the application identifier, SOAP action (API call) and volume, and the last activity date. Application identifiers make a lot of sense to Microsoft 365 (and more specifically, Entra ID), but they’re hard for humans to understand. Fortunately, it’s easy to resolve the application identifiers for many Microsoft apps by consulting the Verify first-party Microsoft apps in (Entra ID) sign-in reports page. A quick check against the apps reported for my tenant found the following apps:
- Office 365 Exchange Online (00000002-0000-0ff1-ce00-000000000000).
- Office 365 SharePoint Online (00000003-0000-0ff1-ce00-000000000000)
- Teams (1fec8e78-bce4-4aaf-ab1b-5451cc387264).
- Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c)
- Microsoft Outlook (5d661950-3475-41cd-a2c3-d671a3162bc1)
- Teams Web Chat (5e3ce6c0-2b1f-4285-8d4b-75ee78787346).
None of these are surprising. EWS has long been used for calendar lookups, and Teams uses EWS in its middle tier to communicate with Exchange. The apps listed here probably use EWS to fetch information about the current calendar status for users to display that status in their profile data.
Checking for Other Apps
Two explanations exist if you find an application identifier that isn’t in Microsoft’s list of first-party applications. The app is either owned by Microsoft but didn’t make it onto the list for some reason. The more likely reason is that it’s a third-party or custom-developed app that uses EWS.
You can resolve the application identifier by searching the set of enterprise applications in the Entra admin center or with PowerShell. Figure 2 shows an extract of the set of enterprise apps with Teams in the name. You can’t search by application identifier or even sort the set of apps by application identifier, so finding the right app can be tiresome.
Instead of grappling with the Entra admin center UI, it’s usually faster to search for an enterprise application with PowerShell. In this case, I create an interactive Microsoft Graph PowerShell SDK session with the Application.Read.All scope (permission) and use the Get-MgServicePrincipal cmdlet to look for the application with a specific identifier. Once you know the name, you can find other details by examining the app’s properties through PowerShell or the Entra admin center.
Connect-MgGraph -Scopes Application.Read.All Get-MgServicePrincipal -Filter "Appid eq '5d661950-3475-41cd-a2c3-d671a3162bc1'" | Select-Object DisplayName, AppId DisplayName AppId ----------- ----- Microsoft Outlook 5d661950-3475-41cd-a2c3-d671a3162bc1
Time Ebbing Away
Microsoft plans to retire EWS from Exchange Online on 1 October 2026. That seems like a long time away, but it’s not if you have to track down the developers of EWS apps built for your organization internally or externally. Unlike other deadlines, Microsoft won’t extend the retirement date for EWS because the API is considered insecure and a prime method for attackers to exfiltrate data from a compromised tenant.
Perhaps your EWS usage report will only contain references to Microsoft first-party apps. If so, you’re all set. If not, it’s time to get moving and either retire or upgrade apps.
Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.
Thank you for this. A question if you’d care to entertain it. I found an unfamiliar App ID in my EWS report. Looked for it in Enterprise Applications but it does not appear there (even when removing the filter so it shows all apps). Also tried to query for this ID against Graph, but it does not return a result. No error, just no result. Not sure what to make of that and wondering if anyone else has experienced something similar.
Have you searched for the GUID with Google? It might turn up a hit to show who created the app.
In most cases, an app that isn’t identifiable is a Microsoft background process. You might learn more by looking at the APIs the app is calling… then again, you might not!
Sorry– I should have mentioned that I did Google the GUID (that sounds…wrong), but it didn’t return any results.
The app in question is apparently calling FindItem, GetItem, GetClientIntent, and GetUserConfiguration. All of them are sub-200 call volume, so very light, relative to known apps whose calls numbers in the thousands to hundreds of thousands.
At least a couple of those calls seem to be Exchange-related, so perhaps as you say it’s a Microsoft Background process.
FindItem and GetItem are EWS operations to find and retrieve mailbox items (you can check the documentation for each call. https://learn.microsoft.com/en-us/exchange/client-developer/web-service-reference/getitem-operation is the page for GetUtem). It’s likely that this is a Microsoft background process that they are in the process of phasing out to be ready to switch off EWS for Microsoft apps in October 2025.
I have the same issue. Just created a ticket in Microsoft so I will update you once I get any news.
Thank you, and I wish you luck– the last two times I opened tickets with Microsoft the process was slow, painful, and ultimately inconclusive.
Just out of curiosity, does the GUID you’re seeing end in 5c170d? Wondering if it’s the same one. Per Tony’s comment and the calls my app is making, I’m leaning toward mine being
a Microsoft background process.
One is 8cfba547-8ce3-eb60-fe2d-3a81ee5c170d as you per Joseph and other one is fef95295-5986-cc3e-1f1f-572b2f8f6bac with only 1 call.
Probably Microsoft services. There are a bunch of microservices running in the cloud that do things like profile synchronization. It wouldn’t surprise me if these were examples of those services.
I’m sure you’re right, Tony, so I’m going to move on to other things and not be concerned about this anymore. Would be nice if there was a list of such GUIDs somewhere (or that they appeared in a search). Alas, this is Microsoft though, so I guess that’s too much to ask. Thank you for your insight, as always.
We too are seeing this application id (8cfba547-8ce3-eb60-fe2d-3a81ee5c170d) in our EWS reports so it would be good to know exactly what’s going on with that!
Hi Tony
What about the “Apple Internet Accounts” app (ID=f8d98a96-0999-43f5-8af3-69971c7bb423) used by used by Apple’s native Mail app on iOS devices to connect to Microsoft Exchange Online. Is it going be blocked as well? And if yes, what to do? (except for switching to Microsoft Outlook).
I believe that Microsoft is working with Apple to make sure that any use they have for EWS is amended. The Apple iOS native mail app doesn’t use EWS. It uses Exchange ActiveSync.
Thanks for the quick response! I’m also hoping that Microsoft is working closely with Apple to make sure the native iOS Mail app can access Exchange email and calendar smoothly. If you have any updates or insights on this, I’d really appreciate it if you could share.
Exchange ActiveSync is an old and stable protocol. It is documented online. You can read all about it there. ActiveSync hasn’t changed, so the EWS deprecation won’t affect it.
Thanks. I admit that I’m a bit confused now or misunderstand something. To my understanding the access to Exchange Online via ActiveSync was blocked while basic authentication was depreciated 2/3 years ago.
I was asking about the EWS/f8d98a96-0999-43f5-8af3-69971c7bb423 because I’ve found a lots of SOAP actions for this app in the EWS Usage Report for Exchange Online – and – for my understanding – it correlates with the fact that many users in my organizations are using iOS native app (or is it something else?)