In August 2016 we announced some changes to the Project Online plans - https://support.office.com/en-us/article/Important-information-for-Project-Online-customers-abo... and now we are in 2017 more of you will be either starting or renewing to these plans. This can be a challenge to swap the old sku for the new sku – particularly when these are not necessarily a one to one mapping for your users. A quick note on terminology around skus and plans (and I don’t mean project plans – or for that matter Planner plans…).
First however, lets just recap what changed.
We retired Project for Office 365, Project Online and Project Online with Project for Office 365 (we had dropped the ‘Pro’ part of the client name earlier in the year). Project Lite was renamed to Project Online Essentials. The new plans were Project Online Essentials (the renamed Project Lite) as well as two new skus that both include the Project Online Desktop Client (the new name for Project for Office 365) – Project Online Professional and Project Online Premium. The article mentioned above covers more details about these different plans and your options for renewing but basically the only straightforward change is Project Lite to Project Online Essentials. If you have purchased just Project for Office 365 then most likely you would switch to Project Online Professional – and if you have Project Online or Project Online with Project for Office 365 then you have a choice. If your users need access to the Portfolio features, demand management or the new Resource Engagement features then they should move to the Project Online Premium – otherwise Project Online Professional will be enough. Easy?
The main focus of this blog post is to help guide you through this process – and it breaks down into 7 steps:
- What do you currently have in terms of users and skus? We have some PowerShell to help!
- What are your options? So read the article mentioned above and also the Service Description – which covers the capabilities for each sku in more detail.
- Identify which users need which new skus based on analysis of 1 and 2.
- Buy or renew to the new skus as required
- Assign the new sku/licenses to your users. We have some PowerShell for that too!
- Ensure you don’t have any users on the old skus.
- Cancel any remaining old skus.
A quick note on terminology around skus and plans (and I don’t mean project plans – or for that matter Planner plans…). A sku usually refers to the top level item that you purchase by subscription – like Office 365 Enterprise E3, or Project Online with Project for Office 365 – but has a different name – like BriSmithPJO:ENTERPRISEPACK and BriSMithPJO:PROJECTONLINE_PLAN_2 for the two examples I have given (BriSmithPJO is my tenant name). Then plans are items that come with the sku and are the level that you tend to make license assignments. For example the sku BriSMithPJO:ENTERPRISEPACK has plans that represent Flow, PowerApps, Sway, Planner and many more – and BriSMithPJO:PROJECTONLINE_PLAN_2 has plans of SharePointWAC, SHAREPOINTENTERPRISE, PROJECT_CLIENT_SUBSCRIPTION and SHAREPOINT_PROJECT. From the Project Online perspective these are the old skus and plans – but happen to be the ones on my trial tenant. For comparison with the new names this table should help:
|
List of possible old SKUs |
List of possible New SKUs |
|
PROJECTONLINE_PLAN_1 PROJECTONLINE_PLAN_1_STUDENT PROJECTONLINE_PLAN_1_FACULTY PROJECTONLINE_PLAN_2 PROJECTONLINE_PLAN_2_STUDENT PROJECTONLINE_PLAN_2_FACULTY PROJECTCLIENT PROJECTCLIENT_FACULTY PROJECTCLIENT_STUDENT |
PROJECTPREMIUM PROJECTPROFESSIONAL PROJECTPREMIUM_STUDENT PROJECTPROFESSIONAL_STUDENT PROJECTESSENTIALS_STUDENT PROJECTPREMIUM_FACULTY PROJECTPROFESSIONAL_FACULTY PROJECTESSENTIALS_FACULTY |
To help with steps 1 and 5 we have some PowerShell, and my colleague Matt Byrd has put together a great script that can report on current usage and output a cool CSV file that you can play around with in Excel to see which users have which licenses – then the same script can handle switching licenses or adding new skus to users. For those who might like to understand how all this happens I’ll start with a couple of basic scripts to group users by sku and skus by user – then unleash Matt’s script.
All these scripts require you to connect to your tenant from PowerShell – so you will need to have installed the required modules – and this article https://support.office.com/en-us/article/Managing-Office-365-and-Exchange-Online-with-Windows-P... is a good one to review to make sure you have the right modules.
Some simple stuff first – and then I’ll introduce a script form the script gallery that will help you. If you just want to see which users have which sku license – and which sku is licensed to which users – you could simply run the following PowerShell – which outputs to the screen but you could redirect to a file. It will prompt you to login to your tenant – and you will need to be an admin with access to the licensing options in Office 365 admin portal.
# Throw up a login window - log in to tenant
Connect-MsolService# Get Users and see which sku they have assigned
$Users = Get-MsolUser
ForEach($User in $Users){
Write-Host $User.DisplayName " has the following Sku(s)"
Write-Host $User.Licenses.AccountSkuId
}#Get Skus and see which users are assigned
$Skus = Get-MsolAccountSku
ForEach($Sku in $Skus){
Write-Host $Sku.AccountSkuId
$SkuUsers = Get-MsolUser | where {($_.Licenses.accountskuid -Like $Sku.AccountSkuId)}
ForEach($SkuUser in $SkuUsers){
Write-Host $SkuUser.DisplayName
}
}
My colleague from the Exchange Online support team, Matt Byrd, came up with a very comprehensive script which you can get from the script gallery at https://gallery.technet.microsoft.com/Manage-your-O365-Licenses-b23ccd16
In Matt’s words, this script:
Helps automate common license management tasks by providing a simpler set of switches on existing PowerShell Cmdlets.
- Add a new SKU.
- Replace one SKU with another.
- Provides a picker for chosing a SKU if not specified.
- Disable plans within a SKU when adding or replacing.
- When making changes only operates on a specified set of users.
- Comprehensive report of assigned SKUs and enabled plans
You can use Get-Help on this command too to get the usage and examples – and the first thing that will help with step 1 above will be the –Report option. The full command, including agreeing to the disclaimer in the script (You should read this first of course) and setting an output log file would look like this – and I also show the output I see from my test tenant (I was already connected (Connect-MsolService)
PS C:\PowerShell> .\Manage-MSOLLicense.ps1 -IAgreeToTheDisclaimer -Report -LogFile .\BlogReport.log
[1/20/2017 9:16:29 AM] - Created 01/10/2017
[1/20/2017 9:16:29 AM] - Agreed to Disclaimer
[1/20/2017 9:16:29 AM] - Reporting Mode
[1/20/2017 9:16:29 AM] - Generating Sku and Plan Report
[1/20/2017 9:16:30 AM] - Found 3 SKUs in the tenant
[1/20/2017 9:16:30 AM] - Found 17 Unique plans in the tenant
[1/20/2017 9:16:30 AM] - Getting all users in the tenant
[1/20/2017 9:16:30 AM] - Found 56 users in the tenant
[1/20/2017 9:16:31 AM] - Finished 25 Users
[1/20/2017 9:16:31 AM] - Finished 50 Users
[1/20/2017 9:16:31 AM] - Exporting to .\License_Report_20170120.csv
[1/20/2017 9:16:31 AM] - Report generation finished; exiting
The requested logfile also contains the output shown above – but the really interesting piece is the csv file that is created. Assuming you have Excel installed then you can just open the csv file and see the report. Using the Sort and Filter, Filter option – and setting the column widths you then have a neat report like this:
I’ve filtered my user list and shrunk some of my columns to make things fit – but you can see in Column C the sku that is assigned – and then columns D to T show the plans available under those skus and their status. Success means it is licensed and provisioned – Pending Provisioning means it is licensed but probably hasn’t been used by that user yet – and Disabled means that specific plan is disabled for that user (More on disabled plans later…)
From there it is pretty easy to select just users having specific skus to see who needs to have their license changed (I just have the ‘old’ licenses in my test trial tenant – so not a great example). Once you know who needs to have their licenses changed you can use Matt’s tool with the –NewSKU and –ExistingSKU parameters set to swap out the old for the new SKU. Again Get-Help has some guidance here – but an example of using the script to achieve step 5 above might be:
C:\PS>$Users = Get-MsolUser | where { ($_.Title -eq "Staff") -and ($_.Licenses.accountskuid -notlike "*PROJECTPREMIUM")}
.\Manage-MSOLLicense.ps1 -IAgreeToTheDisclaimer -Users $Users -LogFile c:\temp\license.log -NewSKU company:PROJECTPREMIUM -ExistingSKU
company:PROJECTONLINE_PLAN_2 -DisabledPlans "SWAY,FLOW_O365_P2"
This command reads all your users who have a specific Title (in this case “Staff”) who do not already have the PROJECTPREMIUM sku. It then uses this array of users (held in the $Users variable) and passes this through to the Manage-MSOLLicense.ps1 script. The script agrees to the disclaimer, sets the log location and then sets the new SKU as PROJECTPREMIUM which will replace the old SKU PROJECTONLINE_PLAN_2. This example also shows the ability to use the –DisabledPlans parameter to disable SWAY and FLOW (Just an example – I have nothing against either SWAY or FLOW – they are really cool!)
Of course your situation may not be this simple – but you can use many filter options to select your users – it will really depend on individual circumstance and the number of users you manage for you to choose the best options.
Once you have re-assigned licenses you could run the report again to ensure everything is as you expected – and use the fresh report to be sure no one is on the old skus before you cancel them.
A couple of gotchas I should point out. First there are situations where having the same plan under different skus can cause errors. This was an issue with the old skus and the SHAREPOINT_PLAN_2 plan – which can be selected either under the ENTERPRISEPACK or the PROJECTONLINE_PLAN_2 but not both. If you tried to use this script to set such a condition it would error out unless you used the –DisabledPlans option. This should not be an issue assigning the new skus.
The 2nd gotcha relates to the use of the –DisabledPLans option and if you read my blog regularly (who wouldn’t!) then you will have seen me talk about this before in regard to Planner. Using DisabledPlans option will disable just the plans mentioned – but could then re-enable plans you hadn’t considered – or potentially if there was a new plan you were unaware of and hadn’t included it in DisabledPlans then it would get enabled. We certainly want to encourage you to use all the features of Office 365, but I do appreciate that from an administrative side you may sometimes want to limit licenses while you evaluate new features. I’m keen that you don’t get any surprises. For more details on this topic see my Planner blog - https://blogs.msdn.microsoft.com/brismith/2016/06/24/microsoft-plannerdisabling-planner-license... . For an interesting approach to Office 365 license management it is also worth reading Matt McNabb’s blog series and part 4 deals with disabled plans - https://mattmcnabb.github.io/Office-365-Licensing_4 .
I know this is a complex area but hopefully with the script from Matt Byrd and the CSV file you have all the information you need to decide how to move forward with the new skus and how to re-assign the licenses. Support is always happy to help too – just get your tenant admin to open an incident if you need some assistance. Or ask a question on the blog.