User License Enforcement in SharePoint 2013

Note: this post was first published in the European SharePoint Community blog.

Amongst the several new features included in SharePoint 2013, there is one that I have unfairly overlooked until just recently and that is User License Enforcement. I say unfairly because it’s a feature that has been requested for a long time and I believe it deserves more attention than it has been receiving.

Up until now, any user that accessed a SharePoint farm would have access to all the features included in the installed SharePoint SKU, regardless of the CAL (Client Access License) level assigned to her. This means that, if a company had a SharePoint farm with an Enterprise license, any user would be able to access all Enterprise features, even if it was assigned a Standard CAL.

On most large companies, for cost saving purposes, it’s quite common to find scenarios where only some of the users are assigned an Enterprise CAL, while every other user is assigned a Standard CAL. One way to ensure that each user can only access the features included in his license, is to have two separate SharePoint farms, one with a Standard SKU and the other with an Enterprise SKU. However, this is hardly an acceptable solution.

SharePoint 2013 solves this with the new User License Enforcement capability, which enables the mapping of licenses with specific users or Active Directory security groups. When User License Enforcement is enabled, users can only access the SharePoint features included with their license, otherwise they are blocked. When it’s disabled, which is the default, SharePoint behaves the same as in previous versions.

User License Enforcement management is performed exclusively through PowerShell cmdlets in SharePoint 2013 Management Shell. There are eight cmdlets which are explained in detail in the following sections:

• Get-SPUserLicensing
• Enable-SPUserLicensing
• Disable-SPUserLicensing
• Get-SPUserLicense
• Get-SPUserLicenseMapping
• New-SPUserLicenseMapping
• Add-SPUserLicenseMapping
• Remove-SPUserLicenseMapping

Enabling and Disabling User License Enforcement

To check if this feature is enabled, use the Get-SPUserLicensing cmdlet in SharePoint 2013 Management Shell. It will return true if the feature is enabled, and false otherwise (see Figure 1). As stated before, User License Enforcement is disabled by default.

Figure 1 – Usage of Get-SPUserLicensing cmdlet

To enable it, execute the Enable-SPUserLicensing cmdlet. To disable it, execute the Disable-SPUserLicensing cmdlet. Both cmdlets require no parameters and return no values (see Figure 2).

Figure 2 – Using the Enable-SPUserLicensing and Disable-SPUserLicensing cmdlets

Now that you know how to enable and disable it, I should advise you to keep it disabled until you have configured it properly. Otherwise you might involuntarily block access to Enterprise features for users that should have access to them or allow access to features that users should not be allowed to use.

Checking Available User Licenses

To check what licenses are available in your SharePoint farm, you can use the Get-SPUserLicense cmdlet (see figure 3).

Figure 3 – Using the Get-SPUserLicense cmdlet

There are five license types (although on my farm there are only four):

• Enterprise
• Standard
• Project
• OfficeWebAppsEdit
• Duet

The Enterprise and Standard licenses are the two SharePoint Server editions, which have been around for several versions already. You can check the differences between the two in TechNet: http://technet.microsoft.com/en-us/library/sharepoint-online-service-description.aspx#bkmk_FeaturesOnPremise.

As for the others: the Project license is used to allow access to Project Server features, the OfficeWebAppsEdit license is used to allow users to edit documents in Office Web Apps, and the Duet license is used to allow access to Duet features (integration between SharePoint and SAP).

Mapping User Licenses

Mapping users to licenses is, in fact, mapping claims to rights. To create a new mapping you must execute the New-SPUserLicenseMapping cmdlet which can be used in a few different ways, depending on the type of claim you are mapping.

You can map an Active Directory security group to a license, executing the following command:

$mapping = New-SPUserLicenseMapping
–SecurityGroup “Enterprise Users”
–License “Enterprise”

You can also map a Forms-based Role to a license by using the –RoleProvider and –Role parameters instead of the –SecurityGroup parameter:

$mapping = New-SPUserLicenseMapping
–RoleProvider “MyRoleProvider”
–Role “Enterprise Users”
–License “Enterprise”

Finally, you can map a claim to a license by using the –ClaimType, –OriginalProvider and –Value parameters, or just the –Claim parameter with a reference to a SPClaim object.

Figure 4 – Using the New-SPUserLicenseMapping cmdlet

When creating the mapping you can also specify which Web Application the mapping applies to, allowing you to configure user licenses on a per-web application basis. If you don’t specify a web application, the mapping will be applied to the whole farm.

After creating the mapping, you must call the Add-SPUserLicenseMapping to add it to the farm:

Add-SPUserLicenseMapping –Mapping $mapping

Checking User License Mappings

To check which mappings are configured in the farm, you can use the Get-SPUserLicenseMapping cmdlet without any additional parameters. Note that any mappings defined on a web application level will not be returned when retrieving the farm level mappings.

Figure 5 – Using Get-SPUserLicenseMapping cmdlet

To list the mappings configured for a specific web application, add the –Web Application parameter with the respective URL value.

Removing User License Mappings

To remove a mapping, you can use the Remove-SPUserLicenseMapping cmdlet. The only required parameter is the identity of the mapping (a GUID) which you can easily get by executing the Get-SPUserLicenseMapping cmdlet.

Enforcement Effects

Two common questions regarding User License Enforcement are:

• Where is the user license enforced?
• What happens when a user tries to access a feature that is not available to his license type?

Regarding the first question, the user license enforcement will be used in the following situations:

• When accessing a page with web parts that require a specific license (e.g. Excel Viewer Web Part or InfoPath Form Viewer);
• Accessing the web part gallery to add a new web part to a page;
• Selecting a site template when creating a new site;
• Trying to edit a document in Office Web Apps.

As for what happens in these situations, two things can happen:

• A user without the required license won’t see the components he has no access to (web parts and site templates); or
• SharePoint will deny access to a component the user has no license for, presenting a message explaining why the user cannot access the component.

Additional Notes

There are a few additional notes I believe are important to keep in mind:

• User License Enforcement is available only for On Premise SharePoint 2013 deployments. SharePoint Online uses a per-user licensing model hence it does not require this capability to control access to specific features.
• User License Enforcement works only with Web Applications that use Claims-based Authentication.
• Once enabled, every user has to be assigned a license, even service accounts. If you forget to assign a license to a user, it will be logged as Unlicensed and will be denied access to most SharePoint features.

References

You can find additional information on the PowerShell cmdlets on TechNet: http://technet.microsoft.com/en-us/library/jj219609.aspx.