Understanding Managed Paths in SharePoint 2010
Managed paths in Microsoft SharePoint 2010 can seem straightforward, but it can also easily get out of hand. Without SharePoint governance and thoughtful planning, your managed paths will be configured without any logic or strategy and can quickly become confusing and hard to manage.
In this article we’ll cover what managed paths are, why they’re important, and how you can plan for them and use them.
What is a managed path in SharePoint 2010?
A managed path is a location within a web application in which you can have site collections. When a web application is created, there are two managed paths that were created with it. The first managed path is called the “/” path, or root. The “/” path is an explicit inclusion managed path. The second is called “sites,” or a wildcard inclusion path.
These are the two types of managed paths that you can create. An explicit inclusion managed path defines an exact path to which a site collection can be directly attached. A wildcard inclusion managed path defines a path that cannot have a site collection attached at its root but can have multiple site collections assigned beneath it.
Example of an explicit inclusion managed path
A good example of an explicit inclusion managed path is the one that is created at the root of a web application, as seen below.
With an explicit inclusion managed path defined at the root, you can create one site collection there. Any attempts to put another site collection in that spot will give an error. You can always have multiple sites in that site collection, but you can only have one site collection in the explicit managed path.
Example of a wildcard inclusion managed path
There is a wildcard inclusion managed path that is added by default to a web application. “Sites” is a wildcard managed path, thus it can have multiple site collections underneath that path, but no site collections are added to the path. The example below shows how a wildcard inclusion managed path helps to separate similar site collections.
In this example, we see that each client is being given their own site collection. This helps to keep the clients separate and with their own content database, as well as their own styles and user permissions.
Since each of the site collections for a client would go in the “clients” managed path, the clients are set up as a wildcard path. And since it’s a wildcard path, then there can be no site collection at the root of HTTP://SharePoint.contoso.com/clients.
Why Use Managed Paths Anyway?
There are two great reasons for using managed paths.
Managed paths, well, manages the paths. That might sound a bit funny, but it’s true. Within SharePoint, you cannot create a site collection just anywhere you want. You have to attach a site collection to a managed path.
The biggest benefit of doing this is that it helps keep SharePoint manageable from the user’s perspective. You don’t want site collections to be created haphazardly. There should be some logic applied to the structure. In highly structured environments, a SharePoint steering committee can specify the managed paths that should be used. Policies then prohibit the addition of new managed paths without committee approval.
When administrators create new site collections, they are unable to create them outside of where the managed paths define.
Managed paths helps SharePoint identify which content database should be used. Since all sites in a site collection use the same content database, using managed paths helps SharePoint identify where the content database is located. When you browse to a website in SharePoint, each managed path is checked against the URL. This way, SharePoint can more easily identify which part of your URL is a site collection and which part of the URL is a managed path. Once SharePoint knows which part of the URL is the site collection, it can identify the content database.
It should be noted that each managed path adds a little bit of overhead to the SharePoint Web application performance. For this reason, you should not go over 20 managed paths total on SharePoint web applications.
How to Add a Managed Path in SharePoint 2010
So are you ready to create some managed paths in SharePoint 2010? Creating them is very easy.
Step 1: Open the SharePoint Central Administration site.
Step 2: Under “Application Management,” choose “Manage Web Applications.”
Step 3: Select the Web Applications for which you want to create managed paths.
Step 4: Click “Managed Paths” in the Ribbon.
Step 5: In Managed Paths, add a name for your path. This path can have multiple levels in it if needed.
Step 6: Choose either a wildcard or explicit inclusion.
Step 7: Click “Add Path” then “OK.”
Once the managed paths are created, site collections can be created on them.
In SharePoint 2010, managed paths are a necessary part of the design and administration. Managed paths help SharePoint identify which part of a URL is the actual site collection, which in turn leads to the site collections’ content database. Because managed paths are checked as SharePoint delivers web pages, do not create more than 20 managed paths per web application.
Managed paths also help with maintaining a logical and structured SharePoint environment. A site collection can only be created when it is assigned to a managed path.
To review: A wildcard inclusion managed path is useful when there will be multiple site collections of a similar nature. “Products,” “Services,” and “Clients” are all good examples of the types of managed paths that are likely to be wildcard inclusions. Wildcards cannot have a site collection added at its root. An explicit inclusion managed path is useful when you want the site collection to have a separate web address, but you will still have only one site collection. The best example of an explicit inclusion managed path is the first “/” in a web application.
Managed paths are a requirement. If you’re setting up SharePoint, you will have to see them to setup a SharePoint site collection. But if you don’t know when to use each type of managed path, it can end up being confusing and frustrating when it’s time to create the site collections.
More in SharePoint 2010
Microsoft Unveils SharePoint Server Subscription Edition
Jul 20, 2021 | Brad Sams
Everything you need to know about SharePoint – November 2018
Nov 30, 2018 | Shane Young
Continuing the SharePoint Migration Journey – Site Collections
May 14, 2018 | Shane Young
Learn to Work with SharePoint PowerShell Objects and Scripts
Dec 21, 2016 | Shane Young
Install and Configure Remote BLOB Storage (RBS) in a SharePoint Farm
Jun 18, 2013 | Phoummala Schmitt
Comparison Shopping: SharePoint 2010 Versions
Oct 10, 2012 | Michael Simmons
Most popular on petri