Some thoughts about SharePoint 2013 Host-Named site collections

  • Article

Last week I visited a customer and came across a very common misconception when it comes to host-named web applications. Lots of people think you can only have one web application on port 80 while you can actually have as many as you want as long as you are dealing with host names.

Let’s consider the following scenario:

You might think about having the second one hosted at port 81. In this case, you will never be able to provide the URL you were thinking about as the Host entry in DNS will direct your requests to the default 80 port. The only way to go would be to have both applications at the same port, 80 that is.

Very basic but it also looks like very confusing for some of my customers. My customer’s question was “is there a way to have a web application on port 81 while having the URL for this site being “www.mycustomer.com” ?". So, the answer is NO.

Let’s have a look at how to enable such a scenario:

Create a new web application:

 $DatabaseName = "WSS_Content_publishing"
$Port = 80
$URL = "https://publishing.contoso.com"
$HostHeader = "Publishing"
$AppPoolName = "Publishing"
$AppPoolAcct = "CONTOSO\AppPoolsAcc.svc"


New-SPWebApplication -Name $Name -Port $Port ‘
-URL $URL -HostHeader $HostHeader -ApplicationPool $AppPoolName ‘
-ApplicationPoolAccount $AppPoolAcct -DatabaseName $DatabaseName

Create the second one:

 $DatabaseName = "WSS_Content_bi"
$Port = 80
$URL = "https://bi.contoso.com"
$HostHeader = "BI"
$AppPoolName = "BI"
$AppPoolAcct = "CONTOSO\AppPoolsAcc.svc"


New-SPWebApplication -Name $Name -Port $Port ‘
-URL $URL -HostHeader $HostHeader ‘
-ApplicationPool $AppPoolName -ApplicationPoolAccount $AppPoolAcct -DatabaseName $DatabaseName

 

Noticed they are both on the same port ? The difference is they both have host headers and these ones are different !

Next step would be to add Host entries (A records) in DNS for each of the web applications.

 

That’s it for the web applications.

The good thing is you can do the same at the site collection level.

This capability was already there for SharePoint 2010, however Microsoft now recommend you create host-named site collections and not path based site collections. In SharePoint 2013 some limitations were addressed and the scalability has been improved.

For instance:

  • the new Set-SPSiteUrl has been introduced : it allows you now to add or change an URL mapping for the site.
  • you can now add multiple URLs to host-named site collections. URL will be mapped to one of the 5 zones which are the same as for a web applications. But you can add multiple URLs to one zone. In SharePoint 2010, the capability was limited to one URL that was added to the Default zone.

One additionnal recommendation would be to NOT host your host-named site collections in different web applications. This is feasible but management would be quite complex. So, a best practice would be to host your host-named site collections in one dedicated web application and configure DNS to send  request to a “wildcarded” host entry like “*.contoso.com” to the web application hosting your host-named site collections. In this case of course, this web application must not have any binding to a particular host header.

 

Also,, web applications hosting host-named site collections must have a default site collection at the root BUT this root site collection does not need to be linked to a Template. Actually, this one will not be used. Note htat you will need a DNS entry pointing the IP of the web application hosting the host-named site collections.

In a nutshell, I see two key benefits to it:

  • you can now have zone settings for host-named site collection (hosters and multitenant admins will be happy)
  • you can be a little bit creative and use multiple host names on internet facing websites. As a result, the amount of concurrent downloads will be improved. For instance having “www.contoso.com” and “www2.contoso.com”.