A screenshot showing the blocked words interface in the Naming Policy interface

A phrase (perhaps) overly used in recent months / years is that of “User Empowerment”; that slightly cheesy phrase attached to services that hand flexibility and choice to end users in how they’re used. It’s also particularly true of Office 365, where features and services are released almost weekly that focus on user experience first, and administrators second. In many respects this shouldn’t be a surprise - it’s an intrinsic part of Microsoft’s mission statement after all - but that stance doesn’t come without issue…

An increasing challenge for many IT Departments is the proliferation of Groups that results from use of Microsoft Teams (in particular). Many accept just how fantastic Teams is at fostering collaboration, but the appearance of “Dave’s Test Group”, “Jane Personal”, and “Project Potato” in our Azure AD tenants doesn’t sit well with most. It’s also counter productive for those looking for useful Groups and Teams to join. Enter Azure AD Naming Policies - in existence for a while, but subject to some recent enhancements.

Group Naming Policies

For quite some time now we’ve been able to enforce a Naming Policy for Office 365 Groups. This extends to the implementation of blocked word lists for Group names… but it’s never been that straightforward. To date, configuration of these policies has been achieved using the PowerShell script below. Not complicated in itself, but unfriendly for monitoring and updating:

$BlockedWords = "<WordList>"

$PrefixSuffix = "<PrefixSuffixNaming>"

Connect-AzureAD

try
    {
        $template = Get-AzureADDirectorySettingTemplate | ? {$*.displayname -eq "group.unified"}
        $settingsCopy = $template.CreateDirectorySetting()
        New-AzureADDirectorySetting -DirectorySetting $settingsCopy
        $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
    }
catch
    {
        $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id       
    }

$settingsCopy = Get-AzureADDirectorySetting -Id $settingsObjectID

$SettingsCopy["PrefixSuffixNamingRequirement"] = $PrefixSuffix

$SettingsCopy["CustomBlockedWordsList"] = $BlockedWords

Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy

(Get-AzureADDirectorySetting -Id $settingsObjectID).Values

Words defined in the $BlockedWords variable are prohibited from use, and the $PrefixSuffix is applied automatically. This latter object can be a static string, one of the following Azure AD attributes, or a combination of the two:

  • Company
  • CountryOrRegion
  • Department
  • Office
  • StateOrProvince
  • Title

So what’s changed?

Group Naming Policies are now available to configure in the Azure AD portal (albeit Preview)! 🙂 In the Groups node of the Azure Active Directory Portal we have a new Setting available: Naming Policy (Preview) containing two tabs; Blocked words, and Group naming policy:

A screenshot showing the blocked words interface in the Naming Policy interface
A screenshot showing the Group Naming policy interface in the Naming Policy interface

These two new sections allow us to define the policy, and see at a glance what settings are configured. Infinitely more user friendly than PowerShell, and far, far easier to see what’s policies are being enforced on our users. We can also more easily view the prefixes being applied, and the supported attributes (a list I hope will grow in time, and extend to custom attributes):

A screenshot showing the available prefix and suffix selection options

The end user experience hasn’t changed. Naming Policies apply across the board in Azure AD and are invoked as soon as users type a new group name. Prefixes applied to Groups are shown in a preview, and blocked words are highlight to inform removal. For a summary of the experience across Office 365 apps, refer here.


From my perspective, this is a fantastic new addition. It simplifies the experience for administrators, and highlights the feature to those that possibly didn’t know it existed. It also delivers some much needed control, while retaining the freedom for users to consume services as they want to… win win!

The inclusion in the Azure AD portal might be a minor tweak, but it’s likely to make some incredibly happy. Thank you Azure AD team!