Skip Ribbon Commands
Skip to main content

Quick Launch

Todd Klindt's home page > Todd Klindt's SharePoint Admin Blog > Posts > Using PowerShell to Specify License Plans in Office 365
October 17
Using PowerShell to Specify License Plans in Office 365

It’s been a while since I’ve gotten a chance to get my hands dirty with some good old PowerShell and last week I got that opportunity. Here is the whole fabulous tale. Smile

A customer wanted some helping scripting out their migration to Office 365. They already had directory synchronization set up between their Windows AD and Azure AD. They are slowly rolling out Office 365 to their users, 10 or 20 at a time, and they are rolling out the services gradually. They’re starting with SharePoint Online. They’ll eventually migrate to Exchange Online, and of course they’ll never use Yammer. Smile Since they’re doing it in batches, PowerShell is the perfect tool to license up their users, but there was a snag. Adding a license to a user in PowerShell is easy, and it’s easy to apply individual license service plans to a user in the UI, but it’s not easy to do service plans in PowerShell, until today.

The Problem

Here is what the customer was trying to do:


We’re all familiar with using Set-MsolUserLicense to assign licenses to users. The problem is that it assigns all the service plans to the user. In our case we don’t want the user to be licensed for Exchange or Yammer, among other things. Figuring out how to combine the flexibility of the UI, with the the looping and scriptablity of PowerShell is what we’re after.

The Solution

Fortunately, PowerShell had the answer for us. With very little work I discovered the New-MsolLicenseOptions cmdlet. This does exactly what I was looking for. However, using it was a little tricky, so I thought I’d write it up.

The first step is to license one user in the UI exactly how you want all of your users to be licensed. We will essentially use this as a template. In our case, the screenshot above is our template. We will use PowerShell to see how that user is configured. I used this command:

(Get-MsolUser -UserPrincipalName


This gave me all the licenses that user has. We can use Get-MsolAccountSku to see which licenses are which, but we need to drill down one level deeper. We need to discover the service plan names of the Enterprise SKU. From the screenshot above we can see that it’s the first license listed. Because these lists are zero based, the first one is 0 and we get to it like this:

(Get-MsolUser -UserPrincipalName[0].servicestatus

And it looks like this:

2016-10-16_22-04-08 Blog 4 -edit

We can see the Service Plans that show as disabled are the same ones that are off in our first screenshot. More importantly it gives us the Service Plan names that PowerShell will need to use when setting our options. Here is how we set the options:


Now that we have that, we can license our users in the normal way with one additional step to set the options.

For completeness, here is the whole process. We have to set the user’s region, then apply the license, then apply the options for that license.

Set-MsolUser -UserPrincipalName -UsageLocation US

Set-MsolUserLicense -UserPrincipalName -AddLicenses "MOD873457:ENTERPRISEPREMIUM"

Set-MsolUserLicense -UserPrincipalName -AddLicenses "MOD873457:ENTERPRISEPREMIUM" -LicenseOptions $opts

And in pictures…


and more pictures:

2016-10-16_22-04-08 Blog 2 -edit

As I was testing this, I had better luck if I applied the license as a whole before I tried to add any options to it. And if Office 365 doesn’t like the values you put in for the license options, it will tell you when you assign the license to the user, not when you create the $opts variable with New-MsolLicenseOptions.

We now have a way to mass license users with specific functionality, and we also know how later on we can go through and toggle an individual service, like Exchange, once the company moves over to it.

Now you can amaze your coworkers once again with your PowerShell prowess.




be aware if you are using a hard coded list of disabled sublicenses

MS has added various sublicense options over the years, so any script that runs on a schedule, with a hard coded list of items to disable, runs the risk of assigning 'new' sublicense types when Microsoft introduces them..

If you're creating a script for long term license maintenance (ie one that will run daily for the next year) you may want to check out the following scripts:

This script adds SharePoint to an existing license if it exists, or assigns a new license if not:

This script can be used to add/remove any combination of sublicenses from an E1/E3, etc..
 on 10/17/2016 4:58 PM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.


Body *

Today's date *

Select a date from the calendar.
Please enter today's date so I know you are a real person


Want a message when I reply to your comment? Put your Twitter handle here.



 Please Support my Sponsors