It doesn't have to be that way, we can have our http://hostname/<sitecollection>. And we don't need any URL rewriting or any other complex solution, just use the OOTB options correctly!
We will have a quick dive into the Central Administration, in Application Management > Manage web applications. Select a Web Application and click "Managed Paths" in the ribbon. The reason why the only option when creating a new Site Collection is "/sites" is due to the configuration there.
The default configuration is, as follows:
- (root) - Explicit inclusion
- sites - Wildcard inclusion
What does this mean? It means that we can have one Site Collection in the root (/) and multiple inside sites (/sites/*). That's exactly what is happening. When you create your root Site Collection you put into the root URL ("/") and when creating a new Site Collection you only have the /sites option.
The explicit inclusion type allows you to create a single Site Collection in the specific specified URL (/<url>), while the wildcard inclusion allows you to create multiple sites inside the specified URL (/<url>/*), but not in the base URL itself.
The reason for this is simple, if you had a Site Collection in that level and multiple Site Collections beneath it, IIS/SharePoint would not know (in a simple way) where to route when accessing a site in /<url>/*. Would it be a subsite in the root Site Collection or a Site Collection within it? That's why trying something like making the (root) a wildcard inclusion will not work if you plan having a Site Collection in the root as well. If you don't (only Site Collections in /*), that would actually work well.
Then, going back to our problem, how to create a specific location for our Site Collection (http://hostname/<sitecollection>)?
Just add a new managed path, enter the URL you want (<sitecollection>) and choose "Explicit inclusion" as type. The next time you create a new Site Collection, you will have this path available to you!
Once you use it in a Site Collection, it will obviously not be available in the creation of further Site Collections, which means you must configure a managed path for each Site Collection you want to place as http://hostname/<sitecollection>, which actually makes total sense.
When creating your managed paths, you should always click "Check URL" to make sure no subsite is created in that location. If it does, you will actually be unable to enter that subsite while the managed path is there, as SharePoint will always try to redirect you to the Site Collection using that path. If you haven't created the Site Collection, you will get a HTTP 404 Not Found, you will still not get redirected to the subsite. Deleting the managed path will get everything back to normal.
On the other hand, after creating a managed path and when creating a subsite in that location in the root Site Collection, you will get the following error:
Error
"<url>" cannot be used as a site name. Site names cannot contain certain reserved words and cannot begin with an underscore. Please enter a different name.
Site name actually refers to Site URL name, and not Site Title (one of those funny SharePoint error messages).
SharePoint checks if the subsite URL collides with any of the managed paths and actually enforce that no subsite is created there.
Hi Alex, great post, thanks. It might also be worth mentioning that Microsoft advises a maximum of 20 managed paths per Web Application before performance degradation will be experienced - so that should be taken into account when you do your planning.
ReplyDeleteThanks for the comment. You are absolutely right, it is something to be considered when the Web App is expected to scale beyond 20 site collections. The limit applies to SP2013 as well.
Delete