SharePoint Portal Server Architecture

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: June 9, 2004

This is a sample chapter from the Microsoft SharePoint Products and Technologies Resource Kit. You can obtain the complete resource kit (ISBN 0-7356-1881-X), which includes a companion CD-ROM, from Microsoft Press.

Microsoft Windows SharePoint Services and Microsoft Office SharePoint Portal Server 2003 share the same underlying technologies. This is a change from the first version of SharePoint Portal Server. Microsoft SharePoint Portal Server 2001 did not share underlying technology with SharePoint Team Services from Microsoft. In this version of Microsoft SharePoint Products and Technologies, SharePoint Portal Server, as the server product, works with and builds upon the architecture of Windows SharePoint Services. This chapter does not cover the feature differences between SharePoint Portal Server and Windows SharePoint Services. Instead, it focuses on the architectural differences that are found in SharePoint Portal Server and explains the architecture of services that are particular to SharePoint Portal Server.

Cc750088.note(en-us,TechNet.10).gif When referring to both products as a single unit, we’ll use the term SharePoint Products and Technologies.

Building on Windows SharePoint Services

Windows SharePoint Services is required when installing SharePoint Portal Server. SharePoint Portal Server can install over an existing Windows SharePoint Services installation, or if Windows SharePoint Services is not yet installed, SharePoint Portal Server installs Windows SharePoint Services first as part of the installation process.

Additional Services

SharePoint Portal Server includes services that are not offered in Windows SharePoint Services. These services can be viewed in the Services application in Control Panel and include the Administration service, the SharePoint Portal Alert service, the Microsoft SharePoint Portal Server Search service, and the Microsoft Single Sign-On service.

Cc750088.note(en-us,TechNet.10).gif During installation, all services that SharePoint Portal Server can provide are installed regardless of which services you choose to install. The services are then enabled or disabled based on which services the administrator chooses to provide to users.

Administration Service

SharePoint Portal Server installs an administration service, called SharePoint Portal Administration, that appears as SPSAdmin in the Services application in Control Panel. SPSAdmin can stop and start services that SharePoint Portal Server needs, including SPSSearch. It can also add or delete catalogs and can add or delete search applications as needed.

SPSAdmin is a service that was written to maintain the configuration of each server in a SharePoint Portal Server deployment. Essentially, this service runs on each server in the farm and is responsible for checking the configuration database every 30 seconds to ensure that the local server is performing its assigned roles.

In the SharePoint Portal Server Central Administration/Component Selection area, each server in the farm must be assigned at least one role to perform in the farm. When a role is assigned to a server in the farm, it is recorded in the configuration database. The SharePoint Portal Administration service checks this database every 30 seconds to ensure that the server is performing its assigned role or roles. If the service discovers that there is a modification in the server’s roles, the service will “turn on” or “turn off” those portions of the server’s code to either stop performing a role or to start performing a role.

For example, let’s assume that there are six front-end Web servers in a large farm. Now let’s assume that server1, a front-end Web server, is a search server. This server has a failure and is no longer available. The site administrator gives the role of search server to server2 and removes the role of search server from server1. Because the SharePoint Portal Administration service works locally on each server, each of the five servers that are still online will poll the configuration database and discover that the Search role has been moved to a different server. When server1 comes back online, the local SharePoint Portal Administration service on server1 will also discover the change and will stop the search service on server1 automatically after polling the configuration database.

Note that when you turn off the search service, the server is pulled out of rotation for queries and the new server won’t have any catalogs until the next index propagation. For indexing servers, all catalogs are removed when the server is turned off, and a new server is created with no catalogs

SharePoint Portal Alert Service

The purpose of the SharePoint Portal Alert service is to notify a user, when the user requests it, that there is a change to a designated item, document, list, or document library on the website. Alerts are managed by the job server.

Microsoft SharePoint Portal Server Search Service

Windows SharePoint Services can perform SQL text queries, but only on content that resides in a site from which the search query was invoked. Because SharePoint Portal Server has Microsoft SharePoint Portal Server Search service, it can index and perform searches on content that is external as well as internal to the portal site. Additionally, it can perform searches across servers and portals. Microsoft SharePoint Portal Server Search service is listed in the Services application as SharePointPSSearch. For more information on the indexing capabilities of SharePoint Portal Server, see Chapter 21, “The Architecture of the Gatherer.”

Microsoft Single Sign-On Service

Third-party enterprise applications such as PeopleSoft, SAP, Siebel, and Lotus Notes use authentication that is different from Microsoft Windows operating systems and SharePoint Portal Server. The Single Sign-On service is provided so that disparate authentication databases, such as Active Directory and a third-party application database, can map credentials from authenticated Windows users to enable a single sign-on environment. The Microsoft Single Sign-On service appears as SSOSrv in the Services application in Control Panel.

Changes to Front-End Components

SharePoint Portal Server has the same front-end/back-end split of components that Windows SharePoint Services has. Because SharePoint Portal Server has additional services that it can provide, it also has more front-end server roles and has more back-end database types than does Windows SharePoint Services. Figure 5-1 shows the components that are available in a SharePoint Portal Server deployment.

Figure 5-1.Architecture of SharePoint Portal Server includes front-end Web servers, search servers, a job server, index servers, and back-end databases

Cc750088.note(en-us,TechNet.10).gif The split between front-end and back-end components in SharePoint Portal Server is a logical one. Physically, the front-end and back-end components can exist on the same server or on separate servers. In fact, in a single-server deployment, all the server farm roles are performed on a single server.

Front-End Servers

Windows SharePoint Services has only one role for front-end Web servers. These servers host sites and process search requests. SharePoint Portal Server includes the ability to separate front-end roles for Web servers and also includes separate roles for index management servers, search servers, and a job server. One or more servers can fill each role, except for the job server, depending on the number of users that are supported. There is only one job server per portal site, regardless of how small or large the environment is.

Job Server

The purpose of a job server is to manage the additional services that are supported in SharePoint Portal Server that are not available in Windows SharePoint Services. This includes the following additional services:

Hosting the Single Sign-On pages
Importing user profiles
Performing audience calculations
Crawling and indexing portal site content
Hosting the Alerts service

Index Management Server

Windows SharePoint Services combines the services of hosting site pages, crawling content, and processing search queries from clients into one front-end Web server. SharePoint Portal Server allows these services to be performed separately. An index management server is dedicated to building and updating indexes, which includes crawling content and breaking down the crawled information through the indexing process.

Only one index server can crawl a content source. If you need better performance on crawls, you cannot get it by adding another index management server. To improve crawl performance, you must upgrade the server that is assigned to a particular content source. Index management servers and the indexing process are covered thoroughly in Chapter 21.

Changes to Back-End Database Components

Windows SharePoint Services installs one configuration database and one or more content databases for use with its sites. Even though SharePoint Portal Server installs over Windows SharePoint Services, it does not use any Windows SharePoint Services databases in their original installed state. When a portal site is created in SharePoint Portal Server, an additional three databases are created that are not in a Windows SharePoint Services deployment. A fourth database is created if the Single Sign-On service is used. SharePoint Portal Server also makes changes to the configuration database that is installed by Windows SharePoint Services.

In addition to changing existing databases, SharePoint Portal Server also changes how the front-end Web servers connect to the databases. Windows SharePoint Services front-end Web servers can use Microsoft SQL Server authentication or Windows authentication to connect to back-end databases, but SharePoint Portal Server front-end Web servers can use only Windows authentication. Also, Windows SharePoint Services front-end Web servers use OLE DB to connect to back-end databases. For most connections, SharePoint Portal Server front-end servers use ADO.Net instead. Only the Microsoft SharePoint Portal Search service uses OLE DB to connect to back-end databases.

Configuration Database

SharePoint Portal Server uses a configuration database in the same manner as Windows SharePoint Services. However, during installation SharePoint Portal Server adds extensions to the configuration database that is installed by Windows SharePoint Services. These extensions include adding a new schema and modifying tables by adding new stored procedures. This means that Windows SharePoint Services cannot connect to a SharePoint Portal Server configuration database and vice versa.

Additional Databases

SharePoint Portal Server ignores the content databases that Windows SharePoint Services installs. Instead, SharePoint Portal Server creates a different location for content databases. In addition, SharePoint Portal Server creates supplementary databases to support the services that a portal site can provide. These databases have a hyphenated name that begins with the name given to the portal and ends with a suffix that identifies the type of database. Table 5-1 has a list of the additional databases created in SharePoint Portal Server.

Table 5-1 Additional Databases in SharePoint Portal Server

Database Name	Purpose
Portalname_prof	Contains the profile database that holds user profiles and audiences.
Portalname_serv	Stores information for services, such as search and alerts, that are provided by a portal site. Also called the component settings database.
Portalname_site	Contains site content information and works like the content database in Windows SharePoint Services.

In addition to these three databases, a fourth database is created when the Single Sign-On service is configured. This database stores credential information for the Single Sign-On service. It does not start with the name of the portal because only one is created per server farm and instead can be named by the administrator.

Physical Configurations

Like Windows SharePoint Services, SharePoint Portal Server can be scaled from a single server to a large farm of servers. The difference in these configurations is the physical separations of the available components. As servers are added to a SharePoint Portal Server deployment, each server becomes more specialized in the services it provides.

Single Server

In a single-server configuration, all components (both front-end and back-end) are on a single server. This configuration can use a separate installation of SQL Server or use SQL Server 2000 Desktop Engine for the back-end databases.

Server Farms

Server farms are created in a SharePoint Portal Server environment when components are placed on separate servers. Server farms can range from small to large, depending on the needs of the environment.

The components that are considered front-end are the Web server hosting the portal site, the index server crawling the content and creating the index, the search server that processes client search requests, and the job server that coordinates available services. A small server farm keeps the front-end components on the same server while separating the back- end databases onto one or more servers. Medium server farms separate the indexing functions and the job server from the front-end Web servers and search services. A large farm can handle up to four index management servers, one of which must be a job server, and four search servers, which are separate from the Web front-end servers. To find out more about deploying server farms, see the chapters in Part 4, “Deployment Scenarios.”

Personal Sites vs. My Site

Personal sites and the My Site feature are separate features that are both available only in SharePoint Portal Server. Although the names of these two features are often used as synonyms for each other, they are not the same. Site administrators need a good understanding of the architectural differences between the two features to understand differences in the behavior of each.

Personal sites are Windows SharePoint Services sites that are created for individual users. Every user who has the Create Personal Site right can have a personal site. By default, the location of a user’s personal site is portalname/personal/username, where portalname is the name of the portal and username is the name of the individual user.

My Site is a single page located in the SharePoint Portal Server site. By default, the path for this page is portalname/My Site/default.asp, where portalname is the name of the portal. Every user who accesses the My Site URL downloads the same page. However, users often don’t realize this because some of the information on the page is personalized based on the user’s profile information and information from the user’s personal site.

So the difference between My Site and personal sites is that My Site is the portal page through which all users must pass to get to their own personal site. A user links to his personal site through the My Site page. It is hard to recognize that the My Site portal page is the same for everyone because it has personalization features. My Site is personalized based on a user’s profile information, and it includes links to document libraries and lists that the user has created on her personal site.

The major architectural difference is that the My Site page is owned and controlled by the site owner, while a personal site is owned and controlled by the user. This means that a user can customize the contents and views of her personal site; however, when a user tries to personalize the My Site page, the choices are limited.

User Profiles and Audiences

SharePoint Portal Server includes a way to integrate user profile information into site pages and to target content to a group of users. User profiles and audiences are contained in the portalname_prof database (where portalname is the name of the portal).

Populating the User Profile Database

The profile database is a list of user account property information. This information is obtained by importing information from a directory that contains user accounts or it is obtained manually by typing in account information. By default, SharePoint Portal Server can import a list of domain users from Active Directory, but code can be written against the SharePoint Portal Server object model that can be used to import information from other directory services or applications. User profile information is stored in a single table in the portalname_prof database. Updates to the database can be scheduled on a regular basis and can be incremental or full.

Creating Audiences

Audiences are also contained in the user profile database, but they are contained in a separate table from the one that contains user profiles. Creating an audience involves creating rules and then compiling the audience. Rules define what user accounts should be included or excluded from the audience. Rules created for any audience are stored in a separate table in the portalname_prof database.

When an audience is compiled, the rules are used as a filter against the complete list of user profiles. Because not all account information is imported into the user profile database, Active Directory is also queried during an audience compilation. Accounts that fit the rule are copied and placed in a separate table that holds the members of the audience. This table contains the members of all audiences for a portal and is separate from the table that stores the rules. The table that contains audience members is not updated, and remains static until the audience is recompiled.

Enabling and Configuring Single Sign-On Service

Like all services in SharePoint Portal Server, Single Sign-On installs automatically, but it is not enabled. Enabling the service requires an administrator to be physically at the server that is designated as the job server for the portal site. The administrator must specify a SQL Server in the server farm on which a credential database is created.

A developer can develop Web Parts that are Single Sign-On–aware and use enterprise application definitions to pull information from enterprise applications and display it on pages within a portal site. The purpose of an enterprise-application definition is to provide the connection from the enterprise application to the Single Sign-On Web Part on a portal site page. Figure 5-2 shows the relationship between Single Sign-On Web Parts, enterprise-application definitions, the enterprise application, and the credentials database.

Figure 5-2. SharePoint Portal Server connects users to enterprise applications using the Single Sign- On service and enterprise application definitions

Authentication with Single Sign-On

Authentication with the Single Sign-On service can be set up to work with groups or with individual users. In either case, enterprise application definitions are used to map credentials used by SharePoint Portal Server to credentials used in an enterprise application.

With group authentication, the individual user is associated with a managed group account. In this case, the user does not need to know an individual set of credentials. Instead, an enterprise application definition is configured by an administrator to provide the credentials needed. The enterprise-application definition maps the credentials used in SharePoint Portal Server to the enterprise application without users needing to provide alternate credentials.

Individual authentication is used when users know and manage their own credentials for the enterprise application. In this case, the enterprise-application definitions map the user’s SharePoint Portal Server credentials to individual credentials needed by the enterprise application that are stored in the credential database. If a user’s credentials are not yet in the Single Sign-On credential database, the Web Part redirects the user to the Single Sign-On logon form used to enter his credentials. Once the credentials are stored in the credentials database, the mapping should happen automatically so that user intervention is no longer needed.

Shared Services

In SharePoint Portal Server, by default, each portal site is configured as a separate entity from other portal sites. As a separate entity, a portal site individually supports and provides needed resources for all services. If the portal sites within a server farm belong to the same organization and support the same set of users, the use of shared services can allow the portal sites to consolidate and save resources.

Shared services centralizes the work required to provide services to one portal site by creating a parent/child relationship between the portal sites. When shared services is implemented, the portal site that provides the services becomes the parent while all other portal sites become children. Because the parent portal site provides services, the child portal sites are left with only site information—such as pages, areas, and lists—to support. The following lists how services change when shared service is implemented:

Search and index.

With shared services, crawling and index creation are consolidated in the parent portal site. Search requests from child portal sites are processed by the parent portal site.

Alerts.

With shared services, alerts are managed and tracked in a single alert store in the parent portal site.

Personal sites.

With shared services, personal sites are created only in the parent portal site and can be viewed and accessed from the child portal sites. The My Site portal page is also located in the parent portal site.

User profiles.

With shared services, a single user profile database is configured in the parent portal site and is accessed by the child portal sites.

Audiences.

With shared services, audiences are compiled and stored only in the parent portal site.

Single Sign-On service.

With shared services, only one Single Sign-On credentials database is created. This database is located and administered only in the parent portal site.

Shared services is an all-or-nothing configuration at the server-farm level. This means that if one portal site in a server farm is using shared services, all portal sites in that farm are using shared services. Once a portal site in a farm is designated as the parent, all other portal sites in the farm automatically become child portal sites. It is also a one-way decision, meaning that once you decide to turn on shared services, you can’t turn it off later.

Database Access in Shared Services

When shared services is implemented, child portal sites look to the parent’s configuration database for shared services data. Although some data is still needed from the original databases used by the child sites after shared services is configured, most information is retrieved from the parent site’s databases. By default, each portal site has two user accounts that are used to access databases. These accounts are called the configuration database administration account and the application pool account for the portal site.

The configuration database administration account is the account used by the CentralAdminAppPool application pool to access the configuration database and all other databases for a portal site. It is recommended that all servers in a server farm use the same account for the configuration database administration account. Once shared services is implemented, this recommendation becomes a requirement. The MSSharePointPortalAppPool is used by the portal site to access the SharePoint Portal Server databases. Although child portal sites must have access to the parent configuration and content databases for added security, that access can be limited to read-only.

Summary

Because SharePoint Portal Server 2003 is built on Windows SharePoint Services, much of the underlying architecture is the same. Both handle page requests and .aspx pages in the same manner. The main architectural differences lie in the way the additional services provided by SharePoint Portal Server are handled. As the server product in Microsoft SharePoint Products and Technologies, SharePoint Portal Server 2003 has additional services that support a larger and more diverse set of users. To accommodate this, additional database types and additional front-end roles are included in SharePoint Portal Server that are not included in Windows SharePoint Services.