I often end up in one of two conversations around Microsoft Teams governance with customers, the “Users can manage them themselves so we don’t need to worry” group, and the “Nobody gets a Team unless we follow this 20 step approval process and our service desk needs to set them up and lock them down” group.
Both options have their merits, but also their pitfalls. If we let everyone create teams we end up with sprawl and have no idea where our data is stored (why are there six “HR Teams”, and which one contains the right data?). On the other hand, if we don’t let our users use Teams without jumping through hoops while saying the alphabet backwards, in Latin, then we are preventing people from using some of the most powerful collaboration features available to them.
We usually end up finding a good middle ground in these discussions that leverages automation and some of the cool Information Protection features of Microsoft 365. My opinion on Teams provisioning process has been the same as it was for SharePoint sites, “I don’t care if we have ten thousand Teams, as long as they are named and protected correctly, the number doesn’t matter”.
This opinion was idealistic in the early days of Microsoft Teams as the governance features just weren’t where I wanted them to be. In the past year, Microsoft have taken strides in the features available and I’m pretty happy (albeit still a few features I’d like) with what’s available. I might even do a follow up post where I can rant about my Teams security and governance opinions down the line.
One feature that has made my life much easier since it was made available (in Preview) is the ability of Sensitivity Labels to be applied to Office 365 Groups / Teams / Sites . This feature allows us to define Sensitivity Labels which, when applied to a Group, can control the privacy level of the Group, the level of functionality available to unmanaged devices, and even the external access configuration.
During some early Teams projects I had automated scripts which changed these group settings in Azure AD, SharePoint sharing settings on the site level at the time of provisioning. That was a nightmare as it had to be maintained and knowledge transferred to the incumbent IT Teams.
When this feature is enabled, we just need to specify the settings in our sensitivity label and it’s all taken care of for us.
To enable this feature for your tenant now, connect to the Azure AD Preview PowerShell Module and run the below to update the Directory Setting and enable MIP Labelling in Office 365 Groups.
##Copy Current Settings to $Settings Variable $Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id ##Change EnableMIPLables setting $Setting["EnableMIPLabels"] = "True" ##Write back changes to directory Set-AzureADDirectorySetting -Id $Setting.Id -DirectorySetting $Setting
Next, connect to the Security & Compliance PowerShell Module and run the below to start the synchronization process between MIP and AAD.
After a little time to replicate, you will be able to see the above page when configuring a new sensitivity label and then apply them to Teams/Groups/Sites and once the labels are deployed (usually 24 hours after creation) you’ll be able to apply them at provisioning time!