[SP2013] Host named site collections

Technical / July 15, 2014 / Jasper Siegmund / 0

With SharePoint 2013, Microsoft claims we need to rethink our architecture. Host named site collections are the way to go, and preferably all within the same web application. But what are host named site collections and what do we need to take into account when setting this up?

Update. Check out part 2, detailing how to set up host named site collections in combination with AD FS and SSL: http://blog.repsaj.nl/index.php/2014/07/sp2013-host-named-site-collections-adfs-claims-and-aam/

Host header webapps in SharePoint 2010

For the readers not already familiar with host headers, we’ll start with a bit of history. Previous version of SharePoint have been constantly redesigned, as we all know so well. Building towards Office 365 / SharePoint Online, Microsoft had to overcome some challenges serving multiple customers from the same farm.

To be able to share a farm, Microsoft introduced the notion of site subscriptions in SharePoint 2010. This was an evolution of something called “scalable hosting mode” which was in the product since SharePoint 2003. A site subscription is a 1-n relation between a subscription and site collections. Together with subscription aware service applications, this allows us to provide seemingly “separate” environments to multiple tenants within a single farm. “Separate”, since they still share things on a technical level.

SharePoint URL’s

But what about the site collection URL’s? Traditionally, a path-based SharePoint URL pointing to a site collection consists of the following parts (figure 1):

The protocol, usually http or https.
The URL which is bound to the web application.
A managed path.
The site collection relative URL.

This imposes a problem, since Microsoft wanted to give tenants the option to configure their own URL’s, instead of having to use a predetermined one. So for that purpose, they introduced the host header web application. Within the host header web application, we can create site collections which have their own URL bound to them. This is done via PowerShell by specifying the HostHeaderWebApplication parameter for New-SPSite:

New-SPSite “http://portal.contoso.com” -HostHeaderWebApplication “http://HNSC01.contoso.com” -Name “Portal” -Description “Customer portal” -OwnerAlias “contoso\administrator” -language 1033 -Template “STS#0”

Listing 1: Creating a host named site collection in SharePoint 2010

So now we can run multiple sites within the same web application, all having different URL’s. Cool!

What’s in a name?

Microsoft doesn’t have a brilliant track record when it comes to naming things. In my opinion this is another example of how things can become confusing. The important things to know are:

When you want to configure multiple web applications supporting host named site collections, you need to use the –HostHeader parameter to configure the URL of the web application.
Within IIS we also need to configure that same URL, within the web applications’ host name bindings. You see where this is kind of odd?
And when you’re then going to configure managed paths, it’s back to host headers again. Hmm…

But fine; whether is host header or host name, the goal is to provide site collections with their own URL’s, instead of using the web applications’ URL.

Setting it up

There is a pretty elaborate article on how to set up host named site collections on TechNet[i], so I’ll won’t go into details in this article. The basic steps are:

Creating a web application like you normally would do. This will have its own URL and a root site collection has to be created for that URL (that has to do with processes like search which will hit this URL, so it needs to exist). Note: should you want to use more than one web application supporting host named site collections, you need to use the –HostHeader parameter for the New-SPWebApplication cmdlet, specifying the URL. Each webapplication will need its own IP address.
Make sure the web application in IIS is the default one, which serves like a “catch all” for unknown incoming URL’s.
Create site collections using the New-SPSite PowerShell commandlet, passing in the –HostHeaderWebApplication parameter.

Managed paths

Alongside the above mentioned per-site collection URL’s, we can also create host named site collections with a managed path. This too can only be done via PowerShell, with the New-SPManagedPath cmdlet specifying the –HostHeader parameter.

Suppose you want to create portal.consoto.com/departments/marketing, you would configure:

A managed path for /departments (wildcard).
A host header site collection at http://portal.contoso.com, this needs to exist before we can create a site collection which uses the managed path.
A host header site collection at http://portal.contoso.com/departments/marketing.

Microsofts’ advise

As said in the introduction, Microsofts official advice is now to use host named site collection by default. Also, they advise us to place those site collections in one single web application. The reason behind this is quite simple: they use the same approach themselves in Office 365. That automatically means it’s the best tested option by default, and Microsoft will invest more time into making it work brilliantly opposed to the traditional method of creating site collections (which is not used within Office 365).

A second advantage is that a host named site collection is very portable. Since the URL is now bound to the site collection, you can move the entire thing without changing the URL of the content. So users can view their pages, lists and documents regardless of the web application or farm the site collection is in. That also implies you can move sites towards the cloud and back without users even noticing the difference. That is, of course, based on the assumption you’ve got things like authentication set up properly. And moving stuff to the cloud is what Microsoft likes.

But is it all truly amazing, or are there considerations to be made?

Migration

To start with; there’s migration. Companies coming from SharePoint 2010 will probably not have an architecture with host named site collections. So moving towards this architecture means you’ll have to rethink your URL’s and some of them will most likely change, breaking content links.

Also, your IT decision makers might wonder: what’s the real benefit here? Apart from the testing and commitment already mentioned, your sites are just as fine without their own host name. Sure, some of the new bits in 2013 will not work without hacking, like the request management service. But for most companies, the functionality they use on a day-to-day basis will be just fine. So one might wonder: why go through all the trouble?

One webapp, bye bye governance?

There’s also the matter of governance. A web application comes with settings. For instance; there’s a link between a web application and the service application proxy group it’s using. So when your requirements are dictating different sites need different service application instances; one web application isn’t feasible. You can easily check out the settings per web application in Central Administration to make a list of governance issues when it comes to using a single web application.

Also, your company might have processes in place which automate the site creation workload. When there is a self-service system facilitating the creation of site collections, take into account that this will need to be changed as well.

SSL

Another issue arises when you want to make use of SSL certificates. It is possible to use SSL, but that requires we make use of wildcard certificates (*.contoso.com). Host named site collections would have to be named site1.contoso.com, site2.contoso.com, etc. to pass the browser validation. Think of your sites in SharePoint online, which are hosted on https://tenant.sharepoint.com, where *.sharepoint.com will be the wildcard SSL certificate used.

When you want to use more than one certificate for different second level domain names, creating multiple web application is the only option you’ve got.

Alternate Access Mappings

Using alternate access mappings on web application level becomes pointless when you’re using host named site collections. Since each site collection is bound to a URL, the AAM configured on the web application level don’t really matter any more. Instead, the Set-SPSiteUrl Powershell cmdlet can be used to add more than one URL to the same site collection. This requires good planning and I would advise only using it when you’ve got a real good reason to.

Conclusion: it depends

As so often with SharePoint, it’s a matter of: it depends. It depends whether you want to spend the time setting this up. Whether you want to use the 2013 bits which require this architecture. Whether you need the governance of settings which you cannot get with this architecture. Whether you care about Microsoft testing this and telling us “it’s the future”. Etcetera.

There’s a lot of speculation about the future of SharePoint. And although Microsoft is pushing the cloud, many believe that on-premises will be getting its share of loving at the upcoming SPC in 2014. So maybe the traditional web application model won’t be so deprecated after all, who knows? But for newly built SharePoint 2013 installations, it might be worthwhile at least considering the option of host named site collections.

[SP2013] Host named site collections