Stacking Managed Paths

Most SharePoint administrators are likely familiar with the Managed Paths feature that allows certain paths to be designated to hold site collections. The “sites” entry is added by default. Not everyone knows that those paths can be stacked to provide the same functionality at different levels.

Flat versus Deep
As part of any Taxonomy plan the team should always consider the appropriate depth to the site collections. Some might argue having a flat taxonomy with lots of siblings, while others will push for a traditional hierarchy.

Using single level Manage Paths help to provide fairly flat site collection taxonomy. That would give you a top-level site, and then site collections organized one level down. In most of the systems I have worked with there are more than one entry, typically separated by a general purpose (i.e. Projects, Team Sites, Applications, ECM Sites).

In some medium complex organizations that may not be enough. Perhaps there are multiple business units, and the sites could benefit from some BU level landing pages with the site collections below that. Stacking the managed paths will provide this.

For example:

Regular managed paths: http://myserver/units/

Stacked managed paths: http://myserver/units/euro/sites/

Note: In very large organizations it is likely that these sites would be in separate web applications or even separate farms. This technique may still offer value.

Landing Pages/Sites
To establish a landing area Site Collection above each of the managed path entries you will need to define a single level managed path and create the site collection as usually. Using the example above /units would be used for the managed paths and the site collection would be setup at http://myserver/units/euro. This would serve as the landing page for European Operations. The site collections underneath would be organized in the sites path.

When establishing the managed paths, the system does not check to see if a site exists at the path you supplied. If you were to setup a site collection at http://myserver/units and then establish /units as a managed path the site would no longer be accessible.

Site Collections versus Sub-Sites
There are a number of reasons why you might choose the isolation of Site Collections versus creating sub-sites. One big reason to require Site Collections would be for Quota Management which may be needed to support a chargeback system. Since quotas are set at the site collection level you will need isolation in order to manage that effectively and provide accurate notification and reporting.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: