Restricting Microsoft 365 Group Creation to an Approved Security Group

To stop everyone in a tenant creating Microsoft 365The KBY LexiconMicrosoft 365Microsoft 365 defined at plain and technical depth, with architecture, operational relevance, an example and a common misunderstanding for practitioners. Read Full Context Groups, keep a single security group of approved creators, then set two values in the tenant-wide Group.Unified directory setting with Microsoft Graph PowerShell: EnableGroupCreation to False and GroupCreationAllowedGroupId to that group’s object ID. Capture the existing values before you change anything, because the same object also holds naming, guest and sensitivity label settings. Microsoft documents that the change can take 30 minutes or more to take effect, that it affects every service that relies on groups for access (Teams, Planner, SharePoint, Outlook, Viva Engage and others), and that several admin roles keep the ability to create groups regardless. The administrator who configures it and the members of the approved group need Microsoft Entra IDThe KBY LexiconMicrosoft Entra IDA concise technical definition of Microsoft Entra ID: what it is, how it fits identity architecture, and where engineers must validate before change. Read Full Context P1 or P2 (or Microsoft Entra Basic EDU) licences. Rolling back means setting EnableGroupCreation to True and clearing the group ID.

#Context: why a single directory setting controls group sprawl

By default, every user in a Microsoft 365 tenant can create a Microsoft 365 Group. Microsoft recommends leaving it that way, because it lets people start collaborating without waiting for IT. Organisations restrict creation when uncontrolled teams and plans have become a governance problem. Microsoft suggests tying the permission to something meaningful, such as completing a training course, then adding people who qualify to the approved group.

The restriction is not a Teams setting or a SharePoint setting. It lives in Microsoft Entra ID and affects every service that relies on Microsoft 365 Groups for access. Microsoft lists the affected services as Outlook, SharePoint, Viva Engage, Microsoft TeamsThe KBY LexiconMicrosoft TeamsA concise plain and technical definition of Microsoft Teams, covering architecture, operational relevance, a bounded example and a common misunderstanding. Read Full Context , Planner, Power BI (classic) and Project for the web / Roadmap. Restricting creation changes all of them at once.

The usual discipline applies: record the state, make one bounded change, verify it from the user’s side and keep the way back ready, as described in bounded change operations in Microsoft 365.

#Architecture: the Group.Unified settings object

Microsoft 365 group behaviour for the whole directory is held in a settings object created from the Group.Unified settings template, whose template ID is 62375ab9-6b52-47ed-826b-58e47e0e304b. A new tenant has no such object at all: Microsoft Entra ID applies built-in defaults until an administrator creates one. In the Microsoft Graph v1.0 API the resource is called groupSetting; in the beta API, which the documented PowerShell procedure uses through the Microsoft.Graph.Beta module, it is called directorySetting.

Two values in that object implement the restriction:

• EnableGroupCreation (Boolean, default True) decides whether non-admin users can create Microsoft 365 Groups in the directory. On its own it does not require a Microsoft Entra ID P1 licence.
• GroupCreationAllowedGroupId (string, default empty) holds the GUID of the group whose members may still create Microsoft 365 Groups when EnableGroupCreation is false.

Several design constraints follow from that model:

• One allowed group per tenant. Only one group can control creation. To delegate to several teams, nest their groups as members of the approved group rather than trying to list several IDs.
• Members, not owners. People and nested groups must be added as members of the approved group. Microsoft’s procedure is explicit that membership is what counts.
• Group type. The template reference describes the value as the GUID of a security group, while the Microsoft 365 solutions guidance also allows a Microsoft 365 group. A dedicated security group with no other purpose is the cleaner choice.
• Shared object. The same Group.Unified object also stores the naming policy, blocked words, guest access, usage guideline URLs, classification and the EnableMIPLabels sensitivity label switch. A change to group creation is a change to an object other teams depend on.
• Admin roles bypass it. The setting governs non-admin users. Members of the roles in the following table can still create groups in the locations shown, and Global Administrators can create them from the Microsoft 365 admin center, Planner, Exchange and SharePoint, though not from Teams.

Those roles can create groups on behalf of restricted users and make the requester the owner, which gives you a supported request path for people outside the approved group. Outlook adds a second, independent gate: the GroupCreationEnabled parameter of an Outlook on the web mailbox policy controls whether Microsoft 365 Group creation is offered in Outlook and Outlook on the web. It defaults to $true. Do not confuse either control with the per-group Group.Unified.Guest template, which manages guest access on an individual group.

#Implementation: capture, change and record

Preconditions before any change:

• Run the procedure first in a non-production tenant if you have one, and schedule the production change for a time when group creation requests are low.
• Use an account in the least privileged role that can do the job. Microsoft reserves Global Administrator for emergencies when no other role will do.
• Assign Microsoft Entra ID P1 or P2, or Microsoft Entra Basic EDU, licences to the configuring administrator and to every member of the approved group. Group-based licensing is the usual way to do this at scale; if it reports conflicts, fixing MutuallyExclusiveViolation in group licensing covers the common one.
• Install or update the Microsoft Graph PowerShell beta module: Install-Module Microsoft.Graph.Beta -Scope AllUsers, or Update-Module Microsoft.Graph.Beta if it is already present.
• Create the approved group (for example, a security group called Group Creators) in the Microsoft 365 admin center under Groups, Add a group, and add the people or nested groups as members.

Implementation steps:

1. Connect and capture the current state. This step is read-only. Get-MgContext confirms which account and tenant the session is signed in to; check it before going further. The last line saves every current value to a file you keep with the change record.

   Terminal

   1Connect-MgGraph -Scopes "Directory.ReadWrite.All", "Group.Read.All"
   2Get-MgContext
   3
   4$Setting = Get-MgBetaDirectorySetting | Where-Object { $_.DisplayName -eq "Group.Unified" }
   5$Setting.Id
   6$Setting.Values
   7$Setting.Values | ConvertTo-Json -Depth 5 | Out-File -FilePath .\Group.Unified-before.json

   If $Setting comes back empty, the tenant has no Group.Unified object and is running on defaults. Record that fact: it changes both the implementation and the rollback.

2. Resolve exactly one group ID. Filtering by display name is read-only, but display names are not unique. Stop if the command returns nothing or more than one ID, and use the object ID from the Microsoft Entra admin center instead.

   Terminal

   1$GroupId = (Get-MgGroup -Filter "DisplayName eq 'Group Creators'").Id
   2$GroupId

3. Apply the change. This is the state-changing step. It writes only the two creation values; the other values in the object are compared against the capture in the next section.

   Terminal

   1$params = @{
   2   templateId = "62375ab9-6b52-47ed-826b-58e47e0e304b"
   3   values = @(
   4      @{
   5         name = "EnableGroupCreation"
   6         value = "False"
   7      }
   8      @{
   9         name = "GroupCreationAllowedGroupId"
   10         value = $GroupId
   11      }
   12   )
   13}
   14
   15# Group.Unified object already exists (captured above)
   16Update-MgBetaDirectorySetting -DirectorySettingId $Setting.Id -BodyParameter $params
   17
   18# Only if the capture returned nothing: create the object instead
   19# $Setting = New-MgBetaDirectorySetting -BodyParameter $params

   Microsoft’s published script creates a missing object with EnableMSStandardBlockedWords set to true. The template reference marks that setting as deprecated with the instruction not to use it, so create the object with only the two values you need.

4. Record the change. Keep the before file, the settings object ID, the approved group’s ID and the time of the change in the change ticket, so the rollback can be run by someone else.

#Validation: prove the restriction from both sides

First read back the object. The output lists every setting in the template; the two you changed should show the new values and every other line should match the before file.

(Get-MgBetaDirectorySetting -DirectorySettingId $Setting.Id).Values

Expected shape of the relevant lines:

1Name                            Value
2----                            -----
3...
4GroupCreationAllowedGroupId     <the GUID held in $GroupId>
5...
6EnableGroupCreation             False
7...

Then test from the user’s side. Microsoft notes the change can take 30 minutes or more to take effect, so a test run immediately after the change proves nothing.

1. Sign in as a user who is not in the approved group and holds none of the admin roles in the table.
2. Open Planner and select New plan. The expected result is a message that plan and group creation is disabled.
3. Repeat with a member of the approved group. Plan creation should succeed, creating a new Microsoft 365 Group; delete that test plan and group afterwards through your normal process.
4. If a member of the approved group is still refused, check the Outlook on the web mailbox policy assigned to them before changing anything else.

#Failure modes and what they look like

• Restricted users can still create groups. The change has not propagated yet, or the test account holds one of the admin roles that bypass the setting. Wait out the propagation period and retest with a plain user account.
• Approved members are refused. Check that each member has the documented Microsoft Entra ID P1 or P2 licence, was added as a member rather than an owner, and is not under an Outlook on the web mailbox policy with group creation turned off, which Microsoft names as a cause. Read the policies with the commands below; this is read-only.
  Terminal

  1Get-OwaMailboxPolicy
  2Get-OwaMailboxPolicy -Identity <PolicyName> | Format-List

  Look for GroupCreationEnabled in the output. $false blocks creation in Outlook and Outlook on the web for mailboxes under that policy.

• The wrong group was approved. A display-name lookup matched a different group. The read-back shows a GUID that differs from the intended group’s object ID. Rerun the change with the correct ID.
• Naming, guest or label behaviour changed at the same time. Another value in Group.Unified was overwritten. Compare the read-back with the before file and restore the affected values from it with the same update cmdlet.
• Self-service requests pile up. People who used to create teams can no longer do so. Publish a request route and name an owner for the approved group before the change.

#Security considerations

The Directory.ReadWrite.All scope that the procedure requests is broad: it can change much more than group settings. Run it from a dedicated administrative session and do not leave a script running with that scope. Prefer the least privileged role that can complete the change, as Microsoft advises, and keep Global Administrator for emergencies.

Membership of the approved group becomes a delegated privilege. Treat additions to it as a reviewed change, keep its membership short, and nest only groups whose own membership you also control. Remember the boundaries: the restriction covers Microsoft 365 Groups for non-admin users only. It does not stop people creating security groups, which Microsoft controls separately through the AllowedToCreateSecurityGroups property set with Update-MgPolicyAuthorizationPolicy, and it does nothing about the admin roles in the table. Nor does it change how existing groups admit guests; that is the job of the guest settings in the same object and, for tenant access, Conditional Access, where problems such as legacy authentication blocked with AADSTS53003 are handled.

#Recovery and rollback

Rolling back restores the default behaviour by turning creation back on for everyone and clearing the approved group. Microsoft’s own guidance for turning off the restriction is the same: an empty group name and creation allowed. Run it from the same kind of session used for the change, then read back the values and compare them with the before file.

1$params = @{
2   templateId = "62375ab9-6b52-47ed-826b-58e47e0e304b"
3   values = @(
4      @{
5         name = "EnableGroupCreation"
6         value = "True"
7      }
8      @{
9         name = "GroupCreationAllowedGroupId"
10         value = ""
11      }
12   )
13}
14Update-MgBetaDirectorySetting -DirectorySettingId $Setting.Id -BodyParameter $params
15(Get-MgBetaDirectorySetting -DirectorySettingId $Setting.Id).Values

• Precondition: the settings object ID is known (from the capture or the read-back) and the session is connected to the right tenant according to Get-MgContext.
• Expected result: EnableGroupCreation reads True, GroupCreationAllowedGroupId is empty, and every other value matches the before file. Allow the same propagation time before testing from a user account.
• If the object did not exist before the change: still roll back by setting the values as shown. Remove-MgBetaDirectorySetting deletes the whole directory-level object, including any naming, guest or label settings added later, so it is not a safe rollback and is deliberately left out here.
• Switching to a different approved group is not a rollback: rerun the implementation step with the new group’s ID.

#Operating group creation control after go-live

Once the restriction is live, three checks keep it honest. Read the Group.Unified values after any change to naming, guest or label policy, and compare EnableGroupCreation and GroupCreationAllowedGroupId with the change record, because those changes write to the same object. Review the approved group’s membership and licence assignments on a fixed schedule, since the licensing requirement covers every approved member. Watch for new or changed Outlook on the web mailbox policies with GroupCreationEnabled set to $false, which silently undercut the approved group. The rollback boundary is narrow: two values, one object, one update call. The next safe decision is organisational: agree who owns the approved group, how requests from everyone else reach an administrator who can create groups on their behalf, and what a requester must complete, such as a training course, before joining it.