How to Limit the Creation of New Teams to Private Access

Using Container Management Sensitivity Labels to Force Specific Teams Privacy Mode

Yesterday, I wrote about how to control the creation of Microsoft 365 groups (and teams) using Microsoft Graph PowerShell SDK cmdlets to update the directory object setting used for the tenant groups policy. This led to a question from a reader who referred to a Microsoft Technical Community discussion about how to force those allowed to create new teams to only create private groups. A private team is one where the team owners control the membership. By contrast, anyone can join a public team.

I’m not quite sure why this is any better than allowing people to have a choice between private and public (Figure 1) in terms of preventing group sprawl, but it is an interesting example of using sensitivity labels for container management.

The privacy options for a new team

Teams privacy mode
Figure 1: The privacy options for a new team

The technique outlined here only affects new groups created through Teams, Outlook, OWA, and SharePoint Online clients. It doesn’t affect existing groups nor will it stop an administrator creating a new public group through an administrative interface like PowerShell or the Graph APIs.

Implementing the Block on Public Teams

The steps to block new public teams starts with creating or selecting a container management sensitivity label (one that exerts control over teams, groups, and SharePoint sites). I have a well-populated set of sensitivity labels in my tenant, so I choose to use one called Confidential Access.

It’s critical that the privacy settings for the label dictate that groups and teams assigned the label can only have private access (Figure 2).

The privacy settings for a sensitivity label limit users to private
Figure 2: The privacy settings for a sensitivity label limit users to private

Next, create a label policy to publish the selected label to selected users. For instance, you could decide to publish the policy to the same users who are allowed to create new groups or limit publication to a subset. Unfortunately, you can’t choose a security group for the target set, so you’ll need to include each user separately (Figure 3) or use a Microsoft 365 group or distribution list to establish the scope for the policy.

argeting users to receive the label
Figure 3: Targeting users to receive the label

Make sure that the label policy requires users to apply a default label to sites and groups. Because only one label is covered by the policy, this is the only one that can be assigned by default (Figure 4).

The label policy settings define a default label
Figure 4: The label policy settings define a default label

Make sure that the label policy has the highest priority so that it takes precedence over any other label publishing policy. This is the usual state for the most recently-created label policy but it’s wise to check and adjust if necessary.

Wait for Effect

Publication is not immediate. Behind the scenes, Microsoft Purview processes the new label publishing policy and makes the label available to the target set of users. It could take up to 24 hours before the user account and relevant applications learn about the new policy and its settings.

When the label policy is in force, the dialog to create a new team prepopulates the sensitivity label with the default label specified in the policy. Because the label specifies that private access is the only permitted option, this action disables the choice of public access (Figure 5).

Forcing the use of the sensitivity label makes public access unavailable
Figure 5: Forcing the use of the sensitivity label makes public access unavailable

Changing Other Teams to Private Access

As mentioned above, implementing a sensitivity label for container management in the manner explained here does nothing to existing teams. If you want to make all teams private, you must search for teams with public access and update them to private access. Here’s some based on the Microsoft Graph PowerShell SDK to do the job.

Connect-MgGraph -Scopes Group.ReadWrite.All
[array]$Teams = Get-MgGroup -Filter "resourceProvisioningOptions/any(x:x eq 'Team')" | Where-Object {$_.Visibility -eq 'Public'} | Sort-Object DisplayName
If ($Teams) {
   Write-Host ("Processing {0} teams with public access..." -f $Teams.count)
ForEach ($Team in $Teams) {
   Write-Host ("Updating team {0} to private access..." -f $Team.DisplayName)
   Update-MgGroup -GroupId $Team.Id -Visibility 'Private' 

I’m still unconvinced that forcing all teams to be private will address the problems of group sprawl, or unused and obsolete teams. But it’s an interesting approach. Maybe it’ll work for you.

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.

3 Replies to “How to Limit the Creation of New Teams to Private Access”

  1. Thank you as always Tony. This is now working for me, but it took almost 2 days for the policy to started to work as expected.

    The idea for such policy is not to address issues of “group sprawl, or unused and obsolete teams”. For that we have the ownerless group policy. Its purpose is to help prevent oversharing of data. I’ve seen many, many cases where users create an open Team without realising the corresponding SharePoint site is public to the entire organisation, and then everyone has access to private/confidential information the owners upload to that team/site… Furthermore, in large organisations, specially highly regulated ones, there are not many cases where a team or site really needs to be open to the entire org.

    1. OK, I can see how restricting sites to private access is a good idea in the context of the possibility that Microsoft 365 Copilot might reveal all in a response that it generates.

    2. If an organization has sensitivity labels deployed (and are able to use labels for container management), they probably have labels to protect documents as well. In that case, it’s a good idea to coach users to apply sensitivity labels to protect confidential information that they upload to SharePoint Online. Admins can make mistakes with the access mode for a team/site, but a sensitivity label will always restrict access to whatever rights are defined in the label.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.