Plan for zones and URLs in an EPM/Office SharePoint Server 2007 extranet environment

更新时间: 2010年2月

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

This article describes how to plan for zones and URLs 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 环境的规划.

Zones and URLs

The model shows how to coordinate URLs across multiple applications in a corporate deployment.

Design goals

The following goals influence design decisions for URLs:

• URL conventions do not limit the zones through which content can be accessed.

• The standard HTTP and HTTPS ports (80 and 443) can be used across all applications in the model.

• Port numbers are not included in URLs. In practice, port numbers are typically not used in production environments.

Design principles

To achieve these design goals, the following design principles are applied:

• Host-named site collections are not used. Note that host-named site collections differ from IIS host headers. Host-named site collections do not work with the alternate access mappings feature. The alternate access mappings feature is required to access the same content through multiple domain URLs. Consequently, when host-named sites are used, these sites are available only through the Default zone. The alternate access mapping feature also provides support for out-of-the-box termination of Secure Sockets Layer (SSL), which enables the remote employee access and partner access scenarios to use SSL (https).

• Each application incorporates a single root site collection. This is required for using alternate access mappings. If multiple root site collections are required in a Web application and you expect to use only the Default zone for user access, host-named site collections are a good option.

• For the applications that include multiple high-level site collections, in which each site collection represents a top-level team or project (for example, team sites), the model incorporates managed paths. Managed paths provide greater control over URLs for these kinds of sites.

Design tradeoffs

Meeting the design goals results in some tradeoffs, including the following:

• URLs are longer.

• Host-named site collections are not used.

Designing load-balanced URLs

When you create a Web application, you must choose a load-balanced URL to assign to the application. Additionally, you must create a load-balanced URL for each zone that you create in a Web application. The load-balanced URL includes the protocol, scheme, host name, and port, if they are used. The load-balanced URL must be unique across all Web applications and zones. Consequently, each application and each zone within each application requires a unique URL across the model.

Intranet

Each of the three applications that compose the intranet requires a unique URL. In the model, the target audience for the intranet content is internal employees and remote employees. The following table lists the URLs for internal and remote employees to access each application.

Table 4. URLs for internal and remote employees

Using explicit and wildcard inclusions for URL paths

By defining managed paths, you can specify which paths in the URL namespace of a Web application are used for site collections. You can specify that one site collection or more than one site collection exists at a distinct path below the root site. Without managed paths, all sites created below the root site collection are part of the root site collection.

You can create the following two kinds of managed paths:

• Explicit inclusion   A site collection with the explicit URL that you assign. An explicit inclusion is applied to only one site collection. You can create many explicit inclusions below a root site collection. An example URL for a site collection created by using this method is http://fabrikam/hr.

• Wildcard inclusion   A path that is added to the URL. This path indicates that all sites that are specified directly after the path name are unique site collections. This option is typically used for applications that support self-site creation, such as My Sites. An example URL for a site collection created by using this method is http://my/personal/user1.

The model incorporates the use of both types as described in the following sections.

Explicit inclusions: Team sites and published intranet content

In the model, both the team sites application and the published intranet content applications incorporate the use of explicit inclusions.

Team sites

Within the Team Sites application an explicit inclusion is used for each team site collection. The scale limit on site collections created with an explicit inclusion is about 100 sites. Good governance practices recommend that you keep the number of top-level team sites within a manageable number. Also, the taxonomy for team sites should be logical for the way your business operates. Many organizations fit well within the 100 sites recommendation. If your organization requires greater scale for team sites, use a wildcard inclusion instead.

In the model, the use of explicit inclusions results in the URLs in the following table.

Table 5. Resulting URLs

In this example, the root site collection, http://team, does not necessarily host content for users.

Published intranet content

Within the published intranet content application, an explicit inclusion is used for each subsite: HR, Facilities, and Purchasing. This enables each of these sites to be managed independently. Each of these site collections can be associated with a different content database, if you need to, to manage growth and to provide the opportunity to back up and restore these sites separately.

In the model, the use of explicit inclusions results in the URLs in the following table.

Table 6. Resulting URLs

In this example, the root site collection, http://fabrikam, represents the default home page for the intranet. This site is intended to host content for users.

Wildcard inclusions: Partner Web and My Sites

Both Partner Web and My Sites incorporate the use of a wildcard inclusion. Wildcard inclusions are ideal for applications that let users create their own site collections. A wildcard inclusion indicates that the next item after the wildcard is a root site of a site collection.

My Sites

My Sites offer self-service site creation. When a user browsing the intranet first clicks My Site, a My Site is automatically created for the user. In the model, My Sites include a wildcard inclusion named /personal (http://my/personal). The My Site feature automatically appends the user name to the URL.

This results in URLs of the format listed in the following table.

Table 7. Resulting URLs

Partner Web

Partner Web helps employees to create sites that have security features for collaboration with external partners. To support this goal, self-service site creation is enabled.

In the model, Partner Web includes a wildcard inclusion named /sites (http://partnerweb/sites). This results in URLs of the format listed in the following table.

Table 8. Resulting URLs

Partner contributors can access Partner Web sites by using the URLs listed in the following table.

Table 9. Partner Web sites URLs

The exception for Partner Web, as illustrated in the model, is the two site collections that are dedicated to authoring and staging the content for the company Internet site. For these two site collections, an explicit inclusion is used. This provides an example of how to use both explicit inclusions and wildcard inclusions in the same Web application.

Administration URLs

The following table lists the URLs for the administration zone of each application hosted on the server farm.

Table 10. URLs for the administration zone

The model assumes that administrators have internal access to corporate network.