Best practices for team collaboration sites (SharePoint Server 2010)
Applies to: SharePoint Server 2010
This article is one of a series of best practices articles for Microsoft SharePoint Server 2010. This article describes the typical characteristics and best practices for hosting collaboration sites in a SharePoint Server 2010 environment. For additional information and resources about best practices for SharePoint Server 2010, see Best Practices for SharePoint Server 2010 (https://go.microsoft.com/fwlink/p/?LinkId=220280).
SharePoint Server 2010 makes team collaboration easier with features such as My Sites, blogs, wikis, and co-authoring. When you plan for team collaboration sites, remember that these sites typically exhibit the following characteristics:
Write-operation intensive Compared to other kinds of sites (such as publishing sites), there is a larger write ratio for Microsoft SQL Server resources for collaboration sites.
No-content or low-content caching Because content is more frequently updated and freshness is very important to the dynamics of collaboration, content caching is rarely used.
Client application interaction is very important Compared to other kinds of sites, collaboration sites have a greater level of interaction with client applications in Microsoft Office 2010.
Each of the following sections describes best practices for team collaboration sites.
1. Plan and allocate database servers to support collaboration
Collaboration is characterized by the significant effect it has on Microsoft SQL Server resources, such as memory and CPU, because of its relatively high write ratio and content model that does not use caching. The practices recommended in the following white paper will help you ensure that you have the SQL Server resources 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).
Plan and configure storage and capacity according to your estimated content size. For more information, see Hardware and software requirements (SharePoint Server 2010) and Storage and SQL Server capacity planning and configuration (SharePoint Server 2010).
You should also lay out the disk drives for optimal performance. For more information, see Best practices for operational excellence (SharePoint Server 2010).
2. Monitor sites and content, and perform cleanups regularly
When team sites are loosely structured, it tends to make collaboration easier. Establish and communicate appropriate service level agreements (SLAs) for archiving and deleting content. Consider that teams often use self-service site creation to collaborate about projects that have limited life spans. Use life-cycle management to remove and archive inactive sites regularly.
Identify and monitor large lists, files, and sites. This includes lists that have lots of items (more than tens of thousands) or many fields, operations that involve very large files (more than 50 MB), and items that have undergone many revisions. For more information, see the following resources:
Monitor Web Part statistics, site activity (last updated, last read), and disk storage to determine site health. The Microsoft SharePoint 2010 Products Management Pack for System Center Operations Manager 2007 (https://go.microsoft.com/fwlink/p/?LinkID=203252) can help you monitor the environment.
Watch for orphaned sites (that is, sites that are not listed in the configuration database, or sites that are listed in the configuration database but do not exist). Orphaned sites can cause problems when it is time to apply updates or perform database maintenance tasks. Detect and clean them up by using the Stsadm databaserepair operation. For more information, see Databaserepair: Stsadm operation (Office SharePoint Server).
3. Enforce site and content size limits
Follow recommended guidelines for managing site collections, sites, lists, and documents according to business needs.
Large lists, versioning, and workflows can affect both the storage capacity and performance of the environment. For example, some organizations turn off the Workflow History Cleanup Job as described in Disable preservation of workflow history (SharePoint Server 2010) 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 creation.
For more information, see the following resources:
4. Manage security and permissions
For each site collection, you can apply security principals (users and groups). Because these security principals can affect the performance of your farm, use groups and roles as much as you can to grant access, instead of adding users individually. For more information, see SharePoint Server 2010 capacity management: Software boundaries and limits.
Minimize the use of custom or fine-grained permissions. The more fine-grained permissions that you apply, 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 Best practices for using fine-grained permissions (white paper) (SharePoint Server 2010).
Periodically review who has access to subsites, lists, libraries, and items. You can use third-party security administration tools to help you discover the fine-grained permissions that are applied to elements in SharePoint Server 2010. One example is Lightning Tools (https://go.microsoft.com/fwlink/p/?LinkID=220248).
5. Use one or more dedicated Web applications to host team sites
To host team collaboration sites on a dedicated Web application has several advantages:
Optimize performance When you host team sites on a dedicated Web application, you have several content databases that contain only team site collections. If content databases host sites that have similar data characteristics, SQL Server database software operates more efficiently because SQL Server uses a query plan based on the characteristics of the database. Therefore, by putting content for team sites in dedicated databases, you can optimize performance for SQL Server, which results in better performance for the overall server farm.
Optimize manageability Because creating separate Web applications results in separate sites and databases, you can implement different site limits (recycle bin, expiration, and size) and negotiate different service-level agreements. For example, you might allow more time to restore self-service sites if this is not the most important kind of content within your organization. This lets you restore more important content before you restore these sites.
Enforce permissions A dedicated Web application provides the opportunity to enforce permissions on the Web application level. For example, you can create a policy on internal collaboration sites to explicitly deny access to partner accounts. Policies for a Web application are enforced regardless of permissions configured on individual sites or documents within the Web application.
For more information, see the Web applications section in the Logical architecture components (SharePoint Server 2010) article.
6. Watch out for high network latency
High 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.
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 multinational 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 by using a product such as Microsoft Groove Server 2010 to help with latency issues.
For more information, see the Four fundamentals of performance section in the Capacity management and sizing overview for SharePoint Server 2010 article.
7. 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. 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 Contacts and Calendars to Microsoft Outlook 2010. Microsoft provides ready access to online training and how-to materials on Office.com (https://go.microsoft.com/fwlink/p/?LinkID=89166). There is also an End-User Training Kit that you can deploy to the SharePoint environment available at the Productivity Hub 2010 (https://go.microsoft.com/fwlink/p/?LinkId=220249). 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.
8. Ensure that you have a governance policy
Governance is important in collaboration environments. To keep collaboration sites manageable, ensure that you follow governance recommendations for consistent information architecture, education, taxonomy, and navigation. For more information, see Governance in SharePoint Server 2010 (https://go.microsoft.com/fwlink/p/?LinkID=220213), Plan site maintenance and management (SharePoint Server 2010), and SharePoint Server 2010 Operations Framework and Checklists (white paper).
9. Manage content to improve team collaboration
Because collaboration sites are typically self-serve, the content can be unstructured and is generally not uniform. Therefore, it might be a good idea to take advantage of a feature such as metadata navigation to help filter and find user content in document libraries. Also, if you use the manage metadata service, you can ensure uniformity in the taxonomy of your organization. For more information, see Metadata navigation overview (SharePoint Server 2010).
The SharePoint Server 2010 Content Publishing team thanks the following contributors to this article:
Aaron Saikovski, Microsoft Consulting Services
Bryan Porter, Microsoft Consulting Services
Israel Vega, Microsoft Consulting Services
Steve Caravajal, Microsoft Technical Sales
Steve Peschka, Microsoft Consulting Services
Steve Walker, Microsoft SharePoint Customer Engineering
Tajeshwar Singh, Microsoft Consulting Services