Managed paths give Microsoft Office SharePoint Server (MOSS) 2007 administrators a powerful, yet easy mechanism for building a corporation's collaboration environment. But proper planning that includes an understanding of the needs of all business groups is crucial to the execution of a successful SharePoint design and taxonomy structure. This tip explains what managed paths are, the benefits of using them, and how to define and implement managed paths in a Microsoft SharePoint 2007 portal.
Using managed paths can help clarify the design and navigation of a Microsoft SharePoint 2007 implementation. Managed paths aren't new; this functionality was also available in SharePoint 2003. They may seem unfamiliar, however, because administrators don't always use them. This is unfortunate because managed paths are a great way to help improve the structure and usability of a SharePoint portal.
There are two types of paths that you can manage: included and excluded. When you define a managed path, you specify it in the URL namespace that will be used in a Web application. For example, using an explicit inclusion, you state that http://server_name/team is a site collection, but no site collections will exist below it. However, using a wildcard exclusion lets you specify child URLs under http://server_name/sites7/, which can be site collections.
Two different types of managed path inclusions are available in SharePoint: explicit and wildcard.
- Explicit inclusions include only the specific path you set. Use explicit inclusions if you want Windows SharePoint Services (WSS) to manage a specific path, such as /portal -- but not any sites below it, such as /portal/site.
- Wildcard inclusions encompass any sites below the path you set, so you don't have to add them individually. Use this type of inclusion for Self-Service Site Creation -- when you want users to be able to create top-level websites underneath a specific path, such as /sites.
The benefits of using managed paths
To better illustrate the benefits of using managed paths, consider a medium-sized company that's preparing to launch a new Microsoft Office SharePoint Server 2007 portal implementation. The company plans to launch a SharePoint portal with a single Web application that provides users with one "top-level" enterprise site. The site will contain corporate information, news and enterprise search.
This company also has four divisions that will contain their own portal sites with numerous sub-sites residing below them (Figure 1).
Figure 1. SharePoint portal sites and subsites.
Portal can mean different things to different people. In this case, portal is used to classify a top-level site in a site collection. It could use one of the publishing portal templates or one of the Team Site templates.
Building a SharePoint taxonomy
Building a corporate taxonomy isn't a trivial task that should be put together haphazardly. It also shouldn't be built and decided on solely by IT staff or a dedicated group handling the Microsoft SharePoint environment. This process should involve representatives from various teams throughout the corporation. But this is often overlooked, resulting in the need to restructure the environment once it goes live.
In the aforementioned example, the top site in the portal (CompanyWeb) will function as the enterprise portal site where users can obtain corporate news, enterprise search, etc. You could choose to keep this structure within the same space, or site collection, but placing each division in its own separate space will allow for a separately administered security model. It also will allow for customization that won't affect the other divisions.
To begin building your managed paths hierarchy:
- Open the SharePoint Central Administration site and enter the Application Management page.
- Select Managed Paths. If this is a new installation, you will see a screen similar to that in Figure 2. Notice that two paths are defined already. These managed paths are created automatically. To add another managed path, enter the name you want to use. For example, if you want to create one for your Human Resources Division named HR, enter that inside the Path: box.
Figure 2. The managed paths screen lets you create another managed path.
Be sure that you're working with the correct Web Application. I have seen pages with numerous paths created, but managed paths weren't showing up when a new Site Collection was created. The problem was that the user created them in the wrong Web Application.
- Specify the type of managed path (Figure 3). For example, I want HR to be listed as a top-level site that everyone can recognize and understand. The end result would be http://companyweb/HR . You would also do this for other divisions, such as IT, marketing and sales.
Figure 3. Select a wildcard inclusion or an explicit inclusion.
You aren't limited to using a single name in your namespace. You may want to bucket your organizations' structure based on other structures. For instance, I defined Administration and Development under IT. Administration may have several teams below it that require their own site collection, such as Directory Services, Help Desk and Web Admins. To facilitate this, you can create a managed path to include the Administration and Development namespaces, as shown in Figure 4.
Figure 4. Create a managed path to include specific namespaces.
Bob Fox is a Microsoft SharePoint MVP who has worked with Microsoft technologies since the mid-1990s. For the past 5 years, Bob's primary focus has been Microsoft SharePoint Services, specializing in architecture, deployment, portal and site customization, administration, and collaboration solutions. He currently works as a SharePoint Technologies Technical Lead for Lawrenceville, N.J.-based B&R Business Solutions LLC. Bob has worked for companies including Merrill Lynch, BISYS Retirement Services and Educational Testing Services, Time Warner Cable, The National Football League, Pfizer and Johnson & Johnson. Visit Bob Fox's SharePoint blog at bobfox.securespsite.com.