Teams. We love it. It’s a place where we and our, well… teams, can have focused and topic centric conversations in an interface that also gives us access to the very data we’re talking about. We can edit our files together, chat, have a quick call or even a group meeting, all from within teams. It’s great!
For each team created in Teams, we’re given a SharePoint site collection for storing and organizing the files uploaded in Teams. With that site collection comes an Microsoft 365 group to provide permissions and security.
In one quick and easy step Teams automatically gives us the security and document management features we have come to rely on over the years. It’s pretty good stuff, until we start thinking about, you know, the “G-Word” and the implications of anyone and everyone creating sites and groups. We do love Teams. We also kind of fear it.
The Common Problem
What we’ve seen happen is this: Bob in HR is excited to have Microsoft Teams for internal Human Resources projects. As an early adopter, Bob creates an HR Team (in Teams) and gets to work populating his group and setting up channels. Meanwhile, Nancy in Benefits is equally thrilled and busily building her own HR Team. Now we have two Microsoft 365 Groups created for HR and two SharePoint site collections.
This has been quite the conversation topic for Teams since we all realized that anyone with the ability to create a Team was also creating sites and Microsoft 365 Groups in the background. Most of us already have naming conventions, policies and guidelines, also known as Governance (there, I said it) set up to help manage the creation of security groups. We don’t need Bob and Nancy using official department naming conventions for unofficial purposes.
One reaction to this has been to restrict who can create teams. In doing so we’ve just removed core functionality from a great communication and productivity tool. Fear not; in December, a support article was written by Microsoft, outlining the new Microsoft 365 Groups Naming Policy. Note, this policy requires the Preview version Azure Active Directory Module for Windows PowerShell.
Using PowerShell, administrators will be able to apply prefixes using short Fixed Strings or Attributes and set restrictions such as blocked words. Fixed strings could include keywords such as ‘Grp_Name’, ‘#Name’, ‘_Name’. Supported Azure AD attributes are [Department], [Company], [Office], [StateOrProvince], [CountryOrRegion], [Title], and [CountryCode].
By using attributes we could have a policy that looks something like this: Policy = “GRP [GroupName] [Department] [StateOrProvence]” and gives us the name: GRP HR Training Initiatives Oklahoma.
*Attributes must be set in AD to work in naming policies.
As a test, our admin created a script that looks like this:
As you can see, the policy will include the user’s department, name of the Team (and M365 Group), and user’s country. The word we tested to block is “banned”.
A simpler policy might just block particular department abbreviation, if your company wants that reserved for official use in naming objects. If a user tried to create a Team using a blocked term, they would see the message as displayed in the Create your team dialogue below.
Remember, this will apply to Microsoft 365 Groups, it’s not specific to Teams and will aid in reinforcing and supporting your company’s naming conventions throughout the Microsoft 365 landscape. And, in case you were worried, there are Admin override settings.
Governance is traditionally a pain point for most organizations. As the Microsoft 365 platform expands we are challenged to adapt and evolve our policies and even the way we work with our teams. Tools such as this can help address areas of concern as the landscape of Microsoft 365 evolves.
The group naming policy does require Azure Active Directory Premium P1 license for unique users that are members of Microsoft 365 groups.
For more information in setting up the naming policy, including instructions for installing the preview version of Azure Active Directory Module for Windows PowerShell follow this link: Microsoft 365 Groups naming policy.