A little bit of Host Header Managed Paths love… or how (not) to break your Publishing Template provisioning

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:

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


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s