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.