Microsoft Forces Backup Vendors and Customers Toward Teams Export API

Warns Customers Not to Use Exchange Web Services for Teams Backup

On July 12, right in the middle of that delicious sleepy time in mid-summer for the IT industry, Microsoft dropped a little bomb on ISVs and customers by declaring that they would start to restrict access to Teams message data via Exchange Web Services (EWS) from September 30, 2022. Microsoft recommends that organizations that need to export Teams message data use the Teams Export Graph API instead.

Update: Microsoft has quietly (and without updating the date of the article) pushed out the date when they will restrict access via EWS to Teams message data in Exchange mailboxes to January 31, 2023.

Microsoft explained their decision by saying they “observed over time that a number of 3^rd party apps are accessing Teams messages through EWS” and that the “approach is both undocumented and unsupported by Microsoft and poses the risk of code failure.” In fact, ISVs do not use EWS to access Teams message data. They use EWS to copy the Teams compliance records stored in user and group mailboxes for their Teams backup products.

Teams Compliance Records Stored in Exchange Online

The compliance records created for Teams messages and chats by the Microsoft 365 substrate are incomplete copies of the real data (which remains in Azure Cosmos DB). The substrate creates compliance records as users send messages in chats and channel conversations, including the capture of records for messages sent by hybrid, guest, and federated users.

The items are mail messages with a limited set of properties tailored for eDiscovery. Nevertheless, this doesn’t stop vendors using compliance records as the source for backups, conveniently ignoring the salient fact that there’s no way to restore compliance records into Teams chats or channel conversations.

Third-Party Applications Can’t Access Teams Data in Mailboxes

Microsoft’s supportability statement says that “Third-party applications aren’t allowed to access or use Teams data in mailboxes” and points out that “Teams can change its location and use of data at any time.” Microsoft’s statement seems highly revisionary (or hopeful). I had never heard about a prohibition against accessing Teams compliance records stored in mailboxes. Given the number of ISV that use EWS to read compliance items from mailboxes for Teams backup, it doesn’t seem that many ISVs had either.

The second point about Teams moving its location for compliance records is accurate as this happened in 2020 and broke scripts (and I assume programs) that depended on looking for data in a specific mailbox folder. However, how often the folder location might change in the future is an open question. My bet is not often.

Charging for the Teams Export API

In June, Microsoft announced that they would start charging for the Teams Export Graph API in July. I have not heard of many companies complaining about charges levied against their Azure subscription for using these APIs, but that might be because ISVs haven’t switched their Teams backup products over to use the Graph APIs yet.

By imposing restrictions on EWS, the natural suspicion is that Microsoft is giving ISVs and their customers a big steer to start using products based on the Graph APIs. One perspective is that this is a win for customers because the Graph APIs real actual Teams data instead of the limited copies stored in Exchange Online mailboxes. The downside is the charges incurred to read items out of the Teams store. No one knows quite how much those charges will be but given the increasing use of Teams across all Microsoft 365 segments, it’s reasonable to predict that the bills can only go up.

ISVs and Customers Shouldn’t be Penalized by Progress

The only reason why ISVs use EWS to access Teams data in Exchange Online is that Microsoft is five years late in delivering an API to export information from the Teams message store. As soon as Teams become generally available in early 2017, customers started to ask about backups. What were ISVs supposed to do? If they played dumb and said that they couldn’t do anything until Microsoft delivered a supported API, they ran the risk that their customer would go elsewhere, and that might risk losing the business for backup of supported workloads like Exchange Online and SharePoint Online.

ISVs did the logical and rational thing by using tools available to them to get the job done. Once Microsoft decided to use the substrate to capture and store mail items in Exchange Online for Teams messages, ISVs had a solution. It was imperfect, and some ISVs overplayed their hands and made claims about their solution capabilities that were simply wrong. But what was delivered made customers happy.

I’m glad that Microsoft now has a supported API to export Teams message data. That’s a good thing. It would be much better if Microsoft dropped the charges for a grace period (perhaps two years) to help ISVs and customers to transition to the new platform and become accustomed to the idea of charging. The time would also allow Microsoft to observe the volumes involved in customer usage and fine-tune the charging rates.

Alas, that’s not happening. Instead. Microsoft is forcing ISVs and customers down a route to extra unknown cost for Teams backup. I’ve always said that Teams is the most difficult Microsoft 365 workload to backup. This is just another reason to justify that feeling.

---

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.