Logical architecture sample design: collaboration sites
Applies To: Windows SharePoint Services 3.0
Topic Last Modified: 2009-04-15
In this article:
About the model
Overall design goals
Server farms
Users, zones, and authentication
Administration sites
Application pools
Web applications
Site collections
Content databases
Zones and URLs
Zone policies
Backing and restoring collaboration sites
Designing for secure external collaboration
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 Logical Architecture Sample Design: Windows SharePoint Services Collaboration (https://go.microsoft.com/fwlink/?LinkId=124861&clcid=0x409).
About the model
The model illustrates a deployment for a fictitious company named Fabrikam, Inc. If you are planning a solution with one or more of the types of collaboration sites represented in this model, you can use the model as a basis for your own design.
The model illustrates a generic deployment of Windows SharePoint Services 3.0 with three different types of collaboration sites represented:
Team sites
Self-service sites
Partner collaboration sites
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.
Each of the different types of collaboration sites:
Hosts data with different data characteristics.
Is subject to a different usage profile.
Requires a different permissions management strategy.
Consequently, the design choices in the model are intended to optimize the performance and security for each application.
Team sites
Team sites represent highly structured and managed collaboration sites in which:
There is a smaller number of top-level site collections, and these site collections are intended to include a large amount of data (in contrast to self-service sites).
Top-level URLs are meaningful for each team.
More planning is invested in site hierarchies, taxonomies, and customizations.
Each team’s content is in a separate database and can be managed separately.
The following diagram illustrates the site hierarchy for team sites:
.gif "Organization of team sites")
Self-service sites
Self-service sites provide an alternative to highly managed team sites. You can allow users and teams to create their own site collections, using Self-Service Site Management. You turn on Self-Service Site Management in Central Administration. This method is best used when you want to allow groups or communities to create sites. This method also works well if you are hosting sites and want to allow users to create sites without waiting for a detailed process.
The characteristics of self-service sites are typically different from highly managed sites. Characteristics might include the following:
Large number of top-level site collections.
Small amount of data per site collection.
URLs that are automatically generated but typically not meaningful.
The following diagram illustrates self-service sites as implemented in the design sample:
.gif "Sites for self-service site creation")
There are several tradeoffs to be aware of when planning to implement self-service sites, and these tradeoffs will affect the way you manage these types of sites:
Rather than implementing a thoughtful taxonomy, sites are created at will with no organizing principle across sites. Because each new site is a site collection, templates and navigation cannot be shared across self-service sites.
Because each site collection provides search only for content on that site collection, there is no aggregation of search results across site collections.
Sites collections can vary greatly in size and use.
Sites may be easily abandoned.
Managing self-service sites can include managing content storage based on the target size of content databases and regularly deleting sites that are no longer used.
For more information about implementing Self-Service Site Management, see Plan process for creating sites (Windows SharePoint Services).
Partner collaboration sites
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 secure sites for 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.
**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 for their sites, inviting only necessary participants to collaborate.
The following diagram illustrates partner collaboration sites.
.gif "Heirarchy of project sites in a partner Web")
Overall design goals
The model illustrates a practical implementation of Windows SharePoint Services 3.0 features within several different types of collaboration applications (team sites, self-service sites, and partner sites). The design implementations for each of the individual site applications are discussed in this article. The key design goals for the model include:
Create a framework for designing an environment that can grow. Design decisions for individual collaboration applications do not prevent the addition of other applications. For example, an initial deployment might include only collaborative team sites or only partner sites. By using a similar logical architecture design, you can add the other types of collaboration sites to the solution without affecting the design of the initial collaboration sites. In other words, the design does not incorporate design choices that limit the use of the environment.
Provide access for several classes of users without compromising the security of the content within the different collaboration applications. Users from different network zones (both internal and external) with different authentication providers can participate in collaboration. Also, users can only access the content they are intended to access. By following a similar logical architecture design, you create the opportunity to provide access to users in multiple locations and with different objectives. For example, your initial design might be intended only for internal employee access. However, by using a similar design you can enable access to remote employees, partner employees, or even customers.
Ensure that the design can be used in an extranet environment. You can make deliberate design choices to ensure that the server farms can be securely deployed in a perimeter network or within any of the extranet topologies discussed in Design extranet farm topology (Windows SharePoint Services).
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 illustrates a five-server farm. However, the model could be implemented on any size farm, including a single server. The server farm in the model is composed of five servers with the following topology:
Two front-end Web servers
One application server for the search server
Two database servers, either clustered or mirrored
The model illustrates the logical architecture of Windows SharePoint Services 3.0 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 (Windows SharePoint Services).
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 demonstrates how authentication is applied across users from different network zones. The following table also demonstrates the authentication applied to each type of user and zone.
| Zone | Users | Authentication |
|---|---|---|
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 |
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 for the Default zone 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, Windows SharePoint Services 3.0 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 with LDAP) satisfies the first goal but not the second. Consequently, the first option is the preferred method for remote employees.
The following table summarizes the differences between these two authentication options.
| Type of comparison | Integrated Windows authentication using NTLM | Forms authentication using an LDAP provider |
|---|---|---|
Functionality |
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 Windows SharePoint Services 3.0. These servers use forms authentication to authenticate users against the Active Directory environment. They then forward the Windows credentials to Windows SharePoint Services 3.0. 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. |
Windows SharePoint Services 3.0 uses forms authentication with an LDAP provider to authenticate remote employees against the internal Active Directory environment. |
Advantages |
Windows SharePoint Services 3.0 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, IAG 2007, or another proxy server product. |
If users connect to Windows SharePoint Services 3.0 both internally and remotely, two different user accounts are created in Windows SharePoint Services 3.0. Consequently, both accounts require permissions to sites and documents. 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.
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. Windows SharePoint Services 3.0 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. The index component uses NTLM authentication. Consequently, in order to crawl content, at least one of the zones must be configured to use NTLM authentication. 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, and Extranet zone. However, if the crawler first encounters a zone that is configured to use Kerberos, basic, or digest authentication, the crawler will not authenticate and will not attempt to access the next zone. Therefore, ensure that the configuration of zones does not prevent the index component from crawling content. For more information about authentication requirements related to crawling content, see Plan authentication methods (Windows SharePoint Services).
Administrative e-mail is sent with links from the Default zone. These include e-mail messages to owners of sites that are approaching quota limits. Consequently, users who receive this type of e-mail 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 need 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 whether they are accessing the sites internally or remotely.
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 can participate in collaboration across multiple Web applications. For example, internal and remote employees can potentially contribute to and administer content across all of the Web applications: team sites, self-service sites, and Partner Web.
In an extranet environment, ensure that the following design principles are followed:
Configure zones across multiple Web applications to mirror 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 is configured for only one Web application.
Alternate access mappings are automatically created when you create the zone. However, if you use a proxy server or gateway product to make sites available from the Internet, you will need to add an additional alternate access mapping entry for each zone. This ensures that URLs that are returned to users outside of the internal network are available to users according to the context of their zone. For more information, see Plan alternate access mappings (Windows SharePoint Services).
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.
Administration sites
In the model, the Central Administration site is hosted on the search server. This protects the site from direct user contact. If a performance bottleneck or security compromise affects the availability of the front-end Web servers, the Central Administration site remains available. Additionally, the Central Administration site is hosted inside a dedicated application pool and Web application.
The load-balanced URLs for the administration sites are not articulated in the model or in this article. Recommendations include the following:
If port numbers are used in administrative URLs, use non-standard ports. 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.
Application pools
Separate Internet Information Services (IIS) application pools are typically implemented to achieve process isolation between sites. 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 any possible security issues on one site that enable an attacker to inject code onto the server to attack other sites.
Practically speaking, consider using a dedicated application pool for each of the following scenarios:
To separate authenticated content from anonymous content.
To isolate sites that are primarily for collaboration with external partners or customers. This isolates external accounts to sites within one application pool.
To isolate sites where users have more freedom to create and administer sites and to collaborate on content.
The model uses application pools in the following way:
The administration site is hosted in a dedicated application pool. This is a requirement of Windows SharePoint Services 3.0.
The internal collaboration sites (team sites and self-service sites) are hosted in one application pool.
The Partner Web application is hosted in a dedicated application pool.
Web applications
A Web application is an IIS Web site that is created and used by SharePoint 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.
Isolate users. In the model, Partner Web is hosted in a dedicated Web application and application pool to ensure that partners do not have access to the internal collaboration content.
Enforce permissions. A dedicated Web application provides the opportunity to enforce permissions by using the Policy for Web Application page in Central Administration. For example, you can create a policy on the internal collaboration sites to explicitly deny access to partner accounts. Policies for a Web application are enforced regardless of permissions configured on individual sites or documents within the Web application.
Optimize performance. Sites achieve better performance if they are placed in Web applications with other applications of similar data characteristics. For example, the data characteristics of self-service 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, team sites and self-service sites do not have unique data isolation requirements — they share the same application pool. Nonetheless, team sites and self-service sites are 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 self-service sites if this is not the most critical type of content within your organization. This allows you to restore more critical content before restoring these sites. In the model, self-service 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.
.jpg "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.
Self-service sites
In the model, the self-service sites incorporate a top-level site with the URL of http://sites. A managed path is incorporated (by using wildcard inclusion), which allows an indefinite number of user-created sites. All sites below the managed path are independent site collections that inherit the site template that was used to create the top-level site. The following figure illustrates self-service sites.
For more information about self-service sites, see Plan process for creating sites (Windows SharePoint Services).
Team sites
When designing site collections within a team site application, the recommendation is to 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 Windows SharePoint Services 3.0 administrator. After the site collection is created, teams can create sites within the site collection based on their needs.
This approach provides the opportunity to implement a thoughtful taxonomy that provides structure to the way team sites are managed and grow. There is also more opportunity to share templates and navigation between projects and teams that share a site collection. The challenge for information architects is to create a second tier of site collections that makes sense for the organization. The following table lists suggestions for different 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
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 projects 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, which provides the following benefits:
Individual site collections provide the appropriate level of isolation between projects.
Self-service site creation can be implemented.
Content databases
You can use 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:
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.
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.
Self-service sites
For self-service sites, the model achieves scale efficiency by managing databases to the maximum target size. The following settings are configured to achieve this goal:
Limit site storage to a maximum of This setting, which you configure on the Quota Templates page in Central Administration, limits the size of a 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 = 175
When the site level warning is reached, create a new database. After you create the new database, new self-service sites are added alternately to the new database and the existing database until the maximum number of sites for one of the databases is reached.
Partner Web
Similar to self-service sites, Partner Web achieves scale efficiency by managing databases to the maximum target size.
Because Partner Web is hosted in a dedicated Web application, you can create size limits that are 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
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). For more information on using host-named site collections see White paper: Create shared hosting solutions on Windows SharePoint Services.
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, host name, 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.
Internal collaboration sites
The two different types of internal collaboration sites each require a unique URL. In the model, the target audience for these sites 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 |
|---|---|---|
Team sites |
http://teams |
https://teams.fabrikam.com |
Self-service sites |
http://sites |
https://sites.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 |
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://team/Team1.
Wildcard inclusion A path that is added to the URL. This path indicates that all sites that are specified directly after the path name are unique site collections. This option is typically used for applications that support self-site creation. An example URL for a site collection created by using this method is http://sites/site1.
The model incorporates the use of both types as described in the following sections.
Explicit inclusions: team sites
In the model, both of the team sites 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 to 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.
Wildcard inclusions: Partner Web and self-service sites
Both Partner Web and self-service 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.
Self-service sites
In the model, self-service sites include a wildcard inclusion named /sites (http://selfservice/sites).
This results in URLs of the format listed in the following table.
| Internal (Intranet zone) | Remote employee (Default zone) |
|---|---|
http://selfservice/sites/site1 |
https://selfservice.fabrikam.com/sites/site1 |
http://selfservices/sites/site2 |
https://selfservice.fabrikam.com/sites/site2 |
http://selfservice/sites/user3 |
https://selfservices.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 |
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 provide one example: denying partner accounts access to internal collaboration sites.
Backing up and restoring collaboration sites
There are several options for backing up and restoring content that are appropriate for collaboration sites:
Built-in backup and recovery tools — Use the tools that come with Windows SharePoint Services 3.0 if databases are under 100 GB and there are not many customizations or customizations are packaged as solution.
Microsoft SQL Server 2005 Backup and Recovery tools — Use these tools if you have a SQL database administrator.
For more information, see Choose backup and recovery tools (Windows SharePoint Services).
Designing for secure external collaboration
The design sample poster includes an overview of how to plan for external secure collaboration. This section includes the introduction text for each item and links to the corresponding articles in the TechNet library.
| Design recommendation | Guidance |
|---|---|
Choose an extranet topology |
Protect your server farm by either using an edge firewall or by placing the server farm in a perimeter network. For more information, see the following articles on TechNet: |
Secure client-server communication |
Secure collaboration in an extranet environment relies on secure communication between client computers and the server-farm environment. Where appropriate, use Secure Sockets Layer (SSL) to secure communication between client computers and servers. For more information, see the following articles on TechNet: |
Protect back-end servers and the Central Administration site |
External secure collaboration requires Internet-facing servers. You can limit the exposure to traffic from the Internet by placing a firewall between Web servers and other servers and by hosting the Central Administration site on a backend server. For more information, see the following articles on TechNet:
|
Configure alternate access mappings |
Alternate access mappings support Internet deployment scenarios in which the URL of a Web request received by Internet Information Services (IIS) is not the same as the URL that was typed by an end user. This is most likely to occur in deployment scenarios that include reverse proxy publishing and load balancing. For example, reverse proxies can perform advanced functionality, such as receiving a Web request over the Internet by using SSL (HTTPS), but forward the request to the server by using HTTP. This is referred to as "off-box SSL termination." For more information see Plan alternate access mappings (Windows SharePoint Services). |
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 books for Windows SharePoint Services.