Archive

Archive for December, 2012

Hostheader managed paths for host-named site collections

December 10, 2012 1 comment

Say you are setting up a hosting environment (a multi-tenant site structure) on SharePoint 2010. You are creating several tenant host-named site collections under a given web application. You will likely require to create a tenant administration site for each tenant site collection you create.

Why is this required? One of the concepts with creating a multi-tenant hosting environment is that you can bind only the specific features and services required by a given tenant. Depending on the requirements of the consumer of each of your tenant site collections, you may apply a different feature pack to each of your tenant site collections. Instead of managing these through the standard interface such as the Central Administration application, you would want to handle these through a site that exposes only what is relevant to the tenant site based on the subscription ID of the tenant.

You can also safely delegate the management of the tenant site to a tenant administrator because the tenant administration site only exposes functions that will configure the tenant related features and services without affecting any of the other sites on the farm. The Tenant Administration site collection is based on a "Tenant Administration" (TenantAdmin#0) site template. Typically, one would like to create a tenant admin site at a managed path location relative to the host named site collection. For instance, if you are creating a tenant host-named site collection at http://mytenantsite.com, it makes sense to create the administration site collection for this tenant at http://mytenantsite.com/admin because it is easy to remember and quick to navigate to.

Now in order to create a site collection at that location, we know that SharePoint 2010 requires that there be a managed path whose relative URL is "admin". Also, since you want to create a site collection at the path specified by admin as opposed to a subpath such as http://mytenantsite.com/admin/tenantadminsite, it is also clear that we need a managed path with "Explicit inclusion". This is different than a managed path with "Wildcard inclusion".

A quick note on the difference for those who do not completely understand this:

Managed Path with wildcard inclusion – you can create any number of site collections, each with its own extension to the path under a managed path with wildcard inclusion. However, you cannot create a site collection at the path specified by the managed path itself. For instance, if you create a managed path called "teams" with wilcard inclusion, you can create several site collections relative to this path such as http://mytenantsite.com/teams/teamASite, http://mytenantsite.com/teams/teamBSite and so on. However, you cannot create a site at http://mytenantsite.com/teams.

Managed Path with explicit inclusion – you can create exactly one site collection at the location indicated by the managed path and no more. For instance, if you create a managed path called "search" with explicit inclusion, you should be able to create one site collection at http://mytenantsite.com/search. You will not be able to create additional site collections extending the URL from "search" unless you added additional managed paths under this level.

So for our admin site scenario above, we require a "Explicit inclusion" managed path defined for the path "admin". But if we added a new managed path for the web application with "explicit inclusion", we have already said that we should only be able to create one site collection at that location. This doesn’t work where we have to create one admin site for each tenant site collection. The conclusion therefore is that you cannot create the managed path for the web application. It will need instead, to be a hostheader managed path – one that can be used by all host-named site collections.

Host header managed paths are different from web application managed paths. In the SharePoint Management Shell, you can list the set of managed paths on a web application through the following Get-SPManagedPath cmdlet usage:

Get-SPManagedPath -WebApplication <webAppUrl>

You can list a separate set of hostheader managed paths by using the following:

Get-SPManagedPath -HostHeader

It is what shows up in the latter list that matters where host-named site collections in a multi-tenant structure are concerned. So how do we create hostheader managed path for the admin sites that we need? We use the New-SPManagedPath cmdlet as shown below:

New-SPManagedPath -RelativeURL "admin" -HostHeader -Explicit

The 3 important things to note here are:

  1. We do not specify a web application
  2. We apply the -HostHeader switch which indicates we want to create a hostheader managed path
  3. We apply the -Explicit switch which indicates this managed path is with "explicit inclusion" meaning we can create a site collection at the path ending with "admin".

And that’s it. Now you should be able to create the tenant administration site under each tenant site at a relative path called “admin”.

%d bloggers like this: