Design sample: collaboration sites (SharePoint Foundation 2010)
Applies to: SharePoint Foundation 2010
This article describes a practical implementation of logical architecture components to achieve a workable design. This article is intended to be used together with the following design samples:
Design sample: collaboration sites with classic authentication
Design sample: collaboration sites with claims-based authentication
To download either of these models, see SharePoint Foundation 2010 design samples: collaboration with classic authentication or with claims-based authentication (https://go.microsoft.com/fwlink/p/?LinkId=219157).
In this article:
About the design samples
Overall design goals
Server farms
Users, zones, and authentication
Administration sites
Services
Application pools
Web applications
Site collections
Content databases
Zones and URLs
Zone policies
The design samples show a generic corporate deployment of SharePoint Foundation 2010. The design samples apply almost all of the logical architecture components and show how these are incorporated into the overall design. The two samples show the same services and sites, but incorporate different authentication methods, as follows:
Classic authentication: This design sample represents a path for upgrading sites from Windows SharePoint Services 3.0 to SharePoint Foundation 2010. This sample incorporates classic authentication, in which Windows authentication methods are used to access sites. A different zone for each authentication method is used. Although Windows authentication is used for SharePoint sites, a firewall or gateway product can be configured to use forms-based authentication to collect Windows credentials that are forwarded to SharePoint Foundation 2010. Partner employee accounts are added to the corporate directory.
Claims-based authentication: This design sample incorporates the new claims-based authentication model. Multiple authentication providers and authentication types are implemented in a single zone. Claims-based authentication supports forms-based authentication, SAML token-based authentication, and Windows authentication. This design example adds partner companies by using SAML token-based authentication to authenticate directly against partner directories. There are several provider options for partner employee accounts.
Use the design sample that best represents your requirements for authentication.
This article describes the design goals for the samples and explains how these goals are achieved by using the logical architecture components illustrated in the samples.
About the design samples
The design samples show a deployment for a fictitious company named Fabrikam, Inc. If you are planning a solution with one or more of the kinds of collaboration sites represented in this model, you can use the model as a basis for your own design.
The model shows a generic deployment of SharePoint Foundation 2010 and represents the three following kinds of collaboration sites:
Team sites
Self-service sites
Partner collaboration sites
The design samples apply almost all the logical architecture components and show how these components are incorporated into the overall design. This article describes the design goals for the samples and explains how these goals are achieved by using the logical architecture components illustrated in the model.
Each of the different kinds of collaboration sites:
Hosts data with different data characteristics.
Is subject to a different usage profile.
Requires a different permissions management strategy.
Consequently, the design choices in the model are intended to optimize the performance and security for each application.
Team sites
Team sites represent highly structured and managed collaboration sites that have the following characteristics:
There is a smaller number of top-level site collections, and these site collections are intended to include a large amount of data (compared to self-service sites).
Top-level URLs are meaningful for each team.
More consideration is given to site hierarchies, taxonomies, and customizations.
Each team’s content is in a separate database and can be managed separately.
Self-service sites
Self-service sites provide an alternative to highly managed team sites. You can enable users and teams to create their own site collections by using Self-Service Site Management. You turn on Self-Service Site Management in Central Administration. This method is best used when you want to enable groups or communities to create sites. This method also works well if you are hosting sites and want to let users create sites without waiting for a detailed process.
The characteristics of self-service sites are typically different from highly managed sites. Characteristics might include the following:
Large number of top-level site collections
Small amount of data per site collection
URLs that are automatically generated but typically not meaningful
There are several tradeoffs to be aware of when planning to implement self-service sites. The tradeoffs in the following list will affect how you manage self-service sites:
Instead of implementing a thoughtful taxonomy, sites are created at will without an organizing principle across sites. Because each new site is a site collection, templates and navigation cannot be shared across self-service sites.
Because each site collection provides search only for content on that site collection, there is no aggregation of search results across site collections.
Site collections can vary greatly in size and use.
Sites can be easily abandoned.
Managing self-service sites can include managing content storage based on the target size of content databases and regularly deleting sites that are no longer used.
For more information about how to implement Self-Service Site Management, see Turn on or turn off self-service site creation (SharePoint Foundation 2010).
Partner collaboration sites
The partner Web application hosts externally available sites for secure collaboration with partner companies and individual partners. This application is intended for employees to easily create sites for secure collaboration. Partners are not able to access other kinds of content hosted on the server farm. The design for zones and service applications addresses this goal. Additionally, individual site owners manage permissions for their sites, inviting only necessary participants to collaborate.
Overall design goals
The model shows a practical implementation of SharePoint Foundation 2010 features within several different kinds of collaboration applications (team sites, self-service sites, and partner sites). The design implementations for each site application are discussed in this article. The key design goals for the model include the following:
Create a framework for designing an environment that can grow. Design decisions for individual collaboration applications do not prevent the addition of other applications. For example, an initial deployment might include only collaborative team sites or only partner sites. By using a similar logical architecture design, you can add the other kinds of collaboration sites to the solution without affecting the design of the initial collaboration sites. In other words, the design does not incorporate design choices that limit the use of the environment.
Provide access for several classes of users without compromising the security of the content within the different collaboration applications. Users from different network zones (both internal and external) with different authentication providers can participate in collaboration. Also, users can only access the content they are intended to access. By following a similar logical architecture design, you create the opportunity to provide access to users in multiple locations and with different objectives. For example, your initial design might be intended only for internal employee access. However, by using a similar design you can enable access to remote employees, partner employees, or even customers.
Ensure that the design can be used in an extranet environment. You can make deliberate design choices to ensure that the server farms can be securely deployed in a perimeter network or within any of the extranet topologies.
The rest of this article discusses each logical component that appears in the model (from top to bottom) and discusses the design choices that are applied to the model. The purpose of this approach is to demonstrate the different ways in which logical architecture components can be configured based on the application.
Server farms
The model shows a five-server farm. However, the model could be implemented on any size farm, including a single server. The server farm in the model is composed of five servers in the following topology:
Two front-end Web servers
One application server for the search server or service applications (optional)
Two database servers, either clustered or mirrored
The model shows the logical architecture of SharePoint Foundation 2010 by showing the following:
All sites are mirrored across front-end Web servers.
The Central Administration Web site is installed on an application server to protect it from direct user access.
In reality, the number of server computers and the topology of the server farm are not important to the logical architecture, except to increase capacity and performance, as needed. The logical architecture can be designed independent of the server-farm topology. The performance and capacity planning process will help you size the server farm to meet performance and capacity goals. For more information, see Performance and capacity test results and recommendations (SharePoint Foundation 2010).
Users, zones, and authentication
When you create a Web application in SharePoint Foundation 2010, you must select either claims-based authentication or classic-mode authentication. The authentication mode determines how accounts are used internally by SharePoint Foundation 2010. The following table summarizes the two approaches.
Type of authentication |
Description |
Recommendations |
Classic-mode authentication |
User accounts are treated by SharePoint Foundation 2010 as traditional Active Directory Domain Services (AD DS) accounts. The following authentication protocols are supported: Kerberos, NTLM, Basic, Digest, and Anonymous. Forms-based authentication is not supported. Only one authentication method can be configured on a zone. |
Classic mode is recommended for upgrading environments from Windows SharePoint Services 3.0, in which forms-based authentication is not a requirement. If you are upgrading, you do not need to run user migration if you select classic-mode authentication. |
Claims-based authentication |
User accounts are treated by SharePoint Foundation 2010 as claims identities. Windows accounts are automatically converted to claims identities. This mode additionally supports forms-based authentication and authentication against a trusted identity provider. Multiple authentication types can be configured on a single zone. |
Claims-based authentication is recommended for new SharePoint Foundation 2010 deployments. It is required for upgrading Windows SharePoint Services 3.0 solutions that require forms-based authentication. |
The two design samples that are discussed in this article represent these two options. The following sections specifically discuss how authentication is incorporated into the two design samples.
Classic-mode authentication design sample
The design sample that uses classic-mode authentication incorporates the traditional one-zone-per-type of authentication approach that was used in the previous release. For this reason, this example provides a path for upgrading from Windows SharePoint Services 3.0 to SharePoint Foundation 2010.
The one issue is that forms-based authentication is not supported in classic mode. When you use classic-mode authentication, all authenticated accounts must reside within Active Directory Domain Services (AD DS). The recommendation for users who are accessing sites remotely is to use forms-based authentication on the firewall or gateway product to collect Windows credentials that are forwarded to the SharePoint farm.
The classic-mode sample shows three classes of users, each assigned to a different zone. Within each Web application, you can create as many as five zones that use one of the available zone names: Default, Intranet, Internet, Custom, or Extranet.
The following table shows the zones, users, and authentication types prescribed by the classic-mode design sample.
| Zone | Users | Authentication |
|---|---|---|
Intranet |
Internal employees |
NTLM or Kerberos |
Default |
Remote employees |
NTLM or Kerberos (using forms-based authentication on the firewall or gateway product to collect and forward the credentials) |
Extranet |
Individual partners |
NTLM or Kerberos (using forms-based authentication on the firewall or gateway product to collect and forward the credentials) |
Claims-based authentication design sample
Claims-based authentication is recommended for all new deployments of SharePoint Foundation 2010 and is required for upgrading Windows SharePoint Services 3.0 solutions that require forms-based authentication. In addition to providing the standard Windows authentication methods, claims-based authentication enables you to authenticate against other directories, such as Windows Live ID, Active Directory Federation Services (AD FS) 2.0, or a third-party identity provider that supports SAML tokens and the WS Federation protocol.
In the claims-based authentication design sample, claims-based authentication is used on the collaborative farm. Claims-based authentication enables multiple kinds of authentication to be used in the same zone. The design sample uses the Default zone for all authentication types. The following table shows the zones, users, and authentication types that are prescribed by the sample for the collaborative farm.
| Zone | Users | Authentication |
|---|---|---|
Intranet |
Internal and remote employees |
AD DS (or LDAP store with forms-based authentication or SAML authentication) |
Default |
Individual partners |
Windows Live with SAML authentication; or SQL Server database with forms-based authentication |
Extranet |
Partner companies |
Trusted partner identity provider with SAML authentication |
In the design sample, team sites and self-service sites are only available to employees, whether they are inside or outside the network. The design sample implements only one URL (which uses SSL) for each of these sites that can be used both internally and externally. AD DS accounts are used. If needed, LDAP can be used with either forms-based authentication or SAML, which requires additional configuration.
In the design sample, the partner Web application represents an extranet site that is available to partner employees and partner companies. Using claims-based authentication in this scenario requires that trust be configured to use one or more external secure token services (STS). This can be provided by using either of the following approaches:
The SharePoint farm can be configured to trust an external STS, such as the STS associated with Windows Live (for authenticating individual partners) or the STS that resides in a partner company (for authenticating directly against the partner directory).
The STS inside the corporate environment can be configured to trust an external STS. This relationship must be established explicitly by administrators in the two organizations. In this scenario, the SharePoint farm is configured to trust only the STS that resides in its own corporate environment. This internal STS verifies the token it receives from the external STS and then issues a token that allows the partner user to access the SharePoint farm. This is the recommended approach.
An alternative to implementing a claims-based environment to authenticate partners is to use forms-based authentication and manage these accounts by using a separate store, such as a database.
For more information about how to implement a claims-based authentication environment, see the following white paper: Claims-based Identity for Windows: An Introduction to Active Directory Federation Services 2.0, Windows CardSpace 2.0, and Windows Identity Foundation (https://go.microsoft.com/fwlink/p/?LinkId=196776).
Zones
When you design zones, several key decisions are important to the success of the deployment. These decisions include design and configuration decisions for the following zones:
The Default zone
Zones for external access
The following sections describe the decisions that are incorporate into the model.
Configuration requirements of the Default zone
The zone that involves the greatest consideration is the Default zone. SharePoint Foundation 2010 includes the following requirements on how the Default zone is configured:
When a user request cannot be associated with a zone, the authentication and policies of the Default zone are applied. Consequently, the Default zone must be the most secure zone.
Administrative e-mail is sent with links to the Default zone. These include e-mail messages to owners of sites that are approaching quota limits. Consequently, users who receive these kinds of messages and alerts must be able to access links through the Default zone. This is especially important for site owners.
Host-named site collections are available only through the Default zone. All users who are intended to access host-named site collections must have access through the Default zone.
Configuring zones for an extranet environment
In an extranet environment, the design of zones is very important for the following two reasons:
User requests can be initiated from several different networks. In the model, users initiate requests from the internal network, the Internet, and partner companies.
Users can participate in collaboration across multiple Web applications. For example, internal and remote employees can potentially contribute to and administer content across all of the Web applications: team sites, self-service sites, and partner Web.
In an extranet environment, ensure that the following design principles are followed:
Configure zones across multiple Web applications to mirror one another. The configuration of authentication and the intended users should be the same. However, the policies associated with zones can differ across Web applications. For example, ensure that the Intranet zone is used for the same employees across all Web applications. In other words, do not configure the Intranet zone for internal employees in one Web application and remote employees in another.
Configure alternate access mappings appropriately and accurately for each zone and each resource.
In the design samples, the Default zone for each Web application is configured identically. Additionally, other zones are configured identically across all Web applications, as needed.
Alternate access mappings are automatically created when you create the zone. However, if you use a proxy server or gateway product to make sites available from the Internet, you will have to add an additional alternate access mapping entry for each zone. This ensures that URLs that are returned to users outside the internal network are available to users according to the context of their zone.
If zones across Web applications do not mirror one another, and links to external resources are incorrect, the risks include the following:
Server names, Domain Name System (DNS) names, and IP addresses can potentially be exposed outside the internal network.
Users might be unable to access Web sites and other resources.
Administration sites
In the model, the Central Administration site is hosted on the application server. This protects the site from direct user contact. If a performance bottleneck or security compromise affects the availability of the front-end Web servers, the Central Administration site remains available. Additionally, the Central Administration site is hosted inside a dedicated application pool and Web application.
The load-balanced URLs for the administration sites are not articulated in the model or in this article. Recommendations include the following:
If port numbers are used in administrative URLs, use non-standard ports. By default, port numbers are included in URLs. Although port numbers are typically not used in customer-facing URLs, using port numbers for administration sites can increase security by limiting access to these sites to non-standard ports.
Create separate DNS entries for administration sites.
Services
The services architecture that is illustrated in the model only represents the two service applications that are included with SharePoint Foundation 2010. The two service groupings (represented by using a red box and a blue-dashed box) are not required in the given example because they include the same two service applications. However, consider which service applications are necessary for partner Web sites and configure the two service groups accordingly. Options to consider include the following:
Consider whether a separate instance of the Business Data Connectivity service application is necessary for partner Web sites. If it is necessary, consider deploying this service application for partner sites in partitioned mode. This ensures that partners do not have access to data across partner sites.
Third-party companies can develop service applications for SharePoint Foundation 2010. If you are using these, decide whether they are appropriate to use across all sites.
Application pools
Separate Internet Information Services (IIS)application pools are typically implemented to achieve process isolation between sites. Application pools enable multiple sites to run on the same server computer but still have their own worker processes and identity. This mitigates any possible security issues on one site that enable an attacker to inject code onto the server to attack other sites.
Practically speaking, consider using a dedicated application pool for the following scenarios:
To separate authenticated content from anonymous content.
To isolate sites that are primarily for collaboration with external partners or customers. This isolates external accounts to sites within one application pool.
To isolate sites where users have more freedom to create and administer sites and to collaborate on content.
The model uses application pools in the following way:
The administration site is hosted in a dedicated application pool. This is required by SharePoint Foundation 2010.
All service applications are deployed to a single application pool. Unless there is a compelling reason to deploy service applications to different application pools, this is the recommended configuration. Using one application pool for all service applications optimizes performance and reduces the number of application pools to manage.
The internal collaboration sites (team sites and self-service sites) are hosted in one application pool.
The partner Web application is hosted in a dedicated application pool.
Web applications
A Web application is an IIS Web site that is created and used by SharePoint 2010 Products. Each Web application is represented by a different Web site in IIS. You assign each Web application a unique domain name, which helps prevent cross-site scripting attacks.
Generally speaking, use dedicated Web applications to do the following:
Separate anonymous content from authenticated content.
Isolate users. In the model, partner Web is hosted in a dedicated Web application and application pool to ensure that partners do not have access to the internal collaboration content.
Enforce permissions. A dedicated Web application provides the opportunity to enforce permissions by using the Policy for Web Application page in Central Administration. For example, you can create a policy on the 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.
Optimize performance. Sites achieve better performance if they are put in Web applications together with other applications of similar data characteristics. For example, the data characteristics of self-service sites include many small sites. In contrast, team sites typically consist of a smaller number of very large sites. By putting these two kinds of sites in separate Web applications, the resulting databases are composed of data with similar characteristics, which optimizes database performance. In the model, team sites and self-service sites do not have unique data isolation requirements; they share the same application pool. Nonetheless, team sites and self-service sites are put in separate Web applications to optimize performance.
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 enables you to restore more important content before you restore these sites. In the model, self-service sites are put in a separate Web application to enable administrators to more aggressively manage growth compared to other applications.
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.
.gif "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.
Self-service sites
In the model, the self-service sites incorporate a top-level site that has the URL of http://sites. A managed path is incorporated (by using wildcard inclusion), which allows an indefinite number of user-created sites. All sites under the managed path are independent site collections that inherit the site template that was used to create the top-level site.
For more information about self-service sites, see Plan process for creating sites (SharePoint Foundation 2010).
Team sites
When you design site collections within a team site application, we recommend that you create a finite number of site collections for the organization based on the way the organization operates. In this approach, site collections are created by a SharePoint Foundation 2010 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 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.
| Type of organization | Suggested site collection taxonomies |
|---|---|
Product development |
|
Research |
|
Higher education institution |
|
State legislative office |
|
Corporate law office |
|
Manufacturing |
|
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 ensuring the following:
Project owners can easily create sites for partner collaboration.
Partners and other contributors have access to only the projects they work on.
Permissions are managed by site owners.
Search results from one project do not expose content from other projects.
Administrators can easily discover sites that are no longer used and delete these sites.
To satisfy these requirements, the model incorporates a site collection for each project, which provides the following benefits:
Individual site collections provide the appropriate level of isolation between projects.
Self-service site creation can be implemented.
Content databases
You can use two approaches to incorporate content databases into the design. The model incorporates both of the following approaches:
Establish target sizes for content databases with appropriate size warning thresholds. Create a new database when size warning thresholds are reached. With this approach, site collections are automatically added to the available database or databases, based on size targets alone.
Associate site collections to specific content databases. This approach enables you to put one or more site collections in a dedicated database that can be managed independently from the rest.
If you decide to associate site collections to specific content databases, you can use the following methods to do this:
Use Windows PowerShell to create a site collection in a specific database.
Dedicate a database to a single site collection by applying the following database capacity settings:
Number of sites before a Warning event is generated = 1
Maximum number of sites that can be created in this database = 1
Add a group of site collections to a dedicated database by following these steps:
Within the Web application, create the database and set the database status to Ready.
Set the status of all other databases to Offline. While content databases are offline, new site collections cannot be created. However, existing site collections in offline databases are still available for both read and write operations.
Create the site collections. They are automatically added to the database.
Set the status of all other databases back to Ready.
Team sites
The design sample incorporates a dedicated database for each team site collection. This approach enables you to manage each team's database independently for backup, restore, and migration. Also, when a project is complete, you can easily archive the database associated with the project. The design sample provides database settings based on a 30-GB limit for site collections. Choose a limit that is appropriate for team sites in your organization.
Self-service sites
For self-service sites, the model achieves scale efficiency by managing databases to the maximum target size. The following settings are configured to achieve this goal:
Limit site storage to a maximum of This setting, which you configure on the Quota Templates page in Central Administration, limits the size of a site.
**Second stage Recycle Bin **This setting, which you configure on the Web Application General Settings page, determines how much additional space is allocated to the second-stage Recycle Bin.
**Maximum number of sites that can be created in this database **This setting is configured when you create a database. Calculate the total allowable size of sites by using the numbers that you specify for the previous two values. Then, based on the size goal for each database, determine how many sites will fit into the database.
The design sample provides the following example size settings based on a target database size of 175 gigabytes (GB) and a target My Site size of 1 GB:
Site size limits per site = 1 GB
Target size of database = 175 GB
Reserved for second-stage Recycle Bin = 15 percent
Maximum number of sites = 180
Site level warning = 150
When the site level warning is reached, create a new database. After you create the new database, new self-service sites are added alternately to the new database and the existing database until the maximum number of sites for one of the databases is reached.
Partner Web
Similar to self-service sites, partner Web achieves scale efficiency by managing databases to the maximum target size.
Because partner Web is hosted in a dedicated Web application, you can create size limits that are appropriate to the kinds of sites that are created. The design sample provides the following example size settings:
Target size of database = 200 GB
Storage quota per site = 5 GB
Maximum number of sites = 40
Zones and URLs
The model shows how to coordinate URLs across multiple applications within 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 design sample.
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.
Each application incorporates a single root site collection. This is required for using alternate access mappings. If multiple root site collections are required within 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 more 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 select a load-balanced URL to assign to the application. Additionally, you must create a load-balanced URL for each zone that you create within a Web application. The load-balanced URL includes the protocol, scheme, host name, and port. 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 design sample.
Internal collaboration sites
The two kinds of internal collaboration sites each require a unique URL. In the design sample, the target audience for the intranet content is internal employees and remote employees. In the claims-based authentication design sample, employees use the same URLs for each of these applications regardless of whether they are on site or remote. While this approach adds a layer of security to the design (all traffic is SSL), this approach requires either routing internal traffic through the firewall or gateway product together with remote traffic or setting up a split DNS environment to resolve internal requests within the internal network.
For the classic authentication design sample, the URLs are different for internal and remote employees. The following table shows the URLs for internal and remote employees to access each application in the classic authentication design sample.
| Application | Internal employee URL | Remote employee URL |
|---|---|---|
Team sites |
http://teams |
https://teams.fabrikam.com |
Self-service sites |
http://sites |
https://sites.fabrikam.com |
Partner Web
In the design sample, the partner Web site is accessed by internal employees, remote employees, and partner employees. In the claims-based authentication design sample, each user enters the same URL, regardless of the authentication method. In the classic authentication design sample, each different kind of user enters a different URL. Although both remote employees and partner employees access the partner Web site externally by using SSL (HTTPS), each group requires a different URL to apply the benefits of using separate zones. Those benefits are different authentication methods and different zone policies. The following table shows the URLs that internal employees, remote employees, and partners use to access the partner Web site, as shown in the classic authentication design sample.
| Zone | URL |
|---|---|
Internal employee URL |
http://partnerweb |
Remote employee URL |
https://remotepartnerweb.fabrikam.com |
Partner URL |
https://partnerweb.fabrikam.com |
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 under the root site. Without managed paths, all sites that are created under 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 under a root site collection. An example URL for a site collection that is created by using this method is http://team/team1. There is a performance impact for every explicit path that is added. Therefore, we recommend that you to limit the number of site collections that are created with an explicit inclusion to about 20.
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. An example URL for a site collection that is created by using this method is http://sites/selfservice/site1.
The design sample incorporates the use of both types as described in the following sections.
Explicit inclusions
The design sample does not currently incorporate the use of explicit inclusions. The following table provides an example set of URLs for a Fabrikam intranet site that uses classic authentication in which URLs are different for internal access and remote access of employees.
| Internal employee (Intranet zone) | Remote employee (Default zone) |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/hr |
https://intranet.fabrikam.com/hr |
http://fabrikam/facilities |
https://intranet.fabrikam.com/facilities |
http://fabrikam/purchasing |
https://intranet.fabrikam.com/purchasing |
In this example, the root site collection, http://fabrikam, represents the default home page for the intranet. This site can host content for users. The next site in the path, for example, http://fabrikam/hr and http://fabrikam/facilities, is the explicit inclusion.
Wildcard inclusions: team sites, self-service sites, and partner Web
Team sites, self-service sites, and the partner Web application incorporate the use of a wildcard inclusion. Wildcard inclusions are ideal for applications that enable users to create their own site collections and for Web applications that include many site collections. A wildcard inclusion indicates that the next item after the wildcard is a root site of a site collection.
Team sites
Within the team sites application, wildcard inclusion is used for each team site collection. 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.
In the classic authentication design sample, the use of wildcard inclusions results in the URLs shown in the following table.
| Internal employee (Intranet zone) | Remote employee (Default zone) |
|---|---|
http://teams/sites/team1 |
https://teams.fabrikam.com/sites/team1 |
http://teams/sites/team2 |
https://teams.fabrikam.com/sites/team2 |
http://teams/sites/team3 |
https://teams.fabrikam.com/sites/team3 |
In this example, the root site collection, http://team, does not necessarily host content for users.
Self-service sites
In the model, self-service sites include a wildcard inclusion named /selfservice (http://sites/selfservice).
This results in URLs in the format listed in the following table.
| Internal (Intranet zone) | Remote employee (Default zone) |
|---|---|
http://sites/selfservice/site1 |
https://sites.fabrikam.com/selfservice/site1 |
http://sites/selfservice/site2 |
https://sites.fabrikam.com/selfservice/site2 |
http://sites/selfservice/site3 |
https://sites.fabrikam.com/selfservice/site3 |
Partner Web
Partner Web is designed to enable employees to easily create sites for collaboration with external partners. To support this goal, self-service site creation is enabled.
In the classic authentication design sample, the partner Web application includes a wildcard inclusion named /sites (http://partnerweb/sites). This results in URLs in the format shown in the following table.
| Internal employee (Intranet zone) | Remote employee (Default zone) |
|---|---|
http://partnerweb/sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb/sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb/sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
Partner contributors can access partner Web sites by using the URLs listed in the following table.
| Partner (Extranet zone) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb.fabrikam.com/sites/project3 |
Coordinating URLs with AAM and DNS
Configure alternate access mappings for each site URL in the farm. This ensures that Web requests are mapped to the correct site, especially in environments that use load balancing or reverse proxy technologies.
The following table lists the necessary information for creating or modifying alternate access mappings based on the classic authentication version of the logical architecture design sample.
| Site | Host header | Zone | Port | AAM public URL |
|---|---|---|---|---|
| Team sites | teams | Intranet | 80 | http://teams |
| teams.fabrikam.com | Default | 443 | https://teams.fabrikam.com | |
| Self-service sites | sites | Intranet | 80 | http://sites |
| sites.fabrikam.com | Default | 443 | https://sites.fabrikam.com | |
| Partner Web | partnerweb | Intranet | 80 | http://partnerweb |
| remotepartnerweb.fabrikam.com | Default | 443 | https://remotepartnerweb.fabrikam.com | |
| partnerweb.fabrikam.com | Extranet | 443 | https://partnerweb.fabrikam.com |
Single-name URLs, such as http://teams, can be configured for intranet access. These URLs are resolved by the client by appending the client’s DNS suffix, such as fabrikam.com, and then issuing a DNS lookup for the name with the suffix. For example, when a client computer in the fabrikam.com domain requests http://teams, the computer sends a request to DNS for http://teams.fabrikam.com.
DNS must be configured to use an A record for each fully qualified domain name (FQDN). The A record points to the load-balanced IP address for the Web servers that are hosting a site. In a typical production deployment, servers are configured to use statically assigned IP addresses, in addition to statically assigned A records in DNS.
After receiving the virtual IP address of the load balancer, the client browser establishes communication with a front-end Web server in the farm, then sends an HTTP request with the original single-name URL, http://teams. IIS and SharePoint 2010 Products recognize this as a request for the Intranet zone, based on the settings configured in alternate access mappings (see the previous table). If the user had instead requested https://teams.fabrikam.com, the process would be the same except that IISand SharePoint 2010 Products would receive this FQDN instead, and therefore recognize this request for the Default zone.
In environments that have multiple domains, enter CNAME records for DNS in the domains that the sites do not reside in. For example, if the Fabrikam network environment includes a second domain named europe.fabrikam.com, CNAME records are entered for these sites in the Europe domain. For the team sites intranet site (http://teams), a CNAME record named teams is added to the europe.fabrikam.com domain that points to teams.fabrikam.com. Then, when a client’s DNS suffix is appended to DNS lookup requests, a request for http://teams from the Europe domain will issue a DNS lookup of teams.europe.fabrikam.com, and be directed by the CNAME record to teams.fabrikam.com.
Note
There is a known issue with some Kerberos clients and resolving CNAME records. For more information, see Kerberos configuration known issues (SharePoint Server 2010).
Zone policies
You can create a policy for a Web application to enforce permissions at the Web application level. A policy can be defined for the Web application generally or only for a specific zone. A policy enforces permissions on all content within the Web application or the zone. Policy permissions override all other security settings that are configured for sites and content. You can configure policy based on users or user groups, but not SharePoint groups.
Policies are not used in the claims-based authentication design sample for the collaborative farm where multiple kinds of authentication are enabled on a single zone. Policies are implemented in the classic authentication design sample and on the published farm of the claims-based authentication design sample where Windows authentication is prescribed. On the published farm, the use of policies adds an additional layer of security between anonymous users and users who have access to manage sites.
The design sample provides one example: denying partner accounts access to internal collaboration sites.