Planning Your SharePoint Deployment

Planning your SharePoint deployment is important so that you not only know what to expect during the installation process but also develop your plan for growth and user support. This section presents the decisions you need to make before starting your SharePoint installation, and discusses how your portal will integrate with the authentication and messaging components that may be present in your environment.

Choosing your shared services roles

Shared services in Microsoft Office SharePoint Server 2007 (MOSS) can be installed on one SharePoint location while providing services to one or more SharePoint instances, with each installation sharing the same settings and administration model. Before you proceed with installation, decide whether you will provide or host shared services or consume shared services, meaning that you are using the shared services provided by another installation. If you choose to consume shared services, you consume all of the services and cannot pick a subset to use. In other words, if you want to consume the search service provided by another SharePoint farm, you will also consume profiles, audiences, the business data catalog, and the other shared services. Unlike the shared services configuration in SharePoint 2003, deciding whether you will share services provided by another SharePoint deployment is not irreversible, so you can change this setting after initially configuring it.

The shared services provided in MOSS are detailed in Table 2.1.

Table 2.1. Shared Services Provided in MOSS

Shared Service	Description
Search and Alert Processing	The operations that run search and indexing are shared services. Content sources are defined at the shared service level, and search is responsible for gathering and processing alerts that are set on each portal.
Profiles and Audiences	Crawling and storing of profiles from multiple sources is a shared service. Additionally, audiences are defined at the shared service level.
My Sites	Provides My Sites for user-based collaboration.
Business Data Catalog	The Business Data Catalog lets you make data in external sources available to your SharePoint application. The definitions of what external data sources to connect to and the processing of those connections is done by shared services.
Excel Services	Provides server-side calculation and thin rendering of Excel workbooks.
Project Server	Provides access to MS Project data and exposes Web services for interacting with project data.
Usage Reporting	Processing of user activity is done by shared services.

If you can agree with another group in your organization about the shared services configuration and administration, you are a good candidate for sharing these services, either as a consumer or as a provider. It is important to agree upon the service level of the shared service administration if you opt to share so that expectations are clear. For example, you may want to implement a service level agreement in the organization that outlines processes and the duration of implementing requests to make changes such as adding content sources to search or uploading a business data catalog entity.

Defining your SharePoint farm topology

Several factors can help you determine what SharePoint farm topology is appropriate for your organization. These factors include:

• The size of your portal content (number of documents and so on)

• Number of SharePoint users

• Expectations of up time

• Scope of the SharePoint services (whether this installation provides or consumes Shared Services)

Based on these factors, you will choose whether a single-server or a farm installation (small, medium, or large farm) is right for your installation. Each scenario is described in detail in the following sections along with some guidelines to help you pick the right topology. It is important to test your proposed architecture in your environment by simulating the users and load on your network using your hardware and representative sample data.

Physical architecture key concepts

The planning and deployment process involves a few key concepts and terms:

• Portal topology: How servers and services are configured and deployed to provide the engine that runs an organization’s portal.

• Server roles: Servers can be configured with different services so that they play unique roles within your SharePoint deployment.

  • Web front end: Renders Web pages and processes business logic.

  • Application server: Provides services to the farm such as indexing, search, Excel calculations, and Project Server.

  • Database: Runs the SQL Server databases.

• Server farm: A collection of servers that work together to provide your SharePoint services.

Choosing your portal topology

You can choose from four possible portal topologies, or distribution of services and servers, for your MOSS deployment. Only the first two (single server and small server farm) are applicable to WSS deployments. The four topologies are described in the following list.

• A single server installation has all the services including SQL Server and SharePoint residing on a single piece of hardware. The SQL Server installation can either be SQL Server Express, SQL Server 2000 SP3 (or later), or SQL Server 2005.

• A small server farm separates the SQL Server back end from the SharePoint front end. The SQL Server can be either SQL Server 2000 SP3 (or later) or SQL Server 2005. The MOSS front end can be one or two servers, and one or both run all of the SharePoint services and are configured as Web servers managing client requests and application servers providing shared service roles.

• A medium server farm has the Web application server separated from the application server and the SQL Server back end. The SQL Server can be either SQL Server 2000 SP3 or later or SQL Server 2005. The Web server front end can be one or more MOSS servers providing Web services and search services. The application server is a MOSS installation that provides shared services such as indexing and Excel services, if applicable. This topology is not applicable for WSS.

• A large server farm has a clustered SQL Server back end and several Web server front ends and application servers. The front-end Web servers are two or more MOSS installations that support client requests. The two or more application servers have the application services such as search, indexing, and Excel services delegated among the servers. This topology is not applicable for WSS.

These topologies vary in number of servers and distribution of services for performance and ability to withstand hardware failures. They also can be differentiated by the number of users that they are designed to support. The following list provides approximate numbers for each topology.

• Single server with SQL Express: Typically < 500 users

• Single server with SQL Server: Typically < 5,000 users

• Small farm: Typically < 50,000 users

• Medium farm: Typically < 100,000 users

• Large farm: Typically < 500,000 users

Table 2.2 details sizing guidelines that help you choose the appropriate configuration for your environment based on the number of users that you support as well as the pros and cons.

Table 2.2. SharePoint Server and Farm Topologies

Topology	Number of Servers Required	Applicable to WSS?	Pros	Cons
Single Server	1	Yes	Simple installation Can use SQL Server Express, SQL Server 2000 SP3, or SQL Server 2005	No redundancy
Small Farm	2–3	Yes	Multiple front ends can provide some protection from failure	Data is not protected for server failure
Medium Farm	3–4	No	Provides capacity for growth to break out services	Data is not protected for server failure
Large Farm	6+	No	Provides the most protection against server failure Provides great deal of growth capacity	Requires more server hardware and serverhard ware maintenance

Considering Administrator Security Needs

MOSS provides many levels of administrator security permissions. By defining your administrator roles before the installation, you establish a strategy for managing your portal throughout its deployment.

The administrative levels that you need to consider are

• Shared services administrators: These administrators are responsible for configuring and maintaining the shared services. It is possible to give permissions to particular items in shared services, like personalization features such as profiles and audiences, but that granularity should only be necessary in the most distributed environments. This level of administration is not necessary for WSS installations.

• Central admin: Central administration permissions are specific to the SharePoint farm. There are both operations and application administrative tasks, such as creating and extending Web applications that your administrators with central admin permissions perform.

• Site owners: Site owners are allowed to configure the overall site settings for the site, such as content types and navigation.

Integrating with network infrastructure

As with most Microsoft products, integrating with other network server components enables you to extend SharePoint functionality. The following are some of the network interface points you should consider.

Providing authentication

There are several methods available to provide SharePoint authentication. The goal in choosing the authentication method appropriate for your organization is to only require one logon by the user and to use any existing authentication infrastructure.

Active Directory

Active Directory (AD) is the standard default authentication option for organizations that primarily use a Microsoft server infrastructure. As in previous releases, SharePoint integrates nicely with Active Directory out of the box. The key integration points are

• User authentication

• User and group management

• User profile replication

• Active directory federation for single sign on

• AD directory management Web service is provided in SharePoint

Pluggable authentication

MOSS and WSS support non-Windows-based identity management systems via integration with ASP.NET pluggable forms. Forms-based authentication allows integration with systems that implement the membership provider interface and provide a way for non-Active directory organizations to integrate with their authentication provider.

SQL Server authentication

As with the forms-based authentication method, it is now possible to bypass Windows authentication and authenticate directly with SQL Server. This is useful for environments that don’t have any authentication provider available.

Using SQL Server

If you are deploying any of the farm configurations, the back-end database server must be running SQL Server 2000 SP3 or later or Microsoft SQL 2005. If you are installing a single-server scenario, you can either have an SQL Server 2000 SP3 or later or Microsoft SQL 2005 database, or you can use SQL Server Express (installed during SharePoint installation).

Using Exchange Server

Exchange server is one of the most widely deployed corporate e-mail server platforms in the world. Configuring SharePoint to send e-mail via exchange or using SMTP is straightforward. SharePoint also includes protocol handlers that allow the indexer to crawl Exchange content and make it available in the portal. Other areas of integration include:

• Using public folders for team site e-mail integration

• Accepting incoming e-mail SharePoint through discussion boards, calendars, document libraries, and announcements

• Accessing inboxes, calendars, and to-do lists via Web Parts