With SharePoint 2007, we had a possibility to create host header site collections. SharePoint 2010 extends this possibility by allowing us to create multiple site collections within one logical host header URL space. This means, not only that you can have for example site collection under http://hosting.adrit.local (as seen in SharePoint 2007) but you can have now additional site collection(s) in location like http://hosting.adrit.local/sites/site1.

I suppose the main driver to bring such an improvement was multitenancy. In a multi-tenant scenario, you can have something like:

• http://www.tenant.com as a main site collection
• http://www.tenant.com/mysite for a tenant-specific MySite Host
• http://www.tenant.com/mysite/personal/* for personal sites
• http://www.tenant.com/admin for tenant admin site collection
• http://www.tenant.com/search for a search center (bad idea, keep reading :))

and so on. To be able to create these site collections, you will need to have appropriate managed paths in place.

Managed paths defined for a Web Application itself just won’t work. We need to define here Host Header Managed Paths. Now, as for Host Header Site Collections, there is just no UI which you can use to configure this. The only way to create managed paths for Host Header site collections is through PowerShell. Cmdlet that will be used for this purpose is the same cmdlet as for creating regular Managed Paths: New-SPManagedPath. The switch you want to use for this is HostHeader. Example:

New-SPManagedPath -RelativeURL admin -HostHeader -Explicit

Explicit switch specifies that the new managed path represent a explicit inclusion. If ommited, a wildcard path will be created.

Now, testing various scenarios, I figured out that you *REALLY* need to think about naming and various naming space collision scenarios. Why? Because, unfortunately, managed paths created this way will be applied over *ALL* web applications. The reason for that is that host header managed paths are not bound to any web application. Example:

New-SPManagedPath -WebApplication http://hosting.adrit.local -RelativeURL testMP -HostHeader 

will cause following error:

New-SPManagedPath : Parameter set cannot be resolved using the specified named parameters.

If you omit the WebApplication parameter, the cmdlet will run successfully.

A really bad example of managed path naming and good collision example is “search” managed path, as mentioned earlier. If you create this one you will break site provisioning using Publishing Template all over your farm, at least for the root of your web applications. Why is that? Well, Publishing Template will try to create a search center within Search subsite. As “/search” is already reserved via (host header) managed path… *bang* – provisioning fails.

One more thing – you won’t be able to see these managed paths via Central Administration UI. Im order to see them you will have to run following cmdlet:

Get-SPManagedPath -HostHeader