SharePoint Portal Server

SharePoint Portal Server (SPS) can really be thought of as a specific application built on top of SharePoint Services. Just like the Office suite, SPS can take advantage of sites, membership, lists, and documents. However, the purpose of SPS is different from that of Office. Whereas Microsoft Office uses SharePoint Services primarily to implement ad-hoc collaboration, SPS uses SharePoint Services to implement a more formal and permanent site structure for an organization. Although ad-hoc site creation is still possible, many of the sites in SPS will be long-lived.

The primary entry point into SPS is the portal home page. End users begin at the home page regardless of their role in the organization or place in the company hierarchy. The home page is intended to deliver company announcements and provide tools for locating useful resources. From the portal home page, users can gain access to SharePoint Services sites directly in the browser. From these sites, end users can retrieve documents and lists similar to those available in Microsoft Office 2003.

Installation Considerations

Before beginning your installation of SPS, you need to consider some infrastructure issues. SPS ships with an administrator's guide that has a complete set of planning topics, so I will not try to repeat all of that detail in this section. Instead, I will just go over the major things you should consider.

User Capacity

One of the first issues to consider is the overall capacity of your solution. Although SPS scales well in a test environment, it has some limitations you will want to keep in mind as you plan for deployment. Under most scenarios, these limitations will probably never be reached, but understanding how SPS scales can help keep the solution running trouble-free. All of the test results that are referenced here assume a server-class, dual-processor machine with 1GB of RAM.

Determining the number of concurrent users that can access a SPS installation is tricky at best. The total number of concurrent users is affected not only by the hardware configuration, but also by the activity level of the users themselves . Obviously a system can handle many more simultaneous users that are only occasionally pulling read-only information as opposed to users that are consistently engaged in read-write operations. With that in mind, you can make some statements regarding scalability assuming a moderate level of read-write activity from a group of simultaneous users.

A single web server environment is good for just under 4,000 concurrent users, assuming the required database server is deployed on a separate machine. This number rises to about 6,000 concurrent users when a second web server is added and a farm is created. For three web servers, the number of concurrent users rises to about 7,000.

After four web servers are added to the farm, the number of supported concurrent users does not rise significantly. This is because access to the database server becomes the limiting factor. In order to scale beyond 7,000 concurrent users, a second database server must be added to the infrastructure.

Other Limitations

Along with user capacity, SPS has limits associated with several other key parameters. The limits covered here are not hard limits, but exceeding them can degrade overall system performance. Generally these limitations are large and will not affect most organizations; however, they are worth reviewing before you get started with your installation. Table 2-1 summarizes the key limitations.

Table 2-1: SPS limitations

ITEM	LIMIT
Total web sites in portal	10,000
Total subsites beneath any one web site	1,000
Total documents in any one folder	10,000
Total documents in the repository	2,000,000
Total single document size	50MB
Total entries in any one list	3,000
Total web parts on any one page	100

Deployment Architectures

SPS may be deployed in any of several different scenarios. The business needs of your organization will largely determine the deployment scenario. In this section, I'll cover each of the deployment scenarios and under what conditions it is appropriate to implement them.

Each of the available scenarios requires you to deploy several different components that support the portal. SPS itself consists of four major components: the Web component, Index component, Search component, and the job server. Additionally, SPS requires a SQL Server installation to support the configuration of the portal and to act as the document repository. As an option, you can also choose to install the components to provide backward compatibility between the SPS 2003 document repository and the SPS 2001 repository.

Stand-Alone Server

The stand-alone server is the simplest deployment option and the one that you will use throughout this book. In a single-server deployment, all four of the SPS components and the SQL Server database reside on a single machine. The SQL Server database may either be a complete installation or the Microsoft SQL Server Desktop Engine (MSDE). The optional components for backward compatibility with SharePoint 2001 may also be installed on the same machine. Exercise 2-1 (at the end of this chapter) will take you through a complete stand-alone server installation that you can use with the rest of this book. Figure 2-5 shows a conceptual drawing of a stand-alone server deployment.

Figure 2-5: A stand-alone server deployment

Small Server Farm

A small server farm is defined as a single web server running the Web component, Index component, Search component, and job server. A second server is used to host SQL Server 2000. In this configuration, you must create an account in the local Power Users group on the web server. This account is then given Security Administrators and Database Creators membership on the SQL Server installation. Detailed installation instructions are available in the administrator's guide and will not be repeated here. Figure 2-6 shows a conceptual drawing of a small server farm deployment.

Figure 2-6: A small server farm deployment

Medium Server Farm

A medium server farm is defined as having at least three servers. At least one, but possibly more, servers are set up as web servers with the Search component installed. These servers are joined together using Network Load Balancing (NLB) to function as the front-end web servers that will receive HTTP requests . In this configuration, you must also set up an account in the local Power Users group on each web server. A second server is used to host the Index component and the job server. This server must also have an account set up in the local Power Users group. Finally, a third server hosts SQL Server 2000. Detailed installation instructions are available in the administrator's guide and will not be repeated here. Figure 2-7 shows a conceptual drawing of a medium server farm deployment.

Figure 2-7: A medium server farm deployment

Large Server Farm

A large server farm is defined as having at least six servers. At least two, but possibly more, servers are set up as web servers joined together using NLB. At least two, but no more than four, separate servers are configured with the Search component. At least one, but no more than four, separate servers are configured with the Index component and job server. Finally, at least one separate server hosts SQL Server. Just as in the other scenarios, you must set up an account in the local Power Users group. Detailed installation instructions are available in the administrator's guide and will not be repeated here. Figure 2-8 shows a conceptual drawing of a large farm deployment.

Figure 2-8: A large server farm deployment

Shared Services

In large organizations, you may find it appropriate to create more than one installation of SPS. In these cases, you can simplify deployment and management by using Shared Services. Shared Services allow you to set up a single installation to manage user information, search services, alert services, and single sign-on services. Because these services are likely to be common to all installations within an organization, sharing them makes management and configuration easier.

Upgrading from SharePoint Portal Server 2001

Although it is possible to upgrade an existing SPS 2001 installation to the 2003 version, this is not a process that you should take lightly. First of all, SPS requires Windows Server 2003. This means that you will have to begin the upgrade process by first upgrading all of the web servers in your farm where SPS will be deployed.

During the upgrade process, some of the information contained in SPS2001 is imported into SPS2003, but much of the information is not used. In particular, any portal customizations and web parts you created under SPS2001 will not be used in the upgraded portal. Much of this content is based on fundamentally different technologies with no backward compatibility. Additionally, security roles do not carry over from SPS2001.