Extended Material from the SharePoint Administration 2013 Inside Out book- Subscription Settings Service Application

The SharePoint Administration 2013 Inside Out book is wrapping up, and I am frantically doing edits before heading out to Sweden for the SEF 2013 event (I'll be ON A BOAT!).

This blog entry is some extended material from that book. I was working on Chapter 6, "Creating and Managing Service Applications" and wrote more material concerning Multi-Tenancy, Subscription Settings service, than the book's style requirements can support.

What this means is I had a section detailing pretty quickly how to create the subscription settings service application, create a subscription ID, create a site collection to use that ID, apply the ID to an existing site collection, create a feature packs, apply them, isolate the users for the tenant in their own OU, etc. Truly, I was supposed to do about a page per service application, and I ended up doing 8 pages for this one alone.

Oops.

So I had to trim the section to better match the intent of the chapter.

But, in case anyone reading the book would like to see this kind of detail, I am posting here. So:

How to create and manage the Subscription Settings Service Application in SharePoint Server and Foundation 2013 (note that in the final section listing the different service applications that can be partitioned, some of those do not apply to Foundation).

Create the Service Application and its proxy

Subscription Settings service obviously has several parts; the Service Application itself, its database (containing all the information concerning the subscription IDs), and its proxy. Interestingly, the service application does not have an association to connect (or not connect) the proxy to individual web applications. Once the service application is started and configured, it applies to the whole farm.

The subscriptions can also use their own Tenant Administration site template for the management of all of the site collections using the same subscription ID. When self-service site creation is enabled, the tenant administrator can create new site collections within the subscription. Feature packs (sets of specific features) are applied per subscription.  So if a tenant has a number of site collections in the subscription, the feature pack will be applied to them all.

Here’s an example of how to create the Subscription Settings Service Application using PowerShell. In this case it will create a new service application pool (in my example the account is already a managed account), create the service application and its proxy. Remember to start the service instance on the Services on Server page in Central Administration.

$apppool= New-SPServiceApplicationPool –Name “SubSettingsAppPool” –Account “contoso\sp_ssacct”

$sapp= New-SPSubscriptionSettingsServiceApplication –Name “Subscription Settings Service” –DatabaseName “SubscriptionDB” –ApplicationPool $apppool

New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $sapp

The Subscription Settings Service will then show up in the Manage Service Applications, but will not have any manageable elements on that page. All management has to be done in PowerShell.

Generate a Subscription ID

Once the Subscription Settings Service Application is created, you can then generate subscription IDs. With an ID, you can create a tenant admin site collection, and, if the web application has self-service site creation enabled, the tenant can create additional site collections all using that subscription ID.

$sub= New-SPSiteSubscription

After you create the subscription ID (notice that I used a variable), you can apply it to new site collections.

Create a New Site Collection to use the Subscription ID

To create a new site collection that uses the subscription ID, you simply need to add the –SiteSubscription parameter and the GUID for the new subscription. Here’s an example, using only the required parameters (for simplicity’s sake) and the variable containing the new ID I created above :

New-SPSite –URL http://sharepoint.contoso.com/client1 –OwnerAlias contoso\clientadmin1 –Template STS#0 –SiteSubscription $sub

Apply the Subscription ID to an Existing Site Collection

If you need to apply the subscription ID to an existing site collection, to make it part of a tenant’s subscription, just use the Set-SPSite command with the –SiteSubscription parameter:

Set-SPSite –identity http://sitecollection.contoso.com –SiteSubscription $sub

Create a Tenant Administration Site Collection for the Subscription

To create a Tenant Administration site you specify the tenant admin template, and the administration site type:

New-SPSite –URL http://sharepoint.contoso.com/client1/admin -OwnerAlias contoso\clientadmin1 -OwnerEmail client1@contoso.com –Template TenantAdmin#0 –SiteSubscription $sub –AdministrationSiteType tenantadministration

The Tenant Administration site, as you can see in Figure 6-3, is a central location to manage the site collections and Service Applications for the Subscription.

 

Figure 6-3 Tenant Administration Site Home Page

It is on the home page of the Tenant Administration site that you configure the settings of the Service Applications that were configured to be partitioned (to support tenants). Each tenant can have their own isolated settings concerning Search, User Profile Service (use the OU unique to the tenant), Managed Metadata, Business Connectivity, and so on. If you have App Management configured for the farm it is automatically tenant aware (of course, since it requires Subscription Settings Service to operate), so tenants can have their own App Catalog and other App Management specific settings.

To manage and create new site collections, click the Manage Site Collections link under SharePoint Sites on the home page. It will take you to a page where you can manage existing site collections in the subscription and, if self-service site creation is enabled for the web application containing the subscription, create new ones (Figure 6-4).  If you select an existing tenant site collection, you can use the Properties button to see the template used by the top level site, number of subsites, owner(s) of the site collection, site administrators, size and quota. The Owners button lets you see and change the site collection administrators for the selected tenant, and the Disk Quota button allows you to see and enter the disk quota settings for the tenant site collection.

Of course the Delete button is used to delete the selected tenant site collection, and the New button is used to create a new one. Remember that if you create host header managed paths, they will show up in the New Site Collection page.

 

Figure 6-4 Tenant Manage Site Collections page where you can manage, create or delete subscription site collections

Getting fancy- creating the host named site collections and their paths

Managed paths are handled in two different ways with PowerShell; Web Application managed paths, and Host Header managed paths. There should never be more than 20 managed paths per web application. But if you have more than 20 tenants, you will easily hit that limit using unique managed paths for each tenant. Host Header managed paths are shared among the host named site collections. This gives each tenant a set of managed paths that are appended to their host named site collection URL.Host Header managed paths are farm wide, so they are available for all web applications.

To create a Host Header managed path of sales, for example:

New-SPManagedPath –RelativeURL “sales” –HostHeader –Explicit

That will create a new explicit, managed path for all host named site collections. Wildcard is the default inclusion, so if you don’t want the path to be explicit, simply omit the parameter, and the path will be a wildcard inclusion.

To check the Host Header managed paths:

Get-SPManagedPath -HostHeader

To create a host named site collection, you have to specify that the web application URL is different than the one to be used by the site collection. It’s that easy.

New-SPSite http://mysitecollection.contoso.com –OwnerAlias contoso\username –Name “My Very Own Site Collection” –Template “STS#0” –HostHeaderWebApplication http://servername

There are a few things to consider when using host named site collections:

·       In order to avoid having to mess with IIS bindings, plan to use the root web application (the one that listens to the server name address, port 80) as the one that will host the tenant host named site collections.

·       Host named site collections have to be accessed through the web application’s default zone. So it uses that zone’s authentication. Plan for that.

·       Host named site collections can support SSL and Kerberos. Years ago there were some issues, and there is a lot of old data out there that is now obsolete.

·       You can mix host named site collections in a web application that contains managed path site collections, with no issues.

For more details about host named site collection considerations, see Kirk Evan’s excellent write up (still valid for SharePoint 2013): http://blogs.msdn.com/b/kaevans/archive/2012/03/27/what-every-sharepoint-admin-needs-to-know-about-host-named-site-collections.aspx

To put together the host named site collection managed path with a new host named site collection:

New-SPSite http://mysitecollection.contoso.com/sales -owneralias contoso\username -Name “MySalesSite” –Template STS#0 –HostHeaderWebApplication http:/servername

Host named site collections add some challenges, but they make up for that by being able to give the tenants a more logical namespace to work with. That is something customers will pay for.

Create a Feature Pack

To control what features a tenant gets to use, you can create feature packs. Feature packs are explicitly applied to subscriptions, and override the default features available for the site collections using that subscription ID. Let me be clear, once you apply a feature pack, that defines all features used, removing those that aren’t in the pack- like the numerous features needed to simply have a site collection. So if you are going to do feature packs, keep that in mind. They are exclusive. Include everything you want the tenant site collections to be able to use, because anything not explicitly included, like Standard Site Collection features for example, will be excluded.

There are two methods to creating feature packs. One is to start empty, and individually add the features you want. But you’d be surprised how many features are required just for a basic site collection template to function. The other method is to get the features of a site you plan to use the most, or just all features scoped to sites or site collections, add those features, then start removing the ones you want to omit from the subscription. Also, if new features are made available on the farm for the tenant, you can add them to the feature pack applied to their subscription. All you need is the GUID or one word feature name for the feature.

The syntax to create a feature pack is:

$fp= New-SPSiteSubscriptionFeaturePack

Notice that I am using variables in these examples. I will be using them as holders for the objects being created so I can use them in later commands.

To add features to a feature pack, you can add them individually or in groups. The syntax for this command is to identify the features by GUID or feature name. It takes a surprising number of features to run a site collection. Conveniently, features are scoped, so you can pull all the features scoped to a single site or existing site collection into a variable and then remove the ones you don’t want the tenant to have. Something to bear in mind is that there can be two of each feature, one that is 14 compatible, and one that is 15 compatible. So many features have two versions. Generally, tenants on a SharePoint 2013 server are going to be using the SharePoint 2013 experience, so they can make use of all of its updated capabilities.

Manage a Feature Pack

When adding features, remember that you will need those scoped for both web (site) and site (site collection). So, to add all the features available for a particular site collection, you need to add both the site and site collection scoped features.

To add features from a particular site collection (they will be scoped to the correct compatibility level already):

 Get-SPFeature –Web http://customer1.contoso.com | Add-SPSiteSubscriptionFeaturePackMember $fp

That will get the site scoped features. To get the site collection scoped features:

Get-SPFeature –Site http://customer1.contoso.com | Add-SPSiteSubscriptionFeaturePackMember $fp

Or, if you don’t have a site collection you’d like to use as the base for your features, you can add all features on the farm scoped to a site at compatibility level 15 to a feature pack:

Get-SPFeature –limit all | Where Scope –eq Web | Where CompatibilityLevel –eq 15 | Add-SPSiteSubscriptionFeaturePackMember $fp

Of course that will only add site level features to the feature pack, so to then add the site collection features, like the commands above, change the word “Web” to the word “Site” and run command again.

These commands (whichever set you choose) will set you up with a functional feature pack that you can apply to a tenant. Keep in mind that the tenant admin site for the subscription will get these features, but will activate only those appropriate for its template.

Adding individual features to a feature pack can be a little tricky because the syntax of the command requires you use the feature ID to identify the individual feature. You can mark and paste it from the Get-SPFeature list (or look under the FEATURES folder in the correct hive for the one word feature name). The syntax of the cmdlet requires you specify the identity of the feature pack you are adding to (in my example I just refer to the variable I use when creating the feature pack), and the feature definition you are adding:

Add-SPSiteSubscriptionFeaturePackMember  –identity $fp –FeatureDefinition

In some situations, tenants may be paying for a particular SharePoint license, and therefore may only be allowed to use features scoped for that license, such as those only for Foundation or Standard. There are lists online of the feature names for those licenses so you can use them to create features packs based on licensing. For example, there is a quick PowerShell script for creating a feature pack of SharePoint Foundation level features at: http://gallery.technet.microsoft.com/office/SharePoint-2013-Foundation-d3d1637f

Note that the feature you add may not be activated automatically. You should check to see if it is. The PowerShell cmdlet to activate a feature is:

Enable-SPFeature –Identity -url http://sitecollection.contoso.com

Or you can just log into the site collections and activate the features from the site settings pages instead.

If you want to add a feature to an existing feature pack, and you don’t have the feature pack’s ID number handy, you can use a site collection that uses that feature pack to specify the site subscription. Basically it gets the feature pack ID for that site collection’s subscription ID:

$featurepack= Get-SPSiteSubscriptionFeaturePack –SiteSubscription  http://tenant.contoso.com

To remove a feature from a feature pack (this capability is important if you are using all the features available and then paring them down):

Remove-SPSiteSubscriptionFeaturePackMember –id -sitesubscription $fp

Applying a feature pack to a subscription uses a new cmdlet, Set-SPSiteSubscriptionConfig. This cmdlet lets you apply a feature pack to a subscription ID.:

Set-SPSiteSubscriptionConfig –Identity $sub –featurepack $fp

That command also has a parameter we will use later to isolate the subscription users to a particular OU in AD.

There is no easy command to remove a feature pack from a subscription, but you can simply apply a new one over the old one or complete delete a feature pack then apply a new one.

To delete a feature pack:

Remove-SPSiteSubscriptionFeaturePack –Identity $fp

Isolate the People Picker for a Subscription to an OU

To isolate a subscription’s people picker to only allow the display and selection of users from a specific OU you need to use the syntax of “OU=OUname,DC=DomainName,DC=DomainSuffix”. For example:

Set-SPSiteSubscriptionConfig –Identity $sub –UserAccountDirectoryPath “OU=customer1,DC=contoso,DC=com”

This capability is actually very cool and new to SharePoint 2013. By limiting the tenant to an OU, you can use User Profile Service (in partition mode, of course) to pull profiles from that OU only. There is an STSADM command that is the equivalent, and does not require that a site collection be part of a subscription (like the preceding PowerShell cmdlet does), which may be even cooler.

The STSADM command to limit the people picker of a site collection to one OU specifies the OU in AD, and the URL of the site collection:

STSADM –o SetSiteUserAccountDirectoryPath –Path “OU=sales,DC=contoso,DC=com” –URL http://sales.contoso.com

To see more of the cool things you can do with STSADM and the peoplepicker, such as specifying an AD directory path to point to more than one OU, see http://technet.microsoft.com/en-us/library/gg602075.aspx

Adventures in Provisioning Service Applications to be consumed by Tenants

In order for most Service Applications to be able to run in partition mode (about to partition off data between tenant site collections), they must be created with the capability to start with. If the correct parameter was not used during the creation of a Service Application, it will not be partitioned. In addition, some Service Application Proxies also need to be created with a partition parameter. Once a Service Application has been created in partition mode, it cannot stop being partitioned.

Generally, a new Service Application and proxy are made specifically for tenants. You can choose to associate the tenant web applications to a custom group (instead of default) and select the tenant service application proxies, or create a new proxy group, add the tenant specific service application proxies as members, then associate the tenant web applications instead.

·       -Managed MetaData Service can be created via PowerShell in partition mode using the –partitionmode parameter. In addition, its proxy must also use the –partitionmode parameter when you create it. For the proxy, content type syndication is enabled by default in partitionmode and default keyword taxonomy also tends to be true unless specifically configured otherwise. It can be configured, per tenant, from their own tenant administration site.

·       User Profile Service can be partitioned. You must use PowerShell to do so (make sure all other required configuration is done beforehand). Configuring the User Profile Service using PowerShell has some known issues, so read up on it first. User Profile Service too requires the –PartionMode parameter. The proxy for the User Profile Service also must be created with a –PartitionMode parameter. This Service Application is configured by the tenant from their own tenant administration site.

·       App Management is already tenant aware by default, and if it is already enabled for the farm, the Tenants will have their own catalog and settings, administrable from their tenant admin site.

·       The Search Service Application supports partitioning for tenants, but its syntax requires the parameter –Partitioned, which is different than the other Service Applications (there always has to be one). Its proxy also requires the –Partitioned parameter when it is created. It is always a good idea create the proxy after you have created all the required Search components. If you have more than one Search Service Application running in the farm, it is not a good idea to have them running on the same server because they are so resource intensive. Search has an extensive number of settings for each tenant from the tenant admin site.

·       Business Connectivity can technically be partitioned, and uses the –PartitionMode parameter. Its proxy is created automatically and added to the default group, so you cannot name or partition it. If you create the proxy manually, it does accept the –partitionmode parameter, but won’t work unless there is an existing published app to associate with.In addition, there is a known issue concerning managing Business Connectivity from the tenant admin site. Hopefully that will be fixed in the future.

·       Technically Secure Store can be partition aware. It uses the –PartitionMode parameter. The problem is the proxy that gets created automatically, is not partition aware and will cause issues unless there is a published application to associate with (sound familiar?).

·       Word Automation and Machine Translation Services support partitioning, and even have the option to partition built into their GUI pages off of the New button in Manage Service Applications. However, they are not managed from the Tenant environment, only from Central Administration or PowerShell.

·       Information Rights Management can be partition aware. There is a setting in Central Administration to configure Information Rights Management (IRM) to be tenant aware. Or you can use PowerShell:

Set-SPIRMSettings -IrmEnabled -UseActiveDirectoryDiscovery –SubscriptionScopeSettingsEnabled

Once enabled, you can only configure IRM in PowerShell, particularly to apply the certificate for IRM to the subscription. For example:

$subirm = Get-SPSiteSubscription "http://customer1.contoso.com"

Set-SPSiteSubscriptionIRMConfig -Identity $subirm -IrmEnabled -CertificateServerUrl http://certsvr.contoso.com

When considering partitioned service applications for tenants, remember that they are applied via associations with the web application that contains them. This is why it is considered best practice (and common sense, which is often what best practice truly is) to keep the tenants in their own web application.

I hope this material was useful for you. Thanks for reading!