Sign In
 
 
Go Search
 
Zach Rosenfield's SharePoint Blog > Posts > SharePoint 101: Managed Paths
SharePoint 101: Managed Paths

I often get asked "What is a managed path?" and thought it would make for a good blog post. However, first I must disambiguate a couple common SharePoint terms. For the remainder of this post I will use Object Model (OM) terms for the following objects listed below. I've given a small explanation of these objects—but it is certainly not all inclusive.

  • SPWeb: These are referred to in SharePoint UI as a "Site". SPWeb's are a collection of user data (lists, library, docs, pages, etc.) in a database. An SPWeb belongs to one, and only one, SPSite.
  • SPSite: These are referred to in SharePoint UI as a "Site Collection". SPSites are a grouping of SPWebs that all share the same root URL. The SPWeb that lives at the root url of an SPSite is called the "Root Web". SPSites have settings, but do not contain user data.

SPSites have one very important feature—all SPWebs in an SPSite must be stored in the same Content Database. This is key to how we figure out what database user data is stored in.

Now, on to managed paths! When user types in a URL into their browser—the root domain is directed through DNS to a SharePoint Server (this is the easy part!). Once SharePoint gets a URL, how does it now what data to look up?! Let's take the following url: http://www.foo.com/sites/foo/bar/foobar. The first thing to note is that we know that the user's data (provided he typed a valid URL in) is in an SPWeb somewhere… But where? First we need to figure out the 'containing' SPSite so we know what database to look at—but which part of the URL gives us the address of the SPSite? /sites? /? /sites/foo/bar? This is where Managed Paths play their role.

SPSites are limited to being created only where a managed path is defined! For example, "(root)" is one of the default managed paths you see when creating a new web application in SharePoint (visit Central Administration -> Application Management -> Define Managed Paths). This means you can create one site collection at the root of the web app—in our example, this means you can have a site collection at http://foo.com. This is an explicit managed path as it means you can create only one site collection at the exact location specified.

Another default managed path you see is "sites"—which is a wildcard managed path. This allows for unlimited number of site collections to be created directly under the provided path (it is important to note that a site collection, and thus an SPWeb, cannot be created at this explicit url). This means I can create site collection (and only SPSites, not SPWebs) directly under this url (http://foo/sites/foo). This means that any additional path in the given URL is an spweb (created from the root web of this spsite). So in our example, we can split the incoming URL into four pieces to quickly look up the information:

"http://ww.foo.com" + "/Sites" + "/Foo" + "/bar/foobar"
(Web Application) + (managed path) + (SPSite) + (Web/SubWeb)

Whenever a URL is 'received' by SharePoint, the site collection is determined by looking at the list of managed paths for a given Web Application. This means SharePoint has to look at every managed path so try to limit the number of managed paths (<20 is highly recommended). SharePoint always matches the longest pattern possible—we'll look at a more complicated example to explain the reason. Using the following managed paths:

  • 10 (explicit)
  • 10/teams (wildcard)
  • 10/howto (explicit)
  • 10/howto/misc (wildcard)

How do we map out URLs? Site Collections (SPSites) urls are highlighted in Bold:

  • http://foo.com/10/teams/sites/bar
  • http://foo.com/10/myteam/sites/bar
  • http://foo.com/10/howto/team1/foo
  • http://foo.com/10/howto/misc/team1/foo/bar
  • http://foo.com/10/howto/misc/team2/foo

The key item to note is in the last three example URLs—notice that the longest managed path (10/howto/misc) takes precedence over the shorter (10/howto). Hopefully this clears up Managed Paths! I'll end by summarizing:

  • 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

Comments

Thanks

This is a really great article. I never knew this is how sharepoint parses the url.
http://blogs.msdn.com
at 7/12/2008 11:34 AM

Thanks

Very readable explanation. Thanks.
at 10/26/2008 5:08 AM

Question about using SPSite

Thanks for this post.  It has been the clearest example of how this is done.  I have a question though.  Let’s say I have a farm and I have one web application.  There are two site collections in the web app (SC1 and SC2).  SC1 is the “default” or “root” site collection.  We just recently built SC2.  We have a managed path defined for it as Explicit Inclusion.  We can access the site through a browser fine.  However, we have code that needs to create a new SPSite object.  We are putting the URL of the SC2 in and it would appear that it is picking up the “root” site collection of SC1.  The reason we think this is because we listed out all of the SPWebs for the SPSite and the webs were of SC1 and not SC2.  Do you have any ideas?
at 12/8/2008 12:14 PM

Good One

This is class one Article for the Managed path. Thanks for Sharing.
http://skurocks.wordpress.com/
at 4/28/2009 12:12 AM

Re: SharePoint 101: Managed Paths

It Was really useful
Thanxxxxxxxx
at 10/21/2009 7:51 AM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title


Comments *


Name (required) *


Attachments
 
 
   
Real Time Web Analytics