SharePoint Blogs / SharePoint University
SharePoint Blogs and SharePoint University - all in one place!
Need SharePoint Training? Attend a SharePoint Bootcamp!

Please delete cookies related to sharepointblogs.com and sharepointu.com to resolve login issues!

SharePoint and Managed Paths

I recently had a question on my SharePoint Architecture posting asking about more details on the use of managed paths. In the email I was asked about a specific scenario regarding 180 departments, managed paths, and scripting out the creation of these site collections. I wanted to share my response for anyone else who might have the same question. Below is my response....

Managed Paths are elements that can be setup for a web application under Central Administration. There are 2 types of managed paths (Explicit and Wildcard). Explicit managed paths allow you to create a single site collection at that specific path only. Wildcard managed paths all you to create multiple site collections using that managed path. Here are some examples...
 
Explicit Managed Path: Accounting
Wildcard Managed Path: Departments
 
Site Collection URL created using the explicit managed path: http://server/accounting
Site Collection URL's created using the wildcard managed path: http://server/departments/accounting, http://server/departments/hr , http://server/departments/it
 
As you can see the "departments" wildcard path acts as a place holder to create site collections related to "departments". The reason why i say it represents a phyiscal hierarchy is becase if this were a normal asp.net web site there would be a physical folder structure on the hard drive somewhere and departments would be that folder. What managed paths allow you to do is represent that physical structure in the URL for the end users and allow for organization on the administrators part. Plus everything in sharepoint is stored in a database, so there are no physical heirarchies. Managed paths allow you to create that feel.
 
As far as scripting is concerned, you can create a BAT file using STSADM -o createsite operation to script out all the site collections. I usually create a list in excel and use a formula to write out the STSADM command then copy it down the list. After I copy out all the stsadm commands into a BAT file and you good to go. Keep in mind site qoutas and database sizing and maintenance. You can have all 180 site collections in a single database if you want, but make sure the forcasted size of that database is manageable in your sql environment (backups, and performance).
 
hope this helps.

Posted 10-24-2007 8:26 PM by dwollerman

Comments

Links (10/25/2007) « Steve Pietrek’s SharePoint Stuff wrote Links (10/25/2007) « Steve Pietrek’s SharePoint Stuff
on 10-25-2007 7:43 PM

Pingback from  Links (10/25/2007) « Steve Pietrek’s SharePoint Stuff

Arjun wrote re: SharePoint and Managed Paths
on 12-03-2007 10:22 PM

Very well explained with practical examples too.

Just what I was looking for.

Arjun wrote re: SharePoint and Managed Paths
on 12-03-2007 10:22 PM

Very well explained with practical examples too.

Just what I was looking for.

Rob wrote re: SharePoint and Managed Paths
on 02-04-2008 8:30 AM

Question:  We have been using the explicit option in the manage paths dialog, and I wonder if we are using it correctly (fortunately we are only in Sharepoint testing phases at this point.)

We wanted to represent a global site with several branch underneath.  Then each of these branches have multiple departments.  The idea is to have the global portal as a site collection, each branch as another site collection, and then each department as either a sub-site or a site collection (depending on the number of documents they generate.)

So here is the resulting taxonomy that we were able to successfully create:

Our root is called:    \\wt\

  - We plan to use this like a worldwide HQ welcome page.

Next level represents branches (identified by country) where we created explicit paths, where we create site collections:    

\usa

\can

\mex

Then we use more explicit paths as follows, which allows us to create additional site collections for each department at each branch if we so desire:

\usa\purchasing

\usa\maintenance

\usa\administration

\can\purchasing

\can\maintenance

\can\administration

Is this approach going to create problems for us?  From what I have been hearing, we should not be able to create site-collections underneath other site collections.  But in fact, this is exactly what we are doing in this scenario.

dwollerman wrote re: SharePoint and Managed Paths
on 02-05-2008 7:25 AM

You should be ok with those managed paths. Keep in mind I believe there is a limit on the number of managed paths per web application. I think it is 255. Also, there is a performance hit I belive when you have a high number of multiple explicit paths.

Your statement related to having site collections under other site collections although it will look like this is what is happening, in fact site collections in sharepoint are not related at all. Site collections do not share in the heirarchy with other site collections.

Frank wrote re: SharePoint and Managed Paths
on 03-27-2008 2:50 PM

rob - we are looking at architecting in a very similar fashion as you, using explicit paths.  have you come across any performance degradation or other drawbacks with this method?

Bill wrote re: SharePoint and Managed Paths
on 12-03-2008 12:35 PM

thanks for your explanation -

Rita wrote re: SharePoint and Managed Paths
on 04-07-2009 9:08 AM

I used stsadm to restore a site and forgot to create the managed path first. My problem is that now it will not let me restore the site after I created the managed path. Message is nor content database is available for this operation. It tells me to create a content db but I want it in the existing content db. Is there anything I can do to remedy this problem?

Manish wrote re: SharePoint and Managed Paths
on 04-12-2009 1:31 AM

Thanks for providing this explanation.

I have also tried to explain managed path with the real scenarios and screen shot at:

manish-sharepoint.blogspot.com/.../using-managed-path-with-implicit.html

dwollerman wrote re: SharePoint and Managed Paths
on 05-10-2009 8:16 PM

Rita,

Are you able to remove the site you created with no managed path? Try removing the site. IF you can't through the web interface try using the stsadm command with a -force option. I have found that some of the commands don't explicitly call out the -force option, but it can still be used.

Harsha wrote re: SharePoint and Managed Paths
on 06-10-2009 4:23 AM

So when wildcard managed paths are used to create site collections are each site collection associated with its on content db or are all sitecollections in the same content db.. the reason i ask is bcoz by having all of them under one content db caused restore issues where if i one site collection goes down, we need to restoe the entire content db and it affects all site collections

dwollerman wrote re: SharePoint and Managed Paths
on 06-10-2009 3:03 PM

Harsha,

The managed path does not dictate what database the site collection will be part of. The idea is to keep your database growth to a manageable level. If you have lots of large site collections (25GB+) you may elect to only keep 2-4 site collections like this in a single database. My Sites for example would have low site quotas (such as 100MB) and can have 200-300 sites in a single database.

You really want to manage the database growths in conjunction with site quotas. If site quotas are not implemented you will run the risk of your database growing out of control, which is never a good thing.

I understand restoring large databases for a single site collection is somewhat of a pain. Usually a separate environment is utilzied to restore and attach the database to, which will allow you to run an stsadm -o backup on the single site collection to restore back to production. There are also third party tools such as NetApp SnapManager for SharePoint and AvePoint.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?
Need SharePoint Training? Attend a SharePoint Bootcamp!
Posts (c) their respective authors. Everything else (c) 2009 SharePoint Experts, Inc.