Export (0) Print
Expand All
29 out of 35 rated this helpful - Rate this topic

Logical architecture model: Corporate deployment

Updated: April 23, 2009

Applies To: Office SharePoint Server 2007

Updated: 2009-04-23

In this article:

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 model Design Sample: Corporate Deployment Logical Architecture (http://go.microsoft.com/fwlink/?LinkId=82151&clcid=0x409).

The model illustrates a generic corporate deployment of Microsoft Office SharePoint Server 2007. The model applies nearly all of the logical architecture components and illustrates how these are incorporated into the overall design. This article describes the design goals for the model and explains how these goals are achieved using the logical architecture components illustrated in the model.

About the model

The model illustrates a corporate deployment for a fictitious company named Fabrikam, Inc. The deployment encompasses two server farms. One server farm hosts the corporate intranet and the partner Web site. The second farm hosts the company Web site (www.fabrikam.com).

Intranet

The corporate intranet includes the following applications:

  • 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 Office SharePoint Server 2007.

  • 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 use of a single Shared Services Provider (SSP) brings these three applications together to provide:

  • Navigation across the applications.

  • Enterprise-wide search.

  • Shared profile data.

The following figure shows the three applications that make up the the corporate intranet.

Logical architecture for corporate model

Partner Web

The Partner Web application hosts externally-available sites for secure collaboration with employees of partner companies. This application is intended for employees to easily create sites for secure collaboration. Key factors that drive design choices for this application include:

  • Content isolation   Partners are not allowed to access other types of content hosted on the server farm. Additionally, with a dedicated SSP you can further isolate content by:

    • Scoping search to only the site level.

    • Not allowing navigation across site collections.

    • Not making profile data available across site collections.

  • Separate authentication of partner accounts   Partner accounts are managed through forms authentication. Partner accounts are not added to the corporate directory.

  • Permissions management   Individual site owners manage permissions to their sites, inviting only necessary participants to collaborate.

In the model, 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, including administrative and authoring tasks.

  • Secure content authoring and publishing   Separate site collections are hosted on Farm A in the Partner Web application for authoring and staging. 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 to the staging site collection (in Farm A) and from the staging site collection in Farm A to the production site collection in Farm B. The following figure shows the publishing process.

Logical farm architecture - publishing model

Overall Design Goals

The model illustrates a practical implementation of Office SharePoint Server 2007 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 model include:

  • Use the minimum number of server farms to host the most common types of Web sites typically required by a corporation: intranet, extranet, and Internet sites.

  • Create 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.

  • Provide access for several classes of users without compromising the security of the content within the disparate 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 create the opportunity to also enable access to remote employees, partner employees, and customers.

  • Ensure 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 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 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 model.

Licensing requirements

NoteNote:

Previous licensing requirements specified that a minimum of two servers were required to host both intranet content and Internet sites (one server for each type of license). This is no longer a requirement. This section is updated to reflect new licensing requirements that were implemented in September, 2008.

There are two server licenses available for Office SharePoint Server 2007. These licenses can be combined on the same server computer or on the same server farm:

  • Microsoft Office SharePoint Server 2007, Server License   This is the appropriate license for 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 Office SharePoint Server 2007 for Internet sites   This license is intended for Internet-facing Web sites only. 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.

If you plan to deploy internal content for your organization and Internet-facing content for non-employees from the same farm, you must purchase both license types for that farm. As an accommodation for possible deployment scenarios, customers wishing to consolidate their Office SharePoint Server 2007 needs under a single deployment may acquire licenses for both products, assign those licenses to the same server, and use the same running instance of the software simultaneously under both licenses. However, customers must acquire CALs as required under the Office SharePoint Server 2007 use rights for users and devices accessing content in any manner not permitted under the Office SharePoint Server 2007 for Internet sites use rights.

For more information about how licensing requirements affect the number of server farms that are required, see Plan for server farms.

Although only one server farm is necessary, the model illustrates the use of two server farms: one for internal content and the other for customer-facing content. If you choose to implement two separate farms, the most critical design choice is deciding which farm hosts the Partner Web application. In the model, Server Farm A hosts the intranet content and Server Farm B hosts the Company Internet site. According to licensing terms, either farm can host Partner Web.

Given a choice of the two farms, general design guidance for determining which farm should host a Partner Web application includes the following:

  • Nature of collaboration   If the primary purpose of a partner extranet site is to securely communicate information to many partners, an Internet server farm is the most economical choice. On the other hand, if the primary purpose is to work collaboratively with a small number of partner employees, an intranet server farm might be a better choice. Choose the option that enables you to optimize the farm for its intended role (that is, collaboration vs. read-only content).

  • Number of partner employees   If you collaborate with many partner employees and minimizing cost is important, you can securely host both collaborative and anonymous content on an Internet-facing farm with the Internet sites license.

In the model, Partner Web is intended for intensive collaboration with partner companies, including developing and staging the company Internet site. Placing Partner Web on Farm A allows the organization to optimize each of the two farms for their intended use (collaboration vs. read-only content).

For more information about choosing the appropriate number of farms for your organization, including more information about licensing requirements, see Plan for server farms.

Topology of the server farms

Each server farm in the model 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 model illustrates the logical architecture of Office SharePoint Server 2007 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 Plan for performance and capacity (Office SharePoint Server).

Users, zones, and authentication

The model illustrates five 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. A farm that hosts more than one Web application can support user requests from more than five network zones (up to five zones per Web application). However, the model shows only five zones.

Users and authentication

The model shows users from different network zones or, in the case of administrators, users who have vastly different permissions requirements. The model demonstrates how authentication is applied across the users. The following table lists how users are authenticated for each zone.

Zone Users Authentication

Custom

Administrators

Kerberos (Integrated Windows)

Intranet

Internal employees

NTLM (Integrated Windows)

Default

Remote employees

NTLM (Integrated Windows) or forms authentication with Lightweight Directory Access Protocol (LDAP).

Extranet

Partner employees

Forms authentication

Internet

Customers

Anonymous

In the model, not all users are given access to both server farms. Consequently, neither farm uses all five zones.

Administrators

The Custom zone is used for secure administrative access to sites. This approach provides the opportunity to:

  • Implement an independent set of URLs and policies. For example, administrators can use URLs associated with the Custom zone to perform administrative tasks according to the policies of the zone. Administrators can use the intranet URLs for all other tasks according to the policies that are configured for the applications that compose the intranet. This approach separates the two contexts and ensures that policy permissions do not conflict.

  • Implement a more secure method of authentication for administrators. This provides greater security for the overall solution.

  • Authenticate against a different provider in scenarios where support for sites is provided by an external vendor.

The model assumes that administrators are employees of Fabrikam and have internal access to the network. The model incorporates the use of Integrated Windows authentication for administrators (that is, either Kerberos authentication or NTLM).

Internal employees

The Intranet zone is used for internal employee access. Integrated Windows authentication is used.

Remote employees

The Default zone is used for remote employee access. The design goals in the model are:

  • Authenticate against the internal Active Directory directory service environment.

  • Simplify permissions management by using Windows authentication for both internal employees and remote employees. This goal is important because if users connect to sites through two different authentication providers, Office SharePoint Server 2007 creates two different accounts for each user, and each of the two accounts must have permissions.

The model presents two different options for authenticating remote employees. With the first option (Integrated Windows authentication using NTLM), both design goals are accomplished. The second option (forms authentication) satisfies the first goal but not the second. Consequently, the first option is the preferred method.

The following table summarizes the differences between these two approaches.

This authentication method Integrated Windows authentication using NTLM Forms authentication using an LDAP provider

How it works

This method relies on using Internet Security and Acceleration (ISA) Server 2006 or Intelligent Application Gateway (IAG 2007) to authenticate users and then to send the user credentials to Office SharePoint Server 2007. These servers use forms authentication to authenticate users against the Active Directory environment. They then forward the Windows credentials to Office SharePoint Server 2007. For more information, see the following resources:

Because the zone is the Default zone, NTLM authentication is used to satisfy a requirement of the index component. For more information, see "Configuration requirements of the Default zone" later in this article.

Office SharePoint Server 2007 uses forms authentication with an LDAP provider to authenticate remote employees against the internal Active Directory environment.

If this method is chosen, ensure that the index component can authenticate through an alternate zone. For more information, see "Configuration requirements of the Default zone" later in this article.

Advantages

Office SharePoint Server 2007 does not create two different accounts for users who work both internally and remotely. This greatly simplifies permissions management.

Does not require a proxy server to authenticate users and forward credentials.

Disadvantages

Requires additional coordination with and configuration of ISA Server 2006 or another proxy server product.

If users connect to Office SharePoint Server 2007 both internally and remotely, two different user accounts are created in Office SharePoint Server 2007. Consequently, both accounts require permissions to sites and documents. Employees can potentially create two My Sites. Employees need to manage permissions for their own sites and documents for both user accounts if they plan to work from both the internal network and remotely.

Partner employees

Partner employees access the network through the Extranet zone, and are authenticated by using forms authentication. This requires a separate directory and provider, such as a Microsoft SQL Server database and provider, to store partner accounts in the extranet. The advantages of this approach are that you can manage partner accounts separately, and you do not need to add partner accounts to the internal employee directory.

Alternatively, you can use Web single sign-on (SSO) to authenticate against a partner's own directory. However, this approach requires a separate zone for each partner directory.

Because the model assumes that Fabrikam is working with partners from several different companies within the same partner application, forms authentication is used. The directory and provider are not specified.

Customers

The Internet zone is used for customer access. This zone is configured to allow anonymous access with read-only permissions.

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 model.

Configuration requirements of the default zone

The zone that involves the greatest consideration is the Default zone. Office SharePoint Server 2007 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.

  • The index component requires access to content through at least one zone to crawl content. By default, the index component uses NTLM authentication. The SSP administrator can configure crawl rules to use either Basic authentication or a client certificate when crawling a particular range of URLs. Consequently, in order to crawl content, at least one of the zones must be configured to use NTLM authentication, Basic authentication, or certificates. Also, the crawler will poll zones in the following order until it encounters a zone that it can authenticate through: default zone, intranet zone, Internet zone, custom zone, extranet zone. However, if the crawler first encounters a zone that is configured to use Kerberos authentication, the crawler will not authenticate and will not attempt to access the next zone. Therefore, ensure that the configuration of zones using Kerberos authentication does not prevent the index component from crawling content. For more information about authentication requirements related to crawling content, see Plan authentication methods (Office SharePoint Server).

  • 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.

In the model, the Default zone is used for remote employee access for the following reasons:

  • Employees can access links in administrative e-mail regardless of where they are located.

  • Internal server names and URLs are protected from being exposed when the zone associated with a user request cannot be determined. Because the Default zone is already configured for remote employees, URLs do not expose sensitive data when this zone is applied.

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 model, users initiate requests from the internal network, the Internet, and partner companies.

  • Users consume content across multiple Web applications. In the model, 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 corporate 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.

In the model, the Default zone for each of the Web applications is configured identically for remote employee access. Additionally, the Intranet zone is configured identically across all Web applications for internal employee access. The Extranet zone and the Internet zone are each configured for only one Web application.

Alternate access mappings are automatically created when you create the zone. However, Office SharePoint Server 2007 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. For example, a file share can be exposed to internal users with an internal URL (file://). The same file share can be exposed as an FTP link to external users (ftp://). This ensures that these resources are available to users according to the context of their zone. When users receive links to these resources in search results, the links are accessible.

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.

SSPs

An SSP provides a common set of services and service data to a logical grouping of Web applications and their associated sites. Services and service data include:

  • Personalization services

  • Audiences

  • Business Data Catalog

  • Excel Services

  • Office SharePoint Server Search

  • Portal usage reporting

The most important criterion that determines if you need more than one SSP in your logical architecture is if you need to isolate content. For example, if your server farm hosts applications for more than one class of users, separate SSPs can help create isolation between these classes of users.

The model incorporates a separate SSP for each of the following applications:

  • Intranet

  • Partner Web

  • Customer Internet Web site

    SSP model for corporate deployment

Intranet

The three individual applications that compose the intranet — published intranet content, My Sites, and team sites — are brought together by one SSP. The intranet application illustrated in the model provides an example of balancing secure isolation with the business need to share information and leverage profile data across the applications.

  • The individual applications are isolated by Web applications and application pools. Separate application pools provide process isolation. Dedicated Web applications provide the opportunity to implement different permission policies for each type of content.

  • Unifying the three applications under one SSP provides for personalization and enterprise-wide search across all of the applications.

    Shared Services Provider architecture

Partner Web

Using a separate SSP for the Partner Web application ensures that partner users cannot search on or access sensitive information within your intranet environment. The SSP can be configured to further isolate content between site collections in the following ways:

  • Limit search scopes to the individual site collections.

  • Use audiences to target content to certain groups of users.

  • Use the Stsadm command-line tool to configure the People Picker to display only users that are members of the site collection. In this configuration, you can add any user from the directory if you know the user name; however, only users that are already added to the site collection are displayed in the People Picker. This prevents partner users from browsing your user directory through the People Picker.

    Use the following command to turn this configuration on;

    Stsadm.exe -o setproperty –url http://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv yes

    Use the following command to turn this configuration off:

    Stsadm.exe -o setproperty –url http://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv no

In addition to configuring services within the SSP to achieve isolation, consider configuring permissions in the following ways:

  • Limit access to sites to specific users or groups.

  • Use SharePoint groups to authorize access to content.

Company Internet site

In the model, the company Internet site is available for anonymous users. Sites intended for anonymous users should always be separated from sites intended for authenticated users. The model uses the following isolation methods for the company Internet site:

  • Separate application pool ensures process isolation.

  • Separate Web application provides the opportunity to target policies.

  • Dedicated SSP ensures that search results are limited to the anonymous application.

Administration sites

In the model, each administration site is hosted inside a dedicated application pool and Web application. The following list describes each of the administration Web sites:

  • Shared services administration Web sites   The model illustrates a dedicated administration site for each SSP. Shared services administration sites cannot be isolated on a single server or set of servers. These sites are automatically mirrored across all front-end Web servers.

  • Central Administration Web sites   In the model, 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 articulated in the model 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.

  • Allow access to administration sites only from an administrative domain.

  • 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 (for example, Business Data Catalog connections).

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

The model uses application pools in the following way:

  • Each administration site is hosted in a dedicated application pool. This is a requirement of Office SharePoint Server 2007.

  • 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. For example, many human resources (HR) sites use business data connections to enable employees to access their personal data.

  • The Partner Web application is hosted in a dedicated application pool.

  • The company Internet site is hosted in a dedicated application pool on Farm B. 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 Products and Technologies. Each Web application is represented by a different Web site in IIS. You assign each Web application a unique domain name, which helps to prevent cross-site scripting attacks.

Generally speaking, use dedicated Web applications to:

  • Separate anonymous content from authenticated content. In the model, the company Internet site is hosted in a dedicated Web application and application pool.

  • 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 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 model, 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 model, 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 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.

Logical architecture  for collaboration sites

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

Published intranet content

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

  • Each division can manage and permission their content independently.

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

The disadvantages of using multiple site collections include:

  • 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 model, 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 figure illustrates My Sites.

Logical network architecture for My Sites

For more information about designing a My Sites application, see Design My Sites architecture.

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

Type of organization Suggested site collection taxonomies

Product development

  • Create a site collection for each product under development. Allow contributing teams to create sites within the site collection.

  • For each long-term development project, create a site collection for each large team that contributes to the product. For example, create one site collection for each of the following teams: designers, engineers, and content developers.

Research

  • Create a site collection for each long-term research project.

  • Create a site collection for each category of research projects.

Higher education institution

  • Create a site collection for each academic department.

State legislative office

  • Create a site collection for each political party. Government officials who share party affiliation can share templates and navigation.

  • Create a site collection for each committee. Or, create one site collection for all committees.

Corporate law office

  • Create a site collection for each corporate client.

Manufacturing

  • Create a site collection for each line of products.

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 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 model 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 figure shows the architecture of the company Internet site.

Logical deployment architecture

Content databases

You can use the following two approaches to incorporate content databases into the design (the model 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.

  • 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 the Stsadm command-line tool 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:

    1. Within the Web application, create the database and set the database status to Ready.

    2. 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.

    3. Create the site collections. They are automatically added to the database.

    4. Set the status of all other databases back to Ready.

Published intranet content

For published intranet content, the model incorporates a dedicated database for each of the department site collections.

This approach enables each department to manage their content independently.

My Sites

For My 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 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 model provides the following example size settings based on a target database size of 100 gigabytes (GB) and a target My Site size of 500 megabytes (MB):

  • Site size limits per site = 500 MB

  • Target size of database = 100 GB

  • Maximum number of sites = 200

  • 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.

For more information about designing database settings for My Sites, see Design My Sites architecture.

Team sites

For team sites, the model incorporates a dedicated database for each of the team site collections. 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.

Partner Web

Similar to My Sites, Partner Web achieves scale efficiency by managing databases to the maximum target size. In the model, however, Partner Web also hosts the authoring and staging site collections for the company Internet site. Consequently, database design incorporates both approaches:

  • Authoring and staging site collections are each 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 sizes that are created. The model provides the following example size settings:

  • Target size of database = 100 GB

  • Storage quota per site = 5 GB

  • Maximum number of sites = 20

  • Authoring and Staging site collections hosted in dedicated databases

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 model 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 model.

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

Design principles

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

  • Host-named site collections are not used. Note that host-named site collections 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. The alternate access mapping feature also provides support for off-box termination of Secure Sockets Layer (SSL), which enables the remote employee access and partner access scenarios to use SSL (https).

  • Each application incorporates a single root site collection. This is 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 model 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 model.

Intranet

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

Application Internal employee URL Remote employee URL

Published intranet content

http://fabrikam

https://intranet.fabrikam.com

Team sites

http://teams

https://teams.fabrikam.com

My Sites

http://my

https://my.fabrikam.com

Partner Web

In the model, Partner Web is accessed by internal employees, remote employees, and partner employees. Although both remote employees and partner employees access Partner Web externally using SSL (https), each requires a different URL to apply the benefits of using separate zones — that is, different authentication methods and different zone policies. The following table lists the URLs that internal employees, remote employees, and partners use to access Partner Web.

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 model incorporates URLs for internal and remote employees. Policies for these zones limit permissions greater than read access to targeted security groups. The following table lists 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://fabrikam/hr.

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

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

Explicit inclusions: Team sites and published intranet content

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

Team sites

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

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

Internal employee (Intranet zone) Remote employee (Default zone)

http://team/Team1

https://team.fabrikam.com/Team1

http://team/Team2

https://team.fabrikam.com/Team2

http://team/Team3

https://team.fabrikam.com/Team3

In this example, the root site collection, http://team, doesn't necessarily host content for users.

Published intranet content

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

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

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 is intended to host content for users.

Wildcard inclusions: Partner Web and My Sites

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

My Sites

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

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

Internal (Intranet zone) Remote employee (Default zone)

http://my/sites/user1

https://my.fabrikam.com/personal/user1

http://my/sites/user2

https://my.fabrikam.com/personal/user2

http://my/sites/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 model, Partner Web includes a wildcard inclusion named /sites (http://partnerweb/sites). This results in URLs of the format listed 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 Partner Web, as illustrated in the model, is the two site collections that are dedicated to authoring and staging the content for the company Internet site. For these two site collections, an explicit inclusion is used. This provides an example of using both explicit inclusions and wildcard inclusions in the same Web application.

Administration URLs

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

Application URL

Published intranet content

http://fabrikam.admin

Team sites

http://teams.admin

My Sites

http://my.admin

Partner Web

http://partnerweb.admin

Company Internet site

http://fabrikamsite.admin

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

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.

The model provides examples of several policies to accomplish the following:

  • Allow administrators access to all content.

  • Deny write access to published content.

  • Ensure authors and testers have appropriate access to published content.

Download this book

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

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

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.