Self-Service in Microsoft Teams

Allowing users to create their own Teams or groups is a topic of some discussion and disagreement, there is not just one right answer, other factors related each organisations capability, governance approach and relationship with users really drives the best decision. I am not planning to review the merits here, other than to say that decisions really should be made to your users benefits. If you can add value by managing group creation for them then go for it, if it will just be bureaucracy then I would suspect that they will work round you.

For my employer it was not a hard decision, the structure of our support capability is such that we really cannot add value, so for the past 18 months we’ve allow self-service group creation, and that now means self-service Team creation. It’s been very popular with our users and continues to gain adoption across the business.

I wanted to highlight some of the approach we have taken to self-govern this content and highlight the tools and capabilities that exist. It’s also worth pointing out up front that a great deal of these features require the AzureAD P1 Licensing, you might have this as part of EMS P1 or in the Microsoft 365 E3 Suite.


My organisation has Information Workers and Front Line Workers, on balance we felt that the self-service capability for Teams and O365 Groups was only relevant to the Information Workers. My colleagues as Front Line Workers can self-create Yammer groups and although they are members of O365 Groups it does not really make sense for them to ever create these.

To achieve this, we created a dynamic AzureAD security group that identified users by the licenses assigned, then we set the policy to only allow these to create new groups.

# create a group looking for Exchange Plan2
$group = New-AzureADMSGroup -DisplayName "E-Users" -MailEnabled $False -MailNickName "Eusers" -SecurityEnabled $True -GroupTypes "DynamicMembership" -MembershipRule "user.assignedPlans -any (assignedPlan.servicePlanId -eq ""efb87545–963c-4e0d-99df-69c6916d9eb0"" -and assignedPlan.capabilityStatus -eq ""Enabled"")" -MembershipRuleProcessingState "On"
#create the setting object, if you get an error it already existed and you can skip
$Template = Get-AzureADDirectorySettingTemplate | where {$_.DisplayName -eq 'Group.Unified'}
$Setting = $Template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $Setting
#update the policy
$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id
$Setting["EnableGroupCreation"] = $False
$Setting["GroupCreationAllowedGroupId"] = $group.objectid
Set-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id -DirectorySetting $Setting

Naming Schemes

Creating Teams and groups will generate an email address in your Exchange Directory, by enforcing a naming scheme you can make it clearer to users which are groups and which are users. Historically we prefixed distribution lists with “DL — “ so we started with a scheme to prefix O365 groups with “GRP — “. This kind of made sense until the advent of Teams, users really don’t get that they are the same. They also don’t really figure out that they can add Teams to their existing groups. I think “Team — “ would be a little odd, so my plan, which we are testing now, is to adopt a scheme that self service would be designated by “# “, it’s neutral but users kind or associate it with things that are modern and cool. My concern is that using a character that is not a letter will make some things more complicated. So far it would seem that the # just gets dropped when forming the SharePoint site and SMTP address.

We have also added the surnames of our executives to the custom blocked word list, so there’s limited chance of impersonation.

#Connect to AzureAD using the V2 preview then …
$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id
$Setting["PrefixSuffixNamingRequirement"] ="# [GroupName]"
Set-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id -DirectorySetting $Setting

SMTP Domain

We have created and validated a subdomain for groups, so while our users are, our teams are As above the naming scheme removes the # as a marker, so this is re-established. The result is that the team for #Technology get

#Connect to Exchange Online Powershell then …
New-EmailAddressPolicy -Name Groups -IncludeUnifiedGroupRecipients -EnabledEmailAddressTemplates "" -Priority 1


The intention of group classifications is to get your users to select a marker to define the sensitivity of content that the group is intending to share. It does not do anything other than label the group, but you can read this via Powershell. For example, I have heard of companies that only allow external guests in groups pf particular categories through a script.

In our case we want to define all groups to the same category ‘Internal’. If users have content that matches higher categories we need them to speak to us and our data governance Teams. Setting a default classification is a convenient reminder to users that self-service Teams are for a specific purpose.

#Connect to AzureAD using the V2 preview then …
$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id
$Setting["ClassificationList"] ="Internal"
$Setting["ClassificationDescriptions"]="Internal:General business data for staff and authorised third parties"
Set-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id -DirectorySetting $Setting

Group Expiry

It is little surprise that many new Teams start that do not succeed but I doubt this is peculiar to self-service groups. In the 18 months since we started we have had about 2,500 groups created, and about 1,000 of these are properly active today. We are soon to start turning on the expiry feature so that group owners will need to revalidate that their groups every 6 months.

The options for this are a bit backward, I can apply the policy to all groups or a specific list, it would be far better for us if I could apply to all but exempt specific groups. The best we’ve come up with is a script that runs periodically and looks at each Teams name, if it’s a # the it applies the expiry policy.

#Connect to AzureAD using the V2 preview then …
#Create a policy that requires validations ever 6 months
New-AzureADMSGroupLifecyclePolicy -GroupLifetimeInDays 178 -ManagedGroupTypes "Selected" -AlternateNotificationEmails ""#you'll see the id for the policy, save it then run each night$pol = "<enter the guid here>"
$groups = get-azureadgroup -searchstring "# "
Foreach ($group in $groups) {Add-AzureADMSLifecyclePolicyGroup -Id $pol -groupId $group.objectID}

In summary

You’ll need to decide for your organisation if self-service is right for Teams and group creation, but if you select self-service there are lots of settings you can tailor to avoid the sprawl of poorly named items and reinforce to your users the status of their self-service efforts.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade