🛡️🧑💼👈Group - Microsoft 365 Group Creators
The single allow-list that decides who may spin up a Microsoft 365 Group, and with it a Team, a SharePoint site, a mailbox and a Planner, in one click.
What this group is about 🛡️
Out of the box, every user can create a Microsoft 365 Group. And a Microsoft 365 Group is never just a group: create one and you have also created a Team, a SharePoint site, a shared mailbox, a Planner plan, and a chunk of storage, all at once, with an owner who may not know any of that just happened.
This group is the fix. You stand up one security group, put the people who are actually allowed to create groups inside it, and point the tenant's group-creation setting at it. From then on, creation is gated: members of this group (and a short list of admin roles) can create; everyone else gets a polite "not allowed."
The group on its own does nothing. It becomes the gate only once you wire it to the Group.Unified directory setting, which is the second half of this page. The group is the who; the directory setting is the lock it fits.
"Everyone can create" is a great collaboration story and a terrible governance one. Every self-served group is a SharePoint site with data in it, a mailbox that can receive external mail, and a lifecycle nobody signed up to manage. Multiply by a company's worth of Tuesday afternoons and you are not running a tenant, you are running a landfill with search enabled.
Why this matters 🕵️
A group is an iceberg. 🧊 The Team is the tip; under the waterline sit a SharePoint site, a mailbox, a calendar, a Planner, and storage, each a place data lands and each a thing that has to be secured, backed up, reviewed and eventually retired. Unrestricted creation means all of that appears on demand, unnamed by any convention, owned by whoever clicked, and governed by nobody.
Sprawl is not a tidiness problem, it is an attack-surface problem. 🎯 Every abandoned site is data with no steward, that two-week project that spun up a Team back in March and is now a haunted SharePoint site nobody will admit to owning. Every duplicate "Project Falcon", "Project Falcon (final)", and "Project Falcon FINAL v2 (use this one)" is one place the right file might live and three places it might leak from. Every group with external sharing left on is a door you did not know you had. The mess is not cosmetic; it is exposure that compounds while nobody is looking.
Lifecycle starts at birth. 👶 You cannot govern what you did not gate. Naming conventions, expiration, ownership, sensitivity labels, guest rules, none of it sticks if anyone can mint a new group outside the process at any moment. Restricting creation is the hinge the rest of group governance hangs on: control the front door and the room stays manageable; leave it open and you are forever cleaning up after the fact.
Locking creation to a governed group does not stop collaboration. It stops unmanaged collaboration, and routes the real requests through people who will name it, own it, and remember it exists next quarter.
🛠️ Configuration
Three moves: build the group, wire the setting, prove it works.
Step 1: Create the group
Create a normal security group (this one), assigned membership, and put your allowed creators inside as members (not owners). Keep it small; see the Membership scope section below.
One hard rule from the platform: only a single group can control group creation. If you need several populations to have the right, nest those groups inside this one rather than trying to point the setting at more than one.
Step 2: Wire it to the Group.Unified directory setting
There is no portal toggle for this; it lives in the directory settings and is set with the Microsoft Graph Beta PowerShell module. The setting turns creation off for everyone (EnableGroupCreation = False) and then hands the key to exactly one group (GroupCreationAllowedGroupId).
Import-Module Microsoft.Graph.Beta.Identity.DirectoryManagement
Import-Module Microsoft.Graph.Beta.Groups
Connect-MgGraph -Scopes "Directory.ReadWrite.All", "Group.Read.All"
$GroupName = "🛡️🧑💼👈Group - Microsoft 365 Group Creators" # the group you created in Step 1
$AllowGroupCreation = "False"
# Grab (or create) the Group.Unified directory setting
$settingsObjectID = (Get-MgBetaDirectorySetting |
Where-Object -Property DisplayName -Value "Group.Unified" -EQ).Id
if (!$settingsObjectID) {
$params = @{
templateId = "62375ab9-6b52-47ed-826b-58e47e0e304b"
values = @(
@{ name = "EnableMSStandardBlockedWords"; value = $true }
)
}
New-MgBetaDirectorySetting -BodyParameter $params
$settingsObjectID = (Get-MgBetaDirectorySetting |
Where-Object -Property DisplayName -Value "Group.Unified" -EQ).Id
}
# Resolve the allow-list group's object ID
$groupId = (Get-MgBetaGroup -All | Where-Object { $_.DisplayName -eq $GroupName }).Id
# Lock creation to that one group
$params = @{
templateId = "62375ab9-6b52-47ed-826b-58e47e0e304b"
values = @(
@{ name = "EnableGroupCreation"; value = $AllowGroupCreation }
@{ name = "GroupCreationAllowedGroupId"; value = $groupId }
)
}
Update-MgBetaDirectorySetting -DirectorySettingId $settingsObjectID -BodyParameter $params
# Confirm
(Get-MgBetaDirectorySetting -DirectorySettingId $settingsObjectID).Values
To change which group holds the key later, rerun with a new $GroupName. To turn the restriction off entirely and hand creation back to everyone, set $GroupName = "" and $AllowGroupCreation = "$true" and rerun.
Step 3: Verify it works
Give it time: changes can take 30 minutes or more to land. Then sign in as a user who is not a member and not an admin, open Planner, and try New Plan. You should be told plan and group creation is disabled. Repeat as a member of the group; it should work.
What "creation" covers
Gating this one setting reaches every service that leans on Microsoft 365 Groups:
- Microsoft Teams
- SharePoint
- Outlook (group mailboxes)
- Planner
- Viva Engage
- Power BI (classic)
- Project for the web / Roadmap
Caveats ⚠️
Admins keep their keys. 🔑 This does not stop privileged roles. Global Administrator, Exchange Administrator, User Administrator, Groups Administrator, SharePoint Administrator, Teams Administrator, Directory Writers and the Partner support roles can still create groups through their respective portals, whether or not they are in this group. That is expected: the control governs users, not administration. It is also a nudge to keep those roles few and deliberate.
One group, and only one. ☝️ The tenant accepts a single GroupCreationAllowedGroupId. Need more than one population to create groups? Nest those groups inside this one. Pointing the setting at a second group is not an option the platform gives you.
Existing groups are untouched. This gates new creation only. Everything already in the tenant keeps working exactly as before, so switching this on is safe to do mid-flight; it changes tomorrow's groups, not today's.
License fit (MKB lens). 💼 The admin who configures this and every member of the allow-list group need Entra ID P1. The good news for the baseline: Business Premium includes P1, so in a standard Business Premium tenant this is already covered. The watch-out: in a mixed-licensing tenant, make sure the people you drop into this group actually hold a P1 (or higher) license, or their create rights silently do not apply. Users who are merely members of Microsoft 365 Groups, and cannot create them, need nothing extra.
Propagation is not instant. Budget half an hour before testing, and do not conclude it failed at minute five.
A second lock can hide here. If a member still cannot create groups after everything looks right, check their Outlook on the web mailbox policy; that can independently block group creation and will happily make your directory setting look broken.
Reversibility. Clean-revert, one script away in each direction. Set EnableGroupCreation back to True and self-service is open to the whole tenant again, no residue, no announcement. That is a relief when you mean it and a landmine when a migration run or a "cleanup" script flips it for you. Watch the setting itself, not your intention to have restricted it.
👥 Membership scope
Assigned (manual) membership, kept short on purpose. This is a capability, not a perk.
Who belongs in it: the IT or MSP staff who provision collaboration spaces, plus any delegated power users you have deliberately trained to name, own and steward a group properly. The point is not to make creation rare; it is to make it accountable. If you want a lightweight self-service path, a common pattern is to require a short training or a request step and then add the person here, so the right to create comes with knowing what creating entails.
Keep it lean and reviewed. Every member is someone who can generate a Team, a site and a mailbox at will. Review the membership on a schedule and prune the people who no longer need it, the same way you would any privileged access. A creators group that has quietly grown to half the company is just the open front door with extra steps.
Nesting is the pressure valve. When distinct teams each need the right, add their group as a member of this one rather than widening the flat list. It keeps the allow-list readable and lets you grant and revoke by team.
🔗 Related
- 🏢🧑💼TS - Default User Permissions: the same reflex one layer down, closing the other self-service doors that ship open in identity.
- 🧩🧑💼AC - User Consent for Applications: another "anyone can, by default" switch where the governed answer is to gate it to a controlled few.
Collaboration should be easy to ask for and hard to litter with. Gate the front door to one accountable group, and every new group arrives named, owned, and expected. 🛡️