Tuesday, March 12, 2013

SharePoint 2010 Managed Paths


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.
Why use Managed Paths?
If you have a medium-scale or larger implementation, give serious consideration to extending the default set of managed paths. A managed path is defined as the path in the URI that is managed by SharePoint products. As an example, sites is the managed path in http://<site>/sites/madison. Managed paths cannot be limited for use by specific security groups, nor can they be targeted directly with audiences. They are simply a way to organize a large quantity of site collections.
When using managed paths, you can have two site collections with same name [i.e., 'Meetings']. For Example, http://<site>HR/Meetings and http://<site>Sales/Meetings [have the same site collection name of 'Meetings'].
When adding a new path, you have the option either to include only that path (explicit inclusion) or to specify that path and all subordinate paths (wildcard inclusion). If the path http:/<site>/sites was specified as an explicit inclusion, content could still be served from the WFE file system at http://<site>/sites/path. When creating an explicit inclusion managed path, you can then create a single site collection in the root of that path. If http://<site>/sites was specified as a wildcard inclusion, multiple named site collections could be created under that path.
If that didn't clear things up, then let's take it one step further.

Explicit Inclusion versus Wildcard Inclusion

Explicit Inclusion
Includes only the specific path you set. Use explicit inclusions, for example, if you want Windows SharePoint Services to manage a specific path, such as /portal, but not any possible sites below it, such as /portal/webapp.

Wildcard Inclusion
Includes any sites below the path you set, so you don't have to add them individually. This is the type of inclusion to use for Self-Service Site Creation, when you want users to be able to create top-level Web sites underneath a specific path, such as /sites.

Example
For example, using an explicit inclusion, you are saying that http://<site>/team/ is a site collection without the possibility of any site collections below it; however, wildcard exclusion allows you to create site collections under http://<site>/team/
Conclusion
Having a solid understanding of Managed Paths is a definite must for any SharePoint administrator. Though, I'm sure I'll have to refer to my own blog post the next time I need to configure Managed Paths.
Few Key points
  • Managed Paths allow SharePoint to determine what portion of a given URL corresponds to the "site collection URL".
  • Managed Paths can be defined per web application (and cannot be defined for host header site collections)
  • Managed Paths can be "Explicit" or "Wildcard"
  • Explicit Managed Paths allow a single spsite to be created at exactly the given url
  • Wildcard Manage Paths allow unlimited spsites to be created under the given url – no spsite can be created at exactly that URL.
  • Limit your managed paths to <20 per web application 

No comments:

Post a Comment