Wen He

What is a host head-based site collection?

First of all, a host header-based site collection is a site collection that allows you to specify your own host header on the site collection level. This provides you with tons of power and flexibility.  Who could it be possible?  Read along...

In my previous blog, I talked about you can extend a Web application to use a different authentication. So basically you have two IIS Web Applications that share the same content database and same site collection. This is cool when you need to authenticate different type of people to access the same site collection. 

Why host head-based site collection?

What if you have a Web application that's already configured to use FBA, and you want to share the same authentication that you've already configured and the same users that are already registered, and you just want to add a site collection to "inherit" all that, but you want the new site collection to use "root" URL. (A "root" URL is a top-level URL that cannot be a managed path or sub-site collection.)

This is exactly what we were wanting to do: host www.HawaiiDotNetUserGroup.com on the same Web application where http://SharePointHawaii.com is hosted to achieve the goals:

1. Serve the same community
2. Share the same FBA authentication store and user profile
3. Have different permissions in each site collection

One of the coolest things you can do is create host header based site collections, enabling a single SharePoint web application the ability to contain http://SharePointHawaii.com and www.HawaiiDotNetUserGroup.com. Given that Microsoft recommends a maximum limit of 20 Web Applications on a farm, the ability to use site collections as the entry point for host headers is very significant (expanding the potential total number of sites on a single farm into the thousands).

How to create a host head-based site collection?

You could use STSAdm -o CreateSite command and specify -URL and -HHURL. But we wanted www.HawaiiDotNetUserGroup.com to have its dedicated database for better maintenance & management. So we used CreateSiteInNewDB switch. Here's the complete command:

STSAdm -o CreateSiteInNewDB 
-URL www.HawaiiDotNetUserGroup.com 
-owneremail hewen@hotmail.com 
-ownerlogin sharepoint\wen 
-HHURL http://SharePointHawaii.com 
-databaseserver SharePointHI 
-databasename WSSContentHawaiiDotNETGroup

To resolve the name www.HawaiiDotNetUserGroup.com, you need to register the domain and have its DNS point to the outer IP of SharePoint. Once the request from that site reaches the IIS, how does IIS know where to direct the traffic? Well, just add the new Host Header to the existing SharePointHawaii.com Web application (see below)

Host headers in the Site Bindings

Now when you browse to this site www.HawaiiDotNetUserGroup.com now, you will be directed to select a site template because I purposely left that part which lets you pick the template in the format of STS#1. Of course, we could add the switch to the CreateSite command which lets you pick the template in the format of STS#1 (for blank sites).

Now the site www.HawaiiDotNetUserGroup.com has been provisioned as root URL (Host Header-based) site collection on the same Web application as http;//SharePointHawaii.com.

In conclusion, there are some caveats:

1. You can do host headers on site collections in a web application as long as the host header is in the same domain as the web application. It will work automatically without manually adding the host header.
2. If you try creating a site with a URL that isn't in the exact same domain as the web application, the command will tell you it was successful but you cannot actually access the site collection. You will have to add the host header manually to the Site Bindings (see above Host headers in the Site Bindings).
3. You cannot manage the site collection's access mapping like you can a web application. As a matter of fact, AAM has no idea that the site collection has a host header.
4. You cannot use SSL on a host header-based site collection, because it's applied to the web application. Site collections aren't a security boundary like web applications are. Site collections are contained in web applications and play by the web app's rules. However, if you are using a wildcard certificate on the web application containing the site, and if the site collection's host header is in the same domain, it can work.
5. You cannot search the host header site that uses both HTTP and HTTPS (see KB927919)
   If you want the host-named site collection to be searchable over HTTP, put the host-named collection in the HTTP Web application. If you want the host-named site collection to be searchable over HTTPS, put the host-named site collection in the HTTPS Web application.
   

Hope this helps. Please send your feedback and comments. Mahalo!