Office 365 Licencing templates
It would be handy if you could licence users based on a licence template! Then if you wanted to add / remove a feature for example “Yammer” it could be done on the template. My client in the education sector would have multiple templates, an example of template for student would be,
- Student template
-- PLAN - Office 365 Education for students
--- Sway – Enable
--- Yammer – Disable
--- Office Online for Education - Enable
--- Skype for Business Online (Plan 2) - Disable
--- SharePoint Plan 1 for EDU - Enable
--- Exchange Online (Plan 1) - Enable
-- PLAN - Office 365 ProPlus for Students - Enable
-- PLAN - Power BI (free) - Enable
The benefit of this would be if they wanted to allow students access to Skype for business they would only need to update the template instead of running a PowerShell script.
S. Porter commented
We are also having problems with enabling services/plans after the fact- we get the "invalid license" error. This system is awful, there should simply be a set-msoluser enableplan and a set-msoluser disableplan. Forget the licensing, if the license doesn't exist, the command should error out.
The template needs to be able to handle licenses that have a portion disabled.
Murray Webber commented
Currently, we see the following:
a) A new user is created on-premises and synchronised to Office 365. At that time, they have no location or licenses applied. These users cannot use the services they need until an admin is notified or finds out.
b) As admins, need to check the "Unlicensed Users" filter, or run a PowerShell query to find unlicensed users, and then need to assign a license to them. There are no notifications. There is no automation, beyond scheduled PowerShell scripots we make ourselves.
c) When assigning licenses via PowerShell, the default is to always assign whole licenses, and then remove components later; which is complex, ever-changing, and somewhat backwards right now. Unlike the web Admin, you also can't replace all licenses with a selection, you need to remove individual licenses and add replacement ones; and if you get the order incorrect, or something goes wrong, you risk data loss.
d) Making matters worse, thanks to education users being able to obtain their own ProPlus license without admin approval - that happened... thanks Microsoft - users now have inconsistent licensing, with some products enabled across multiple licenses, with various components of licenses assigned from each. It's a mess. PowerShell licensing scripts error out when multiple component licenses exist, or when licenses exist or don't exist, so unless you write a lot of administration scripts and perform a lot of checks, you'll fail to replace licenses. It's easier, at that stage, to load up the web UI.
e) But the admin Web UI is also broken. You can only edit licenses for one hundred (100) users at a time. You can't perform actions against more and have them split into group of 100, it just doesn't let you continue. You also can't create "pages" of users, to make selecting 100 at a time easier, because the page loads as an endless single list of users as you scroll down. This also rules out using the "select all" box, and requires you to perform manual clicking on users. It's horrible, and the page sometimes fails to load users as well, which further frustrates the admin.
So, for us, when our executive/board declared that Yammer is to be turned off for students (for now), that meant removing a component from nearly two thousand (2000) accounts, by hand, in groups of one hundred (100). And it couldn't be automated due to the licensing issues discussed above, and the fact that PowerShell doesn't offer the same "replace all licenses with the selected" functionality that the web UI provides. And because the Admin page was broken when we did it, we had to manually select users one screen at a time (which meant twenty students at a time). Do you have any idea how long that took!? This is something that can be easily achieved by using groups/collections, and licensing templates. For example, we'd like to:
- Create a query-based collection for students, using something similar to the "Filters" in the "Users" area, to include all users from our student domain. Any new students that are created and synchronised to Office 365 will obviously be a member of this collection.
- We then create a license template for that collection, and apply it.
- Regardless of the number of users, we simply click "Apply" and wait. Even if the back end of Office 365 can only handle 100 user operations at any one time - as is the limit when using the Admin page - it should queue up the actions in groups of 100 automatically. The user should not need to manage this. If this is a "safety feature", then display the appropriate "Are you sure" prompt, with appropriate information about the action, and let us continue if it what we desire.
- After a couple of minutes, the licenses are applied, and we're all happy. There is no longer a need for scheduled PowerShell scripts or visits to the Office 365 Admin page. Users are automatically licensed as required.
- Using this concept, if we want to allow Yammer for a sub-set of students, we'd build a new student collection (possibly using the above collection as a "Limiting Collection"), and further limited via synchronised Active Directory attributes and/or direct membership. We'd then simply add the Yammer license to this group, and have this enable the new license component for all the members.
I don't understand why Office 365 doesn't support groups/collections. Using Configuration Manager, on-premises SharePoint, etc., everything is scoped and limited to collections of users (audience), based on groups. Why is Microsoft's cloud solution all about assigning individual UPN access to things? This just makes management harder than it needs to be. Even permissions in SharePoint Online are based on individual UPNs instead of groups. Why? Okay, I've finished my rant.
What about the ability to assign licenses to groups? So if you have a "student" group then you can assign licenses to this group.
Jan Tamas commented
I Agree with this idea,
On a corporate level it would make even more sense as I could create a template for example HR
and a separate one for other user etc.
Matt M. commented
I'd like to tack on to this idea. Powershell is a great way to automate user licensing, but this is a core administrative action and I believe this should be available directly in the GUI portal.
It should be simple to set up entitlement plans using conditions based on user attributes. For our own use, we would benefit greatly from being able to set license plans based on UPN domain name and the department attribute. In a way I think this would be similar to setting up dynamic distribution lists in Exchange, but with a simpler to use interface or syntax.
Even if this is never added to the GUI portal, we should definitely have easier licensing in Powershell. For instance, setting -DisabledPlans in license options is totally wrong. When a new service plan becomes available in our SKUs, which does happen, it will be on by default. Setting enabled plans in the license options would be the preferred way to approach this so that we have to explicitly add new service plans in our automation scripts.