Introduction
I’ve been reading and seeing a lot of blog posts, articles, videos etc over the last few months discussion Host Named site collections vs Path Based site collections in SharePoint 2013, and 2010 for that matter. What I find interesting is that a lot of those articles are either misinterpreting the official guidance and documentation on TechNet or are just plain wrong. In this post I will try to clear up some of the confusion, and hopefully I’m not that wrong in this post. And yes, I can agree that Microsoft could have been more clear on this topic, but what’s there is actually pretty decent.
What are Path Based site collections?
Let’s start with Path Based site collections (PBSC) which has been the traditional method of creating and locating site collections. It’s based on the fact that you have a Web Application (IIS Web Site) in SharePoint listening to a specific host header, (1) in the picture below. Then each site collection is located relative to this host header. A site collection can only exist under (wildcard) or in (explicit) a managed path, (2) in the picture below. The URL to the site collection is the combination of the protocol, host header, the managed path and the name of the site collection. In order to have different host names, multiple Web Applications must be created, as in the example below where the Personal Sites are located on a different host name. When using Path Based site collections you configure the managed paths on a web application level,
The illustration above shows us how we need two Web Applications to host two different host names; one for intranet.contoso.com and one for my.contoso.com, and that we use different managed paths in the two different Web Applications.
Path Based site collections has been the de facto, and also recommended approach, and therefore it’s the most well-known method. All configuration can be done using SharePoint Central Administration and most admins are familiar with managing Path Based site collections.
What are Host Named site collections?
Now, let’s take a look at Host Named site collections (HNSC). Host Named site collections have now been the “recommended” approach, very much to the fact that SharePoint Online/Office 365 uses it and it is now the most tested (by Microsoft) method. Note that this alone does not validate that HNSC should be the default method for all new deployments.
The largest difference compared to Path Based site collections is that all site collections now have its own URL and that the web application should not listen to a host header (3), but all incoming requriest. Even though the site collections themselves have their own URL, site collections can only be created under/in a managed path. The managed paths used by HNSC are not the managed paths configured at the web application but instead they are configured on the Farm level (4).
One of the “myths” around Host Named Site Collections is that you cannot use managed paths, which is completely wrong. As you can see by the illustration this web application uses multiple host names and multiple farm level managed paths. You can see that we have intranet.contoso.com and my.contoso.com in the same web application. We could also add new site collections for search.contoso.com or teams.contoso.com, just as long as the DNS (and certificate) is configured correctly for the IIS.
One of the caveats with HNSC is that you cannot configure anything of this using Central Administration. You need to use PowerShell to create the web application, managed paths and each and every site collection.
Note: also note that the web application above have a root site collection without a site template. This is currently a support requirement. For instance see this support article KB2590564.
Do I need to choose one of HNSC or PBSC methods?
This is one of the largest misconceptions in this discussion. No, you do not have to choose either HNSC or PBSC. As usual with SharePoint – it depends! It depends on your requirements. For instance if you want process isolation of site collections, then you can use HNSC for the most of your site collections and then use PBSC for those who need to be in separate application pools – all you need to do is configure your DNS and the correct host headers on your PBSC. Requirements of alternate access mappings might also be a reason to think of PBSC.
So, which method should I use then?
My recommendation is that you always start your design with Host Named site collections. It gives you way more flexibility in the way you give host names to your site collections. You will also reduce the memory footprint of SharePoint on the web servers. Of course as always if you get bad code in your SharePoint farm which takes the application pool down – all of your sites will go down. Depending on your scalability requirements you might need to evaluate the needs of HNS and/or PBSC.
The TechNet article referenced below contains even more details on some subtle and significant differences between HNSC and PBSC – make sure to read and understand those before starting your design. Well, you can always export and import site collections between the two methods if you need to change the structure at a later stage – but the end users will most likely not be fond of that.
References
Here are some important and authorative articles and posts on the topic that you should read:
Kirk Evans, Microsoft: What Every SharePoint Admin Needs to Know About Host Named Site Collections
TechNet: Host-named site collection architecture and deployment (SharePoint 2013)
Summary
I hope that this post cleared up the confusion between Host Named site collections and Path Based site collections. Which method to choose is always up to you and your requirements. I did not go into all the nitty gritty configuration details in this post, and leave that for now or to the TechNet article…