In todays episode of discovering awesome features in SharePoint 2013 we’re going to take a look at something really interesting, a feature that has been requested for years, a better management of end-user licensing in SharePoint.
Even though this article contains a lot about SharePoint 2013 licensing I must make it very clear that nothing has yet been communicated from Microsoft regarding licensing on SharePoint 2013, and I am no expert on licensing and this is a Preview and this article must be considered as-is, things will and might change over the course of time. Remind me to go back to this article once SharePoint 2013 has gone gold. Microsoft has not made any statements about this and it might be so that you can forget about this article after RTM.
SharePoint has historically existed in two versions, the free called SharePoint Services or SharePoint Foundation and the paid version named SharePoint Server (built on top of SharePoint Foundation). SharePoint Server has had two editions (I’ve no idea how it will be in SharePoint 2013 RTM, but most likely the same as today) – Standard and Enterprise, where Enterprise is the most expensive one requiring specific Enterprise CALs. For some companies it is just a too big expense to go for the Enterprise version, due to the limit that you need(ed) to have Enterprise licenses for all users in the SharePoint farm. But in some cases only a small subset of the users actually require the Enterprise license (which has a lot of the BI and integration stuff). And a lot of companies I’ve met can not justify the extra investment for this. I’ve seen numerous ways to work around this (remember I’m no licensing expert so I’m not saying it’s the legit way to do it). Multiple farms – one standard and one enterprise, is the most obvious one. Downside is that you need to double up on everything (almost)! I’ve seen companies use the multi-tenancy features in SharePoint 2010 to work around it – a really bad decision. And some other ways that we should not discuss here…
Introducing the User Licensing Features in SharePoint 2013 Preview
In SharePoint 2013 Preview there are eight new Windows PowerShell cmdlets, that we are going to cover in this post:
What do these cmdlets do and how do we use them? I’ve been experimenting with the Preview and these cmdlets and set up a sample scenario, which is extremely interesting given the problem statement above about combining Standard and Enterprise licenses.
For another great example on how to use these cmdlets I recommend reading Spence Harbar’s post “Enabling Office Web Apps Preview editing with SharePoint 2013 Preview Licensing” which focuses on how to handle the licensing with the new Office Web Apps server.
Enforcing User Licensing in SharePoint 2013 Preview
Let’s start from the top of that list of cmdlets. If we execute the Get-SPUserLicensing cmdlet in a SharePoint 2013 Preview farm it will return false by default. If we take a look at the help text of that cmdlet we will see something really interesting, The synopsis says “Returns the state of user-license enforcement.”. Looks like we can control/enforce licensing in some way in SharePoint 2013!?
If we move on to the Enable-SPUserLicensing cmdlet and run that cmdlet (Synopsis: “Enables user-license enforcement.”), and then run the Get-SPUserLicensing cmdlet again. It will now return true instead of false – wow, we’ve just enabled User License Enforcement in this farm! We’re on to something really interesting now!
To get back to normal, just run the Disable-SPUserLicensing cmdlet.
Actually, all these cmdlets do is to check or update the Farm property called UserLicensingEnabled. You can check it for yourself:
Note: You should leave the user licensing disabled until you have configured all your license mappings, as I’ll describe in a minute. Not doing so can result in unwanted results.
If we now take a quick look at the Get-SPUserLicense cmdlet and run it. It will return four different licenses; Enterprise, Standard, Project and OfficeWebAppsEdit.
Very cool, huh. I think now you’re starting to get a picture on where we are going with this scenario…
User and license mappings
Let’s take a look at the remaining cmdlets *-UserLicenseMapping. First let’s run Get-SPUserLicenseMapping – it will return nothing. So let’s try to create some.
Before we start that, let’s make sure we have something to do the mapping with. For this I created two Security Groups in Active Directory called “Standard Users” and “Enterprise Users“.
Now, let’s use the New-SPUserLicenseMapping cmdlet and try to create a mapping. The following command creates me a mapping using the “Standard Users” group (the name of the AD group) to the “Standard” license (the name of the license from the Get-SPUserLicense cmdlet):
1 $map = New-SPUserLicenseMapping -SecurityGroup “Standard Users” -License Standard
If we take a look at the $map variable it looks like this:
There’s plenty of cool stuff in that picture. First of all notice that the -SecurityGroup argument to the cmdlet is converted to a claim, and if you take a look at the New-SPUserLicenseMapping cmdlet you can see that you actually can add a claim directly (for instance create a mapping for all users sitting in a specific building, belonging to a specific department etc…). Also notice that the WebApplication value is empty here – the New-SPUserLicenseMapping cmdlet can also take a Web Application as an argument, which means that you can configure licensing on a per Web Application basis.
This mapping is so far only created “in-memory”, we need to add it to the farm, this is done by just using the Add-SPUserLicenseMapping cmdlet like this:
1 Add-SPUserLicenseMapping -Mapping $map
We’ll add another mapping, this time using the other group and the “Enterprise” license, and add it to the farm:
1 $map = New-SPUserLicenseMapping -SecurityGroup “Enterprise Users” -License Enterprise
Now, we can run the Get-SPUserLicenseMapping again and see our result:
We have now created two license mappings – one for Enterprise license users mapped to the Active Directory group “Enterprise Users” and one for Standard license users mapped to the “Standard Users” group.
All that is left is to verify that it all works!
Verify the license assignment
To see if it all works, as we all now hope it should, let’s create a page with, let’s say, the Excel Viewer Web Part. In this case I use a user which is member of the “Enterprise Users” group to create the page and add the Web Part. It looks like this, just as we expect:
Ok, let’s log in as a user who is member of the “Standard Users” group and go to the very same page:
What! Did you see that. It’s worth a close-up:
Woohaa! This must simply be one of the best features ever implemented in SharePoint!
Even if I take a look at that page using a user that is not part of any of the two groups with license mapping (i.e. not having any license) it will show me that I don’t have licenses to use it.
Let’s do another test – edit the page and look at the available Web Parts using the two users. And as you can see the Standard user cannot add the Enterprise Web Parts.
Enterprise user Standard User
Where is this licensing enforced?
I’ve been fiddling around in excitement with this and found that the licensing is enforced in the following places, which seems the logical places to have it enforced:
•Web Parts – just as you’ve seen above
•Web Part Gallery – second example above
•Web Templates – when creating new sites
•In Document Libraries – in combination with Office Web Apps permissions (as Spence Harbar explains here)
What areas does it affect, prohibit usage?`
Although I have not tested all features, some testing and reverse engineering have told me that these are the things you get with the different licenses:
•Standard: My Sites
•Enterprise: Access Services, BCS, BI-stuff, InfoPath, PerformancePoint Services, Visio, My Sites (and some more)
•Project: Project Server
A couple of notes…
To get this to work, you need to have a Claims Web Application – without it, it just don’t work!
This article is all about on-premises installations. There are features in this capability only for SharePoint Online/365 to satisfy those needs (desk less users etc.).
Do not “over design” your license mappings for a manageability reasons. It defeats the whole purpose of this feature – you need to know what users have what licenses. And nothing is worse than having your end-users getting the message that they don’t have permissions to use the features they are entitled to.
Make sure that you have a fallback mapping! As I mentioned if any user does not fit into any of these mappings they will not even have access to the “Standard” features.
There is only Windows PowerShell configuration for this. Nothing fancy in the Central Administration that helps you visualize it. It is all up to you to create the correct scripts. Oh, and to document this configuration!
I think Microsoft finally nailed it! If all this works as above when SharePoint 2013 RTM’s and it actually can make clients combine Standard and Enterprise licenses in a single SharePoint farm, without violating any license agreements, this is going to be huge. Using these features you can actually have control of exactly how many users that have access to a specific license and pay for the correct amount of licenses. I can for sure tell you that Microsoft will get a handful of new clients and especially Enterprise CAL users, just from my set of clients. Also this will clear up a lot of the licensing discussions and most likely prohibit people from doing really stupid design decisions/mistakes. And this fits very nice where Microsoft is going as well, into a more versatile and agile licensing/subscription model and it will likely be easier for clients to move to the cloud/Office 365 if they start thinking about subscriptions internally (as in don’t let the IT department pay all the licenses, let the ones having needs for it pay it instead).
Finally SharePoint has a solid and manageable way to configure licensing within a single farm. Really looking forward to discuss this new feature with my clients.