Guide to SharePoint 2013 Host Name Site Collections

Intro to Host Name Site Collections (HNSC)

First, I know several resources are out there published and all provide value. I feel like putting my own spin on Host Name Site Collections for SharePoint 2013 and I hope this helps you. Host Name Site Collections are the answer to simplifying and consolidating SharePoint Farm/s.   Let’s assume a SharePoint Farm has 5 web applications each mapped to a unique application pool.   While this gives you a nice separation for security purposes, it adds unnecessary strain on each WFE.   Each time an application pool is spun up, it must load all of the assemblies from memory.   So in this case, each WFE is consuming 5x memory right off the bat.   The costs increase by having to procure beefy machines with lots of memory to support this requirement.   For many of our customers, this led to many multi farm environments due to hitting a cap in physical memory.   Also as you’ve experienced, the sheer # of web applications can lead to long patching cycles with PSConfig.  By consolidating web applications, your essentially cutting operations costs (faster patching times) and reducing infrastructure costs (additional memory required to service multiple application pools).

Host Name Site Collection setup and administration is all performed using Power Shell.   Host Name Site Collections provides the ability to configure a host header at the site collection level.   So it’s possible to have 1 web application servicing different Host Name Site Collections all with completely different URL’s.   So for example, I have 3 host name site collections contained in a single web application.

HNSC 1:  https://intranet.contoso.com
HNSC 2:  https://corp.fabrikam.com
HNSC 3:  https://home.tailspintoys.com

Other benefits when using Host Name Site Collections

a. Can use http or https
b. Supports Off-box termination of SSL

c. Each HNSC supports up to 5 URL’s in a single zone.  However if all zones are in use, one URL per zone.  Yes, these URL’s can be completely unique DNS names.

d. I can map additional URL’s to a specific zone.  (Useful to meet security requirements “User Policy” and use alternate authentication providers)

e. Make use of multiple authentication providers bound to a single web application
f. It's much easier to migrate host name site collections to Office 365

Important Note:  Do not use host header in IIS bindings when using HNSC’s. I’ll dive into this a bit more during the configuration portion.

 

 

Scaling Host Name Site Collections (HNSC)

I wanted to figure out how host name site collections scale in a single farm with a single web application by leveraging Microsoft's published Software boundaries and limits for SharePoint 2013 here.  Let’s assume a content farm called ContentA is hosting a single web application.   Based on That single web application can hosts up to 250,000 site collections.   Up to 500 content databases can be added to this single Web Application.  The content database size by default is 200 GB per content database although we do support up to 4 TB content database assuming you meet the following conditions:

• • Disk sub-system performance of 0.25 IOPs per GB. 2 IOPs per GB is recommended for optimal performance.
  • You must have developed plans for high availability, disaster recovery, future capacity, and performance testing.

In this example, I’ll assume the maximum content database size you can support is 200 GB.

Other Factors

The max size per site collection we recommend is 100 GB due to limitations with backup/restore.
The total # of site collections per content database is 2,500

 

Scenario # 1

Let’s assume in Scenario 1 you’re backend doesn’t meet the requirement of supporting 4 TB.  In this case, the maximum content database size is 200 GB each.

Content Farm (Content A) Supports
1,000 Site Collections
500 Content Databases (2 site collections per content database)
Single Web Application

 

Scenario #2

Let’s assume your back end IOPS are incredible and your able to support 4 TB content databases.  The numbers change a bit.

2,500 Site Collections per content database * 100 GB size per site collection  =  250,000 GB (244 TB) – this exceeds the content DB size of 4 TB.
40 Site Collections * 100 GB each = 4,000 GB (4 TB).  Important: Each Content Database supports a max of 40 site collections per content database.
40 Site Collections * 500 Content Databases = 20,000 Site Collections and it’s well within the supported boundary, see red bold above!

Content Farm (Content A) Supports
20,000 Site Collections
500 Content Databases (40 site collections each)
Single Web Application

 

Note: In both scenarios, the limitation is really based off content database size.

In my opinion, this is probably pushing the envelope for how many HNSC's you can have in a single web application based off of our software boundaries or limits. However, it's within the limits so it's possible. The idea behind this section is to provide some perspective of what kind of scale a single Web Application can offer in SharePoint 2013.

 

 

Host Name Site Collections and Managed Paths

I’m starting to type Host Name Site Collection’s to much so will use HNSC instead. 

This is a very important subject and worthy of its own section.   In the classic approach when one creates a web application and site collection through Central Administrator, the URL is constructed using three key pieces of information.  The AAM + the managed path + unique name of site assuming the managed path is a wild card inclusion.   When you use HNSC’s you take a completely different approach to constructing the URL.  First, alternate access mappings are not used to construct the URL with HNSC’s.  Second, Managed Paths defined in Central Administrator aren’t used with HNSC’s.   That’s right, you must use PowerShell to administer managed paths for HNSC’s.   The managed paths you define for HNSC’s in PowerShell will not appear in Central Administrator via Web Application\Manage Paths in the UI so they are logically separate.  I call these Host Header Managed Paths.  So, a SharePoint 2013 HNSC URL is constructed with the HNSC URL + Host Header Managed Path + unique name (assuming wild card inclusion is set as the Host Header Managed Path).

A couple of rules to take note when you start working with Managed Paths for HNSC’s via PowerShell:

1. Host Header managed paths are available to the entire farm (Yes, if you have two web applications both servicing HNSC’s each will be able to make use of the managed paths)
2. Host Header managed paths support both wild card and explicit inclusions
3. Up to 20 host header managed paths supported per farm
4. Host Header Managed Paths are only managed only through PowerShell

 

 

Basic Host Name Site Collection Setup without custom defined host header managed paths

This scenario is for my company contoso.com.   I want to setup two host name site collections within a single web application.   One for https://intranet.contoso.com and the other for https://benefits.contoso.com. Both of these HNSC’s will use the default zone and the default zone is already configured with both Windows Claims and SAML Claims (ADFS).  Before continuing with these steps, I would ensure you have SharePoint 2013 and SAML Claims environment setup properly. Please check Steve's blog here for the steps. I'm not using any custom host header managed paths in this scenario. Also, please note this is my simple lab so my steps should reflect that. I'm not using a NLB or doing off box SSL termination so you may need to tweak your steps if using either.

1. Create web application using Central Administrator and root site collection used as an entry point to HNSC’s

a. host header value should remain empty
b. I gave it a name of Contoso Sites
c. Set port 443 although you can use 80.  
d. My server name is WFE so the url oob is https://wfe.  
e. Ran the following PowerShell to provision stub site collection:

New-spsite https://wfe –name “Portal” –Description “Portal on root” –OwnerAlias “contoso\administrator” –language 1033 –template “STS#0”

Note: If this fails, you probably need to temporarily disable the SAML Provider by unchecking it via Central Administrator\Manage Web Applications\Select the Web Application and choose Authentication Providers. After you successfully run the command, just add the SAML provider back.

 

2. Next, used Central Administrator and granted my SAML Claims admin identity access as a Site Collection Admin.

3. Setup a  wild card certificate and add it to IIS Site\bindings.

Note:  In my example, I already setup AD Certificate Services.

a. On the WFE, Go to IIS and click the server object and double-click on certificates
b. On the right, click on Create Domain Certificate
c.  Since both host header urls contain contoso.com, it looks like the following:

 

d. Click Next, and click Select and choose the AD Certificate authority and click OK
e. Next, type in a Friendly name for the Cert

 

f. Click Finish and your cert should be present:

 

g. Finally, add the cert to the SSL bindings on the IIS Site

 

 

4. My default zone is using SAML Provider so  when using an external Identity Provider like ADFS, you’ll need to update both SharePoint (RP) and ADFS (Identity Provider).

Since my host name site collection urls are unique,   I’ll repeat the steps below for each HNSC.

a. From SharePoint, add the URN and URL as a provider realm to the existing sptrustedtokenidentityissuer object using PowerShell.  It will look something like this:

$uri = new-object System.Uri(“ https://intranet.contoso.com”)
$ap = get-sptrustedidentitytokenissuer
$ap.ProviderRealms.Add($uri, “urn:intranet:contoso”)
$ap.update()

$uri = new-spobject System.Uri(“ https://benefits.contoso.com”)
$ap.ProviderRealms.Add($uri, “urn:benefits:contoso”)
$ap.update()

 

b. From ADFS, add a new relying party trusts for Intranet HNSC

• • Set the relying party WS-Federation Passive Protocol as https://intranet.contoso.com/_trust/
  • Add the URN to the Relying party trust identifier field:  “urn:intranet:contoso”
  • Setup the appropriate claims rules defined by your organization

c. From ADFS, add a new relying party trusts for Benefits HNSC

• • Set the relying party WS-Federation Passive Protocol as https://benefits.contoso.com/_trust/
  • Add the URN to the Relying party trust identifier field:  “urn:benefits:contoso”
  • Ensure you setup the appropriate claims rules defined by your organization

Should look like:

 

5. Using Power Shell, Create two host header site collection specifying the SAML claim account of the Admin.

$wa = get-spwebapplication “ https://wfe”
$user = “i:05.t|samlprovider|administrator@contoso.local”

New-SPSite https://intranet.contoso.com –HostHeaderWebApplication $wa –Name “Intranet” –Description “ContosoIntranet” –owneralias $user –language 1033 –template “STS#0”

New-SPSite https://benefits.contoso.com –HostHeaderWebApplication $wa –Name “Benefits” –Description “ContosoBenefits” –owneralias $user –language 1033 –template “STS#0”

 

6. Update DNS with the appropriate host records.  In my case, my domain is contoso.local so I added a new forward lookup zone for contoso.com and added a couple of a records for intranet.contoso.com and benefits.contoso.com which point to my WFE box.

 

 

Host Name Site Collection Setup with custom defined host header managed paths

In this scenario, I'm interested in making use of a customer host header managed path called departments. This will be a wild card path and the sites will reflect the various departments that make up the Contoso company. I will leverage this host header managed path to setup two host name site collections within a single web application.   One for https://intranet.contoso.com/departments/engineering and the other for https://intranet.contoso.com/departments/hr. Both of these HNSC’s will use the default zone and the default zone is already configured with both Windows Claims and SAML Claims (ADFS).  Before continuing with these steps, I would ensure you have SharePoint 2013 and SAML Claims environment setup properly. Please check Steve's blog here for the steps. Also, please note this is my simple lab so my steps should reflect that. I'm not using a NLB or doing off box SSL termination so you may need to tweak your steps if using either.

1. Follow steps (1-3) in the Basic Host Name Site Collection Setup to provision a new web application, stub site collection, and configure a wild card certificate.

2. My default zone is using SAML Provider so  when using an external Identity Provider like ADFS, you’ll need to update both SharePoint (RP) and ADFS (Identity Provider).  Since both of my host name site collection urls share a common FQDN,   I’ll simply need to add one provider realm for SharePoint and one relying party trusts in ADFS.

a. From SharePoint, add the URN and URL as a provider realm to the existing sptrustedtokenidentityissuer object using PowerShell.  It will look something like this:

$uri = new-object System.Uri(“ https://intranet.contoso.com”)
$ap = get-sptrustedidentitytokenissuer
$ap.ProviderRealms.Add($uri, “urn:intranet:contoso”)
$ap.update()

 

b. From ADFS, add a new relying party trusts for Intranet HNSC

• • Set the relying party WS-Federation Passive Protocol as https://intranet.contoso.com/_trust/
  • Add the URN to the Relying party trust identifier field:  “urn:intranet:contoso”
  • Setup the appropriate claims rules defined by your organization

Should look like:

 

3. Using Power Shell, setup a host header managed paths called departments which will be used to provision two host name site collections.

New-SPManagedPath -RelativeURL "departments" -hostheader

Validate: Run, get-spmanagedpath -hostheader to view the newly created host header managed path:

 

4. Using Power Shell, Create two host header site collection leveraging the departments managed path and specifying the SAML claim account of the Admin.

$wa = get-spwebapplication “ https://wfe”
$user = “i:05.t|samlprovider|administrator@contoso.local”

New-SPSite https://intranet.contoso.com/departments/engineering –HostHeaderWebApplication $wa –Name “Engineering” –Description “Engineering Dept” –owneralias $user –language 1033 –template “STS#0”

New-SPSite https://intranet.contoso.com/departments/hr –HostHeaderWebApplication $wa –Name “Hr” –Description “HR Dept” –owneralias $user –language 1033 –template “STS#0”

 

5. Finally, use step 6 from the Basic Host Name Site Collection setup DNS to ensure users can resolve intranet.contoso.com

 

 

Host Name Site Collections with Multiple URL’s and Zones

What about Host Name Site Collections with multiple URL’s and zones?   As stated in earlier in this blog, you have the ability to setup 5 unique URL’s per Host Name Site Collection.  These URL’s could all map to the default zone.  These URL’s could be evenly split across all 5 zones  (one URL per zone).   I can’t think of a good business case of why a company would use multiple unique URL’s all mapped to the same zone although it’s cool that it’s possible.  What about the multiple zone scenario?  That is, having a single HNSC with two unique URL’s.  One URL mapped to the default zone and the second one mapped to the extranet zone.  This is far more interesting and I see many business cases for this.  Perhaps you require a different URL for external users and apply restrictions at the web application’s extranet zone via User Policy.  Let’s take a closer look at how to set this up.              

 

 

Setup Multiple Zones with Host Name Site Collections

In this scenario, I already created a web application and host name site collection (HNSC) at https://intranet.contoso.com.   This HNSC is mapped to the default zone which is configured for multiple authentication providers (Windows Claims and SAML Claims).   It’s currently serving SharePoint page requests for intranet users.   I have a new security requirement to ensure users accessing this HNSC externally are assigned read only permissions.  One way to accomplish this is by adding an additional URL to this HNSC and map it to the Extranet Zone.   The external zone is only using SAML Claims provider (ADFS) for Authentication.  Finally, setup a User Policy to ensure all users accessing the designated Web Application -> Extranet Zone has only read access. 

1.) Adding additional URL’s for an HNSC and mapping them to a specific zone is only possible through PowerShell.

$site = get-spsite https://intranet.contoso.com
set-spsite –identity $site –url https://extranet.contoso.com –zone “Extranet”

 

2.) The URL assigned to the extranet zone must have representation in IIS so you must extend the web application and map it to the extranet zone.  Access Central Administrator\Manage Web Applications\Select Web Application and choose extend.

a. Name:  Extranet Contoso Sites
b. Port 443
c. Use SSL – Yes
d. Url: https://stubwfe  (what you put as the URL doesn’t matter)       

 

3.) Since the URL is unique, I must update SharePoint (RP) and ADFS (IP) so authentication requests work between both parties.

a. From SharePoint, add the URN and URL as a provider realm to the existing sptrustedtokenidentityissuer object using PowerShell.  It will look something like this:

$uri = new-object System.Uri(“ https://extranet.contoso.com”)
$ap = get-sptrustedidentitytokenissuer
$ap.ProviderRealms.Add($uri, “urn:extranet:contoso”)
$ap.update()

 

b.  From ADFS, add a new relying party trusts for Extranet HNSC

• • Set the relying party WS-Federation Passive Protocol as https://extranet.contoso.com/_trust/
  • Add the URN to the Relying party trust identifier field:  “urn:extranet:contoso”
  • Setup the appropriate claims rules defined by your organization

 

4.) From the WFE, Add an additional IP Address on the Network Adapter by going to network adapter properties on my nic and hit Advanced.

 

5.) Update Bindings on the Extended IIS Site to the following:

a. IP Address: 192.168.0.24  <- New IP
b. SSL Certificate “ContosoWildCardCert”  <- I can use the existing wild card cert since the URL matches “*.contoso.com”
c. Hit OK

 

Question:  Why would I be required to create a new IP address and bind it to the extended IIS site?

Answer:  Because each IIS Site requires uniqueness. Two IIS site listening for traffic on the same port without a host header or IP address defined isn’t unique and won’t work. Since HNSC’s don’t work with IIS Sites that are using host headers, the only supported option is to add an additional IP and bind to the extended IIS Site. The original site in this case requires no configuration.

 

6.) Setup User Policy on Web Application A that all users have read access and bind it to the Extranet Zone.

7.) Update DNS by adding the host record for extranet.contoso.com and point to the new IP

 

Question & Answer

Q: How should I setup my SharePoint 2013 Search Service Application to crawl HNSC's?
A: The only requirement is to add the URL of the web application within the desired content source. The crawler is able to detect and crawl any host header site collections defined in the web application.

Q: Is it possible to use a host header managed path across more than one web application?
A: Yes, this is what's unique about host header managed paths. They are shared across the farm.

Q: What if I just want to use a single Authentication Provider like Windows Claims?
A: The setup is much easier in this case as you wouldn't be required to mess with adding provider realms or updating external identity providers

Q: How do host name site collections work if I'm required to extend a web application to separate authentication providers?  How do I setup HNSC’s across multiple web applications?
A: The setup is a bit different but works fine. I'll discuss this in Part 2 of this blog series

 

I hope you found this guide helpful.  Out of curiosity, feel free to use the comments section to share how many host name site collections you provisioned in a single web application. I'm curious on your experiences :)

 

Additional Resources

Software boundaries and limits for SharePoint 2013

Logical Architecture Guidance for SharePoint 2013 Part 1

Host-named site collection architecture and deployment (SharePoint 2013)

 

Thanks,

Russ Maxwell, MSFT