Configuring SharePoint Portal Server 2003

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.

As a classic example of a multitiered distributed architecture, Microsoft Office SharePoint Portal Server 2003 presents some unique administration requirements. While the administration tools provided with Microsoft Windows SharePoint Services discussed in the previous two chapters serve to configure and manage each server individually, they do not suffice when faced with the multitude of servers that are usually involved in using SharePoint Portal Server 2003. If multiple database servers, Web servers, and other component servers are present in this environment, each will require a single place to go that allows for configuration and management of the individual servers and of the farm as a whole.

The Web-based tool provided with SharePoint Portal Server 2003 is called SharePoint Central Administration. By maintaining a list of all portal sites in the farm, this tool allows the administrator to configure the many services provided by each portal site on a per-portal-site basis. Furthermore, by using the list of all servers in the farm, the administrator is able to quickly navigate to those servers to perform server-level management of the servers’ portal site services. It also allows the administrator to perform ongoing management tasks such as portal site management, which includes site content and security administration, user profile and personal site management, audience creation and management, as well as search and index management.

This chapter will concentrate on showing the portal site configuration tasks an administrator will have to perform both after installation and on an ongoing basis as new servers are added or removed from the farm. This will include the configuration of virtual servers and the subsequent creation of portal sites on those virtual servers.

On This Page

A Quick System Overview
SharePoint Central Administration
Creating Additional Application Pools
Summary

A Quick System Overview

To properly set the stage for what the administrator does in configuring SharePoint Portal Server 2003, let us review the many component services that provide the product with its functionality. A total of four types of servers are part of a server farm for which configuration tasks must be performed:

Web.

• This type of server receives HTTP requests from the client community and serves the portal site content in the form of Web Pages.

Index.

• These servers crawl all portal site content, as well as chosen external content, and created index files used when users utilize the search feature of the portal site.

Search.

• This type of server receives queries from users’ search requests, handles the queries by using the index files created by the index servers, and returns the matching results.

Job.

• This server coordinates scheduled jobs, such as content crawls by the index server or profile imports from Active Directory.

  Additionally, there are three more server types that provide support services to the farm:

Database Server.

• All portal site configuration information, site security settings, and content is stored in multiple databases in one or more required database servers.

E-Mail Server.

• These optional servers will relay alert messages from the portal site to administrators and users.

HTML Viewer Server.

• This optional type of server installed from the Office 2003 Resource Kit can be set up to convert standard Microsoft Office documents to HTML on behalf of users who do not have Microsoft Office or the Office Viewers installed.

To qualify as a potential Web, index, search, or job server in the farm, each of these types of servers will need to have SharePoint Portal Server 2003 installed on them. Not only must each server be assigned its role in the farm, but each service that the server will provide must also be configured and tailored to the specific environment to achieve the desired effect.

SharePoint Central Administration

After installing SharePoint Portal Server 2003, you might notice that you do not yet have a working portal site. You will have to designate all the server types just mentioned and configure their services before you can create a portal site.

The install does create an administration website on the server. This is the site from which the SharePoint Portal Server Central Administration Web pages are served via Internet Information Services (IIS). During installation, a random port is generated for this administration website as a simple form of security and to avoid using port 80, which will be needed for the actual portal site users will access. Therefore, to administer a portal site through a server named woodgrove on which the administration website was installed on port 9999, the administrator would use the following URL in his browser to navigate to the main portal site administration page: https://woodgrove:9999/sps/. Figure 17-1 depicts the SharePoint Portal Server Central Administration Web page displayed in the browser for this scenario.

Figure 17-1.The SharePoint Portal Server Central Administration page

There are two considerations with this random port assignment: first, this means that each server for the portal site has a different administration port; second, you might need to secure this port. Even though only user accounts armed with the knowledge of the random portal site and with appropriate administrator privileges can modify settings, all traffic is still unencrypted between the administrator’s workstation and the server being managed. This can be an issue in your environment because some configuration pages require assigning service accounts and their passwords.

To resolve the first problem, we want to simplify remote administration by changing the port number so that it is consistent on all servers on the server farm. This allows the administrator to type the URL for the central administration pages without going through the Site Settings page for each server. You will need to be logged on as a member of the local administrator’s group to perform these tasks.

Standardize the port number for the Central Administration pages

1. Open a command prompt.

2. Navigate to %Program Files%\Common Files\Microsoft Shared\web server extensions\60\BIN.

3. Type stsadm.exe -o setadminport -port port_number, and then press Enter.

   For example, to specify 8088 as the common port, type

   stsadm.exe -o setadminport -port 8088

4. Close the command prompt.

5. Update the shortcut for SharePoint Central Administration on the All Programs menu for other servers. Do this by using the following steps:

   1. On the taskbar, click Start, point to All Programs, point to SharePoint Portal Server, and then point to SharePoint Central Administration.

   2. Right-click SharePoint Central Administration, and then click Properties.

   3. On the Web Document tab, in the URL box, replace the existing port number with the updated port number.

      For example, if the updated port number is 8088 and the existing URL is https://localhost:10505/sps/Default.aspx, change 10505 to 8088 so that the URL is https://localhost:8088/sps/Default.aspx.

   4. Click OK.

Keep in mind that this affects the port for the Windows SharePoint Services Central Administration pages as well because they are served out of the same virtual server.

To resolve the security issue, encryption is required and available by configuring IIS with a security certificate and then configuring the administration website to require a secure channel with Secure Sockets Layer (SSL). Refer to the SharePoint Portal Server 2003 documentation on Office Online at https://office.microsoft.com/home/default.aspx for details on how to set this up. Assuming that the SSL certificate is already installed on the servers, the following command will set all servers for the portal site to require SSL when accessing the administration pages:

stsadm.exe –o –setadminport –ssl

Granting Administrative Access to the Portal Server Farm

One of the first configurations relating to a portal server that you need to understand and set is administrative access control. There are two high-level administrator types for a portal site.

Users who are members of the local Administrators group on a portal server have full administrative access to the server’s configuration and potentially all the portal site’s content. If the user has Administrators group membership on a portal server that is playing the Web front-end server role, that user will be able to access all content and perform all site administration tasks. On non-front-end Web servers, such members are able to determine settings for the entire farm of servers with respect to their farm service roles simply by navigating to the SharePoint Portal Central Administration page on that server.

Another way to grant portal site administrator privilege to a user is to assign user accounts (or group accounts) to what is called the SharePoint administrators group account. The account is defined by navigating to the Set SharePoint Administrative Group Account link found in the Security Configuration section of the SharePoint Portal Server Central Administration page. Even though the location implies a user account, in actuality, any Active Directory account can be assigned here, including group accounts.

  It is considered a best practice to assign an Active Directory Global Group account as the SharePoint administrators group account to avoid accidentally losing administrative access should the user account be deleted.

There are a few tasks that a user associated to the SharePoint administrators group account cannot perform. Following is a list of tasks that only the local administrator can perform:

• Extend or unextend a virtual server

• Change the SharePoint administrators group

• Manage paths (inclusions and exclusions)

• Change the configuration database

The SharePoint Portal Server Central Administration Page

The main SharePoint Portal Server Central Administration page has four categories of links leading to appropriate configuration subpages. These categories and links allow for configuration of each of the components’ servers, services, and features that relate to the functionality of the farm. The four categories are Server Configuration, Portal Site and Virtual Server Configuration, Security Configuration, and Component Configuration. The remainder of this chapter will be organized by these categories. The Portal Site and Virtual Server Configuration links will be covered last as part of an overall discussion on virtual servers as they relate to portal site creation.

Server Configuration

The Server Configuration category of links is used to configure server topology such as Web, index, search, and job server assignments; database server settings; e-mail server information; and server farm account settings. This area, depicted in Figure 17-2, is the first area to go to every time a new server is added to the server farm.

Figure 17-2.The Server Configuration links on the SharePoint Portal Server Central Administration page

Configure Server Topology

This link is to a page that is used to view and assign the components of SharePoint Portal Server for each server in the farm and to remove servers from the farm. This page also allows administrators to change the components that servers in the farm will service. In effect, the four server types discussed earlier are defined by assigning respective servers one or more components to service. For example, a Job Server is defined by assigning to it the Job service component.

There are three main sections to the Configure Server Topology page: Database Server Settings, Component Assignments, and Problems With This Configuration. Figure 17-3 shows the first two sections of the page.

Figure 17-3.The Configure Server Topology page, which is used for component assignment

Database Server Settings

Because everything, including configuration, is stored in a database, it makes sense to have to configure database settings first. There are four databases that are used in the portal site, but only the first three are configurable with respect to which SQL Server will host that database. Following is an explanation of those three databases and a few other items appearing in this section of the Configure Server Topology page:

Configuration Database Server.

• The configuration database maintains connections between servers and content databases, stores server settings, and identifies which content is to be provided by which virtual servers. There is one configuration database per stand-alone server or per server farm. Each server in the farm must be associated with the configuration database by connecting it to that database. The default name of the database is SPS_01_Config.

  Typically, the page will already display the server assigned during the product’s post-installation Portal Configuration Wizard. Therefore, clicking the listed server will show a page displaying the name of the existing configuration database (as well as the database server name). Also, the option of disconnecting the managed server from that database will be displayed. This is the preferred method for removing a server running SharePoint Portal Server from the server farm.

Content Database Server.

• The content database is where all portal site content will be placed. By default, the server hosting the portal site content database is the same as the configuration database. This can be changed here to distribute the database load. Also, because the portal site will have many sites—and potentially thousands—more than one database on more than one server can be manually defined. However, only one server is designated as the default database server on whose databases new sites will be created. When you create a new site, the databases on the designated default database server are queried and the new site’s content is added to the database that has the most available space. The default database name for the first portal site content database is composed of the first eight characters of the first portal site’s name, followed by a number, and followed by _SITE. For example, if the portal site is named Woodgrove, the content database would be Woodgrov1_SITE. Keep in mind that even though this is the default database used for both portal and team sites, a separate database can be defined and used to contain team sites.

Component Settings Database Server.

• This database stores service information for each portal site in a deployment. For example, each time SharePoint Portal Server 2003 updates an index, it creates a gatherer log entry in a table in the component settings database for the portal site. The default database name will start the same way as the content database but end with _SERV. Using the same example as in the previous paragraph, the database would be named Woodgrov1_SERV.

Profile Database Server.

• The profile database is used to store the content for the My Site feature, which gives each portal site user a personal site. It will always default to the same server as the configuration database server and cannot be changed here. This database name will end with _PROF. Using the same example as before, the database would be named Woodgrov1_PROF.

Global E-Mail Server.

• Even though this is not a database server, it appears in this section and should be configured for the farm. The farm can operate without having an e-mail server defined; however, the alert feature will not function. The alert feature allows users to subscribe to lists and documents and be alerted via e-mail when those lists or documents change. The configuration page allows you to set the SMTP e-mail server name or IP address (which can be Microsoft Exchange, the IIS SMTP service, or any third-party SMTP server that accepts Anonymous connections) that the alerts should show the change notification as coming from and to whom replies will be sent, as well as the character set used for the e-mails. Keep in mind that this is a global setting for the farm. If a certain server needs to be pointed to a different e-mail server (such as for a portal server residing outside of a firewall), that server can have its e-mail server setting changed on its Windows SharePoint Services Central Administration page.

Single Sign-On Credentials.

• If you are wondering about Single Sign-On credentials, they too do not have anything to do with databases and are configured with an optional setting used in highly customized portal site implementations. Single Sign-On allows you to store and map an application’s account credentials to user account credentials. This prevents users from having to sign on again when portal-based applications retrieve information from business applications, such as third-party enterprise resource planning and customer relations management (CRM) systems.

By using Single Sign-On, you can centralize information from multiple back-end applications through a single portal site that uses application definitions. By using application definitions, you can minimize and automate the sign-on process to these applications in a more secure environment. In addition, SharePoint Portal Server 2003 provides an easy interface for developers to create and extend this feature.

Component Assignments

The Component Assignments area lists all servers that have been assigned some role in the server farm. Servers that are assigned as database servers or e-mail servers will not have a hyperlink, while servers that play one of the following key component roles will have a hyperlink: Web, Search, Index, and Job. This makes sense because the hyperlink leads to the SharePoint Central Administration pages as serviced by the virtual server on that server, which of course requires SharePoint Portal Server 2003 to be installed on that server.

To assign or change the component roles that the listed servers will play, click the Change Components button at the bottom of the page. This can be useful if, for example, you add servers to your server farm. You add a server to the farm by first installing SharePoint Portal Server 2003 on the server. You will then be able to see it as a server to which you can assign one of the four component roles (Web, Search, Index, or Job).

You will need to have at least one Web server to service the client HTTP requests and serve out the portal site content. Because a portal site needs to offer search capability, you will have to assign at least one index server to create indexes from the content it crawls and one search server to handle the client requests using these indexes. Finally, you will need to assign one job server to handle scheduling of the index crawls among other services. All four roles must be assigned to a server before a portal site can be created.

To change component assignments for the server farm

1. On the SharePoint Portal Server Central Administration For server_name page, in the Server Configuration section, click Configure server topology.

2. On the Configure Server Topology page, click Change Components.

3. On the Change Component Assignments page, in the Component Assignment section, do one of the following:

   • Select a check box to assign a component to a server.

   • You can assign more than one component to each server.

   • Clear a check box to remove the assignment of a component to a server.

4. In the Job Server Component section, in the Job server list, select a job server.

5. If you have installed the server component for backward-compatible document libraries, in the Document Library Server Component (Optional) section, in the Document library server box, type the URL of the server to run the document library server component.

6. If you are not using SSL, the URL should be of the form https://server_name or server_name.

7. If SSL is enabled or enforced on the document library server, the URL must be an https address (for example, https://server_name).

8. Click OK.

In a single-server scenario, one server plays all roles. However, in larger environments you will want to distribute the services for availability and performance reasons. Refer to Chapter 9, “Capacity Planning,” to determine how many servers of each server type you will need. Also refer to Chapter 12, “Deploying Medium and Large Server Farms,” for additional details on recommended server role configuration scenarios.

Problems With This Configuration

Found at the bottom of the Configure Server Topology page, the Problems With This Configuration section simply provides reminders of any missing server-role component configurations. If all required components have been configured, you will see the following message:

“There are no issues at this time. Your farm is fine.”

Otherwise, you will see messages reminding you of configuration tasks you should perform.

One last item to cover on this page is the Remove Server button. Click this button to remove servers from the farm only in the following situations:

• The server does not have SharePoint Portal Server installed on it.

• The server running SharePoint Portal Server is unresponsive or offline.

• The server is running the optional component for backward-compatible document libraries only.

Before you remove a server from the server farm, you must remove all dependencies from the server, unless it is the last computer remaining in the server farm.

Configure Server Farm Account Settings

This is a very important page, as it relates to the user accounts used by the various services to perform their tasks as well as to some connectivity settings the services might need. If you are wondering why we’ve skipped the four links following the Configure Server Topology link in the Server Configuration section of the SharePoint Portal Server Central Administration page, it is because navigating to them will show that they point to the same configurations discussed on the Configure Server Topology page.

You can configure the following settings on the Configure Server Farm Account Settings page:

Contact E-mail Address

As part of the HTTP header in the requests it makes to crawl content, SharePoint Portal Server 2003 provides an e-mail address to each website it crawls when creating an index. If a problem occurs while crawling (for example, the crawler is hitting the site too much), the administrator of the website can contact this address. All portal sites on the server provide this e-mail address to the crawled site while creating indices. For this reason, the e-mail address for the server farm administrator is typically specified.

Configuration Database Administration Account

The configuration database administration account is the user name and password that SharePoint Portal Server uses when connecting to the configuration database or when propagating full-text indexes from index management servers to search servers. At a minimum, this account must be a member of the Power Users local group on all the front-end Web servers, index management servers, and search servers. This account must also be a member of the local Administrators group on the document library server. In addition, this account must be a member of the Security Administrators and Database Creators server roles on Microsoft SQL Server.

Default Content Access Account

The default content access account is the user name and password used by the index component servers to crawl content outside the portal site. There are many aspects to consider when choosing this account, including the following ones:

• When SharePoint Portal Server connects to external servers to create content indexes of sites hosted on the external Internet server, it connects to those servers by first providing the default content access account to establish a connection. If this account has not been configured, SharePoint Portal Server provides the anonymous account. The account used must have Read permissions for the websites and servers being crawled.

• If there is a proxy server to pass through to get out to the Internet to crawl external content, the account mentioned above must have proxy permissions on the proxy server to browse externally to be able to crawl the sites and create a content index of these Internet sites. Without permissions, the index servers can crawl only content on the local intranet.

• The access account should be a member of the SharePoint administrators group. If the access account is not a member of the SharePoint administrators group, the server will crawl the site but the content index will not be secure because all users will be able to access the documents. In the case of intranet crawls, it means that some data might not be included in the content index because the account might not be able to access all the sites under a Windows SharePoint Services site.

Portal Site Application Pool Identity

This account is used by the default application pool (MSSharePointPortalAppPool) created by SharePoint Portal Server to contain all portal sites. It is the account used by the application pool to do the initial lookup to determine which content database stores the user- requested URL’s data. It is also used to access the indices on search servers, and it plays a role in importing data from Active Directory if the Profile Import feature is enabled.

The following is a list of security considerations for this account:

• In a multiserver portal site, the account must be a domain account and must have the db_owner role on the Configuration Database.

• This account must be a member of the local Administrators group on document library servers.

Proxy Server Settings

With this link, you can set SharePoint Portal Server 2003 index servers to use a proxy server when they create crawls of external websites so that they can create full-text indexes of those sites. Proxy servers are generally used to enhance the security of intranets by working along with a firewall to prevent unauthorized access in from or out to the Internet. Proxy servers can also enhance performance by caching recently accessed Web pages, which minimizes download time.

By default, SharePoint Portal Server uses the proxy server setting defined for the default content access account. The default content access account derives its proxy server setting from the current proxy server settings in the Microsoft Internet Explorer application on the crawling server.

Changes to the proxy settings for the SharePoint Portal Server computer do not affect other applications on the server. For example, configuring the server to use a proxy server that is different from the proxy server used by Internet Explorer does not affect Internet Explorer.

Changing the proxy settings on the Search Server Settings page affects servers running the index component only. For other servers, you can change the proxy settings from the Configure Server Farm Account Settings page.

Security Configuration

The Security Configuration section is used to view or configure security settings for Microsoft SharePoint Products and Technologies for servers in the server farm, including blocked file types and antivirus configuration if third-party antivirus software has been installed. Figure 17-4 displays the Security Configuration section, which is the next area on the SharePoint Portal Server Central Administration page that you might want to configure before creating your first portal site.

Figure 17-4.The Security Configuration section on the SharePoint Portal Server Central Administration page

Set SharePoint Administrators Group Account

As mentioned previously, the SharePoint administrators group account is where you assign a domain user or group as the administrator of the farm.

Manage Site Collection Owners and Manage Website Users

The purpose of these two links relate to managing access to sites and will be discussed in Chapter 18, “Managing SharePoint Portal Server 2003.”

Manage Blocked File Types

Windows SharePoint Services provides the ability to restrict certain kinds of files from being uploaded or retrieved, based on the file extension. By default, several standard file extensions are blocked, including any file extensions that are treated as executable files by Microsoft Windows Explorer. Files with curly braces, { or }, are also blocked automatically. Because the list of blocked file types is maintained by file extension, all files that use a file extension on the list cannot be uploaded or downloaded, regardless of the file’s intended use.

The list of file extensions is controlled for the entire server or server farm and is recorded in the configuration database. Additional file extensions can be blocked (up to 1024 file types) by adding them to the list.

One thing to keep in mind is that when the list of file extensions is changed, the change affects both new files being added to a website and files already posted to a website. Users will be able to rename or delete a file with a blocked file extension but will not be able to perform any other actions.

Even though this option appears in the Security Configuration section, it is important to realize that technically this is just a file-extension checking mechanism. For example, if the .mp3 file type is blocked and the user renames the file as .mpz, the portal site will not block the uploaded file.

Configure Antivirus Settings

When you install an antivirus scanner that is compatible with SharePoint Portal Server 2003, you can enable the antivirus protection feature for all servers for the portal site on the Configure Antivirus Settings page. In a server farm deployment, you will have to install antivirus software on every front-end Web server in the server farm.

Remember that having such antivirus software installed on your front-end servers will affect their performance and scalability. You will have to configure your servers with additional processing power to compensate for the additional overhead.

Component Configuration

The Component Configuration links are used to manage search settings, configure Single Sign-On, manage shared services, and to configure usage analysis, HTML viewer settings, and diagnostic settings. If you have installed the optional backward-compatible document library component (for compatibility with SharePoint Portal Server 2001), you can also configure document libraries (Web Storage System–based) from here. All the links in this section found on the SharePoint Portal Server Central Administration page are shown in Figure 17-5.

Figure 17-5.The Component Configuration section on the SharePoint Portal Server Central Administration page

Manage the Search Service

This link leads to a page that allows the administrator to manage how and when the index servers crawl content, to specify where the index servers store temporary files, and to specify other Search Service–related settings. Refer to Chapter 21, “The Architecture of the Gatherer,” and Chapter 22, “Managing External Content in Microsoft Office SharePoint Portal Server 2003,” for details about the index and search services. Chapter 18 will also cover these links in the context of ongoing management tasks relating to the search services.

Manage Settings for Single Sign-On

As stated earlier, Single Sign-On is a feature relating to integration with enterprise-level third-party applications. For more information see Chapter 26, “Single Sign-On in SharePoint Portal Server 2003.”

Configure HTML Viewer

Included with Windows SharePoint Services is the ability to connect to an HTML Viewer server. An HTML Viewer server provides support for users who want to view the content of files on the Windows SharePoint Services website but do not have Microsoft Office Word, Excel, or PowerPoint from Microsoft Office 97 (or a later release of Office) installed on their local computers. Even users who have only a Web browser (Microsoft Internet Explorer or Netscape Navigator) can view content by having the native Office file format converted to HTML on the fly. Although a slight delay occurs while the transformation takes place, the converted file is extremely close to the WYSIWYG formatting of the original. In addition to the process of transforming files on the fly for end users, administrators can use a batch process mode to convert the contents of entire folders to HTML ahead of time and give users better response when requesting those documents.

By default, the HTML Viewer server supports only the following document types: .doc, .xls, .ppt, and .pps.

Transformation of a supported document can take from 1 to 30 seconds, depending on the complexity and size of the document as well as the speed and available resources of the dedicated computer. To provide for this ability and assure a fast response time, you should dedicate a separate computer to this service.

To install the service, find the htmlview.exe file in the Microsoft Office 2003 Resource Kit and extract it on a server that will handle the conversion process. Using the required instructions found with the HTML Viewer files, you will have to install Microsoft Office 2003 along with the HTML Viewer on the chosen server.

Installing Office for the HTML Viewer

To create an Office HTML Viewer server, you must install a customized version of Office 2003 to the dedicated Office HTML Viewer server. Before creating this installation, find the ENG11PROBYPASS.MST and HTMLTRBACKEND.MSI files from the package that included this document. Copy these two files (ENG11PROBYPASS.MST and HTMLTRBACKEND.MSI) to the local computer and folder where the setup.exe for Office 2003 will be run.

Office 2003 must be installed in order to create an Office HTML Viewer server. From the command prompt of the workstation, enter the following command line from the folder where the ENG11PROBYPASS.MST file is stored:

setup TRANSFORMS=ENG11PROBYPASS.MST

Or you can add the path to the file using the TRANSFORMS property, as shown in the following example:

setup TRANSFORMS="<path>\ENG11PROBYPASS.MST"

You can also add further customizations, but they are not needed and, in fact, might conflict with settings in the ENG11PROBYPASS.MST file.

You should accept the default install location for Office (C:\Program Files\Microsoft Office\).

  You should not use Office 2003 from the console on the Office HTML Viewer server. It is only for use by the HTML Viewer server. The customizations to Office on the server provide for a specialized installation. Use of Office from the console could slow down the server. Also, if an HTML viewing action takes place while Office is in use for other purposes, it would dramatically affect the responsiveness of all other applications or services on the server.

  The specialized installation of Office on the Office HTML Viewer server is provided to help mitigate any possible security threats by reducing the exposure of Office access points to external users. The configuration of Office used for the Office HTML Viewer sets macro security to High. Setting macro security to High turns off macro support for executables. Macros embedded in documents or files will not run during the file conversion process. Any documents or files that retrieve data on the fly from remote servers or custom applications will not function. Content within the document or file must be static to be converted. However, VBA projects (source code) in any documents or files will make a roundtrip through the HTML viewing process.

Running the Office HTML Viewer Windows Installer Package

After the Microsoft Office 2003 install process completes, run the Microsoft Office HTML Viewer install package on the Office HTML Viewer server by using the following command line:

HTMLTRBACKEND.MSI

This file is a Windows Installer file that places necessary Office HTML Viewer executables and Office customizations on the computer.

You can also run this file by double-clicking it from within Windows Explorer or referencing it in the Run utility (Start menu, Run option). When it starts, a setup dialog box requesting you to specify where to install files appears. You should accept the default install location. If the HTMLTRBACKEND.MSI file does not start, it is likely that MSIEXEC.EXE is not installed on the computer or it is not the most recent version. The latest version of MSIEXEC.EXE is available from the www.microsoft.com website.

When the HTMLTRBACKEND.MSI file finishes, the installation and customization process of Office 2003 is also complete. It is now necessary to instruct Windows SharePoint Services where to find the Office HTML Viewer server.

After installing the HTML Viewer service on a host, the administrator can configure the portal site to use the viewer by navigating to its configuration page from the SharePoint Portal Central Administration page depicted on Figure 17-6.

Keep in mind that the resource requirements for this service are very high and can severely affect the performance of any server not dedicated to this task. It is therefore recommended to dedicate a server to host this service. The steps and parameter settings are explained next.

Figure 17-6.The HTML Viewer Configuration page

To configure Windows SharePoint Services

1. In the Path to HTML Viewer Server box, type the full URL to the server hosting HTML viewing.

2. In the Maximum Cache Size box, type the maximum size to allow for the HTML viewing cache.

3. In the Maximum File Size box, type the maximum file size to view.

4. In the Timeout Length box, type the length of time to wait before ending an HTML Viewer process.

5. Click OK.

Configure Diagnostic Settings

This link leads to a page that allows the administrator to change logging settings for the various services and processes, view and manage her diagnostic logs, and configure automatic reporting settings for certain types of events.

Logging Settings

The Logging Settings section on the Configure Diagnostic Settings page shows a list of components that run on the various portal servers, allowing each to have its logging settings modified. The components that allow their logging levels to be modified are as follows:

• WWW Worker Process

• Notification Service

• Single Sign-On Service

• Administrative Service

• Search Service

• Search Filter Process

• Backup – Restore

• Audience Job

• Third Party Applications

For each component, you can edit the logging level as follows:

• Do not log event for this component

• Log critical events only

• Log informational events and critical events

• Log tracing information

    You should select Log Tracing Information only for troubleshooting purposes. Logging tracing information might affect performance and disk use.

You can also choose to save a copy of the log automatically after a specified number of days, and you can choose to delete logs automatically after a specified number of days to save disk space.

View Diagnostic Logs

This section allows for viewing and deleting the log files created by the components defined in the Logging Settings section just described.

To view and delete diagnostic logs

1. On the SharePoint Portal Server Central Administration For server_name page, in the Component Configuration section, click Configure diagnostic settings.

2. On the Configure Diagnostic Settings For server_name page, in the View Diagnostic Logs section, in the Diagnostic logs list, select a diagnostic log, and then do one of the following:

   1. To view the selected log, click View Log.

   2. To delete the selected log, click Delete. You cannot delete a log file that is in use.

   3. To delete unused log files, click Delete Unused Log Files.

Automatic Error Reporting

SharePoint Portal Server 2003 can be configured to automatically send reports to Microsoft of errors that cause it to crash. Automatic error reporting uses a connection that uses the HTTP over SSL (https) protocol, which is more secure than an ordinary Internet connection. The data that Microsoft collects is used strictly for the purpose of tracking down and solving problems that users are experiencing. The information is stored in a secure database with limited access.

You can view the Microsoft Error Reporting Data Collection Policy from a link in the Automatic Error Reporting section. There is a link to this page on the SharePoint Portal Server Central Administration For Server server_name page.

The procedure to configure automatic error reporting for this server involves configuring the Error Reporting settings from Local Computer Policy in Microsoft Management Console. You must be logged on to the computer as a member of the local Administrators group to complete this procedure.

To configure automatic error reporting

1. On the taskbar, click Start, and then click Run.

2. Type gpedit.msc and then click OK.

3. In Group Policy Object Editor, under the Local Computer Policy node, expand the Computer Configuration node.

4. Right-click Administrative Templates, and then click Add/Remove Templates.

5. In the Add/Remove Templates dialog box, click Add.

6. Select AER_LanguageID.ADM, and then click Open. For example, for English, you would select AER_1033.ADM. For more information about language IDs, see “Regional and Language Settings” in the SharePoint Portal Administrator’s Guide.

7. Click Close to close the Add/Remove Templates dialog box.

8. Under the Computer Configuration node, expand the Administrative Templates node.

9. Expand the Application Error Reporting node.

10. Click the Queued Reporting node.

11. In the details pane, right-click Bypass queue and send all reports, and then click Properties.

12. On the Properties page, on the Setting tab, click Enabled.

13. Click OK.

14. Close Group Policy Object Editor.

Portal Site and Virtual Server Configuration

At this point, we have configured almost all the core service features for the portal servers in the farm. We are now ready to discuss the configuration options and procedures relating to the creation of portal sites. The links in the Portal Site And Virtual Server Configuration section are used to extend and configure virtual servers required to host portal sites and team sites, create and manage portal sites, and configure portal site information such as external access settings and quota configurations.

Because all websites including portal sites need to be serviced through a virtual server preconfigured in IIS, we will begin our discussion there and end with the actual portal site creation procedure. Figure 17-7 depicts the links of the Portal Site And Virtual Server Configuration section we will be discussing.

Figure 17-7.The Portal Site And Virtual Server Configuration section on the SharePoint Portal Server Central Administration page

Extending Portal Virtual Servers

As with Windows SharePoint Services, for a virtual server to provide front-end Web services for sites, it must be extended. Extending a virtual server associates the appropriate application pool, installs the Windows SharePoint ISAPI filter to the virtual server, and creates the appropriate files in the virtual server’s folder.

However, in the portal site scenario, you do not have to extend the virtual server before creating your portal sites. This is different from Windows SharePoint Services, which requires that this step be performed before any sites can be created. The portal site creation process auto-extends the virtual server as part of the process. That said, you might be wondering why the Extend An Existing Virtual Server From The Virtual Server List Page option even exists on the SharePoint Portal Server Central Administration page. It is there to configure front-end Web servers that are added to the farm after the portal site has been created. Read the “Creating Portal Sites” section at the end of this chapter for details on how to extend virtual servers in a multiportal farm.

Once you have extended a virtual server, it will appear on the Virtual Server List page that appears when you click Configure Virtual Server Settings from the Virtual Server List page. Selecting a virtual server on that page brings you to the Virtual Server Settings page depicted in Figure 17-8, which will allow you to configure that server. We now will examine the various configuration options the Virtual Server Settings page provides. Keep in mind that any settings that contradict similar settings that you have defined at the portal site level will be superseded by the virtual server’s settings.

Figure 17-8.The Windows SharePoint Services Virtual Server Settings page

Configure Self-Service Site Creation

You might want to give your user community the ability to create new sites for themselves on the fly by enabling Self-Service Site Creation. If this feature is enabled, any user can create new top-level websites without an approval process.

Careful consideration must be given before turning this feature on, as you are potentially relinquishing control over the propagation of sites and site content in your organization. If you turn it on and don’t check its usage, you might find yourself with a portal site filled with unused sites created at the user community’s whim. To address this issue, a “dead-web cleanup” feature is provided that is described in the next section.

Configure Site Collection Use Confirmation and Deletion

To help mitigate the loss of disk and database space as a result of unused site collections, this option allows the administrator to set time limits that define how long to wait to delete unused site collections. There are also parameters that allow the administrator to define how many times to e-mail the owners of these unused sites to warn them of the deletion. If activity on the site is detected or if the owner of the site responds to the e-mailed warning, the site will not be deleted. Keep in mind that this feature will work only if the usage analysis processing is turned on at the portal site level.

Security Settings

This area of the SharePoint Portal Central Administration page, depicted previously in Figure 17-8, is used to configure the list of available rights for any sites hosted by a particular server, as well as how to handle Web Part Pages. Details follow for each of the two links.

Manage User Rights for the Virtual Server

This link is also referred to as the Virtual Rights Mask. It is used if you want to make sure that certain rights are not available to anyone using any of the site collections hosted by the virtual server, regardless of site group membership. You can disable those rights by deselecting the rights you want to block.

A situation in which you’d use this setting is when you want to ensure that users cannot change the themes to their sites. You can disable the Apply Themes right at the virtual server level so that users must use the default theme of the site template when any site or workspace is created.

Manage Security Settings for Web Part Pages

Web Parts are the main programming mechanism through which the portal site Web pages provide their functionality. A Web Part has server-side code, client-side code, or both that eventually translates to user-viewable rendered HTML. The code behind these Web Parts can pass parameter values and other data to other Web Parts that have been written by the programmer to receive that data. Web Parts that have been written with this kind of functionality are called “Connected” Web Parts because they use the Web Part Connections programming feature.

Connected Web Parts pass data to each other, and therefore might expose that data and violate existing security policy constraints. Also, these kinds of Web Parts tend to have more code running either at the client or server to support the connections. As an administrator, you can turn off Web Part Connection support at the virtual server level to improve security or to improve the performance of the server.

The other configuration you might want to set on this page pertains to whether or not you want to have your user community see Web Parts that have been published on the Microsoft website. The feature is turned on by default, but if it’s disabled, it will cause the site pages to show only the default Web Parts created at install time as well as those posted by the administrator.

Virtual Server Management

Because Microsoft SharePoint Portal 2003 is based on Windows SharePoint Services, which in turn handles all Web requests through an ISAPI filter in IIS, it follows that some virtual server configuration tasks are required. The settings for these tasks are available via the Virtual Server Management section of the Virtual Server Settings page depicted in Figure 17-9. Refer to Chapter 15, “Configuring Windows SharePoint Services,” for details about most of the settings found here. The most important link in this section is the Define Managed Paths link, which will be described next.

Figure 17-9.The Virtual Server Management section on the Virtual Server Settings page

Define Managed Paths

When client URL requests come in to the server on the listening port (usually port 80) defined on any virtual server that has been extended with Windows SharePoint Services, the Windows SharePoint Services ISAPI filter first looks at the URL to determine whether the path requested is to be serviced by Windows SharePoint Services. The filter makes that determination by comparing the requested path to the Managed Path list. By default, all paths under the virtual server’s home folder are implicitly included.

However, an administrator might want the same virtual server that serves the portal site to also serve other subwebs that are not part of Windows SharePoint Services. For example, the administrator might want the path /tsweb, which represents a Web interface to terminal services, to be excluded from any portal Windows SharePoint Services processing. This is accomplished on this page by explicitly excluding the path.

On this page, it is also possible to append additional managed paths. For example, the default path intended for team site hosting, created at install time, is the /sites URL. If another path is preferred, such as /dept or /team, simply add the paths using the Add A New Path section of the page. Then, when a team site is created, the administrator will be able to select these additional paths as alternate creation paths for the new team site.

Create Top-Level Website

The virtual server hosting a portal site can also host team sites. This is accomplished by creating site collections, also known as top-level websites. When creating a site collection, the administrator will need to provide the desired URL path, a Site Collection Owner, Secondary Owner, Quota Template, and a Site Language.

The */*sites URL is the default URL path created at installation of the portal site intended for team sites. If additional paths were added on the Define Managed Paths page, the administrator will see them in the URL Path drop-down combo box.

Delete Site Collection

When you specify the URL for the top-level website that the administrator wants to delete and click OK, that site and all subsites along with their content will be deleted.

Configure Data Retrieval Settings

Windows SharePoint Services makes use of data retrieval services for working with data in SharePoint lists, OLEDB, and XML data sources. For example, client applications and data-bound Web Parts, such as the Spreadsheet Web Part, use data retrieval and provider services to query the data source supported by the particular data source. Keep in mind that while the Web Parts provided with Windows SharePoint Services have predefined retrieval services, developers can create Web Parts that define their own custom database connections.

Each extended virtual server has such a set of data retrieval services installed and configured to handle client requests. This page allows the administrator to temporarily disable the service in troubleshooting scenarios, limit the KB size of data returned to clients so as to limit server and network loads, and set the time-out if the data source does not respond within the specified duration.

Configure Site Quotas and Locks

The only way to control the use of space in your content databases is to assign quota limits to the team sites that will be using that space. This is accomplished by clicking Configure Site Quotas And Locks from the Virtual Server List page in the Portal Site And Virtual Server Configuration section on the SharePoint Portal Server Central Administration page, defining quota templates, and then assigning quota templates as defaults for all site collections defined on the virtual server.

Any number of templates can be defined, each with its own storable limit values. There are two sets of values, one is the maximum space allowed for the site to occupy, and the second is the amount of space at which the owner of the site will be notified via e-mail that the limit is being approached.

Configure Alternate Portal Site URLs

Administrators often deploy portal sites that users can access by using different URLs. In these scenarios, it is 4important that functionality, such as search results for portal site and document library (Web Storage System–based) content, be appropriate for the URL that was used to access the portal site. External URLs must be provided to the user in a form that is appropriate for how the user is currently accessing the portal site. For example, let us assume that internal users are given *https://woodgrove/*as the base URL for accessing the portal site and its subsites. Let’s also assume that the portal is also accessible to external users who use https://www.woodgrove.com as the base URL. When users utilize the search feature, they expect links in the result set to work. The only way for this to happen is to tell the portal site to provide the appropriate alternate URL based on where the request came from.

Without alternate access settings, search results might be displayed in a way that would make them inaccessible to users. Users might receive search results that they cannot access whenever they access the portal site by using a URL that is different from the original URL used for crawling the content.

To define URL alternate access settings, the administrator will need to navigate to the Configure Alternate Portal Access Settings page available via Configure Alternate Portal Site URLs For Intranet, Extranet, And Custom Access on the Central Portal Administration page. Figure 17-10 shows this page with one entry for the Woodgrove portal site that has an External Extranet URL of https://www.woodgrove.com and a Custom URL of https://portal. This means that intranet users can use either the current default https://woodgrove URL or the custom https://portal URL, while external users will have to use https://www.woodgrove.com.

Figure 17-10.Alternate access URLs for a portal

  Remember that there must be name resolution, such as DNS, that will return the IP address of the portal site to requesting users.

  This feature does not require the definition of custom http headers in IIS. However, if custom http headers are defined in IIS, you must remember to match them up to the alternate access URLs. Otherwise, those alternate URLs will not be serviced by IIS.

The Microsoft SharePoint Portal Server Search (SharePointPSSearch) service consults the alternate access setting entries when crawling a document. If the URL of the document matches one of the mapping entry URLs, the URL is replaced with the mapping ID for the entry. When the search result is displayed, the mapping ID is replaced by the appropriate URL if the user is requesting the document from an access point listed in the alternate access setting entries. If there is no appropriate alternate mapping, the search results display the default URL. Figures 17-11 and 17-12 show the same search results for a query. Note the status bar at the bottom of each, which shows that the appropriate alternate address URL has been placed for the link.

Figure 17-11.Search results display with appropriate links for the extranet users

Figure 17-12.Search results display with appropriate links for the intranet users using the custom URL

When defining alternate access, every entry must have a default URL. Each entry can have additional alternate access methods for either intranet, extranet, or custom access. Each URL must be different from all other URLs. These mappings are stored in the configuration database. SharePoint Portal Server 2003 uses the default URL for any requested URL that is not found in the mapping table. Also, you cannot delete entries for virtual servers that currently host portal sites or document libraries.

  If an entry has been deleted but URLs for that mapping ID still exist in the index, those results will be displayed with a message stating that the content is not currently accessible. The server farm administrator will have to update the content index in order to update the URLs.

Creating Additional Application Pools

Windows SharePoint Services allows you to create application pools and associate them with separate virtual servers. By creating new application pools and assigning websites and applications to them, you can isolate portal sites and help enhance security between them while maintaining the availability of your other applications. Figure 17-13 shows how an additional application pool is created from within the IIS administration tool.

Figure 17-13.Creating an additional application pool

An application pool is a configuration in IIS that links one or more applications to a set of one or more worker processes. Because worker process boundaries separate applications in an application pool from other applications, problems caused by applications in one application pool do not affect applications in another application pool. For example:

• If one application pool identity is compromised and SharePoint Portal Server 2003 uses only one application pool, the administrator must disable all portal sites on the server. However, if the server farm administrator creates an application pool for each portal site and uses different application pool identities, the compromise of one application pool identity affects only one portal site, not all portal sites. Companies that provide SharePoint Portal Server services to other parties might want to create additional application pools, with separate application pool identities, to help enhance security and service continuity.

    When you create separate application pools, you can no longer manage the credentials by using the Configure Server Farm Account Settings page. Specifying the application pool identity of the portal site on this page applies only to MSSharePointPortalAppPool. You must use IIS Manager to manage any new application pools.

• IIS shuts down an application pool if its processes falter several times. If all portal sites share an application pool and IIS shuts down that application pool, none of the sites will be operational. Therefore, using multiple application pools helps improve and ensure reliability. The server farm administrator might want to create one application pool for the parent portal site and another application pool for all the child portal sites to enhance reliability of the sites. Both application pools could use the same application pool identity.

• If the server farm hosts more than 50 portal sites, it is required that additional application pools be created so that no single application pool has more than 50 portal sites sharing it. All application pools could use the same application pool identity. The limit is because, by default, IIS will recycle an application pool that grows beyond a certain memory limit. Splitting the application pools allows IIS to be more efficient about memory usage.

    Having multiple application pools increases memory usage. Each portal site with its own application pool uses approximately 150 megabytes (MB) of memory. When portal sites share an application pool, the first portal site uses approximately 150 MB, and each additional portal site uses 15 MB to 30 MB.

By default, SharePoint Portal Server 2003 creates a single application pool, named MSSharePointPortalAppPool, that hosts all virtual servers on which portal sites are created. Although this default setting is sufficient for many customers, others might want to move the virtual servers into separate application pools. For example, moving the virtual servers into separate application pools could be a requirement for customers who provide hosting services to different clients by using the same SharePoint Portal Server 2003 server farm. You can separate portal sites into different security contexts by specifying unique identities for each application pool.

  Each portal site still has the db_owner database role on the configuration database and can affect other portal sites in the server farm by writing to the configuration database.

Remember and be careful to switch all components of the Web server to the new application pool, including the virtual directories (for example, _vti_bin, _layouts, and so on). If this is not done, the portal site will become inaccessible. Also, do not forget to assign the appropriate user account to the application pool. Figure 17-14 shows the Identity tab of the properties page for an application pool where this is done.

Figure 17-14.Creating an additional application pool

Creating Portal Sites

It is important to realize that more than one portal site can be hosted by a Microsoft SharePoint Portal 2003 server. This section will describe the overall steps required to create additional portal sites beyond the first one in a multi-front-end server farm.

From what we’ve learned so far, we know that for each portal site we need an additional virtual server to be created in IIS. We also know that even though we do not extend portal virtual servers directly, the portal site creation process, displayed in Figure 17-15, extends them for us. Extending a virtual server involves associating the Windows SharePoint Services ISAPI filter to it, as well as entering folder references for Managed path exclusions or inclusions.

Figure 17-15.Creating a portal site

So you might be wondering why the Extend A Virtual Server link exists in the first place. Its purpose is to give administrators something to use on additional front-end servers once the portal sites have been created. The idea is to go to each front-end Web server’s Central Administration page and extend the virtual server that will host a given portal site. On the Extend Virtual Server page, instead of creating a content database for it, you will map the virtual server to the original virtual server on which the portal site was created.

Summary

This chapter has shown that Microsoft SharePoint Portal Server 2003 provides a complete set of configuration tools that allow the administrator to define all the operational settings for the myriad servers and services that play various roles in the portal site. We also saw that some configuration tasks need to be performed from a command line by using the stsadmin.exe tool. Furthermore, the Web-based SharePoint Portal Central Administration page provides a single place for the administrator to do these configuration tasks from any browser-capable workstation. From there, the administrator can configure all servers at once or configure each server on a case-by-case basis.

The next chapter will continue our discussion of Microsoft SharePoint Portal Server 2003 from the perspective of ongoing administration of the portal sites themselves.