Group based licensing errors are unusually hard to look up, and it is not your search technique. Microsoft’s own documentation currently sends you round in a circle: the admin centre article tells you to see a dedicated error reference, and the URL it gives you returns the admin centre article. The API reference does the same thing from the other end. The actual list of values the service returns lives somewhere else entirely, and it is shorter than most troubleshooting content implies. Here is where the list really is, what is on it, and which widely used error name is not. For the wider picture of how assignment fits into the bill, start with Microsoft 365 licensing and the rules that decide it.
Why group based licensing errors are hard to look up
Start where everyone starts, at the admin centre article on assigning licences to a group. It ends its troubleshooting section with this:
For a full description of each error type, including insufficient licenses, conflicting service plans, missing dependencies, proxy address issues, and usage location problems, along with steps for how to resolve them, see Identify and resolve license assignment problems for a group.
That is the right instinct, and the link is live. Fetch the URL it points at and you get back the page you just came from, the admin centre article. I tried every other published path variant of that reference I could find, across the entra/fundamentals, entra/identity/users and azure/active-directory/users-groups-roles segments, in en-US and en-GB. Five addresses in total. Every one of them returns the admin centre article, and every one declares the same canonical URL.
The circle closes from the other side too. The Microsoft Graph reference page that does document the error values ends its description with “for more information on how to identify and resolve license assignment errors, see here”, and the address behind that link is the fifth variant above. So the admin centre sends you to the reference, the reference is not there, and the API documentation sends you to the same missing page.
For a change record, the mechanics are plain once you read the headers. Four of the five addresses answer with a 301 straight to the admin centre article, anchored at its own section on group-based licensing errors, which is the section that sent you looking in the first place. The legacy azure/active-directory address takes one extra hop before it lands in the same place. None of them reaches a page that lists a single error value.
There is a detail here worth more than the loop itself. Search for group based licensing errors and the top results are still addresses for the missing reference, listed under its old title, “Identify and resolve license assignment problems for a group”. At the time of writing they sit on docs.azure.cn, Microsoft’s documentation site for Azure operated in China, rather than on Learn. Neither serves the reference. One redirects to the admin centre article, and the other to a general Entra licensing page. The index is still ranking a page that no longer exists, and it has found a second domain to rank it from.
The real list has six values, and it is in the Graph reference
The enumeration that actually matters is a property on the licenseAssignmentState resource in the Microsoft Graph v1.0 reference. Verbatim:
License assignment failure error. If the license is assigned successfully, this field will be Null. Read-Only. The possible values are CountViolation, MutuallyExclusiveViolation, DependencyViolation, ProhibitedInUsageLocationViolation, UniquenessViolation, and Other.
Six values. That is the whole set the API documents. The companion property is worth having in front of you at the same time:
Indicate the current state of this assignment. Read-Only. The possible values are Active, ActiveWithError, Disabled, and Error.
Two things follow, and both are checkable by anyone reading this.
First, the usage location value is ProhibitedInUsageLocationViolation, in full. To be fair to the field, the better write-ups do use the long form, so this is not a case of the internet getting it wrong. The trap is at the keyboard. The value is long, UsageLocationViolation reads like the obvious name for it, and a filter typed from memory returns an empty set rather than an error. An empty result here looks exactly like a clean bill of health, which is a quietly expensive way to be wrong.
# The documented value. This is the one that matches.
$states | Where-Object { $_.Error -eq "ProhibitedInUsageLocationViolation" }
# The plausible looking short form. Returns nothing, always.
$states | Where-Object { $_.Error -eq "UsageLocationViolation" }
Second, and more interesting: there is no ProxyAddressViolation. I checked the reference page explicitly for that string and it is absent. Yet the admin centre article promises an explanation of “proxy address issues”, and proxy address conflicts are one of the most common things that actually stops a licence landing.
Those two facts are reconcilable, and the reconciliation is the useful part. The admin centre page is describing categories of problem in prose; the Graph reference is enumerating values the API returns. When a proxy address conflict does block an assignment, the error text practitioners report seeing takes the form “Uniqueness violation. Property: ProxyAddresses”, which maps onto the documented UniquenessViolation rather than onto a value of its own. I want to be precise about the standing of that: the mapping is consistent with the documented enumeration and with field reports, but I have not found a Microsoft page that states it, and I have not reproduced it myself. Treat it as the best available reading rather than as documentation.
What is safe to act on is narrower and still worth having. ProxyAddressViolation is not a documented value of the error property, so do not write code that expects it, and if you are hunting a proxy address problem through the API, look under UniquenessViolation before you conclude there is nothing there.
If you are checking the beta view of the same reference for a second opinion, note that it is considerably staler than v1.0, with the same wording on this property. The v1.0 view is the one to cite.
Two documented limits that explain symptoms people blame on errors
A good proportion of what gets reported as a licensing error is not an error at all. Nothing failed, so nothing is returned, and there is no value to look up. Two documented behaviours cover most of it.
Nested groups are silently ignored. From the admin centre article:
Group-based licensing doesn’t currently support nested groups (groups that contain other groups). If you assign licenses to a nested group, only users in the first-level group are assigned licenses.
The limitation itself is reasonably well known. The failure mode is the part that gets left out, and it is the part that matters. Users in the nested group do not get an error. They get nothing, and no error value is recorded, because no assignment was ever attempted for them. If you are hunting for an error code to explain why half a group is unlicensed, and the group contains groups, stop hunting. There is no code to find.
Reprocess works on 20 users at a time. Also verbatim:
When you select Reprocess to resolve issues with group license assignment, the feature attempts to reprocess licenses up to a maximum of 20 users at a time.
This is the single most useful sentence in the article and I have not found it quoted in a single third-party troubleshooting post. It explains the symptom admins describe constantly: pressing Reprocess on a group of several hundred, watching it report success, and finding nothing has changed for most of the members. The button did what it documents. It is just not a bulk operation.
The article is also explicit that scale costs time, which bears on how long you should wait before treating a missing licence as a fault:
When you assign or modify licenses for a large group, like 100,000 users, it can affect performance. In certain high load situations, it might take a long time to process license changes for groups or membership changes to groups with existing licenses.
I have not run any of this at scale and cannot give you a number. My tenant is a lab with no enrolled devices, so the 20 user cap and the performance warning are Microsoft’s statements rather than my measurements. What I would take from them is a sequencing rule: confirm membership first, then wait, then look for an error value, in that order. If group membership has not landed yet then the licence cannot have, which is the same root cause I wrote about in Entra dynamic group not updating.
MutuallyExclusiveViolation is usually a plan decision, not a bug
Of the six values, MutuallyExclusiveViolation generates the most confused threads, and the common trigger is a tenant moving users between plan families while both licences are briefly assigned. It is not a rare edge case. There is a discussion in the Microsoft Entra forum, opened in July 2026 and still without a resolution at its last reply in August, from an admin trying to move 87 accounts from E3 to Business Premium and being blocked by exactly this error through months of support contact. If you are stuck on it, you are not doing anything unusual.
It is worth separating the mechanical fix from the decision underneath it: if two plans conflict, somebody has to decide which one the user should end up on, and that is a licensing question rather than a troubleshooting one. If that is where you have arrived, the comparisons in Microsoft 365 E3 vs E5 and Entra ID P1 vs P2 are the more useful reading.
There is also a sequencing trap the documentation warns about directly, and it bites hardest during exactly this kind of migration:
If you remove a user from a group before they’re added to the new one, the user can experience a brief loss of access to licensed services while group-based licensing finishes processing the new assignment.
Add first, then remove. The documentation does not say how brief brief is, and on the evidence of the performance warning above it will depend on your tenant.
What I would do
Treat the Graph v1.0 reference as the only authority on what the values are, and match any third-party table of group based licensing errors against those six names before you trust it. The fact that the official reference page is unreachable at five published addresses, that both the admin centre article and the API reference still link to it, and that search still ranks dead copies of it first under a title neither address serves, tells you how much of the surrounding ecosystem is pointing at something nobody has opened recently.
Then work the two silent cases before you work the errors. Check for nested groups, check that membership has actually landed, and remember that Reprocess is a 20 user operation. In my experience of documentation that disagrees with itself, the cheapest move is always to find the machine-readable source and believe that one. Here, that is the API reference.
Primary sources, both verified on the date below: the licenseAssignmentState resource type in the Microsoft Graph v1.0 reference and Assign or unassign licenses to a group in the Microsoft 365 admin center.
Last verified: 8 October 2026. I have not run this in production; my tenant is a lab with no enrolled devices and no licences at scale, so everything above is what the documentation states and what I observed fetching the pages.
