Microsoft SharePoint Foundation 2010 is used for a broad set of applications and solutions, either stand-alone or in concert with other systems. To achieve this flexibility, the platform supports lots of possible architectures and configurations. Some parts of the system are well-known, but we still see variances to these parts. This article focuses on the top configuration best practices that you should consider, such as front-end Web server configuration, database configuration, servicing, and patching.

This article is one of a series of best practices articles for SharePoint Foundation 2010. This article describes best practices for operational excellence. For more articles in the series, see Best practices (SharePoint Foundation 2010). For additional information and resources about Best Practices for SharePoint Foundation 2010, see the Best Practices Resource Center (http://go.microsoft.com/fwlink/p/?LinkId=221383).

No front-end Web server or application server should have more than one millisecond (ms) of latency between it and the database server. In practice, this generally means that you should keep all the servers in a farm in the same data center. All servers in a farm must be in the same time zone.

The way that you configure Web servers and application servers can have a big effect on throughput and availability. Follow the following recommendations for best results:

Separate system components into logical drives and use RAID for redundancy.

Components on drive

Recommended RAID level

Windows and program files drive

RAID 1

Operating system swap drive and temp directory

RAID 1

Log files

RAID 1

Boot disk for imaging and Windows Desktop Search (optional)

RAID 1

Use at least four physical disks and use separate disks to keep the log files and swap drive separate from the Windows and program files drive.

In most production environments, we recommend that you allocate at least 200 GB of disk space for the operating system and temporary files and 150 GB of disk space for logs.

Be sure to test the Web server capacity and provide sufficient servers for the number of users and requests that are in the farm. For high availability, make sure that you allocate an additional server so that you can pull one server out of a network load-balancing server farm and recycle it without affecting service availability.

As is also the case with Web servers and application servers, the configuration for database servers affects how well SharePoint Foundation 2010 performs. Certain databases require specific co-location with or separation from other databases.

The databases listed in the following table should be kept separate from other databases.

Database name

Size

Read/write optimization

Co-location

TempDB

Medium

Must be on a separate spindle from all other databases.

Secure Store

Small

Host on a separate database instance. Limit access to one administrator.

Usage

Extra large

Optimize for write

Must be on a separate spindle.

Note

The usage database can be on a separate server, and does not need performance to be as high as other databases. The speed of the usage database does not affect the performance of the site.

The databases in the following table must be stored in the same location as other databases.

A healthy database server has enough headroom for databases and log files, plus enough capacity to keep up with requests. Use the recommendations in the following list to keep database servers performing optimally.

Pre-grow all databases and logs if you can. Be sure to monitor the sizes so that you do not run out of disk space.

Do not overload database servers by using too many databases or data. Use the following guidelines:

When you use SQL Server mirroring, do not store more than 50 databases on a single physical instance of SQL Server .

Limit content databases to 200 GB.

Defragment and rebuild indices daily, if you can absorb the downtime required to rebuild.

Monitor the database server to make sure that it is responding correctly and is not overloaded. Key performance counters to monitor include the following:

It is important to keep current by applying the latest hotfixes, updates, and service packs. These updates contain important product enhancements and improvements. However, make sure that you thoroughly test these updates on the pre-production environments before you apply them to the production environments. Follow the recommended procedure to deploy the updates, including the following:

Turn on Windows Update to download updates automatically, but not install automatically.

Schedule time to install updates at off-peak hours.

For high availability, rotate servers out of service one at a time during the update process.

Make sure that you are patching the BIOS (server computers, controllers, and disks), Windows operating system, Microsoft SharePoint Foundation 2010 and SQL Server.

Use appropriate accounts for the Web applications and services. All accounts should be domain accounts. (Reminder: Do not use Network Service.) For best results, use separate accounts for the following:

Web applications: Use different accounts based on your security requirements.

Search account: Use one account for the farm.

There are many more accounts that are used by SharePoint Foundation 2010, such as SQL Server services accounts, the Central Administration application pool identity, the SharePoint Foundation Timer service account, the default content access account, the single sign-on account, and the profile import account. Be sure to follow recommended procedures to keep their passwords current and ensure that the services keep working.

In general, it is best to use a local disk, not a network drive, for backups, and then copy the data later. Use compression when you can, but when you use compression with backups, be mindful not to overwhelm SQL Server. For example, LiteSpeed for SQL Server compresses during backup, which can disrupt SQL Server performance.

For large databases, rely on incremental backups such as those available with System Center Data Protection Manager (DPM) 2010. Do not rely on full backups as your primary mechanism. They are too large to restore quickly.

Do not only back up the data. Back up the log files, too. The usage logs, IIS logs, transaction logs, and SMTP e-mail logs all must be backed up if you want to be able to fully recover your environment. For transaction logs, you should back up and truncate the log file every five minutes. However, never shrink the transaction log because you may experience performance issues while the log re-grows.

Routinely test backups and validate their consistency. Do not assume that the backup will work when you want it to. Make sure that it will. Practice recovery to learn what else you must do to bring back the whole environment. For geographically dispersed environments, prepare for disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Similarly, you can set up a standby environment that runs the same version of software as the production environment so that you can restore the databases and recover documents quickly. Keep databases small to speed recovery.