azureblog.co.uk
← cd ~/posts

Group-based licensing: finding and fixing assignment errors

Group-based licensing is the right way to assign Microsoft 365 licences, until a user silently doesn't get one. Here's where the errors hide.

2 min read⚠ checked 11 Feb 2026Entra ID · Microsoft 365
On this page
  1. Where errors show up
  2. The usual causes
  3. Moving users between SKUs cleanly
  4. Reprocessing after a fix

Assigning licences through security groups keeps things tidy: join the group, get the licence. When a new SKU arrives, the usual approach is to mirror the existing setup with a new group. Most of the time it just works. When it doesn't, the user simply ends up without the licence, and nothing tells them why.

AdminLicensing groupLicensing engineUserAdd user to the group1Membership changetriggers processing2Checks: seats, usage location,plan conflicts, dependenciesAll good: licenceassigned4Any check fails: errorrecorded on the group5
How a group licence reaches a user, and where it fails.

Where errors show up

In the Entra admin center, open the licensing group and check its Licenses blade. Groups with problems show a warning, and you can drill into the users affected and the error for each. To find every group with errors across the tenant:

powershell
Connect-MgGraph -Scopes "Group.Read.All"

Get-MgGroup -All -Filter "hasMembersWithLicenseErrors eq true" |
  Select-Object DisplayName, Id

The usual causes

  • Not enough licences. The group has more members than you have seats. Users beyond the limit get nothing.
  • Conflicting service plans. Some service plans can't be assigned alongside each other. If a user is in two licensing groups with overlapping or conflicting plans, the second assignment can fail.
  • Missing dependencies. Some add-ons need a base plan to be enabled. If you disabled that plan in the group's licence options, the add-on fails.
  • No usage location. Users need a usage location set before a licence can be assigned.
ErrorMeaningFix
CountViolationNot enough licencesBuy more or remove unused assignments
MutuallyExclusiveViolationConflicting service plansRemove the user from one group, or disable the clashing plan
DependencyViolationAdd-on needs a base plan that's disabledEnable the required plan in the group's licence options
UsageLocationNotAllowedNo usage location on the userSet it, ideally from HR data or a default in provisioning
ProhibitedInUsageLocationViolationService not available in the user's countryCheck the usage location is correct

You can check the licence finder at /tools/licences/ to see which SKUs include which service plans.

Moving users between SKUs cleanly

  1. Create the new licensing group and configure its service plans to match the old one.
  2. Test with a small pilot group of users first.
  3. Add users to the new group, check for errors, then remove them from the old one.
  4. Use Reprocess on the group after fixing a problem, so Entra retries the assignments.
Tip: keep licensing groups for licensing only. Mixing them with groups used for app access or makes it much harder to see why someone has a licence.
  1. New group created, service plans matched
  2. Pilot users added, errors checked
  3. Everyone added to the new group: users hold both licences
  4. Removed from the old group
  5. Old SKU count reduced at renewal
A clean SKU migration, with overlap.

Reprocessing after a fix

Fixing the cause doesn't always clear the error straight away. Reprocess the affected users:

powershell
Connect-MgGraph -Scopes "User.ReadWrite.All"
$g = Get-MgGroup -Filter "displayName eq 'LIC-M365-E5'"
Get-MgGroupMember -GroupId $g.Id -All | ForEach-Object {
  Invoke-MgLicenseUser -UserId $_.Id
}
Why does the user have the licence directly and through a group?

Direct and group assignments can coexist. Remove the direct one once the group has applied, so the group is the only thing to manage.

Can a user be in two groups for the same SKU?

Yes. They consume one licence, and the enabled plans are combined across the groups.

This post was last checked against Microsoft's documentation over six months ago. The approach should still hold, but check the linked sources for anything that has changed before you act on it.