Although these guys have been around since WSS 3.0, host-named site collections haven’t received a great deal of attention up until the last year or so. Having previously worked at a small SharePoint hosting company, I’ve always found this slightly surprising; we preferred to use host-named sites over their path-based counterparts due to the huge scalability they offered us when creating “vanity” URLs for customers. In WSS 3.0 (the “Foundation” version of SharePoint Server 2007, for the 2010 and 2013 folks out there), we could create up to 150,000 site collections per Web application, vs. a documented limit of  In reality, SharePoint 2007 farms would often start to creak at the seams way before that 99 Web Application limit was reached, and this was reflected in subsequent product versions (Microsoft recommend no more than in SharePoint Server 2013). This underlines the point that site collections are the unit of scale in SharePoint, and host-named site collections mean that vanity URL requirements alone may not provide sufficient justification for multiple Web Applications.

Fast forward to today and host-named sites have hit the big time, and they are a key component of Office 365. Microsoft aren’t shy about admitting this – in fact, host-named sites are now the preferred deployment method in SharePoint 2013. However, as with most capabilities in the SharePoint world, the decision to use host-named sites isn’t the no-brainer that TechNet might want you to believe. It’s a good thing, then, that there are a bunch of great posts out there already for you to digest if you want broader coverage than this post offers (here we are mainly addressing MySites):

• , by Steve Peschka
• , by Kirk Evans
• , by Wictor Wilén

So why have I bothered writing yet ANOTHER article regarding host-named site collections, I hear you quite rightly ask? In truth, all the information contained herein is out there already, but I had a couple of very specific, “nuts and bolts” type questions that I have been asked by some of our clients and colleagues who have tried, with varying degrees of success to implement host-named site collections. I figured it would be worth stepping through the answers to these questions by scenario, the first being usage of MySites within Microsoft’s . In this architecture, one of the most significant departures from traditional SharePoint deployments is that Microsoft recommend a single Web Application for the entire farm where possible, excluding SharePoint Central Administration. This post isn’t intended to answer the wider question as to whether a single Web App is a good idea – it simply covers a couple of implementation details that may help you out if you plan to pursue this option.

Can MySites be host-named?

I’ll cut to the chase – the short answer is yes, but possibly not in the way you might expect (we will dig into that below). This is despite the fact that according to Microsoft, the OOB . My best guess at an explanation is that one of three MySite instantiation timer jobs actually carries out the work of creating a user’s MySite, as opposed to the synchronous process that runs when you create a “regular” self-service site. As far as I can tell, however, Self Service Site Creation does need to be enabled for MySite instantiation to work.

MySite instantiation jobs in SharePoint Server 2013

Why would I want a host-named MySite anyway?

To answer this question, we need to take a step back for a moment and review Microsoft’s of a host-named site. As far as I can tell, there are (unofficially, my own terminology), two types:

• A “traditional” host-named site collection that looks and smells like a Web Application Public URL, or IIS host header binding (but is NOT the same thing). Example: https://bathawes-my.sharepoint.com. I’m going to call this a “root” host-named site in this post.
• A “host-named site collection created at a managed path”. Unfortunately, these look very much like the path-based site collections that we know and love, but there is a difference: they should be created under a managed path created specifically for host-named sites. Example: https://bathawes-my.sharepoint.com/personal/ben_bathawes_com. I’m going to call these “child” host-named sites in this post.

While I’m at it, I’m also going to start abbreviating “host-named site collection” to HNSC every so often for brevity. About time, right?

Back to the question at hand: it probably makes no sense to use a “root” HNSC for individual user MySites per DNS requirements, but a “child” HNSC does the job nicely, and appears to align with Microsoft’s recommended architecture for host-named sites. Microsoft provide a simple PowerShell script to help you work this out for yourself – below is an example from one of my dev VMs. Using the “unofficial” terminology I have defined above, note that:

1. https://sharepointhosting.bathawes.com is the only path-based site collection in the farm, created at the root of the Web Application. This site collection is required for search crawls to function correctly.
2. https://my.bathawes.com is a “root” HNSC.
3. /personal is a Managed Path created for host-named sites (we know this because the -HostHeader parameter was specified when using New-SPManagedPath).
4. https://my.bathawes.com/personal/administrator and https://my.bathawes.com/personal/sp2013_install are “child” host-named sites.

Illustration of “root” and “child” host-named sites.

The section below provides the script I used to configure this environment so you can test this yourself.

Create a Web Application for host-named MySites with PowerShell

I used various sources to put together the script below, but the two articles I should call out are Spencer Harbar’s article on and Steve Peschka’s article on  I’ve made a few tweaks here and there to take into account Microsoft’s strong recommendation to use SSL for SharePoint 2013 Web Applications, and automate creation of the MySite host. There are a few assumptions that you should be aware of before running the script:

1. I assume that a User Profile Service Application has been created, and that the MySite host has been set to the correct URL.
2. I assume that you want to use SSL per Microsoft guidance, and have a valid certificate.
3. I’m not fond of using a server’s machine name as the URL of a Web Application, primarily because there will be more than one server in almost all SharePoint deployments. I’m not 100% sure that changing the URL to something more friendly (by passing the -Url parameter to New-SPWebApplication), is supported in this architecture for host-named sites, but I haven’t had any problems so far in my development environment, so assume for now that it is.

<# Sets up a SharePoint 2013 Web Application for hosting host-named site collections per http://technet.microsoft.com/en-us/library/cc424952.aspx
#>

<# App Pool details
#>
$appPoolName = "SharePointHosting"
$appPoolUserName = "bathawes\SPHosting"
$ownerAlias = "bathawes\sp2013_install"
$ownerEmail = "[email protected]"

<# Web App details
        Note that the Web App URL is HTTPS per SSL guidelines from Microsoft
#>
$hostingMainURL = "https://sharepointhosting.bathawes.com"
$webAppName = "SharePoint Hosting"
$contentDBName = "SharePoint_Content_Hosting"

<# Host-named site collections
        Ensure that the MySite Host URL is configured correctly within the User Profile Service, under the "Setup My Sites" link in SPCA
#>
$mysitehost = "https://my.bathawes.com"

$managedAccount = Get-SPManagedAccount $appPoolUserName

<# Create a new Web App using Windows Claims (Windows (NTLM))
      The -Url parameter specifies the Default Public URL. Otherwise, the machine name must be used when creating the root (path based) site collection
      The -SecureSocketsLayer is only required if using SSL
      Also changed -Port to 443
      When the Web App is created, ensure that an appropriate certificate is bound in IIS
#>
$authenticationProvider = New-SPAuthenticationProvider

write-host "Creating Web Application for host-named site collections at $hostingMainURL..."
$webApp = New-SPWebApplication -ApplicationPool $appPoolName -ApplicationPoolAccount $managedAccount -Name $webAppName -Port 443 -AuthenticationProvider $authenticationProvider -DatabaseName $contentDBName -Url $hostingMainURL -SecureSocketsLayer

<# Sometimes, the New-SPSite cmdlet reports that a path-based site already exists if it is run immediately after creating the Web App, so sleep for a minute
#>
write-host "Web App created" -foreground "green"
write-host "Sleeping for a minute before creating the root path-based site collection..."
Start-Sleep -s 60

<# Create path-based Site Collection at the Web App root. This won't be accessed by users but is required for support.
#>
New-SPSite -Url $hostingMainURL -owneralias $ownerAlias -ownerEmail $ownerEmail

# Enable self-service site creation for MySites
$webapp = Get-SPWebApplication $hostingMainURL
$webapp.SelfServiceSiteCreationEnabled = $true
$webApp.Update()
write-host "Self-service site creation enabled successfully..." -foreground "green"

<# Removing the existing /sites path-based managed path per http://blogs.technet.com/b/speschka/archive/2013/06/26/logical-architecture-guidance-for-sharepoint-2013-part-1.aspx
#>
$sitesManagedPath = Get-SPManagedPath sites -WebApplication $hostingMainURL
if ($sitesManagedPath -ne $null) {Remove-SPManagedPath sites -WebApplication $hostingMainURL -confirm:$false}
write-host "Removed /Sites path-based managed path..." -foreground "green"

<# Create MySite Managed Path (a managed path for use with HNSC, so ONE per farm)
#>
$personal = Get-SPManagedPath personal -hostheader 
if ($personal -eq $null) {New-SPManagedPath personal -HostHeader}
write-host "Created /Personal managed path for MySites..." -foreground "green"

<# Create the MySite Host
#>
New-SPSite -Url $mysitehost -owneralias $ownerAlias -ownerEmail $ownerEmail -HostHeaderWebApplication $hostingMainURL -Template SPSMSITEHOST#0
write-host "Created MySite host at $mysitehost..." -foreground "green"

$webApp = Get-SPWebapplication $hostingMainURL

<# Confirm that the correct sites have been created
        From http://technet.microsoft.com/en-us/library/cc424952.aspx#section3a
#>
write-host "Confirming the site collections that we created within $hostingMainURL :"
$webApp = Get-SPWebapplication $hostingMainURL

foreach($spSite in $webApp.Sites)
{
if ($spSite.HostHeaderIsSiteName) 
{ Write-Host $spSite.Url 'is host-named' -foreground "green"}
else
{ Write-Host $spSite.Url 'is path based' -foreground "red"}
}

write-host "Done!" -foreground "green"

Below are a couple of screenshots of my farm after running the above script. Usage of a non-standard port for SPCA (2013 in this case) is irrelevant to this discussion and – it’s just how this dev VM is configured:

As SPCA only appears to be aware of path-based Managed Paths, the /Personal Managed Path for host-named sites doesn’t appear. Also note that the script above removes the default /Sites path-based Managed Path, as it is not required for HNSC:

 

07/01/2014 update: if no path-based Managed Paths are defined for a Web Application, you will see the error below when attempting to create a site collection from within SPCA. This is due to the fact that SPCA can only create path-based sites.

Below, I have enumerated the host-named and path-based Managed Paths in the same farm and Web Application using PowerShell. This time, /Sites and /Personal do appear, as they are Managed Paths created using the -HostHeader parameter:

This sounds awesome! Why would I use any other approach?

Although consolidating to a single Web Application has potential performance, administration and future support benefits, there are a few significant trade-offs. For a start, we will probably need to turn to  or PowerShell to ensure that site collections get created in the “correct” SharePoint Content Database. We also need to be comfortable with the idea that all Web Application scoped options apply to all site collections in the entire farm. This includes security policies, web.config changes (such as those required to configure BLOB Caching), and Service Application connections amongst others. We also lose a couple of options when moving to a host-named site model, the most well-known being  (except, apparently for MySites!). As I say, this post isn’t really about prescribing a model, but I wanted to flag those considerations so they are out in the open.

Ben