Table of Contents
How will Organizations Handle Compliance and Backup for Teams Shared Channels?
Teams customers are naturally very excited by the imminent arrival of the shared channel feature in public preview in March. Nice as it will be to be able to implement federated collaboration with your favorite tenants (Figure 1), the introduction of major new functionality in an application comes with its own administrative challenges.
Take the subject of compliance. Microsoft says that all the Microsoft 365 compliance technologies like Data Loss Prevention, retention policies, and communications compliance work with shared channels. Microsoft’s assertion is accurate and it’s all possible because compliance occurs within the tenant which owns a shared channel. In other words, all processing happens within the home tenant and all data created and used within the shared channel remains in that tenant.
Keeping and managing data within the home tenant is analogous to how Teams handles compliance for data generated by guest users in regular and private channels, but I’ve heard some people assume that the federated arrangement between tenants based on Azure AD B2B Connect cross-tenant policies mean that data is shared between tenants. Or perhaps that Teams would create copies of data in both tenants.
Duplication Possible But Not Feasible
From a technical perspective, the Microsoft 365 substrate could duplicate data in the tenants involved in a shared channel. Duplication would be straightforward for Teams messages but would become increasingly messy as other workloads and applications become involved with a shared channel. For instance, the substrate could create a duplicate SharePoint site for each tenant and then synchronize document and lists as users work on them. However, how would sharing work? Or information protection? And do you really want copies of confidential documents to end up in other tenants?
Time and engineering talent could work through and solve the problems. However, I think it is wise of Microsoft to adopt the keep it simple principle from the start and say that a shared channel has one set of data which remains and is managed on the host tenant.
Cloud-Only Mailboxes for Shared Channels
An interesting aspect of the shared channel implementation is the use of a cloud-only mailbox (aka “shard mailbox”) to hold data used by the channel such as calendar items and compliance records. Regular channels store this information in a group mailbox, while private channels don’t have a calendar and store their compliance records in the personal mailboxes of channel members. Microsoft knows that cloud-only mailboxes work well for compliance because this is how they retain data for hybrid and guest users. A big advantage of the implementation is that Microsoft doesn’t have to create special retention processing for shared channels like they had to do for private channels. Normal Teams retention policies already handle the compliance records for hybrid and guest accounts. Now they’ll handle those for shared channels.
Keeping compliance processing to a single tenant certainly simplifies matters, even if compliance managers need to think through how they can manage the activities of their users in other tenants. The obvious answer is to agree a means to co-operate with other tenants when federated conversations need to be investigated. It will be interesting to see how things develop in this area.
Using cloud-only mailboxes for shared channels comes with a downside. Normal administrative and client interfaces have no access to these mailboxes. This might not seem a big thing if compliance processing like eDiscovery searches can find the information in those mailboxes (which they can). The issue lies when applications attempt to use public APIs to access shared channel data for purposes like backups or tenant-to-tenant migrations.
The Teams Backup Challenge
Teams is already the most challenging Microsoft 365 application to backup. The lack of a Microsoft backup API for Teams messages and the degree of integration between Teams and other Microsoft 365 applications like Planner mean that backup ISVs have been forced to use techniques like copying compliance records from Exchange Online. This approach certainly copies compliance records. The problem comes when attempting to restore the data.
Microsoft has a beta Teams messaging API which backup and tenant to tenant vendors use. The restoration of data copied from channel conversations ends up as new messages containing the original topic and all its replies posted into a target channel. Even if this isn’t a perfect representation of the original data, it can be good enough (depending on your need). Chat messages have always been a challenge because the beta API didn’t handle them.
Hope might be on the horizon in the form of the Teams Export APIs. Generally available since October 1, the new APIs seem to offer everything that a backup ISV might need to copy Teams chat and channel messages. Of course, restoring the messages is another day’s work and includes issues like fixing up cross-tenant access policies and the roster of channel membership.
The Export API can handle regular and private channels today. Microsoft hasn’t said if the Export API will be able to handle shared channels. It’s a fair assumption that this capability will be available, but there’s no information about when this might happen. And even when such a capability becomes viable, there’s still the issue of the consumption charging model Microsoft uses for the API. Microsoft has provided some guidelines for how the charging will work when exporting Teams messages using the Export API, but those guidelines need to be worked out into charging patterns for different kinds of tenants, including those with heavy, moderate, and light volumes of Teams messaging.
It’s difficult for backup vendors to have discussions with potential customers when a product has a dependency on an API with such a charging model. I suspect Microsoft will let customers use the Teams Export APIs free of charge for a period to gather data and figure out an acceptable charging regime. When that’s done, tenants will likely pay for the backup transactions they consume using an Azure subscription.
Shared channels are a nice step forward for cross-tenant collaboration. Like all technology, their implementation and management will require new APIs and techniques. The learning continues!
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.
You mentioned DLP policies, but what about Sensitivity Labels, do you know how those will interact with shared channels?
Sensitivity labels apply to shared channels in the same way as they do to private channels: settings are inherited from the host team.