Microsoft Teams is one of the best collaborative cloud tools available, providing users with both real-time chat, online meetings, schedulining and more. And along with that comes a SharePoint site with which to store, share, and edit content. As such it’s perfect for users who are working together on major projects—allowing them to both stay in touch and share their work with one another.
As powerful as this pairing is, however, it poses a problem that many users aren’t actually aware of, and one that can ultimately be detrimental to site organization and SPO environment management. You see, when a project is completed, it is common for admins to delete the Team in which the project was based. Unfortunately, this does not delete the corresponding SharePoint site in which that shared content is stored.
In some ways, this hiccup makes sense. After all, just because a project is completed doesn’t mean that the files that the team created and used throughout the process aren’t valuable. By preserving that SharePoint Online site even after the team is gone, SPO seems to be ensuring that this content doesn’t vanish unless explicitly deleted by admins.
Sensible as this may be, though, it still creates an issue. Because many admins are not aware of this feature in SharePoint Online–and thus unaware of the SPO site’s continued existence–their ability to monitor the behavior of that preserved content is diminished to almost nothing. In fact, what might have been a previously well-organized cloud environment is now populated with free floating sites, detached from the main architecture of other SharePoint Online sites.
In a previous ebook, we explored the importance of maintaining a clean and tidy SharePoint Online environment, as well as different techniques for achieving that. One of the topics that we briefly touched on was security, and why messy SPO architectures make it more likely that valuable content will be lost or exploited. In the scenario that we’re discussing here, that is a huge problem, especially because even if admins can see these sites, it’s virtually impossible to tell whether they’re a site that was once associated with a team, or whether they’re just independent sites created by users to store some of their content.
Many projects in different departments will, at one time or another, require access of sensitive files. For example, a Team might be created involving members of the legal and human resources departments in the wake of an acquisition. The files shared on that Team or stored in its sister site might include contracts or financial statements. After the project is done, copies of this content might be stored in different sites, secure and monitored; but, if admins aren’t aware that deleting that team doesn’t extinguish the SPO site attached to it, other copies of those contacts and statements will exist potentially unmonitored. These sites might have different permissions–even external permissions–that were meant to be revoked at project’s end, but if that site remains, staying somewhat hidden, those permissions will still be active.
If users who shouldn’t have access take advantage of those files, it’s possible that admins won’t know until it’s too late.
After discovering this, we thought maybe we could use the Office 365 CLI to identify which sites are associated with Teams, but as shown in the image below, the sites associated with Teams are not distinct at all from normal Group sites or site collections. As such, it’s hard to separate the Teams sites out to properly decommission them.. For organizations with thousands or hundreds of thousands of sites, locating each Teams-associated SPO site that remains manually would be a major drain on resources, and total accuracy would be nearly impossible.
How Can I Fix This?
Finding a workaround for these problems is essential, and there are a number of ways to achieve that. To do so, however, requires at two step plan: how will admins be made aware of existing sites (which must be properly decommissioned), and what will be done about the content contained within them.
Alerting is actually not that difficult. In the Teams admin center, there are a number of ways to customize usage reports for a given Team, meaning that it’s possible to send notifications upon the deletion of a team to administrators. Once the admin is notified, it’s simply a matter of going to the still-existing SharePoint Online site, deciding what to do with the files therein, and moving forwards.
It’s possible to automate these notification process through other means as well–namely, Microsoft Flow. With Flow, admins can create workflow processes made up of a number of different integrated apps: everything from Twitter to OneDrive. The flows are designed so that a certain action within one application will trigger a behavior in another one–such as the posting of a new article on a blog triggering an automatic “Check out our new post!” tweet. In the case of Teams, a flow could be designed that automatically notifies admins across multiple channels when a Team is deleted. The notification could even be customized at the beginning of a project, so that the email or slack message automatically contains a link to the associated SPO site that will need to be reviewed.
Once all this is instituted, the choice about what to do with the content becomes the main issue. In most cases, this will depend on the nature of that content and the project. For smaller projects containing no sensitive files, admins might simply alert team members that they have a set amount of time to return to the site and download or move what they need before it will all be deleted. More efficient (and more suited to scenarios where sensitive content is contained in that site), however, would be to use a tool like Cloud FastPath.
In this case, admins can use CFP to migrate the content–which, depending on the project, might be substantial in size–to a different SPO site suited for sensitive files or otherwise. In cases where the content is sensitive, but unlikely to be necessary in the near future, admins can migrate it to a designated archive, where it will remain, ensuring that no retention policies are violated.
Manage Your Teams and Avoid Sprawl
Because projects will be ephemeral, Teams are constantly being created and deleted, and it’s important that admins can be absolutely sure what is becoming of the content that was previously associated with a Team, its users, and their project. Designing a strategy to handle the remaining SharePoint Online sites in the wake of a Teams deletion puts you in a better position to protect your files, and keep your SPO environment from succumbing to the storage sprawl that puts both users and content at risk.
With tools such as Flow, Cloud FastPath, and Teams’ own customizable alerting features, admins are able to tackle this issue with relative ease, and those who were previously unaware of the issue should quickly start figuring out exactly what approach they want to take.