Group-Based Licensing in Microsoft Entra ID for M365

One of the most common tickets a junior engineer inherits in an enterprise Microsoft 365 environment is inconsistent or missing license assignment: a new hire can sign in but Outlook never provisions a mailbox, or Teams is missing for an entire department. In most tenants this traces back to manual, per-user license assignment that nobody maintains as staff join, move, or leave. The production-grade fix is group-based licensing in Microsoft Entra ID, where licenses are attached to a security group rather than individual accounts, and membership (ideally dynamic, attribute-driven membership) does the assignment work automatically.

This tutorial walks through configuring group-based licensing end to end, verifying it actually applied, and safely rolling it back if it causes a service disruption — the exact skill set expected of a new engineer supporting a live tenant. It also covers the operational discipline around change control, monitoring, and evidence collection that separates a demo-quality configuration from something a service desk can rely on at 2 a.m. without paging a senior engineer.

#Scenario

You have been asked to automate Microsoft 365 E3 and a Power Automate per-user plan for everyone in the Sales department, using the department attribute synchronised from on-premises Active Directory (or set directly in Entra ID for cloud-only tenants). Today this is done manually by the helpdesk team, and it is regularly missed for new starters. The business impact is concrete: a new account executive without Exchange Online for their first three days is a recurring, avoidable complaint, and repeated manual assignment errors erode confidence in the identity team.

#Prerequisites

• Microsoft Entra ID P1 (or higher) licensing in the tenant — required for dynamic group membership rules. Assigned/static groups work on any tier but require manual membership maintenance.
• An account with the License Administrator Entra role, or Groups Administrator if you also need to create the dynamic group. Avoid using Global Administrator for this task.
• Confirmed available license units for the target SKU (checked in Microsoft 365 admin center > Billing > Licenses).
• Microsoft Graph PowerShell SDK installed locally for verification and auditing (Install-Module Microsoft.Graph).
• A confirmed, healthy Azure AD Connect (or Entra Connect) sync cycle if department is sourced from on-premises AD — check the last successful sync timestamp before relying on the attribute.
• A change ticket or request record already logged, even at pilot stage, so the configuration is traceable back to an approved request rather than an ad hoc console change.

#Least-privilege note

License Administrator can assign, remove, and update license assignments for users and groups but cannot create Conditional Access policies or reset arbitrary passwords. Request this role specifically rather than accepting a broader admin role bundled with it — if your organisation uses Privileged Identity Management (PIM), activate it as a time-bound, just-in-time assignment rather than holding it standing. If you also need to create the dynamic group itself, request Groups Administrator for the same limited window; do not request Global Administrator as a shortcut to avoid two separate PIM activations.

#Step 1: Confirm the target SKU and available seats

1. Sign in to the Microsoft 365 admin center at admin.microsoft.com.
2. Go to Billing > Licenses and locate the SKU (for example, Microsoft 365 E3).
3. Note the Unassigned count. If it is lower than your expected department headcount, raise a licensing procurement request before proceeding — group-based licensing will silently fail assignments once seats run out, and affected users show an error state rather than a clear alert.
4. Repeat the same seat check for the Power Automate per-user plan SKU independently; teams frequently confirm the primary SKU has capacity and overlook a smaller add-on SKU running out first.

#Step 2: Create or identify the group

For an attribute-driven population, a dynamic security group is the correct choice.

1. Open the Entra admin center at entra.microsoft.com and navigate to Groups > All groups > New group.
2. Set Group type to Security, provide a clear name such as LIC-Sales-E3, and set Membership type to Dynamic User.
3. Add the dynamic query rule. For a department-based rule:
   snippet.text

   1(user.department -eq "Sales")

4. Save the group. Dynamic membership evaluation is not instant — initial population can take anywhere from a few minutes to several hours depending on tenant size and directory sync load.

If this tenant does not have Entra ID P1, create an Assigned security group instead and accept that membership additions/removals will be manual, or handled through an existing HR-driven provisioning workflow. Name the group consistently regardless of type (a LIC- prefix convention) so that anyone auditing group-based licensing later can distinguish licensing groups from access-control groups at a glance, and so that a future migration from assigned to dynamic membership does not require renaming and re-linking dependent documentation.

#Step 3: Assign the license to the group

1. In the Entra admin center, go to Identity > Users > All users is not the path here — instead go to Identity > Groups, open LIC-Sales-E3, and select Licenses under Manage.
2. Click Assignments > Add assignment, choose the Microsoft 365 E3 SKU.
3. Expand Options and review the individual service plans (Exchange Online, SharePoint, Teams, Stream, etc.). Disable any service plans not approved for this department — for example, if Sales should not receive Yammer/Viva Engage, toggle it off here rather than relying on a separate policy.
4. Confirm the assignment. Entra ID begins processing membership and pushing licenses to each qualifying user.
5. Repeat the assignment step for the Power Automate per-user plan SKU on the same group, reviewing its service plan options separately — each SKU assignment on a group is configured independently, so disabling a plan on one SKU has no effect on another.

#Step 4: Verify the assignment actually applied

Do not close the ticket on the assumption that the group configuration succeeded — verify against real user objects.

1. In the Entra admin center, open a known Sales user’s profile and go to Licenses. Confirm the SKU shows as assigned via group with status Success, not Error or Processing.
2. Cross-check with Microsoft Graph PowerShell:
   snippet.text

   1Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
   2Get-MgUserLicenseDetail -UserId "jane.doe@contoso.com"

3. Confirm the mailbox actually provisioned in Exchange Online (can take up to a few hours after license success):
   snippet.text

   1Get-Mailbox -Identity jane.doe@contoso.com

4. Check the group’s Licenses > error status tab in the Entra admin center for any users stuck in an error state — this is the single most useful screen for this feature and is often missed by new engineers.
5. Capture evidence for the change ticket: a screenshot or exported CSV of the group’s license assignment status, and the PowerShell output for at least two sampled users. This evidence is what distinguishes a verified change from an assumed one during a post-incident review.

#Verification evidence checklist

Before marking the pilot or rollout complete, confirm each of the following independently rather than inferring success from the console alone.

#Common failure modes

#Change management before wider rollout

Do not enable this for the full Sales department directly in production without a controlled test:

1. Log a standard change request describing the SKU, group name, and dynamic rule.
2. Pilot with a static test group containing two or three volunteer accounts first, and validate mailbox, Teams, and SharePoint provisioning end to end.
3. Only after pilot sign-off, switch the group to the live dynamic rule or expand static membership.
4. Record the change in your ticketing/change system with before/after license counts and the rollback procedure below attached.
5. Notify the helpdesk team of the go-live window and the new authoritative process, since they are the front line for any provisioning complaints during the first week and need to stop performing the old manual assignment step.
6. Schedule the dynamic rule switch outside peak business hours where practical, since a large department-wide membership evaluation can generate a burst of simultaneous mailbox and Teams provisioning requests.

#Rollback procedure

If group-based licensing causes unexpected service loss (for example, a disabled service plan removes access someone actually depended on):

1. Do not delete the group immediately — this can trigger bulk license removal and associated data retention timers (Exchange mailbox conversion, OneDrive retention countdown) across every member simultaneously.
2. First, remove only the specific license assignment from the group under Group > Licenses > Assignments, leaving the group itself intact for later reuse.
3. Monitor affected users’ license status until it returns to unassigned, then reassign the previous manual licenses if an interim state is required.
4. For a single problem user rather than a group-wide issue, add them to an exclusion group pattern instead of unwinding the whole group assignment — this is the standard production approach and avoids re-litigating the entire rollout.
5. Document the rollback outcome in the same change ticket and note the root cause for the post-incident review.
6. If the rollback was triggered by a disabled service plan rather than a licensing failure, re-enable that specific service plan on the group assignment rather than removing the whole SKU, then re-verify with the same evidence checklist used during initial rollout before considering the incident closed.

#Ongoing operations

Once live, periodically audit license error states rather than waiting for helpdesk tickets:

1Get-MgGroup -Filter "displayName eq 'LIC-Sales-E3'" | Select-Object Id
2Get-MgGroupMember -GroupId <group-id> | ForEach-Object { Get-MgUserLicenseDetail -UserId $_.Id }

Consider scheduling this as a runbook in Azure Automation or a scheduled task feeding an alert into your team’s monitoring channel so license errors surface before end users notice missing services. At minimum, review the seat consumption trend against total purchased seats weekly, since gradual headcount growth in a dynamic group can exhaust a SKU quietly over several months with no single change event to point to. Also review group membership drift monthly against HR records; a dynamic rule based on a single attribute like department can misfire if that attribute is repurposed elsewhere in the directory for an unrelated reporting or Conditional Access rule, so treat any change to that attribute’s meaning as a change to this licensing configuration as well and route it through the same change process.

Group-based licensing removes one of the most persistent sources of manual error in enterprise Microsoft 365 administration, but it introduces its own failure surface around seat exhaustion, conflicting group definitions, and directory sync timing. Treat it like any other production identity change: pilot it, verify against real service provisioning rather than just the license blade, keep a clean rollback path that does not force a disruptive full removal when only one user is affected, and fold the ongoing seat and membership audits into the same monitoring discipline you would apply to any other tenant-wide automation. Done this way, the configuration stops being a one-off console task and becomes a durable, auditable piece of the tenant’s identity operations that a graduate engineer can hand off, extend to other departments, and defend confidently during a change review or an audit.