Vanity Site Collection URLs

A customer recently asked for “vanity” URLs for each of the major departments; HR, Finance, Legal, etc.; so for example, HR would be http://hr.bigcorp, and legal would be http://legal.bigcorp.  No problem you say, just create a web application for each department, give the web application default zone the vanity URL, create corresponding DNS entries, and the requirement is fulfilled.

The problem is there are over 30 departments, not to mention foreign subsidiaries, and possibly other “I want my own vanity URL” requests from other corporate groups. Since web applications are heavy resource consumers, each one requiring one IIS web site per zone, basing vanity URLS on web applications would not be feasible.

The traditional out-of-the-box site collection paths did not meet the requirements;

Wildcard inclusion; e.g., http://bigcorp/sites/finance

Explicit inclusion: e.g., http://bigcorp/finance

For both wildcard inclusion and explicit inclusion, the vanity part of the URL is at the end, which is not what was desired.

Host-Named Site Collections

Host-named site collections (what used to be called "scalable hosting mode" in WSS v2) provide exactly the needed capability. Don’t confuse the terms host-named with host headers. They are different concepts. The host-named concept applies to the internal SharePoint virtual path mapping mechanism; whereas host headers apply to IIS web sites independent of SharePoint.

Host-named site collections effectively allow use of an arbitrary URL, which is associated with an existing web application. There can be many host-named sites for a web application.  The net result is freedom to have as many vanity URLs as necessary, while limiting the number of web applications. We can have URLs like http://finance.bigcorp, http://finance, http://my.finance, etc.

Host-named sites cannot be created through the UI. You must use stsadm. This should not deter you, since the syntax is simple. The secret is to add the –hhurl parameter to the stsadm createsite command.

Host-Named Site Collections Limitations

As with all good things, there are some limitations and complications. The following blog is an excellent read: http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx. Quoting from this blog:

Host-named site collections short circuit much of the AAM functionality, including the URL remapping functionality.  They're always considered to be in the Default zone, and their URL is always the same URL you supplied when creating the site collection.  You cannot use host-named site collections with off-box SSL termination, port translation, or host header manipulation scenarios.

This whitepaper is also highly recommended reading. It discusses how to enable SSL, and many other configuration issues:

http://office.microsoft.com/search/redir.aspx?AssetID=AM102157711033

Step-by-Step Example

Assume we want to create a site collection with the vanity URL http://finance.litwareinc.com in the http://extranet.litwareinc.com web application.

Step 1: Open a command prompt as a farm administrator, and then enter this command, being sure to include the –hhurl parameter:

>stsadm -o createsite -url http://finance.litwareinc.com -ownerlogin litwareinc\administrator -owneremail administrator@litwareinc.com -hhurl http://extranet.litwareinc.com -sitetemplate STS#1 -title "Finance Department" -quota DepartmentalSite

Operation completed successfully.

The new site collection appears in the site collection list of the extranet.litwareinc.com web application.

Step 2: Create a DNS entry for this new name, pointing to the http://extranet.litwareinc.com IP address. For local test, make an entry the hosts file.

You can now open a browser and navigate to the site collection.

Step 3: Create a search context for the new site collection, or include it as a starting address within an existing site collection. Start a crawl to include the site contents in the search index.

To test the search, create a simple text document in a shared document library. When the next increment crawl completes, you can then search for the document to verify the search results are using the vanity URL.

The Kerberos Factor

The stsadm site creation command will give a warning if the host web application is using Kerberos authentication (negotiate).

>stsadm -o createsite -url http://finance.litwareinc.com –ownerlogin mossfs\administrator -owneremail administrator

@mossfs.com -hhurl http://dmz.litwareinc.com -sitetemplate STS#1 -title "Finance Department"

WARNING: SharePoint no longer customizes Integrated Authentication security settings. This Web application may be using Kerberos, which can require manual configuration. See http://support.microsoft.c

om/?id=832769 for more information.

Operation completed successfully.

It is necessary to register the vanity URL with Active Directory using setspn.

>setspn -a http/finance.litwareinc.com litwareinc\administrator

In my testing, I stumbled into another complication. Without realizing it at first, I created a site collection in the Intranet zone of a web application, which was configured for Kerberos.

After creating the site collection, adding the DNS (host file) entry, and executing setspn, I got a “This site is under construction” error page every time I tried to browse to the site. I eventually worked-around this by explicitly adding a host header to the IIS web site. I consider this an unsupported solution, and so I recommend extensive testing before applying it to a production scenario.