Moving Group-Based Licensing to Microsoft 365 Admin Center Creates Some Challenges
Group-based licensing is the ability to assign product licenses to members of a group. When Microsoft first introduced group-based licensing, the functionality to manage license assignments was in the Azure AD admin center (now the Entra admin center). In the summer of 2024, Microsoft decided to move the focus for group-based licensing to the Microsoft 365 admin center. The Entra admin center no longer supports group-based licensing.
The Microsoft 365 admin center takes a different approach to the relationship between groups and licenses. Where the Entra admin center associates licenses with groups, the Microsoft 365 admin center assigns groups to licenses. At the end of the day, the same thing happens, but the switch in focus can take a little time to get used to.
Generally, the new assignment model works well in most scenarios. However, it runs into difficulty when the need exists to swap licenses because of the potential of “plan collision.” A Microsoft 365 product license (SKU) is composed of one or more service plans. Each plan governs access to specific functionality, like Teams, SharePoint Online, or Exchange Online. “License stacking” allows multiple plans for the same functionality to be assigned to a user account at one time, but sometimes stacking is not supported and a clash occurs. For example, you cannot assign a product license containing SharePoint Online Plan 2 to an account that already has a license for SharePoint Online Plan 1. Likewise, you can’t assign a product license for Viva Engage (Yammer) to an account that already has a Yammer license.
The model used by the Entra admin center swaps licenses in one operation. For example, it can remove an Office 365 Student A1 license from an account and swap it for an Office 365 Student A5 license. To do this, the administrator selects the group that assigns the licenses to users, removes the A1 license, adds the A5 license, and saves the change. Behind the scenes, when Entra processes the update, it performs the license swap in a single operation.
The scenario is more complicated in the Microsoft 365 admin center. To achieve the same result, an administrator must select the A1 license and remove the group. They then select the A5 license and add the group.
Several issues flow from the new model, the first being that group-based licensing works asynchronously. If Entra processes the A5 addition before it removes the A1 license, the change fails because of conflicting service plans. However, the A1 removal can go ahead to leave the account without a license. In turn, this can lead to Microsoft 365 deprovisioning services like the user’s mailbox. Adding the A5 license subsequently will reprovision the mailbox, but the user might lose access for some time.
The fact that the Microsoft 365 admin center does not support license swapping is a known problem. Microsoft understands the problem and might change the way that license processing occurs in the future. In the meantime, it’s an issue to avoid, unless you script a solution.
Because of the possibility that users might lose access to their mailbox due to license swaps, especially using group-based licensing, the Exchange development group released the delicensing resiliency feature to allow administrators extra time to pick up any licensing issues. However, the delicensing resiliency feature only applies to tenants with more than 10,000 paid Exchange seats and only works for Exchange Online licenses.
Group-Based Licensing and the Graph
Entra ID license assignments are performed using Microsoft Graph APIs, including the Set-MgGroupLicense cmdlet from the Microsoft Graph PowerShell SDK. License assignment operations can be tricky if you don’t understand the structure of product SKUs and service plans and how these are passed to the Graph. However, when done correctly, the Set-MgGroupLicense cmdlet can swap licenses. Conceptually, it’s no different to swapping directly assigned licenses using the Set-MgUserLicense cmdlet.
The GraphLicenseManager Module
To make group-based license swaps easy, I built the GraphLicenseManager module from PowerShell, Graph APIs, and Windows Forms. Sometimes, it’s just easier to do things through a GUI.
GraphLicenseManager can run interactively using the credentials and permissions for the signed-in user, or in an app-only Microsoft Graph PowerShell SDK session. This means that the session authenticates using an Entra-registered app with consent for the following application permissions:
- Organization.Read.All
- LicenseAssignment.ReadWrite.All
To run in app-only mode, an X.509 certificate must also be uploaded to the app (see this article for details).
After downloading the module, run:
<em>Install-Module GraphLicenseManager </em>
Next, start the app with:
<em>Start-GraphLicenseManager -logFolderPath c:\temp </em>
When GraphLicenseManager initializes, it displays a logon screen to establish the Graph connection. You must enter the tenant identifier (easily found in the overview screen of the Entra admin center) and decide if you want to use an interactive or app-only session. In the latter case, you must provide the object identifier for the registered app and the certificate thumbprint. If the tenant isn’t part of the Commercial Cloud, you can select a different Graph environment (like GCC).
After entering the necessary details, click Connect Microsoft Graph to connect and start the license manager (Figure 1).
Using GraphLicenseManager
When authentication has completed successfully the license manager is displayed. The process of managing or assigning licenses begins by entering the identifier (GUID) for the group to host the licenses. The group identifier is easily obtained from the overview properties for the group in the Entra ID admin center. The search button utilizes the group object ID to retrieve group properties, license templates assigned, and details of the product SKUs and service plans for the tenant. This information is populated into the GUI.
The specified group might already be used for license assignments. It is a common scenario to leverage the same group to swap licenses. If a license is already assigned to the group, the SKU manager displays details of the SKUs and plans already assigned to the group. The SKU manager is also where any changes to the desired license template is made.
The license manager includes a table with a summary view of all SKUs subscribed to by a tenant. The summary view is helpful in understanding the capability status of SKUs, for example, enabled, warning, or disabled. The table also provides a quick snapshot of SKU utilization for each subscription (Figure 2).
Swapping Licenses with GraphLicenseManager
When swapping licenses, generally two common paths are followed. The first is a license swap in one operation. The second is where both licenses are assigned to the user for a period of time. The graph license manager can accomplish both.
When assigning both licenses to a user account, it is important to avoid overlapping plans. In the example where a user is assigned an Office 365 A1 Student license and that should be swapped for a Microsoft 365 E5 license, a plan conflict exists for Yammer because both SKUs include a Yammer service plan. To perform the swap, the Microsoft 365 E5 is assigned to the account. When the tool attempts to assign the Microsoft 365 E5 license, the commit operation detects the plan collision for Yammer and works around the problem by removing the Yammer service plan from the Office 365 A1 license before assigning the Microsoft 365 E5 license. Later, the Office 365 A1 Student license can be removed from the account to complete the swap (figure 3).
To perform a swap operation where licenses are removed and added at the one time, it is important to process a single license at a time. If multiple licenses are involved, it is possible that users may lose access to services during the swap. To perform the swap, the tool removes the original license and replaces it with a new license. The actions required to execute the swap occur over a short period to minimize the chance that users will experience any loss of service.
The assignment of the new license can be confirmed by running a search operation against the same group to check that the user is now present.
Summary
Everything that I’ve described above can be handled by running Graph commands manually or through a PowerShell script. However, by wrapping the commands in a GUI, license assignment actions, especially swaps, are easier and more reliable for administrators who aren’t accustomed to working with Graph PowerShell.
The Real Person!
The Real Person!
Thanks for the quick and detailed response, Tim. This is very valuable info and we will definitely consider this way of managing license moves. It will be a little more research up front, but seems like it may be very well worth it. Thank you again.
The Real Person!
The Real Person!
Great article, thank you. What if we wanted to change user licenses by managing their membership in Entra groups? For example, when upgrading users from an E3 license to an E5, we would do a bulk import operation in Entra of the users to the new group that is assiged the E5 licenses. Then shortly after, a bulk operation to remove them from their old E3 license group. Would this work as well? Thank you.
Thanks for the comment.
Changing group membership to solve this issue can often lead to the same problems as attempting to swap the licenses in the M365 admin center.
When you remove the user from the E3 group and then add them to the E5 group this is all a matter of when the removal is processed and then when the license is processed. You could have the E3 removal processed before the E5.
In general I recommend two paths for this –
Change the license on the group entirely as a single operation as outlined in this article. This obviously does everyone.
If you want to do a small group at a time – I recommend using a license transition group. Essentially you would create a group and assign the same E3 that is on the users today. You would add the users to this group – and after license processing occurred remove them form the original. Then swap the license on this group, allow it to process, and add them to the final E5 group. Its certainly more work – but it really ensures that you do not put yourself in a situation where users loose their licenses.