Home » Blog » Managing Office 365 Licenses with the Azure AD V2 PowerShell Module

Managing Office 365 Licenses with the Azure AD V2 PowerShell Module

In Office 365 we have three methods of managing license assignments for individual or multiple user accounts.

The Office 365 admin portal provides a simple web interface for managing license assignments. It's easy to add a license for a user, or for multiple users, enable or disable sub-SKU features (the individual services that are included in a license), or remove a license. Licenses for multiple users can be managed at the same time. This method is useful for ad-hoc license management, or for bulk assigning licenses when you first provision an Office 365 tenant. The web interface is friendly for even a non-technical user, so license management tasks can be delegated to people outside of IT support if necessary.

Azure Active Directory group-based licensing, which I wrote about here, simplifies license management by mapping license assignments to groups. License management for end users is then a simple task of adding or removing users in groups, and doesn't require the ongoing use of Office 365 management tools.

In this article I'm going to demonstrate how to manage Office 365 licenses using PowerShell. This is more complex than either of the previous methods, but is useful for automating license assignments as part of a user provisioning process. PowerShell is also a good method for querying license usage and generating your own custom reports for license consumption, which can help you to manage your costs over time.

We'll look at:

The Azure AD V2 PowerShell Module

License management in Office 365 is performed using the Azure Active Directory PowerShell module. The first version of this PowerShell module is also known as the MS Online module, and uses cmdlets with “Msol” in the name, for example Connect-MsolService and Get-MsolUser.

While the MS Online module is still available today, it will be deprecated in the near future. A new Azure Active Directory PowerShell V2 module has been developed to replace it. This module is also known as the Azure AD module. The Azure AD module uses the Office 365 Graph API to interact with Office 365. Microsoft aims to migrate the functionality of the MS Online module to the Azure AD module, and recommends that you use Azure AD for any script development. In this blog post I will demonstrate license management using the Azure AD module.

The Azure AD module is installed using PowerShellGet, which is included with Windows Management Framework (WPF) 5.0 (PowerShell 5.0). Windows 10 and Windows Server 2012 R2 or later ship with PowerShell 5.0 installed by default, which means that PowerShellGet is already available. For earlier operating systems, you'll either need to upgrade to WMF 5.0, or install PowerShellGet for PowerShell 3.0 or 4.0. Some applications such as Exchange Server are sensitive to changes in the version of WMF that is installed on the system, so you should not upgrade WMF until you've verified that all your installed software will continue to work

After the Azure AD module is installed you can connect to your Office 365 tenant by running the Connect-AzureAD cmdlet, and then entering your admin credentials when prompted. The Azure AD module supports the use of multi-factor authentication (MFA).

To explore the available cmdlets in the Azure AD module, run the following command.

As a side note, Connect-AzureAD will work with stored credentials function as long as your account does not require MFA or you're connecting from a network that allows MFA to be bypassed.

Listing Available Licenses

The Get-AzureADSubscribedSku cmdlet is used to query the licenses that your organization has subscribed to in Office 365.

A more detailed view of the licenses that are enabled and consumed is available by expanding the PrepaidUnits property.

In the output above we can see that my tenant has 25 “ENTERPRISEPACK” licenses, and 5 “EMS” licenses. The SkuPartNumber for each does not precisely match the name of the license that you'll see in Office 365 documentation or in the license management sections of the Office 365 admin portal. For example, ENTERPRISEPACK is the SkuPartNumber for the Enterprise E3 license, while EMS is the SkuPartNumber for the Enterprise Mobility and Security E3 license. A complete list of part numbers and friendly names isn't available on Microsoft online documentation sites, although with a little searching and common sense you can usually work out what they mean. If there's any confusion, opening a support ticket with Microsoft will get you the answers you need.

The individual license features and services, also referred to as sub-SKU features, can also be inspected. As with the SkuPartNumber values, the ServicePlanName values are not a match for the friendly names that you see in the Office 365 or Azure admin portals, but names like SWAY, POWERAPPS_O365_P2, and EXCHANGE_S_ENTERPRISE are obvious. Others are not so obvious, such as MCOSTANDARD (Skype for Business Online), but again some searching online will usually clear up any confusion.

Querying License Assignments for User Accounts

There are two user properties that reveal the license assignments for a user. The first is the AssignedLicenses property, which can be retrieved using Get-AzureADUser.

In the output above we can see the SkuId of the license that is assigned to the user. The matching license can be found by running Get-AzureADSubscribedSku, which in the ouput below we can see is the ENTERPRISEPACK license (Enterprise E3).

The Get-AzureADUser output shown above also reveals the DisabledPlans property. This property contains the ServicePlanId values of the sub-SKU features that have been disabled for the user. There are two ways to match those ServicePlanId values to the actual names of the sub-SKU features. The first is to use the output of Get-AzureADSubscribedSku to view the ServicePlanId values for the individual services, as demonstrated earlier. For the example of Jane Tulley, the ID of the disabled plan is “7547a3fe-08ee-4ccb-b430-5077c5041653”, which is YAMMER_ENTERPRISE in the list of service plans for the ENTERPRISEPACK license.

The other approach is to look at the AssignedPlans property of the user.

In the output above we can see that the “YammerEnterprise” service is suspended, and has a ServicePlanId matching the ID in the list of DisabledPlans we saw earlier.

You will also notice that the service names returned in the Get-AzureADUser output do always not match the service plan names returned in the Get-AzureADSubscribedSku output. For example, Get-AzureADUser shows a service name of “TeamspaceAPI” whereas Get-AzureADSubscribedSku shows the same service as “TEAMS1”. These differences are mildly irritating but do reinforce the idea that you should match two difference pieces of data by the ServicePlanId, not by the friendly name, whenever you are running PowerShell cmdlets or writing scripts to manage your licenses.

For administrators who are familiar with using the MS Online PowerShell module to manage licenses, there is one minor difference to be aware of. The Get-AzureADUser and Get-MsolUser cmdlets return slightly different information for the same user object. Get-AzureADUser will only return sub-SKU features that are Enabled, Deleted or Suspended, whereas Get-MsolUser will return the status of all sub-SKU features. Here's an example, using an account where I've disabled several sub-SKU features to demonstrate the differences in cmdlet output.

Assigning a Single License Using PowerShell

The Set-AzureADUserLicense cmdlet assigns and removes Office 365 licenses to user accounts. A simple example is assigning a license to a new user account. Before assigning the license, the usage location of the account also needs to be configure. The license assignment process involves a series of steps to:

  1. Create an assigned license (singular) object
  2. Add the assigned license object to another object representing the assigned licenses (plural)
  3. Run Set-AzureADUserLicense and provide the value for the assigned licenses (plural)

To perform those steps we need to know the ObjectId of the user account, and the SkuId of the license.

Now we can go ahead and create the license assignment.

The user now has a single license SKU assigned, and the plans for that license are enabled.

Assigning Multiple Licenses Using PowerShell

Using the same steps as above you can assign an additional license to a user. For example, if we wanted to add the EMS license to the user who is already licensed for Enterprise E3, we could simply re-run the steps above using the SkuId for the EMS license.

If you would like to assign multiple licenses at the same time you can do so with just a small modification to the process. Remember, we're creating an assigned license (singular) object, and adding it to an assigned licenses (plural) object. We can add multiple assigned license (singular) objects by repeating those commands. Here's an example of licensing a user for Enterprise E3 and EMS at the same time.

The user now has multiple license SKUs assigned, and the services for both of those SKUs are enabled.

In the output above you might notice that Intune, which is included with the EMS license, is not listed as a service. This is another example of how Get-AzureADUser doesn't show services that are not in an enabled, suspended, or deleted state. Intune requires activation for the user, and is in a “PendingInput” state when the license is initially assigned to the user as you can see in the Get-MsolUser output below.

Assigning Licenses with Sub-SKU Features Disabled

Office 365 licenses such as Enterprise E3 and E5 allow access to multiple services and applications. For some organizations it is required to disable some of the features of a license, either because the feature should not be used in that environment, or simply to manage a staged roll out and adoption of Office 365 features.

To assign a license with sub-SKU features disabled we use the same process demonstrated earlier, but this time we need to configure the license object with enable and disabled plans before applying the license to the user. For this example I'll assign an E3 license but only enabled the Exchange Online mailbox and the Office 365 ProPlus applications.

The user now has the license SKU assigned, but with multiple disabled plans. Only the two enabled features are showing as enabled services for the user as well.

Removing Licenses Using PowerShell

For the final demonstration in this article let's look at how to remove an assigned license using PowerShell. The Set-AzureADUserLicense cmdlet is used for this task, and the process is similar to adding a license. The difference is that when creating the assigned licenses (plural) object we use RemoveLicenses instead of AddLicenses, and provide only the SkuId instead of the full license object.

The user has now had each of the previously licensed features marked as deleted due to the license being removed.


As you can see, managing Office 365 licenses with the Azure AD V2 PowerShell module is a complex task at first, but once you've performed the steps a few times it should become much more comfortable. Azure AD group-based license management is simpler, but won't fit everyone's needs. Using PowerShell to manage licenses like this will suit organizations who want to automated license assignments into other processes. The use of the Graph API also means you can ignore the Azure AD module itself and write custom code to interact with the REST API to perform the same tasks. That is out of scope of this blog post, but it's something you can explore if custom development and integration into third party systems is a requirement for you.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Blog


  1. Matthew Silcox says:

    This probably won’t help you, but maybe it will help someone else who reads your blog. Your bit on removing licenses was helpful; however, we have a ton of SKUs. There’s no way my Junior Admins or I will remember the SkuIDs for these…so I needed a way to easily remove licenses from a user account without having that information. I wrote this module:

    function global:Remove-CompanyUserLicense ($delicenseUID)




    $delicenseEmail = $delicenseUID + ‘@company.com’
    $Current = Get-AzureADUser -ObjectId $delicenseEmail | Select -ExpandProperty AssignedLicenses
    $License = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
    $License.SkuId = $Current.SkuId
    $LicensesToAssign = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses
    $LicensesToAssign.AddLicenses = @()
    $LicensesToAssign.RemoveLicenses = $License.SkuId

    Set-AzureADUserLicense -ObjectId $delicenseEmail -AssignedLicenses $LicensesToAssign

    Write-Host -ForegroundColor Cyan “License has been removed on $delicenseEmail.”




    Write-Output “Error clearing license.”



    I’m sure there is a more efficient way to do this, as my Powershell is a bit green. At any rate, I thought it might help save someone some time. Great blog, by the way!

Leave a Reply

Your email address will not be published. Required fields are marked *