Departmental Deployment of SharePoint Team Services

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: February 1, 2001

Introduction

SharePoint™ Team Services enables a new way for teams to work together. By providing both Save-to-Web and collaboration features in a single package, it makes communicating ideas and sharing information easier. SharePoint Team Services contains workgroup features that create a rich environment for Web-based document collaboration and team communication. By using SharePoint Team Services, anyone can create, author, and administer ad hoc team Web sites that help a team organize and advance on a project.

SharePoint Team Services is an out-of-the-box, turnkey solution. As such, you can be up and running with a productive SharePoint Team Services-based Web site in a very short period of time. Key functionality is easy to discover, configure and customize, while also providing for flexibility for those wanting more complex configurations.

This white paper will show you how to set up SharePoint Team Services. It begins with a discussion about what you need to think about before you install SharePoint Team Services, continues with a step-by-step description of the setup process, and concludes with a discussion of the basic tasks you will need to perform to prepare for site creation. For more detailed information, see the SharePoint Team Services Administrator's Guide.

Overview of SharePoint Team Services

SharePoint Team Services is a superset of FrontPage® Server Extensions 2002 and includes all of the features available with the server extensions. In addition, SharePoint Team Services contains new workgroup features that create a rich environment for Web publishing and team communication, among other things.

SharePoint Team Services is available for the Microsoft Windows® 2000 platform. FrontPage 2002 Server Extensions are available on the Microsoft Windows NT®, Windows 2000, and UNIX platforms.

A new standard

In their initial implementation, company intranets tended to use a one-way publishing paradigm—information that the company wants to communicate to employees is put through a formal, centralized process of staging and publishing to the intranet.

While the publication paradigm is valid, and certain company information demands it, this process becomes a bottleneck for information that does not need to be handled in such a formalized manner. Additionally, such a formalized process does not take into account the needs of users or teams within the company who need to work in a more ad hoc collaborative environment and who need to share information within the team in an effective and efficient manner. For these users, the one-way publishing paradigm is neither flexible nor efficient enough to be used effectively.

SharePoint Team Services allows users to save directly to the Web in a structured and organized way so that information and documents can be shared among users in real time. Users can post drafts for collaborative purposes or a final version, depending on business needs. The publishing process itself is no longer the bottleneck.

Features of SharePoint Team Services

SharePoint Team Services lets you do the following:

Create out-of-the-box ad hoc team web sites.
Discuss and subscribe to documents.
Customize a site by adding or removing features, such as task lists or surveys.
Send invitations to the new site and allow users to begin collaborating on the site immediately.
Create document libraries to find and view documents quickly.
Create and customize powerful, interactive lists and allow each user to create customized views of lists.
Add announcements, calendar information, surveys, and other special items to the Web site via a browser-based interface.
Add users, and perform other Web administration tasks by using an easy browser-based HTML interface.
Use the rich features of Office XP™ to add new documents and edit existing documents on SharePoint Team Services sites.

Architecture

The architecture for SharePoint Team Services is based on the architecture for FrontPage 2002 Server Extensions Microsoft. The architecture also includes a database component (SQL Server or MSDE) to support features such as Lists, Web document discussions and document libraries.

SharePoint Team Services is a set of Internet Server Application Programming Interface (ISAPI) applications that run in process with the Internet Information Services Web server. SharePoint Team Services provides file and folder permissions management, hyperlink management, and maintains metadata about files in a Web site.

Communication between a client computer and a Web server running SharePoint Team Services uses the same open HTTP protocol that Web browsers on a client computer use to interact with a Web server. No file-sharing access on the Web server computer is needed, and neither FTP nor telnet access is required. No proprietary file system sharing calls are necessary to use SharePoint Team Services. For save-to-Web functionality, SharePoint Team Services allows Office XP applications to save or access files on the server via HTTP.

Pre-Deployment Considerations

Before installing SharePoint Team Services, be sure that your server meets the hardware and software requirements and that you have familiarized yourself with the other prerequisites described below.

System requirements and prerequisites

The minimum system requirements for running SharePoint Team Services on a server are as follows:

Operating System and other software	Hardware
Microsoft Windows 2000 Server, Microsoft Windows 2000 Advanced Server, or Microsoft Windows 2000 Datacenter Server with Internet Information Server 5.0 or later, including World Wide Web service, and Service Pack 2	200 MHz Intel Pentium processor Minimum: 128 MB RAM Recommended: 192 MB RAM 70 MB free hard-disk space, plus 5 MB minimum for each provisioned Web site
Microsoft Windows 2000 Professional with Internet Information Server 5.0 or later, including World Wide Web service, and Service Pack 2	200 MHz Intel Pentium processor Minimum: 64 MB RAM Recommended: 128 MB RAM 70 MB free hard-disk space, plus 5 MB minimum for each provisioned Web site

While SharePoint Team Services will function with the minimum RAM installed, it is recommended that, with average departmental usage, 192Mb of RAM be installed.

File system considerations

The security features of SharePoint Team Services require the NTFS file system. Windows 2000 includes a conversion utility (Convert.exe) you can use to convert an existing file allocation table (FAT) volume to NTFS—without losing any data.

If you install SharePoint Team Services to a FAT partition you will receive security warnings indicating that the configuration is not secure.

Database requirements

To support the list, document discussion, and document library features, SharePoint Team Services requires a database. Note that with SharePoint Team Services, each virtual server requires its own database. Supported databases are:

Microsoft SQL Server 7.0 or later
Microsoft Data Engine (MSDE) 7.0 or later (included with SharePoint Team Services)

Note: If you do not have SQL Server installed on your server, MSDE is installed automatically when you install SharePoint Team Services. If you are using the command-line interface to install SharePoint Team Services, or are using a script to run the installation, you can specify a separate server to use for your database.

Because it is easy to use and comes included with SharePoint Team Services, most departmental configurations will involve the use of MSDE. For information on using a remote SQL server with SharePoint Team Services, see the SharePoint Team Services Administrator's Guide.

Database size

There is no hard and fast rule for determining how large a database will grow relative to the size of the file share. The general ratio is that disk space taken up by documents will be about four times the size of the database. If a site's document libraries consist of 100MB of content, the database will be approximately 25MB.

This ratio is impacted by a number of things, including:

The number of docs. Because each document has metadata, ten 1MB documents will have a larger impact on the database that one 10MB document.
The level of discussions.
The level of subscriptions. You can reasonably expect that large numbers of users and large numbers of lists will lead to high subscription rates.

SQL Server account

When using a SQL server, ensure that a user account and password are available to the administrator performing the installation. If you are using the default SQL Server SA account, you should change the SA password using the SQL Server administrative tools prior to provisioning the Web site. The SA account is blank by default, but leaving it this way is a security concern.

If you will be using a remote SQL Server 2000 server as your database, there are other requirements for working with SharePoint Team Services: see Large-Scale Deployment of SharePoint Team Services for more information.

Client requirements

Any Windows-based client can use SharePoint team Web site features, providing the client runs the following software:

Microsoft Internet Explorer 4.0 or later, or Netscape Navigator 4 or later

Site locations

SharePoint Team Services installs to the system partition of the Web server. However, the sites that run using SharePoint Team Services can be anywhere on that server. If, for instance, the Web server has c:\, d:\, and e:\ partitions, the sites do not need to reside on the c:\ partition. Rather, they could be spread across the other partitions.

If you will be hosting multiple virtual servers, you will need to make sure that the virtual servers are not nested. Nested virtual servers result in broken security. A nested virtual server is one that resides below another. For instance, the second site below is nested:

Default web site - c:\inetpub\wwwroot

Virtual Web Site - c:\inetpub\wwwroot\virtual

The recommended non-nested configuration would look like the following:

Default web site - c:\inetpub\wwwroot

Virtual Web Site - c:\inetpub\virtual

Catalog locations

Index Server creates a default catalog when it is installed on Windows 2000. This default catalog is the Web catalog. SharePoint Team Services also creates an Index Server catalog that it uses for search capabilities on Web sites. The SharePoint catalog is created on the same partition as the Index Server default Web catalog. If you need the SharePoint catalog to reside on a different partition then you will need to delete the existing Web catalog and recreate it on the partition that you want the SharePoint catalog to be created. During install SharePoint will identify the new location of the Web catalog and create the SharePoint catalog on the same partition.

Architectural considerations

The simplest architecture will consist of a single server containing all necessary components:

SharePoint Team Services installation
Database (either MSDE or SQL Server)
Catalogs

Such a configuration will be ideal for relatively small departmental groups wishing to maintain their own SharePoint Team Services environments. Groups wishing to run more than 10 sites should consider using more powerful hardware and a separate SQL server, depending on the size of the sites and the databases.

Deploying SharePoint Team Services

Installing

For the purposes of this departmental level deployment guide, it will be assumed that either SQL Server is installed locally or not at all. Remember that SharePoint Team Services will detect whether SQL Server is installed locally; if it is not, SharePoint Team Services will install MSDE.

The simplest possible installation is where there is only one virtual server on the server, neither SQL Server nor the Microsoft Data Engine (MSDE) are pre-installed on the server, and there is no Web content. If there is more than one virtual server on the Web server, install SharePoint Team Services and then, after setup is complete, choose which virtual server to extend. If SQL Server or the MSDE is already installed, SharePoint Team Services will still create the required databases, but you will need to supply connection information. If Web content already exists, the user must decide whether or not to replace the existing homepage.

The following table describes the possible installation scenarios on a Windows 2000 Server.

Virtual servers	Database	Result
Single	None or MSDE already installed	Virtual server is extended and a SharePoint Team Services -based team Web site is created.
Single	SQL Server 7.0 already installed	Virtual server is not extended – use HTML Administration pages to extend the virtual server and create a SharePoint Team Services-based team Web site.
Multiple	Any database configuration	Virtual server is not extended – use HTML Administration pages to extend the virtual server and create a SharePoint Team Services-based team Web site.

To install SharePoint Team Services Team Services from the FrontPage 2002 or Office XP versions containing FrontPage 2002:

Insert the compact disc into the CD-ROM drive on your server.
Navigate to the \SharePt directory.
Double-click Setupse.exe.

Follow the steps in the Setup Wizard to install SharePoint Team Services.
The first screen prompts you for your name, Organization, and Product Key. Enter the information, and click Next.
At the next screen (shown below), read the End-User License Agreement, check I accept the terms in the License Agreement, and click Next.
Verify Installation information, and click Install.
If a homepage already exists on the server, the install program detects this and requests input from the user as to which action it should take (shown below). You can leave the existing home page and SharePoint Team Services will create a page called SharePoint.htm. To use the features and functionality of SharePoint Team Services, you must navigate from the SharePoint.htm page. However, by not overwriting the default page, it allows you to not lose your previous homepage and then later integrate design changes using FrontPage 2002 or other compatible web authoring tool. The other option is to allow SharePoint Team Services to overwrite the Default.htm page. Choose, and click Next.

When the Setup Wizard is complete, SharePoint Team Services is installed on the server.

If there is only one virtual server, the SharePoint Team Services-based home page (shown below) opens.

If there are multiple virtual servers on the Web server, the SharePoint Team Services Administrator page opens (shown below). From there the user can extend the Web site with SharePoint Team Services. This process is described in the next section.

Provisioning

Once SharePoint Team Services is installed, the virtual server(s) on that server must be extended. Extending the server is the process by which SharePoint Team Services is applied to the virtual server. This process is accomplished through the SharePoint Team Services Administration page. If the Administration page is not already open, it can be launched by clicking on Start, Programs, Administrative Tools, Microsoft SharePoint Administrator. This will start the Administration page, listing all the virtual servers on a Web server. To provision a site, click on Extend for the appropriate virtual server.

Note: If the server has a previous version of the FrontPage Server Extensions, the Office 2000 Server Extensions, or a beta installation of SharePoint Team Services, the link will say "Upgrade" instead of "Extend".

The installation defaults can be set so that all virtual servers provisioned with SharePoint Team Services will be set up according to the same configuration. To set these defaults, click on Set Installation Defaults from the Administration page (see below). Here, you can configure the default database server settings, document discussion settings, usage analysis settings, and other things.

By creating a standard configuration, the server administrator can decide what configuration would suit the majority of sites to be provisioned on the Web server. Changes to this configuration will only be necessary in the case of exceptions.

Site management

SharePoint Team Services sites allow the owner of a site to accomplish many of the day-to-day management tasks for that site. This day-to-day management does not require Web server access or the intervention of a Web server administrator; the owner of a site can administer many aspects of that site. This is advantageous insofar as a site owner does not need to rely exclusively on the Web server administrator for certain changes and it frees the Web server administrator from many day to day tasks that do not necessarily need that level of expertise.

Managing users

Every Web site has users, and part of the administrator's is to make sure to give the users of a Web site the appropriate permissions to the site. To get permissions to the site, users must be added to the site and assigned to a role.

When you create accounts for users, you assign passwords to each user. When the user logs onto the site, he can change his password. If he loses or forgets his password, he cannot look it up. However, you can reset his password.

You can manage users from the Site Administration page for your web. On your home page, click Site Settings, and then click Manage users. By using this page, you can view a list of users, check which role a user is assigned to, add new users, delete users, or assign users to roles.

The Manage Users page shows a list of all user and the roles they are assigned. To add a user:

On the Manage Users page, click Add a user.
On the Add a User page (shown below), in the User area, fill in the information about the user.

If you are adding a new user, select Add a new user with the following information, fill in the user name and password, and then confirm the password.

If you are adding an existing account, select Add a user or group name (For example, DOMAIN\name), and then fill in the username. Note that this option is only available when the domain is based on the Windows platform. This option is used to either add an existing user with a domain account to a Web or subweb, or to add an existing user with a local machine account to a subweb.
In the User Role area, select the roles you want the user to be assigned to.
Click Add User.

You can also delete users from all roles from the Manage Users page. Note that this does not delete the user account, but does remove all rights to the Web site. To delete a user from all roles:

On the Manage Users page, select the check box next to the user you want to delete.
Click Delete selected user(s) from all roles.

Note: If your site has user account limits, and you want to delete the user account rather than just removing the user from all roles, you can use the Manage Virtual Server Accounts page in the Site Administration pages for the virtual server.

To change a user's role:

Click the user name you want to change.
In the User Role section on the Edit User Role Membership page, click the new role.
Click Submit.

Working with role Levels

Roles are the privileges granted to users on a SharePoint Team Services site. By default there are five roles available on a SharePoint Team Services Web:

Browser - Has rights to view pages, view Web document discussions, and read lists.
Contributor – Has Browser rights, plus rights to participate in Web document discussions and subscribe to documents and lists. This role is named "collab" on the command line.
Author – Has Contributor rights, plus rights to edit pages and directories, and edit lists.
Advanced Author – Has Author rights, plus rights to define and apply themes and borders, link style sheets, and recalculate a web. This role is named "advauthor" on the command line.
Administrator – Has all rights from other roles, plus rights to configure roles, create local machine user accounts, manage source control, create subwebs, manage Web document discussions and subscriptions, manage server health, and manage usage analysis. This role is named "admin" on the command line.

All of these roles are per-Web in scope. So, the administrators in this list are Web site administrators. To perform some administrative tasks that affect settings for all webs and virtual servers on the server computer, you must be both a Web site administrator and an administrator for the server computer (also known as machine or "box" administrators).

Note: For a complete lists of user rights and to see which are included in each role by default, see the User Rights worksheet in the OwsCmdLn.XLS spreadsheet.

It may be the case that a site manager wants to grant higher levels of access in certain areas to trusted users, but not necessarily all the rights of a particular role. An example of this might be where the site manager wants to delegate usage analysis to a user. However, she does not want to give that user full administrator privileges. In this case, the site manager can create a new role (see below).

To create a new role, the site manager can navigate to the Manage Roles page by clicking on Site Settings from the home page, then clicking on Go to site administration, Manage Roles. A list of all roles on that site is displayed. To add a role:

Click on Add a role.
On the Add a role page, name the role, provide a description, and select the rights from a detailed list of available options. When the Manage Usage Analysis box is selected, any necessary down level rights for that role are automatically selected as well.

Multiple role membership

Users can be members of more than one role, so you do not need to remove their old roles before adding them to a new one. Neither do you have to replicate all of their existing rights in the new role.

Inviting users to a site

As mentioned above, there are two methods of adding users to a site. Invitation is the second method. By using this method, the site administrator can both add a user to the site and inform that user of the site's existence (or the fact that the user was added). To invite users to a site, the site manager can navigate to the Send an Invitation Wizard by clicking on Site settings, Send an invitation. The wizard consists of four steps:

Entering the e-mail address of the user to be added.
Verifying all added accounts.
Adding a personal greeting, if desired.
Choosing a role for the user(s).

Each added user is sent an invitation, which includes the greeting, the user id, and a password for accessing the site. After users receive the invitation, they can access the site and change their passwords (recommended).

Setting Usage Analysis

If you want to know what kind of impact your Web site has, you need to track how many users visit your site, the type and number of hits your site receives, and other site-usage information. SharePoint Team Services includes features that analyze usage of your site, providing information such as:

Total hits on a site
Total unique hits on a site
Top page by hits
Most popular browsers
Top referring site
Hits per page

The usage reports rely on a plain-text log file, generated by the Web server on which the Web site is hosted, which keeps a distilled record of every transaction on your Web site. When you create a usage report in a SharePoint Team Services-compatible Web page editor, such as FrontPage 2002, the data from the log file is arranged into a readable format.

Note that usage data is collected for an entire virtual server at a time, even if you have separate Webs on a virtual server.

Although you view these reports from within a SharePoint Team Services-compatible Web page editor, such as FrontPage, you administer the settings for processing the usage log with SharePoint Team Services commands. You can control:

Whether the usage data is generated.

If you do not want to use the usage analysis features, you can turn off the usage analysis log to conserve hard disk space (although the log files themselves are not large). If you decide that you do want to use these features, you can turn the log processing on again. Note that each time the log file is processed, the data is appended to the original log. If you want to conserve disk space, you should turn off usage analysis before it has been run the first time.
When the usage log is processed.

You can schedule the usage log to be generated at a convenient downtime for your Web. If internal employees primarily use the Web, for example, you might schedule the log to be processed at night, when demand on the site is lower than during working hours. You can schedule the log to be processed on a daily, weekly, or monthly basis, depending on how closely you want to track your site's usage. If you only run usage reports once a month, you can process the log once a month. If you want to know how your site is being used every day, you can set the log to be processed daily.
How long usage data is stored.

You can store usage data indefinitely. However, unless you are running long-term usage studies, you probably do not need to store that much data. You can specify that usage analysis data be automatically deleted after a certain number of months.
Whether to use 24-hour increments in the log file.

If you use this option, data is accumulated for full days only. For example, if you process the usage log at 12:35 A.M. on Friday, the data is processed through midnight on Thursday. If you turn off this option, all hits are processed right up to the time set for processing. In this case, usage processing contains all hits up until 12:35 A.M. on Friday. The data in the log file determines the data used for the usage reports. Choose the 24-hour increments option if you prefer a cleaner usage report, with data for full days only.

To configure usage analysis, click on Site Settings, Go to Site Administration, Configure Usage Analysis Settings. At this page (shown below), the site manager can turn analysis on or off, choose if the analysis should be run on a daily, weekly or monthly basis, and if or when the data should be deleted. Additionally, the site manager or her designate can be notified by e-mail when the analysis has been run.

Once the analysis has been configured, the site manager or her designate can view the reports using FrontPage 2002 (see below). Reports include usage summaries on a daily, weekly, or monthly basis, page hits, visiting users, operating systems, browsers, referring domains and URLs, and search strings.

Server health

Web sites, especially SharePoint Team Web sites, undergo many changes each day. This high level of change creates potential server problems. SharePoint Team Services includes functionality that helps you detect and repair common server problems when they arise.

When you check your server's health, you can perform several functions either individually or all at once. You can also choose whether to be notified of problems, or to have the problems automatically corrected. Server health checks are performed for an entire virtual server at one time. You must be an administrator of the virtual server, or have the Manage Server Health right to run a server health check.

During a server health check, you can choose to:

Synchronize the database (SharePoint Team Services only).

This check ensures that database information matches that of the SharePoint team Web site file system. If content is added to a web when the database is offline, the metadata for the content may not be added to the database. As a result, the database becomes unsynchronized with your Web's content—a problem that can occur in other ways, as well. Because many SharePoint Team Services operations rely on data in the database, you want the database to accurately reflect your Web content. You can synchronize the database with the metadata during a server health check.
Verify existence of webs.

This check verifies whether the subwebs on a root web exist in the file structure. It looks through the services.cnf file in the root web to find which subwebs should exist, and then checks the file system to see if it does. If a directory or subweb does not exist, and you specify that you want to fix this problem, the services.cnf file is updated to reflect the fact that the subweb does not exist or that the folder is not a subweb. This process is repeated for each subweb of the root web.

Note that this is not always a safe operation to repair. For example, if you have a subweb that is stored on a network file share, rather than locally, if the network is temporarily unavailable, this check will report that the subweb does not exist. If you then repair the problem, the subweb will be deleted from the root web's list.
Check roles configuration.

Ensures that user role settings can be enforced. This check detects and repairs possible problems with roles, including the following: a user record has an invalid format, the user has a record in the list of users, but no matching user account, the user record refers to a non-existent role, there is no role for the anonymous user, and so on.
Reapply file system security.

This option looks at the user and roles permissions you have created for your Web site, and then applies those settings to the file system. There is no detect portion to this server health check; there is only the repair process.
Tighten security.

This check ensures that all the necessary Web site files and directories are present, and that only users with the proper permissions have access to them.
Check anonymous authoring.

FrontPage 2000 Server Extensions did not support anonymous authoring of a web. With SharePoint Team Services, you can use anonymous authoring of your site if you want. This option checks the anonymous user access rights for your Web sites and all subwebs to ensure that anonymous users don't have the right to modify any content.

To check server health:

On your Web site, click Site Settings, and then under Web Administration, click Go to Site Administration.
In the Server Health area, click Check server health (see below).
In the Detect and Repair area, select the Detect and Repair check boxes for any server health actions you want to perform.

If you only want to check for problems, but not fix them, do not select the Repair check box for that action.
Click OK.

Clicking OK accepts your settings and performs the server health check. After the server health check runs, you can view the results from the Server Health Report page. If you want to run additional health checks, you can do so from the Server Health Report page. Just select the Fix this problem check box for any actions you want to perform, and then click Submit.

Creating subwebs

The site manager of a SharePoint Team Services based team site has the capability to create subwebs. To create a subweb:

From the home page, click on Site Settings, and click Create a subweb.

This brings up the Create a Subweb page (shown below), where the site manager inputs the name of the subweb, whether it should inherit the permissions from its parent Web or have unique permissions, and if it should be a SharePoint Team Services site or a blank Web site.

Depending on the purpose of the subweb, the site manager can decide to inherit permissions or establish a subweb with unique permissions. When creating a subweb that has unique permissions, the site manager must designate a site owner for that subweb – just as the site manager is the site owner of the parent Web. When a subweb has unique permissions, users must be explicitly added to that Web, even if they have permissions on the parent. The same users may have differing permissions on a parent Web and a subweb. For instance, an advanced author on the parent Web might be the administrator of the subweb.

As opposed to creating a subweb with unique permissions, a subweb might inherit permissions from the parent Web. If this is the case, all users will have the same rights as on the parent Web. However, it is possible to change the permissions of a subweb after it has been created. If, for instance, it is decided after the fact that a subweb which is inheriting permissions should really have unique permissions, the permissions can be changed. They must be changed by an administrator.

When permissions are altered from inherited to unique, they are unique only from that point on. That is to say that all users from the parent Web are listed as users on the subweb, with the same permissions. However, their roles can be altered, they can be deleted, and users can now be added who do not have access to the parent Web. If a subweb is going to have a number of users who also have access to the parent, with only a few role changes, creating a site which inherits permissions, and then modifying those permissions is the most efficient way to accomplish this goal. It will then take only a little bit of effort to modify the roles and delete unnecessary users. This is especially helpful when there are a large number of users.

Maintaining Your SharePoint Team Services Environment

Site settings

Site settings can be changed from or reset to the default settings if the site manager finds that they are not suitable for activity levels of a Web site. The Site Administration page (Site Settings, Go to Site Administration) is the page that allows the site manager to administer all aspects of their site that can be administered. If the site manager finds that more discussions are occurring on documents than she originally anticipated, she can change the setting to automatically delete stored discussions after a certain period of time. If necessary, that time can later be lessened or increased. Further, automatic deletion of usage analysis data can be initiated or modified.

Additionally, SharePoint Team Services provides built-in source control and can also work with Microsoft Visual SourceSafe™ for Windows (VSS) 5.0 or later source control. This will require that anyone who is editing pages check those pages in and out. To apply version control, click on Site Settings, go to Site Administration, and click Configure Version Control. One can then choose to use built-in version control. With either source-control method enabled, authors can use commands in a SharePoint Team Services-compatible Web page editor, such as Microsoft FrontPage 2002 to check pages and other files in and out of a SharePoint Team Services-based Web.

With Visual SourceSafe control enabled, authors benefit from advanced functionality such as tracking and storing changes to each file, reviewing a file's history, and returning to earlier versions of a file. For more information about setting up version control functionality, see the SharePoint Team Services Administrator's Guide.

Discussions

You can administer Web document discussions on a per-virtual server basis only, not per subweb. This is because Web document discussion data is stored in the database, and there is only one database for each virtual server. The greater the number of subwebs created on a virtual server, the larger the likelihood that a high numbers of discussions will take place. It is therefore incumbent on the site manager (or her designate) to keep a handle on the number of discussions as well as how long stored discussions are maintained. To view the current discussions on a virtual server, as well as their locations, click on Site Settings, Go to Site Administration, Manage discussions. This will bring up a listing of all discussions currently on the virtual server, with a link to the discussion and the number of entries for that discussion noted.

The site administrator can configure discussions so that after a certain amount of time, stored discussions are automatically deleted. If the volume of discussions on the server is high, the automatic deletions can be set for a shorter amount of time.

Roles

When a site is first provisioned, the five rolls described above will probably fulfill the needs of the site manager. However, by their very nature, Web sites are evolutionary and are sure to grow. The site manager may need to begin to designate trusted team members to handle certain tasks on the Web site. Such tasks might be to manage usage analysis or to manage discussions. To support this need, SharePoint Team Services allows custom roles to be created. By creating custom roles, the site manager can delegate site management responsibility across a team.

Subwebs

Subwebs can be created from any Web. It is possible to have many levels of nested Webs. Therefore, it is a good practice for a site manager to run reports on a regular basis to ascertain the level of use across the entire site. If a site is inactive for a long period of time, the site manager should consider the possibility of deleting it. If there is content located on that subweb that is still relevant, it might be migrated to the parent Web. If the subweb was created as a blank Website, the site manager can merge the subweb into the parent Web.

Note: Subwebs with lists and document libraries cannot be merged using the merge subweb feature of SharePoint Team Services. The error is:

Cannot convert the Web <subwebname> into a folder because it contains lists, surveys, discussion boards, or document libraries. Please delete these and try again.

To merge a subweb, the child Web must be using the same permissions as the parent Web. If it is not, you will receive the following error:

Unable to convert the Web /Webname into a directory because it does not use the same permissions as its parent Web.

To fix this, open the child Web in FrontPage 2002, on the Tools menu, choose Server/Permissions, and then click Change permissions.

To merge a subweb, click on Site Settings in the SharePoint team web site interface, Go to Site Administration, and click Merge a Subweb. This will convert the subweb into a directory of the parent Web. All documents and the structure of that subweb are kept within the new directory. For instance, if there is a subweb named Payroll off of the parent Web of Human Resources, and within that subweb there are various documents and folders, the subweb Payroll is now a directory in the Human Resources Web. Whatever structure existed within what used to be the subweb is maintained in the directory.

Conclusion

This paper has introduced the key aspects of deploying SharePoint Team Services in a departmental environment. For more detailed information on any aspect of installation, configuration, or management, see the SharePoint Team Services Administrator's Guide.