To remove or change a license safely you need its origin: whether it is a direct assignment or group-based, and which group grants it. One Microsoft rule keeps the trace bounded: group-based licensing applies only to direct user members of the licensed group and does not flow through nested groups. This guide shows the manual trace and the visual one.
Step 1: identify the assignment source#
License details on the user distinguish direct assignments from group-based ones and name the assigning group:
Connect-MgGraph -Scopes "User.Read.All"
Get-MgUserLicenseDetail -UserId user@contoso.com |
Select-Object SkuPartNumber, SkuIdStep 2: find out why the user is in the granting group#
Knowing which group grants the license is not the same as knowing why the user is in it. Group licensing only applies to direct members, so the question becomes who or what put the user there: an administrator, a sync from on-premises AD, or a dynamic membership rule. That mechanism, not the license itself, is what you will change.
Step 3: check for other paths before acting#
Before removing a membership, confirm the license does not also arrive from another direct group membership or a direct assignment. Overlapping sources are the main reason removals appear not to work, and the membership you remove can still carry nested access consequences even though licensing does not traverse nesting.
VisualizerEngine
How VisualizerEngine does it
Inheritance mapping renders steps 1 to 3 as one picture: for any user, the exact path each license travelled through nested groups, every overlapping source, and per-user conflict and duplicate tracking. Removal impact analysis then answers the question you actually care about: if I unassign this, who loses what?