次の方法で共有

Mixing SharePoint Standard CALs and Enterprise CALs on the same farm

  • [アーティクル]

I decided that for my first MSDN blog post I would start with a controversial topic:

Can an organization deploy a single SharePoint farm with a mixed blend of Enterprise and Standard CALs (client access licenses) for their users? What if only a small subset of users actually needs Enterprise features? How do I control and report on which sites are using Enterprise features?

 

This problem is compounded because organizations are looking to consolidate their infrastructure into a single managed platform. Microsoft have embraced this by combining what used to be several products including SharePoint Server, Performance Point, InfoPath Forms Server and EPM (amongst others) into a single product with many capabilities, namely SharePoint Server 2010. So previously a company such as LitwareInc may have been using EPM for a small project management office, Performance Point for a group of users in the Finance department, and SharePoint 2007 standard for the rest of the organisation (80% of the other users). If LitwareInc upgraded to SharePoint 2010 they'd love the fact that they could consolidate their infrastructure, reduce the management overhead and save money. But if you tell organizations such as LitwareInc that if they want to consolidate their environments they have to purchase SharePoint Enterprise CALs for all their users many of these companies will think twice because they may not be able to justify the licensing cost of doing so. So the question remains can you mix Enterprise and Standard CALs on the same farm?

 

The general implied answer to that from a Microsoft perspective is "No". In fact if you do a search on the internet you will quickly come across a number of references to the Microsoft SharePoint FAQs that specifically state something along those lines:

https://office.microsoft.com/en-us/sharepointserver/HA101655351033.aspx

"What if some users need enterprise features and others do not?"

"Once the enterprise features of Office SharePoint Server 2007 are enabled, every client accessing enterprise functionality on that server, or servers in a farm, is required to have an Enterprise CAL in addition to their standard client access."

Of course that is still subject to interpretation, what if the users were not accessing enterprise functionality and were simply using standard functionality? It also won't take you long to realise that you will no longer be able to find this FAQ on the Microsoft website. So does that mean you can do it or not? I like Mike Walsh's answer to this:

Microsoft sometimes allow a (presumably large) company to have a certain number of Standard+Enterprise CALs and a certain number of Standard only CALs provided the customer can prove that it is impossible (i.e. they have made technical measures to block this) for the set of Standard CAL customers to access *any* Enterprise functionality.

There also appears to be some variations with regards to the interpretation of the licensing requirements depending on the country / region your company resides in. However my intent for writing this blog was not to clarify what is or isn't allowed from a licensing perspective.

I'd like to shift the focus of this blog to making an assumption that your organization has already had a discussion with your Microsoft licensing representative, and that they have told you that it is possible to have a mix of some users with Standard CALs and some users with Standard + Enterprise CALs. Now the onus is on your organization to prove that your "standard" users are not accessing "enterprise" features.

So let's take a look at what happens when you enter a SharePoint Enterprise key for your SharePoint farm. After you've entered the Enterprise license key you can enable the Enterprise Feature Set in Central Administration > Upgrade and Migration > Enable Enterprise Features

 

Once you've done this you get access to all the SharePoint Enterprise features. I am not going to list all those features here - you can go check out the official Microsoft SharePoint Editions comparison website for that info.

If you want to enable Enterprise features for all existing sites you can go to Central Administration > Upgrade and Migration > Enable Features on Existing Sites

 

The biggest two challenges for organizations that have a mixed blend of Standard CAL and Standard + Enterprise CAL users is to control and identify where Enterprise features are used in SharePoint 2010. Let's look at each of these requirements.

Controlling where Enterprise features are used

One of the first things you might notice after you've enabled Enterprise features is that there's no going back. You cannot convert the farm license type back to a standard license farm and you cannot change the Feature Set in the Central Admin site to back to Standard features. You'll also notice that after enabling the Enterprise Feature Set any new site collection or sub site you create will automatically have the Enterprise features enabled by default. So let's looks at some options to govern the use of Enterprise features:

  1. Many Enterprise feature capabilities are delivered through Service Applications in SharePoint 2010, such as Excel Services, Performance Point, Project etc. The ability to use these Service Applications can be restricted to specific web applications. This means you could enable it for the https://intranet web application and disable it for https://team web application. Even better you could ensure the Enterprise Service Applications are not associated with either of those web applications in the Web Application Management page in Central Admin. You can then create another web application specifically where the Enterprise features will be used e.g. https://bi or https://project. You can further restrict / block users from accessing the new web application using a Deny All policy for users in a particular AD group (called say MyDomain/SharePointStandardUsers).

  2. So restricting Enterprise Service Applications to specific web applications would immediately give you a high level of governance, however it doesn't change the fact that new site collections and sub sites will have Enterprise features enabled by default wherever they are created in the farm. So even though users may not be able to do as much if the Enterprise Service Applications aren't available to the web application, the Enterprise features would still enabled by default and policing that can be a pain. There is also not much guidance currently out there on how to prevent the Enterprise features being enabled by default, so I investigated what process causes them to get enabled in the first place. This led me to identifying a farm stapling feature that enables the Enterprise features whenever a new site or site collection is created. So the seemingly simple solution is to disable this farm stapling feature, which you can do using PowerShell:

    001

    Disable-SPFeature -Identity PremiumSiteStapling -Confirm:$False

    After doing this, I created a new site and voilà both the Site Collection and Site Enterprise features for the new site were no longer enabled. My next thought though was what would happen if I created a site based on a template that requires Enterprise features to be enabled such as a Business Intelligence Site? Would it break? So I tested created one of those too and hey presto the Enterprise features were enabled for that site automatically. So far so good. (Now I'm waiting for all the comments that tell me what does break...)

  3. Unfortunately I did find one caveat for disabling Enterprise features and there are probably others. Even when the Enterprise features are not enabled for a site or site collection, the InfoPath enterprise feature is (which also has an Enterprise CAL requirement) and there is no way to disable this though the UI. I have yet to find a supported way to prevent the InfoPath site features from being enabled automatically whenever a site collection gets created. General site users will likely never use the InfoPath customize form feature unless they have the InfoPath 2010 client installed on their workstation and they specifically choose to customize List forms, although they could unknowingly access an InfoPath form customized by someone else. It is however possible though to use PowerShell to disable the InfoPath site collection (IPFSSiteFeatures) and site (IPFSWebFeatures) features for a specific site collection or site:

    001

    Disable-SPFeature IPFSSiteFeatures –Url https://yourserver/yoursite

    001

    Disable-SPFeature IPFSWebFeatures –Url https://yourserver/yoursite

    I am sure there are some other IT Pros out there who have some suggestions on how to address this from a compliance perspective, but if we go back to what Mike Walsh was saying, it really is about intent. Has the company done everything reasonably possible to block Enterprise functionality? If one had to be pedantic, you could write a PowerShell script that runs through all sites in a web application and disables all other Enterprise features such as the InfoPath features. Then you'd need to schedule this to run occassionally to ensure the features were disabled for any new sites.

 

Identifying where Enterprise features are used

Ok, so now you've enabled the Enterprise Service Applications for the entire web application because one small finance site needed them and all your users are loving it because they get to enable and use all the cool Enterprise features. What now? How do you at least identify and report on where they are being used? With a bit of PowerShell script you can pretty much get out any information you want from the environment. I tried to find a PowerShell script on the internet to give me this information, but couldn't find anything suitable so I decided to write my own. Here is what I came up with:

  1. PowerScript to show all web applications that have Enterprise features enabled:

     foreach ($webapp in Get-SPWebApplication) 
{ 
    foreach ($premiumfeature in Get-SPFeature "PremiumWebApplication" `
        -WebApplication $webapp.Url -ErrorAction SilentlyContinue) 
    { 
        Write-Host $webapp.Url 
    }
}

  2. PowerScript to show all site collections that have Enterprise features enabled:

     foreach ($site in Get-SPSite -Limit All -ErrorAction SilentlyContinue)
{ 
    foreach ($premiumfeature in Get-SPFeature "PremiumSite" `
        -Site $site.Url -ErrorAction SilentlyContinue) 
    {
        Write-Host $site.Url
    }
    $site.Dispose()
}

  3. PowerScript to show all sub sites that have Enterprise features enabled:

     foreach ($site in Get-SPSite -Limit All -ErrorAction SilentlyContinue)
{ 
    foreach ($web in Get-SPWeb -site $site.url -Limit ALL `
        -ErrorAction SilentlyContinue) 
    { 
        foreach ($premiumfeature in Get-SPFeature "PremiumWeb" `
            -Web $web.Url -ErrorAction SilentlyContinue) 
        {
            Write-Host $web.Url, $web.Title
        }
        $web.Dispose()
    }
    $site.Dispose()
}

 

Of course you could tweak the scripts above to identify where the InfoPath site features are enabled or make some modifications to output the results to csv or add some additional information such as the site owner, but you get the drift.

One additional note, these scripts assume the account running them can assess all sites. Any permission errors will be ignored (due to the SilentlyContinue flag).

 

Wrapping it all up

This is definitely not the be-all and end-all blog on dealing with SharePoint Enterprise licensing complexities, but hopefully it will get you thinking on some of the things that can be done with PowerShell to control and to do basic reporting on the usage of some of the Enterprise features in your environment!

Comments

  • Anonymous
    September 26, 2011
    This has been the best write up I've seen on this topic! thank you so much!
  • Anonymous
    November 04, 2011
    we have an enterprise sharepoint 2007 Internet License farm, the business decided to go Standard in 2010, We are not using any enterprise feature in 2007.is there any equivalent STS command in 2007 to remove the enterprise featurelike in 2010 ?Please adviceDisable-SPFeature -Identity PremiumSiteStapling -Confirm:$Falseprobably then migrate the content db to 2010 ?
  • Anonymous
    July 25, 2012
    Yeah, really nice write up.  Only thing I've found that tells you if you're using Enterprise or not.  Good stuff.
  • Anonymous
    October 18, 2012
    This is really great information.My Question is, if I create a new Web Application, and have a site collection with the Enterprise features disabled, would creating a new site/subsite under this have any of the Enterprise features enabled?
  • Anonymous
    November 30, 2012
    Great Informatoin.. If among the apps published in the same Farm ( std and ent CALS) some are just links to other web sites, are the ent cals required?
  • Anonymous
    December 05, 2012
    mpm: Simply having a link to another SharePoint site that has Enterprise features enabled would not require an Enterprise CAL. Only users that access those sites directly would require the Enterprise CAL
  • Anonymous
    December 19, 2012
    This is great information and i have used these scripts with some modifications to loop through everything in the Farm and output the enablement to an HTML web page. I scripted this to run daily and disable across the farm.  Where our frustration comes in is the fact that we have had these enabled from day one and now we need to disable accross the farm and implement a process that adds eCal approved users to an AD group and that AD group has access to a new WebApplication that will have the features enabled.  That part really isn't that tough...what is, is the fact that i'm trying to figure out who is "actually using the enterprise features".   How can you track a site that is actually using any of the entreprise features?  We need to communicat that they will be moved to the new Ent Feature enabled WebApp.  Any ideas or thoughts on taking what you have (which is awesome) and taking it one step deeper to show what is actually being used?  Is this even possible?  My searching hasn't shown anything easy...Initially i thought about looing at IIS logs and collecting the URL's asocciated with envoking an Enterprise Feature and since windows auth we could target communications....but this appears to be extremey variable in all the URL's which i'm guessing could be thousands!  Dilemma!
  • Anonymous
    December 19, 2012
    Hi Greg, yeah I totally agree with all your comments - I've been meaning to post a follow-up on this blog for a while now. Since I wrote this blog a year and half ago I've also done more research and put together some "improved" PowerShell scripts, for example to identify which users actually have accessed sites that have enterprise features enabled (based on the sites' user information lists). I haven't shared this yet because I still think it too many holes in it - e.g. a user may have accessed the site 3 years ago before the site had any Enterprise features enabled. Later the site could have the Enterprise features enabled, but locked down to fewer users, but the site user information list will still contain any user who has ever access this site.So that said, I think you are on the right approach with regards to the IIS logs. "If" I get around to writing another blog, it would probably be on how to use the Microsoft Assessment and Planning (MAP) Toolkit to create SharePoint usage analysis reports. IIS can track SharePoint feature usage, and the MAP Toolkit is designed to track software usage, including SharePoint usage - I believe the toolkit uses the IIS logs. I don't know that the documentation on TechNet for the MAP toolkit goes into great detail on how to report on SharePoint Enterprise/Standard user usage, so I first have do a bit of research on this before I can post a new blog on this topic...
  • Anonymous
    January 11, 2013
    Hi Brian, this work is nice and very useful. I have another question about User Access: what would be the script to identify which users actually have accessed the sites? My customer has already enabled the Enterprise feature allover, so some simple figures would be useful to prepare a Microsoft Audit... :0)Thanks a lot.
  • Anonymous
    April 22, 2013
    Hi Francois,Having the details of who actually accessed it would not satisfy the licence requirement.It is based on who has access and not who has used it.In saying that though, it is not a simple script for 2007 that would generate those results considering PowerShell would not suffice for 2007. 2010 however has some options and I will try and post a link here to 2007 options first as I have recently written some "PowerShell" with some STSADM embedded and it requires some Excel filtering to finally get to the User List.If its 2010 you need then let me know and I will see if I can write it up.I also have some 2007 "PowerShell" that iterates and finds all Site Collections and sites where the feature is activated.Thanks
  • Anonymous
    August 12, 2014
    Is there a powershell script that could go through a farm and identity the number of unique active real users (i.e. users which are not disabled or deleted in Active Directory).?With a tool like this, one could make certain that one had enough Enterprise CAL, but not way too many enterprise CAL.Surely within SharePoint there is some sort of functionality that someone would use if they desired to audit a farm, right?
  • Anonymous
    August 12, 2014
    Another SharePoint CAL question.At our site, besides the normal logins for users, there are auxiliary logins as well. For instance, local admin logins, system account logins, application specific logins, and so forth.Since the user using the alternate account is already covered by a STD+Enterprise CAL, then is there a requirement to have additional CALs to cover things like "spfarm", etc.?