Control Microsoft 365 Group Creation

原文：Control Microsoft 365 Group Creation — theDXT (Daniel Keer)

Controlling who can and can’t create Microsoft 365 groups can be a very powerful tool. In this post, I will detail step-by-step how to prevent users from creating Microsoft 365 groups unless they are members of a specific security group.

Prerequisites

• Microsoft Entra ID P1 or P2 is needed for the users who are allowed to create groups. (The old name was Azure Active Directory Premium P1 or P2)
• Microsoft Graph Beta Installed.

The Process

• Login to Microsoft Entra admin center
• Click on Groups > All Groups

• Click on New group

• Make sure the Group type is set to Security.
• Give your group a name. In my example, I will use the name Group Creators.

• Add anyone that you want to have the power to create Microsoft 365 Groups to the security group you just created.
• Open PowerShell ISE.
• Copy the script from Microsoft here.
• On line 6 enter the name of the security group you just created. In my case, that group is called Group Creators.

The beginning of the script should look something like this.

Import-Module Microsoft.Graph.Beta.Identity.DirectoryManagement
Import-Module Microsoft.Graph.Beta.Groups

Connect-MgGraph -Scopes "Directory.ReadWrite.All", "Group.Read.All"

$GroupName = "Group Creators"
$AllowGroupCreation = "False"

$settingsObjectID = (Get-MgBetaDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id

Code language:PowerShell(powershell)
The script will use Microsoft Graph to connect your Microsoft 365 tenant and turn off group creation and set it so that only members of the security group we created are allowed to make Microsoft 365 groups and it will output the Object Id of that group in the results.

If you want to read more about Microsoft Graph I wrote a post that goes into more detail on the setup of Microsoft Graph called Microsoft 365 Setup Microsoft Graph PowerShell SDK.

• Run the script.

You should get an output similar to the image below.

Output from the script

Let’s confirm it worked.

• Log in to OWA with an account that is not a member of Group Creators and click on Groups. You should no longer see the New group option.

OWA for a user that is not a member of Group Creators

• Log in to OWA with an account that is a member of Group Creators and click on Groups. You should see the New group option.

OWA for a user that is a member of Group Creators

That’s all it takes to control who can and can’t create a Microsoft 365 Group in your Microsoft 365 tenant.

If you want to read more about restricting who can create Microsoft 365 Groups you can read the Microsoft Documentation about it here.

Why You Should Restrict Group Creation

By default, every user in a Microsoft 365 tenant can create a Microsoft 365 group — and with it a mailbox, a SharePoint site, a Planner plan, a OneNote notebook and a Teams team. That default is generous in a small organisation and genuinely hazardous at scale. The problems it creates are predictable:

• Naming sprawl. Without a naming policy you end up with "Marketing Team", "marketing team", "Marketing-Team-2024" and "Marketing (do not use)" — all live, all resolvable, all indexed by search.
• Shadow IT. Groups are created outside any governance process, so nobody can enumerate what exists, who owns it, or what data sits inside it.
• Orphaned ownership. The creator leaves the company and the group has no second owner. Nobody can administer it, and it survives as an unmanaged data store indefinitely.
• Guest access by default. Depending on your tenant settings, a freshly created group may accept external members immediately, widening your data perimeter without a single approval.
• Licensing surprises. Some workloads attached to groups consume licences, and uncontrolled creation makes cost forecasting harder than it needs to be.

The control described in this post is a targeted one: it does not remove the ability to create groups, it moves that ability behind membership of a specific security group. That is the right trade-off for most organisations, because it keeps self-service available for the people who need it while giving IT a single, auditable list of who is allowed to act.

Prerequisites and Licensing Detail

Two things are required, and the first is easy to get wrong:

• Microsoft Entra ID P1 or P2 for the users who will be permitted to create groups. The directory setting itself is a tenant-level object, but the group-based scoping of "who may create" is an Entra ID Premium capability. If your administrators have P1 and your intended creators do not, the setting will exist but the creators will still be blocked — which is a confusing failure mode worth ruling out first. Confirm the licence assignments under Entra admin center > Users > [user] > Licenses before you start.
• The Microsoft Graph PowerShell SDK, specifically the beta modules Microsoft.Graph.Beta.Identity.DirectoryManagement and Microsoft.Graph.Beta.Groups. The cmdlets used below (the MgBeta verbs) exist only in the beta surface; the v1.0 module will report that the cmdlet is not recognised.

Installation and authentication, if you have not already connected a workstation to the tenant:

Install-Module Microsoft.Graph.Beta -Scope CurrentUser
Import-Module Microsoft.Graph.Beta.Identity.DirectoryManagement
Import-Module Microsoft.Graph.Beta.Groups

Connect-MgGraph -Scopes "Directory.ReadWrite.All","Group.Read.All","Group.ReadWrite.All"

The connection is delegated and interactive by default, so the account you authenticate with must hold a directory role that can write tenant settings — Global Administrator, or a custom role with the directory settings permission. For automation, a certificate-based app registration with the relevant application permissions is the better long-term answer than a stored credential.

The Full Script Explained

The Microsoft-published script is short, and reading it line by line makes the later troubleshooting much easier. This is the same logic, annotated:

Import-Module Microsoft.Graph.Beta.Identity.DirectoryManagement
Import-Module Microsoft.Graph.Beta.Groups

Connect-MgGraph -Scopes "Directory.ReadWrite.All", "Group.Read.All"

# The security group whose members are allowed to create groups
$GroupName = "Group Creators"
$AllowGroupCreation = "False"

# Locate the tenant-level Group.Unified settings template instance
$settingsObjectID = (Get-MgBetaDirectorySetting |
    Where-Object -Property DisplayName -Value "Group.Unified" -EQ).Id

# Resolve the security group object id by display name
$group = Get-MgBetaGroup -Filter "DisplayName eq '$GroupName'"

# Build the settings payload
$params = @{
    Values = @(
        @{ Name = "EnableGroupCreation";        Value = $AllowGroupCreation }
        @{ Name = "GroupCreationAllowedGroupId"; Value = $group.Id }
    )
}

Update-MgBetaDirectorySetting -DirectorySettingId $settingsObjectID @params

Three details matter. First, Get-MgBetaDirectorySetting returns the tenant's settings instances by template; Group.Unified is the one that governs Microsoft 365 group behaviour as a whole, while Group.Unified.Guest governs guest permissions specifically. If the lookup returns nothing, the template has never been instantiated in the tenant and must be created with New-MgBetaDirectorySetting -TemplateId <templateId> first — you can find the template id with Get-MgBetaDirectorySettingTemplate. Second, GroupCreationAllowedGroupId takes the object id, not the display name, which is why the script resolves the group into $group.Id rather than writing the name into the setting. Third, EnableGroupCreation = False is what makes the allow-list authoritative; setting it to True leaves creation open to everyone regardless of the allowed-group value.

Other Settings on the Same Template

Because the Group.Unified instance is a general-purpose settings container, it is worth reviewing the neighbouring values while you are in there. The same Update-MgBetaDirectorySetting call can set:

• EnableGroupCreation — the master switch.
• GroupCreationAllowedGroupId — the security group allow-list.
• UsageGuidelinesUrl — a URL surfaced in the group creation UI, typically your internal governance page.
• ClassificationList — comma-separated values that appear as a classification drop-down at creation time, useful for marking groups as Public, Internal or Confidential.
• EnableMSStandardGroupCreation — controls whether the above settings apply only to Microsoft 365 groups while leaving security and mail-enabled security groups unrestricted.
• AllowGuestsToBeGroupOwner and AllowGuestsToAccessGroups — guest access controls that pair naturally with creation restrictions.

Confirm what is currently in place before changing anything:

Get-MgBetaDirectorySetting | Format-List DisplayName, Id, Values

Verifying the Change

The web verification in the walkthrough above is the check that matters, because it exercises the exact code path a user would hit. To verify programmatically as well:

# Read the value back from the tenant
(Get-MgBetaDirectorySetting -DirectorySettingId $settingsObjectID).Values |
    Where-Object Name -in "EnableGroupCreation","GroupCreationAllowedGroupId"

# Confirm who the allow-list currently contains
Get-MgBetaGroupMember -GroupId $group.Id |
    Select-Object -ExpandProperty AdditionalProperties

# Prove the setting is enforced, running as a non-member
Connect-MgGraph -Scopes "Group.ReadWrite.All"
New-MgBetaGroup -DisplayName "Test Governance Group" `
                -MailEnabled:$false `
                -MailNickname "test-governance-group" `
                -SecurityEnabled:$true

The final command should fail with an authorisation error when run by a user who is not a member of the allow-list group, and should succeed for a member. That is the definitive test — the portal hiding the "New group" button is a user-experience hint, not the enforcement point.

Be aware of the surfaces that are not covered. Users can still create a security group or a mail-enabled security group if your directory role settings permit it, and they can still create a SharePoint site or an Azure resource group depending on your other policies. If your objective is a single coherent boundary, pair this setting with the equivalent controls for the workloads you actually run, and review how you scope access with Entra ID Conditional Access What If before rolling out a broader change.

Reversing the Change

The control is fully reversible, and you should rehearse the reversal so that a future administrator is not left hunting for a portal toggle that does not exist:

# Allow everyone to create groups again
$params = @{
    Values = @(
        @{ Name = "EnableGroupCreation";         Value = "True" }
        @{ Name = "GroupCreationAllowedGroupId"; Value = "" }
    )
}
Update-MgBetaDirectorySetting -DirectorySettingId $settingsObjectID @params

Note that leaving GroupCreationAllowedGroupId populated after re-enabling creation is harmless but confusing; clear it so the tenant state reflects the actual intent. Changes to directory settings can take a short while to propagate to every workload, so if a user still cannot create a group immediately after the change, wait a few minutes and have them sign out and back in before escalating.

Governance Beyond the Switch

Restricting creation is the entry point, not the whole policy. Once only nominated users can create groups, revisit the other four corners of group lifecycle management:

• Naming policy. A prefix or suffix policy detects duplicate names early and can block a set of reserved words. It applies to the creation UI and to the Graph API alike.
• Expiration policy. Groups expire after a set period unless an owner renews them. This is the single most effective control against orphan accumulation and it is available in Entra ID P1 and above.
• Owner requirements. Require at least two owners, and a creator is automatically an owner. This addresses the departing-employee scenario that creates unmanageable groups.
• Guest policy. Decide deliberately whether group owners or only administrators may invite guests, and give guest access an expiration date where your licensing supports it.
• Access reviews. Use Entra ID Governance access reviews to periodically recertify membership, which is the pattern covered in Entra ID Governance entitlement management access packages.

A practical rollout order is: restrict creation first (this post), then add a naming policy, then enable expiration, then introduce access reviews. Each step is independently reversible and none of them requires a service outage. Where the same governance questions apply at the tenant level, enabling organization customization covers the prerequisite you will need for some of the related settings, and if you are building a disposable test environment, see deleting a Microsoft 365 tenant for the full teardown sequence.

Troubleshooting

• "The term 'Get-MgBetaDirectorySetting' is not recognized". You installed the v1.0 module instead of the beta module. Install Microsoft.Graph.Beta and re-import.
• The settings lookup returns $null. The Group.Unified template instance does not exist yet in the tenant. Create it from the template before trying to update it.
• The script runs without error but nothing changed. You authenticated with an account lacking rights to write directory settings, or you connected to the wrong tenant. Re-run Get-MgContext to confirm the tenant id and account.
• A user with P1 still cannot create a group. They are not a member of the allow-list group — licence alone does not grant the ability. Add them and have them sign out and back in.
• Some users see the New group button but creation fails server-side. Cached client state. Have them clear the browser session; the server-side setting already won.