Microsoft SharePoint Portal Server 2001 (formerly code-named Tahoe) is a departmental portal server that delivers basic document management and workflow features bundled with a strong search engine. The product also offers reasonably tight integration with Microsoft Office XP, Office 2000, and Web browsers, especially Microsoft Internet Explorer (IE) 5.0 or later.
SharePoint Portal Server is easy to install, but installation is only the start of the journey. The final destination depends on how well you manage the product's implementation within your enterprise. When you begin to consider the nuts and bolts of this task, many questions spring to mind. How will SharePoint Portal Server fit into your existing infrastructure? What's the most efficient way to organize documents on the server? What do you need to do to help users reap the maximum benefits from the product? What should you do with your existing network file shares? What types of information can you index, and from what sources? What do you need to deploy portals and clients?
Knowing the answers to these questions before you deploy SharePoint Portal Server can help you get the most out of the product. The discussion in this article assumes that you're familiar with basic SharePoint Portal Server terminology and features. For more basic information about the product, see "Microsoft SharePoint Portal Server," June 15, 2001, InstantDoc ID 20935.
SharePoint Portal Server doesn't depend on Active Directory (AD). You must install SharePoint Portal Server on a Windows 2000 Server or Win2K Advanced Server with Service Pack 1 (SP1) or later, but that system can be part of a Windows NT infrastructure. A Win2K or NT domain controller (DC) can provide the necessary user authentication and security model for the current version of SharePoint Portal Server. (Future versions, however, might demand a Win2K infrastructure so that the product can leverage the OS's more advanced features.)
The product also functions independently of Microsoft Exchange Server. A technological connection to Exchange exists in that both products use the same database engine (known as the SharePoint Portal Server Store in this product), but this connection doesn't create a dependency. In fact, you should avoid installing both server products on the same system. (See "Exchange 2000 and SharePoint Portal Server," December 2001, InstantDoc ID 22949 for details about this restriction.)
Within the Store, SharePoint Portal Server uses one database pair, which consists of a message database (MDB) file and a streaming store (STM) file. The MDB file holds document properties (i.e., metadata), and the STM holds document content. You might assume that the MDB file will be smaller than the STM file, but that isn't the case. (Think of the database as storing documents in rows, with one row for each version of a document. Content aggregation is a primary function of SharePoint Portal Server, and much of this content comes from external sources that maintain the content in situ. In such cases, SharePoint Portal Server imports only metadata—not content.)
The product uses the same transaction-logging model as AD and Exchange use. To restrict disk space, SharePoint Portal Server employs circular logging.
After you've installed SharePoint Portal Server, you're ready to create workspaces. At the time of this writing, Microsoft recommends that you have no more than 10 workspaces per SharePoint Portal Server system. The product is new enough, though, that such guidelines might change quickly. Keep an eye on the product's home page (http://www.microsoft.com/sharepointportalserver.asp) for evolving information and guidelines.
Several factors influence the number of workspaces you should create for your environment. These factors include
- the number of users who will connect to the server to add, edit, or approve documents
- the number of users who will connect to the server to read documents
- the number of documents that you plan to manage on the server
- the number of external content sources that the server will index
The best idea is to start small and grow in a supervised manner. Each workspace is a separate portal, so don't create a new workspace unless you have a good reason—a new category inside an existing workspace might be sufficient to meet your needs. To help you organize data within your workspaces, SharePoint Portal Server provides two logical divisions: folders and categories.
Documents reside in folders within the SharePoint Portal Server Store. A document can belong to only one folder and automatically inherits the folder's approval requirements and security set. For example, you can create an Articles folder and require all documents in that folder to go through an approval process before being published. Approvals can be serial (i.e., each reviewer approves the document, then passes it to the next reviewer) or parallel (i.e., multiple reviewers can approve the document simultaneously). The approval mechanism is simple but can handle most department-level review requirements.
SharePoint Portal Server uses roles to control access to information. Each role is a set of permissions that determines how a user can work with the documents in a folder or workspace. Three roles are available: Reader, Author, and Coordinator. You can't create custom roles or change a role's predefined set of access rights.
The Reader role lets users view published documents. Readers can't see a document that other users have checked out or that isn't fully published. The Author role lets users create and edit documents. Authors can check out and modify a document. Coordinators can allocate roles to other users and can set workspace policy. A Coordinator can decide which document profiles a folder uses and whether documents require approval before being published.
You assign roles to user accounts or groups. The accounts can be from any domain as long as a trust relationship exists between that domain and the domain in which you've installed SharePoint Portal Server. SharePoint Portal Server uses domain logon authentication to determine a user's role. In other words, the product uses Windows user credentials (e.g., ADOMAIN\AUSER) to set up roles, then checks those credentials whenever a user attempts to perform an operation (e.g., check out a document).
A category is a subsection of a workspace that provides a logical division of information within the SharePoint Portal Server Store; you can create and use a category to contain documents with a specific relationship. For example, Figure 1 shows a workspace, Microsoft Technologies Portal, that contains eight categories; each category holds information relating to a specific technology. A document can belong to multiple categories.
Help Users Find Data
Users can take out subscriptions to information in which they're interested. A user can subscribe to a document to receive a notification when someone updates that document. Users more commonly subscribe to a category, meaning that the user wants to receive a notification when someone publishes a new document or updates an existing document in that category. Figure 2 shows a subscription notification, which is an SMTP message. (You don't need to connect the SharePoint Portal Server system to an email server to send notifications. You need only to ensure that SMTP traffic can flow between the SharePoint Portal Server system and your email systems.)
After you add a document to the SharePoint Portal Server Store, you can access the document's Properties dialog box (through Windows Explorer) and update the document's properties, as Figure 3 shows, to assign the document to one or more categories. When the document is published, SharePoint Portal Server determines whether any users have subscribed to the document's category, then sends those users a notification that the document is available. As Figure 3 also shows, you can also make the document a Best Bet for a category. SharePoint Portal Server then returns the document as a top item when a user searches for documents in that category.
The purpose of subscriptions is to let users know when information is added to or changed in a specific category or document. However, subscriptions can fulfill this purpose only when you maintain accurate category information. You might be tempted simply to dump a lot of documents into the SharePoint Portal Server Store, but if you don't update the documents' properties to create metadata and assign categories, users won't be able to find the documents easily. In that case, SharePoint Portal Server has the potential to become an enormous wastebasket. To keep the Store organized and to simplify the process of finding information, assign someone to be a content manager—to control how documents are stored, organized, and categorized. The work that this task will involve will vary enormously from installation to installation and is highly dependent on the number of document-management operations your enterprise generates. If your site publishes hundreds of documents each week, the content manager is going to have a full-time job. On the other hand, if you publish only 10 or 20 documents each week, the content manager probably will need to spend no more than one day each week to control publishing.
Profiles provide another way to help users find specific types of documents. A profile is a collection of properties that Authors and Coordinators can associate with a document to specify which document properties SharePoint Portal Server will store in its metadata. You can use profiles to distinguish documents according to format (e.g., Microsoft Word, Excel, PowerPoint), subject, or author.
More usefully, though, you can use profiles to distinguish a document in terms of its content. For example, a white paper is different from a project plan. Users might want to search for white papers according to publication date, whereas they might want to search for project plans according to project manager. To help users, you can create a profile to describe a white paper—specifying such properties as Authorized By and Publication Date, and another profile to describe a project plan—including such properties as Project Name and Project Manager. When Authors and Coordinators associate the appropriate profile with a document, SharePoint Portal Server stores the specified properties and lets users carry out searches against them. Therefore, a user could quickly find all documents that specify a certain project manager.
Replacing Network File Shares
When you've created your workspaces and defined your categories, you're ready to add content. One of SharePoint Portal Server's primary attractions is its ability to replace the crude storage mechanism that network file shares provide with an indexed and searchable repository that incorporates basic document-management features. But what should you do with your existing file shares: migrate the content, or leave it in the file share and simply index it? To decide how to handle existing file shares and how to store and manage content going forward, review your active file shares and answer the following questions for each:
- Is the file share operational?
- Who manages the file share?
- What content does the file share hold, and is that content still useful?
- How would you move the content?
- To which workspace would you move the content, and which categories would you assign it to?
The answers to these questions should help you decide whether the effort required to transfer documents will be worthwhile. You should move and categorize the content of any file share that is in day-to-day use by a group of people who collaborate to author and publish documents.
Moving content isn't simple—at least not when you do so correctly and completely. The first step is easy enough: Connect to the file share and to the workspace, then drag all the documents from the file share to the appropriate folder in the workspace. (To perform this operation, you need Read permission on the file share and you need to hold the Author or Coordinator role for the workspace.) You might want to move documents in batches of 100 or fewer, or this task will progress slowly.
When you import documents into the workspace, SharePoint Portal Server sets the documents' status as checked out and makes them available only to you (or another Coordinator). Therefore, you need to check in and publish each document before it's available to users. As SharePoint Portal Server imports the documents, it captures basic metadata (e.g., author, title) from the documents' OLE properties, assuming that the original authors provided that information. However, you shouldn't attempt to save time by relying on the basic metadata. You need to review each document during the publication process and update the document's properties to describe it as accurately as possible ( e.g., set keywords on a document, change its profile, add version comments, make it a Best Bet). This task is an important part of ensuring that SharePoint Portal Server delivers accurate and valuable content to users when they search for information. This process is likely to take 5 to 10 minutes per document if you know the content well and could take 15 minutes if you need to open the document (to verify its content and compose the metadata).
Moving documents into the SharePoint Portal Server Store lets you refine content, discarding outdated or unwanted information and tidying up other content to make it more useful. However, the effort involved in migrating hundreds of documents is often too great to justify the end result. Migrating content from a file share that holds thousands of documents that no one accesses or updates probably would be a waste of time. Instead, you can treat the network share as an archive and tell SharePoint Portal Server to create an index of all the information in the share.
Indexing the content in a network file share realizes about 90 percent of the benefits you'd gain by moving that content into the SharePoint Portal Server Store. When users select an item from a SharePoint Portal Server index, the item opens in their browsers through an interface similar to Microsoft Outlook Web Access (OWA) 2000. Although you don't get the benefits of SharePoint Portal Server's document-management features, users will still be able to find content more easily than without an index. And adding a network share as a new content source to a SharePoint Portal Server workspace takes less than 5 minutes. The SharePoint Portal Server software development kit (SDK) provides tools that you can use to develop automated processes to add files to the Store. These tools aren't off-the-shelf solutions, though; you need to do a substantial amount of development work to create a reliable and robust tool that can take documents from a file share, import them into SharePoint Portal Server, and perform all the necessary categorization and metadata population.
Apart from indexing network shares, you can index external and internal Web sites, other SharePoint Portal Server systems, Exchange 2000 Server and Exchange Server 5.5 public folders, and Lotus Notes databases. SharePoint Portal Server provides the Add Content Source Wizard to simplify the process. You tell the wizard from where and when to fetch information, and SharePoint Portal Server's indexing agent does the rest. You can configure incremental or full updates according to a schedule, or an administrator can launch updates manually. (The options for starting an index are in a context-sensitive menu that appears when you right-click a content source in Windows Explorer.)
You can index only the initial page of a Web site, or you can follow and index all the links from that page. You can apply filters to prevent SharePoint Portal Server from attempting to index files that aren't suitable for an index (e.g., the graphic files on Web pages).
Exchange 2000 includes a modified version of the same search engine that SharePoint Portal Server uses, so SharePoint Portal Server can index Exchange 2000 and Exchange 5.5 public folders. As Figure 4 shows, you can use the Add Content Source Wizard to set up a feed from a public folder on an Exchange 2000 server. You can elect to index only the target folder or to include subfolders. (You can specify which account to use to access and index a public folder, but if you need to do so, ask yourself whether indexing that folder is wise. If the folder isn't fully accessible to the public, perhaps you shouldn't index it.)
SharePoint Portal Server does a magnificent job of indexing even large public folders. For example, many companies use public folders to host subscriptions to Internet mailing lists, which generate substantial message traffic. Searching such large public folders without an index is an exercise in patience. You can create a full-text index of such sources to provide a far more pleasant experience. (Of course, you have no control over information you index from any external sources that you don't manage.)
When you index a content source, SharePoint Portal Server generates a log that includes full details of any errors that occur. The product's Content Sources window contains a link to the log. Indexing a public folder usually returns far fewer errors than indexing a Web site does. (Web site indexing returns numerous errors for outdated URLs, whereas most public-folder indexing errors are the result of encrypted messages.)
The aim of deploying SharePoint Portal Server is to create a portal—a centralized place for users to find information. Users might not appreciate all the work that goes into creating a portal, but they'll enjoy quick and easy access to information.
Figure 5 shows a finished portal with a complete underlying workspace, defined categories and folders, published documents, populated indexes from different content sources, subscribers, announcements, news items, and quick links. This portal includes some additional touches: A graphic for the team that operates the portal replaces the default heading, and a custom Web Part at the bottom of the screen lists the most recently published documents in the workspace. The SharePoint Portal Server portal consists of Web Parts that comply with Microsoft's digital dashboard standard, so you can combine the product's standard Web Parts with inhouse or third-party Web Parts to build the best portal for your users. For information about some of the options to consider when building portals, see the SharePoint Portal Server home page.
Users who want only to access the information on a SharePoint Portal Server system can do so through a Web browser. IE 5.0 or later is Microsoft's preferred version and delivers the best user experience because it supports protocols such as XML, WWW Distributed Authoring and Versioning (WebDAV), and Extensible Stylesheet Language (XSL). You can use other browsers, but the SharePoint Portal Server UI won't be as rich.
Authors and Coordinators need to use the SharePoint Portal Server client, which extends Windows Explorer with SharePoint Portal Server options and which you can install on Windows XP, Win2K, NT, Windows Me, and Windows 98 workstations. (You can't install the client on Win95 systems.) SharePoint Portal Server extensions are also available for Office XP and Office 2000. Collectively, these extensions let users create and manage (e.g., check in, check out, approve to publish) documents in the SharePoint Portal Server Store.
Microsoft released SharePoint Portal Server SP1 in late 2001. Like other Microsoft service packs, SP1 is a clean-up release that addresses known problems that have appeared since SharePoint Portal Server's initial release. Apart from delivering bug fixes, SP1 provides a useful performance increase: Better digital dashboardcaching and Web Partcaching algorithms make SharePoint Portal Server more scalable, especially when many clients connect to a server. For this reason alone, I recommend you upgrade to SP1 as soon as you can.
Wrap It Up
SharePoint Portal Server certainly simplifies the process of getting a departmental portal up and running. In most cases, you can install the product and begin indexing content within 2 hours (including the time necessary to install Win2K, upgrade to Win2K SP1 or—preferably—SP2, and connect the server to the network). SharePoint Portal Server depends on Microsoft IIS, so you also need to run the IIS LockDown tool on the server and install any postservice pack Win2K hotfixes.
SharePoint Portal Server's ability to aggregate data from a variety of sources, its comprehensive search engine, and its ready-to-go portal provide users with a wealth of information—with a minimum of effort on your part. With proper planning and implementation, you can exploit the product's basic advantages—especially those inherent in its document-management features—to deliver even more value. SharePoint Portal Server marks the beginning of the end of network file shares—which I, for one, won't miss.