Large-Scale 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

There is a wealth of information available on installing and configuring SharePoint™ Team Services from Microsoft®. The intention of this white paper is to gather the most pertinent information from those sources and combine it with sound recommendations for how to deploy SharePoint Team Services in a large-scale hosting environment.

Companies that provide hosting for multiple customers or teams have some unique configuration requirements for SharePoint Team Services. This paper discusses the advantages of using SQL Server™ over Microsoft Data Engine (MSDE) in a large-scale hosting environment and how to use the Self-service Site Creation (SSC) tool. It also provides tips such as how to maximize performance by editing the Registry when hosting a large number of Websites and users on a server.

This paper is not meant to be an exhaustive step-by-step instruction manual – the SharePoint Team Services Administrator's Guide provides that detail. Rather, it is meant to help you understand how SharePoint Team Services fits into your environment so that you can optimize performance and avoid pitfalls.

For more detailed information on SharePoint Team Services, see SharePoint Team Services Administrator's Guide. For detailed information on the FrontPage® Server Extensions 2002, see the FrontPage 2002 Server Extensions Resource Kit.

Overview of SharePoint Team Services

SharePoint Team Services provides both Web publishing and collaboration features to make communicating ideas and sharing information easier. 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 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 provided by SharePoint Team Services

SharePoint Team Services provides very compelling functionality. Users of SharePoint Team Services will be able to:

Use the rich features of Microsoft Office XP™ to add new documents and edit existing documents.
Post any document to a SharePoint team Web site using only a Web browser.
Discuss and subscribe to documents on the SharePoint team Web site.
Customize a SharePoint team Web site by adding or removing features, such as task lists or surveys.
Send invitations for the new site or allow users to sign up for the site automatically.
Create document libraries so they can find and view documents quickly.
Create and customize team lists and allow each user to create customized views of the list.
Add announcements, calendar information, surveys, and other special items to the Web site.
Add other users and perform Web administration tasks by using an easy Browser based-interface.
Secure team Web sites and grant authoring, browsing, site management, or other user rights to authenticated users.
Analyze site usage to find out who is viewing the site and how often.

Features for large-scale providers

SharePoint Team Services was designed with two basic deployment scenarios in mind:

Departmental deployment, in which user uses SharePoint Team Services as an out-of-the box collaboration solution, installed on a single server for a defined group of users. Here, the focus is on ease of administration from the users' perspective and on functionality.
Large-scale deployment, in which SharePoint Team Services is provided as a service for many customers. Here, the focus is the Administrative perspective.

SharePoint Team Services provides a number of tools for large-scale providers to make deployment and management easier in this second scenario. These include the ability to:

Manage Web sites either on the local server or remotely by using browser-based Administration pages or a comprehensive command-line interface.
Customize and automate SharePoint Team Services deployment with Quiet Mode.
Track errors on the server to help prevent site or server crashes.
Grant users the ability to provision their own sites using the Self-service Site Creation (SSC) wizard.
Modify cache settings to improve performance.
Set quotas on sites to manage the number of users.
Specify which rights are available to be assigned to roles and users.

SharePoint Team Services architecture

The architecture for SharePoint Team Services is based on the architecture for FrontPage 2002 Server Extensions from Microsoft. The architecture also includes a database component (SQL Server or MSDE) to support new features such as Web document discussions and document libraries. Note that the architecture of FrontPage 2002 Server Extensions is not significantly changed from that of the FrontPage Server Extensions 2000.

FrontPage Server Extensions architecture

The FrontPage client communicates with FrontPage Server Extensions using HTTP, the same protocol Web browsers and Web servers use to communicate. FrontPage initiates a remote procedure call on top of the HTTP POST request, so that the FrontPage client can request documents, update the Tasks list, add new authors, and so on.

The Web server sees POST requests addressed to the FrontPage Server Extensions and the Common Gateway Interface (CGI) programs and directs those requests accordingly. FrontPage correctly communicates between client and server through proxy servers (firewalls).

SharePoint Team Services architectural differences

SharePoint Team Services uses a database to provide functionality beyond what the FrontPage Server Extensions provide. Also keep in mind that SharePoint Team Services does not follow the "create and then publish" model you may be used to with FrontPage Server Extensions. The moment you create a SharePoint team Web site it is live on the server; you do not need to publish the team Web site to another server. Users can still edit the team Web site in a SharePoint Team Services–compatible Web page editor, such as FrontPage 2002, or add pages and documents to the site, but they do not need to publish their changes — they take effect immediately when they save the files.

The following diagram illustrates the SharePoint Team Services architecture in action.

Note that although a few features require Microsoft Internet Explorer (such as importing a spreadsheet, which uses ActiveX® components), all content returned to the client computer is HTML.

Pre-Deployment Considerations

System requirements and prerequisites

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

Hardware and software requirements

Hardware requirements vary depending on which version of Windows 2000 you use. The following table describes the hardware requirements for the supported operating systems.

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	200 MHz Intel Pentium processor Minimum: 128 MB RAM Recommended: 192 MB RAM 70 MB free hard-disk space, plus 4 MB minimum for each provisioned Web site
Microsoft Windows 2000 Professional with Internet Information Server 5.0 or later, including World Wide Web service	200 MHz Intel Pentium processor Minimum: 64 MB RAM Recommended: 128 MB RAM 70 MB free hard-disk space, plus 4 MB minimum for each provisioned Web site

Note: The security features of SharePoint team Web sites require the NTFS file system. Microsoft Windows 2000 includes a conversion utility (Convert.exe) that you can use to convert an existing file allocation table (FAT) volume to NTFS — without losing data.

Database requirements

To support the 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.

It is recommended that large-scale providers use a dedicated SQL Server configuration. This is described in more detail in the next section.

Client requirements

Any Windows, Macintosh, or UNIX 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

Security and user roles

SharePoint Team Services rely on the security features of Microsoft Windows 2000 to provide security for Web site content. There are two elements in Windows security:

User authentication — the process used to validate the user account that is attempting to gain access to a Web site or network resource.
User authorization – based on SharePoint Team Services user roles, you do not have to control the file and folder permissions separately, or worry about keeping your local groups synchronized with your list of Web users. You use roles to give users permissions on your team Web site, and use SharePoint Team Services administration tools to add new users directly. For more information about user roles, see "Managing Roles" in the SharePoint Team Services Administrator's Guide.

User authentication

When you use SharePoint Team Services, user authentication is based on Internet Information Services (IIS) authentication methods. IIS provides five forms of user authentication:

Anonymous authentication
Basic authentication
Integrated Windows authentication
Digest Access authentication
Certificate authentication

You choose the authentication method you want to use when you set up your Web server. You cannot change the authentication method by using the SharePoint Team Services administration tools; you must use the IIS administration tool for your server computer to change the authentication method.

Anonymous authentication

Anonymous authentication provides access to users who do not have Windows 2000 server accounts on the server computer (for example, Web site visitors). IIS creates the anonymous account for Web services, IUSR_computername. When IIS receives an anonymous request, it impersonates the anonymous account. An issue with this is that the server cannot specifically identify users, so, for example, surveys may not function as desired.

Basic authentication

Basic authentication is an authentication protocol supported by most Web servers and browsers. Although Basic authentication transmits user names and passwords in easily decoded clear text, it has some advantages over more secure authentication methods, in that it works through a proxy server firewall and ensures that a Web site is accessible by almost any Web browser. If you use Basic authentication in combination with Secure Sockets Layer (SSL) security, you can add a layer of protection to the user names and passwords, making user information more secure.

Integrated Windows authentication

Integrated Windows authentication (also known as Windows NT Challenge Response) encrypts user names and passwords in a multiple transaction interaction between client and server, thus making this method more secure than Basic authentication. Disadvantages are that this method cannot be implemented through a proxy server firewall, and some Web browsers (most notably, Netscape Navigator) do not support it. You can, however, enable both this method and Basic authentication at the same time.

Digest Access authentication

Digest Access authentication is similar to Basic authentication, except that a user's name and password are transmitted in a more secure format. This method requires IIS 5.0 (included with all versions of Windows 2000) or later on the server computer and Microsoft Internet Explorer 5 or later on the client computer. Digest Access authentication works with domain accounts only; you cannot use Digest Access authentication with local user accounts.

Certificate authentication

Certificate authentication (also known as Secure Sockets Layer security) provides communications privacy, authentication, and message integrity for a TCP/IP connection. By using the SSL protocol, clients and servers can communicate in a way that prevents eavesdropping, tampering, or message forgery. With SharePoint Team Services, SSL ensures secure authoring across firewalls and ensures security during remote administration of SharePoint Team Services. You can also specify that SSL be used when opening a SharePoint team Web site or opening or publishing FrontPage-based Web sites.

About firewalls

SharePoint Team Services supports connectivity through firewalls. Depending on the configuration, your users' firewalls must open for the standard HTTP ports 80 and 443. When using a firewall, users' sites should not use Integrated Windows Authentication because it cannot pass through a firewall.

File system security

SharePoint Team Services relies on NTFS to secure the file system for your Web sites.

Note that security for documents is set per Web and not per document.

With FrontPage 2000 Server Extensions, you could bypass the built-in security management and set permissions manually on the content of a FrontPage-based Web site. With SharePoint Team Services, the roles and permissions have been improved, and this functionality is no longer available.

Architectural Considerations

The primary architectural consideration you need to address prior to deploying SharePoint Team Services is in the configuration of the database. Web sites based on SharePoint Team Services rely on the database to store meta-information: this includes user and site information and properties of the documents such as author, creation date, revision date (see figure below). Properties are promoted into the database during the save process.

SharePoint Team Services was built with the understanding that different companies and situations would call for different deployment strategies. Therefore, SharePoint Team Services Web boxes can be architected in three main ways:

With no SQL Server; the Microsoft Data Engine will be installed.
With a local version of SQL server 7.0 or greater running.
With a remote version of SQL server 7.0 or greater running.

The standard SharePoint Team Services installation will attempt to find a local installation of SQL Server (7.0 or later). If it finds it, it will only install SharePoint Team Services files, and it will allow you to connect to SQL Server after installation (using the Administration pages). If it does not find it, it will automatically install the Microsoft Data Engine (MSDE), which is an embedded version of SQL Server. The following sections discuss SQL Server and MSDE and offer recommendations for large-scale providers.

Using MSDE

The primary advantages of using MSDE are that it is an out of the box solution, and it does not require any SQL Server knowledge. Also since it resides on the same server as SharePoint Team Services, there is no extra network trip for database data. For these reasons, MSDE is ideal for users whose only storage needs are for SharePoint Team Services and who have a small number of servers.

A disadvantage to using MSDE is that there are no built-in management tools, so you are not able to adjust performance to suit your needs unless you use the SQL management tools. And because MSDE is an embedded product, its performance is throttled.

SQL Server

Using SQL Server has a number of advantages over using MSDE. First, SharePoint Team Services data can be administered along with data in other databases on your SQL Server. No new administration processes are needed. And SharePoint Team Services data is protected by the backup strategy that you have in place on the SQL Server.

Using SQL Server on its own server also allows you to host all of your collaboration databases together and manage them all at once with SQL Server management tools. Using SQL on its own server also allows your SharePoint Team Services server to devote all of its processor, memory, and disk resources to serving up pages and files. The two drawbacks of using SQL Server are that it has to be maintained separately from SharePoint Team Services and that it requires that data travel over the network to and from the database.

In spite of the drawbacks, the recommendation for hosting companies and other large scale deployments of SharePoint Team Services is to use SQL Server. An optimal configuration would be SQL Server 2000 on a cluster of Windows 2000 Servers. At the very least, however, it is recommended to have a dedicated SQL Server that is not running SharePoint Team Services. In this case, you will have to manually prevent installation of MSDE from the command line during SharePoint Team Services setup.

To prevent the installation of MSDE, insert the Office XP with FrontPage 2002 or the FrontPage 2002 CD, and then type the following command:

setupse.exe /nd

During the setup process, you will be given the opportunity to specify that there is a remote SQL Server. After setup, you must provide the database connection information using the administration pages or one of the command line tools (described below).

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.

SharePoint Team Services scalability

For scalability, the key concerns are:

How many virtual servers can be hosted on a Web server
How many databases can be hosted on a SQL server
What are the RAM requirements

Microsoft has successfully run SharePoint Team Services with up to 1000 virtual servers (with hardware configuration of dual Pentium 3 with 1GB of RAM). You may want a bit of a buffer for performance' sake, but consider that SharePoint Team Services beta customers have had very good performance hosting 500 sites on a server. Whether your number is closer to 500 or closer to 1000 will depend on how heavily the sites are used.

Testing has shown that a remote SQL server with similar hardware configuration can handle about 2000 databases averaging 5MB per database. This means that you will generally require 1 SQL server for every 2 Web servers. At this level of SQL Server usage, however, RAM utilization can become a performance factor, though not a debilitating one. The other performance factor when running at the maximum of 1000 virtual servers on the Web server and 2000 databases on the SQL server is network bandwidth. It is recommended that your Web servers and SQL servers be maintained on a high-speed network.

In terms of disk space on the SQL server, a good rule of thumb is stay below 60 percent usage.

In terms of "concurrent users", memory is the driving factor on the Web server. A SharePoint team Web site is stateless, so a user connects, executes their request, and then disconnects. There is no persistent connection. SharePoint Team Services uses one thread per connection, and the default maximum number of SharePoint Team Services threads is:

(amount of memory in the server – 64MB) / 32MB

Note that you can customize the maximum number of threads in the Registry (see "Editing the Registry to tune Web site performance" below). However, based on the default setting, the following table shows the amount of memory required to handle a given number of concurrent connections.

Amount of Memory	Approximate concurrent connections
128Mb	~ 40
192Mb	~ 80
256Mb	~ 120
512Mb	~ 280
1Gb	~ 600

So, if there is 1GB of memory on a Web server, the maximum default number of threads would be 30. ((1024MB x 1) – 64MB)/32MB = ((1024MB)-64MB)/32MB = 960MB/32MB = 30. This is equivalent to a typical peak user load of about 600 users (about 1 request every 20 seconds per user). However, there is not a hard number or formula for calculating concurrent connections to a SharePoint team Web site. This is because the number goes up or down depending on what types of operations are being performed and on the server setup.

Deploying SharePoint Team Services

Deploying SharePoint Team Services in a large-scale hosting environment consists of two basic steps:

Running the setup program to copy the SharePoint Team Services software onto the server.
Provisioning (or extending) Web sites so that they can use SharePoint Team Services features.

For information on upgrading to SharePoint Team Services, see the SharePoint Team Services Administrator's Guide.

Preparing the SQL database

With the Office Server Extensions (predecessor to SharePoint Team Services), in certain situations you had to create your database prior to installation so that the Server Extensions could connect to the database and configure discussions and other features. With SharePoint Team Services, this is not required. However, there are a few things you do need to address prior to installing SharePoint Team Services.

SQL Server authentication

If you are using SQL Server 2000 remotely, your SQL server needs to be using SQL Server authentication so that the setup program can make the connection to the database server to create the database. To do this:

Open SQL Server Enterprise Manager (click Start, Programs, Microsoft SQL Server, Enterprise Manager).
Expand Microsoft SQL Servers.
Expand SQL Server Group.
Right click on the SQL server name, and click Properties.
On the Properties dialog, click the Security tab.
Under Authentication, click the SQL Server and Windows radio button, and click OK.

TCP/IP SQL connection

When using remote SQL 7.0 or SQL 2000, you should configure the Web server to connect to SQL using TCP/IP instead of Named Pipes, which is the default. In many configurations, if you do not make this change, SharePoint Team Services will not be able to connect to the remote SQL server. To do this, you need to make the following change to the Registry:

On the Web server, open Regedit (click Start, Run, type REGEDIT, and click OK).
Locate KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo
Change DSQUERY=DBNMPNTW to DSQUERY=DBMSSOCN
Stop and restart the IIS Services.

In some cases you may find that the Registry key does not exist at all on the Web server. If this is the case, then when you attempt to provision a Web site with SharePoint Team Services, a connection to the remote SQL cannot be made and the provision fails. In this case you need to create the Registry keys manually. To create the key, use the following steps:

On the Web server, open Regedit.
Locate HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft
Click on the Microsoft key and, on the menu bar, click Edit, New, Key. Enter the new key name as MSSQLServer.
Click on the new MSSQLServer key and, on the menu bar, click Edit, New, Key. Enter the new key name as Client.
Click on the new key Client and, on the menu bar, click Edit, New, Key. Enter the new key name as ConnectTo.
Click on the new key ConnectTo and, on the menu bar, click Edit, New, String Value. Enter the value name for the string as DSQUERY.
Double click on the new string value DSQUERY and enter the value data as DBMSSOCN.
Stop and restart the IIS Services.

Manual installation

SharePoint Team Services is available on the Microsoft Office XP versions containing FrontPage 2002 CD, the FrontPage 2002 stand-alone CD, and as a Web download for members of the Web Presence Provider for Microsoft FrontPage program.

Note that there are many command line options for SharePoint Team Services setup (see the table below). To see them, insert the CD, open a command prompt, change to the CD-ROM drive, and then type the following command:

setupse.exe /?

You will see a dialog box with the following available commands:

Command	Does:
/I <path to msi>	Install using the specified .msi file
/f <path to msi>	Reinstall using the specified .msi file
/x <path to msi>	Uninstall using the specified .msi file
/l <path to logfile>	Log setup messages to the specified file
Logfile=<path to cfgquiet.ini>	Use the specified configuration options file during install (quiet mode setup only)
/qf	Full UI setup (default)
/qb	Basic UI setup
/q	Quiet mode setup (no UI)
/help OR /?	Display this help
/settings <path to setupse.ini file>	Install using the specified .ini file
/nd	Don't install MSDE

Having considered the hardware, software, and database prerequisites, determine whether your server has existing Web content. If it does, you must decide during setup whether you will replace the home page for that content with the SharePoint team Web site home page or create the new home page as Sharepoint.htm.

To begin, you can install directly from the Office XP or FrontPage 2002 CD:

Insert the Office XP CD into your server computer's CD-ROM drive.
Click Start, and then click Run.
Because we will be using a remote SQL server, we must use the /nd parameter. In the Run box, type d:\SharePt\setupse.exe /nd (where "d:" is your computer's CD-ROM drive.)
Follow the steps in the setup wizard.

Or, if you are a member of the Web Presence Provider (WPP) for Microsoft FrontPage program, you must install SharePoint Team Services from the Microsoft Web Presence Provider Web site. Installation and licensing instructions are provided.

Continuing with installation

The setup procedure itself is very straightforward. When complete, SharePoint Team Services is installed on the server.

Note: The databases must be created through the setup program. You cannot create the databases manually.

Because you used the /nd parameter, when installation is complete, the browser opens to the Administration pages, which you can use to extend a virtual server with SharePoint Team Services. The command-line tools can also be used to do this.

Extending the server

The part of the installation process during which SharePoint Team Services is applied to a virtual server is called extending a server. This process can also create a SharePoint team Web site. Since you installed SharePoint Team Services with a remote SQL server, you must extend your virtual server in one of three ways:

By using Browser enabled Administration pages.
By using the install operation with the command-line tools.
By running the command-line installation in unattended mode with an edited cfgquiet.ini file (described below).

When you extend the server, you also specify the type of site you want to create on the virtual server. The following table describes the site types from which you can choose when you extend the server.

Site type	Description	Command line parameter
SharePoint team Web site	This option gives you a new SharePoint team Web site that's ready to use. Note that it replaces the existing home page (default.htm), if there is one, with the SharePoint Team Services home page	SHAREPTHP
Web site based on SharePoint Team Services (preserves home page if one exists)	This option gives you a new SharePoint team Web site but does not replace any existing home page you already have. You can use a SharePoint Team Services-compatible Web page editor, such as FrontPage 2002, to integrate your existing content with your new SharePoint team Web site.	SHAREPT
SharePoint Team Services blank Web site (this enables features such as document libraries and lists and document discussions and subscriptions)	This option gives you SharePoint Team Services, but no Web site content. You can still create a Web site that uses the SharePoint team Web site features, such as a discussion board or survey.	COLLAB
Blank Web site	This option gives you a blank Web site and no collaboration options. This, in essence, extends the site with the FrontPage 2002 Server Extensions, which enables support for publishing.	PUBLISH

Using the Administration pages to extend a server

You can extend a server by using the Administration pages. Doing so gives you the most flexibility to choose which options you want enabled when you extend your server. To extend a server by using Administration pages:

Open the Server Administration page. On Windows 2000 Server, click Start, Programs, Administrative Tools, Microsoft SharePoint Administrator. On Windows 2000 Professional, click Start, Settings, Control Panel, Administrative Tools, Microsoft SharePoint Administrator.
In the list of virtual servers, next to the virtual server you want to extend, click Extend.

Note that if the server has a previous version of the FrontPage Server Extensions, the Office Server Extensions, or a beta installation of SharePoint Team Services, the link will say "Upgrade" instead of "Extend".
In the Administrator box, type the user name for the administrator of the virtual server.
Presuming SQL Server, on the Database section, enter the collaboration database settings to use: enter the database server name, the administrator account, and the password. Note that for MSDE, no input is required in this section.
In the Site Type area, select a site type.
Click Submit.

Using the command-line tools to extend a server

In a large-scale hosting environment, rather than use the Administration pages, the better option may be to extend a server by using the command-line tools, Owsadm or Owsrmadm. To do so, you use the install operation. The install operation takes the following parameters.

Parameter	Short Form	Description
Port	-p	The port number. On IIS 4.0 or later, this value can be an instance number, such as /LM/W3SVC/1. If missing, this parameter defaults to port 80.
Multihost	-m	If provisioning a virtual server that is using a host name, the –m parameter specifies a virtual server's name or IP address. On IIS version 4.0 or later Web servers, this argument is used to specify an instance number.
Username	-u	If your server is part of a domain, the –u parameter specifies the already existing username that you would like to administrate this website. For example, MyDomain\MyUserName.
DatabaseServer	-ds	Name of the server on which the collaboration database is stored. For example, MyServer.
DatabaseName	-dn	Name of the collaboration database. For example, MyServer_collab. The default value is generated automatically from the machine name and the virtual server.
DatabaseUserName	-du	User name for the administrator of the collaboration database.
DatabasePassword	-dp	Password for the database administrator user name.
Siteprovision	-sp	Creates a default SharePoint team Web site when SharePoint Team Services is installed on the virtual server. Takes the following values: SHAREPTHP (the default value), SHAREPT, COLLAB, PUBLISH.

If any of these parameters are missing, default parameters are used, although you are always prompted for a database password when you enter a database user name on the command-line.

The following example shows the syntax for the install operation:

owsadm.exe –o install –p <port> -u <username> -ds <database server> -dn <database name> -du <database username> -dp <database password> -sp <value>

The values for the siteprovision parameter determine what (if any) default content is placed on your extended Web. If you use the PUBLISH value, the virtual server is extended with FrontPage 2002 Server Extensions from Microsoft. If you use the COLLAB value, the virtual server is extended with SharePoint Team Services and the collaboration database is created. If you use the SHAREPT value, a SharePoint team Web site is also created. If you use the SHAREPTHP value, the SharePoint team Web site is created and the team Web site home page replaces the current default home page.

Unattended installation with Quiet Mode

For SharePoint Team Services, you can perform a quiet installation, in which the setup program will not prompt for information or display messages. You can run an unattended setup from the command-line by itself or as part of a script for distribution across several servers. Any output from setup is stored in the log file in the Temp directory of the Windows volume.

To perform the unattended setup, use the setupse.exe command with the /q command-line option. The setupse.exe command relies on settings in a text file, Cfgquiet.ini, to determine which options are incorporated into the setup. Cfgquiet.ini is a hidden file located at the root of the Sharept directory. When you run the setupse command, specify the path to the Cfgquiet.ini file by using the logfile parameter in the command-line syntax. To specify a quiet install, you would use the following syntax:

setupse.exe /q logfile=<path to cfgquiet.ini>

The settings in the Cfgquiet.ini file can be edited to suit your environment. For example, you can edit Cfgquiet.ini to extend specific virtual servers when SharePoint Team Services is installed, or to specify a database server to use for collaboration data, or to extend the virtual servers with FrontPage 2002 Server Extensions instead of SharePoint Team Services.

Important: For the scripted install to work, you must uncomment the [Server0] section by removing the semi-colons, as follows:

spdpgl04 [Server0]

spdpgl04

VRootMDPath: For Microsoft IIS\PWS>=4.0 web servers. Metabase path for web site to extend.

spdpgl04

VRootMDPath=/LM/W3SVC/1

You can use any text editor, such as Notepad, to edit the Cfgquiet.ini file.

The Cfgquiet.ini file is divided into Security Settings, Database Settings, and Mail Settings. Basic information, such as the server type, is at the top of the file. The configuration options take the format NAME=value. To change an option, you replace the default value with the value you want. The following example shows the Discussions option set to On:

Discussion=On

See the SharePoint Team Services Administrator's Guide for complete details on all of the values that you can set with Quiet Mode.

Administration tools

With SharePoint Team Services, all administrative tasks are performed from either Administration pages or the command-line tools.

The two new tools for command-line administration are:

Owsadm.exe for local command-line administration.
Owsrmadm.exe for remote command-line administration.

These tools provide full functionality for a managing the SharePoint Team Services environment.

We have already seen owsadm.exe in action in the section on extending a server. Commercial hosting companies will probably prefer the command-line tools, though, since they can be used in batch files or within scripts to:

Manage users and roles.
Detect potential problems with the server extensions installation and repair them.
Set database connection properties.
Add, delete, or merge subwebs.
Recalculate a Web site.
Upgrade to the new version of the server extensions.
Uninstall the server extensions for a particular Web site.
Set properties for a subweb, root Web, or all Web sites on a server.

For a complete list of the operations you can perform by using the command-line tools, see the Owscmdln.xls spreadsheet.

Command-line tools details

The command-line tools offer a complete set of SharePoint Team Services operations. You can use the command-line tools from the command line or from batch files. You must have machine administrator rights on the server computer to use either command-line tool. Owsadm.exe must be run on the server computer, while Owsrmadm.exe can be run from a remote location (on Windows only). The Owsadm tool can be run even when the Web server is not running (although the Web server administration service for your server may need to be running). The Web server must be running before you can use the Owsrmadm tool.

Unlike Fpsrvadm.exe in the FrontPage 2000 Server Extensions, Owsadm and Owsrmadm are not interactive tools. With the Fpsrvadm tool, you typed a command and operation, and then you were asked for parameters. With Owsadm and Owsrmadm, you type the operation and parameters all at once, and you are not queried for further information. If a required parameter is missing, the operation fails, and you must type the operation and parameters again. The one exception here is that passwords will be interactively prompted for if not supplied.

This new behavior allows better flexibility for batching commands, since the tools do not prompt you for information after you have submitted a command. However, it does mean that you cannot perform queries, such as looking up the role assigned to a particular user. If you want a more interactive tool, try using Administration pages. With the Administration pages you can perform most of the same operations as the command-line tools, but you can also see the options you have for those operations, and look up information about each Web site, user, server, and so on.

Maintaining Your SharePoint Team Services Environment

Self-Service Site Creation tool

Due to the capabilities of SharePoint team Web sites, it is likely that a high adoption rate will be seen. To enhance the rapid creation aspect of SharePoint Team Services, Microsoft created an add-in that allows users to provision their own SharePoint team Web sites. Known as Self-Service Site Creation Tool, this add-in allows end-users to create their own SharePoint team Web sites in a matter of moments.

Some issues to consider in making SSC available to your users are:

Scalability – how many sites would be able to be served per Web box.
User restrictions – whether you want each and every user to have self-service site creation functionality available to them.
Virtual account restrictions – the number of virtual accounts allowed per created site.
Site size limitations – to what size will sites be limited.

User restrictions

It is possible to limit the access to the Self service site creation tool. In this manner, hosts can determine to whom this access be granted and add that set of users to the SSC authorized user list. A scenario where this might be implemented is if a large-scale provider wants to limit this option to premium customers. By restricting the set of users who may take advantage of the SSC functionality, more control can be put on the number of sites created.

Users and user rights

Managing the number of users per web

If you manage multiple Web sites or host sites for other organizations, you need to balance the load on your server computers and ensure an even distribution of resources. One way to achieve this balance and distribution is to control how many users have access to a Web.

With SharePoint Team Services, you can limit the number of users allowed access to a Web on a per-virtual server basis. This way, you can safely delegate the tasks of creating and deleting accounts to the administrator of each Web, but still maintain quotas on those actions to ensure that your server stability is not put at risk.

SharePoint Team Services can also track user accounts as they are deleted and remove unused user accounts from the virtual server, freeing the quota for other users. User account limits are applied at the virtual-server level. This means that when you set a quota, it is per virtual server, not per Web.

In addition, there are safeguards built in to prevent a user from being added to multiple virtual servers on the same server computer. A user can be a member of multiple Webs on a virtual server, but not of other Webs on other virtual servers on the same server computer. This makes it easier to control who has access to which sites.

The ability to limit user accounts is turned off by default. If you want to implement user account limits, you must specify a limit by using either the command-line interface or the Administration Pages. You must be a machine administrator (a member of the Administrators group of the server computer) to set SharePoint Team Services to track user accounts.

Storing user account information

To make the quotas possible, user account information is stored in a flat file database for each server computer. When you create a new user account, the user information is added to the database and is marked as belonging to a particular virtual server. When a user is deleted, he or she is removed from this database, and will not be able to access any site on that virtual server.

If the quota for the virtual server has been reached, and an administrator tries to add a new user, a message is returned that the quota has been reached and that a user must be deleted before a new user can be added. Also, if an administrator tries to add a user who already has an account on a different virtual server, a message is returned that the user already exists on another virtual server and cannot be added.

Only new local machine accounts are tracked in user account limits. Existing users and domain users do not count against the user account limits. For example, if you have an existing Web and you upgrade that Web to SharePoint Team Services, any user accounts that already exist on that Web are not affected by user account limits. However, if you add a new user after the upgrade, the new user account is counted against the limits.

Note: User account limit data is stored in the Owsuser.cnf file in the ..\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\50 folder. If you are using account limits, you must back up this file whenever you back up your collaboration database and your site content. There is no other way to repair this file other than restoring it from a backup.

Using the command-line tools to limit user accounts

Use the accountlimits operation to control how many accounts can be added to a virtual server. The accountlimits operation takes the following parameters.

Parameter	Description
-port	Optional
-multihost	Optional
-limit	Number of local accounts allowed. Set to a number to turn limits on (for example, 30) or to "unlimited" to turn limits off.

For example, the following command can be used to set port 80 to allow 30 users:

owsadm.exe –o accountlimits –p 80 –limit 30

And the following command can be used to set port 80 to allow unlimited accounts:

owsadm.exe –o accountlimits –p 80 –limit unlimited

For information on how to limit user accounts using the Administration pages, see the SharePoint Team Services Administrator's Guide.

Limiting account visibility

FrontPage 2000 Server Extensions contains a useful feature that limits what users are displayed in permissions management. The feature in FrontPage 2000 was restrictiisusersandgroups. The new command line operation in SharePoint Team Services is RestrictAccountVisibility. This is a global operation that specifies that the list of users only shows users that were either created on the virtual server or role members in the current Web. Set the value to 1 to turn on the restriction.

Specifying which rights are available for a server

Server administrators can determine which user rights are available for use on the Web server. As an administrator, if you do not want to allow users of a web to perform certain actions, you can disable the associated right on the server. For example, if you do not want users to be able to recalculate a web, you can disable the Recalc Web right. When you disable a right on your server, it cannot be assigned to any role and, as a result, cannot be granted to any user of the server. Note that if a user already has a right, and you disable the right, the right is also disabled for that user.

Using the command line to specify available rights

To specify available rights on the command line, you set the GlobalRightsMask property by using the rightsmask operation and one of the command-line tools. The rightsmask operation can only be used at the global level and takes the following parameters: command (add/set/del/delall), right (name of right or a comma-separated list of rights), and port (optional — only accepts "global" as the value). Any right that you remove from GlobalRightsMask property is no longer available to any user on the server.

The following sample syntax shows how to set the GlobalRightsMask property to remove the Theme Web right:

owsadm.exe -o rightsmask -c del -r themeweb

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

Management issues

To maintain an effective collaboration environment, the server administrator has to keep up with tasks such as server backup and customer account management. The following sections describe the need for such tasks.

Backup and restore

One of the primary duties of the server administrator is backup and restore. In a SharePoint Team Services environment, two types of data need to be backed up: file system data and database data. For example, a list in a SharePoint team Web site is a combination of data in the database and HTML files. If you want to back up a list, you must back up both the data in the database and the HTML files. You must back up and restore the file system by using your usual operating system tools. To back up the database, use one of the command-line tools with the BackupDB operation in the following format:

owsadm -o backupdb [-schedule <date and time> -p <port> -m <name>

Be sure to back up the file system whenever you back up the database. If changes occur in the time between the two backups, there would not be a transactionally pure snapshot of the Web. A recommendation, then, is to run your backups during the evening, when changes are less frequent.

For more information on backing up and restoring, see the SharePoint Team Services Administrator's Guide.

Content management

Content management will generally be the responsibility of the customer. However, providers may wish to support users with specific issues such as standards enforcement and site health management. Providers can help enforce the use of templates and styles within a given virtual server. For site health management, providers may provide users with reports on broken links and inefficient pages. Where providers might be of great help is when users need to reorganize content. Content reorganization will require new Webs, consolidation of existing Webs, link fixing, etc.

Performance optimization

The speed with which a Web server responds to requests from a client depends a lot on the size of the Web site, particularly the number of pages and the other files it contains. You can improve a Web site's response time by tuning it. When you tune a Web site, you set aside a certain amount of memory as a cache for the Web site, based on the number of Web pages. You can tune a Web site for any size.

In addition to controlling the document cache, when you tune performance, you can specify cache sizes for images and include files. You can also specify how large to make the search index for your Web site.

Again, you can use either the Administration pages or the command-line tools to tune Web site performance. If you want maximum control over performance tuning, use the command-line properties rather than the Administration pages to specify performance settings.

For more advanced performance tuning, you can use the Registry to modify such things as Thread count. This is described in more detail below.

Using the command-line tools to tune Web site performance

To tune performance, you set properties using the SetProperty operation with the command-line tools, Owsadm and Owsrmadm. All of the command-line performance properties can be set at all levels (server, virtual server, or subweb). This flexibility in levels is an advantage over the Administration pages, which can only be used to tune performance for an entire virtual server. By using the command line, you can also control the document cache separately for read and write operations in Microsoft FrontPage.

The following table describes the properties you can set to control performance tuning.

Property	Description
CacheMaxDocMeta	Sets the maximum number of documents kept in the cache when FrontPage is doing write operations. This is the maximum number of documents whose property information, such as Web site parameters, you want to keep in active memory. The size of the cache affects how quickly the save and recalculate hyperlinks processes can be completed. In general, you should set this property to be greater than or equal to the number of HTML pages in a Web site that contain FrontPage components. If there are a large number of pages in the Web site, you can choose a lower value to save memory, but this will decrease the performance of the recalculate hyperlinks and save processes. Default value = 4096.
CacheMinDocMeta	Sets the maximum number of documents kept in the cache when FrontPage is doing read operations. This is the maximum number of documents whose property information, such as Web site parameters, you want to keep in active memory. When an author opens a document after the cache is full, the cache is cleared and starts with the most recently opened document. Default value = 8.
CacheMaxInclude	Sets the maximum number of included files on a page (that is, files included through the Include Page component) that SharePoint Team Services will cache while recalculating hyperlinks or saving the page. Increase this value to the highest number of pages that are included in any page in your Web site, if that number is higher than the default value (16).
CacheMaxIncludeSize	Sets the maximum document size in kilobytes that SharePoint Team Services will cache internally. Default values = 256K.
CacheMaxImage	By default, SharePoint Team Services sets the HEIGHT and WIDTH attributes in all IMG tags in pages saved to a Web site. This improves the appearance of pages when a site visitor downloads them over a slow connection. This property sets the maximum number of images whose HEIGHT and WIDTH attributes the server extensions will cache while recalculating hyperlinks or saving a page. If you set this variable globally or per virtual server, and Web sites on your server frequently contain more than 16 images, you should increase this number. If you set this variable on an individual subweb, do not set it higher than the number of image files in the Web site. Default value = 16.
TextMemory	If you are using the built-in Wide Area Information Server (WAIS) search engine, setting this property to 0 turns off full-text indexing of the Web site. A non-zero value specifies the number of megabytes of RAM the server extensions are to use during text indexing for hash-tables and other data structures. For Web sites with less than 500 pages, set the value of this property to 1. For Web sites with 500 to 5000 pages, set it to 2. For Web sites with more than 5000 pages, set it to 4. Default value = 1.

For example, you can restrict the number of files that can be included on a page to 10 files. If you wanted to set this as a limit for all Web sites on a server, you could use the following syntax and set the CacheMaxInclude property globally:

owsadm.exe –o setproperty –pn CacheMaxInclude –pv 10

For more information about setting properties by using the command-line tools and about performance tuning via the Administration pages, see the SharePoint Team Services Administrator's Guide.

Editing the Registry to tune Web site performance

There are a number of Registry settings that you can use to tune SharePoint Team Services to specific needs. Making changes to these Registry keys should be done with care, since inappropriate changes can actually harm performance. The Registry keys fall into two categories:

Thread Pool Configuration Keys
Database Cache Configuration Keys

These keys do not exist, so you will have to create them at HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Shared Tools\Web Server Extensions\All Ports. For simplicity's sake, create the keys with the default values (in order to duplicate the built-in default value) and then modify those values to suit your needs.

To create the keys:

On the Web server, open Regedit.
Locate HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Shared Tools\Web Server Extensions\All Ports
Click on the All Ports key and, on the menu bar, click Edit, New, DWORD Value. Enter the new DWORD name.
To edit the value, double click the DWORD, enter the new value, and click OK.

Thread Pool Configuration Keys

The thread pool allows SharePoint Team Services to handle many more requests than was possible in older versions of the FrontPage Server Extensions. Requests for SharePoint Team Services enter IIS as IIS threads. The thread pool takes the request from the IIS thread and attempts to get a thread in the thread pool to handle the request. If a thread is available and waiting, the request is given to that thread and the IIS thread is released. If a thread is not available, the thread pool attempts to create one. As long as the number of threads currently in the thread pool is less than or equal to MaxThreadsCount and there is sufficient memory available, a new thread will be created in the thread pool to handle the request. If there are no threads available and the thread pool cannot create another, the request will be queued (as long as the number of threads in the thread pool's queue is less than or equal to RequestQueueSize)

MinThreadsCount DWORD value that indicates the smallest number of threads that will always be available in the thread pool, even after the thread pool is trimmed after the time interval specified in the ThreadTimeOut value (described below). Note that this value is per processor, so a MinThreadsCount setting of 2 on a four processor machine would mean that SharePoint Team Services always has at least 8 threads running (plus the threads that IIS creates). The default value for MinThreadsCount is 2.
MaxThreadsCount DWORD value that indicates the maximum amount of the threads that SharePoint Team Services will allow in the thread pool. If an incoming request appears and the threadpool already contains MaxThreadsCount * NumProcs then the request will be queued. Again, this value is per processor, so a setting of 32 on a four processor machine would result in a maximum of 128 threads (plus the threads that IIS creates). The default setting for MaxThreadsCount is 32.
ThreadTimeOut DWORD value that specifies the number of milliseconds that should be waited before timing out a thread that isn't performing useful work. Each time the interval passes, the thread pool will be trimmed down to a minimum size of MinThreadsCount * NumProcs. The default setting for ThreadTimeOut is 300000 ms (5 minutes).
RequestQueueSize DWORD value that controls the size of the incoming request queue. As requests come in, if there isn't a thread available in the thread pool, then the request is queued. As threads become available, requests are taken out of the queue. If a request comes in and no threads and available and the Request Queue is full, then the user will get a "server too busy" error.

Database Cache Configuration Keys

These keys control the behavior of the SharePoint Team Services database cache. This cache stores the metadata for three different types of information in the SharePoint Team Services database: Lists, Projects and UserInfo. By storing this information in a cache, each request can get the information needed to render the lists without accessing the database directly. If the metadata for a particular list is located in the cache, the only request sent to the database is for the actual data that makes up the list. The cache is global to the entire server, so changing a setting will affect all virtual servers on the machine. The settings listed below are the minimum size that the cache will shrink when the database cache is trimmed. The cache is trimmed at an interval controlled by the value of DBCacheAgingInSeconds.

DBCacheListsMax DWORD value that indicates the minimum size of the cache that will store metainfo for lists. The default setting for DBCacheListsMax is 1000.
DBCacheProjectsMax DWORD value that indicates the minimum size of the cache that will store metainfo for unique projects (webs.) The default setting for DBCacheProjectsMax is 200
DBCacheUserInfoMax DWORD value that indicates the minimum size of the cache that will store metainfo for unique users (that are in the UserInfo table) The default setting for DBCacheUserInfoMax is 2000.
DBCacheAgingInSeconds DWORD that controls the time interval for trimming the database cache. Every DBCacheAgingInSeconds seconds after SharePoint Team Services is started, a thread will awaken to trim the database cache. Each cache will be trimmed down to its Maximum value using a least recently used algorithm to control which entries will be removed. (e.g. if the Lists Cache has 5000 entries in it, it will be trimmed down to 1000)

Usage analysis

SharePoint Team Services includes features that allow users to analyze usage of their sites. Summary and detailed usage reports supply 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 that the Web site is hosted on, which keeps a distilled record of every transaction on the Web site. When a customer creates 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 there are separate Webs on a virtual server.

As the provider, you can control the settings for processing the usage log by using the Administration Pages or command-line tools.

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).
When the usage log is processed. You can schedule the usage log to be generated at a convenient downtime for your Web. Note that usage analysis does impact performance. You can schedule the log to be processed on a daily, weekly, or monthly basis, depending on how closely you want to track a site's usage. If you only run usage reports once a month, you can process the log once a month.
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.

Conclusion

Some final thoughts and recommendations for building an efficient large-scale hosting environment will be useful at this point. To recap some of the major discussions in this paper, a multi-server and/or commercial hosting environment should:

Use the NTFS file system to use the security features of SharePoint Team Services.
Use clustered SQL servers as the database component and not MSDE.
Count on about a 4:1 ratio of file system space versus database space.
The more RAM on your Web servers, the better.
Understand the command-line tool parameters and use them to both install SharePoint Team Server and extend your server.
Simplify your site provisioning by using the Self-service Site Creation tool.

As with all things infrastructural, architecting your SharePoint Team Services hosting environment appropriately from the beginning will go a long way to easing your administrative burden and ensuring low-maintenance, highly satisfied users.