Making Sense of SharePoint Portal Server Architecture

Microsoft SharePoint Portal Server builds on Windows SharePoint Services' ability to create team sites by letting you construct a central portal that comprises several different types of sites, links the individual team sites, and lets users share information across them. If you're responsible for implementing and administering your organization's SharePoint Portal Server project, to ensure the project's success you'll need to be familiar with SharePoint essentials: the basic architecture of a SharePoint portal, SharePoint portal area permissions, portal listings, Web Parts, and how to manage the information that's shared through the portal. I'll start here by explaining key aspects of SharePoint's portal architecture—in particular, portal listings and how you can use them to flatten your SharePoint site's navigation structure and aggregate and display information consistently across portal areas. Then, in the upcoming part two of this article, I'll delve into more detail about the visual elements of SharePoint, such as Web Parts, and how to use them to build a SharePoint site's UI. (If you're just beginning the planning phase of your portal, see the sidebar "Planning Your SharePoint Portal," for some planning guidelines.)

SharePoint Architecture
If you're new to SharePoint Portal Server portal design, you'll need to know the following key terms.

Site. A SharePoint site is a Web site that's enabled by SharePoint Web Parts and Windows ASP.NET–based components and contains collaborative content (e.g., documents, discussion groups) for a team. (For more information about SharePoint sites, see the sidebar "Types of SharePoint Sites" in "Making Sense of SharePoint Search," September 2006, InstantDoc ID 50623.)

Portal area. A portal area is generally a special type of one-page, self-contained site that SharePoint Portal Server controls. Multiple portal areas comprise a site. Portal areas are created in a manner that will produce a hierarchical navigation structure (i.e., by using a taxonomy). Generally, administrators and subject matter experts create portal areas. So, for example, the administrator might create a top-level portal area for the HR department, then permit a named individual in HR to create subareas such as Compensation, Vacation, and Procedures.

Each portal area contains various information containers, such as document libraries, lists, and portal listings, which are geared toward the users of that portal area. An individual portal area can maintain only one portal-listing list. (I discuss lists and listings in more detail in the Portal Listings section.) You can target a portal area to specific audiences (an audience is a custom group who can view specific content targeted to that group) who will view the content in that area and set permissions to limit portal-area access to certain users. You can also designate a portal area as hidden from navigation (regardless of the permission settings for that area) as well as whether or not it—and its content—are searchable.

In addition to serving as a site that includes the information containers mentioned earlier, a SharePoint Portal Server portal area can itself be an information container. By placing a Content Editor Web Part on a portal area, you enable that area to become an information container. (I'll discuss Web Parts and other visual elements in SharePoint in part two of this article.)

Document libraries and lists. If you've worked with Windows SharePoint Services, you should be familiar with document libraries and lists. Document libraries and lists are the foundation for maintaining information, such as Microsoft Office files, links, contacts, events, issues, and tasks, on a SharePoint site. A document library contains a collection of documents shared with SharePoint site members. A list is an element of a SharePoint site that contains a collection of items that aren't documents, such as contacts or tasks. (For more information about document libraries, see "Office 2003 and SharePoint: Better Together," December 2004, InstantDoc ID 44156.) Lists are a powerful component of SharePoint and include many features for maintaining fields in a list, such as text, Rich Text Format (RTF), drop-down lists, lookups from other lists, and calculations (e.g., sum, total).

Portal-Area Permissions
Permissions for SharePoint Portal Server and its associated content are less granular than permissions in Windows SharePoint Services. The granularity of permissions derives from the manner in which Microsoft designed each product to be used. Windows SharePoint Services is designed as a secure collaborative environment for managing "work in progress." SharePoint Portal Server is designed to manage published content and provide a single UI containing a holistic view of aggregate information specific to the current user's need—that is, a portal. Portal users have an unlimited view of and access to the portal area, whereas on a Windows SharePoint Services team site, only team members can access the site.

In SharePoint Portal Server, you define portal-area permissions for the portal area itself, and all content associated with that area assumes the same permissions. You set portal-area permissions via the standard Manage Users option that's available for any administrator of a team site or portal area. You can't set specific permissions on a document library or list as you can in Windows SharePoint Services.

Permissions are an important consideration when designing your information structures and determining where they will be physically located. Because permissions are at the portal-area level, you need to be careful when deciding what content goes into what portal area, since anyone who has write access to the portal area will have write access to all content in that portal area. Therefore, you might want to look at your content and group it together by access permission—for example, a portal area for all content that's readable and a portal area for content that's writeable.

You might be tempted to try to circumvent SharePoint Portal Server permissions. For example, some SharePoint administrators have used an unsupported technique published on the Internet that lets you manage the permissions of a specific document library or list within a portal area—that is, it lets you give a list a different set of permissions than those of the portal area. I strongly recommend that you avoid such unorthodox solutions because they can have unpredictable results and Microsoft doesn't support them.