I don’t know about you, but I’m a creature of habit--from ice cream (Ben and Jerry’s “Vermonty Python”, of course), to shoes, to SharePoint. I have worked with SharePoint since it was a feisty little product called SharePoint Team Services 2001. From that first moment, I’ve been using path-based site collections, and you probably have too. They served us well, and, because of inertia, we stick with them.
But in this article, I’m going to sing the praises of host-named site collections. And while I don’t think they’ll completely replace our old friends the path-based site collections, there’s a place in our hearts for host-named site collections, too.
What is a Host-Named Site Collection and Why Should I Care?
With path-based site collections, the differentiation between site collections is their path. One site collection might be http://portal.contoso.com/sites/freediettips and another might be http://portal.contoso.com/teams/tiddlywinks. Each of those site collections have the same host, portal.contoso.com, but the path is different. With the first, it’s /sites/freediettips, and with the second it’s /teams/tiddlywinks.
This approach works, but it has a couple of limitations. It can result in some hysterically long URLs, which trips up some browsers, and there is actually a hard limit on how long URLs can be in SharePoint.
The other annoyance with path-based site collections is users. (It’s always the users!)
As a SharePoint administrator I think we’ve all had users push back when we deliver their shiny new SharePoint site and the URL is http://portal.contoso.com/sites/accounting.
They really had their hearts set on http://accountantsrock.contoso.com, and since they approve (most of the time) our expense reports, we should try to keep them happy.
In the Dark Ages of SharePoint, that meant spinning up a new web app for http://accountantsrock.contoso.com. This has quite a few drawbacks. There is significant overhead, both in management and in resources.
Plus, once HR finds out about it, they aren’t going to be satisfied with http://portal.contoso.com/teams/humanresources anymore. They’re going to request, nay, demand, http://hriscooltoo.contoso.com. And since they approve our promotions, we want to keep them happy too.
Thus more resources are required, and this mess soon spirals out of control.
On top of the increased resource demands, SharePoint has a web app limit of 10 web apps per farm, and they get gobbled up pretty quickly. Older versions had a way to host site collections with different hostnames in the same web app, but those solutions were not fully baked and not a good option for real, production work.
Why Would I Want to Use Host-Named Site Collections?
Enter SharePoint 2013’s host-named site collections--or HNSCs to their friends--the newest, hottest thing in keeping your users happy. Like their similarly named counterparts in earlier versions of SharePoint, host-named site collections allow you to have site collections with different hostnames in the same web app, all the while being able to keep your sanity.
For example, you could have http://accountantsrock.contoso.com/, http://hriscooltoo.contoso.com, and even http://custodiansarepeopletoo.contoso.com all in the same web app. This keeps you from running afoul of SharePoint’s web app limitations and allows you to keep your management duties at a minimum.
The best part of HNSCs? There’s nothing extra you need to do to use them. You don’t need to install SharePoint any special way, you don’t need all the overhead of multi-tenancy, and you can mix and match path-based and HNSCs to your heart’s content.
There are really only two steps. When you create the HNSC, you need to tell SharePoint which web app to put it in. You do that with the –HostHeaderWebApplication parameter. It looks like this:
New-SPSite http://noonelikesit.contoso.com –OwnerAlias “contoso\herbert” –HostHeaderWebApplication http://portal.contoso.com –Name “IT Love In” -Template “STS#0”
This assumes that the web app http://portal.contoso.com already exists. There is no way to create HNSCs in Central Admin, so you get to flex your Windows PowerShell muscles when you create them.
After the HNSC is created, you need to create a DNS record for it, pointing at the same place you point the DNS entries for your SharePoint farm. That might be a specific web server, or maybe a network device of some sort.
I would recommend a DNS A Record over a CName. SharePoint doesn’t like CNames, and they can cause some problems. If you think you’ll be creating a lot of HNSCs, consider creating a wildcard DNS entry. If you create a DNS A record for *.contoso.com, any DNS requests for a record that isn’t already defined will resolve to the wildcard. Your existing DNS entries will continue to work, and any newly created ones will too.
Speaking of wildcards, if you’re using SSL in your environment that will require some fancy footwork, too. You can use a wildcard cert, which will work for any URL that matches *.contoso.com. That will cover portal.contoso.com and any other URLs your business units can dream up.
If you can’t get a wildcard cert for whatever reason, you can create a new cert for each HNSC and assign it to the IIS site that is hosting your host header web application. With the magic of Server Name Indication (SNI) IIS can now have multiple certs on a single IIS site. Most recent browsers support SNI, so they will include the host name unencrypted in SSL packets, that way IIS will know which SSL cert to use to decrypt the request.
I know, it sounds like a lot of work, but after you do it once or twice, there’s nothing to it. If you go the SNI route, make sure to test it. Some non-browser things, like WebDAV, get along worse with SNI than most men do with their mother-in-laws.
Flexibility with Scaling and URLs
Once you get your head wrapped around HNSCs, they give you a lot of flexibility in your SharePoint farm to scale and provide fancy URLs to any of your business units. I’d make your coworkers bribe you with baked goods or candy before you do it, though.
