Recently, I was enjoying an episode of Mark Kashman and Chris McNulty’s Intrazone podcast where they had Stephanie Donahue & Dux on talking about how granularly recoverable everything is nowadays with products like AvePoint Cloud Backup. AvePoint’s platform really is fantastic – minus the inability to restore a Team as a new/different Team. The capabilities are so much more advanced than what we’ve had in the past that its easier than ever for organizations to be lulled into a false sense of security as they implement such rapidly changing & powerful products.
Fantasy Productivity: Adopting (Microsoft) Teams – The Intrazone by Microsoft 365
Specifically, the gap that I couldn’t stop thinking about as I listened was the role of Data Loss Prevention (DLP) & retention policies for Microsoft Teams.
Recently, I had a scenario play out with a large customer where a lot of energy was being put into Microsoft 365 Compliance planning. Despite the effort that was being put in, they fell into a VERY non-intuitive trap that I suspect others will trip over at some point. Anyway, it felt worthy of committing to written form in hopes of helping someone else – or at least registering my complaint with the internet.
Scenario
If you’ve ever applied a retention policy to a SharePoint Online site, you know that they make deleting sites pretty difficult – by design. The policy works, and not just for SharePoint, but (generally) for each of the applicable locations. Separate from these policies, you have the reality of recovering a Microsoft Team that’s been deleted. Generally speaking, if a Team gets deleted, you hop over to the SharePoint Admin Center and restore the site that corresponds to the Team in question. Ta-daa! Team pops back in, just as it was before.
Where it gets weird is when you have a Microsoft Team, which is made up of parts that are covered by these polices. The underling SharePoint site and the corresponding Microsoft 365 Group each explicitly covered by a policy preventing deletion.
On face value, they see the Microsoft 365 Group and SharePoint site protected from deletion and the historical knowledge that restoring a deleted Team is done by restoring its site – which now can’t be deleted anyway. They justifiably conclude that their Teams are protected from deletion and move on with their day.
Problem
IT managers are surprised when reports come in that someone accidentally deleted their Microsoft Team. They go into their SharePoint Admin Center and there’s nothing in the “Deleted Sites” bucket. Weird. The site is sitting there in “Active Sites” and appears to be fine. In the moment, they are confronted with the fact that a) someone deleted a Team and b) the process for restoring a Team isn’t going to work.
Eventually, someone remembers that Teams are made up of 3 components – what about the Microsoft 365 Group? Someone else chimes in and says that it can’t be that, after all, the group was explicitly covered by the retention policy. Sure enough, the corresponding Microsoft Group is sitting in the “Deleted Groups” bucket in the admin center. Restore it and everything is restored – SharePoint is happy, Teams is happy, users are happy.
Unfortunately, that’s just the first problem. Ignoring the mechanics of how & why that specific outcome is what you get when you have retention policies in place, you still have a hard-coded 30-day window to figure out that it happened. Sadly, there also doesn’t appear to be any (universally available) ways to passively monitor for when those events happen.
Solution
Ideally, there would be more cohesion between the 3 major parts of the Team. Like the legs of a tripod, the 3 parts (Team, M365 Group & SharePoint site) all represent necessary & interdependent elements of “what a Team is”.
Yes, you can work do different things with some parts and not others, but to lose any of those 3 parts, you’ve lost the overall context of what the Team was. The Team is more than the chats, more than the files presented within it, more than the security trimming that someone applied to a few sub-folders in a channel, and more than the tabs & apps that users access… it’s all of these things, combined as a singular experience in the eyes of the user. Currently, I am unaware of an OOTB system-wide safety net to ensure that this experience is kept whole.
I would argue that this is a very large hole in the grand scheme of things. You have a 30-day window to HOPEFULLY catch that this happened or that Team (as it was) is gone forever.
Setting aside the belief that this lack of connective tissue between these parts will become cancerous to the product of Microsoft Teams at some point – and seeing that virtually every single ISV in the 365 cloud backup space is currently struggling with how to address it, we moved to “Ok, how can we at least know when one of these events happens”. Even then, none of the usual candidates seemed to allow the trap we were looking for. If Microsoft would add “Team Deleted” as a trigger in Power Automate, it would have been fantastic. Allowing specific audit search queries from the Compliance Center to be saved as custom alerts would work too since the event can be observed in the audit logs as a Team Deletion event. Heck, even AAD logs trap a Microsoft 365 Group deletion event, but again, not in a way that was conducive to proactive alerting.
For my part, the only thing I was able to come up with was to establish a specific Cloud App Security control policy. From Cloud App Security, we were able to define the trap and configure an alert to go to a dedicated list of humans that would know how to respond to such a scenario.
I’m sure there are more clever ways to accomplish this – ideally something that doesn’t require the additional license of Microsoft Cloud App Security. If you know of a more efficient way, I’d certainly be grateful if you shared them (not to mention a couple of our customers).
Everyone is still responsible for their own end-to-end testing, retention polices are no different – nor are they a substitute for back up & recovery strategies. That said, the face value of the policy claims to protect Microsoft 365 Groups, and it doesn’t. Even if a group’s mails or other Exchange bits are protected, a group is more than that, and it’s not what the users are seeing in the interface.
The only long-term answer that makes sense to me is for Microsoft to strengthen the relationships between the three legs of the Teams tripod.
You can find me at @rickzeleznik on twitter & instagram