Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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. |
Microsoft 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 , you need to make certain choices about configuring your environment, and you need to be aware of how works in that environment. This topic explains those choices, and describes how to work with 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 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 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 https://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 administration tasks.
Replicating Configuration Settings
Most changes to configuration settings in are replicated automatically, without requiring software such as Microsoft Application Center. For example, when you change the e-mail server for , 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 .
You must install directly to any server computers that you want to include as front-end Web servers in your server farm.
Extending a virtual server with .
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.
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. 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 :
Software solutions, such as Network Load Balancing
Network Load Balancing is included with Microsoft . This method is inexpensive, but offers only limited scalability. For more information about Network Load Balancing, see your 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 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 scalablemethod and it provides the best use of your front-end Web server resources.
You do not need to perform any configuration steps to make 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 .
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 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 for your servers.
Switch to the SharePoint Central Administration page for a different server
On the SharePoint Central Administration page for your server farm, under Server Configuration , click Manage Web server list .
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 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
On the SharePoint Central Administration page for your server farm, under Server Configuration , click Manage Web server list .
On the Manage Web Server List page, next to the server name you want to remove, click Remove .
Click OK to remove the server.
Cleaning Up Old Logging Data
When you run , 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 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. |
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.