Assign a License to an Office 365 User with PowerShell

There are several scenarios where you might need to assign an Office 365 license to a user. The specific scenario in this blog article is that you’re migrating an Exchange Server 2010 on-premises environment to Office 365. The Exchange Server is already in hybrid mode. Users have been automatically created in Office 365 by synchronizing them from your on-premises Active Directory environment using Azure AD Connect. Users who haven’t already had their mailbox moved to Office 365 will first need an Office 365 license assigned to them, and before a license can be assigned to them, a usage location must be set on their individual account.

This blog article is written using Windows 10 Enterprise Edition version 1803 and Windows PowerShell version 5.1. The examples shown in this blog article will not work with PowerShell Core. Your mileage may vary with other operating systems and other versions of PowerShell.

First, you’ll need the cmdlets to perform these actions. Find the MSOnline module in the PowerShell Gallery.

Install the MSOnline module from the PowerShell Gallery:

Store your Office 365 credentials with sufficient access to perform these tasks in a variable.

Connect to your Office 365 account. This is the part that will generate an error if you’re using PowerShell Core.

Check to see if you have more than one Office 365 subscription.

Store the specific account SKU with the licenses for the Office 365 subscription to assign to users in a variable.

Find the users to assign licenses to and store them in a variable. I found it useful to narrow these results down by filtering left with the UserPrincipalName and/or Department parameters of Get-MsolUser.

As you can see in the previous image, John Doe does not currently have a license assigned.

Assign a usage location.

Assign an Office 365 license.

A license has now been assigned to John Doe.

Although a single user was assigned a license, with the exception of the previous command, the code as it is written in this blog article can be used to assigned licenses to multiple users.

µ

9 Comments

  1. Nigel Heyman

    If you assign a license before migrating the mailbox, it will fail because if you assign a license and the mailbox does not already exist, it will automatically create a mailbox.

    I prefer to use connect-msolservice with no parameters so if I typed the password incorrectly I can retype if without the script failing.

    You are enabling the whole sku. In practice there are a lot of situations where this would not happen, like enabling office in the sku and then enabling exchange once the mailbox has been migrated.

    If you some services within the sku and then enable exchange without first checking what is enabled and specifying that you want to enable what is currently enabled, then the existing services will get disabled.

    Reply
    • Mike F Robbins

      #1 You’re definitely incorrect. I’ll post the error messages that I receive for the next users that I have to move.

      #2 I personally don’t want to know the password well enough to be able to key it in and there’s no chance of typing it in incorrectly when it’s copy and pasted from a password vault.

      #3 The first part is correct. I’ve assigned the entire SKU.

      #4 The checking was done as shown in the screenshot in my blog article where the user shows as unlicensed. That means no services are licensed for that user.

      Reply
    • Dustin

      Not the case. When you synchronize your directory, the Exchange GUID is replicated up. If there is an existing Exchange GUID, Exchange Online will not provision a mailbox when a license is applied. It can mess up, but it is because there is a problem with the GUID not getting synced. If there is no Exchange GUID, then that means there is no mailbox and it will provision a mailbox.

      Reply
  2. AJ

    Mike any reason for using Ms Online instead of the Azure AD module?

    Reply
    • Gary

      You actually need both, the MS Online Sign-in Assistant is required for Powershell to connect to any Office 365 service. Then you use the Azure AD module for administrating/managing it.

      Reply
      • AJ

        Gary I think you may be confusing the MS Online Sign-in Assistant for the MS Online PowerShell Module.

        You can login with the AzureAD module without the MS Online Sign-in Assistant
        Simply, ‘Connect-AzureAD’ once the module is installed (‘Install-Module AzureAD’)

        The cmdlets for the Azure AD module are prefixed with [verb]-AzureADxxx as apposed to [verb]-MSOLxxx.

        For example, to apply a license to a user using the Azure AD cmdlets (note the prefix):

        # Create the objects we’ll need to add and remove licenses
        $license = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicense
        $licenses = New-Object -TypeName Microsoft.Open.AzureAD.Model.AssignedLicenses

        # Find the SkuID of the license we want to add – in this example we’ll use the O365_BUSINESS_PREMIUM license
        $license.SkuId = (Get-AzureADSubscribedSku | Where-Object -Property SkuPartNumber -Value “O365_BUSINESS_PREMIUM” -EQ).SkuID

        # Set the Office license as the license we want to add in the $licenses object
        $licenses.AddLicenses = $license

        # Call the Set-AzureADUserLicense cmdlet to set the license.
        Set-AzureADUserLicense -ObjectId “Violeta.Collias@drumkit.onmicrosoft.com” -AssignedLicenses $licenses

        My question to Mike was asking why we would use one over the other.

        Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: