I recently came across a very good blog posting on Host Named Site Collections (HNSC), and I recommend it: What Every SharePoint Admin Needs to Know about Host Named Site Collections by Kirk Evans.  Kirk has lots of good details here that will help answer questions on this popular feature with some obscure underpinnings.

However, I worked up other material on HNSC some time ago that’s not found in Kirk’s article.  Mine is targeted more to the SharePoint Architect who is considering the best way to design and use HNSC in a SharePoint farm.

One small discrepancy with Kirk’s article—he relates a commonly accepted fact of HNSC: “if you are going to implement host named site collections, you should not use a host header for the containing web application that houses the host named site collections or it will not work properly.”  The most unfortunate thing about this is that it requires you to use different IP  addresses or ports if you want more than one web application to host HNSC.  Fortunately, I was able to find that Microsoft does indeed support Host Headers and HNSC on the same web application; I give the procedure below and tips for verifying support through Microsoft Premier.  This provides an additional degree of flexibility for architecting your SharePoint farm.

Host Named Site Collections

The mechanism for consolidating existing web applications into individual site collections, yet retain their existing URLs, is to use Host-Named Site Collections (HNSC). This is a feature of SharePoint that allows individual site collections to have their own top-level URL. This section explores pertinent points from TechNet article Plan for host-named site collections (SharePoint Server 2010).

Benefits

• Much more scalable for vanity URLs because there can be thousands of site collections per web application, but only 20 web applications per farm.
• Managed paths may still be used on an HNSC web application, so that the more familiar “path-based” site collections may be created.
• An explicit or wildcard managed path may be created in the “normal” way, so that non-HNSC site collections may be created on them, as usual. This is done using Central Admin.
• Also, explicit and wildcard managed paths may be created on the web app that will apply to each HNSC site collection created. That is, each HNSC site collection will have the same managed paths that are created this way. This is done using PowerShell scripts; an example below shows adding these kind of managed paths..

Drawbacks

• HNSC may only be created using PowerShell scripts (or programmatically), not via the SharePoint UI.
• This introduces additional effort in creating them, similar to the effort of creating an additional web application, which requires a farm administrator, but with the added requirement of having to execute a PowerShell script on one of the farm servers. This also means that a higher level of access—server administrator—is required to create new HNSC. It would be possible to develop a simple extension to SharePoint that could be executed from Central Administration (or other administration site) to call the appropriate PowerShell script, so that this operation could be delegated back to a farm administrator.
• HNSC cannot use alternate access mappings. Host-named site collections are automatically considered to be in the Default zone, and the URL of the request must not be modified between the end user and the server.

Special considerations

For using SSL and SSL with encryption offloading, some special considerations apply.

• Because SharePoint Server 2010 uses the public URL in the Default zone of the Web application to determine whether host-named site collections will be rendered as HTTP or SSL, you can now use host-named site collections with off-box SSL termination. There are 3 requirements to use SSL termination with host-named site collections:
• The public URL in the Default zone of the Web application must be an HTTPS-based URL.
• The SSL terminator or reverse proxy must preserve the original HTTP host header from the client.
• If the client SSL request is sent to the default SSL port (443), then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the default HTTP port (80). If the client SSL request is sent to a non-default SSL port, then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the same non-default port.
• To use host-named site collections with off-box SSL termination, configure your Web application as you normally would for SSL termination and ensure that it meets the requirements described above. In this scenario, SharePoint Server 2010 will render links of its host-named site collections in that Web application using HTTPS instead HTTP.
• SharePoint Server 2010 does not support a host-named site collection using both HTTP- and SSL-based URLs simultaneously. If some host-named site collections need to be available over HTTP while other host-named site collections need to be available over SSL, separate the host-named site collections into two different Web applications dedicated for that type of access. In this scenario, HTTP host-named site collections should be in a Web application dedicated for HTTP access and SSL host-named site collections should be in a Web application dedicated for SSL access.

Both types of site collections may be mixed on the same web application. Comparison of features:

Feature	Path-Based Site Collection	Host-Named Site Collection
Managed Paths	YES	YES*
Create new site collection at top level	SharePoint UI	PowerShell Script
Create new site collection on a managed path	SharePoint UI	PowerShell Script
Authentication Zone	Choose: Default, Internet, Intranet, Extranet, Custom	Default only
Alternate Access Mapping (AAM)	YES	No
SSL	YES	YES
SSL Termination (encryption offloading)	YES	YES**
Kerberos	YES	YES

* Managed paths for HNSC and the site collections created on them must both be created using PowerShell scripts. The example later in this section shows both of these techniques.

** Offloading encryption for SSL sites is possible with HNSC, but has slightly more stringent requirements for configuration. Specifically: the public URL in the Default zone of the Web application must be an HTTPS-based URL, and the SSL terminator or reverse proxy must preserve the original HTTP host header from the client. Also, best to use standard ports 80 and 443.

Kerberos authentication works with HNSC as it does with an HH web application—must register a Service Principal Name (SPN) for the external URL on the identity of the application pool that hosts the web app.

The strategy recommended is:

• Create a Host-Named Site Collection for every request for a site that requires its own “vanity” URL. That these URLs can be either of the format http://newsite.customer.com, or even http://www.newsite.com, as far as SharePoint is concerned.
• DNS must be configured to serve the appropriate addresses.  If there are more than one web application in the farm that contain Host-Named Site Collections, then it will probably not be possible to use a wildcard DNS “A” record such as *.customer.com to direct all traffic correctly, but each HNSC will need a separate DNS “A” record. See analysis of options for creating multiple web apps, below.
• This option is for a less frequent, more “long-term” type of configuration request, justifying the additional effort.
• Create a Path-Based Site Collection for every request for a site that falls in the category of an existing web application. These use URLs such as http://teams.customer.com/sites/TeamOne, where TeamOne is the path-based site collection that may be created through the SharePoint UI. Explicit managed paths may also be used, such as http://teams.customer.com/TeamTwo.
• This option is for a more frequent type, “immediate” type of configuration request for new teams, communities, projects, etc., and can be accomplished entirely within SharePoint without server or external dependencies.

From an organization standpoint, it may be desirable to use a few individual web applications to organize sites by certain criteria, to better manage different types of sites from a standpoint of security, reliability, performance, scalability or SLA.  For the examples below, we’ll consider two web applications labeled “Standard” and “Sensitive”, then deploy HNSC to each web application.

Basic instructions for creating HNSC assume there is only one web application that supports these on the farm. When deploying multiple web applications that each will host HNSC, some additional complexity is required to create the web applications correctly. The following table compares the options for accomplishing this.

Options for creating multiple web apps for Host-Named Site Collections (HNSC)

When creating multiple web applications in SharePoint, they are often configured to use different Host Header (HH) names to ensure uniqueness, while having the same IP address and port (80 or 443). Host Header names on web applications are largely incompatible with Host-Named Site Collections, but can be made to work in a supported way.  The following table examines each option for creating multiple web apps, and their implications for HNSC:

Option	Implications	Supported?
1. Create web apps using different ports	Configure entirely through SharePoint UI. Some HNSC will require nonstandard ports in URLs; e.g. http://teams.customer.com:81 All URLs must include port numbers (That is, one web application hosting HNSC could use default port 80, but any additional web apps hosting HNSC would need to use a different port, and this would be required in all URLs hosted by those web applications.)	Yes (out-of-box)
2. Create web apps using different IP addresses	Requires multiple IP addresses, one per each web app that’s hosting HNSC. Must manually configure different IP addresses, per web app, per server. Must create VIP for each HNSC web app Must configure DNS for each HNSC to appropriate VIP Gives desired URLs, consolidated into multiple web applications, separated by category to enforce security, performance, reliability and scalability.  However, there is additional complexity of maintaining different IP addresses and mappings in DNS and the load balancer.	Yes (KB927376, applies also to SharePoint 2010)
3. Create web apps using different host headers	Blocks HNSC URLs being recognized by IIS. Must manually configure IIS to bind HNSC URLs to unblock, per web app, per server. This option has all the benefits of option 2, with the added benefit that DNS can be configured with wildcard third-level domain names so that creation of a new HNSC does not necessarily require a new DNS record.	Yes (reference Microsoft Premier case 111022261144490)

Option 1 – Identify by Port

This is the simplest approach, described in the reference article Plan for host-named site collections (SharePoint Server 2010). 

The problem with this approach is that if you want to configure more than one web application for HNSC, then only one of them may use default port 80 or 443, while the others must use different ports; many organizations don’t wish to require their users to enter ports for URLs to the various sites they plan for their intranet.

Option 2 – Identify by IP Address

This approach allows the creation of multiple web applications that are uniquely identified by IP address.  This means that “clean” URLs may be presented to the end user, without ports.  The drawbacks here are not necessarily terrible, but worth considering:

• Multiple IP addresses are required on the farm WFE servers; one per HNSC web application per WFE server.  This isn’t hard to configure, but some companies have policies against it that must be waived with a business justification.
• Creating a new HNSC web application means a new IP address must be provisioned onto each of the WFE servers, and into the load balancer, with a new Virtual IP (VIP) address as well.

IP Addresses. The first web application configured to host HNSC could use the “default” IP address of the server, but each additional web application to host HNSC must have a unique IP address. To accomplish this, the Network Interface Card (NIC) providing user access on each WFE server must be configured with multiple IP addresses. Naturally IP addresses will be different across all servers.

Load Balancer. The load balancer that distributes requests across all web front end servers must be configured with multiple Virtual IP (VIP) addresses. Each VIP will load balance out to the IP addresses associated with a separate web application across the WFE servers.

DNS. Finally, DNS must be configured with the root URLs of the HNSC, each targeted to the appropriate load-balanced VIP. A wildcard “A” record like *.customer.com cannot be used, unless DNS can be configured to guarantee that it will first honor all explicit “A” records such as teams.customer.com.

The following diagram shows conceptually the relationship among these aspects, also illustrating how non-HNSC web applications are configured:

In this diagram, each WFE has a “default” IP address; this is used for all requests to the server that are not host-named site collections, including Host Header web applications (e.g. mysite.customer.com, app.customer.com) and web applications distinguished with a separate port. Also, one web app hosting HNSC may also use this IP address. Then, additional IP addresses are shown, corresponding to each additional web application serving HNSC. Note, this arrangement minimizes the number of IP addresses required on each server. If that is not of great concern, it will be clearer to simply use a unique IP address for each HNSC web app, not configuring one of these on the default IP.

There must be a load-balanced VIP corresponding to each of the separate IP addresses across the WFE servers. VIP.1 is the “typical” VIP that distributes inbound requests to each server’s default IP address. VIP.2 distributes inbound requests to each server’s next additional IP address, and so on.

Note: for DNS entry *.customer.com, this will only work if DNS can be configured to examine inbound requests against all other explicit A records prior to following this wildcard entry.

How to create web applications with different IP addresses for HNSC

The following PowerShell scripts illustrate steps for configuring different IP addresses per web app, per server. This script creates two web apps, configures them to different IP addresses, then creates managed paths and a series of host-named site collections on the web apps. This approach follows KB article 927376, which gives the supported method for configuring web applications on different IP addresses. Written for MOSS 2007, KB article 927376 also applies to SharePoint 2010.

Full example scenario for option 2

1. Create web applications on the farm using host header names. Use the SharePoint UI to do this, or a PowerShell script such as the following.

# Create web apps using Host Headers so multiple can be created on port 80. # Run this once per farm New-SPWebApplication -ApplicationPool "SharePoint Web Apps" -Name "Portal" –HostHeader Portal -DataBaseName "WSS_Content_Portal" -DatabaseServer "FARMSQL" -Path "C:\inetpub\wwwroot\wss\VirtualDirectories\Portal" -Port 80 -URL "http://Portal:80" New-SPWebApplication -ApplicationPool "SharePoint Web Apps" -Name "Teams" -HostHeader Teams -DataBaseName "WSS_Content_Teams" -DatabaseServer "FARMSQL" -Path "C:\inetpub\wwwroot\wss\VirtualDirectories\Teams" -Port 80 -URL "http://Teams:80"

2. Change the bindings on the web applications just created in order to use IP addresses. It’s recommended to do this using PowerShell because the scripts can be created ahead of time and reviewed for correctness over multiple runs, instead of relying on a manual configuration via IIS manager each time. Note that the IP addresses will be different for each WFE server.

# Change bindings on web applications from host headers to IP Addresses # Run this once on each WFE server # Requires IIS Administration module Import-Module WebAdministration # Remove bindings with Host Headers from IIS sites Remove-WebBinding -Name "Portal" -HostHeader "Portal" Remove-WebBinding -Name "Teams" -HostHeader "Teams" # Replace with new bindings having unique IP Addresses New-WebBinding -Name "Portal" -IPAddress 192.168.3.11 -Port 80 New-WebBinding -Name "Teams" -IPAddress 192.168.3.12 -Port 80

3. Create Host-Named Site Collections on the web applications. PowerShell must be used to do this because the SharePoint UI does not provide this specific configuration option.

# Create Host-Named Site Collections (HNSC) # Run this once per farm # Add managed paths (for all HNSC in farm) New-SPManagedPath "it" -Explicit -HostHeader -ErrorAction Continue New-SPManagedPath "sec" -Explicit -HostHeader -ErrorAction Continue # Create HNSC on Portal New-SPSite http://communities.customer.com -HostHeaderWebApplication http://Portal -Name "CUSTOMER Community Sites" -Template "STS#0" -OwnerAlias CUSTOMER\Administrator New-SPSite http://intranet.customer.com -HostHeaderWebApplication http://Portal -Name "The Intranet" -Template "BLANKINTERNETCONTAINER#0" -OwnerAlias CUSTOMER\Administrator # Create HNSC on Teams, with sites on managed paths New-SPSite http://teams.customer.com -HostHeaderWebApplication http://Teams -Name "CUSTOMER Team sites" -Template "STS#1" -OwnerAlias CUSTOMER\Administrator New-SPSite http://teams.customer.com/it -HostHeaderWebApplication http://Teams -Name "CUSTOMER IT - Information Technology" -Template "BLOG#0" -OwnerAlias CUSTOMER\Administrator New-SPSite http://teams.customer.com/sec -HostHeaderWebApplication http://Teams -Name "CUSTOMER SEC - Information Security" -Template "BLOG#0" -OwnerAlias CUSTOMER\Administrator New-SPSite http://project.customer.com -HostHeaderWebApplication http://Teams -Name "Project Tracking" -Template "SGS#0" -OwnerAlias CUSTOMER\Administrator

Option 3 – Identify by Host Header

The TechNet article we’ve been referencing says several things against this option:

“In most cases, applying a host header binding at the IIS Web site level makes it impossible to access host-named site collections through the IIS Web site. This is because IIS will not respond to requests for host names that differ from the host header binding.”

“To ensure that both types of site collections are accessible to users, do not put host header bindings on the IIS Web site assigned to the Default zone of your Web application, if you have host-named site collections in that Web application.”

“You can manually modify host header bindings on the IIS Web site from the IIS Manager, but this is not recommended. Any changes you make using the IIS Manager will not be recorded in SharePoint Server 2010. If SharePoint Server 2010 tries to provision an IIS Web site on another computer in the farm for the same Web application and zone, the original host header binding is used instead of the modified binding.”

However, these can be overcome by following a process to maintain host header bindings on the IIS web site. A proposal to use this approach has been approved by Microsoft Premier as supportable; reference Microsoft Premier case “[REG:111022261144490] prem/SharePoint Server 2010 AL/Requesting RCS for support ability scenario”

The main implications of this option are the operational procedures for creating a new HNSC. Instead of using the SharePoint Central Administration console, or the feature for self-service site creation, PowerShell commands must be run, in the following specific order:

1. On each WFE server in the farm, must add a host header binding to the IIS web site hosting the web application/zone. This could be done via IIS manager, but it’s recommended to use a PowerShell script for accuracy and repeatability. Example of adding the HNSC URL binding for “sitename.customer.com” to the web application whose host header name is “Standard”:

New-WebBinding -Name "Standard" -HostHeader "sitename.customer.com"

(This requires the IIS Administration Module to be imported for PowerShell)

2. Once for the whole farm, must create the HNSC using a PowerShell command; it can’t be done via the SharePoint UI. Example of creating the HNSC “sitename.customer.com”

New-SPSite http://sitename.customer.com -HostHeaderWebApplication http://Standard -Name "Our Work Site" -Template "STS#1" -OwnerAlias CUSTOMER\Administrator

The steps must be performed in this order so that IIS is configured to respond correctly to the desired HNSC URL before SharePoint is asked to create it.

Note: if the -Template argument is omitted from the New-SPSite command, then the first access of the site collection will prompt for a choice of site template to be instantiated.

Note: this additional operational procedure would be necessary for option 2 also, because that is the recommended technique for creating web applications on different IP addresses.

Full example scenario for option 3

The PowerShell scripts below are an example showing how a set of web applications and site collections can be created using host headers to uniquely identify the web applications, thus avoiding the drawbacks of the “port” and “ip address” approaches.

Sample steps only

• Web app “Standard” will host intranet.customer.com and communities.customer.com
• Web app “Sensitive” will host teams.customer.com and projects.customer.com. In addition, managed paths are added so that teams will also contain teams.customer.com/sec and teams.customer.com/it.

1. Create web applications on the farm using host header names. Use the SharePoint UI to do this, or a PowerShell script such as the following.  Scripting is recommended for repeatability (dev, test and prod!)

# Create web apps using Host Headers so multiple can be created on port 80. # Run this once per farm New-SPWebApplication -ApplicationPool "SharePoint Web Apps" -Name "Standard" –HostHeader Standard -DataBaseName "WSS_Content_Standard" -DatabaseServer "FARMSQL" -Path "C:\inetpub\wwwroot\wss\VirtualDirectories\Standard" -Port 80 -URL "http://Standard:80" New-SPWebApplication -ApplicationPool "SharePoint Web Apps" -Name "Sensitive" –HostHeader Sensitive -DataBaseName "WSS_Content_Sensitive" -DatabaseServer "FARMSQL" -Path "C:\inetpub\wwwroot\wss\VirtualDirectories\Sensitive" -Port 80 -URL "http://Sensitive:80"

2. Add new bindings on web applications so IIS recognizes Host-Named Site Collection names

# Add HNSC bindings on web applications # Run this once on each WFE server # Requires IIS Administration module Import-Module WebAdministration # Add new bindings for HNSC New-WebBinding -Name "Standard" -HostHeader "intranet.customer.com" New-WebBinding -Name "Standard" -HostHeader "communities.customer.com" New-WebBinding -Name "Sensitive" -HostHeader "teams.customer.com" New-WebBinding -Name "Sensitive" -HostHeader "projects.customer.com"

3. Create Host-Named Site Collections on the web applications.

# Create Host-Named Site Collections (HNSC) # Run this once per farm # Add managed paths (for all HNSC in farm) New-SPManagedPath "it" -Explicit -HostHeader -ErrorAction Continue New-SPManagedPath "sec" -Explicit -HostHeader -ErrorAction Continue # Create HNSC on Standard New-SPSite http://intranet.customer.com -HostHeaderWebApplication http://Standard -Name "The Intranet" -Template "BLANKINTERNETCONTAINER#0" -OwnerAlias CUSTOMER\Administrator New-SPSite http://communities.customer.com -HostHeaderWebApplication http://Standard -Name "Community Sites" -Template "STS#0" -OwnerAlias CUSTOMER\Administrator # Create HNSC on Sensitive, with sites on managed paths New-SPSite http://teams.customer.com -HostHeaderWebApplication http://Sensitive -Name "Team sites" -Template "STS#1" -OwnerAlias CUSTOMER\Administrator New-SPSite http://teams.customer.com/it -HostHeaderWebApplication http://Sensitive -Name "IT - Information Technology" -Template "BLOG#0" -OwnerAlias CUSTOMER\Administrator New-SPSite http://teams.customer.com/sec -HostHeaderWebApplication http://Sensitive -Name "HR – Human Resources" -Template "BLOG#0" -OwnerAlias CUSTOMER\Administrator New-SPSite http://projects.customer.com -HostHeaderWebApplication http://Sensitive -Name " Project sites" -Template "SGS#0" -OwnerAlias CUSTOMER\Administrator

Note: Wildcard managed paths for HNSC can also be added, by omitting the -Explicit parameter from New_SPManagedPath.

This type of configuration is supported, and illustrates a way to partially automate this configuration on each WFE in the farm.