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:

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
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s