Best practices for operational excellence

Article
01/10/2017

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

Topic Last Modified: 2016-11-14

Microsoft Office SharePoint Server 2007 is used for a broad set of applications and solutions, either stand-alone or in concert with other systems. To accomplish 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, and improvements included in the Infrastructure Update for Microsoft Office Servers.

This article is one of a series of Best Practices articles for Office SharePoint Server 2007. This article describes best practices for operational excellence. For more articles in the series, see Best practices. For additional information and resources regarding Best Practices for Office SharePoint Server 2007, see the Best Practices Resource Center (https://go.microsoft.com/fwlink/?LinkID=125981&clcid=0x409).

1. Use 64-bit hardware, plenty of memory, and fast network cards

64-bit hardware (for all server roles) offers the best performance for Office SharePoint Server 2007. In addition, make sure that you allocate appropriate memory for each server role:

Allocate at least 2 gigabytes (GB) of RAM per processor for front-end Web servers and application servers.
Allocate at least 4 GB of RAM per processor for database servers.
Use gigabit network cards for all server roles.
For front-end Web servers and application servers, use dual NICs in production environments: one for users, one for SQL Server communication.
Under heavy load, consider using virtual local area networks (vLANs) to reduce network traffic.

For more information, see Physical topology recommendations (Office SharePoint Server) and Additional performance and capacity planning factors (Office SharePoint Server).

2. Stay close: Do not put too much network distance between front-end Web servers, application servers, and database servers

No front-end Web server or application server should have more than 1 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 have to be in the same time zone.

For more information, see Plan for bandwidth requirements and Optimizing Office SharePoint Server for WAN environments.

3. Configure front-end Web servers and application servers with performance and availability in mind

The way you configure front-end Web servers and application servers can have a big effect on throughput and availability. Follow these recommendations for best results.

Separate system components into logical drives with the following RAID levels for redundancy:

Components on drive	Recommended RAID level
Windows and Program Files drive	RAID 1
Operating System swap drive	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/Program Files drive.
Allow at least one front-end Web server for every 20,000 users. Note that for high availability, you have to have two front-end Web servers for every 20,000 users.

For more information, see the following resources:

4. Configure database servers with performance and availability in mind

As is also the case with front-end Web servers and application servers, the configuration for database servers affects how well Office SharePoint Server 2007 performs. Separate each type of data onto individual spindle sets, with the appropriate RAID level, spindles, and optimization for each data type, as shown in the following table.

Type	RAID level	Spindles	Optimization
TempDB	[RAID 1+0] - 10% of total database size	2 IOPS/ GB	Write optimized
Transaction Logs	[RAID 1+0]	2 IOPS/GB	Write optimized
Search property store (Search database)	[RAID 1+0]	2 IOPS/GB	Read/Write optimized
Content databases	[RAID 1+0]	0.75 IOPS / GB	Read optimized

For more information, see Physical storage recommendations (Office SharePoint Server) and Planning and Monitoring SQL Server Storage for Office SharePoint Server: Performance Recommendations and Best Practices (white paper).

5. Keep it clean: Maintain databases in a healthy state

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 using SQL Server mirroring, do not store more than 50 databases on a single physical instance of SQL Server.
- Limit content databases to 100 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 appropriately and is not overloaded. Key performance counters to monitor include the following:
- Network Wait Queue: at 0 or 1 for good performance
- Average Disk Queue Length (latency): less than 5 ms
- Memory used: less than 70%
- Free disk space: more than 25%

For more information, see the following resources:

6. Keep servers current with the latest updates

It is important to keep current by applying the latest hotfixes, updates, and service packs. These updates contain important product enhancements and improvements. However, be sure that you thoroughly test these updates on the pre-production environments before you apply them to the production environments. Follow the recommended procedure for deploying 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, Windows SharePoint Services 3.0 and Office SharePoint Server 2007, and SQL Server.

For more information, view the presentation Understanding and deploying hotfixes, public updates, and service packs (https://go.microsoft.com/fwlink/?LinkId=123927&clcid=0x409), and see the Updates Resource Center for SharePoint Products and Technologies (https://go.microsoft.com/fwlink/?LinkID=106182&clcid=0x409).

7. Use different accounts for different actions

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 for each Web application.
Search account: Use one account for the farm.
Excel Services account: Use one account for external connections.

For more information, see Account permissions and security settings (Office SharePoint Server).

There are many more accounts that are used by Office SharePoint Server 2007, such as SQL Server services accounts, the Central Administration application pool identity, the Windows SharePoint Services 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.

For more information, see Change passwords used for administration accounts (Office SharePoint Server).

8. Follow recommendations for backing up and restoring data

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, SQL LightSpeed compresses during backup which can disrupt SQL Server performance.

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

For more information, see Tips for improving backup and recovery performance (Office SharePoint Server) and Data protection and recovery for Office SharePoint Server (White paper).

9. Be sure that you back up and truncate the log files

Do not just 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. 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.

For more information, see Back up logs (Office SharePoint Server 2007) and How to stop the transaction log of a SQL Server database from growing unexpectedly (https://go.microsoft.com/fwlink/?LinkID=111458&clcid=0x409).

10. Restoring data: Test backups and have a standby environment available for service continuity

Routinely test backups and validate their consistency. Do not assume that the backup will work when you need 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 running 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.

For more information, see Data protection and recovery for Office SharePoint Server (White paper).

Acknowledgements

The Office SharePoint Server 2007 Content Publishing team thanks the following contributors to this article:

Simon Skaria, Microsoft SharePoint Customer Advisory Team
Doron Bar-Caspi, Microsoft SharePoint Customer Advisory Team
Steve Peschka, Microsoft Consulting Services
Jason Cahill, Microsoft Office SharePoint Server Core
Mark Harmsworth, Microsoft Office SharePoint Server Core
Todd Carter, Microsoft Premiere Field Engineering
Cory Burns, Microsoft Hosted SharePoint

Share via