Managing a Server Farm Running Windows SharePoint Services

Microsoft Windows SharePoint Services was designed to be useful in large server farms, supporting hundreds or thousands of SharePoint sites and millions of users. When you manage a server farm environment for Windows SharePoint Services, you need to make certain choices about configuring your environment, and you need to be aware of how Windows SharePoint Services works in that environment. This topic explains those choices, and describes how to work with Windows SharePoint Services in a large-scale, server farm environment.

About Front-End Web Servers

In a server farm environment, the front-end Web servers contain only the files and settings required to route requests from clients to the appropriate sites in the database. Unlike in SharePoint Team Services 1.0 from Microsoft, they do not contain site data.

All site content and all configuration data is shared for all front-end Web servers in a server farm. To get the best performance and the best protection against hardware failure, you should configure Windows SharePoint Services identically on all the front-end Web servers in your server farm.

The exceptions to this rule are those cases where data must be stored or pulled from Internet Information Services (IIS). For example:

  • Usage analysis data is collected for each front-end Web server individually. You can view usage analysis reports for each site. The data for these reports is compiled from the information collected from each server in your server farm. For more information about usage analysis, see Configuring Usage Analysis and Analyzing Web Site Usage.
  • Some settings used for virtual servers in IIS, such as whether anonymous access is allowed for the virtual server, are stored in the IIS metadata on the server itself.

It is strongly recommended that you use the same application pool accounts across all of the front-end Web servers in your server farm. For example, on server1, virtual_server1 hosts http://site1. On server2, virtual_server1 hosts the same site. When you use the same application pool for virtual_server1 on both servers, you can be sure that the application pool always has the appropriate permissions to perform the Windows SharePoint Services administration tasks.

Replicating Configuration Settings

Most changes to configuration settings in Windows SharePoint Services are replicated automatically, without requiring software such as Microsoft Application Center. For example, when you change the e-mail server for Windows SharePoint Services, you do so either from the SharePoint Central Administration pages or the command-line tool, Stsadm.exe. You make this change only once, and the change is entered into the configuration database and automatically applied to all servers in the server farm.

Some configuration processes must be performed individually on each front-end Web server. These processes include:

  • Installing Windows SharePoint Services.

You must install Windows SharePoint Services directly to any server computers that you want to include as front-end Web servers in your server farm.

  • Extending a virtual server with Windows SharePoint Services.

Although this task is performed from either the SharePoint Central Administration pages or the command line, it adds files to the virtual server directory on the front-end Web server itself.

Windows SharePoint Services uses the SharePoint Central Administration virtual server on each front-end Web server to keep configuration data synchronized. To make automatic replication of other configuration settings work best, you should ensure that:

  • The SharePoint Central Administration virtual server for each front-end Web server is directly accessed by administrators, and not solely by a virtual Internet Protocol (IP) address.
  • If you are using hardware load balancing, the routers or switches you use in a multi-host environment are configured so that command-line operations work. For example, if you are using a virtual IP environment for the SharePoint Central Administration virtual server, you must be sure that each front-end Web server can ping every other front-end Web server.

Choosing a Load Balancer

To make the most of your server farm environment, you need some method of balancing the client requests across all of the front-end Web servers in your server farm. Windows SharePoint Services works with most of the standard load balancing methods available. Some methods work better, or scale up better than others. You can use any of the following methods with Windows SharePoint Services:

  • Software solutions, such as Network Load Balancing

Network Load Balancing is included with Microsoft Windows Server 2003. This method is inexpensive, but offers only limited scalability. For more information about Network Load Balancing, see your Windows Server 2003 documentation.

  • Software configuration solutions, such as using the domain name system to route requests

You can configure your domain name system (DNS) to create a basic load balancing system. For more information about DNS, see your Windows Server 2003 documentation.

  • Hardware load balancing

You can also purchase load balancing hardware, such as a router, to distribute requests. The hardware method is more expensive, but it is also the most scalable method and it provides the best use of your front-end Web server resources.

You do not need to perform any configuration steps to make Windows SharePoint Services work with any of these load balancing methods. Simply set up the load balancing method in your server farm, and either install or continue using Windows SharePoint Services.

Managing the List of Servers in a Server Farm

In a server farm environment, you may frequently need to perform the same action across several front-end Web servers in your server farm. To make performing actions on multiple servers easier, the SharePoint Central Administration page includes a link to the Manage Web Server List page — which lists all of the servers in your server farm. All servers running Windows SharePoint Services that are registered with the server farm are listed on this page. From this page, you can navigate to another server and continue managing or configuring Windows SharePoint Services for your servers.

Switch to the SharePoint Central Administration page for a different server
  1. On the SharePoint Central Administration page for your server farm, under Server Configuration, click Manage Web server list.
  2. On the Manage Web Server List page, click the name of the server you want to manage.

If you need to remove a server from your server farm (either temporarily or permanently), you can do so from the Manage Web Server List page. Removing a server from this list does not uninstall Windows SharePoint Services on that server, or make any sites on that server inaccessible. It simply removes it from the server farm, and because you are in a server farm, all sites are still accessible from other front-end Web servers in the server farm.

Remove a server from the list
  1. On the SharePoint Central Administration page for your server farm, under Server Configuration, click Manage Web server list.
  2. On the Manage Web Server List page, next to the server name you want to remove, click Remove.
  3. Click OK to remove the server.

Cleaning Up Old Logging Data

When you run Windows SharePoint Services, several processes generate log files that reside on the front-end Web servers in your server farm. To ensure that your servers are running as efficiently as possible, you should periodically delete this old data. The following table lists the types of log files used by servers running Windows SharePoint Services and where these types of log files are stored on the front-end Web servers.

Log file type Location
Usage analysis logs %Windows%\system32\LogFiles\STS
Stsadm.exe logs The %temp% directory for the user account running Stsadm.exe.
Smigrate.exe logs The %temp% directory for the user account running Smigrate.exe.
Windows SharePoint Services setup logs %Windows%\Temp
IIS logs

%Windows%\system32\LogFiles\Virtual_Server_ID

Where Virtual_Server_ID is the IIS ID for the virtual server, such as W3SVC1 for the default virtual server.

W3wp.exe logs

%Windows%\Temp\w3wpApplication_Pool_ID

Where Application_Pool_ID is the ID for the application pool, such as StsAdminAppPool for the default SharePoint Central Administration application pool.

For more information about the IIS and W3wp.exe logs, see the About Logging Site Activity topic in the IIS Help system.

 
 
Applies to:
Deployment Center 2003