Design logical architecture for collaboration sites

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

In this article:

• About team sites within an intranet environment

• 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

In Microsoft Office SharePoint Portal Server 2003, team sites had limited functionality when compared to portal sites. This is not the case in Microsoft Office SharePoint Server 2007. In Office SharePoint Server 2007, collaborative sites within an intranet environment can take advantage of the same features as a published intranet portal site, if the features are made available in the intranet environment. For the purposes of this article, we will refer to such sites by the former term, "team sites." However, keep in mind that these sites are not restricted as to the features they can contain as they were in previous version. Rather, the term "team sites" implies that these sites are used by smaller groups or for more ad-hoc collaboration, unlike a published and controlled intranet portal site.

Team sites are an important part of most deployments of Office SharePoint Server 2007, and are particularly important to intranet deployments. The collaboration that team sites enable and the storage space they provide is useful for long-term and short-term projects, communication, and cross-group collaboration. If you plan to offer team sites as part of your deployment, you should include them in the initial architecture design, so you can plan to host and manage the sites. For example, you need 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 purposes.

This article provides logical architecture design recommendations for deploying team sites within a server farm. This article does not discuss the information architecture — that is, the internal structure — of team sites. For information about designing information architecture, see Plan Web site structure and publishing (Office SharePoint Server). For more information about team sites, see Plan for collaboration sites.

About team sites within an intranet environment

In a Office SharePoint Server 2007 intranet environment, team sites can be connected to your published intranet portal site by listing them in the Site Directory. You can create them through the Site Directory for the published site so that they share the same host name, or you can just add already-existing sites to the Site Directory to aggregate all related team sites in one place. No matter what their URLs, they can appear as a part of the published intranet portal in this way.

Because team sites are SharePoint sites that have the same feature set as any published sites in your environment, they can also use the business intelligence, forms, and other features available in your environment. These features can influence the architecture for your team sites. For example, if you need to display business data from the business data catalog in a team site, you must ensure that the members of that team site have access to view the data. Business intelligence features and security are configured at the Shared Services Provider (SSP) level, so all team sites that connect to the same business data must use the same SSP, and must be in Web applications associated with that SSP.

For more information about planning for business intelligence and forms in your environment, see the following resources:

• Plan for business intelligence

• Plan InfoPath Forms 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 ones, or expand their current team sites to contain more and more data. To manage or control this growth, you need to carefully plan your 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 types of sites within your 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

Host team sites either in a dedicated Web application, or in a Web application shared with My Sites. We recommend that you do not host team sites in the same Web application as a published intranet portal site. Keeping team sites separate from your intranet portal site provides easier data recovery and maintenance. (If you manage the size of the content databases, then this is less of an issue.) The following illustration shows the Web application that contains the team sites for an intranet solution:

You might want to use multiple, dedicated Web applications to host your team sites. Consider the following examples:

• An investment banking and equities research firm in the United States needs 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 needs to use two Web applications with isolated sets of team site collections for the two divisions. The firm also needs to use Web application policies and separate SSPs to ensure that users from each division do not see content produced by the other division.

• A research and manufacturing company needs 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, so 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 planning for extranets, see Design extranet farm topology (Office SharePoint Server).

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 model: Corporate deployment.

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 with similar data characteristics, Microsoft SQL Server database software operates more efficiently because SQL Server chooses a query plan based on the characteristics of a database. By contrast, if a database hosts sites with vastly different data characteristics, the query plan that SQL Server uses might not be the most efficient method for all content in the database. For example, if a database hosts team sites (that is, a large number of medium-sized sites) and portal sites (that is, a small number of very large sites with many requests), the chosen query plan will be inefficient for one of the types of sites. Therefore, by placing content for team sites in dedicated databases, you can optimize performance for SQL Server, which results in better performance for the overall server farm.

Consider manageability

By hosting team sites on a dedicated Web application, you can enhance 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 types of sites.

• You create the opportunity to negotiate a specific service-level agreement. For example, along with your 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 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. For example, team sites can share an application pool with My Sites because they both are used for collaboration, to store information and documents, and typically are scoped similarly for isolation purposes (that is, they are both available for the entire organization).

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

• To separate authenticated content from anonymous content.

• To isolate applications that store passwords for and interact with external business applications (for example, Business Data Catalog connections).

• To isolate applications where users have great liberty to create and administer sites and to collaborate on content.

For more information about when to have dedicated application pools, see Logical architecture model: Corporate deployment.

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 provides you with better scalability (with fewer application pools, you have fewer processes running), as well as 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 your performance planning recommends, and what your isolation requirements are.

Plan Web application general settings

There are several settings on the Web Application General Settings page that can assist in managing the growth of data and how current content is in team sites within your 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 your 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 in an Office SharePoint Server 2007 environment. 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 your 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 your organization.

For example, if your 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 your 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 your 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 your organization's team sites. To enhance manageability, only adjust quotas on a per-user basis when it is necessary to meet a business need.

Determine the maximum upload size

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

Determine Recycle Bin settings

Turning on the Recycle Bin is a simple way to enhance 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, so plan your 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 (30 days, by default). 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 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 your team sites centrally, or allow users to create their own site collections, 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:

• You lose the opportunity to implement a thoughtful taxonomy.

• The application can become difficult to manage.

• Sites are easily 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 your 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. With this approach, after the initial site collection has been created, teams can create sites within the site collection based on their needs. However, you are spending IT resources every time a user wants to create a site.

For examples of when to use each method, see Logical architecture model: Corporate deployment. For more information about planning for site creation, see Plan process for creating sites (Office SharePoint Server).

If your organization has chosen to create site collections for your team sites, rather than 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 determining 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. For more information about the types of sites available in Office SharePoint Server 2007, see Determine sites and subsites.

Design content database settings for team sites

In the Logical architecture model: Corporate deployment, team sites are stored in dedicated databases — one for each site collection. This approach 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.

Note, however, that SQL Server performance can be affected by the number of databases per each SQL Server instance. In other words, if you plan to have 300 or more team site collections, storing each in a dedicated database might degrade 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, you should store multiple site collections in each database. Note that 300 databases is the number used by the Microsoft IT department. Note that 300 databases is not a point of failure, but rather an estimate based on SharePoint Portal Server 2003 data, where 300 databases represented a level of confidence for Microsoft IT about how many site collections could safely be hosted on each server. Your number will vary based on a number of parameters including the number of databases. For example, whether or not to use dedicated databases can also depend on factors such as:

• 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 your teams expect a high level of autonomy and independence for operations that happen at the database level?

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

If you choose 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, so you may be creating too many content databases. Use the quota estimates as a consideration in database planning, but be sure to track your real usage and adapt. If you had a previous environment with SharePoint Portal Server 2003 or Windows SharePoint Services 2.0, you can also take a look at how big those site collections were, and create databases based on the actual site collection sizes rather than quota estimates.

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

• The time 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 your environment.

• The service window (that is, the amount of 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 amount of time.

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

Given the two values for volume of content (B and D), the maximum manageable database size for your 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.

When you create the Web application for your 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 your 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 with 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 to 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 in use 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 sending 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 your organization. Because this feature works by way of confirmations, and not by tracking actual use of the site, you need 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 an extended period of time.

Automatic site deletion can help you control your environment, but you risk that business-critical data might be stored in a site that was automatically deleted. To mitigate 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 your organization, there is still a contact available to confirm whether a site is in use. 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 business-critical information in them. Or, plan to store content databases long term in case a site that has been deleted needs to be restored at some point in the future.

Use paths or host names to organize team site URLs

Depending on your organization and how you are using team sites, consider using paths to organize the URLs for your 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. Similarly, or you could make the association with a published intranet site clear by using http://intranet_name/teamsites. If you are using Self-Service Site Management, the default URL for team sites is http://server_name/sites, but you could also create a wildcard inclusion for http://server_name/team or whatever prefix you prefer for your team sites.

For more information about paths, see the following resources:

• Plan for collaboration sites

• Determine sites and subsites

• "Using explicit and wildcard inclusions for URL paths" in Logical architecture model: Corporate deployment

• 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 your organization. For example, if your human resources Web site is a team site and is not part of your published intranet 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 your environment, particularly when you consider that you want to test all solution packs several times: before you deploy them, when you need to apply an update, and when you are ready to upgrade your environment. You should decide what your 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 your environment.

• Manageability   If you need to back up and restore your entire environment (such as in a disaster recovery scenario or if you are moving hardware), you need to have backups for all custom elements (such as a custom Web Part that was developed for your environment or a custom site definition) and remember to add them back to your environment again when you restore. This is because you cannot restore the configuration database, which contains all of the references to these custom elements, so you must add them back in to your restored environment. For example, you need 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 need to track down the code you need while your users wait.

• Supportability   Having custom elements in your 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 impact is on the system. Also, consider how you can rule out the customizations as part of the root cause of a problem when troubleshooting. If you are creating the custom code yourself, be sure to design it so that any errors from your customizations are logged in both the event log — for Microsoft Operations Manager (MOM) events — and any other location that your organization uses for troubleshooting, so you can troubleshoot the errors.

• Usability   Consider the usability of your solutions, Web Parts, and templates. If you have so many custom templates for team sites in your 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 need 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 choose to have more than one policy about customizations. For example, they can choose to have a two-tiered or three-tiered system, with level 1 being plain sites (using 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 where you might want multiple Web applications to host your 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.

Download this book

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

• Planning and architecture for Office SharePoint Server 2007, part 2

See the full list of available books at Downloadable content for Office SharePoint Server 2007.