Understanding Hierarchy and Basic Concepts of Navigation in Microsoft Office SharePoint Server 2007/Windows SharePoint Services

Web applications are the foundation of a SharePoint Products and Technologies server farm and host the root site collection, root and subordinate webs.  SharePoint Portal Server 2003 and Windows SharePoint Services 2.0 used the term Virtual Server to designate a Web application also known as a Web site in Internet Information Services.

A root site [collection] is the term commonly applied to the what is the uppermost site collection within a server farm or otherwise referred to as the top-level site collection or alternatively portal site collection.  The root site [collection] can host any number of subordinate webs or root webs, each serving any number of subsequent webs.  A root site [collection] in Microsoft Office SharePoint Server 2007 hosts the Site Directory and Search Center webs and serves as an aggregation mechanism and provides search results through the native Search Center. 

Path-based site [collections] were traditionally known as 'team' sites, a term coined in SharePoint Team Services.  Each site can host any number of webs and subsequent webs.  Breadcrumb navigation is available in two contexts for both site [collections] and webs provided both inter and intra-site.  Intra-site breadcrumb navigation provides hierarchical navigation substance when within a site and/or web; whereas inter-site breadcrumb navigation provides hierarchical navigation relational to each site collection within a tier and can establish a connection to the root site [collection] where portal site mappings are applied and is referenced by using the 'Title' of a site [collection], web, List or Document Library.

This concept is also known as the relationship chain where each object has a parent, where a parent is not available to an object, an orphan exists and can include, site [collections], webs, Lists and Document Libraries.  So to put it into context, breadcrumb navigation can be equated to a family tree of sorts, where site [collections] reside within the same level of the relationship chain there is no genealogy or navigational reference between the two.

The image above shows both inter-site and intra-site breadcrumb navigation respectively.

Another method of structuring site [collections] within a SharePoint Products and Technologies deployments is to use managed paths as a designator to represent a logical navigation structure, as an example, a managed path 'HR' may be implement to host site [collections] and subsequent webs related to Human Resources.  Managed paths define which pieces of the URL namespace are controlled by Microsoft Windows SharePoint Services.  In Windows SharePoint Services 2.0 there were several possible options when using managed paths:

  • Explicit Inclusions:  Used if you want Windows SharePoint Services to manage a specific path, I.e. /path/, but not any paths beneath it, I.e. /path/anotherpath.

  • Explicit Exclusions:  Indicated to Include any site [collections] below the path.

  • Top-level Web site explicit inclusion:  Indicates only the root site [collection] should be handled by Windows SharePoint Services.

  • Top-level Web site wildcard inclusion:  Indicates every directory under the specified path is a Windows SharePoint Services root site [collection].

  • Exclusion:  Exclusion paths indicate a path that should not be handled by Windows SharePoint Services, in example if a Virtual Directory with the alias 'FabrikamApp' is created within a Web application through Internet Information Services, it's contents will not be managed by Windows SharePoint Services.

In Windows SharePoint Services 3.0 the implementation of managed paths has changed in comparison to previous versions, prior to implementing managed paths you should consult the Windows SharePoint Services 3.0 Technical Library at http://technet2.microsoft.com/windowsserver/WSS/en/library/700c3d60-f394-4ca9-a6d8-ab597fc3c31b1033.mspx?mfr=true.

When using managed paths as a navigation provider it is also important to understand that users requesting http://<server>/<path>/ will be presented with a 404 since no content can reside at a managed path reference.  To mitigate the server standard 404, you can develop and present a user friendly 404 using Jingmei Li's instructions at How to create your own custom 404 error page and handle redirect in SharePoint 2007 (MOSS)-.



Comments (4)

  1. To detach a Windows SharePoint Services content database – open SharePoint 3.0 Central Administration and select Application Management.  From the Application Management page, click Content databases under the SharePoint Web Application Management section – select the content database to be detached from the list of available content databases noting the database server, warning and maximum site collection values and any assigned index server and then select the Remove content database checkbox and click OK.  To reattach the content database you will select Add a content database from the Manage Content Databases page and provide the values of the removed content database captured in the steps above.

  2. Managed paths are used to define the SharePoint namespace in other words which paths SharePoint will or will not process, you will want to use Alernate Access Mappings to establish a friendlier URL.  I would recommend restoring the deleted Managed Path, detaching (SharePoint) and reattaching your content databases, then run stsadm -o execadmsvcjobs and IISRESET each Web front-end.

  3. Andrei says:

    Hi William, Thank you for your post here. I would like to ask your help if you don’t mind for one of my problem related to the “Define Managed Paths”. So the story is:

    1. I have a test SharePoint server MOSS 2007 installed as single stand alone installation on the server ”nac-sptest01”

    2. It was a Web Application created with a URL  

    3. I created a site collection on this Web Application and URL for access to my Portal site collection was  http://nac-sptest01:25417/Pages/Default.aspx

    4. Then I was looking to way to change this URL path (or add another path) to something more friendly instead of nac-sptest01:25417

    5. I went to the “Central Administration” > “Application Management” > Define Managed Paths   , … I checked the check box for the first row in the right side of the page titled “Delete selected paths” and suddenly deleted that first row:

    “(root)  —   Explicit inclusion”

    After that I can not access my Portal site collection through the browser any more by using the URL  http://nac-sptest01:25417/Pages/Default.aspx   ,    it says “http 404 error”.

    6. I tried to recreate this deleted path back (…(root)  — Explicit inclusion  ) by adding this URL as new path on the same page “Central Administration” > “Application Management” > Define Managed Paths  .  But it did not bring my site back.

    I still can see all managers options for this web application:http://nac-sptest01:25417/  on the Central Administration page, but don’t know how to solve my problem and open my Portal
    site collection on the browser. Maybe you can give an advise or any other type of help with this ? Or I need to create my portal sites collection from scratch again ? Thank you very much in advance. Andrei. My e-mail:andreich01@yahoo.com  

  4. Andrei says:

    William, thank you very much for your help with my problem, but I am a new for SharePoint and don’t know the detailed steps how to do this "detaching (SharePoint) and reattaching your content databases". Maybe, if you have time, you can give me some more details and steps how to do this. I am very much appreciate your help ! Thank you.

    Andrei (my e-mail:andreich01@yahoo.com)

Skip to main content