Design logical architecture for collaboration sites (Windows SharePoint Services)

Applies To: Windows SharePoint Services 3.0

 

Topic Last Modified: 2009-04-15

In this article:

• Team sites design recommendations

• Host team sites in a dedicated Web application

• Plan Web application general settings

• Choose whether to allow users to create site collections

• Design content database settings for team sites

• Automatically delete sites that are not used

• Use paths to organize team site URLs

• Plan for custom elements

• Plan the permissions to apply to team sites

The collaboration that team sites enable and the storage space that they provide is useful for long-term and short-term projects, communication, and cross-group collaboration. When you create the initial architecture design for the server farms, you have to plan for hosting and managing team sites. For example, you have to plan for the content databases needed to host the team site content, plan for archiving and deleting short-term project team sites to make way for more projects, and monitor team communication sites to ensure that their sizes are manageable for backup and recovery.

This article contains logical architecture design recommendations for deploying team sites in a server farm. This article does not discuss the information architecture — that is, the internal structure — of team sites. For information about how to design information architecture, see Plan Web site structure and publishing (Windows SharePoint Services).

Team sites design recommendations

In most organizations, the number of team sites increases and the sizes of individual team sites grow, sometimes rather quickly. As teams reorganize or as projects complete and new projects start, teams create new team sites and abandon old sites, or expand their current team sites to contain more data. To manage or control this growth, you have to carefully plan support for team sites.

Design goals for team sites include:

• Optimizing performance of the overall server farm.

• Creating logical divisions of databases for team sites for ongoing maintenance (that is, backup, recovery, and upgrade).

• Enabling you to apply appropriate policies and settings for team sites without affecting other kinds of sites within the intranet.

Design guidance for team sites includes the following recommendations, each of which is elaborated in the following sections:

• Host team sites in a dedicated Web application.

• Apply Web application general settings, such as quota and life-cycle management settings at the Web application level to manage growth of team sites and to keep content current.

• Design content database settings for appropriate storage and scale and to ensure that you can back up and restore databases of the designed size.

• Automatically delete sites that are not used.

• Use paths to organize team site URLs.

• Plan for appropriate policies and permissions.

Host team sites in a dedicated Web application

Use one or more dedicated Web applications to host the team sites. Consider the following examples:

• An investment banking and equities research firm in the United States has to keep sites for the investment banking division and the equities research division completely isolated to comply with U.S. Securities and Exchange Commission regulations. In this example, the firm has to use two Web applications that have isolated sets of team site collections for the two divisions. The firm also has to use Web application policies to ensure that users from each division do not see content produced by the other division.

• A research and manufacturing company has to keep tight control over its intellectual property and research findings. In this example, the company can host the research team sites in a separate Web application and use Web application policies to enforce permissions and ensure that only research staff sees the content in the research team sites.

• An organization hosts both internal (intranet) and external (extranet) team sites and wants to implement and manage them differently. In this example, the organization plans and implements two separate Web applications to host the two sets of team sites. In this way, it can have different authentication methods, different databases, and different IIS logs for each environment in case there is an issue. For more information about how to plan for extranets, see Design extranet farm topology (Windows SharePoint Services).

Generally speaking, use dedicated Web applications to:

• Separate anonymous content from authenticated content.

• Isolate users.

• Enforce permissions.

• Optimize performance.

• Optimize manageability.

For more information about deciding whether to have shared or dedicated Web applications, see Logical architecture sample design: collaboration sites.

Consider 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, Microsoft SQL Server 2005 database software operates more efficiently because SQL Server 2005 uses a query plan based on the characteristics of a database. By contrast, if a database hosts sites that have significantly different data characteristics, the query plan that SQL Server 2005 uses might not be the most efficient method for all content in the database. Therefore, by putting content for team sites in dedicated databases, you can optimize performance for SQL Server 2005, which results in better performance for the overall server farm.

Consider manageability

By hosting team sites on a dedicated Web application, you can improve manageability in the following ways:

• You can separately manage the following items:

  • Database settings

  • Quota templates

  • Recycle Bin settings

  • Automated actions for unused sites

  • Authentication

  • Policies

• You can more effectively manage the growth of team sites by managing team sites separately from other kinds of sites.

• You create the opportunity to negotiate a specific service-level agreement. For example, together with a service-level agreement to store weekly full backups and daily differential backups of the content databases, you could offer quicker turnaround on recovery of individual items of content by using the second-stage Recycle Bin.

Choose an application pool

In a corporate environment, team sites can share an application pool with Web applications that have similar collaboration and isolation requirements.

Generally speaking, you must have a dedicated application pool when you want to do any of the following:

• Separate authenticated content from anonymous content.

• Isolate applications where users have great liberty to create and manage sites and to collaborate on content.

For more information about when to have dedicated application pools, see Logical architecture sample design: collaboration sites.

In a hosting environment in which content for multiple organizations is hosted on a single server farm, we recommend that you host all content for a single organization in the same application pool. This gives you better scalability (with fewer application pools, you have fewer processes running), and process isolation between the application pools (so that if Customer A's application pool stops, it does not affect Customer B's sites). This, of course, depends on how many organizations you have, what performance planning recommends, and what the isolation requirements are.

Plan Web application general settings

There are several settings on the Web Application General Settings page that can help you to manage the growth of data and how current content is in team sites within the environment. These settings are applied to all sites within a Web application. At a minimum, plan to implement the following settings, each of which is discussed later in this section:

• Define and apply a quota template to limit the maximum size of team sites.

• Establish a maximum upload size. Choose a generous size based on business requirements so users can easily collaborate.

• Turn on the site Recycle Bins and use the second-stage Recycle Bin.

In addition to the settings listed previously, evaluate all feature settings on the Web Application General Settings page to ensure that the features are appropriate for team sites in the organization. By default the following features are enabled:

• Person name smart tag and online status (online presence information is displayed)

• Alerts (users can create a maximum of 500 alerts, by default)

• Really Simple Syndication (RSS) feeds

• Blog application programming interface (API) (link to create a blog)

Determine quota template settings

There is no default quota template for team sites. However, the following settings are recommended as a starting point:

• Automated e-mail is sent to a site owner when the size of the site reaches 450 megabytes (MB).

• Users are prevented from uploading additional documents when the size of a site reaches 500 MB.

These settings might work well for the organization, but you should evaluate the size and number of items that you expect users to store in team sites and adjust these settings as appropriate to ensure that team sites are used as intended in the organization.

For example, if the organization includes research or design teams that collaborate together to produce a large volume of content that needs to be stored and archived, consider increasing quota limits — for example, increase the site limit to 5 or 10 gigabytes (GB). In these scenarios, hosting the content on team sites ensures that the content is backed up regularly and that all those individuals who need to contribute to it can do so. You might also consider putting a site collection of the 5-10 GB size into it its own content database, especially if you expect that site collection to grow rapidly.

On the other hand, if team sites are mostly used for short-term projects or team communication sites, consider using a lower quota limit. This encourages teams to store only the information needed to keep short-term projects moving forward (however, be sure not to lower it too far, or you risk an increase in costs associated with help-desk requests to increase the quotas). In this scenario, you encourage teams to store general team content or content for a new project in separate team sites.

If a particular team or group in the organization has a business need to store a greater volume of content on its team site, you can adjust the quota limits for an individual site collection. To adjust quota limits, on the Site Collection Quotas and Locks page, select the site collection that corresponds to the team or group. Change the current quota template to Individual Quota, and then specify the limits that are appropriate.

When planning for quota templates, choose limits that work for most of the organization's team sites. To improve manageability, only adjust quotas on a per-user basis when you must meet a business need.

Determine the maximum upload size

The default maximum upload size is 50 MB. 50 MB is considered a generous limit that gives users the flexibility of uploading many types and sizes of documents without adversely affecting performance. If users in the organization have to store larger files in their team sites, consider adjusting this setting, and be sure to monitor the IIS time-out settings if you have users who have slower connections.

Determine Recycle Bin settings

Turning on the Recycle Bin is a simple way to improve manageability of team sites. The Recycle Bin enables site owners to retrieve items that they have deleted without requiring central administrative intervention (that is, restoring from backup tapes).

The following list describes the default settings for the Recycle Bin, which work well for most organizations:

• Recycle Bin Status: On

• Delete items in the Recycle Bin: After 30 days

• Second-stage Recycle Bin: Add 50 percent of live site quota for second stage deleted items

The second-stage Recycle Bin stores items that users have deleted from their Recycle Bins. Only site collection administrators can restore items from the second-stage Recycle Bin. The size that is specified for the second-stage Recycle Bin increases the total size of the team site. For example, if the team site limit is 500 MB and the second-stage Recycle Bin is set to 50 percent, the total amount that can be used by the site is 750 MB. Therefore, plan database capacity accordingly.

Just as with the Recycle Bin, items in the second-stage Recycle Bin are automatically deleted when the time period for deleted items is reached (by default, 30 days). However, when the size limit of the second-stage Recycle Bin is reached, items are automatically deleted from the second-stage Recycle Bin starting with the oldest items. Site collection administrators can also empty the second-stage Recycle Bin manually.

Key considerations when you are using the Recycle Bin feature are whether to use the second-stage Recycle Bin and how much space to allocate. Consider allocating at least a small amount of space (such as 10%) to the second-stage Recycle Bin to accommodate cases in which a user deletes an important document, a folder in a document library, or a column in a list by mistake.

Plan site creation method

You can decide whether to create site collections for team sites centrally, or allow users to create their own site collections by using Self-Service Site Management. There are tradeoffs to each approach.

If you allow teams to create site collections through self-service site management, teams can easily create a site, as needed, without assistance from an administrator. However, there are many disadvantages to this approach, including the following:

• You lose the opportunity to implement a thoughtful taxonomy.

• The application can become difficult to manage.

• Sites can easily be abandoned.

• You cannot share templates and navigation across projects or teams that might otherwise share a site collection.

If you instead create site collections centrally, based on the way the organization operates, you gain the opportunity to implement a thoughtful taxonomy that provides structure to the way team sites are managed and grow. There is also more opportunity to share templates and navigation between projects and teams that share a site collection. By using this approach, after the initial site collection is created, teams can create sites within the site collection based on their needs. However, you are spending IT resources every time that a user wants to create a site.

For examples of when to use each method, see Logical architecture sample design: collaboration sites. For more information about how to plan for site creation, see Plan process for creating sites (Windows SharePoint Services).

If the organization has decided to create site collections for team sites instead of allowing users to create their own team site collections, use the Site paths worksheet (https://go.microsoft.com/fwlink/?LinkId=73149) to determine the level at which team sites are created: top-level sites in their own site collections, or one large site collection with multiple subsites. For more information about how to determine whether to create many site collections or only a few site collections with many subsites, see "Decide whether to use individual site collections or subsites within one site collection" in Determine sites and subsites needed (Windows SharePoint Services) in the Windows SharePoint Services 3.0 Technical Library.

Design content database settings for team sites

Depending on scale and manageability considerations, you can use dedicated content databases for each site collection or group multiple site collections into one or more content databases. Using a dedicated content database for each site collection enables you to manage each site collection database independently for backup, recovery, and migration. Also, when a project is complete, you can easily archive the database associated with the project. Although by using this approach you create many databases, you gain the ability to individually control the database for each site collection.

However, realize that SQL Server performance can be affected by the number of databases per each instance of SQL Server. In other words, if you plan to have 300 or more team site collections, storing each in a dedicated database might decrease SQL Server performance. This is because each database represents a connection between the application pool and SQL Server. When you add Web servers and databases, the number of active connections increases. If you add too many connections, SQL Server can become non-responsive.

Therefore, if you plan to have more than 300 team site collections, you should not use dedicated databases. Instead, store multiple site collections in each database. 300 databases is the number that is used by the Microsoft IT department. Note that 300 databases is not a point of failure. Instead, it is an estimate based on Windows SharePoint Services 3.0 data, where 300 databases represented a level of confidence for Microsoft IT about how many site collections could safely be hosted on each server. The number will vary based on several parameters including the number of databases. For example, whether to use dedicated databases can also depend on factors such as the following:

• Do teams have different service-level agreements (such as different backup requirements)?

• Do teams require more than 8 GB of storage?

• Do teams have different project timelines? Mixing teams with short projects with teams with long projects might make it difficult to archive sites and move them out of the production environment if they share the same database.

• Do teams expect a high level of autonomy and independence for operations that occur at the database level?

For any of these, if you answer yes, you should consider dedicated databases for site collections.

If you decide to store multiple site collections in each database, you can calculate how many to store in each database by determining the maximum size for any one database and the maximum size for each site collection (based on the quota template storage limit value plus the Recycle Bin allocation). Note that even if you give everyone 500 MB quotas, not everyone will use the full quota. Therefore, you may be creating too many content databases. Use the quota estimates as a consideration in database planning, but be sure to track real usage and adapt. If you had a previous environment that used Windows SharePoint Services 2.0, you can also consider how big those site collections were, and create databases based on the actual site collection sizes instead of on quota estimates.

In a managed environment, database size limits are often determined by the following two factors:

• The time that is required to back up a database. Beyond a certain database size, backup operations become inefficient, require more time than is practical, and become subject to other disruptions. This may also be the point at which you decide to add more database servers to the environment.

• The service window (that is, the time) allowed for restoring content, as determined by the service-level agreement. For example, if the service window for restoring content is four hours, the size of the database is limited to a volume that can be restored within this time.

To determine the maximum manageable database size for team site collections, determine the values listed in the following table.

Item	Factor	Value
A	Service window for restoring content	hr
B	Volume of content that can be restored within the service window, given the chosen recovery method and tools	GB
C	Target time window for backing up databases	hr
D	Volume of content that can be backed up within the target window, given the chosen backup method and tools	GB

Given the two values for volume of content (B and D), the maximum manageable database size for the organization is the lesser of the two values.

After you determine the target size for content databases, you can calculate the number of site collections that can be supported in each database. The following table shows the number of site collections per database based on database size and site collection size limits. Site collection size limits include the space allocated to the second-stage Recycle Bin.

Database size	500 MB site collection size limit	750 MB site collection size limit	1 GB site collection size limit	2 GB site collection size limit	5 GB site collection size limit	10 GB site collection size limit
25 GB	50	33	25	12	5	2
50 GB	100	66	50	25	10	5
100 GB	200	133	100	50	20	10
200 GB	400	266	200	100	40	20
500 GB	800	533	500	250	100	50
1 Terabyte	1,600	1,066	1,000	500	200	100

When you create the Web application for team sites, modify the settings by using the Manage Content Databases page for the first content database with the maximum number of site collections that corresponds to the database size target and site collection size limits (Maximum Number of Sites). Also specify the threshold for the number of sites that triggers a warning (Site Level Warning). When the site level warning is reached, create a new database that has the same settings. When the maximum number of site collections is reached, no new site collections are created within the database. If another database has not been created, site creation fails.

Automatically delete sites that are not used

You can increase the currency of content in team sites by automatically deleting sites that are not used. This can also help you control the overall growth of team sites. If team sites are hosted in a separate Web application, you can manage unused team sites differently than personal sites, such as by giving them a longer life span before you start querying for unused Web sites.

By default, settings for automatically deleting sites are not enabled. To manage site deletion settings, on the Application Management page, in the SharePoint Site Management section, click Site use confirmation and deletion.

If you enable this feature, default settings include the following:

• E-mail notifications are sent to owners of site collections 90 days after site collection creation, or use is confirmed. In other words, if a site has not been confirmed as being used for 90 days, the site owner receives a notification.

• The system checks for unconfirmed site collections and sends notices daily at midnight.

• The option to automatically delete unconfirmed site collections is not selected. If this setting is selected, sites are automatically deleted after the system sends 28 notices. Alternatively, you can specify the number of notices.

Given the default settings, a site collection that has not been used for 90 days is deleted after 28 notices, or 118 days after the last confirmation of the site. You can specify settings that are appropriate for the organization. Because this feature works by way of confirmations, and not by tracking actual use of the site, you have to plan for unexpected absences of site owners and not set the expiration and deletion times for sites for short durations. Also, be sure to always have multiple site collection administrators so that you have a backup administrator to confirm site use if the primary site collection administrator is out for a long time.

Automatic site deletion can help you control the environment. However, you risk that business-critical data might be stored in a site that was automatically deleted. To reduce this risk, we recommend that you:

• Require a secondary contact for all sites. By so doing, if the site owner is not available or leaves the organization, there is still a contact available to confirm whether a site is being used. If you do not have a secondary contact and you shorten the number of days or number of notices given before deleting an unused site, you risk accidentally deleting a site that is needed. Implement this recommendation when you turn on Self-Service Site Management, or as a business process for creating site collections from Central Administration.

• Archive sites before they are deleted automatically. Many organizations that implement automatic deletion of unused sites also invest in developing a tool that archives all sites before they are deleted automatically so that they can be easily restored if there is important information in them. Or, plan to store content databases long term in case a site that was deleted has to be restored sometime in the future.

Use paths or host names to organize team site URLs

Depending on the organization and how you are using team sites, consider using paths to organize the URLs for team sites. For example, if you want different URLs for team sites associated with different divisions, you could use URLs such as http://company_name/division_name/sites or http://company_name/research/sites. If you are using Self-Service Site Management, the default URL for team sites is https://server_name/sites. However, you could also create a wildcard inclusion for https://server_name/team or whatever prefix you prefer for the team sites.

For more information about paths, see the following resources:

• Determine paths for sites (Windows SharePoint Services)

• Determine sites and subsites needed (Windows SharePoint Services)

• White paper: Create shared hosting solutions on Windows SharePoint Services (https://go.microsoft.com/fwlink/?LinkId=86128&clcid=0x409)

You can also create host-named sites if you have team sites that serve a larger role in the organization. For example, if the human resources Web site is a team site, you might want to create a host-named team site for that site called http://hrsite or http://humanresources.

Plan for custom elements

Customizations can add complexity to the environment, especially when you consider that you want to test all solution packs several times: before you deploy them, when you must apply an update, and when you are ready to upgrade the environment. You should decide what the organization's policy will be toward using custom features, templates, Web Parts, and so on, and plan for the manageability, supportability, and usability of these elements in the environment.

• Manageability   If you have to back up and restore the complete environment (such as in a disaster recovery scenario or if you are moving hardware), you must have backups for all custom elements (such as a custom Web Part that was developed for the environment or a custom site definition) and remember to add them back to the environment again when you restore. This is because you cannot restore the configuration database, which contains all of the references to these custom elements. Therefore, you must add them back in to the restored environment. For example, you have to add back the custom site definitions and install the custom Web Parts. If you forget a custom element when you move to a new server or restore a server, you can cause errors in users' team sites and you will have to track down the code that you need while users wait.

• Supportability   Having custom elements in the environment can add to troubleshooting time when something goes wrong. Each custom piece of code is unique, and can be either complex or simple, and can consume additional memory to run. Consider the number of places the custom code is used and what its effect is on the system. Also, consider how you can exclude the customizations as part of the cause of a problem when troubleshooting. If you are creating the custom code, be sure to design it so that any errors from the customizations are logged in both the event log — for Microsoft Operations Manager (MOM) events — and any other location that the organization uses for troubleshooting so that you can troubleshoot the errors.

• Usability   Consider the usability of solutions, Web Parts, and templates. If you have so many custom templates for team sites in the environment that the list of templates or Web Parts scrolls for multiple screens (for example, 50 is too many to read and differentiate), consider whether you must have all those custom elements, whether you can break the list up in some way, or whether you should roll them up into common feature packs for easier browsing and tracking.

Some organizations decide to have more than one policy about customizations. For example, they can decide to have a two-tiered or three-tiered system, with level 1 being plain sites (that use standard templates only), level 2 allowing for some customizations (with a different service-level agreement), and level 3 wherein the organization hosts the hardware, but the team that owns the team sites is responsible for running and managing their own customized environment on that hardware. This is another case in which you might want multiple Web applications to host team sites, with different service-level agreements for each Web application.

Plan the permissions to apply to team sites

The permissions and policies that you apply to team sites determine:

• Who can create team sites.

• Who can view and contribute to team sites.

• Who is prevented from accessing content on team sites.

We recommend that you use security groups to manage permissions. The following table provides guidance for configuring permissions and indicates where permissions are configured.

Permission	Guidance	Configuration
Create team site collections	By default, only members of the Farm Administrators group can create site collections for team sites. If you want more users to be able to create team site collections, use the Self-Service Site Management feature in Central Administration. For more information, see Plan process for creating sites (Windows SharePoint Services). Alternatively, you can enable Self-Service Site Management for a subset of people in the organization by turning on self-service site management, but limiting the Self-Service Site Creation permission to one or more security groups, or by limiting access to the Self-Service Site Management New SharePoint Site page (Scsignup.aspx) to specific security groups.	On the Central Administration site, on the Application Management page, in the Application Security section, click Self-service site management. Users and groups that have the Use Self-Service Site Creation permission can create site collections when self-service site management is turned on.
Create subsites within site collections	By default, members of a team site who have the Create Subsites permission (included in the Full Control permission level) can create subsites in a site collection. We recommend that you allow site owners to manage permissions for creating subsites, instead of globally preventing users from creating subsites.	On the Site Settings page, add or delete members who belong to the Owners group.
View and contribute to team sites	Even if an employee is prevented from creating a team site, they can still view and contribute to documents on other team sites, based on the permissions that site owners apply. We recommend that you allow site owners to manage permissions to content on their sites, instead of globally preventing users from participating in this kind of collaboration.	On the Site Settings page, add or delete members who belong to the Visitors group.
Cannot access team site content	You can block users in the organization from accessing team site content completely by creating a policy for the Web application. Use this option cautiously because this prevents all collaboration on team sites that have the users who are blocked. A policy on the Web application overrides any other permissions that are configured within the Web application.	On the Application Management page, in the Application Security section, click Policy for Web application. On the Policy for Web Application page, select the users whom you want to block, click Edit Permissions of Selected Users, and then on the Edit Users page, in the Permission Policy Levels section, select Deny All.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

• Planning and architecture for Windows SharePoint Services 3.0, part 2

See the full list of available books at Downloadable books for Windows SharePoint Services.