• Illustration: SharePoint Technology Stack
• Illustration: New Document Workspace
• Illustration: New Meeting Workspace
• Sidebar: How WSS Integrates with Office 2003
• Illustration: WSS Task Pane in an Office Application

Windows SharePoint Services (WSS), the successor to SharePoint Team Services (STS) and a free add-on for Windows Server 2003, makes it easier to create and customize team sites—specialized intranet sites for team and project information. When combined with Office 2003, WSS supports common team-based activities such as document collaboration and meeting facilitation. While improved collaboration and easier development and deployment of team sites may entice customers to upgrade to Windows Server 2003 and Office 2003, server and site proliferation could cause administrative headaches for IT planners.

Goal of WSS: Easy Team Collaboration

The combination of WSS and Office 2003 is Microsoft’s latest attempt to position Office as a tool for team collaboration. Earlier attempts date back to the Office Server Extensions introduced with Office 2000.

The center of WSS-based collaboration is the team site, an intranet Web site that provides a central repository of team information. Although it is possible to navigate and browse team sites with a Web client like Internet Explorer (IE), team members can interact with the team site while working within Office applications in other useful ways. For example, users can use Outlook to add important events posted on a team site to their calendars, or view information related to a particular document (such as a discussion thread) while editing the document in Word.

A WSS team site consists of a set of ASP.NET pages for site administration (such as creating sites and adding and deleting users), and a set of team pages that allow workers to view and manipulate the actual team data. The team pages are made up of Web Parts—modular ASP.NET-based Web components that display information (e.g., contacts) and allow users to take action (e.g., adding a contact), and that greatly simplify creation and customization of sites. WSS ships with a collection of Web Parts, from simple image-display components to more complex components for managing document libraries.

Today, information workers typically collaborate by sharing documents on a file server. Microsoft intends that the WSS team site replaces the file share as the base unit of currency for team collaboration. By giving away WSS, emphasizing the team site as the center of team activities, and making it trivially easy to create, customize, and manage those sites, Microsoft hopes to lower resistance to adopting the product.

Finally, users must have Office 2003 to reap the full benefits of WSS. For example, although it is possible to open team site documents with Office 2000 or Office XP, contextual information related to that document (such as the discussion thread mentioned above) is not visible. Microsoft intends that broad adoption of WSS and positioning Office 2003 (combined with WSS) as a key ingredient for increasing team worker productivity, rather than a set of standalone document authoring tools, will lead customers to upgrade to Office 2003. (For details on how WSS and Office 2003 work together, see the sidebar "How WSS Integrates with Office 2003".)

Better Collaboration Features

Although STS offered features intended to support team collaboration, the product found favor mainly with organizations looking to build static information portals for small groups. WSS puts more emphasis on collaboration scenarios, offering new and improved features designed to help workers perform common team activities, such as group editing of documents and preparing and planning meetings.

Document Management

WSS users manage documents through a document library component, the WSS analog of the file share.

In contrast with STS, which lacked version control and mimicked document check-in/out by marking documents read-only, the WSS document library supports both version control and check-in/check-out. If users specify versioning, WSS automatically creates a backup copy of a file whenever it is saved. The file check-in and check-out capabilities let users lock files while editing so they cannot be overwritten by other users.

In addition, whereas STS supported only non-hierarchical document storage, WSS allows document libraries to contain subfolders, allowing users to better control the structure and organization of libraries in a way that is analogous to subfolders in the Windows file system.

WSS also improves the way users are notified of changes in documents. In STS, users could configure an alert to be sent when a change was made in a document library, but could not specify alerts on individual files. WSS allows users to configure notifications at the individual document level.

List Creation and Management

WSS improves STS’s list creation and management capabilities, utilities that give team members and administrators a simple way to build and post structured information lists that are relevant to team members, such as announcements, contacts, tasks (to-do list items), or special events.

WSS ships with a set of predefined list types and corresponding data fields—for example, the Tasks list contains fields for priority, status, owner, and description. One notable addition is the Issues list, which can be used to track and maintain history on specific problems (such as unresolved questions related to a customer complaint). Team members can also create their own custom list types and define the fields for those types.

List management has also been improved: for example, users can now apply permissions to lists to prevent unauthorized changes, and administrators can build list templates from existing lists to help enforce a common look across multiple team sites.

Better Search

Search capabilities have been dramatically enhanced in WSS, improving the ability of users to access potentially important information quickly, such as assigned tasks, team contacts, or team announcements.

In STS, search was based on Internet Information Server (IIS) catalogs and was limited to searching documents on the file system. It did not search through content stored in databases, such as task lists or contacts. In WSS, search is based on SQL Server full-text searching. Since all site information (including documents) is now stored in a database, WSS can search the contents of both documents and lists.

Workspaces

WSS introduces the concept of workspaces, team sites based on predefined templates that are designed to be a central collection point for information about a specific activity.

WSS offers two canned workspaces, the Document Workspace and the Meeting Workspace, for two of the most common business activities: collaborative document authoring and meeting organization.

Document Workspaces. The Document Workspace is meant to facilitate team collaboration on a document or set of documents. When a team member or administrator creates a Document Workspace, WSS generates a new site that contains a new document library and a set of default Web Part components. (See the illustration "New Document Workspace".) These components provide a central location for storing information relevant to a document collaboration project (e.g., research notes) and assigning and tracking task-oriented activities (such as chapter or section editing).

Meeting Workspaces. The Meeting Workspace can be used for planning and organizing meetings and publishing and tracking information for meeting follow-up. WSS supplies several templates for different kinds of meetings: for example, the Basic Meeting Workspace contains list components for objectives and attendee contact information, while the Decision Meeting Workspace adds a document library and lists for tasks and decisions. (See the illustration "New Meeting Workspace".) These workspaces offer a convenient way to gather and share pre-meeting material and to publish decisions or results afterward.

As is the case with other WSS sites, a user can customize a Document or Meeting Workspace by adding other Web Parts to the pages of the workspace.

Improved Administration

Compared with STS, WSS sites are easier to create and maintain, and IT departments can more easily manage the overall WSS infrastructure.

In general, team sites are administered by team administrators, who can add members to their sites and assign them to site groups—special membership categories in WSS that dictate what a given team member can do (e.g., a site Contributor can add subsites beneath the top-level team site, while site Readers cannot). WSS also offers a set of Web pages called WSS Central Administration for IT departments to set up the basic team server infrastructure—for example, creating top-level team sites and assigning owners to those sites.

Important changes in the product’s administrative functions include the following:

Site creation and customization. With STS, only a local or domain administrator could create sites. WSS allows any team member that belongs to the appropriate WSS site group to create and customize sites without involving the site owner or the IT department.

Address book integration. Team members and administrators are able to browse an organization’s address book, for example, in Active Directory, from within WSS, and select users from that address book to add to a team site or workspace, allowing them to quickly build membership lists.

Controlling site proliferation. WSS allows central administrators (e.g., IT staff) to limit the amount of storage used by a specific team site or site owner and can generate alerts when quotas are reached or when a site is inactive for some period of time. This gives central administrators some ability to control disk usage on a team server and manage the runaway site proliferation that may result from the fast and easy site creation provided by WSS. However, once the ability to create sites is delegated, there is no way to control the number of sites created or to alert administrators based on the number of sites on a server.

Backup and restore. STS was able to back up and restore top-level team sites and all subsites, but was not able to operate selectively on subsites. With WSS, subsites can be individually backed up and restored, which should help IT administrators selectively identify and remove obsolete sites, and restore those sites if needed.

Additionally, while STS offered backup, scheduled backup, and restore of the SQL Server or Microsoft Data Engine (MSDE) database where lists and document properties were stored, the operation was not integrated with backup and restore of STS documents on the file system, increasing the complexity of keeping these sets of data synchronized. WSS removes this complexity by storing all administrative data and site content in SQL Server.

Security. WSS lets IT administrators block specific document types from being stored in a document library to prevent team servers being overloaded with extraneous data, such as MP3 digital audio files, or with potentially damaging files, such as executable (EXE) files.

Infrastructure Overhaul

WSS is a major architectural overhaul of STS that relies on a new technology foundation (ASP.NET) and subsumes much of the technology and functionality formerly provided by SharePoint Portal Server (SPS) 2001, Microsoft’s solution for building corporate portals. (Microsoft will release a new version of SPS at the same time as WSS; for more details, see "SharePoint Portal Server Radically Redesigned".)

For example, the document management functions and Web Parts technology that were formerly exclusive to SPS now reside in WSS. By moving this technology downstream, Microsoft builds a common collaboration platform for corporate and team portals and improves the usefulness of WSS as a collaboration tool. (See the illustration "SharePoint Technology Stack".)

Although Microsoft provides a utility to move STS sites to WSS, some STS sites will need to be manually restructured in order to work with WSS. For example, because WSS blocks the use of ASP pages that are not part of the WSS installation, STS sites with custom ASP pages will need to be altered to work with WSS.

The most notable architectural changes between STS and WSS are as follows:

WSS sites are based on templates. To make site creation quicker and easier, WSS provides templates (made up of predefined collections of Web Parts) for common types of sites, such as team sites and Document and Meeting Workspaces. When administrators create a site based on the team-site template, for example, a top-level Web page is generated that contains the announcement, events, links, and site image Web Parts. Users and team administrators can then customize these sites by dragging and dropping additional Web Parts onto the page, configuring and customizing those parts as needed. Team administrators can save site templates based on customized sites for later reuse.

SQL-based data storage. WSS is more scalable and reliable because it uses SQL Server as the underlying data store for site content and administrative information.

STS used the Windows file system for document storage, which physically tied document-based content to the Web server and created single points of failure. Using SQL Server for all data storage separates content from the Web server logically and allows site builders to physically scale Web servers independently of content servers. For example, IT personnel can add Web servers to access common content on a SQL server as demand for that content grows, and they can also load-balance those Web servers to increase site availability.

WSS is based on ASP.NET and IIS 6.0. Underlying WSS is Microsoft's ASP.NET and IIS 6.0 Web server. By allowing applications to run in isolated Web server processes, IIS 6.0 offers improved fault tolerance compared with older versions. ASP.NET also offers important advantages over the previous Active Server Pages (ASP) technology, such as faster execution, better security, and easier development of Web Parts. (For more information on ASP.NET, see the Feb. 2002 Research Report, "The .NET Development Platform.")

In addition, WSS servers, sites, and site contents are exposed by object models that give developers a way to programmatically access and extend WSS capabilities. The object models are ASP.NET based, allowing developers to build custom Web applications or to customize Web Parts in the Visual Studio .NET integrated development environment (IDE).

This technology environment presents opportunities for some partners. Since the release of the second beta of Office 2003, which included WSS, Microsoft has tried to whip up interest among ISV partners by emphasizing the ease of Web Part development, the extensibility of the platform, and the free availability of the WSS technology. For ISVs developing Web Parts and value-add extensions to WSS or Office, a freely available platform could greatly increase their target audience. For Microsoft’s part, a large body of compelling Web Parts—for example, components that facilitate workflow—should increase interest in both Windows 2003 and Office 2003.

Limitations, Concerns, and Futures

WSS is essentially a ground-up rewrite of STS, built on new technology (ASP.NET and Web Parts) and encompassing functionality previously included in SPS. Thus customers may expect a level of product immaturity.

In addition, prospective customers should consider the following limitations and concerns when evaluating WSS:

Different work model. Having struggled with previous attempts at an Office-centric collaboration paradigm, Microsoft may face an uphill battle convincing customers to take advantage of the work models implicit in the WSS-Office 2003 system, which may create resistance to adopting WSS.

For example, the Meeting Workspace may prove useful for arranging large, complex meetings with detailed agendas and background materials or recurring project meetings with fixed agendas that focus on issue tracking. It may, however, be overkill for the majority of less complex meetings with simpler agendas and a small number of invitees or ad-hoc meetings between colleagues. For such meetings, the existing features in Outlook are perfectly adequate.

Site navigation. WSS provides limited ability for users to view and traverse overall team site hierarchy. Although all team sites and pages have an explicit link to the site one level above them, and users can navigate to a page that lists sites and workspaces one level below, a team site does not contain links to all subsites below it. The most direct path to a Meeting Workspace, for example, is to click the link included in the meeting request sent when the workspace was created. This could prove frustrating for team members who want to view meeting minutes or action items, but were either not invited to the meeting or declined and deleted the original meeting request.

Controlling site proliferation. Once the base server infrastructure is in place, concepts like the workspace make creating team sites trivially easy. (Microsoft itself has more than 20,000 internal STS sites.) Because of this, IT departments may see a runaway proliferation of short-lived, unmaintained sites. Although WSS provides tools, such as site quotas and inactive-site notification, to help the IT manager control site growth, the limited site navigation capabilities may make this challenging for administrators.

For example, while it is possible to delete a team site and all related subsites, it is not possible to view overall site hierarchy (e.g., in a view like the tree control used to visualize directory structure on a file server) and then selectively delete blocks of sites from that hierarchy. It will take active management by both IT and team administrators to ensure that quotas are not quickly filled by obsolete or extraneous sites and data, thereby blocking other legitimate site uses.

For organizations with widespread team site growth, Office SharePoint Portal Server 2003 (SPS 2003) may be the answer. SPS 2003 is designed to give an administrator or IT manager greater control of large numbers of team sites and potential associated problems, such as runaway site proliferation. For example, site navigation and visibility is improved with the SPS site directory, which can give administrators a structured view of all team sites in a WSS installation. Unlike WSS, however, SPS is not a free product.

MSDE limitations. Although it is possible to use WSS to build simple sites by installing it with the (free) MSDE option, WSS functionality will be limited. For example, MSDE does not include tools for backing up and restoring the database (although Microsoft has said it will remove the 2GB storage limit on the version of MSDE included with WSS).

Furthermore, in this configuration WSS cannot search team sites. To implement search with WSS, customers must have SQL Server or SPS 2003. Even with SQL Server, however, there are still limitations—for example, it is not possible to do cross-site searching or search other stores, such as exchange or files shares. Thus, to build more complex team infrastructures that support many users and enterprise-wide search capabilities, larger customers will want to consider SPS 2003.

Availability and Resources

WSS is slated for release sometime in the summer of 2003 and will be a free add-on for customers of Windows Server 2003. The server running WSS must be configured as a Web server (running IIS 6.0 in worker process isolation mode) and running ASP.NET.

Windows, Macintosh, and UNIX clients running IE 5.01 or later (IE 5.2 or later for Macintosh), or Navigator 6.2 or later can browse and use features on WSS sites.

For more information on WSS, see www.microsoft.com/sharepoint/preview/default.asp.

More information on Office 2003 can be found at www.microsoft.com/office/preview/default.asp.