• Sidebar: Choosing Between WSS and SPS
• Sidebar: The SPS 2003 Developer Story
• Sidebar: Migration from SPS 2001 Difficult
• Chart: SPS Terminology and Concept Changes
• Illustration: SPS 2003 Scalability
• Illustration: Categories Help Classification, Navigation

SharePoint Portal Server, Microsoft’s product for hosting corporate portals, is getting a major makeover. Now in beta and expected in late summer of 2003, SharePoint Portal Server (SPS) 2003 is built on Windows SharePoint Services (WSS) and, by taking advantage of WSS’s .NET technologies and the underlying SQL Server database, it scales much better than its predecessor, SPS 2001. However, the radical design changes will orphan the "Web Parts" built for SPS 2001, and the new product requires Windows 2003.

Although the term corporate portal is broad, it frequently means an intranet or extranet (an external Web site accessible only to authorized users) that provides a single, well-organized starting point for the corporate information and applications needed by a particular user or group. Ideally, a corporate portal provides quick access to any resource a particular user needs to get work done, be it a document on a file server, a "self-service" front end to the human resources system, a report generated from a company's enterprise resource planning (ERP) or customer relationship management (CRM) system, or traffic information from a public Web site. (For more on how SPS and WSS fit into Microsoft’s portal and collaboration strategy, see "Choosing Between WSS and SPS".)

Built on Windows SharePoint Services

SPS 2003 runs on top of WSS, the successor to SharePoint Team Services (STS). WSS will ship as a free add-on for Windows Server 2003 and is designed to host "team sites." (For information on WSS, see "Windows SharePoint Services Supports Office Collaboration".)

Unlike SPS 2001 and STS, which were based on completely separate technologies, SPS 2003 has been radically redesigned so that many of its functions are built on the WSS architecture. (Some of the terminology used to describe SPS features has also radically changed because of this dependency— for details, see the chart "SPS Terminology and Concept Changes".)

Just as Internet Information Services (IIS) 6.0, ASP.NET, and SQL Server together form the platform for WSS, WSS in turn provides the platform for SPS 2003. Although the two products are distinctly different, SPS 2003 leverages the WSS architecture and adds a set of additional Web Parts, a Web-based administrative interface, and some additional SQL databases that store data particular to SPS. It also provides some additional intermediate business-tier logic, such as index and search engines. (For a graphical overview of the shared architecture, see the illustration "SharePoint Technology Stack".)

The common architecture of the two products gives SPS 2003 the following benefits:

Uses ASP.NET Web Parts. WSS now supports Web Parts—modular ASP.NET server controls that allow nonprogrammers to select those parts meeting their specific needs and assemble them into a customized Web interface. Unlike the older ASP-based Digital Dashboard Web Parts used by SPS 2001, the new Web Parts gain the security and performance benefits of the .NET Framework and are easier to develop using Visual Studio .NET. Furthermore, ISVs building aftermarket Web Parts do not have to use different technologies to support both SPS and WSS. SPS includes many more Web Parts than come standard with WSS; the additional Web Parts provide SPS-specific functions such as advanced search or navigational controls.

Because the product is based on radically different technology than SPS 2001, migration to SPS 2003 could involve significant difficulties (For more information, see the sidebar "Migration from SPS 2001 Difficult").

SQL Server storage. WSS stores all team content, such as documents, lists, and calendars, in a SQL Server or Microsoft Data Engine (MSDE) database. Similarly, SPS 2003 stores all of its portal content, including the content indexes used by SPS’ search functions, in SQL Server or MSDE databases. This separation of content into a distinct back-end data tier allows SPS to use SQL Server clusters, partition its databases over multiple SQL Servers, or use SQL Server’s built-in recoverability features. Furthermore, any third-party SharePoint backup and recovery tools should work with both WSS and SPS.

The WSS architecture enables SPS 2003 to scale to extremely large portal sites. SPS 2001 had some serious scalability problems that prevented it from fulfilling the corporate portal role for larger organizations. SPS 2003 can use farms of front-end Web servers, multiple back-end database servers, and separate farms of index and search servers to support extremely large processing loads, allowing it to store millions of documents and index tens of millions of other content sources. (For a graphical diagram of SPS 2003’s scalability options, see "SPS 2003 Scalability".)

Unified document management. Because WSS now provides many more document management capabilities (namely the check-out/check-in, versioning, and extended attribute support, formerly provided by SPS 2001), SPS 2003 can index and search documents stored in document libraries on either WSS or SPS sites using the same access methods.

Common object, security, and event models. Web Parts and other applications can now access WSS or SPS functions using the same .NET object model, which means that developers can use the same techniques to develop for both products. (For more on SPS 2003’s developer support, see the sidebar "The SPS 2003 Developer Story".) WSS supports a role-based security model that maps Active Directory (AD) users and groups to preconfigured sets of permissions that determine who can perform various actions; SPS uses the same underlying security mechanism, although SPS supports more granular access controls. WSS also provides an event engine for detecting changes to sites and taking actions, such as sending notifications or other alerts to subscribers when a new item or document is listed, and SPS takes advantage of this same facility.

Clearer functional separation, consolidation of Microsoft effort. Now that SPS 2003 is built on WSS and adds a set of distinct functions, much of the confusion over the preceding products’ overlapping areas of functionality has been eliminated. However, because of the shared architecture, Microsoft can concentrate its efforts on improving one core set of technologies rather than two. This should result in better stability and performance than had the two products remained entirely separate from each other. It also means consolidation of client-side code development. Office 2003 will contain many built-in links to WSS functionality (see "How WSS Integrates with Office 2003"), which gives Office 2003 users access to portal documents using the same task pane used to access WSS documents, reducing the learning curve for users and eliminating the need to install SPS-specific Office extensions.

Categories Now Determine Site Structure, Security

In SPS 2001, "categories" provide a hierarchical method for classifying, organizing, describing, finding, and browsing documents. This offers greater flexibility than a folder system (which essentially supports organization only on a single attribute) and improves search accuracy. An administrator can define any number of levels within the category structure, and documents may belong to multiple categories or even to a parent and child category at the same time.

In SPS 2003, this capability is retained, but categories are also reflected in a portion of the site structure itself. That is, there is a Web page dedicated to each category. All portal items coded with a category, including documents, news items, and people, will appear as links on that category page, even though the item may be stored in a different part of the site or as external content. (For more on categories, see the illustration "Categories Help Classification, Navigation".)

Using the WSS security model, SPS supports assignment of AD user and group accounts to various "roles" in each category. Once a site administrator has assigned one or more users to the "category manager" role, those individuals can manage all further role assignments. Category managers can also configure the category to require their approval before any content shows up in that category.

As with SPS 2001, the new version includes a Category Assistant that can be "trained" from a sample of hand-categorized documents to automatically categorize documents imported in bulk into SPS.

Search Improvements

SPS 2003 provides a service that can crawl many different types of content, index their text and any metadata associated with them, and allow users to find them using the SPS search engine. Although this may seem straightforward at first glance, "content" exists in many file and data formats, requires different protocols to access it, and must support multiple languages, each with its own rules on how to parse sentences and identify the root forms of words, while ignoring junk words such as "and" and "the."

SPS 2003 uses the same basic indexing and index update technology as SPS 2001, but adds support for the following:

• Crawling content stored in SQL Server and STS databases
• Crawling Web sites encoded using the Secure Sockets Layer (SSL) protocol
• Reading Microsoft Publisher, Visio, and XML files
• Reading Czech, Finnish, Hungarian, and Portuguese text.

Support for Personalization

New to SPS 2003 is support for personalization. Unlike SPS 2001, which uses identity only for determining access permissions, SPS 2003 leverages identity information to create detailed user profiles of individuals in an organization, to allow users to create personal portal sites, and to allow portal managers to tailor content views to particular audiences.

User Profiles

User profiles provide portal users with detailed information about other individuals in the organization, such as their manager or telephone number, and serve as the basis for other personalization features. These user profiles can not only serve as a company directory and expose AD information to anyone with a browser and permissions to access the portal but can also be used to organize and list documents and other portal items related to individual users.

Although profiles can be created manually, administrators will in most cases create them by importing user information from AD. SPS 2003 includes a scheduler that keeps users’ profiles automatically synchronized with AD. (This synchronization is one-way; changes made to SPS 2003 profiles do not get replicated back to AD.)

Organizations that customized their AD schema with additional user attributes, such as employee numbers, can create additional SPS profile fields and map those custom AD user attributes to them.

Personal Sites

With SPS 2003, each user with a profile can create a personal portal site and store documents, links to other content, and other types of information, such as lists, alerts, and pictures, on it. Each site has a private view, and the user can opt to expose some information in a public view, meaning that it is indexed by the search engine and available for others to view.

Users can customize personal sites by using Web Part templates that allow them to create document libraries, picture libraries, lists of various types, and discussions without any coding. Users can even create additional child Web pages in their personal site.

Because personal sites can contain private document libraries, they can conceivably become more powerful replacements for server-based home directories. However, until Microsoft adds true offline access to SPS similar to the way that Windows "offline folders" work today, SPS 2003’s lack of offline support will present problems for laptop users who must have access to their documents while disconnected. Until then, mobile users must remember to move documents they will need to access while disconnected from their personal document library onto their local hard drive or into an offline folder (which automatically caches a local copy on the hard drive).

Audiences

New to SPS 2003, "audiences" are special SPS groups that can be targeted with specific information by portal content managers. Various items can show up or be hidden on both shared portal pages and personal sites, depending on the user’s audience membership.

Unlike membership in SPS’s roles, audience membership is automatically calculated on a recurring basis and can be based on more fine-grained criteria than just simple membership in AD security groups; audiences can also be based on matches with any properties in the SPS 2003 user profile, including the identity of their manager (as determined by their "reports to" relationship in AD). By default, all content is initially assigned to a built-in audience called "all portal users."

Application Integration

Applications can be integrated with SPS 2003 in two different directions: customized SPS Web Parts can use Web services or ADO.NET to link to the applications or their data sources, or applications can call certain specific SPS 2003 services, such as its search functions, using Web services.

SPS and WSS both support the same core Web Parts–based application integration technologies. However, SPS 2003 comes with an important new feature—single sign-on (SSO)—that could make SPS a better choice for application integration in certain instances. Because SPS 2003 can now store personal information for each user, its SSO feature also allows it to securely store various application-level log-on credentials for each user.

For example, if a human resources system requires its own log-on credentials, a Web Part that provides access to that system could automatically pass the appropriate user credentials based on the Windows log-on of the SPS 2003 user. However, the SPS 2003 SSO feature has no provision for keeping application accounts and passwords synchronized with the SSO credential storage. For example, if the application enforces a periodic password change, users would have to update their SSO credential storage with the changed value.

Web Parts are intended to use Web services to communicate directly with back-end applications. However, until more applications expose their functions as Web services, developers will need some intermediary code to translate native application APIs into Web services. One way to do this is to use BizTalk Server in conjunction with the BizTalk Adapter for Web Services and BizTalk adapters, which are available for many popular server-based and mainframe-based business applications. This combination makes it relatively easy to build Web service "wrappers" around those applications and link Web Parts to them.

However, if organizations want to use SPS 2003’s SSO functionality in conjunction with BizTalk, they will need to download the SharePoint Single Sign-on Component for BizTalk. Moreover, this component will only work with third-party BizTalk adapters that are designed to use the SPS 2003 SSO functionality, such as Actional’s Peoplesoft, SAP, or Siebel adapters.

Limitations Remain

Despite the many improvements in SPS 2003, some serious limitations remain:

Centralized architecture only. Even though SPS 2003 can now scale to support very large sites, it is based on a centralized server-farm architecture rather than a geographically distributed server architecture. Because SPS 2003 does not have database replication support, a portal cannot be replicated to different WAN sites to serve users there locally (similar to the way Exchange can replicate Public Folders to geographically separated sites). Furthermore, it does not support distributed indexing, so remote indexing servers cannot crawl content on remote LANs and then consolidate the partial indexes back into a master index.

These architectural limitations mean that an organization’s WAN capabilities could effectively limit portal scalability—all remote SPS 2003 users must traverse slower WAN links to reach the portal site, and SPS must repeatedly download content from over the WAN just to maintain its indexes, potentially saturating WAN links.

No MOM application pack. Microsoft’s new systems management philosophy calls for each server product group to produce a specific Microsoft Operations Manager (MOM) application pack for its product; these packs are used to monitor and manage those applications from a central MOM console. However, based on the current beta, it appears that SPS 2003 will not come with a MOM application pack, nor has Microsoft announced any plans to ship one later.

No more publication workflow support. SPS 2001 provides a means for defining approval processes for publishing content to the portal. However, now that SPS relies on WSS to provide document management functionality, much of the workflow capability in SPS 2001 has been lost: all that remains is the ability for category owners to require documents to be first approved before they may be listed in that category.

Microsoft says that structured publication workflow is more relevant to more carefully structured and managed Web sites, and recommends that customers use Content Management Server (CMS) 2002 for this kind of functionality.

However, Microsoft has stated that it plans to release an integration pack similar to the current pack that links SPS 2001 and CMS 2002. Thus, CMS may be the appropriate starting point for the top levels of large corporate portals in which a small number of writers publish information in a carefully controlled and structured way to a large, uniform readership; customers could then use the integration pack to link the top-level CMS portal directly to one or more SPS portals, allowing SPS to index CMS-based content and return links to it in searches. (For background on the current version of the integration pack, see "Linking Content Management Server to SharePoint" on page 7 of the July 2002 Update.)

Primitive native backup and restore tools. Moving WSS and SPS to a shared architecture based on SQL Server should make system backup much easier (as the state of the entire site can be captured at once) and will ultimately provide better restore options. However, SPS 2003’s built-in backup and restore tools are primitive. SPS 2003 comes with a graphical backup and restore utility that backs up the SQL databases of one or more sites or entire servers to a file, which can then be copied to tape during the regular backup. However, this utility has no scheduler and can only restore the whole portal site and index databases, either overwriting the current ones or restoring the backup to an alternate server. There is no way to recover individual items, particularly documents.

Because of the new architecture, existing third-party SPS 2001 backup and restore tools from vendors such as CommVault and Veritas won’t work with SPS 2003. However, most current SPS 2001 backup vendors plan to make upgrades available after SPS 2003 ships. Ideally, these will be able to exploit SQL Server’s ability to work with the Windows Server 2003 Volume Shadow Copy service, which will make frequent backups much more practical and restores much faster.

Software Requirements Could Make SPS 2003 Expensive

In addition to the cost of upgrading third-party SPS Web Parts and backup/restore utilities, SPS 2003 will also have Microsoft software requirements that could drive up the purchase cost high enough to give organizations pause. Organizations will have to calculate the impact of these requirements based on the provisions of their Microsoft volume licensing agreements.

Windows Server 2003 required. SPS 2003 requires Windows Server 2003, which means new server licenses and Windows Server 2003 Client Access Licenses (CALs) for all clients that must access the portal (except for users that connect anonymously, typically only useful for outward-facing portal sites).

SQL Server may be required. Although SPS 2003 can use MSDE for simple single-server portal sites (the version of MSDE that ships with it will not have the previous version's 2GB storage limit or connection throttling), any site that needs multiple servers must use SQL Server 2000, Service Pack 3. This will entail SQL Server licenses, which run approximately US$4,700 per CPU for Standard Edition and US$18,800 per CPU for Enterprise Edition.

User experience best on Office 2003. As with WSS, users will have the best experience with SPS 2003 when using Office 2003. For example, Office 2003 applications have a task pane that allows users to check documents in and out of SharePoint document libraries. Thus, organizations may need to factor in the licensing and deployment costs of upgrading to Office 2003 when considering SPS 2003.

SharePoint CALs likely. SPS 2001 requires each user to have an SPS CAL, either through a standalone CAL or via the "Core CAL" (which also includes CALs for Exchange, SMS, and Windows). Although Microsoft has not yet announced licensing or pricing for SPS 2003, it’s doubtful that Microsoft will upset this pricing structure and the revenue that comes from it. However, because WSS is provided free with Windows Server 2003 and much of SPS 2001’s functionality has been moved into WSS, customers will have to evaluate whether SPS 2003’s added value justifies the cost of the server software plus CALs, which are currently about US$70 for SPS 2001. (Microsoft has said that it plans to continue offering an External Connector client license for non-employee SPS users.)

Availability and Resources

SPS 2003 is expected to ship in late summer or early fall, concurrent with the release of Office 2003. (See "Office 2003 Delayed".)

For more on SPS 2003, see www.microsoft.com/sharepoint/preview/default.asp.

For more on portals and the specific needs addressed by SPS, see "Tahoe Brings Document Management to the Masses" on page 3 of the Dec. 2000 Update and "Corporate Portal Strategy in Flux" on page 3 of the Nov. 2001 Update.

To download the SPS 2003 SDK, see msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001891.

To download the BizTalk Adapter for Web Services, see www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4DD298A4-C42E-42C5-94D7-9D564DF29F3B.