Came through some of the good articles on SharePoint Managed Paths:
Source:
http://sharepoint.microsoft.com/Blogs/zach/Lists/Posts/Post.aspx?ID=30
http://technet.microsoft.com/en-us/library/cc288905.aspx
The advantage of multiple managed paths is it's a first piece of metadata you can have in your farm. It helps break sites out into logical trees even thought they all reside in the same farm. This becomes very beneficial if you organize your structure very flat (many site collection)
•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
Define managed paths for a Web application by using Central Administration
Define managed paths for a Web application by using Windows Powershell
Define managed paths for a Web application by using Central Administration
Use the procedures described here to add or delete managed paths for a Web application by using Central Administration.
To add a managed path by using Central Administration
1.Verify that the user account that is performing this task is a member of the Farm Administrators SharePoint group.
2.On the SharePoint Central Administration Web site, click Application Management.
3.On the Application Management page, click Manage Web Applications
.4.Click the Web application for which you want to manage paths. The ribbon becomes active.
5.On the ribbon, click Managed Paths.
6.On the Define Managed Paths page, in the Add a New Path section, type the path to include.
7.Click Check URL to confirm the path name.
8.Use the Type dropdown menu to identify the path as either Wildcard inclusion or Explicit inclusion. The Wildcard inclusion type includes all paths that are subordinate to the specified path. The Explicit inclusion type includes only the site that is indicated by the specified path. Sites subordinate to the specified path are not included.
9.Click Add Path.
10.When you have finished adding paths, click OK.
To remove a managed path by using Central Administration:
1.Verify that the user account that is performing this task is a member of the Farm Administrators SharePoint group.
2.On the SharePoint Central Administration Web site, click Application Management.
3.On the Application Management page, click Manage Web Applications.
4.Click the Web application for which you want to manage paths. The ribbon becomes active.
5.On the ribbon, click Managed Paths.
6.On the Define Managed Paths page, in the Included Paths section, click the check box next to the path that you want to remove.
7.Click Delete selected paths.
Warning:
Be sure that you want to remove the selected path before performing this action. You will have no additional opportunity to confirm. Deletion is immediate.
8.When you have finished removing paths, click OK.
Define managed paths for a Web application by using Windows Powershell
You can use the New-SPManagedPath cmdlet to add managed paths for a Web application.
You can use the Remove-SPManagedPath cmdlet to remove managed paths from a Web application.
The New-SPManagedPath cmdlet adds a new managed path to a given Web application or for use with all host header site collections
. If the HostHeader switch is provided, the managed path is shared among all host header site collections; otherwise, you must specify a Web application in which to create this managed path. The relative URL is a partial URL that represents the managed path. When the slash mark (/) is used, the root is defined. If the Explicit parameter is not provided, the new managed path is a wildcard path.
To add a managed path by using Windows PowerShell
1.Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
2.On the Start menu, click All Programs.
3.Click Microsoft SharePoint 2010 Products.
4.Click SharePoint 2010 Management Shell.
5.At the Windows PowerShell command prompt, type the following command:
Copy
New-SPManagedPath [-RelativeURL] "" -WebApplication
Where:
is the relative URL for the new managed path. The type must be a valid partial URL, such as site or sites/teams/.
is the Web application group to add this path.
For more information, see New-SPManagedPath.
To remove a managed path by using Windows PowerShell
1.Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
2.On the Start menu, click All Programs.
3.Click Microsoft SharePoint 2010 Products.
4.Click SharePoint 2010 Management Shell.
5.At the Windows PowerShell command prompt, type the following command:.
Copy
Remove-SPManagedPath [-Identity] -WebApplication
Where:
is the name of the managed path to delete.
is the identity of the Web application that hosts the managed path to delete.
You are prompted to confirm the deletion.
For more information, see Remove-SPManagedPath.
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.
