Plan for site collections in an EPM/Office SharePoint Server 2007 extranet environment

更新时间: 2010年2月

上一次修改主题： 2015-03-09

This article describes how to plan for site collections in an Enterprise Project Management (EPM)/ Microsoft Office SharePoint Server 2007 extranet environment. For an overview of this chapter about how to plan for EPM extranets, see Project Server 2007 Extranet 环境的规划.

Site collections

Site collections bridge logical architecture and information architecture. The design goals for site collections in the model are to satisfy requirements for URL design and to create logical divisions of content.

To satisfy the requirements for URL design, each Web application includes a single root-level site collection. Managed paths are used to incorporate a second tier of top-level site collections. For more information about URL requirements and using managed paths, see "Zones and URLs" later in this article. Beyond the second tier of site collections, each site is a subsite.

The following figure shows the site hierarchy of Team Sites.

Given the requirement for a root-level site collection, the design decisions revolve around the second tier of site collections. The model incorporates choices based on the nature of the application.

Published intranet content

The assumption for the published intranet content application is that multiple divisions within the company will host published content. In the model, each division's content is hosted in a separate site collection. This provides the following advantages:

• Each division can manage and permission their content independently.

• Each division's content can be stored in a dedicated database.

The disadvantages of using multiple site collections include the following:

• Master pages, page layouts, templates, Web Parts, and navigation cannot be shared across site collections.

• More effort is required to coordinate customizations and navigation across site collections.

Depending on the information architecture and design of the intranet application, the published content can appear to the user as a seamless application. Or, each site collection can appear to be a separate Web site.

My Sites

My Sites have distinct characteristics, and the recommendations for how to deploy My Sites are straightforward. In the model, the My Site application incorporates a top-level site that uses the URL of http://my. The first top-level site collection that is created uses the My Site Host template. A managed path is incorporated (by using wildcard inclusion), which allows an indefinite number of user-created sites. All sites below the managed path are independent site collections that inherit the My Site Host template. The user name is appended to the URL in the form http://my personal/username. The following figure illustrates My Sites.

For more information about how to design a My Sites application, see 设计“我的网站”体系结构.

Team sites

You can use either of the following two approaches for designing site collections in a Team Site application:

• Allow teams to create site collections through self-service site creation. The advantage of this approach is that 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.

• Create a finite number of site collections for your organization based on the way your organization operates. In this approach, site collections are created by a SharePoint administrator. After the site collection is created, teams can create sites within the site collection based on their needs. This approach provides 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.

The model incorporates the second approach, which results in a similar site collection hierarchy for team sites as for published intranet content. The challenge for information architects is to create a second tier of site collections that makes sense for the organization. The following table lists suggestions for different kinds of organizations.

Table 3. Different kinds of organizations

Partner Web

Partner Web is intended to be used for collaboration with external partners on projects that have finite scopes or finite durations. By design, sites within the Partner Web application are not intended to be related. The requirements for Partner Web include making sure of the following things:

• Project owners can easily create sites for partner collaboration.

• Partners and other contributors have access to only the project they work on.

• Permissions are managed by site owners.

• Search results from one project do not expose content from other projects.

• Administrators can easily find sites that are no longer used and delete these sites.

To satisfy these requirements, the model incorporates a site collection for each project. In this manner, the following benefits occur:

• Individual site collections provide the appropriate level of isolation between projects.

• Self-service site creation can be implemented.

Because the Partner Web application also hosts the site collections for developing content for the company Internet site, separate site collections are created for authoring and staging.