Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error MutuallyExclusiveViolation

MutuallyExclusiveViolation and DependencyViolation in group licence assignment

9 min read Updated October 4, 2026 Microsoft 365 & Entra ID

Fix it now

Both are licence assignment failure values Microsoft publishes, and they say opposite things. MutuallyExclusiveViolation is the conflicting service plans case: the user is being given two things that cannot both be enabled. DependencyViolation is the missing dependency case: something is being enabled while what it depends on is switched off.

  1. Find where the assignment comes from. In the Microsoft 365 admin center, Users, Active users, the user, Licenses and apps shows what they hold; anything inherited from a group cannot be edited there.
  2. For a group assignment, open Billing, Licenses, the product, then the Errors & issues tab and read the failure recorded against that user.
  3. Compare the products the user holds and look for the same service plan appearing in both, or a plan enabled while its prerequisite is disabled.
  4. Disable the duplicate plan in one of the two assignments – at the point where that licence is assigned, which for a group means the group’s licence settings and not the user.
  5. Reprocess the group’s licence assignment and recheck the user. Reprocessing covers a maximum of 20 users at a time.
  6. If both products are genuinely needed, decide explicitly which one owns each shared plan rather than leaving it to whichever assignment ran first.

The third value in this article, Other, is the unclassified case. Retry it once; if it persists, stop treating it as a licensing problem and look at the user object.

If the licence lands and the plan appears once on the user, you are finished. If the same clash keeps coming back, the next section covers why suites overlap and how the two assignment models fight.

Why it happens

A product is a container of service plans, and each plan can be enabled or disabled per user. Two suites can perfectly well contain the same underlying plan. The assignment engine will not enable the same service twice for one person, so when it sees the collision it refuses the whole assignment rather than guessing which copy should win. Microsoft’s Graph documentation lists MutuallyExclusiveViolation among the published assignment failure values, and the admin centre documentation calls this category conflicting service plans.

Dependencies run the other way. Some plans cannot function without another being present and enabled: an archiving plan needs the mailbox it archives, an add-on protecting a workload needs that workload. Disable the underlying plan while leaving the dependent one on and the engine rejects that too, because the result would be an entitlement that cannot work. That is the missing dependencies category, reported as DependencyViolation.

Other is the value worth treating differently. It is the published catch-all for assignment failures that do not fall into the named categories, which includes transient conditions and objects that were mid-change when the assignment ran. Retry it once. If it survives a retry, the problem is more likely to be the object than the licence.

Two products contain the same service plan

You have this one if The user holds two suites and the error names a plan present in both.

  1. Decide which product should own that plan for this population.
  2. Disable the duplicate in the other assignment, at the point where that licence is assigned.
  3. Reprocess, then confirm the user’s licences show the plan enabled exactly once.

A prerequisite plan is disabled

You have this one if DependencyViolation naming a plan that cannot run on its own.

  1. Re-enable the prerequisite, or disable the dependent plan as well so the pair is consistent.
  2. Check whether the prerequisite was disabled deliberately, for example to keep a service switched off across the organisation.
  3. Apply the same decision to every assignment that touches those plans, so the next person does not hit the same wall.

Direct and group assignments are fighting

You have this one if The licence applies cleanly when set on the user and fails when it comes from a group, or the reverse.

  1. Pick one assignment model per product and hold to it; mixed models are the most common source of these errors.
  2. Remove the direct assignment once the group-based one is applying correctly.
  3. Record which groups carry which products, because this becomes unmanageable quickly without a written record.

A script overwrites the plan state

You have this one if The error reappears on a schedule that matches an automation run.

  1. Read the current state before writing, and compute the change rather than applying a fixed list of plans.
  2. Make the script idempotent, so running it twice produces the same result as running it once.
  3. Log what it changed, so the next person can tell automation from manual edits.

Nested or dynamic membership applies an unexpected product

You have this one if A user is receiving a product from a group nobody expected them to be in.

  1. Trace the user’s group memberships, including nested groups, back to the source.
  2. Check dynamic membership rules for one that has quietly widened.
  3. Correct the membership rather than working around it on the user object.

Full reference

Tracing where the clash comes from

What the error shows Where the conflict lives
Two suites, one shared service plan Overlapping products on the same person
A named plan that requires another plan A prerequisite disabled in the same or another assignment
Works when assigned directly, fails from a group Direct and group assignments competing
The error returns every time a script runs The script writes a fixed plan list over the current state
Only some members of a group are affected Those members hold an extra product the others do not
Other, once, then gone A transient condition; the retry is the fix

The published set of assignment failures

Value Category Microsoft names
CountViolation Insufficient licences
MutuallyExclusiveViolation Conflicting service plans
DependencyViolation Missing dependencies
ProhibitedInUsageLocationViolation Usage location problems
UniquenessViolation Proxy address issues
Other Anything the engine does not classify

Knowing the whole list is useful because the portal shows one failure at a time and the next one only appears after you clear the first. A user with a duplicated plan and a blank usage location will produce two different errors on two successive attempts, and it is easy to think the first fix did not work.

Deciding which product owns a plan

  1. List the products the affected population holds, and the plans inside each.
  2. For each duplicated plan, pick the product that will own it – normally the one everybody in that population holds.
  3. Disable the duplicate at the other assignment, not on individual users.
  4. Write the decision down next to the group definition, because it is invisible afterwards.
  5. Reprocess and confirm the affected users come back clean.

Where disabled plans go to hide

  • A disabled plan looks identical to a plan the organisation does not own, from the user’s point of view.
  • Nothing surfaces a list of plans somebody turned off two years ago and why.
  • Renewals change what a tenant holds, so a suite replaced by a different suite can create an overlap that did not exist before.
  • The order of assignment can decide which product ends up owning a shared plan, which is exactly why the choice should be explicit.
  • Keep the record of disabled plans with the group, not in somebody’s inbox.

When a licence is the actual fix

Disabling the duplicate service plan is free and it works, so treat this section as optional. It is worth reading only if the same people keep ending up with overlapping products, because that pattern says the estate has drifted rather than that one assignment went wrong. Where an organisation has accumulated a base plan plus a stack of add-ons that between them duplicate half a suite, consolidating onto a single product that already contains what those users need removes the conflict permanently and leaves one thing to manage instead of five. That is a purchasing decision you might reach afterwards; it is not required to clear the error. Arco can map what you currently hold against what your users actually use, and will tell you plainly when disabling one plan is the better answer.

Every code this article covers

Code What it points at Source
MutuallyExclusiveViolation A published licence assignment failure value, corresponding to the conflicting service plans category: two assigned products both contain a plan that cannot be enabled twice Microsoft Learn
DependencyViolation A published licence assignment failure value, corresponding to the missing dependencies category: a plan is enabled while a plan it depends on is disabled Microsoft Learn
Other A published licence assignment failure value for failures the engine does not classify; retry once, then examine the user object Microsoft Learn

Confirm the fix worked

  1. The product’s Errors & issues tab reports no assignment failures for any member of the group.
  2. The user’s Licenses and apps page shows the expected plans, each enabled exactly once.
  3. The service that was failing works for that user.
  4. Running your assignment automation again produces no new errors, confirming it is idempotent.

Questions people ask about this

Does fixing this cost anything?

No. Disabling a duplicate service plan is a configuration change. Consolidating overlapping products onto one suite is a purchasing decision you might reach afterwards, but it is not needed to clear the error.

Can I just disable plans everywhere to be safe?

You can, but record what you disabled and why. Undocumented disabled plans become invisible outages months later, when somebody asks why a service everyone else has does not appear for one team.

Why did this start after a renewal?

Renewals change which products a tenant holds. A suite replaced by another suite, or an add-on folded into a larger plan, can create an overlap that did not exist before.

Does the order of assignment matter?

It can decide which product ends up owning a shared plan, which is precisely why you should make that choice deliberately instead of letting timing decide it.

What should I do with Other?

Retry it once. It is the published catch-all for failures the engine does not classify, and a transient condition is the common explanation. If it survives a retry, look at the user object rather than the licences.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error AADSTS70008 and AADSTS700082: the refresh token expired or was revoked License Error 0x80180022 and 0x800705b4: Windows edition and TPM block Intune enrolment License Error AADSTS53003: sign-in blocked by a Conditional Access policy in Entra ID Free Fix 403 FORBIDDEN and Access Denied in SharePoint Online and OneDrive
← Back to Knowledge Base