Design sample: Corporate deployment (SharePoint Server 2010)
Applies to: SharePoint Server 2010, 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: Corporate portal with classic authentication
Design sample: Corporate portal with claims-based authentication
To download either of these models, see SharePoint Server 2010 design samples: Corporate portal with classic authentication or with claims-based authentication (https://go.microsoft.com/fwlink/p/?LinkId=196872).
In this article:
About the design samples
Overall design goals
Server farms
Users, zones, and authentication
Services
Authoring and publishing alternatives
Administration sites
Application pools
Web applications
Site collections
Content databases
Zones and URLs
Zone policies
The design samples illustrate a generic corporate deployment of Microsoft SharePoint Server 2010. The design samples apply nearly all of the logical architecture components and illustrate how these are incorporated into the overall design. The two samples illustrate the same services and sites, but incorporate different authentication methods, as follows:
Classic authentication: This design sample represents a path for upgrading sites from Microsoft Office SharePoint Server 2007 to Microsoft SharePoint Server 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. While Windows authentication is used for SharePoint sites, a firewall or gateway product can be configured to use forms authentication to collect Windows credentials that are forwarded to SharePoint Server 2010. Partner employee accounts are added to the corporate directory.
Claims authentication: This design sample incorporates the new claims authentication model. Multiple authentication providers and authentication types are implemented in a single zone. Claims authentication supports forms-based authentication, SAML token-based authentication, and Windows authentication. This design example adds partner companies 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 using the logical architecture components illustrated in the samples.
About the design samples
The design samples illustrate a corporate deployment for a fictitious company named Fabrikam, Inc. The deployment encompasses two server farms. One server farm hosts the company intranet and the partner Web site. The second farm hosts the company Web site (www.fabrikam.com). The rest of this section describes these top-level sites.
Intranet
The corporate intranet includes the following sites:
Published intranet content (such as HRweb)
Collaborative team sites
My Sites
Together, these are the content and collaboration sites that employees will use on a day-to-day basis. Individually, each of these applications represents a distinct type of content. Each type of content:
Emphasizes different features of SharePoint Server 2010.
Hosts data with different data characteristics.
Is subject to a different usage profile.
Requires a different permissions management strategy.
Consequently, design choices for each of these applications are intended to optimize the performance and security for each application.
The design of service applications brings these three applications together to provide:
Navigation across the applications
Enterprise-wide search
Shared profile data and enterprise metadata
The following diagram illustrates the three applications that make up the corporate intranet.
.gif "Intranet sites")
The URLs within this illustration are from the classic authentication design sample.
Partner Web application
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 allowed to access other types 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.
In the design sample, the partner Web application is hosted by the same farm that hosts the intranet content.
Company Internet site
The company Internet site is the company's Internet presence. The content is made available to customers by configuring anonymous access with read-only permissions. Key factors that drive design choices for this application include:
Content isolation: Customers cannot access any other type of content hosted on the server farm.
Targeted management: Authenticated access is provided for employees who manage the Web site by performing administrative and authoring tasks.
Secure content authoring and publishing: A separate site collection is hosted on Farm A in the partner Web application for authoring. This enables secure collaboration and content development with both internal and remote employees, as well as with editorial partners who specialize in Web site development or content authoring. Content publishing is configured to automatically publish the content from the authoring site collection in the first farm to the production site collection in the second farm. The following diagram illustrates the publishing process.
.gif "Published sites")
Overall design goals
The design sample provides practical implementations of SharePoint Server 2010 features within several common types of applications. The design implementations for each of the individual applications are discussed in this article. The key design goals for the design sample include:
Using the minimum number of server farms to host the most common types of Web sites typically required by a corporation, that is, intranet, extranet, and Internet sites.
Creating a framework for designing an environment that can grow. Design decisions for individual applications do not prevent the addition of other applications. For example, an initial deployment might include only collaborative team sites or only the three applications that compose an intranet (team sites, My Sites, and published intranet content). By using a similar logical architecture design, you can add applications to the solution without affecting the design of the initial applications. In other words, the design does not incorporate design choices that limit the use of the environment.
Providing access for several groups of users without compromising the security of the content within the different types of sites. 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 create the opportunity to also enable access to remote employees, partner employees, partner companies, and customers.
Ensuring that the design can be used in an extranet environment. Deliberate design choices are made to ensure that the server farms can be securely deployed in a perimeter network.
The rest of this article discusses each of the logical components that appear in the design sample (from top to bottom) and discusses the design choices that are applied to the design sample. 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 design sample incorporates the use of two server farms. This section describes the licensing requirements that affect the number of server farms that are required in a corporate environment and notes the topologies of the server farms that are illustrated in the design sample.
Licensing requirements
To host both intranet content and Internet sites, the design sample uses two server farms that use two difference licenses.
The following two server licenses are available for SharePoint Server 2010:
Microsoft SharePoint Server 2010, Server License: This is the appropriate license for collaborative intranet content. This license requires the use of Client Access Licenses (CALs). If you create sites for partner collaboration, you must ensure that you purchase the requisite number of CALs for partner employees.
Microsoft SharePoint Server 2010 for Internet sites: This license is intended for Internet-facing Web sites. This license does not require CALs. If you create sites for partner collaboration, you do not need to purchase additional CALs. However, you cannot create sites that are intended exclusively for use by your employees.
Customers who want to combine their SharePoint Server 2010 requirements under a single deployment may obtain licenses for both products, assign those licenses to the same server, and use the same running instance of the software at the same time under both licenses. However, customers must obtain CALs as required under the SharePoint Server 2010 use rights for users and devices that access content in any manner that is not permitted under the SharePoint Server 2010 for Internet Sites use rights.
For more information about farm licensing requirements, see the following resources:
SharePoint 2010: How to Buy (https://go.microsoft.com/fwlink/p/?LinkID=196728)
SharePoint License Overview: Determining Your Needs (https://go.microsoft.com/fwlink/p/?LinkId=210179)
Microsoft Volume Licensing Brief: Microsoft SharePoint Server 2010 for Internet Sites (https://go.microsoft.com/fwlink/p/?LinkId=210180)
Additionally, the design sample includes Microsoft Office Web Apps. Office Web Apps requires an Microsoft Office 2010 client license. In other words, if you make Office Web Apps available to partners, you must also purchase Office 2010 client licenses for them.
Topology of the server farms
Each server farm in the design sample is composed of five servers with the following topology:
Two front-end Web servers
One application server
Two database servers, either clustered or mirrored
The design sample illustrates the logical architecture of SharePoint Server 2010 by showing that:
All sites are mirrored across front-end Web servers.
The Central Administration 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 management (SharePoint Server 2010).
Scaling beyond two farms
Your business might require more than the two farms represented. Sites that are candidates for a dedicated farm include the following:
My Sites: Many organizations with large numbers of employees or students choose to host My Sites on a dedicated server farm.
Authoring and staging sites: If published content is complex or extensive, authoring and staging might be better optimized by hosting these sites on a dedicated single-server farm using the Microsoft SharePoint Server 2010 for Internet sites license. For example, publishing content that includes tagged metadata increases the complexity of the services design sample between both the authoring farm and the published farm, including sharing the service across farms and making decisions about how the service might be shared across other types of Web applications in a multi-use farm.
Partner sites: Security and isolation requirements might warrant a dedicated farm for partner collaboration. This creates physical isolation between internal-only content and content that is developed in collaboration with external partners.
Users, zones, and authentication
When you create a Web application in SharePoint Server 2010, you must choose either claims-based authentication or classic-mode authentication. The authentication mode determines how accounts are used internally by SharePoint Server 2010. The following table summarizes the two approaches.
Type of authentication |
Description |
Recommendations |
Classic mode authentication |
User accounts are treated by SharePoint Server 2010 as traditional Windows Active Directory 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 Microsoft Office SharePoint Server 2007, in which forms-based authentication is not a requirement. You do not need to run user migration if you are upgrading and select classic mode authentication. |
Claims-based authentication |
User accounts are treated by SharePoint Server 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 Server 2010 deployments. It is required for upgrading Office SharePoint Server 2007 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 incorporated in the previous release. For this reason, this example provides a path for upgrading from Office SharePoint Server 2007 to SharePoint Server 2010.
The one caveat is that forms-based authentication is not supported in classic mode. When using 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 illustrates four different classes of users, each assigned to a different zone. Within each Web application, you can create up to five zones using one of the available zone names: Default, Intranet, Internet, Custom, or Extranet.
The following table shows the zones, users, and authentication type prescribed by the classic mode design sample.
.gif "Table showing zones, users, and authentication.")
The search crawl account requires access to at least one zone using NTLM authentication. If none of the zones for users is configured to use NTLM, configure the custom zone to use NTLM authentication.
Claims-based authentication design sample
Claims-based authentication is recommended for all new deployments of SharePoint Server 2010 and required for upgrading Office SharePoint Server 2007 solutions that require forms-based authentication. In addition to providing the standard Windows authentication methods, claims-based authentication allows you to authenticate against other directories, such as Windows Live ID, Active Directory Federation Services 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 allows multiple types 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 type that are prescribed by the sample for the collaborative farm.
.gif "Table showing zones, users, and authentication.")
In the design sample, the Published Intranet Content site, Team Sites, and My Sites are only accessible to employees, whether they are inside or outside the network. The design sample implements only one URL (using SSL) for each of these sites that can be used both internally and externally. Active Directory 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 accessible by partner employees and partner companies. Using claims-based authentication in this scenario requires that trust be configured with one or more external secure token service (STS). This can be provided using either one 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 using a separate store, such as a database.
For more information about implementing 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).
In the claims-based authentication design sample, the published farm is set up to use classic mode authentication. An alternative is to use claims-based authentication for the published farm as well and implement a separate zone for anonymous users. The important element of the design is to use a separate zone for anonymous users to create isolation between the read-only environment and the read-write environment, regardless of which authentication mode is implemented. The following table shows the zones, users, and authentication type that are illustrated for the published farm.
.gif "Table showing zones, users, and authentication.")
Again, the search crawl account requires access to at least one zone using NTLM authentication. NTLM authentication can be added to a claims-authentication zone, if needed. In classic-mode, if none of the zones for users is configured to use NTLM, configure the custom zone to use NTLM authentication.
Zones
When you design zones, several key decisions are critical 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 incorporated in the design sample.
Configuration requirements of the default zone
The zone that involves the greatest consideration is the Default zone. SharePoint Server 2010 places 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 from the Default zone. These include e-mail to owners of sites that are approaching quota limits. Consequently, users who receive these type of e-mails and alerts must be able to access links through the Default zone. This is especially important for site owners.
Host-named site collections are only available 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 critical for the following two reasons:
User requests can be initiated from several different networks. In the design sample, users initiate requests from the internal network, the Internet, and partner companies.
Users consume content across multiple Web applications. In the design sample, the intranet is composed of three different Web applications. Additionally, internal and remote employees can potentially contribute to and administer content across all of the Web applications: intranet, Partner Web, and the company Internet site.
In an extranet environment, ensure that the following design principles are followed:
Configure zones across multiple Web applications to mirror each other. 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. Alternate access mappings are automatically created when you create the zone. However, SharePoint Server 2010 can be configured to crawl content in external resources, such as a file share. Links to these external resources must be created manually for each zone by using alternate access mappings.
If zones across Web applications do not mirror each other and links to external resources are not appropriate, the risks include:
Server names, Domain Name System (DNS) names, and IP addresses can potentially be exposed outside of the internal network.
Users might be unable to access Web sites and other resources.
Services
The services architecture illustrated shows the most complex option for deploying services across the three different types of sites: Intranet, partner Web, and the company Internet site. Dedicated and partitioned services are deployed for the partner Web site. A separate instance of the Managed Metadata service application is deployed for exclusive us by the authoring site collection and published Internet site.
A much simpler alternative is to deploy one set of service applications and to share each service, as needed, across the sites. This architecture relies on security trimming to show only content that users have access to. The following diagram illustrates this simpler approach.
.gif "Services architecture")
The primary design decision for deploying service applications is how broadly to spread the organization taxonomy. Services architecture can be simplified by sharing managed metadata, user profile, and search across all Web apps and relying on security trimming to manage access to content. In the simplified architecture described in this article, one instance of the Managed Metadata service is shared across all sites. However, with this configuration all users have access to the corporate taxonomy. Solution architects must decide whether to implement multiple instances of the Managed Metadata service. They’ll also need to decide how broadly to share the User Profile data.
Partner Web site
For the partner Web site (custom group on Farm 1), the minimum services prescribed by the design sample are Search and Managed Metadata. If you add Office Web Apps to the group of services used by the partner Web site, ensure that you have the appropriate licenses for all users of this site, including partners. The User Profile service application is not included by the design sample to prevent partner users from browsing people data in the organization.
In the simplified architecture, partners have access to the entire corporate taxonomy and can browse people data in the organization. However, search limits results to sites and content that partners have access to.
If your partner sites require content isolation between projects, deploying dedicated and partitioned service applications is a good choice, as illustrated in the design sample. This increases the complexity of the services architecture but ensures that partners do not have access to metadata associated with the Intranet content or even other projects within the partner Web site.
Company Internet site
In the simplified design architecture, the corporate Managed Metadata service application is also shared with the published Internet site. In the design sample, a dedicated instance of the Managed Metadata service application is deployed on the collaboration farm for exclusive use by the authoring site collection and the published farm.
If the published farm is anonymous and read-only, there is no risk of exposing managed metadata that is not associated with the published content. Anonymous users have access only to the content that is published and cannot submit ratings or create other types of metadata.
Sharing the Managed Metadata service application across the organization (as illustrated in the simplified architecture in this article) allows authors to utilize the corporate taxonomy. In contrast, deploying a dedicated instance of the service for authoring and publishing (illustrated in the design sample) ensures that managed metadata is isolated.
A dedicated instance of the Search service application is deployed to the farm hosting the company Internet site. This is the recommended configuration for a published Internet-facing site.
Authoring and publishing alternatives
For the company Internet site, the design sample illustrates a publishing process that includes using the content deployment feature to move content from an authoring site collection to the publishing farm. A simpler alternative to this approach is to author directly on the publishing farm. This is commonly referred to as authoring in production.
Authoring on the production environment greatly simplifies the solution by consolidating services on one farm and removing the need for content deployment. The design sample includes the additional zones that can be used by authors to work securely without impacting anonymous users. Be sure to block incoming anonymous access on the port associated with the zones used by authors. If your site has less than 500 writes per hour of authoring activity, it is unlikely that performance of the published site will be impacted when authoring on the production environment.
SharePoint Server 2010 includes publishing features that can be used in this scenario to ensure that content is not exposed to anonymous users until it is ready. For more information, see the following articles:
Schedule the start and end date for a published page (https://go.microsoft.com/fwlink/p/?LinkId=196777)
Approve or reject a pending submission (https://go.microsoft.com/fwlink/p/?LinkId=196778)
Set permissions for publishing (https://go.microsoft.com/fwlink/p/?LinkId=196779)
Administration sites
In the design sample, the Central Administration site for each server farm is hosted on an 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.
The load-balanced URLs for administration sites are not mentioned in the design sample or in this article. Recommendations include the following:
If port numbers are used in administrative URLs, use non-standard ports. Port numbers are included in URLs by default. While 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.
In addition to these recommendations, you can optionally load-balance the Central Administration site across multiple application servers to achieve redundancy.
Application pools
Separate Internet Information Services (IIS) application pools are typically implemented to achieve process isolation between content. Application pools provide a way for multiple sites to run on the same server computer but still have their own worker processes and identity. This mitigates an exploit on one site that provides an opportunity for an attacker to inject code onto the server to attack other sites.
Practically speaking, consider using a dedicated application pool for each of the following scenarios:
To separate authenticated content from anonymous content.
To isolate applications that store passwords for and interact with external business applications (although the Secure Store Service can be used for this purpose instead).
To isolate applications where users have great liberty to create and administer sites and to collaborate on content.
The design sample uses application pools in the following way:
The administration site is hosted in a dedicated application pool. This is a requirement of SharePoint 2010 Products.
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.
Intranet content is divided into two different application pools. Collaborative content (My Sites and team sites) is hosted in one application pool. The published intranet content is hosted in a separate application pool. This configuration provides process isolation for the published intranet content in which business data connections are more likely to be used.
The partner Web application is hosted in a dedicated application pool.
The company Internet site is hosted in a dedicated application pool on the second farm. If this farm were also to host content for partner collaboration, these two types of content (Internet and partner) would be hosted in two different application pools.
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.
Generally speaking, use dedicated Web applications to:
Separate anonymous content from authenticated content. In the design sample, the company Internet site is hosted in a dedicated Web application and application pool.
Isolate users. In the design sample, the partner Web site is hosted in a dedicated Web application and application pool to ensure that partners do not have access to the intranet content.
Enforce permissions. A dedicated Web application provides the opportunity to enforce permissions by policies by using the Policy for Web Application page in Central Administration. For example, you can create a policy on the company Internet site to explicitly deny write access to one or more groups of users. Policies for a Web application are enforced regardless of permissions configured on individual sites or documents within the Web application.
Optimize performance. Applications achieve better performance if they are placed in Web applications with other applications of similar data characteristics. For example, the data characteristics of My Sites include a large number of sites that are small in size. In contrast, team sites typically encompass a smaller number of very large sites. By placing these two different types of sites in separate Web applications, the resulting databases are composed of data with similar characteristics, which optimizes database performance. In the design sample, My Sites and team sites do not have unique data isolation requirements—they share the same application pool. Nonetheless, My Sites and team sites are placed 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 My Site content if this is not the most critical type of content within your organization. This allows you to restore more critical content before restoring My Site content. In the design sample, My Sites are placed 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 design sample 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 diagram illustrates 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 design sample incorporates choices based on the nature of the application.
Published intranet content
The assumption for the published intranet content Web application is that multiple divisions within the company will host published content. In the design sample, 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:
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. Alternatively, each site collection can appear to be a separate Web site.
My Sites
My Sites have distinct characteristics and the recommendations for deploying My Sites are straightforward. In the design sample, the My Site application incorporates a top-level site with 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 illustration illustrates My Sites.
For more information about designing a My Sites application, see Plan for My Sites (SharePoint Server 2010).
.gif "My Sites")
Team sites
You can use either of the following two approaches for designing site collections within 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:
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.
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 design sample 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 shows suggestions for different types of organizations.
| Type of organization | Suggested site collection taxonomies |
|---|---|
Product development |
|
Research |
|
Higher education institution |
|
State legislative office |
|
Corporate law office |
|
Manufacturing |
|
Partner Web application
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 the partner Web application include ensuring that:
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 within one project do not expose content from other projects.
Administrators can easily identify sites that are no longer used and delete these sites.
To satisfy these requirements, the design sample incorporates a site collection for each project. In this way, 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.
Company Internet site
The company Internet site incorporates a single root-level site collection. All sites beneath this site collection are subsites. This structure simplifies URLs for pages within the site. The following diagram illustrates the architecture of the company Internet site.
.gif "Company Internet site")
Content databases
You can use the following two approaches to incorporate content databases into the design (the design sample incorporates both 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. This is the most commonly used approach.
Associate site collections to specific content databases. This approach enables you to place one or more site collections in a dedicated database that can be managed independently from the rest.
If you choose to associate site collections to specific content databases, you can use the following methods to accomplish 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 performing the following 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 accessible 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.
Published intranet content
For published intranet content, the design sample incorporates a single database for ease of management. Add databases based on target size goals, if needed.
My Sites
For My Sites, the design sample 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 personal 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 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%
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 My 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.
Team sites
For team sites, again the design sample achieves scale efficiency by managing databases to the maximum target size. Team sites for most organizations are expected to be much larger than My Sites. 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.
Another approach for organizations with teams that have large storage needs is to dedicate a single database to each top-level team site collection.
Partner Web
Similar to My Sites, Partner Web achieves scale efficiency by managing databases to the maximum target size. In the design sample, however, Partner Web also hosts the authoring site collection for the company Internet site. Consequently, database design incorporates both approaches:
Authoring site collection is hosted in a dedicated database.
Database and size settings are configured to manage all other sites and databases.
Because Partner Web is hosted in a dedicated Web application, you can create size limits that are more appropriate to the types 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
Authoring site collection hosted in dedicated database
Company Internet site
By using a single site collection in the design of the company Internet site, you use a single database for this Web application.
Zones and URLs
The design sample illustrates 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 are different 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 a requirement 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 design sample incorporates managed paths. Managed paths provide greater control over URLs for these types 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 within a Web application. The load-balanced URL includes the protocol, scheme, hostname, and port, if 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 design sample.
Intranet
Each of the three Web applications that compose the intranet requires a unique URL. In the design sample, the target audience for the intranet content is internal employees and remote employees. In the claims 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 SharePoint design (all traffic is SSL), this approach requires either routing internal traffic through the firewall or gateway product along 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 |
|---|---|---|
Published intranet content |
http://intranet |
https://intranet.fabrikam.com |
Team sites |
http://teams |
https://teams.fabrikam.com |
My Sites |
http://my |
https://my.fabrikam.com |
Partner Web site
In the design sample, the partner Web site is accessed by internal employees, remote employees, and partner employees. In the claims authentication design sample, each of these users enters the same URL, regardless of the authentication method. In the classic authentication design sample, each different type of user enters a different URL. Although both remote employees and partner employees access the partner Web site externally using SSL (HTTPS), each group requires a different URL to apply the benefits of using separate zones—that is, 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 |
Company Internet site
The company Internet site is a public site and can be accessed by any user by using the default URL, http://www.fabrikam.com. The policies of the Internet zone are applied (that is, anonymous access and deny write).
However, to support administration and authoring tasks on the public site, the design sample incorporates URLs for internal and remote employees. You can use policies for these zones ensure appropriate access to targeted security groups for authoring and maintenance tasks. Both the classic authentication and the claims authentication design samples use the same approach for this farm. The following table shows the URLs for each zone.
| Zone | URL |
|---|---|
Internal employee URL |
http://fabrikamsite |
Remote employee URL |
https://fabrikamsite.fabrikam.com |
Customer URL |
http://www.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 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 types 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://intranet/hr. There is a performance impact for every explicit path added so the recommendation is to limit the number of site collections 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 site collections 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 design sample incorporates the use of both types as described in the following sections.
Explicit inclusions: Published intranet content
In the design sample, the published intranet Web application incorporates the use of explicit inclusions.
Published intranet content
Within the published intranet content Web application, an explicit inclusion is used for each subsite, for example, HR, Facilities, and Purchasing. Each of these site collections can be associated with a different content database, if needed. The use of explicit inclusions in this example assumes that no other types of sites are created in the Web application, including wildcard inclusions.
The recommended limit for sites created using an explicit inclusion is about 20. If your organization requires a greater number of site collections, then consider using a wildcard inclusion or host-named site collections.
In the classic authentication design sample, the use of explicit inclusions results in the URLs shown in the following table.
| Internal employee (Intranet zone) | Remote employee (Default zone) |
|---|---|
http://intranet |
https://intranet.fabrikam.com |
http://intranet/hr |
https://intranet.fabrikam.com/hr |
http://intranet/facilities |
https://intranet.fabrikam.com/facilities |
http://intranet/purchasing |
https://intranet.fabrikam.com/purchasing |
In this example, the root site collection, http://intranet, represents the default home page for the intranet. This site is intended to host content for users.
Wildcard inclusions: Team Sites, My Sites, and Partner Web
Team Sites, My Sites, and the partner Web application incorporate the use of a wildcard inclusion. Wildcard inclusions are ideal for applications that allow users to create their own site collections and for Web applications that include a lot of 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.
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 design sample, My Sites include a wildcard inclusion named /personal (http://my/personal). The My Site feature automatically appends the user name to the URL.
In the classic authentication design sample, this results in URLs of the format shown in the following table.
| Internal (Intranet zone) | Remote employee (Default zone) |
|---|---|
http://my/personal/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/personal/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/personal/user3 |
https://my.fabrikam.com/personal/user3 |
Partner Web
Partner Web is designed to allow employees to easily create secure sites for collaboration with external partners. To support this goal, self-service site creation is allowed.
In the classic authentication design sample, the partner Web application includes a wildcard inclusion named /sites (http://partnerweb/sites). This results in URLs of 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 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 |
The exception for the partner Web application, as illustrated in the design samples, is the collection dedicated to authoring the content for the company Internet site. For this site collection, an explicit inclusion is used. This provides an example of using both explicit inclusions and wildcard inclusions in the same Web application.
Coordinating URLs with AAM and DNS
Configure alternate access mappings (AAM) 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 |
|---|---|---|---|---|
| Published intranet content | intranet | Intranet | 80 | http://intranet |
| intranet.fabrikam.com | Default | 443 | https://intranet.fabrikam.com | |
| 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 | |
| Company Internet site | www.fabrikam.com | Internet | 80 | http://www.fabrikam.com |
| fabrikamsite | Intranet | 80 | http://fabrikamsite | |
| fabrikamsite.fabrikam.com | Default | 443 | https://fabrikamsite.fabrikam.com |
Single-name URLs, such as http://teams, can be configured for intranet access. These URLs are resolved by the client computer by appending the DNS suffix of the client computer, 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 that has the original single-name URL, http://teams. IIS and SharePoint Server 2010 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 instead requested https://teams.fabrikam.com, the process would be the same, except that IIS and SharePoint Server 2010 would receive this FQDN instead, and therefore would 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 computer’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 will 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 in general or just 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. If you add or change a zone policy, search must re-crawl sites to pick up the new permissions.
Policies are not used in the claims authentication design sample for the collaborative farm where multiple types 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 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 samples provide examples of several policies to accomplish the following:
Deny write access to published content.
Ensure authors and testers have appropriate access to published content.
See Also
Other Resources
Resource Center: Architecture Design for SharePoint Server 2010