Best practices for team collaboration sites

  • Article

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

This article is one of a series of Best Practices articles for Microsoft Office SharePoint Server 2007. This article describes the typical characteristics and best practices for hosting collaboration sites in an Office SharePoint Server 2007 environment. 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).

Team collaboration sites typically exhibit the following characteristics:

  • Write-operation intensive. Compared to other kinds of sites (such as publishing sites), there is a higher write ratio for the SQL Server storage tier for collaboration sites.

  • No or low content caching. Because content is more frequently updated and freshness is very important to collaboration dynamics, content caching is rarely used.

  • Most content is unstructured and non-uniform. Because collaboration sites are typically self-serve, the content is largely unstructured and not uniform in nature. Attempting to enforce a high level of content structure may deter users from adopting server-based collaboration.

  • Minimal custom solutions. Collaboration environments rarely allow deployment of solutions or custom code such as custom Web Parts, server controls, workflow actions, and InfoPath action forms. However, interaction with SharePoint Designer for custom authoring, branding, and designing simple workflow processes is expected.

  • Client application interaction is very important. Compared to other kinds of sites, collaboration sites have a greater level of interaction with client applications in the 2007 Microsoft Office system.

1. Deploy 64-bit architecture across the farm

64-bit hardware (for all server roles) offers the best performance for Office SharePoint Server 2007. 64-bit architecture provides significantly larger address space than 32-bit. Large address space provides more room for SharePoint assemblies, CLR/Native APIs, Network Stack, IIS/ASP.NET and other components hosted in respective tiers.

For more information, see Physical topology recommendations (Office SharePoint Server).

2. Plan and allocate database servers to support collaboration

Collaboration is characterized by its larger impact on SQL Server storage because of its relatively high write ratio and no cached content model. Therefore, optimize SQL Server for write operations and make sure that you have a dedicated database server for the farm. Follow the practices recommended in the following white paper to make sure that you have the SQL Server storage and performance that are required to support this kind of site: Planning and Monitoring SQL Server Storage for Office SharePoint Server: Performance Recommendations and Best Practices (white paper).

In a typical server computer that is running SQL Server (8 core, 16 gigabytes (GB) of RAM, 1 IOPS/GB), plan to support approximately 5 terabytes (TB) of content. For more information, see Design logical architecture for collaboration sites.

You should also lay out the disk drives for optimal performance. For more information, see Best practices for operational excellence.

3. Monitor sites and content and perform clean-ups regularly

Team sites are often self-service and loosely structured to make collaboration easier. Establish and communicate appropriate service level agreements (SLAs) for content archival and content deletion. Consider that team sites often have limited life spans that are determined by the projects they support. Use life-cycle management to remove and archive inactive sites regularly.

4. Enforce site and content size limits

Follow recommended guidelines for managing site collections, site, lists, and documents according to business needs, including the following:

  • 50,000 site collections per content database

  • 500 MB per site collection (default quota maximum)

  • 50 MB file size limit (recommended) up to 2 GB (maximum)

  • 2000 items per list view

Large lists, versioning, and workflows can affect both capacity of storage and performance of the environment. For example, some organizations turn off the Workflow History Cleanup Job as described in Disable automatic cleanup of workflow history (SharePoint Server 2007) to preserve workflow history for longer than 60 days. Be sure to use quotas to control site sizes, especially if you are enabling self-service site management.

For more information, see the following resources:

5. Plan for capacity plus one for front-end Web servers

If the environment serves approximately 5000 or more users, consider deploying a minimum of three front-end Web servers, or the number of front-end Web servers that are required to provide appropriate capacity plus one more. That way, when one front-end Web server is experiencing occasional high load, load balancers can route the traffic to other servers. In the case when there is only one remaining front-end Web server, this can cause a cascading outage in which the extra traffic that affected the first front-end Web server is transferred to the second front-end Web server, which brings it down too. Having an extra front-end Web server helps the farm to evenly consume such loads, therefore providing more performance and stability in the farm during such situations. This best practice is for the front-end Web servers that are serving user traffic. Additionally, use best practices for dedicating front-end Web servers to be crawled or standby farms. Note that these front-end Web servers should be physical servers, not virtual.

For more information, see Plan for redundancy (Office SharePoint Server).

6. Set application pool recycling settings for better availability

Office SharePoint Server 2007 requires that application pools be recycled regularly. Follow these recommendations to keep sites up and running, even when you have to recycle processes for application pools.

  • Recycle application pools at different times for different Web servers (64-bit and 32-bit). If you have multiple Web servers in the farm, make sure that the application pools are set to recycle at different times on different Web servers.

  • Recycle application pools at different times for different IIS Web sites (64-bit and 32-bit). Recycle different IIS Web sites at different times to avoid peaks on the Web servers. If you have to recycle more than one application pool on a specific Web server at the same time, temporarily remove that Web server from the load balancer to avoid bad user experience.

  • Consider memory usage for recycling (32-bit). When you plan application pool recycling, consider the amount of memory used by each application pool and change the frequency based on the amount of memory used. Application pools that ordinarily use low memory resources will need fewer recycles than others that use lots of memory. We recommend the following settings, although the numbers will vary by how you use the installation and the features that you are using:

    • Configure a virtual memory-based recycle to occur at 1700 MB.

    • Configure the memory used recycle to occur at 1000 MB.

    • Set the shutdown time limit to at least 300 seconds to allow for long-running user requests, such as large file uploads, an opportunity to be completed.

    • Use time-based recycles in environments with regular heavy loads at certain periods of the day. Set a scheduled recycle about 30 minutes before the peak traffic starts.

For more information, see the following resources:

7. Manage security and permissions

For each site collection, there is a limited number of security principals (users and groups) that can be applied (2000 per Web site). Use Active Directory security groups and SharePoint groups as much as you can to grant access, instead of adding users individually. For more information, see Plan for software boundaries (Office SharePoint Server).

Minimize the use of custom or fine-grained permissions. The more fine-grained permissions that are applied, the more difficult it is to track who has access to what. Moreover, fine-grained permissions can affect performance because additional security checks must be performed for each item to which they are applied. For more information, see Plan site security (Office SharePoint Server) and the following blog post: SharePoint Groups, Permissions, Site Security, and Depreciated Site Groups (https://go.microsoft.com/fwlink/?LinkId=123980&clcid=0x409).

Monitor access to elements in the site collections. Periodically review who has access to subsites, lists, libraries, and items. There are third-party security administration tools available that can help you discover the fine-grained permissions that are applied to elements in Office SharePoint Server 2007. One example is DeliverPoint (https://go.microsoft.com/fwlink/?LinkId=126308).

8. Test custom code and customizations

Before you deploy any custom code in the environment, get a baseline of the environment’s performance so that you can see how the custom element might affect the performance. Test the custom code thoroughly in a test or sandbox environment so that you can see how it will affect the environment. Never deploy custom code without testing it. Also test all code that you get from third parties or free resources. Just because it is free or already used widely does not mean it will not have unexpected effects in the environment, especially on performance. Use solution deployment to deploy all custom code so that you can easily track and re-deploy the customizations after you restore the environment.

For more information, see the following resources:

9. Watch out for network latency

Network latency can reduce user satisfaction by making even a high-performing environment feel slow. Attempting to collaborate on large files over a network that has high latency creates a frustrating user experience. Consider that even a small change to a document means that the complete document is uploaded to the 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 must be in the same time zone.

For multi-national and global enterprises, if the teams in the organization are typically centered around local geographies, deploy multiple, smaller team collaboration farms closer to end-users. This reduces network latency and WAN bandwidth costs. Consider using WAN acceleration or background caching with a product such as Microsoft Office Groove 2007 to help with latency issues.

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

10. Teach end-users how to get the most out of the tools

Most end-users are not Web site designers, nor do they want to be. For example, expect that they may start to use team collaboration sites but have little or no previous experience in configuring SharePoint sites or using built-in features such as linking of Contacts and Calendars to Outlook.

Microsoft provides ready access to online training and how-to materials on Office Online (https://go.microsoft.com/fwlink/?LinkID=89166&clcid=0x409). There is also an End-User Training Kit that you can deploy to the SharePoint environment available at Gear up. Drive awareness and usage of these materials in the organization so that users are better equipped to do things on their own. Doing so will lessen the number of calls to the help desk for routine tasks.

11. Comply with operational excellence best practices and have a governance policy

The Best practices for operational excellence article has more tips for setting up and maintaining the environment so that it performs at its best. Follow these best practices to benefit the most from collaboration sites.

Governance is important in collaboration environments. To keep collaboration sites manageable, make sure that you follow governance recommendations for consistent information architecture, education, taxonomy, and navigation. For more information, see the Governance Resource Center (https://go.microsoft.com/fwlink/?LinkID=92729&clcid=0x409) and the SharePoint Governance Checklist Guide (https://go.microsoft.com/fwlink/?LinkID=122806&clcid=0x409).

Acknowledgements

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

  • Simon Skaria, Microsoft SharePoint Customer Advisory Team

  • Luca Bandinelli, Microsoft SharePoint Customer Advisory Team

  • Steve Peschka, Microsoft Consulting Services

  • Larry Kuhn, Microsoft Consulting Services

  • Ali Mazaheri, Microsoft Consulting Services

  • Todd Carter, Microsoft Premiere Field Engineering

  • Sam Crewdson, Microsoft Hosted SharePoint

  • Cory Burns, Microsoft Hosted SharePoint

  • Mike Watson, Microsoft SharePoint Support and Health