Theoretical Foundation: Manage Licenses in Microsoft Entra ID
1. Initial Intuition
In previous objectives, we built two fundamental pillars: we created identities (users and groups) and learned to manage their properties. Now, we reach the third piece of the puzzle: assigning licenses to these identities so they can effectively use Microsoft services.
The analogy is straightforward. Imagine that creating a user is like registering an employee at the company and issuing their badge. Managing properties is keeping the registry updated. But the badge, alone, doesn't provide access to any tools. For the employee to use the Office suite, have email, access Teams, or use Power BI, they need an assigned license. The license is like the key that unlocks specific services for that user.
Without a license, the user exists in the directory, can authenticate, but has no functional access to Microsoft's paid products. Managing licenses is, therefore, the act of controlling who can use what, and at what cost.
2. Context: Why Licensing Matters
The licensing model for Microsoft 365 and Azure is based on per-user subscriptions. The organization purchases a certain number of licenses (for example, 500 Microsoft 365 E3 licenses), and each license needs to be individually assigned to a user for them to use the services included in that subscription.
This model creates three operational needs that the administrator must master:
Inventory control: how many licenses were purchased, how many are assigned, and how many are available.
Assignment and removal: ensuring the right users have the right licenses, and that licenses from former employees are recovered.
Granularity: within a license (like E3), there are multiple service plans (Exchange Online, SharePoint, Teams, etc.), and it's possible to enable or disable each one individually.
Licensing is directly connected to previous concepts. Remember: the usageLocation property we discussed in the previous objective is mandatory before assigning a license. Without it, Entra ID rejects the operation.
3. Building the Concepts
3.1 Hierarchical Structure of Licensing
To understand licensing in Entra ID, you need to know three hierarchical levels:
Subscription (SKU): is the product purchased by the organization. Example: Microsoft 365 E3, Microsoft 365 E5, Enterprise Mobility + Security E5. Each subscription has an identifier called SKU (Stock Keeping Unit). The organization purchases a fixed quantity of each SKU.
License: is an individual unit of the subscription. If the organization purchased 500 E3 units, it has 500 licenses available to assign.
Service Plan: each license/SKU contains multiple service plans. Each service plan corresponds to a specific service. For example, the "Microsoft 365 E3" SKU includes service plans such as Exchange Online (Plan 2), SharePoint Online (Plan 2), Microsoft Teams, Office Apps for Enterprise, among others.
The granularity of service plans is important because it allows disabling services individually. If the organization uses a third-party email system and doesn't want users to access Exchange Online, it can assign the E3 license but disable the Exchange service plan.
3.2 Two Assignment Methods: Direct vs. Group-Based
There are two fundamental methods for assigning licenses in Microsoft Entra ID:
Direct Assignment: the administrator manually assigns a license to an individual user. It's equivalent to handing the key directly to each employee, one by one.
Group-Based Licensing: the administrator assigns the license to a group. All members of that group automatically inherit the license. If a new member is added to the group, they receive the license. If removed, the license is withdrawn.
Group-based assignment is the recommended method for environments with more than a few users, because it eliminates the need for individual manual assignments and integrates directly with the dynamic groups we discussed in previous objectives.
| Characteristic | Direct Assignment | Group-Based Assignment |
|---|---|---|
| Scale | Low (manual, 1 by 1) | High (automatic) |
| Automation | Requires script for each user | Automatic via group membership |
| Requires Entra ID P1 license? | No | Yes |
| Granular service plan control | Yes | Yes |
| Audit ease | Low | High (just check the group) |
| Automatic removal when leaving group | Not applicable | Yes |
Critical point: Group-Based Licensing is a feature that requires Microsoft Entra ID P1 or P2 (or equivalent, like Microsoft 365 E3 which includes Entra ID P1). If the tenant only has Entra ID Free licenses, group-based assignment is not available.
3.3 How Both Forms Coexist
The same user can have licenses assigned by both methods simultaneously. For example, a user can receive Microsoft 365 E3 via group and Power BI Pro via direct assignment.
When the same SKU is assigned both directly and via group, Entra ID does not consume two licenses. It recognizes the duplication and uses only one unit of the subscription. However, assignment sources are tracked separately. If the direct assignment is removed, the license remains (from the group), and vice versa.
This coexistence has an important practical implication: if the administrator wants to migrate from direct assignment to group-based, they should first add the license to the group, verify that all members received the license via group, and only then remove the direct assignments. Doing it in reverse order would result in temporary loss of access.
3.4 Service Plans: Granular Control
When assigning a license (directly or via group), all service plans included in the SKU are enabled by default. However, the administrator can disable specific service plans.
Common scenarios for disabling:
The service plan is redundant with another product already in use (ex: disable Exchange Online because the company uses Gmail).
The service plan is not needed for certain user profiles (ex: disable Power Automate for interns).
Regulatory or compliance reasons (ex: disable Sway in regulated financial environments).
Important behavior with Group-Based Licensing: when a license is assigned via group with certain service plans disabled, and the same user receives the same license via direct assignment (or another group) with all service plans enabled, the result is the union of service plans. That is, Entra ID enables every service plan that is active in any of the sources. The logic is additive, never subtractive between sources.
This is powerful, but requires planning. If you want to ensure a user does not have access to Teams, disabling Teams in one group is not sufficient if another group enables it.
3.5 License States in Group-Based Licensing
When licenses are assigned via group, each user can be in one of several states regarding that assignment:
| State | Meaning | Action needed |
|---|---|---|
| Active | License successfully assigned, all service plans processed | None |
| Error | Assignment failed for this user | Investigate and fix the cause |
| Processing | Assignment is in progress | Wait |
The most common errors that generate the Error state are:
Not enough licenses: the number of available licenses in the tenant is exhausted. The organization bought 500 units, all are assigned, and a new member joined the group. They remain in error state.
Conflicting service plans: the user already has a service plan assigned by another license that conflicts with the service plan of the new license. Classic example: Exchange Online Plan 1 (from one license) conflicts with Exchange Online Plan 2 (from another). Both cannot coexist.
Usage location missing: the user's usageLocation attribute is empty. As we saw in previous objectives, this property is mandatory.
Service not available in location: certain service plans are not available in all regions. If a user's usageLocation points to a country where the service is not offered, the assignment fails.
4. Structural View
The diagram below shows how licensing connects to the entire identity ecosystem we've built so far:
5. Practical Operation
5.1 License Lifecycle
A license's lifecycle follows the user lifecycle we studied in previous objectives, but with its own nuances:
Non-obvious behavior about user deletion: when a user is deleted (soft delete), their licenses are automatically released back to the available pool. If the user is restored from the recycle bin (within 30 days), the licenses they had are not automatically restored. They need to be manually reassigned. This catches many administrators by surprise.
However, if the user was in a group with Group-Based Licensing and is restored still as a member of that group, the license will be automatically reassigned by the group mechanism. This is another reason why Group-Based Licensing is preferable to direct assignment.
5.2 Behavior with Multiple SKUs
A user can receive licenses from multiple SKUs simultaneously. For example, a user can have:
Microsoft 365 E3 (which includes Exchange, Teams, SharePoint, Office Apps). Enterprise Mobility + Security E5 (which includes Intune, Azure AD Premium P2, Azure Information Protection P2). Power BI Pro.
In this case, each SKU consumes one license unit from the respective subscription. The service plans from all SKUs are combined, and the user receives the superset of functionalities.
5.3 Service Plan Conflicts
Not all service plans can coexist. Some are mutually exclusive by design. The most common conflicts involve different versions of the same service:
| Service Plan A | Service Plan B | Conflict? |
|---|---|---|
| Exchange Online Plan 1 | Exchange Online Plan 2 | Yes |
| SharePoint Online Plan 1 | SharePoint Online Plan 2 | Yes |
| Azure AD Premium P1 | Azure AD Premium P2 | Yes (P2 includes P1) |
| Teams | Teams (from another SKU) | No (same plan, no conflict) |
When there's a conflict, Entra ID does not assign the license to the user and generates a Conflicting service plans error. To resolve, the administrator needs to remove the license containing the conflicting service plan before assigning the new one.
Practical example: the organization has some users with Office 365 E1 (which includes Exchange Online Plan 1). The administrator decides to assign Microsoft 365 E3 (which includes Exchange Online Plan 2) via group. Users who already have E1 with Exchange Plan 1 will enter Error state. The solution is to remove the E1 license from these users before (or simultaneously) adding them to the E3 group.
6. Implementation Methods
6.1 Azure Portal (Graphical Interface)
Direct assignment to a user: Microsoft Entra ID > Users > select the user > Licenses > Assignments > Add assignments > select the SKU > optionally disable service plans > Save.
Assignment via group: Microsoft Entra ID > Groups > select the group > Licenses > Assignments > Add assignments > select the SKU > configure service plans > Save.
Checking group licensing errors: Microsoft Entra ID > Groups > select the group > Licenses > view the status column. Users with errors will be listed, and clicking on each one shows the specific cause of the error.
Inventory verification: Microsoft Entra ID > Licenses > All products. Here you can see each SKU, total licenses purchased, total assigned, and total available.
When to use: Point operations, visual troubleshooting, quick inventory checks.
Limitations: Doesn't scale to hundreds of operations. Doesn't allow automation.
6.2 PowerShell (Microsoft Graph PowerShell SDK)
List available licenses in tenant:
Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits, @{N='TotalUnits';E={$_.PrepaidUnits.Enabled}}
Assign license to a user (with all service plans):
Set-MgUserLicense -UserId "ana.silva@contoso.com" -AddLicenses @{SkuId = "<sku-id>"} -RemoveLicenses @()
Assign license disabling specific service plans:
$licensesToAssign = @{
SkuId = "<sku-id>"
DisabledPlans = @("<service-plan-id-1>", "<service-plan-id-2>")
}
Set-MgUserLicense -UserId "ana.silva@contoso.com" -AddLicenses @($licensesToAssign) -RemoveLicenses @()
Remove license from a user:
Set-MgUserLicense -UserId "ana.silva@contoso.com" -AddLicenses @() -RemoveLicenses @("<sku-id>")
When to use: Batch operations, onboarding/offboarding automation, recurring scripts.
Advantages: Allows conditional logic (ex: "assign E3 only to Sales department users who don't already have a license").
Note about legacy cmdlets: the cmdlets Set-MsolUserLicense (from MSOnline module) and Set-AzureADUserLicense (from AzureAD module) are deprecated. The correct module is Microsoft Graph PowerShell SDK with the Set-MgUserLicense cmdlets.
6.3 Azure CLI
Azure CLI has limited support for license management directly. Most licensing operations require the use of Microsoft Graph. Therefore, for licensing, PowerShell or Graph API are the preferred methods via command line.
6.4 Microsoft Graph API
Assign license via API:
POST https://graph.microsoft.com/v1.0/users/{id}/assignLicense
Body:
{
"addLicenses": [
{
"skuId": "<sku-id>",
"disabledPlans": ["<service-plan-id>"]
}
],
"removeLicenses": []
}
List user licenses:
GET https://graph.microsoft.com/v1.0/users/{id}/licenseDetails
When to use: HR system integration, self-service portals, custom applications that manage lifecycle.
Advantage: Support for batch requests (up to 20 operations in one call).
| Method | Direct assignment | Group-Based | Granular Service Plan | Automation |
|---|---|---|---|---|
| Azure Portal | Yes | Yes | Yes | No |
| PowerShell | Yes | Indirect (manages group membership) | Yes | Yes |
| Graph API | Yes | Indirect (manages group membership) | Yes | Yes |
| Azure CLI | Limited | No | Limited | Partial |
7. Control and Security
Who Can Manage Licenses?
| Role | Can assign/remove licenses? | Notes |
|---|---|---|
| Global Administrator | Yes | Unrestricted access |
| License Administrator | Yes | Dedicated role for licensing |
| User Administrator | Yes | Includes license management as part of scope |
| Groups Administrator | Indirectly | Can manage group membership, which affects Group-Based Licensing |
The most specific and recommended role for exclusively licensing tasks is the License Administrator. It allows assigning, removing, and managing licenses without granting additional identity management permissions.
License Governance
Over-licensing: assigning E5 licenses (more expensive) to all users when most only need E3 generates significant financial waste.
Orphaned licenses: licenses assigned to inactive or disabled accounts represent cost without benefit. Review periodically.
No centralized control: direct assignment by multiple administrators without coordination leads to inconsistencies and makes auditing difficult.
8. Decision Making
| Situation | Best choice | Reason |
|---|---|---|
| Tenant with fewer than 20 users | Direct assignment | Simplicity, no need for P1 |
| Tenant with hundreds of users, defined profiles | Group-Based Licensing with dynamic groups | Total lifecycle automation |
| Organization with multiple SKUs and departments | Groups by profile (e.g., "License-E3-Sales", "License-E5-Engineering") | Clarity, auditability, granular control |
| User needs specific service plan that others in the group don't need | Direct assignment complementary to group | Flexibility without affecting others |
| Migration from E1 to E3 | Assign E3 via new group, validate, then remove E1 | Avoids access loss during transition |
| Cost reduction | Audit licenses, identify inactive accounts, disable unused service plans | Financial optimization |
Naming Strategy for License Groups
A very efficient practice is to create groups dedicated exclusively to licensing, with standardized names:
LIC-M365-E3-General: M365 E3 license for general users.
LIC-M365-E5-Engineering: M365 E5 license for engineering.
LIC-PBI-Pro: Power BI Pro license.
This clearly separates licensing groups from resource access groups (RBAC) and collaboration groups (M365 Groups), avoiding operational confusion.
9. Best Practices
Use Group-Based Licensing as standard. Whenever possible, avoid direct assignment. Groups make licensing predictable, auditable, and automatic.
Combine dynamic groups with Group-Based Licensing. This is the most powerful combination. Example: create a dynamic group with the rule user.department -eq "Engineering", assign the E5 license to the group, and every engineer will automatically receive the license when registered with the correct department.
Monitor license inventory proactively. Configure alerts when the number of available licenses falls below a threshold (e.g., 10% of total). Running out of licenses causes silent errors in Group-Based Licensing.
Handle service plan conflicts before migrating licenses. When migrating from one SKU to another, always check for conflicting service plans before starting. Plan the removal of the old license and assignment of the new one in a coordinated manner.
Fill usageLocation as part of the user creation process. Don't leave it for later. If usageLocation is empty when the group tries to assign the license, the user will be in an error state.
Create separate license groups from access groups. Don't assign licenses to the same group used for RBAC access control. Mixing purposes makes auditing difficult and can cause unwanted license or permission assignments.
Review licenses of disabled accounts periodically. An account with accountEnabled = false still consumes license if the license is not removed. Automate license removal as part of the offboarding process.
10. Common Errors
Forgetting usageLocation before assigning licenses. This error continues to be the most frequent. The system simply rejects the assignment, and the administrator spends time investigating a trivial problem.
Not noticing service plan conflicts during migrations. When migrating from E1 to E3, users who have Exchange Plan 1 conflict with Exchange Plan 2. Assignment fails silently in Group-Based Licensing, generating an Error state that isn't always monitored.
Removing the old license before assigning the new one during migration. This causes temporary access loss. The correct order is: assign the new one, validate, and only then remove the old one.
Assuming that restoring a user from trash restores their licenses. It doesn't restore them. Licenses need to be reassigned (unless the Group-Based Licensing mechanism handles this automatically).
Creating license groups with "Assigned" membership type and forgetting to add new employees. Without automation (dynamic group or HR integration), new employees remain without licenses until someone remembers to add them to the group.
Ignoring error monitoring in Group-Based Licensing. Entra ID doesn't send proactive notifications when there are license assignment errors in groups. The administrator needs to check manually or configure automation for this.
Assigning expensive licenses (E5) to everyone without evaluating need. The cost difference between E3 and E5 can be significant. Evaluate which additional service plans from E5 each user profile actually needs.
11. Operations and Maintenance
Day-to-Day Monitoring
License dashboard in portal: Microsoft Entra ID > Licenses > All products. Shows the inventory of each SKU.
License usage report: available in the Microsoft 365 Admin Center (admin.microsoft.com), allows seeing which users are effectively using services (logins to Exchange, Teams, etc.) versus which have licenses but don't use them.
Audit Logs: all license assignment and removal operations are logged in Entra ID audit logs, with identification of who performed the action and when.
Common Problems
| Problem | Probable cause | Solution |
|---|---|---|
| "Not enough licenses" in group | All SKU units are assigned | Buy more licenses or free licenses from inactive accounts |
| "Conflicting service plans" | Two SKUs with incompatible versions of the same service | Remove the license with the conflicting service plan |
| "Usage location is required" | User's usageLocation is empty | Set the property before assigning |
| User has license but can't access service | Specific service plan is disabled | Check which service plans are enabled in the license |
| Licenses consumed but no active users | Disabled or deleted accounts (soft delete) still with license | Audit and remove licenses from inactive accounts |
Important Limits
| Resource | Limit |
|---|---|
| Licenses assignable per user | No defined technical limit (multiple SKUs can coexist) |
| Groups that can have licenses assigned | No technical limit, but each group consumes evaluation processing |
| Group-Based Licensing processing time | From minutes to hours, depending on tenant size |
| License retention in soft delete | License is freed immediately when deleting the user |
12. Integration and Automation
HR Systems Integration (Complete Scenario)
In mature environments, the license lifecycle is completely automated:
In this scenario, human action happens only in the HR system. Everything that follows is automatic: user creation, attribute filling, inclusion in dynamic group, license assignment. The reverse also works: when HR registers a termination, the account is disabled, removed from groups, and licenses are freed.
Reports and Alerts Automation
To monitor license consumption proactively, a common pattern is to create an Azure Logic App or Azure Function that:
- Periodically queries the
GET /subscribedSkusGraph API endpoint. - Calculates the utilization percentage of each SKU.
- Sends an alert (by email, Teams, or webhook) when consumption exceeds 90%.
This avoids the situation where new employees are left without licenses for days because inventory was silently depleted.
Cleanup Automation
A recurring script that identifies users with accountEnabled = false for more than X days and that still have assigned licenses, automatically removing these licenses, is a common and recommended pattern for cost optimization.
13. Final Summary
Licenses are the mechanism that transforms identity into functional access. Without a license, the user exists but cannot use the services.
The structure is hierarchical: Subscription (SKU) > License > Service Plans. Each SKU contains multiple service plans that can be individually enabled or disabled.
There are two assignment methods: Direct and Group-Based. Group-Based Licensing is the recommended method for environments at scale, but requires Entra ID P1/P2.
usageLocation is a mandatory prerequisite for any license assignment. Without it, the operation fails.
Service plan conflicts occur when different versions of the same service coexist (e.g., Exchange Plan 1 and Plan 2). They prevent assignment and need to be resolved by removing the conflicting license.
Service plan logic between multiple sources is additive. If any source enables a service plan, it remains enabled for the user.
Deleting a user frees the license immediately, but restoring the user does not restore the license (except via Group-Based Licensing).
The License Administrator role is most suitable for those who only need to manage licenses, respecting the principle of least privilege.
Group-Based Licensing combined with dynamic groups is the most scalable and automated approach for managing licenses in corporate environments.
Monitor group assignment errors actively. Entra ID doesn't proactively notify about failures. Check periodically or automate with alerts.
Separate licensing groups from access (RBAC) and collaboration (M365) groups. This ensures operational clarity and facilitates auditing.
Periodically review disabled accounts with assigned licenses. Inactive accounts with licenses represent unnecessary cost.