Newly published content for Search Server 2008
DropDown image

Updated: 2009-11-30

In this article:

  • Updated the week of November 30, 2009

  • Updated the week of October 19, 2009

  • Updated the week of August 17, 2009

  • Published the week of August 10, 2009

  • Updated the week of August 10, 2009

  • Published the week of July 27, 2009

  • Published the week of July 20, 2009

  • Updated the week of July 20, 2009

  • Updated the week of July 13, 2009

  • Published the week of June 29, 2009

  • Updated the week of June 22, 2009

  • Updated the week of June 8, 2009

  • Published the week of June 1, 2009

RSS feed This list is also available in an RSS feed (http://services.social.microsoft.com/feeds/feed/SearchServerNewContent).

Updated the week of November 30, 2009

Microsoft Search Server 2008 Technical Library in Compiled Help format (http://www.microsoft.com/downloads/details.aspx?FamilyID=6cf0f7b6-c0a7-48f8-977e-9bc76b97ff98&DisplayLang=en) The entire library for Microsoft Search Server 2008 is now available as a downloadable .chm file. This download includes all content in the library as of November 30, 2009.

Updated the week of October 19, 2009

Configure Search Server to crawl Lotus Notes (Search Server 2008) and Prepare to crawl Lotus Notes (Search Server 2008) These articles have been updated with a table containing updated Lotus Notes Client and Domino Server versions.

Updated the week of August 17, 2009

Move content databases between instances of SQL Server (Search Server 2008) This article has been updated with a note explaining that if you have installed a software update that includes the Infrastructure Update, you must not run the Stsadm preparetomove operation.

Published the week of August 10, 2009

Plan server farm security (Search Server 2008) This group of articles describes how to plan security hardening for server roles, plan for secure communication, and plan security hardening for an extranet. The articles include topology design checklists.

Choose the security environment (Search Server 2008) The security guidance that is recommended for your organization depends on the environment. This article describes the following three security environments: internal team or department; external secure access; external anonymous access.

Plan environment-specific security (Search Server 2008) This group of articles gives environment-specific security guidance that you can follow in addition to the security guidance given in "Plan server farm security". The articles cover the following Microsoft Search Server 2008 environments: internal team or department; external secure search; external anonymous access.

Plan for security roles (Search Server 2008) This article describes the two-tier administration model in Search Server 2008 and the roles within each tier that you can use to help administer your solution.

Plan secure configurations for Search Server 2008 features This article tabulates recommendations that can help you to manage Search Server 2008 features more securely.

Updated the week of August 10, 2009

Use crawl rules to determine what content gets crawled (Search Server 2008) This article has been updated with information about how to use a global exclusion crawl rule, which applies regardless of the order in which it is listed.

Published the week of July 27, 2009

Best practices for search performance (Search Server 2008) This article describes best practices that you can use to maintain a healthy and efficient search system. Topics include what to monitor, how to diagnose query bottlenecks, how to optimize SQL Server, and how to avoid bottlenecks caused by access control lists.

Published the week of July 20, 2009

Configure Web Part properties (Search Server 2008) This article describes how to configure properties that are common across search Web Parts.

Configure properties for the Search High Confidence Results Web Part (Search Server 2008) This article describes how you can use the Search High Confidence Results Web Part to display the results of many types of automatic searches.

Configure properties for the Search Box Web Part (Search Server 2008) This article describes how you can edit the properties of the Search Box Web Part to change how the Web Part appears and responds to users.

Configure properties for the Search Core Results Web Part (Search Server 2008) This article describes how to configure the Search Core Results Web Part to control how search results are displayed and to return the most relevant results based on keywords and property filters.

Updated the week of July 20, 2009

Helping users make successful queries (Search Server 2008) This article has been updated with information about how to configure properties for search Web Parts and how to use two new Stsadm operations for results highlighting.

Deploy language packs (Search Server 2008) This article has been updated to clarify procedures for deploying language packs.

Updated the week of July 13, 2009

White paper: Backing up Search Server 2008 by using System Center Data Protection Manager This white paper has been updated to reflect updates to System Center Data Protection Manager Service Pack 1. As of Service Pack 1, Data Protection Manager supports backing up and restoring indexes without additional scripting.

Published the week of June 29, 2009

Using wildcard characters in property searches (Search Server 2008) This article provides information that can help users make successful queries.

Updated the week of June 22, 2009

Back up a farm by using the Stsadm command-line tool (Search Server 2008) This updated article contains a minor correction to Stsadm syntax.

Updated the week of June 8, 2009

Move all databases (Search Server 2008) The syntax in this article has been corrected.

Published the week of June 1, 2009

Change the content index location for a query server (Search Server 2008) This article describes how to change the location of the content index that is saved to the file system of a query server.

Configure all Web servers as query servers (Search Server 2008) This article describes how to add the query server role to existing Web servers in a Search Server 2008 deployment.


Getting started with Search Server 2008
See Also
DropDown image

Updated: 2008-03-03

Use the links below to get started with Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

  • To plan how to install and deploy Search Server 2008, see the topics in Planning and architecture for Search Server 2008.

  • For information about supported and unsupported upgrade paths, see Upgrade paths (Search Server 2008).

  • To install Search Server 2008, see the topics in Deployment for Search Server 2008.

  • To learn how to quickly set up the server and start crawling content after Search Server 2008 is installed, see How to crawl content (Search Server 2008).

  • To find articles about how to crawl content, install protocol handlers and IFilters, work with federation, and manage Search Server 2008 on a daily and weekly basis, see Operations for Search Server 2008.

  • For information about security, see Security and protection for Search Server 2008.

  • To learn how to backup and restore the index, see Protecting and restoring the farm (Search Server 2008).

See Also

Concepts

Determine hardware and software requirements (Search Server 2008)

Other Resources

Microsoft Search Server 2008 Known Issues
Microsoft Enterprise Search


Planning and architecture for Search Server 2008
DropDown image

Updated: 2008-07-31

This topic provides links to topics that help you plan to install, deploy, and manage Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this section:

  • Determine hardware and software requirements (Search Server 2008) — This topic provides information about the minimum and recommended hardware and software requirements of Basic and Advanced installation of Search Server 2008.

  • Plan to deploy Search Server 2008 or Search Server 2008 Express — This article provides information about planning considerations for installing and configuring Search Server 2008 or Microsoft Search Server 2008 Express.

  • Plan for administrative and service accounts (Search Server 2008) — Learn about the different server administrator roles and the account requirements for setting up and running Search Server 2008.

  • Plan to crawl content (Search Server 2008) — This topic introduces concepts about what it means to crawl content, how content is crawled, and best practices for set up crawling.

  • Plan the end-user search experience (Search Server 2008) — See how to create a search experience for users to quickly find the information that they want.

  • Plan for redundancy (Search Server 2008) — This article describes the options for scaling out redundant server roles included in a Search Server 2008 farm. After reading this article, you will be able to determine and record the redundancy options that are appropriate for the environment.

  • Plan for availability (Search Server 2008) — This article describes availability in general, costs and challenges for availability in a SharePoint Products and Technologies environment, and strategies and solutions that you can use to improve availability in the environment.


Determine hardware and software requirements (Search Server 2008)
DropDown image

Updated: 2009-05-21

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

A Microsoft Search Server 2008 or Microsoft Search Server 2008 Express configuration can range from a Basic installation (a stand-alone deployment on a single server) to an Advanced installation that uses multiple servers. This article describes minimum and recommended hardware and software requirements for the Basic and Advanced installation options. The hardware and software requirements described in this article apply to both x86 (32-bit-based) and x64 (64-bit-based) systems. Search Server does not support Itanium-based systems.

Note Note:

Beyond the minimum requirements described in this article, your hardware needs depend on your planning for availability, capacity, and performance. This article does not provide guidance on designing a farm topology or selecting hardware based on extended architectural requirements. For information about designing a solution to meet your requirements, see Planning and architecture for Search Server 2008.

In this article:

  • Software requirements

  • Basic installation (single-server deployment) requirements

  • Advanced installation (multiple-server deployment) requirements

Software requirements

This section describes the following software requirements:

  • Operating system and Windows component requirements

  • Levels of browser support

Operating system and Windows component requirements

We recommend that you install Search Server on a computer that has a new installation of either of the following:

  • Any of the following Windows Server 2003 operating systems (32-bit or 64-bit versions) with the most recent service packs or their R2 counterparts:

    • Windows Server 2003 Standard Edition operating system

    • Windows Server 2003 Enterprise Edition operating system

    • Windows Server 2003 Datacenter Edition operating system

    • Windows Server 2003 Web Edition operating system

Any of the following Windows Server 2008 operating systems (32-bit or 64-bit versions) with the most recent service packs:

  • Windows Server 2008 Standard operating system

  • Windows Server 2008 Enterprise operating system

  • Windows Server 2008 Datacenter operating system

  • Windows Web Server 2008 operating system

When you run the Search Server Preparation Tool from the installation Start screen, the tool downloads, installs, and enables the following elements as necessary and appropriate to satisfy Search Server requirements:

  • Windows Server 2003 SP1 (Windows Server 2003 operating systems only)

  • Either of the following:

    • Windows Workflow Foundation Runtime Components and Microsoft .NET Framework 2.0

    • Microsoft .NET Framework 3.0

  • Application server role (IIS, ASP.NET)

  • IIS, ASP.NET Web service extensions

Levels of browser support

Web browser support is divided into two levels: level 1 and level 2. Although administrative tasks on SharePoint sites are optimized for level 1 browsers, Search Server 2008 also provides support for other browsers that are commonly used. To ensure that you have complete access to all the functionality, we recommend that you use a level 1 browser for administrative tasks.

Level 1 Web browsers

Level 1 Web browsers take advantage of advanced features provided by ActiveX controls and provide the most complete user experience. Level 1 browsers offer full functionality on all SharePoint sites, including the SharePoint Central Administration Web site.

Level 1 Web browsers for Search Server 2008 with Service Pack 2 (SP2) are as follows:

  • Windows Internet Explorer 7.x (32-bit)

  • Windows Internet Explorer 8.x (32-bit) (includes running in compatibility mode)

  • Internet Explorer 6.x (32-bit)

Level 1 Web browsers for Search Server 2008 are as follows:

  • Internet Explorer 6.x (32-bit)

  • Internet Explorer 7.x (32-bit)

Note Note:

Level 1 browser support is only available for computers that are running the Windows operating system.

Level 2 Web browsers

Level 2 Web browsers provide basic functionality so that users can both read and write in SharePoint sites and perform site administration. However, ActiveX controls are supported only in level 1 browsers. In addition, there are functionality differences between different browsers. As a result, there might be a user experience that is different from that in level 1 browsers.

Level 2 Web browsers for Search Server 2008 with SP2 are listed in the following table.

Browser | Windows | Linux/Unix | Macintosh OSX Leopard
Internet Explorer 7.x (64-bit) | X |  |
Internet Explorer 8.x (64-bit) | X |  |
Firefox 3.x |  | X | X
Safari 3.x |  |  | X

If a browser is not listed in either level 1 or level 2, it is not supported. For example, older browsers — such as Internet Explorer 5.01, Internet Explorer 5.5x, Internet Explorer 6.x, Internet Explorer for Macintosh, and versions of third-party Web browsers that are earlier than the ones listed as level 2 browsers — are not supported.

Basic installation (single-server deployment) requirements

You use the Search Server Basic installation option to create a stand-alone configuration on a single computer. A Basic installation automatically installs and uses Microsoft SQL Server 2005 Express Edition for data storage.

Hardware requirements (Basic installation)

The following table shows minimum and recommended hardware requirements for deploying Search Server and SQL Server 2005 Express Edition in a Basic (single server) installation.

Component | Minimum | Recommended
Processor | 2.5 gigahertz (GHz) | Dual processors that are each 3 GHz or faster
RAM | 2 gigabytes (GB) | 4 GB
Disk | NTFS file system-formatted partition with a minimum of 3 GB of free space | NTFS file system-formatted partition with 3 GB of free space, plus adequate free space for your SharePoint sites
Network connections: Client to server | 56 kilobits per second (Kbps) | 56 kilobits per second (Kbps)
Drive | DVD drive, or a local or network-accessible drive to which you can copy the entire contents of the Search Server installation CD | DVD drive, or a local or network-accessible drive to which you can copy the entire contents of the Search Server installation CD
Display monitor | 1024 × 768 or higher resolution | 1024 × 768 or higher resolution

Database requirements (Basic installation)

If you are using Windows Server 2003 Web Edition in a single-server environment, you can install Search Server using the Basic (stand-alone) installation option only. This is because an Advanced installation requires an existing SQL Server database, but SQL Server cannot be installed on Windows Server 2003 Web Edition due to Windows licensing restrictions.

Advanced installation (multiple-server deployment) requirements

The primary difference between single-server and multiple-server deployments is that in the latter case you can use one or more computers to host each of the following server roles:

  • Application server

  • Web front-end server

  • Database server

This section describes minimum and recommended system requirements for a computer that hosts the application server role and Web front-end server role side by side. If you install more than one role on a single computer, ensure that the computer meets the minimum requirements for each installed role.

Note Note:

Search Server 2008 Express can be installed in a configuration that contains no more than one application server. (The application server role is used for serving search queries and crawling content.) There is no limit to the number of Web front-end servers that can be used with a Search Server 2008 Express application server.

Application server hardware requirements (Advanced installation)

The following table shows minimum and recommended hardware requirements for deploying a Search Server application server.

Component | Minimum | Recommended
Processor | 2.5 GHz | Dual processors that are each 3 GHz or faster
RAM | 2 GB | 4 GB for application server and SQL Server host computers
Disk | NTFS-formatted partition with 3 GB of free space | NTFS-formatted partition with 3 GB of free space, plus adequate free space for data storage
Network connections: Client to server | 56 Kbps | 56 Kbps or faster
Network connections: Server to server | 100 megabits per second (Mbps) | 1 gigabit per second
Drive | DVD drive, or a local or network-accessible drive to which you can copy the entire contents of the Search Server installation CD | DVD drive, or a local or network-accessible drive to which you can copy the entire contents of the Search Server installation CD
Display monitor | 1024 × 768 or higher resolution | 1024 × 768 or higher resolution

Web front-end server hardware requirements (Advanced installation)

The following table shows minimum and recommended hardware requirements for deploying a Search Server Web front-end server.

Component Minimum Recommended

Processor

2.5 GHz

Dual processors that are each 3 GHz or faster

RAM

2 GB

More than 2 GB

Disk

NTFS-formatted partition with a minimum of 3 GB of free space

NTFS-formatted partition with 3 GB of free space, plus adequate free space for data storage

Network connections

  • 56 Kbps connection between client computers and server

  • 100 Mbps connection between computers in a server farm

  • 56 Kbps or faster connection between client computers and server

  • 1 gigabit per second connection between computers in a server farm

Drive

DVD drive, or a local or network-accessible drive to which you can copy the entire contents of the Search Server installation CD

DVD drive, or a local or network-accessible drive to which you can copy the entire contents of the Search Server installation CD

Display monitor

1024 × 768 or higher resolution

1024 × 768 or higher resolution

Web front-end server software requirements (Advanced installation)

The role of a Web front-end server is a subset of the application server role; all features on a Web front-end server are available on an application server. Software requirements for the Web front-end server are the same as those for an application server before you add resources to satisfy your capacity demands.

Database server software requirements (Advanced installation)

The database server must have SQL Server 2000 with at least SP3a or Microsoft SQL Server 2005 with at least SP2. Some advanced features require SQL Server 2005 Analysis Services with at least SP2. For information about hardware and software requirements for deploying a database server running SQL Server 2005, see SQL Server 2005 System Requirements.


Plan to deploy Search Server 2008 or Search Server 2008 Express
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This article addresses planning considerations for installing and configuring Microsoft Search Server 2008 or Microsoft Search Server 2008 Express. For more information about Search Server planning, see Planning and architecture for Search Server 2008. For information about known product issues, see Microsoft Search Server 2008 Known Issues.

In this article:

  • Plan for hardware and software requirements

  • Plan your Search Server administration team

  • Determine the kind of deployment you need

  • Topology options

  • Plan for required accounts

  • Prepare the database server

  • Uninstallation considerations

  • Other considerations

Plan for hardware and software requirements

Before you install and configure Search Server, ensure that your servers meet the requirements described in Determine hardware and software requirements (Search Server 2008).

Plan your Search Server administration team

Identify members of your Search Server team and assign administrative roles as appropriate, including site collection administrators for Central Administration, Search Administration, and the Search Center site. Depending on the size of your organization and your requirements for search, some members of your search team might be assigned more than one administrative role, or you might require only one administrator for your entire Search Server deployment. For more information, see Plan for administrative and service accounts (Search Server 2008).

Determine the kind of deployment you need

Before you begin an installation, ensure that you understand the differences between Search Server 2008 and Search Server 2008 Express and the associated installation options. These topics are addressed in the following sections:

  • Understanding server roles in a Search Server deployment

  • Choosing Search Server 2008 or Search Server 2008 Express

  • Choosing Basic or Advanced installation

  • Product comparison summary

Understanding server roles in a Search Server deployment

Depending on your choices during installation, Search Server 2008 or Search Server 2008 Express can install and configure the following Search Server roles on a computer:

  • Application server role A Search Server host computer that is configured as an application server can provide these roles:

    • The index server role, which crawls content and indexes the crawled content.

    • The query server role, which serves search queries.

    For information about separating the index and query server roles on multiple application servers in a Search Server farm, see Topology options later in this article.

  • Web front-end server role A computer configured with the Web front-end (WFE) server role hosts Web sites for end users. These sites accept search query requests from clients and render query results for those clients as Web pages. The WFE server role does not provide search functionality. However, a Search Server computer can host the application server role and WFE server role side by side. A single-server, stand-alone deployment is an example of this kind of configuration.

  • Database server role (Basic installations only) When you install with the Basic installation option, Search Server automatically installs Microsoft SQL Server 2005 Express Edition on the same computer and uses it for data storage. (When you install with the Advanced installation option, Search Server does not install the database server role. Instead, an Advanced installation requires you to specify a SQL Server host.)

Choosing Search Server 2008 or Search Server 2008 Express

This section outlines the main differences and similarities between Search Server 2008 and Search Server 2008 Express deployments.

Differences between Search Server 2008 and Search Server 2008 Express

Search Server 2008 Express has the following distinguishing characteristics:

  • It allows one and only one application server in a deployment. On that server, both the index server role and the query server role are enabled automatically. You cannot have separate index and query servers in a Search Server 2008 Express deployment.

  • It is available as a free download from Microsoft, with no time restrictions. For information about downloading and installing Search Server 2008 Express from the Microsoft Enterprise Search Web site, see Install Search Server 2008 or Search Server 2008 Express.

In contrast, Search Server 2008 has the following main characteristics:

  • It enables you to deploy multiple application servers in a farm in order to separate the index server and query server roles to different computers. You can add query servers as the need arises. For more information, see Advantages of deploying separate query servers later in this article.

  • It requires a Product Key during installation.

Similarities between Search Server 2008 and Search Server 2008 Express

Search Server 2008 and Search Server 2008 Express share the following characteristics:

  • Both products provide the option to deploy a single-server, stand-alone configuration that is fully functional. With either product, you set up this kind of configuration by choosing the Basic installation option. This option automatically installs all Search Server components and server roles, as well as Microsoft SQL Server 2005 Express Edition for data storage, on one computer. For more information about the Basic and Advanced installation options, see Choosing Basic or Advanced installation.

  • Both products, in any configuration, require one and only one index server in a deployment. This applies to Basic installations and Advanced installations, and to single-server and multiple-server deployments.

  • Both products require you to specify an existing SQL Server host for data storage when you choose the Advanced option during installation. SQL Server provides greater performance and indexing capacity than SQL Server 2005 Express Edition, which is installed automatically when you choose the Search Server Basic installation option. For information about database server requirements for a Search Server Advanced installation, see Prepare the database server later in this article.

  • Both products provide the option to add multiple WFE servers to an existing farm. After you install either product with the Advanced installation option on the first computer in a farm, you can install the same product on other computers that you want to add to the farm. Each time you install the product on another computer, you can configure that computer with the WFE server role and join that computer to the farm.

Choosing Basic or Advanced installation

When you install Search Server 2008 or Search Server 2008 Express, you are prompted to specify the Basic or Advanced installation option. The main differences between Basic and Advanced installation are as follows:

Basic installation

A Basic installation is useful when you need:

  • A small-scale deployment with minimal administrative overhead

  • A development or test environment

  • A deployment for product evaluation

A Basic installation has the following main characteristics:

  • It installs Search Server for a single-server deployment. This fully functional configuration automatically enables the application server role and WFE server role on one stand-alone computer. There is no option to add computers to the deployment to create a multiple-server farm. (To use the computer as part of a multiple-server farm, you must uninstall Search Server and then run an Advanced installation on that computer with the appropriate options.)

  • It automatically installs and uses SQL Server 2005 Express Edition for data storage on the same computer with Search Server. SQL Server 2005 Express Edition is based on the SQL Server architecture, but it has the following limitations:

    • Supports one CPU only

    • Provides a maximum of 1 gigabyte (GB) of memory for the buffer pool

    • Does not support enterprise-level features

    • Limits maximum database size to 4 GB

      Note Note:

      There is no limit to the number of documents that Search Server can index. However, the 4 GB maximum database size in SQL Server 2005 Express Edition can limit Search Server indexing capability to approximately 400,000 documents, depending on the size and type of the documents.

    • Uses default configuration settings.

Advanced installation

On the first computer in a new Search Server deployment, the Advanced installation option installs the application server and WFE server roles. Together with a SQL Server host, which can be the same computer, this creates a fully functional Search Server configuration. For a production deployment, we recommend that you install Search Server 2008 with the Advanced installation option. This enables you to expand your farm as necessary to satisfy search requirements for your organization.

An Advanced installation has the following main characteristics:

  • Enables you to deploy a single-server farm initially, and then add multiple servers to an existing Search Server deployment to distribute the functionality and workload. Deploying a multiple-server farm helps to increase capacity, performance, and availability for the deployment.

    • After you install Microsoft Search Server 2008 Express on the first computer in a deployment, you can install it on other computers to add WFE servers to the deployment.

    • After you install Microsoft Search Server 2008 on the first computer in a deployment, you can install it on other computers to add application servers and WFE servers to the deployment.

      For more information about Search Server topology options, see Topology options later in this article.

  • Requires that you specify a SQL Server host, which can be a different computer from Search Server. SQL Server does not impose a limit on the number of documents that Search Server can index.

  • Provides other configuration options.

Product comparison summary

The following table briefly summarizes the preceding comparison of Search Server 2008 and Search Server 2008 Express features and installation options.

 | Basic installation option | Advanced installation option
Search Server 2008 or Search Server 2008 Express: Server roles | Provides a stand-alone deployment by installing all Search Server components and roles (application server, WFE server, and database server) on one computer. | On the first computer in a deployment, installs the application server role and WFE server role only.
Search Server 2008 or Search Server 2008 Express: Database requirement | Automatically installs SQL Server 2005 Express Edition on the first server in a deployment. | During installation, requires that you specify an existing server that is running either Microsoft SQL Server 2005 with at least SP2, or SQL Server 2000 with at least SP3a. The database software can be installed on the same computer as Search Server, or on a different computer.
Search Server 2008 Express: Scalability options | Limited to one stand-alone server that fulfills all server roles. Does not allow you to add servers to the deployment. | Provides one and only one application server in a deployment. Enables you to add WFE servers to a deployment.
Search Server 2008: Scalability options | Limited to one stand-alone server that fulfills all server roles. Does not allow you to add servers to the deployment. | Enables you to add application servers (configured as query servers) and WFE servers to a deployment.

Topology options

When you deploy the first computer in a Search Server farm, typically you install Search Server so that the computer is configured with the application server role and WFE server role. As the sole application server for the deployment, the computer is automatically configured as the index server and query server. This installation process is explained in Install Search Server 2008 or Search Server 2008 Express.

As previously mentioned, Search Server requires one and only one index server in a deployment. When you add an application server to a deployment, we recommend that you continue to use the first server in the deployment as the index server and you configure the new application server as a query server. Because indexing is so resource-intensive, we recommend that the first computer that you deploy for a multiple-server farm has the most power and storage capacity, or that it is second only to your database server in this respect.

In this section:

  • Sample topologies for various farm sizes

  • Advantages of deploying separate query servers

Sample topologies for various farm sizes

The following table shows sample topologies for various deployment sizes.

Size of deployment Installation option and scalability Server role details

Stand-alone:

One Search Server host computer with Microsoft SQL Server 2005 Express Edition installed on the same computer

Basic installation:

No scalability. Cannot be expanded to a multiple-server deployment.

  • The computer fulfills all roles for the deployment: application server, WFE server, and database server.

  • The application server role is automatically configured to function as both index server and query server.

Small:

One Search Server host computer with SQL Server installed on the same computer or on a different computer

Advanced installation:

Installing Search Server 2008 with the Advanced option on the first computer in a farm enables you to add application servers and WFE servers to the deployment at any time.

  • The Search Server host computer is configured with the application server role and WFE server role.

  • The application server role is automatically configured to function as both index server and query server.

Medium to large. Includes:

  • Multiple application servers

  • A dedicated SQL Server host

  • Optional: Servers configured with only the WFE server role

Advanced installation:

Installing Search Server 2008 with the Advanced option on each computer in the farm enables you to add application servers and WFE servers to the deployment at any time.

A multiple application server deployment contains one index server and one or more separate query servers.

To determine which topology option is best for your organization, consider the demands of your organization in areas such as the following:

  • Search availability

  • Search query volume

  • System performance

The following section provides information about how deploying separate query servers can address requirements in these areas.

Advantages of deploying separate query servers

Installing Search Server 2008 or Search Server 2008 Express with the Basic installation option creates a stand-alone deployment. A single computer fulfills the role of application server and WFE server. Because there is only one application server, computer resources for indexing content and serving search queries must be shared. In addition, if the computer is unavailable, Search Server cannot index content or serve queries until the computer becomes available again.

However, if you install the first computer in a deployment with the Search Server 2008 Advanced installation option, you can add application servers to the deployment at any time to increase capacity, performance, and availability.

In a farm with multiple application servers, you must configure those servers in the following way:

  • Configure one and only application server with the index server role but not the query server role.

  • Configure each of the other application servers with the query server role but not the index server role.

Thus, when you add an application server to a stand-alone deployment, resources of one computer are used for indexing, and resources of the other computer are used for serving search queries. In this way, more computer resources can be devoted to each server role than in a stand-alone deployment.

This configuration also provides greater availability than a stand-alone deployment. As Search Server crawls and indexes content, it automatically propagates the content index from the index server to the query server. The query server serves search queries from its own copy of the index. In this configuration, if the index server is unavailable, the query server continues to serve search queries from the index that was most recently propagated. Conversely, if the query server is unavailable, a search services administrator can configure the index server to serve queries. The administrator can then rejoin the query server to the farm when the query server is available again. At this point, the content index automatically resumes propagating from the index server to the query server. (The time required for this propagation varies depending upon the size of the index. A content index can contain many gigabytes of data, depending on how much content has been crawled.)

As your availability, capacity, and performance requirements increase, you can add more query servers. The content index automatically propagates to each query server in the deployment. Each query server serves queries from its own copy of the index. If a query server is unavailable, Search Server automatically diverts all queries to other query servers. Moreover, Search Server automatically balances the load among all query servers.

For information about how to add query servers to a farm, see Add query servers to expand a farm (Search Server 2008).

Plan for required user accounts

When you deploy Search Server 2008 in a multiple-server configuration, you must provide credentials for certain user accounts. These accounts are required for installation, administration, and operation of Search Server 2008 and the associated database server. These account requirements are described in the following table. For more information about account requirements, see Plan for administrative and service accounts (Search Server 2008).

Account When used Account requirements Account purpose

SQL Server service account

  • SQL Server installation

  • Search Server Advanced installation

Must be a domain user account

Account under which the following SQL Server services run:

  • SQL Server (MSSQLSERVER)

  • SQL Server Agent (MSSQLSERVER)

If you are not using the default SQL Server instance, these services are shown as:

  • SQL Server (MSSQL$InstanceName)

  • SQL Server Agent (SQLAgent$InstanceName)

User account for current logon session

Search Server installation

  • Must be a domain user account

  • Must be a member of the local administrators group (after installation, the account can be removed from the local administrators group)

  • Must be the same account on each farm server on which you install Search Server

Used to install Search Server on each computer in the farm

Server farm account (also called the database access account)

Search Server Advanced installation (Specify Configuration Database Settings dialog box)

  • Must be a domain user account

  • Need not be a member of any Windows security group

  • In accordance with the principle of least privilege, we recommend using an account that is not a member of the local administrators group on any application server, WFE server, or database server in your Search Server farm.

Used for all of the following:

  • Application pool identity of the Web application that contains the Central Administration site

  • Windows SharePoint Services Timer (SPTimerV3) service.

  • SQL Server configuration database access

  • The Search Server installation program also adds this account to the SQL Server Logins, the SQL Server Database Creator server role, and the SQL Server Security Administrators server role.

Default account for services

Search Server Configuration page that appears immediately following Search Server Advanced installation

Must be a domain user account

Used for all of the following:

  • Application pool identity of the Web application that contains the Search Administration site

  • Office SharePoint Server Search (OSearch) service

  • Windows SharePoint Services Search (SPSearch) service

Search Center account

Search Server Configuration page that appears immediately following Search Server Advanced installation

Must be a domain user account

Application pool identity of the Web application that contains the Search Center site

Prepare the database server

The database server must have Microsoft SQL Server 2005 with at least SP2, or SQL Server 2000 with at least SP3a. Some advanced features require SQL Server 2005 Analysis Services with at least SP2. For information about the hardware and software required to deploy a database server running SQL Server 2005, see SQL Server 2005 System Requirements.

Note Note:

For best performance, we recommend that you deploy a dedicated database server.

SQL Server configuration

If you are using SQL Server 2005, you must configure the surface area settings to enable remote connections, as described in the following procedure. For more information, see How to configure SQL Server 2005 to allow remote connections.

To enable remote connections in SQL Server 2005

  1. Log on to the SQL Server 2005 host using an account that is a member of the local administrators group.

  2. Click Start, point to All Programs, point to Microsoft SQL Server 2005, point to Configuration Tools, and then click SQL Server Surface Area Configuration.

  3. In the SQL Server 2005 Surface Area Configuration dialog box, click Surface Area Configuration for Services and Connections.

  4. On the Surface Area Configuration for Services and Connections page, perform the following tasks:

    1. In the tree view, expand the node for your instance of SQL Server, expand the Database Engine node, and then click Remote Connections.

    2. Select Local and Remote Connections, select Using both TCP/IP and named pipes,and then click Apply.

    3. When you receive the message Changes to Connection Settings will not take effect until you restart the Database Engine service, click OK.

    4. In the tree view, under the node for your instance of SQL Server, under Database Engine, click Service, and then click Stop.

    5. After the MSSQLSERVER service stops, click Start to restart the service.

  5. Click Apply.

  6. Click OK to close the Surface Area Configuration for Services and Connections dialog box.

  7. Close the SQL Server 2005 Surface Area Configuration dialog box.

SQL Server collation settings

For Search Server compatibility and consistency with Windows operating system file naming conventions, SQL Server collation must be configured as follows:

  • Case-insensitive

  • Accent-sensitive

  • Kana-sensitive

  • Width-sensitive

Important Important:

During Search Server installation, the SharePoint Products and Technologies Wizard cannot proceed beyond a certain point if SQL Server is not configured with the proper collation settings.

For more information, see Selecting a SQL Collation and Collation Settings in Setup in SQL Server Books Online.

Deploying Search Server in a DBA environment

During a typical installation, Search Server creates the configuration and content databases that it needs. However, in many IT environments a database administrator (DBA) is responsible for database creation and management. In such environments, the DBA can create Search Server databases before product installation so that Search Server can be deployed using those databases.

Uninstallation considerations

  • Uninstalling a Search Server Advanced installation does not delete existing Search Server databases. If you reinstall Search Server on the same computer and you do not delete existing Search Server databases, you might be prompted to delete existing databases or specify different databases.

  • A Basic installation cannot be converted to an Advanced configuration. If you run a Basic installation and later you want to use features offered only in an Advanced installation, you must uninstall the Basic installation and then run an Advanced installation with the appropriate options.

  • Uninstalling Search Server from the first computer you deployed in a farm might cause problems in the farm. This is because the first computer is typically the index server and also hosts the Central Administration Web site. We recommend that you choose a different server if you want to uninstall Search Server from a computer in your farm.

Other considerations

  • You must install the same language packs on all servers that are configured with the WFE role in a Search Server farm. For more information about installing language packs, see Deploy language packs (Search Server 2008).

  • All servers in a Search Server farm must be in the same language. For example, you cannot have both an English version and a Japanese version of Search Server in the same farm.

  • If you place a query server and index server on opposite sides of a firewall, you must open the NetBIOS ports (TCP/UDP ports 137, 138, and 139) on each firewall that separates these servers. If your environment does not use NetBIOS, you must use direct-hosted server message block (SMB). This requires that you open the TCP/UDP 445 port.

  • On all WFE servers that you deploy in your farm, you must install Search Server on the same drive.

  • Installing Search Server on a domain controller might require additional configuration steps.

See Also

Concepts

Upgrade to Search Server 2008 from Windows SharePoint Services 3.0
Upgrade to Search Server 2008 from Search Server 2008 Express
Install Search Server 2008 or Search Server 2008 Express
Add query servers to expand a farm (Search Server 2008)
Plan to crawl content (Search Server 2008)
Plan the end-user search experience (Search Server 2008)


Plan for performance and capacity (Search Server 2008)
DropDown image

Updated: 2008-09-11

Performance and capacity planning is the process of mapping your solution design to a farm size and set of hardware that will support your business goals. This section provides information about how to plan performance and capacity for your Search Server 2008 or Search Server 2008 Express farm.

The articles in this chapter include the following:

  • About performance and capacity planning (Search Server 2008) walks you through the process of determining the hardware requirements for a single farm, and provides an overview of the planning process.

  • Estimate performance and capacity requirements for Search Server 2008 discusses test results and recommendations specific to Search Server 2008 and Search Server 2008 Express. This article also includes software limits and guidelines for acceptable performance.

See Also

Concepts

Plan for availability (Search Server 2008)
Plan for redundancy (Search Server 2008)


About performance and capacity planning (Search Server 2008)
DropDown image

Updated: 2008-09-11

The articles in this chapter will help you to determine the most appropriate hardware, topology and configuration requirements for a single Microsoft Search Server 2008 or Microsoft Search Server 2008 Express farm. The articles identify factors that can affect performance and capacity requirements, and provides recommendations for the following:

  • Number of server computers in the server farm.

  • Configuration of server roles in the server farm.

  • Hardware requirements for specific server roles in the server farm.

The capacity planning process should include a testing program for the characteristics specific to the environment. Because of the variety of factors that can affect performance and capacity in a given environment, testing is a crucial step in establishing the characteristics of the environment.

Planning for capacity vs. availability and redundancy

Search Server 2008 and Search Server 2008 Express are built on the Windows SharePoint Services 3.0 platform. If you plan to use Search Server 2008 to host Windows SharePoint Services 3.0 sites as well as for Search functionality, you should also read the Plan for availability (Search Server 2008) and Plan for redundancy (Search Server 2008) articles to ensure that you start the capacity planning exercise with a topology that meets the organization's minimum availability and redundancy requirements. Given the topology you have determined you will deploy, these articles will help you decide whether you need to do the following:

  • Deploy Search Server 2008 or Search Server 2008 Express.

  • Add servers to meet goals for capacity and performance.

  • Adjust the configuration of server roles to optimize capacity and performance of the server farm.

  • Plan for more than one server farm based on capacity requirements.

In some cases, an organization's requirements for availability or redundancy can result in a server farm size that provides greater capacity or performance than is otherwise required. If this is the case, the capacity planning process can focus on sizing the server hardware economically, rather than on adding server computers or scaling up with higher-performing hardware.

In many cases, the topology that meets an organization's minimum availability and redundancy requirements is used as a starting point and server computers are added or scaled up to meet capacity and performance goals.

Performance and capacity planning process

There are many variables that can affect performance and capacity planning. Consequently, the most common answer to a performance- or capacity-related question begins with, "It depends."

The performance and capacity planning exercises provided in these topics are designed to reduce the number of variables in consideration so that straightforward answers can be provided based on common scenarios.

Performance and capacity planning focuses on the following three aspects of a solution:

  • Software boundaries Each of the features that can be implemented and the objects that can be created have scale limitations. Planning for capacity boundaries ensures that the solution design fits within the scale recommendations of the software. Software boundaries and limits provided in this guide apply to all Search Server 2008 and Search Server 2008 Express environments.

    The article Estimate performance and capacity requirements for Search Server 2008 covers this area. Review the software boundaries and limits of the software against the solution design using the guidance in this article, and make adjustments to the design if they are necessary.

  • Throughput targets Throughput is the number of operations per second that a server or server farm can process. Each kind of action that is performed by a server farm introduces a performance load on the server hardware. Primary actions include user operations, indexing content, and operations tasks (such as backing up the databases). The use of specific features also adds a performance load. Developing throughput targets involves estimating or calculating the number of operations per second that a server farm must process to support the expected throughput load.

    Guidance for establishing throughput targets and data capacity is provided for in Estimate performance and capacity requirements for Search Server 2008. Use the guidance in this article to determine the key performance and capacity characteristics for the environment, to estimate throughput and data capacity targets for the solution, and to evaluate targets against the performance of several sample topologies and sizes of hardware.

  • Data capacity Data capacity includes the expected volume of content databases and the configuration database. Each server role also has unique data requirements based on the solution, such as disk space for content indexes or for cached content.

    Use the guidance in the article Estimate performance and capacity requirements for Search Server 2008 to determine your data capacity requirements.

After you have established a starting point topology, you can deploy a test environment based on the deployment plan. You can use the test tools that are provided in the article Tools for performance and capacity planning (Windows SharePoint Services) to establish actual performance and capacity data for the environment, and revise the deployment plan as required.

See Also

Concepts

Estimate performance and capacity requirements for Search Server 2008
Determine hardware and software requirements (Search Server 2008)
Plan for availability (Search Server 2008)
Plan for redundancy (Search Server 2008)

Other Resources

Plan for performance and capacity (Windows SharePoint Services)


Estimate performance and capacity requirements for Search Server 2008
DropDown image

Updated: 2008-09-11

In this article:

  • Key characteristics

  • Test environment

    • Assumptions

    • Lab topologies

    • Usage profile

  • Estimating throughput targets

    • Throughput and latency by farm configuration

    • Data trends

  • Recommendations

    • Hardware and software recommendations

    • Starting-point topologies

    • Estimate crawl window

    • Estimate disk space requirements

    • Determining specifications for index, query, and database servers

  • Guidelines for acceptable performance

This article provides test results and recommendations for both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express. Use this article to help determine the hardware and configuration details required for the deployment.

This performance and capacity planning scenario incorporates a single Search Server 2008 farm or a computer running Search Server 2008 Express that is used to search and index content in an enterprise environment. The performance and capacity characteristics of multiple-farm environments are not covered in this topic.

Note that the only substantive difference between Search Server 2008 and Search Server 2008 Express is that in a Search Server 2008 Express deployment, you can only have one application server. In both Search Server 2008 and Search Server 2008 Express, you can use either Microsoft SQL Server 2005 Express Edition or Microsoft SQL Server 2005, and the database server software can reside either on the same server as or on a separate server from the computers that are running Search Server 2008 Express or Search Server 2008. In all other respects, Search Server 2008 and Search Server 2008 Express function and are managed in the same way.

Use the information in this article to help you determine the best architecture for the Search Server 2008 or Search Server 2008 Express deployment.

Before you read this topic, you should review About performance and capacity planning (Search Server 2008).

Key characteristics

Key characteristics describe environmental factors, usage characteristics, and other considerations that are likely to be found in deployments based on this scenario.

The key characteristics for this scenario include:

  • Time to complete user queries. Some organizations might tolerate slower user response times or might require faster user response times. The expected response time is a key factor that influences overall throughput targets. Throughput is how many requests the server farm can process per second. When you have more users, you require faster throughput to achieve the same response time.

  • User concurrency. A concurrency rate of 10 percent is assumed, with one percent of concurrent users making requests at a given moment. For example, for 10,000 users, 1,000 users are actively using the solution simultaneously, and 100 users are actively making requests.

  • Long-running asynchronous tasks. Tasks such as crawling content and backing up databases add a performance load to the server farm. The general performance characteristics of sample Search Server 2008 and Search Server 2008 Express topologies assume that these tasks may run during peak hours, and may therefore impact the overall performance of the farm.

  • Scale-out factors. Several different scaling options were tested to help determine the most effective topology for the environment. See the Lab Topologies section for information about the tested topologies.

Test environment

Testing for this scenario was designed to help develop estimates of how different farm configurations respond to changes in a variety of factors, including:

  • How many query servers are deployed in the farm.

  • How many content sources are being crawled simultaneously.

  • How many items are in the index that is being queried.

Note that although some conclusions can be drawn from the test results, the specific capacity and performance figures in this article might be different from the figures in real-world environments. The figures in this article are intended to provide a starting point for the design of an adequately sized environment. After you complete the initial system design, test the configuration to determine if the system will meet the requirements of the environment.

Assumptions

64-bit architecture. Only 64-bit servers were used in the test environment. Although Search Server 2008 can be deployed on 32-bit servers, we recommend that you use 64-bit servers in Search Server 2008 and Search Server 2008 Express farm deployments.

The guidance presented in this guide is based on testing that was performed on 64-bit servers. Therefore, if you are planning to deploy to 32-bit servers, you should perform additional testing on the 32-bit servers in the environment. The best practices and performance trends in this guide will generally apply to 32-bit environments, but actual results may vary.

The 64-bit system architecture has the following characteristics that contribute to superior server scalability and performance:

  • Memory addressability. A 32-bit system can directly address only a 4-gigabyte (GB) address space. Windows Server 2003 with Service Pack 1 (SP1) running on a 64-bit system architecture supports up to 1,024 GB of physical memory.

  • Larger numbers of processors and more linear scalability per processor. Improvements in parallel processing and bus architectures enable 64-bit platforms to support more processors (up to 64) while providing close to linear scalability with each additional processor. Server platforms that offer more than 32 CPUs are available exclusively on 64-bit architecture.

  • Enhanced bus architecture. The front-side bus on current 64-bit chip sets is faster than that of earlier generations, and also has higher bandwidth. More data is passed more quickly to the cache and processor.

Lab Topologies

The farm configurations that were used for testing are described in the following table. All server computers were running Search Server 2008 Enterprise Edition or Microsoft Search Server 2008 Express on the Microsoft Windows Server 2008 operating system with Service Pack 1 (SP1), Enterprise x64 Edition.

In this article, the guidelines are determined by performance. In other words, you can exceed the guidelines provided, but as you increase the scale, you might experience reduced performance.

Note that there are many factors that can affect performance in a given environment, and each of these factors can affect performance in different areas. Some of the test results and recommendations in this article might be related to features or user operations that do not exist in the environment, and therefore do not apply to your solution. Only thorough testing can provide you with exact data related to your own environment.

The following table lists the specific hardware and software configurations used for testing.

Configuration A: Search Server 2008 Express and SQL Server 2005 Express Edition on a single server
Computer role | Hardware | Hard disk capacity
Single server | Dual-core Intel 2.4 gigahertz (GHz) processor 4 gigabytes (GB) RAM | 500 GB SATA
Configuration B: Search Server 2008 and SQL Server 2005 on a single server
Computer role | Hardware | Hard disk capacity
Single server | Dual-core Intel 2.4 GHz processor 4 GB RAM | 500 GB SATA
Configuration C: Search Server 2008 on one server and SQL Server 2005 on a separate server
Computer role | Hardware | Hard disk capacity
Application server | Dual-core Intel 2.4 GHz processor 4 GB RAM | 500 GB SATA
Database server | Quad-core Intel 3.4 GHz processor 8 GB RAM | 750 GB SAS
Configuration D: Search Server 2008 on two servers and SQL Server 2005 on a separate server
Computer role | Hardware | Hard disk capacity
Query server | Dual-core Intel 2.4 GHz processor 4 gigabytes (GB) RAM | 500 GB SATA
Index server | Dual-core Intel 2.4 GHz processor 4 gigabytes (GB) RAM | 500 GB SATA
Database server | Quad-core Intel 3.4 GHz processor 8 GB RAM | 750 GB SAS

A gigabit (1 billion bits/sec) network was used in the test environment. We recommend using a gigabit network between servers in a Search Server 2008 farm to ensure adequate network bandwidth.

Usage profile

The following tables show the usage profile for the Search Server 2008 search test environment.

Note Note:

Only query operations were used to determine system performance in these scenarios.

A range between 1.5 million and 6.5 million items was crawled for the different tests. The following table shows the type and number of items crawled. Items were 10 kilobytes (KB) to 100 KB in size, and included list items, Web pages, and various document types.

Type of item Number of items

Content on SharePoint sites

4.5 million items, including the following:

  • site collections

  • sites

  • lists

  • files on file shares

Content on file shares

3.5 million

HTTP content

Between 1.5 million and 6.5 million

The following table shows disk space usage.

Type of usage | Volume
Index size on query server | 100 GB*
Index size on index server | 100 GB*
Search database size | 600 GB
Note Note:

The tested index sizes are smaller than what might be in a production environment. This is because in the test-generated corpus, the number of unique words is smaller in the test-generated corpus.

Estimating throughput targets

This section provides test data that shows farm throughput for an increasing number of query servers and more content sources for Search Server 2008. The test data for configurations B, C, and D in this section does not apply to Search Server 2008 Express.

Because Search Server 2008 can be deployed and configured many ways, there is no simple way to estimate how many users can be supported by a given number of servers. Therefore, it is important that you conduct testing in your own environment before deploying Search Server 2008 in a production environment.

There are several factors that can affect throughput, including the number of users, complexity and frequency of user operations, and the types of content being crawled. Each of these factors can have a major effect on Search Server 2008 farm throughput. You should carefully consider each of these factors when you are planning the deployment.

If the organization has an existing search solution, you can view the Web server logs to determine the usage patterns and trends in the current environment.

If the organization is planning a new search solution deployment, use the information in the following section to estimate usage patterns.

Throughput and latency by farm configuration

The table in this section shows test results for a variety of user operation profiles using the hardware and usage profile listed in Test environment earlier in this article. For each farm configuration, a range of one through eight query servers was tested in conjunction with one index server and one database server.

The following table shows test results for query and crawling operations.

Farm configuration | Number of content sources | Average crawl speed in items per second | Query latency | Query latency when crawling | Query throughput (RPS) | Query throughput when crawling
Configuration A: Search Server 2008 Express on a single server with SQL Server 2005 Express Edition | 1 | 24.27 | 0.5738 | 1.0028 | 33.01 | 26.36
Configuration B: Search Server 2008 on a single server with SQL Server 2005 | 1 | 19.18 | 0.7433 | n/a | 20.53 | n/a
 | 2 | 16.54 | 0.8404 | 1.62 | 17.65 | 15.54
 | 3 | 13.04 | 0.8844 | 2.4429 | 12.46 | 11.51
 | 4 | 11.9 | 0.9226 | 2.5011 | 10.45 | 10.94
 | 5 | 10.85 | 1.1112 | 3.4106 | 8.59 | 9.82
Configuration C: Search Server 2008 on one server and SQL Server 2005 on a separate server | 1 | 19.3 | 0.7821 | n/a | 20.83 | n/a
 | 2 | 16.54 | 0.8561 | 0.868 | 18.61 | 17.17
 | 3 | 17.11 | 0.8998 | 1.0274 | 18.56 | 12.21
 | 4 | 17.28 | 0.8882 | 1.0833 | 15.37 | 11.93
 | 5 | 16.12 | 1.0929 | 1.0985 | 12.77 | 11.16
 | 6 | 14.81 | 1.3025 | 1.3909 | 10.89 | 7.74
Configuration D: Search Server 2008 on two servers and SQL Server 2005 on a separate server | 1 | 19.47 | 0.6578 | n/a | 27.5 | n/a
 | 2 | 17.19 | 0.8467 | 0.7148 | 18.49 | 21.47
 | 3 | 17.79 | 0.8536 | 0.8493 | 18.48 | 18.26
 | 4 | 18.47 | 0.8855 | 0.9387 | 18.37 | 15.21
 | 5 | 15.34 | 1.0562 | 0.9891 | 12.84 | 14.61
 | 6 | 15.6 | 1.2461 | 1.209 | 10.92 | 11.13

Data trends

The following graphs compare trends between configurations B, C, and D as the volume of crawled items increases. Configuration A is not represented because Search Server 2008 Express running SQL Server 2005 Express Edition has a maximum database size of 4 GB, which effectively limited the number of crawled items to 500,000.

The graph below shows the difference in average crawl speed in items per second between configurations B, C and D.

Average crawl speed

As the number of items being crawled increases past 1,000,000 items, configurations C and D, both having separate index and database servers, continue to perform well up to the maximum number of items crawled, whereas the performance of configuration B begins to fall. Therefore, if the number of items to crawl in the environment exceeds 1,000,000, you should consider deploying a separate database server.

The following graph shows the difference in query latency while crawling content between configurations B, C, and D.

Query latency while crawling

In this graph, you can see that latency while crawling is substantially higher for configuration B than for configurations C and D. If the needs of the organization indicate a need for low latency for user requests while crawling, you should consider deploying a separate database server.

The following graph shows the difference in query throughput in requests per second (RPS) between configurations B, C, and D.

Query throughput while crawling

Whereas configurations C and D show similar performance in terms of latency while crawling, configuration D performs substantially better than configurations B and C in query throughput during a crawl operation. If user requirements do not permit a regular crawling window in which crawling can take place without interfering with the performance of query response, you should consider a deployment architecture that includes at least one separate query server and separate index and database servers.

Recommendations

This section provides general performance and capacity recommendations. Use these recommendations to determine the capacity and performance characteristics of the starting topology that you created in Determine hardware and software requirements (Search Server 2008), and to determine whether you need to scale out or scale up the starting topology.

Note Note:

Scale out means to add more servers in a particular role, and scale up means to increase the performance or capacity of a given server by adding memory, hard disk capacity, or processor speed.

Hardware and software requirements

Memory requirements for Web, index, and database servers are dependent on the size of the farm, the number of concurrent users, and the complexity of features and pages in the farm. The memory recommendations in the following table may be adequate for a small or light-usage farm. Nonetheless, memory usage should be carefully monitored to determine if more memory must be added.

For information about minimum and recommended system requirements, see Determine hardware and software requirements (Search Server 2008).

Starting-point topologies

You can estimate the performance of the starting-point topology by comparing the topology to the starting-point topologies that are provided in Plan to deploy Search Server 2008 or Search Server 2008 Express. So doing can help you quickly determine if you need to scale up or scale out the starting-point topology to meet performance and capacity goals.

Capacity and performance of scaled-up and scaled-out topologies

To increase the capacity and performance of one of the starting-point topologies, either scale up by implementing server computers with greater capacity or scale out by adding servers to the topology. This section describes the general performance characteristics of several scaled-up or scaled-out topologies. The sample topologies represent the following common ways to scale up or scale out a topology for a search environment:

  • To accommodate greater user load, add query server computers. You can also add dedicated query servers to relieve some of the processing burden from the Web servers.

  • To accommodate greater data load, increase the capacity of the index server, or add capacity to the database server role by increasing the capacity of a single (clustered or mirrored) server, by upgrading to a 64-bit server, or by adding clustered or mirrored servers.

  • Maintain a ratio of no greater than eight query server computers to one (clustered or mirrored) database server computer.

Estimate crawl window

In a Search Server 2008 or Search Server 2008 Express environment, crawling content is the longest-running operation that is not initiated by users. You will need to perform testing in your own environment to determine the amount of time it takes to crawl content using a particular content source, and whether the throughput consumed by crawling this content interferes with target user response times. You should use incremental crawls when possible to reduce the impact of crawling on farm performance.

Estimate disk space requirements

Use the following information to plan the disk space requirements for the index server, query servers, and database servers in the environment.

Disk space requirements for index and query servers

Use the following information to plan the disk space requirements for the index server and query servers in the server farm.

Note Note:

The size of the content index is typically smaller than the corpus because all noise words are removed before the content is indexed.

Note Note:

If the query server role is enabled on a server other than the index server, the index is automatically propagated to those query servers. To store a copy of the content index in the file system on a query server, each query server requires the same amount of disk space as the index server uses for the content index.

To estimate the disk space requirements for the hard disk that contains the content index:

  1. Estimate how much content you plan to crawl and the average size of each file. If you do not know the average size of files in the corpus, use 10 KB per document as a starting point.

    Use the following formula to calculate how much disk space you need to store the content index:

    GB of disk space required = Total_Corpus_Size (in GB) x File_Size_Modifier x 2.85

    where File_Size_Modifier is a number in the following range, based on the average size of the files in the corpus:

    • 1.0 if the corpus contains very small files (average file size = 1 KB).

    • 0.12 if the corpus contains moderate files (average file size = 10 KB).

    • 0.05 if the corpus contains large files (average file size = 100 KB or larger).

Note Note:

This equation is intended only to establish a starting-point estimate. Real-world results may vary widely based on the size and type of items being indexed, and how much metadata is being indexed during a crawl operation.

In this equation, you multiply Total_Corpus_Size (in GB) by the value of the File_Size_Modifier to get the estimated size of the index file. Next, you multiply by 2.85 to accommodate overhead for master merges when crawled data is merged with the index. The final result is the estimated disk space requirement.

For example, for a corpus size of 1 GB that primarily contains files that average 10 KB in size, use the following values to calculate the estimated size of the index file:

1 GB x 0.12 = 0.12 GB

According to this calculation, the estimated size of the index file is 120 MB.

Next, multiply the estimated size of the index file by 2.85:

120 MB x 2.85 = 342 MB

Thus, the disk space required for the index file and to accommodate indexing operations is 342 MB, or 0.342 GB.

Note Note:

The volume of crawled data can differ based on the content being crawled.

  1. Based on the estimate, if the content index will fit within the available hard disk space on the index and query servers, go to step 3. Otherwise, add disk space or reevaluate step 1 before proceeding to step 3.

  2. Crawl some of the content.

  3. Evaluate the size of the content index and the number of files that were crawled. Use this information to increase the accuracy of the calculation that you performed in step 1.

  4. If the remaining hard disk space is adequate, crawl some more content. Otherwise, add hard disk space as necessary or reevaluate how much content you plan to crawl.

  5. Repeat steps 3 through 5 until all content is crawled.

    After you have crawled the entire corpus, we recommend that you keep a record of the size of the content index and search database for each crawl so that you can determine an average growth rate. A corpus tends to grow over time as new content is added to the farm. Therefore, you should monitor the available hard disk space to ensure that adequate capacity for indexing operations is maintained.

Disk space requirements for the search database

The search database, which stores metadata and crawler history information for the search system, typically requires more disk space than the index. This is especially the case if you primarily crawl SharePoint sites, which are very rich in metadata.

Note Note:

Both the metadata for all indexed content and the crawler history are stored in the search database. For this reason, the search database requires more storage space than the content index.

Use the following formula to calculate how much disk space you need for the search database:

GB of disk space required = Total_Corpus_Size (in GB) x File_Size_Modifier x 4

where File_Size_Modifier is a number in the following range, based on the average size of the files in the corpus:

  • 1.0 if the corpus contains very small files (average file size = 1 KB).

  • 0.12 if the corpus contains moderate files (average file size = 10 KB).

  • 0.05 if the corpus contains large files (average file size = 100 KB or larger).

For example, for a corpus size of 1 GB that primarily contains files that average 10 KB in size, substitute the following values into the equation to calculate the estimated size of the index file:

1 GB x 0.12 = 0.12 GB, or 120 MB

Then multiply the estimated size of the index file by 4:

120 MB x 4 = 480 MB

Thus, the disk space required for the search database is 480 MB, or 0.48 GB.

Determining specifications for index, query, and database servers

In Search Server 2008, search is a shared service available at the Shared Services Provider (SSP) level. The Search Server 2008 search system consists of two main server roles: the index server and the query server.

Crawling and indexing are resource-intensive operations. Crawling content is the process by which the system accesses and parses content and its properties to build a content index from which search queries can be serviced. Crawling consumes processing and memory resources on the index server, the query server or query servers that are servicing the crawl operations, the server or servers that are hosting the content repository that is being crawled, and the database server that is serving the Search Server 2008 farm.

Crawls affect the overall performance of the system, and directly affect user response time and the performance of other shared services in the farm. Crawls also affect the Web service on the query server that services crawl operations. You can dedicate a query server for crawling operations to reduce the load on other farm servers.

Indexing the crawled content can also affect the overall performance of the system if crawl operations are not assigned to a dedicated query server. If search-related operations constitute a significant portion of farm operations, consider deploying a dedicated query server.

Determining specifications for the index server

Use the information in this section to specify requirements for the index server in a Search Server 2008 farm.

Index server CPU

The index server processor speed influences the crawl speed and the number of crawling threads that can be instantiated. Although there is no specific number or type of processors that are recommended, you should consider the amount of content that will be crawled when determining the index server requirements. In an enterprise environment, the index server should have multiple processors to handle a large indexing load.

The following table shows how crawl speed increases as the number of processors available on the index server increases.

Number of processors | Percentage of improvement in crawl speed
1 | 0.00
2 | 10.89
4 | 19.77
8 | 30.77

Index server memory

On the index server, items are loaded in buffers for processing by the crawler engine. In a farm with a corpus of approximately 1 million items, the index server requires approximately 1.5 GB of memory. After a document is processed in memory, it is written to disk. The greater the memory capacity, the more items the crawler can process in parallel, which results in improved crawl speed.

We recommend a minimum of 4 GB RAM on the index server.

Index server disk speed

We recommend that you specify redundant arrary of independent disks (RAID) 10 with 2 millisecond (ms) access times and faster than 150 MB/sec write times for fast disk writes.

Single index and relevance

Search Server 2008 does not support the use of multiple index servers for scaling out, as each index server requires a separate SSP, and only one SSP can exist in a Search Server 2008 farm.

Index server performance optimization

Indexing operations increase the load on the database server, and can reduce the responsiveness of the farm. Indexing operations can also affect other shared services on the application server that is running the Indexing Service. You can adjust the indexing performance level for each index server to one of the following three values:

  • Reduced

  • Partly reduced

  • Maximum

The default setting is Partly reduced.

Crawls affect performance of the database server because the Search Server 2008 Search service writes all the metadata collected from the crawled items into database tables. It is possible for the index server to generate data at a rate that can overload the database server.

You should conduct your own testing to balance crawl speed, network latency, database load, and the load on the content repositories that are being crawled.

The following table shows the relationship between the performance-level setting and the CPU utilization on the index and database servers as tested.

Performance-level setting | Index server CPU utilization percentage | Database server CPU utilization percentage
Reduced | 20 | 20
Partly reduced | 24 | 24
Maximum | 25 | 26
Tip Tip:

If the index server and database servers are used only for the Search Server 2008 Search service, you can set the level to Maximum. However, we recommend that the maximum increase in database server CPU utilization related to index server activity not be greater than 30 percent. If the increase in database server CPU utilization exceeds 30 percent when the performance level is set to Maximum, we recommend setting the performance level to the next lower setting.

Crawler impact rules

Crawler impact rules are farm-level search configuration settings that specify the number of simultaneous requests that the Search Server 2008 Search service generates when it crawls using a specified content source. The greater the number of simultaneous requests, the faster the crawl speed. Note that the request frequency specified in a crawler impact rule directly affects the load on the database server and the load on the server hosting the content that is being crawled. If you increase the request frequency for a given site, you should carefully monitor the servers being crawled to evaluate whether the greater load is acceptable.

The default value is the number of processes on the index server. Therefore, for a quad-processor computer, the default value is eight. We recommend that you adjust the value and measure the load on the target server to determine the optimum number of simultaneous requests. You can select the number of simultaneous requests from the following available values: 1, 2, 4, 8, 16, 32, 64.

You can also create a rule to request one document at a time and wait a specified number of seconds between requests. Such a rule can be useful for crawling a site that has a constant user load.

The following table shows the relationship between the number of simultaneous requests and the CPU utilization on the index server and database servers.

Number of crawl threads | Index server CPU utilization percentage | Database server CPU utilization percentage
4 | 35 | 12
8 | 40 | 15
12 | 45 | 15
16 | 60 | 20

Determining specifications for query servers

Use the information in this section to determine specifications for query servers in the Search Server 2008 farm.

Query server memory

The more memory that is available, the fewer times the Search Server 2008 Search service will need to access the hard disk to perform a given query. Having adequate memory also permits more effective caching. Ideally, enough memory should be installed on the query servers to accommodate the entire index.

Query server disk speed

We recommend using RAID 10 for fast disk writes.

Number of query servers

You can deploy multiple query servers in the farm to achieve redundancy and load balancing. The number of query servers you use depends on how many users are present in the farm and the peak hour load that you expect. We have tested up to eight query servers per farm.

Remote server latency

Server latency is a major factor that affects crawl performance. Performance between farm servers must be balanced for overall crawl performance to reach its potential. For example, a powerful index server can be operating at 25% of its capacity if the database server for the farm being crawled is not able to respond quickly enough. In such a case, you can scale up the database server, which will in turn increase crawl speeds across the entire farm.

You should conduct your own testing to evaluate the responsiveness of servers in the environment. The database server serving the target farm is often the bottleneck in cases where crawl performance is poor. To improve crawl performance, you can:

  • Scale up database server hardware by adding or upgrading processors, adding memory, and upgrading to hard disks with faster seek and write times.

  • Increase the memory on query servers in the farm.

  • Crawl during off-peak hours so that the database server being crawled can service user traffic during the day, and respond to crawls during off-peak hours.

Determining specifications for database servers

The Search Server 2008 search system crawls both text data and the metadata associated with the content. In Search Server 2008, the inverted full text index is stored on the index server, and the metadata is stored in the Search database. The index server writes metadata to the database, and the query servers read that data to process property-based queries issued by users.

Use the information in this section to determine specifications for database servers in a Search Server 2008 farm.

Database throughput

The database metadata store is shared by the index server and all query servers in the farm. The index server writes all metadata, and the query servers read this data to process search requests. Query throughput is dependent largely on the metadata store responsiveness.

As the number of query servers increases in the farm, the load on the database server also increases and affects the overall query throughput. You should carefully monitor the database server when you add query servers to the farm to ensure that database performance remains satisfactory.

Database server hard disk distribution

Because the Search Server 2008 Search service writes a large amount of data to the search database during crawls, we recommend that you use separate hard disks for the SharedServices_Search_Db, SharedServices_Db, and TempDb databases for better performance in scenarios in which the index contains more than 5 million items.

Database server disk speed

We recommend that you use RAID 10 for fast disk writes.

Guidelines for acceptable performance

Capacity is directly affected by scalability. This section lists the objects that can compose a solution and provides guidelines for acceptable performance for each kind of object. Limits data is provided, together with notes that describe the conditions under which the limits obtain and links to additional information where available. Use the guidelines in this article to review your overall solution plans.

If the solution plans exceed the recommended guidelines for one or more objects, take one or more of the following actions:

  • Evaluate the solution to ensure that compensations are made in other areas.

  • Flag these areas for testing and monitoring as you build and deploy the solution.

  • Re-design the solution to ensure that you do not exceed capacity guidelines.

The following tables list the objects by category and include recommended guidelines for acceptable performance. Acceptable performance means that the system as tested can support that number of objects. However, that the number cannot be exceeded without some decrease in performance. An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit.

Search Server 2008 is usually deployed to be a Search solution in an environment that already contains sites or other data sources. You might find it desirable to use a Search Server 2008 farm for hosting Windows SharePoint Services 3.0 sites in addition to the Search Center.

For information about recommended guidelines for Search Server 2008 and Search Server 2008 Express site objects and people objects, see Plan for software boundaries (Windows SharePoint Services).

The following table lists the recommended guidelines for search objects.

Search object | Guidelines for acceptable performance | Notes
Search indexes | 1 per Search Server 2008 or Search Server 2008 Express farm |
Indexed document | 50 million per search index | 50 million items per index server are supported, and one search index per index server. This means that the effective limit of items per index server is 50 million.

The following table lists the recommended guidelines for logical architecture objects.

Logical architecture object | Guidelines for acceptable performance | Notes
Shared Services Provider (SSP) | Search Server 2008: 3 per farm (20 per farm maximum) Search Server 2008 Express: 1 maximum |
Internet Information Services (IIS) application pool | 8 per Web server | Maximum number is determined by hardware capabilities. Search Server 2008 does not require additional application pools unless you decide to use the farm to host additional Windows SharePoint Services 3.0 sites.
Site collection | 50,000 per Web application |
Content database | 100 per Web application |
Site collection | 50,000 per database |

The following table lists the recommended guidelines for physical objects.

Physical object | Guidelines for acceptable performance | Notes
Index servers | 1 per SSP* |
Query servers | No hard limit, recommended 8 maximum | Note that this limit only applies to Search Server 2008 deployments. You may only have one application server in a Search Server 2008 Express deployment.
Query server/domain controller ratio | 3 query servers per domain controller | Depending on how much authentication traffic is generated, the environment may support more query servers per domain controller.

See Also

Concepts

Determine hardware and software requirements (Search Server 2008)
Plan for availability (Search Server 2008)
Plan for redundancy (Search Server 2008)

Other Resources

Configure a dedicated front-end Web server for crawling (Office SharePoint Server 2007)
Plan for performance and capacity (Windows SharePoint Services)


Plan for administrative and service accounts (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This information in this article describes the roles of the planning teams who might be involved in deploying and managing Microsoft Search Server 2008, and then it explains the various administrative and service accounts that are used in installing and maintaining Search Server 2008.

In this article:

  • About the search planning team

  • About administrative and service accounts

  • Standard account requirements

  • Planning recommendations for accounts

About the search planning team

Before you begin planning the features and deployment of Search Server 2008, you should understand the role of the search planning team. Planning for search might require some or all of the following team members depending on the size of your organization and deployment plans:

  • A search services administrator to manage the configuration of the search service. This responsibility includes defining the content sources to be crawled, setting up crawl rules, and scheduling crawls. In addition, the search services administrator monitors the indexes to ensure that the content sources are being crawled successfully.

  • At least one site collection administrator to manage the default site collection that contains the search center site. This administrator manages the end-user experience at the site and site collection level. This responsibility includes defining keywords, Best Bets, and scopes. If there are additional site collections in the farm hosting SharePoint sites, additional site collection administrators might be necessary.

  • IT administrators who plan architecture and topology for one or more server farms in the organization based on content needs. Typically, IT administrators are not concerned with content except as it affects IT operations such as availability, reliability, and capacity planning.

About administrative and service accounts

Administrative and service accounts are used throughout Search Server 2008 to provide access and security. The information in the following sections provides guidance by describing the purpose of each account, the standard account requirements for single-server and multi-server installations, and planning recommendations.

Server farm-level accounts

The following table describes the accounts that are used to configure Microsoft SQL Server and to install Search Server 2008.

Account Purpose

SQL Server service account

SQL Server prompts for this account during SQL Server installation.

This account is used as the service account for the following SQL Server services:

  • MSSQLSERVER

  • SQLSERVERAGENT

If you are not using the default instance, these services are shown as:

  • MSSQL$InstanceName

  • SQLAgent$InstanceName

Setup user account

The account of the person who is logged on while installing Search Server 2008.

Server farm account

This account is also referred to as:

  • Database access account

This account is:

  • The application pool account for the Central Administration site

  • The process account for the Windows SharePoint Services Timer (sptimerV3) service

  • Security account for the SSP

Shared Services Provider (SSP) accounts

The following table describes the accounts that are used in the SSP, for the search service, and to crawl content.

Account Purpose Location

SSP service credentials

Used by the following:

  • SSP Web services for inter-server communication

  • SSP Timer service to run timer jobs

During an Advanced installation of Search Server 2008, you can specify this account under Search Services Administration Account in the optional section of the Search Server Configuration page.

To change the account, go to the Central Administration Web site, and then click Application Management. Under Office SharePoint Server Shared Services, click Create or configure this farm's shared services. On the Manage this Farm's Shared Services page, click the arrow next to the name of the SSP account you want to change, and then click Edit Properties. Under SSP Service Credentials, type the new account information in the Username and Password boxes.

Office SharePoint Server Search

Used as the service account for the Office SharePoint Server search service. There is only one instance of this service.

During an Advanced installation of Search Server 2008, you define this account under Search Service Account on the Search Server Configuration page.

To change the account after installation, go to the Central Administration Web site, and then click Operations. Under Topology and Services, click Services on server. Under Service, click Office SharePoint Server Search. On the Configure Office SharePoint Server Search Service Settings page, under Farm Search Service Account, type the new account information in the User name and Password boxes.

Default content access account

Used to crawl content and is the default account. When a specific account is not provided, the default content access account is used.

To change this account, go to the Central Administration Web site, and then under Shared Services Administration, click SharedServices. On the Search Administration page, under Crawling, click the Default content access account. On the Default Content Access Account page, type the new account information in the Account and Password boxes.

Content access account

Used in a crawl rule that is used to crawl specific content and is an optional account. For example, content that is external to Search Server 2008, such as a file share, might require a different access account from the default.

To change this account, go to the Central Administration Web site, and then under Shared Services Administration, click SharedServices. On the Search Administration page, under Crawling, click Crawl rules. Set the credentials in a new or existing crawl rule.

Windows SharePoint Services Search accounts

The following table describes the accounts that are used to set up and configure Windows SharePoint Services search. In Search Server 2008, this service is referred to as the Windows SharePoint Services Help Search service, because this service is used to provide search capability for Help. When you install Search Server 2008, the accounts are automatically predefined to run as Local services.

Account | Purpose | Location
Windows SharePoint Services Search service account | Used as the service account for the Windows SharePoint Services Search service. There is only one instance of this service in a farm. | During an Advanced installation of Search Server 2008, you define this account under Help Search Service Account on the Search Server Configuration page. To change it after installation, go to the Central Administration Web site, and then click Operations. Under Topology and Services, click Services on server. On the Services on Server page, under Service, click Windows SharePoint Services Search. On the Configure Windows SharePoint Services Search Service Settings page, under Service Account, type the new account information in the User name and Password boxes.
Windows SharePoint Services Search content access account | Used by the Windows SharePoint Services Search application server role to crawl Help content across sites. | This account is automatically configured during installation. To change it after installation, go to the Central Administration Web site, and then click Operations. On the Operations page, under Topology and Services, click Services on server. On the Services on Server page, under Service, click Windows SharePoint Services Search. On the Configure Windows SharePoint Services Search Service Settings page, under Content Access Account, type the new account information in the User name and Password boxes.

Application pool accounts

The following table describes the application pool account. Plan one application pool account for each application pool you plan to implement.

When Search Server 2008 is installed, two application pools are automatically created. One is for Central Administration, which uses the server farm account, and the other is for the search center Web application, or the SSP.

Account | Purpose | Location
Application Pool process account | Used to access content databases associated with the Web application. | Defined when you create the Web application and can be changed in Internet Information Server (IIS).

Standard account requirements

This section provides the requirements for each of the accounts in both single-server (Basic installation) and multiple-server (Advanced installation) deployments. Listed in the requirements are permissions you might need to grant prior to installation. In some cases, additional permissions that are automatically granted during installation are noted.

Note Note:

This article does not include account requirements for environments that use SQL authentication.

Server farm-level accounts

The following table describes the standard account requirements for server farm-level accounts.

Account Single server requirements Server farm requirements

SQL Server service account

  • Local system account (default)

  • Database system administrator

Setup user account

  • Member of the Administrators group on the local computer

  • Domain user account

  • Member of the Administrators group on each server on which Search Server 2008 is installed.

  • Member of the following SQL Server security roles:

    • Logins

    • Securityadmin

    • Dbcreator

Server farm account

  • Network Service (default)

  • No manual configuration is necessary

  • Domain user account

  • Additional permissions are automatically granted for this account when Search Server 2008 is installed and when additional computers are added to the farm, including additional permissions on Web front-end servers (WFE) and application servers

  • This account is automatically added to the following SQL Server security roles:

    • Logins

    • Dbcreator

    • Securityadmin

    • Database owner (db_owner) for all databases

SSP accounts

The following table describes the standard account requirements for SSP accounts.

Account Single server requirements Server farm requirements

SSP service account

  • No manual configuration is necessary.

No manual configuration is necessary.

The following permissions are automatically granted for this account when Search Server 2008 is installed:

  • Database owner for the SSP content database

  • Read/write to the SSP content database

  • Read/write to content databases for Web applications that are associated with the SSP

  • Read from the configuration database

  • Read from the Central Administration content database

  • Additional permissions on WFEs and application servers

Office SharePoint Server Search account

  • By default, this account runs as the local service account

  • To crawl remote content by using crawl rules, change this account to a domain account, so that you can change the default content access account

  • Must be a domain account

  • Should not be a member of the Farm Administrators group

Permissions are automatically granted for this account when Search Server 2008 is installed:

  • Read/write to content databases for Web applications

  • Read from the configuration database

  • Read/write to the Windows SharePoint Services Search database

Default content access account

  • No manual configuration is necessary for this account to crawl local content

  • To crawl remote content, change the account to a domain account, use a crawl rule, and apply the requirements described for a server farm

  • Must be a domain account

  • Should not be a member of the Farm Administrators group

  • Read access to external or secure content sources that you want to crawl by using this account

Additional permissions for this account are automatically granted when Search Server 2008 is installed.

Content access account

  • No manual configuration is necessary for this account to crawl local content

  • To crawl remote content, change the account to a domain account, use a crawl rule, and apply the requirements described for a server farm

  • Read access to external or secure content sources that you want to crawl by using this account

  • Full read access to external SharePoint sites

Windows SharePoint Services Search accounts

The following table describes the standard account requirements for Windows SharePoint Services Search accounts. In Search Server 2008 these accounts are used only to search and index the Help contents.

Account Single server requirements Server farm requirements

Windows SharePoint Services Search service account

  • By default, this account runs as the local service account.

  • Must be a domain account

  • Need not be a member of the Farm Administrators group

Permissions are automatically granted for this account when Search Server 2008 is installed:

  • Read/write to content databases for Web applications

  • Read from the configuration database

  • Read/write to the Windows SharePoint Services Search database

Windows SharePoint Services Search Content access account

  • Should not be a member of the Farm Administrators group

  • Read access to Web applications

  • Same requirements as the Windows SharePoint Services Search service account

  • Read access to Web applications

Permissions are automatically granted for this account when Search Server 2008 is installed:

  • Added to the Web application Full Read policy for your farm

Application pool accounts

The following table describes the standard account requirements for application pool accounts.

Account Single server requirements Server farm requirements

Application pool process account

  • No manual configuration is necessary.

No manual configuration is necessary.

The following SQL Server roles and permissions are automatically assigned to this account:

  • Database owner role for content databases associated with the Web application

  • Read/write access to the associated SSP database

  • Read from the configuration database

Additional permissions for this account on WFEs and application servers are automatically granted by Search Server 2008.

Planning recommendations for accounts

This section describes practical planning recommendations suitable for implementing accounts in most environments in the following two deployment scenarios:

  • Secure farm environment

  • Single-server environment

Secure farm environment

These planning recommendations are for individual accounts in a secure farm environment.

Server farm-level accounts

The following table describes the planning recommendations for server farm-level accounts in a secure farm environment.

Account Recommendation

SQL Server service account

  • A domain account is recommended rather than a SQL Server account or a local account. To do this, you might need to set up a valid Service Principal Name (SPN) in Active Directory Domain Services for the domain user account

  • Do not use the server farm account for this account

Setup user account

  • A domain account is recommended

  • For a workgroup environment, this can be a local Windows account

Server farm account

  • A domain account is recommended

SSP accounts

The following table describes the planning recommendations for SSP accounts in a secure farm environment.

Account Recommendation

SSP service account

  • The default account for services is used by default

  • After completing installation, change this account to a domain account

Office SharePoint Server Search account

  • The default account for services is used by default

  • After completing installation, change this account to a domain account

Default content access account

  • By default, the Network Service account is used. After completing installation, change this account to a domain account

  • Do not give the default content access account access to the directory service

Windows SharePoint Services Search accounts

The following table describes the planning recommendations for Windows SharePoint Services Search accounts in a secure farm environment. In Search Server 2008 these accounts are used to crawl and index Help.

Account Recommendation

Windows SharePoint Services Search service account

  • The local service account is used by default.

  • After completing installation, change this account to a domain account.

Windows SharePoint Services Search content access account

  • The local service account is used by default.

Application pool accounts

The following table describes the planning recommendations for application pool accounts in a secure farm environment.

Account Recommendation

Application pool process account

  • Plan a unique domain account for each application pool.

  • Select a unique user account that does not have administrative rights on your front-end servers or on your back-end database servers.

Single-server environment

The following table describes the planning recommendations for using Search Server 2008 in single-server environments. A single-server environment is one where one server hosts all server roles.

Scenario Recommendation

Search Server 2008 Express

Note Note:

This information applies only to Search Server 2008 Express.

  • Use the standard administrator account to run the installation.

  • Use the default accounts assigned by the installation.

  • Assign to the Network Service account the necessary permissions to SQL Server.

SQL Server in a domain environment

  • Use the recommendations provided for a secure farm environment.

SQL Server in a workgroup environment

  • Use the recommendations provided for a secure farm environment, except use Windows accounts instead of domain accounts.


Plan to crawl content (Search Server 2008)
DropDown image

Updated: 2008-09-19

In this article:

  • About crawling and indexing content

  • Identify the sources of content that you want to crawl

  • Plan content sources

  • Plan for authentication

  • Plan protocol handlers

  • Plan to manage the impact of crawling

  • Plan crawl rules

  • Plan search settings that are managed at the farm level

  • Indexing content in different languages

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

The purpose of this article is to help search services administrators plan to crawl content by helping them understand how Microsoft Search Server 2008 crawls and indexes content. For more information, see Add or remove a search services administrator (Search Server 2008).

Before end users can take advantage of the enterprise search functionality in Search Server 2008, the content that they will run queries against must first be crawled.

For the purpose of this article, content is an item that can be crawled, such as a Web page, a Microsoft Office Word document, or an e-mail message file.

When planning to crawl content, consider the following questions:

  • Where is the content physically located?

  • Is the content stored in different sources, such as file shares, SharePoint sites, Web sites, or other places?

  • Do you want to crawl all of the content stored at the source or a portion of it?

  • What types of files do you want to crawl?

  • When and how often will you crawl content?

  • How is the content secured?

Use the information in this article to help you answer these questions and make the necessary planning decisions about the content you want to crawl and how and when you want to crawl that content.

About crawling and indexing content

Crawling and indexing content is the process by which the system accesses and parses content and its properties, sometimes called metadata, to build a content index from which search queries can be served.

The result of successfully crawling content is that the individual files or pieces of content are accessed and read by the crawler. The keywords and metadata for those files are stored in the content index, sometimes called the index. The index consists of the keywords that are stored in the file system of the index server and the metadata that is stored in the search database. The system maintains a mapping between the keywords, the metadata, and the URL of the source from which the content was crawled.

The search service is associated with the Shared Services Provider (SSP) and is assigned a specific server to index content. Unlike the server products in the 2007 Office release, which can have multiple SSPs and therefore more than one content index, Search Server 2008 is limited to one SSP and therefore, has only one content index.

Note Note:

The crawler does not change the files on the host servers. Instead, the crawler accesses and reads the files, and then sends the text and metadata to the index server. Some host servers change the date on the files after the crawler accesses them. The crawler does not do this.

Identify the sources of content that you want to crawl

In many cases, the needs of your organization might only require that you crawl all the content contained by the SharePoint sites in your server farm. In this case, you might not need to identify the sources of content you want to crawl because all site collections in a server farm can be crawled by using the default content source. For more information about the default content source, see Plan content sources later in this article.

Many organizations also need to crawl content that is external from the server farm, such as file shares or Web sites on the Internet. Search Server 2008 can crawl and index content that is hosted on other Windows SharePoint Services farms, Web sites, file shares, Microsoft Exchange public folders, and IBM Lotus Notes servers. This greatly increases the amount of content that is available to search queries.

In many cases, however, you might not want to crawl every site collection in your server farm, because content stored in some site collections might not be relevant in search results. In this case, you must do one or both of the following:

  • Note the URLs of the site collections that you do not want to crawl. If you decide to use the default content source, you must ensure that the start addresses for the site collections that you do not want to crawl are not listed in the default content source.

  • Note the start addresses of the site collections that you do want to crawl. If you decide to create additional content sources to use to crawl this content, you need to know these start addresses. Information about when to use one or more content sources is provided in the Plan content sources section of this article.

Tip Tip:

With Search Server, there are two ways to process search queries in order to return search results to users. You can query the Search Server content index, or you can use federated search. There are advantages to each approach. For a comparison of these two approaches to processing search queries, see Federated Search Overview (http://go.microsoft.com/fwlink/?LinkID=122651). For a list and brief description of Search Server articles about understanding and using federation, see Working with federation (Search Server 2008).

Plan content sources

Before you can crawl content, you must determine where the content is located and on what types of servers the content is hosted. After this information is gathered, a search services administrator can create one or more content sources. These content sources provide the following information to the crawler:

  • The type of content to crawl — for example, a SharePoint site or a file share.

  • The start address from which to start crawling.

  • What type of behavior to use when crawling — for example, how deep to crawl from the start address, or how many server hops to allow.

  • How frequently to crawl.

Note Note:

Crawling content by using a particular content source is sometimes called "crawling the content source."

This section helps you plan for the content sources needed by your organization.

The default content source is called Local Office SharePoint Server sites. Search services administrators can use this content source to crawl and index all content in the server farm. By default, Search Server 2008 adds the start address (in this case a URL) of the top-level site of each site collection in the farm to the default content source.

For some organizations, simply using the default content source to crawl all sites in their site collections satisfies their search requirements. However, many organizations need additional content sources.

Reasons for creating additional content sources include the need to:

  • Crawl different types of content.

  • Crawl some content on different schedules than other content.

  • Limit or increase the quantity of content that is crawled.

Search services administrators can create up to 500 content sources and each content source can contain up to 500 start addresses. To keep administration as simple as possible, you should create only as many content sources as you need.

Crawl different types of content

You can only crawl one type of content per content source. That is, you can create a content source that contains URLs for SharePoint sites and another that contains URLs for file shares, but you cannot create a single content source that contains URLs to both SharePoint sites and file shares. The following table lists the types of content sources that can be configured.

This type of content source Includes this type of content

SharePoint sites

SharePoint sites from the same farm or different Office SharePoint Server 2007, Windows SharePoint Services 3.0, or Search Server 2008 farms

  • SharePoint sites from Microsoft Office SharePoint Portal Server 2003 or Windows SharePoint Services 2.0

    Note Note:

    Unlike crawling SharePoint sites on Office SharePoint Server 2007, Windows SharePoint Services 3.0, or Search Server 2008, the crawler cannot automatically crawl all subsites in a site collection from previous versions of SharePoint Products and Technologies. Therefore, when crawling SharePoint sites from previous versions, you must specify the URL of each top-level site and each subsite that you want to crawl.

    Sites listed in the Site Directory of Microsoft Office SharePoint Portal Server 2003 farms are crawled when the portal site is crawled. For more information about the Site Directory, see About the Site Directory (http://go.microsoft.com/fwlink/?LinkId=88227&clcid=0x409).

Web sites

  • Other Web content in your organization not found in SharePoint sites

  • Content on Web sites on the Internet

File shares

Content on file shares within your organization

Lotus Notes

E-mail messages stored in Lotus Notes databases

Note Note:

Unlike all other types of content sources, the Lotus Notes content source option does not appear in the user interface until you have installed and configured the appropriate prerequisite software. For more information, see Configure Search Server to crawl Lotus Notes (Search Server 2008).

Exchange public folders

Exchange Server content

Crawl content on different schedules

Search services administrators often must decide whether some content is crawled more frequently than other content. The larger the volume of content that you crawl, the more likely it is that you are crawling content from different sources. These different sources might or might not be of the same type and might be hosted on servers of varying speeds in relation to one another.

These factors make it more likely that you need additional content sources to crawl those different sources of content at different times.

Primary reasons that content is crawled on different schedules are:

  • To accommodate downtimes and periods of peak usage.

  • To more frequently crawl the content that is updated more frequently.

  • To crawl content hosted on slower host servers separately from content crawled on faster host servers.

In many cases, not all of this information can be known until after Search Server 2008 is deployed and running for some time. Instead, some of these decisions are made during the operations phase. However, it is a good idea to consider these factors during planning so that you can plan your crawl schedules based on the information at hand.

The following two sections provide more information about crawling content on different schedules.

Downtimes and periods of peak usage

Consider the downtimes and peak usage times of the servers that host the content you want to crawl. For example, if you are crawling content hosted by many different servers outside your server farm, it is likely that these servers are backed up on different schedules and have different peak usage times. The administration of servers outside your server farm is typically out of your control. Therefore, we recommend that you coordinate your crawls with the administrators of the servers that host the content you want to crawl to ensure you do not attempt to crawl content on their servers during a downtime or peak usage time.

A common scenario involves content outside the control of your organization that relates to the content on your SharePoint sites. You can add the start addresses for this content to an existing content source or create a new content source for external content. Because availability of external sites varies widely, it is helpful to add separate content sources for different external content. In this way, the content sources for external content can be crawled at different times than your other content sources. You can then update external content on a crawl schedule that accounts for the availability of each site.

Content that is updated frequently

When planning crawl schedules, consider that some sources of content are typically updated more frequently than others. For example, if you know that content on some site collections or external sources are updated only on Fridays, it would be a waste of resources to crawl that content more frequently than once each week. However, your server farm might contain other site collections that are continually updated Monday through Friday, but not typically updated on Saturdays and Sundays. In this case, that you might want to crawl several times each week day, but only once or twice on weekends.

The way in which content is stored across the site collections in your environment can guide you to create additional content sources for each of your site collections in each of your Web applications. For example, if a site collection stores only archived information, you may not need to crawl that content as frequently as you crawl a site collection that stores frequently updated content. In this case, you might want to crawl these two site collections using different content sources so that they can be crawled on different schedules without having to crawl the archive sites as frequently as the other content.

Full and incremental crawl schedules

Search services administrators can configure the crawl schedules independently for each content source. For each content source, they can specify a time to do full crawls and a separate time to do incremental crawls. Note that you must run a full crawl for a particular content source before you can run an incremental crawl. If you choose an incremental crawl for content that has not yet been crawled, the system performs a full crawl.

We recommend that you plan crawl schedules based on the availability, performance, and bandwidth considerations of the servers running the search service and the servers hosting the crawled content.

When you plan crawl schedules, consider the following best practices:

  • Group start addresses in content sources based on similar availability and with acceptable overall resource usage for the servers that host the content.

  • Schedule incremental crawls for each content source during times when the servers that host the content are available and when there is low demand on the resources of the server.

  • Stagger crawl schedules so that the load on the servers in your farm is distributed over time.

  • Schedule full crawls only when necessary for the reasons listed in the next section. We recommend that you schedule full crawls less frequently than incremental crawls.

  • Schedule administration changes that require a full crawl to occur shortly before the planned schedule for full crawls. For example, we recommend that you attempt to schedule the creation of the crawl rule before the next scheduled full crawl so that an additional full crawl is not necessary.

  • Base simultaneous crawls on the capacity of the index server to crawl them. We recommend that you typically stagger your crawl schedules so that the index server does not crawl using multiple content sources at the same time. For best performance, we suggest that you stagger the crawling schedules of content sources. The performance of the index server and the servers hosting the content determines the extent to which crawls can be overlapped. A strategy for crawl scheduling can be developed over time as you can become familiar with the typical crawl durations for each content source.

Reasons to do a full crawl

Reasons for a search services administrator to do a full crawl include:

  • One or more hotfix or service pack was installed on servers in the farm. See the instructions for the hotfix or service pack for more information.

  • A search services administrator added a new managed property.

  • To re-index ASPX pages on Windows SharePoint Services 3.0 sites.

    Note Note:

    The crawler cannot discover when ASPX pages on Windows SharePoint Services 3.0 sites have changed. Because of this, incremental crawls do not re-index views or home pages when individual list items are deleted. We recommend that you periodically do full crawls of sites that contain ASPX files to ensure that these pages are re-indexed.

  • To detect security changes that were made on a file share after the last full crawl of the file share.

  • To resolve consecutive incremental crawl failures. In rare cases, if an incremental crawl fails one hundred consecutive times at any level in a repository, the index server removes the affected content from the index.

  • Crawl rules have been added, deleted, or modified.

  • To repair a corrupted index.

  • The search services administrator has created one or more server name mappings.

  • The account assigned to the default content access account or crawl rule has changed.

The system does a full crawl even when an incremental crawl is requested under the following circumstances:

  • A search services administrator stopped the previous crawl.

  • A content database was restored.

    Note Note:

    If you are running the Infrastructure Update for Microsoft Office Servers, you can use the restore operation of the Stsadm command-line tool to change whether a content database restore causes a full crawl.

  • A farm administrator has detached and reattached a content database.

  • A full crawl of the site has never been done.

  • The change log does not contain entries for the addresses that are being crawled. Without entries in the change log for the items being crawled, incremental crawls cannot occur.

  • The account assigned to the default content access account or crawl rule has changed.

  • To repair a corrupted index.

    Depending on the severity of the corruption, the system might attempt to perform a full crawl if corruption is detected in the index.

You can adjust schedules after the initial deployment based on the performance and capacity of servers in the farm and the servers hosting content.

Limit or increase the quantity of content that is crawled

For each content source, you can select how extensively to crawl the start addresses in that content source. You also specify the behavior of the crawl, sometimes called the crawl settings. The options you can choose for a particular content source vary somewhat based on the content source type that you select. However, most options determine how many levels deep in the hierarchy from each start address listed in the content source are crawled. Note that this behavior is applied to all start addresses in a particular content source. If you need to crawl some sites at deeper levels, you can create additional content sources that encompass those sites.

The options available in the properties for each content source vary depending on the content source type that is selected. The following table describes the crawl settings options for each content source type.

Content source type Crawl settings options

SharePoint sites

  • Everything under the host name for each start address

  • Only the SharePoint site of each start address

Web sites

  • Only within the server of each start address

  • Only the first page of each start address

  • Custom — Specify page depth and number of server hops

    Note Note:

    The default setting for this option is unlimited page depths and server hops.

File shares

  • The folder and all subfolders of each start address

  • Only the folder of each start address

Exchange public folders

  • The folder and all subfolders of each start address

  • Only the folder of each start address

As the preceding table shows, search services administrators can use crawl setting options to limit or increase the quantity of content that is crawled.

The following table describes best practices when configuring crawl setting options.

For this content source type If this pertains Use this crawl setting option

SharePoint sites

You want to include the content on the site itself

-or-

You do not want to include the content available on subsites, or you want to crawl them on a different schedule

Crawl only the SharePoint site of each start address

SharePoint sites

You want to include the content on the site itself

-or-

You want to crawl all content under the start address on the same schedule

Crawl everything under the host name of each start address

Web sites

Content on the site itself is relevant

-or-

Content available on linked sites is not likely to be relevant

Crawl only within the server of each start address

Web sites

Relevant content is on only the first page

Crawl only the first page of each start address

Web sites

You want to limit how deep to crawl the links on the start addresses

Custom — Specify the number of pages deep and number of server hops to crawl

Note Note:

We recommend that you start with a small number on a highly connected site because specifying more than three pages deep or more than three server hops can crawl the entire Internet.

File shares

Exchange public folders

Content available in the subfolders is not likely to be relevant

Crawl only the folder of each start address

File shares

Exchange public folders

Content in the subfolders is likely to be relevant

Crawl the folder and subfolder of each start address

Plan file-type inclusions and IFilters

Content is only crawled if the relevant file name extension is included in the file-type inclusions list and an IFilter is installed on the index server that supports those file types. Several file types are included automatically during initial installation. When you plan for content sources in your initial deployment, determine whether content you want to crawl uses file types that are not included. If file types are not included, you must add those file types on the Manage File Types page during deployment and ensure that an IFilter is installed and registered to support that file type.

Search Server 2008 provides several IFilters, and more are available from Microsoft and third-party vendors. For more information about how to install and register additional IFilters that are available from Microsoft, see How to register Microsoft Filter Pack with SharePoint Server 2007 and with Search Server 2008. If necessary, software developers can create IFilters for new file types.

On the other hand, if you want to exclude certain file types from being crawled, you can delete the file name extension for that file type from the file type inclusions list. Doing so excludes file names that have that extension from being crawled.

The following table lists which file types are supported by the IFilters that are installed by default and which file types are enabled on the Manage File Types page by default.

File name extension | Default IFilter support | Default file type inclusions
ascx | Yes | Yes
asm | Yes | No
asp | Yes | Yes
aspx | Yes | Yes
bat | Yes | No
c | Yes | No
cmd | Yes | No
cpp | Yes | No
css | Yes | No
cxx | Yes | No
def | Yes | No
dic | Yes | No
doc | Yes | Yes
docm | Yes | Yes
docx | Yes | Yes
dot | Yes | Yes
eml | Yes | Yes
exch | No | Yes
h | Yes | No
hhc | Yes | No
hht | Yes | No
hpp | Yes | No
hta | Yes | No
htm | Yes | Yes
html | Yes | Yes
htw | Yes | No
htx | Yes | No
jhtml | No | Yes
jsp | No | Yes
lnk | Yes | No
mht | Yes | Yes
mhtml | Yes | Yes
mpx | Yes | No
msg | Yes | Yes
mspx | No | Yes
nsf | No | Yes
odc | Yes | Yes
one | No | No
php | No | Yes
pot | Yes | No
pps | Yes | No
ppt | Yes | Yes
pptm | Yes | Yes
pptx | Yes | Yes
pub | Yes | Yes
stm | Yes | No
tif | Yes | Yes
tiff | No | Yes
trf | Yes | No
txt | Yes | Yes
url | No | Yes
vdx | No | Yes
vsd | No | Yes
vss | No | Yes
vst | No | Yes
vsx | No | Yes
vtx | No | Yes
xlb | Yes | No
xlc | Yes | No
xls | Yes | Yes
xlsm | Yes | Yes
xlsx | Yes | Yes
xlt | Yes | No
xml | Yes | Yes

IFilters and Microsoft Office OneNote

An IFilter is not provided for the .one file name extension used by Microsoft Office OneNote. If you want users to be able to search content in Office OneNote files, you must install an IFilter for OneNote. To do this, you must do one of the following:

  • Install the Microsoft Office OneNote 2007 client application on the index server.

    The IFilter provided by Office OneNote 2007 can be used to crawl both Office OneNote 2003 and Office OneNote 2007 files. The IFilter installed by Office OneNote 2003 can crawl Office OneNote 2003 files only.

  • Install and register the Microsoft Filter Pack.

    The OneNote IFilter provided by this filter pack can be used to crawl Office OneNote 2007 files only. For more information, see How to register Microsoft Filter Pack with SharePoint Server 2007 and with Search Server 2008.

Limit or exclude content by using crawl rules

When you add a start address to a content source and accept the default behavior, all subsites or folders below that start address are crawled unless you exclude them by using one or more crawl rules.

For more information about crawl rules, see Plan crawl rules later in this article.

Other considerations when planning content sources

You cannot crawl the same addresses using multiple content sources. For example, if you use a particular content source to crawl a site collection and all of its subsites, you cannot use a different content source to crawl one of those subsites separately on a different schedule. To accommodate this restriction, you might need to crawl some of these sites separately. Consider the following scenario:

An administrator at Contoso wants to crawl http://contoso, which contains the subsites http://contoso/sites/site1 and http://contoso/sites/site2. The administrator wants to crawl http://contoso/sites/site2 on a different schedule than the other sites. To achieve this, the administrator adds the addresses http://contoso and http://contoso/sites/site1 to one content source and selects the setting called Crawl only the SharePoint site of each start address. The subsite http://contoso/sites/site2 is then added to a separate content source with a different crawl schedule.

In addition to crawl schedules, there are other things to consider when planning content sources. For example, whether you group start addresses in a single content source or create additional content sources to crawl those start addresses depends largely on administration considerations. Administrators often make changes that require a full update of a particular content source. Changes to a content source require a full crawl of that content source. To make administration easier, organize content sources in such a way that updating content sources, crawl rules, and crawling content is convenient for administrators.

Content sources summary

Consider the following when planning your content sources:

  • A particular content source can be used to crawl only one of the following content types: SharePoint sites, Web sites that are not SharePoint sites, file shares, Exchange public folders, and Lotus Notes databases.

  • Search services administrators can create up to 500 content sources, and each content source can contain up to 500 start addresses. To keep administration as simple as possible, create only as many content sources as you absolutely need.

  • Each URL in a particular content source must be of the same content source type.

  • For a particular content source, you can choose how deep to crawl from the start addresses. These configuration settings apply to all start addresses in the content source. The available choices on how deep you can crawl the start addresses differ depending on the content source type that is selected.

  • You can schedule when to perform either a full or incremental crawl for the entire content source. For more information about scheduling crawls, see Plan crawl rules later in this article.

  • Search services administrators can modify the default content source, create additional content sources for crawling other content, or both. For example, they can configure the default content source to also crawl content on a different server farm or they can create a new content source to crawl other content.

  • To effectively crawl all the content needed by your organization, use as many content sources as make sense for the types of sources you want to crawl, and for the frequency at which you plan to crawl them.

Plan for authentication

When the crawler accesses the start addresses that are listed in content sources, the crawler must be authenticated by and granted access to the servers that host that content. This means that the domain account used by the crawler must have at least read permission to the content.

The default content access account is the account that is used by default when crawling content sources. This account is specified by the search services administrator. Alternatively, you can use crawl rules to specify a different content access account to use when crawling particular content. Regardless of whether you use the default content access account or a different content access account specified by a crawl rule, the content access account that you use must have read access to all content that is crawled, or the content is not crawled and is not available to queries.

We recommend that you select a default content access account that has the broadest access to most of your crawled content, and only use other content access accounts when security considerations require separate content access accounts. For information about creating a separate content access accounts to crawl content that cannot be read using the default content access account, see Plan crawl rules later in this article.

For each content source you plan, identify the start addresses that cannot be accessed by the default content access account and plan to add crawl rules for URL patterns that encompass those start addresses.

Note Note:

Ensure that the domain account used for the default content access account or any other content access account is not the same domain account that is used by an application pool associated with any Web application you crawl. Doing so can cause unpublished content in SharePoint sites and minor versions of files (history) in SharePoint sites to be crawled and indexed.

For more information about the planning considerations for content access accounts, see Plan crawl rules later in this article.

Another important consideration is that the crawler must use the same authentication method as the host server. By default, the crawler attempts to authenticate using NTLM authentication. You can configure the crawler to use a different authentication method, if necessary. For more information, see "Authentication requirements for crawling content" in Plan authentication methods (Office SharePoint Server). This article also pertains to Search Server 2008.

Plan protocol handlers

All content that is crawled requires the use of a protocol handler to gain access to that content. Search Server 2008 provides protocol handlers for all common Internet protocols. However, if you want to crawl content that requires a protocol handler that is not installed with Search Server 2008, you must install the third-party or custom protocol handler before you can crawl that content.

The following table shows the protocol handlers that are installed by default.

Protocol handler | Used to crawl
File | File shares
http | Web sites
https | Web sites over Secure Sockets Layer (SSL)
Notes | Lotus Notes databases
Rb | Exchange public folders
Rbs | Exchange public folders over SSL
Sps | People profiles from Windows SharePoint Services 2.0 server farms
Sps3 | People profile crawls of Windows SharePoint Services 3.0 server farms only
Sps3s | People profile crawls from Windows SharePoint Services 3.0 server farms only over SSL
Spsimport | People profile import
Spss | People profile import from Windows SharePoint Services 2.0 server farms over SSL
Sts | Windows SharePoint Services 3.0 root URLs (internal protocol)
Sts2 | Windows SharePoint Services 2.0 sites
Sts2s | Windows SharePoint Services 2.0 sites over SSL
Sts3 | Windows SharePoint Services 3.0 sites
Sts3s | Windows SharePoint Services 3.0 sites over SSL

Plan to manage the impact of crawling

Crawling content can significantly decrease the performance of the servers that host the content. The impact that this has on a particular server varies depending on the load that the host server is experiencing and whether the server has sufficient resources (particularly CPU and RAM) to maintain service level agreements under normal or peak usage.

Crawler impact rules enable farm administrators to manage the impact your crawler has on the servers being crawled. For each crawler impact rule, you can specify a single URL or use wildcard characters in the URL path to include a block of URLs to which the rule applies. You can then specify how many simultaneous requests for pages are made to the specified URL or choose to request only one document at a time and wait a number of seconds that you choose between requests.

Crawler impact rules reduce or increase the rate at which the crawler requests content from a particular start address or range of start addresses (sometimes called a site name), regardless of the content source used to crawl those addresses. The following table shows the wildcard characters that you can use in the site name when adding a rule.

Wildcard to use | Result
* as the site name | Applies the rule to all sites.
*.* as the site name | Applies the rule to sites with dots in the name.
*.site_name.com as the site name | Applies the rule to all sites in the site_name.com domain (for example, *.adventure-works.com).
*.top-level_domain_name as the site name | Applies the rule to all sites that end with a specific top-level domain name, for example, *.com or *.net.
? | Replaces a single character in a rule. For example, *.adventure-works?.com applies to all sites in the domains adventure-works1.com, adventure-works2.com, and so on.

You can create a crawler impact rule that applies to all sites within a particular top-level domain. For example, *.com applies to all Internet sites with addresses that end in .com. For example, an administrator of a portal site might add a content source for example.microsoft.com. The rule for *.com applies to this site unless you add a crawler impact rule specifically for example.microsoft.com.

For content within your organization that other administrators are crawling, you can coordinate with those administrators to set crawler impact rules based on the performance and capacity of the servers. For most external sites, this coordination is not possible. Requesting too much content on external servers or making requests too frequently can cause administrators of those sites to limit your future access if your crawls are using too many resources or too much bandwidth. Therefore, the best practice is to crawl more slowly. In this way, you can mitigate the risk of losing access to crawl the relevant content.

During initial deployment, set the crawler impact rules to make as small an impact on other servers as possible while still crawling enough content frequently enough to ensure the freshness of the crawled content.

During the operations phase, you can adjust crawler impact rules based on your experiences and data from crawl logs.

Plan crawl rules

Crawl rules apply to a particular URL or set of URLs represented by wildcards (also referred to as the path affected by the rule). You use crawl rules to do the following things:

  • Avoid crawling irrelevant content by excluding one or more URLs. This also helps to reduce the use of server resources and network traffic, and to increase the relevance of search results.

  • Crawl links on the URL without crawling the URL itself. This option is useful for sites with links of relevant content when the page containing the links does not contain relevant information.

  • Enable complex URLs to be crawled. This option crawls URLs that contain a query parameter specified with a question mark. Depending on the site, these URLs might or might not include relevant content. Because complex URLs can often redirect to irrelevant sites, it is a good idea to enable this option on only sites where the content available from complex URLs is known to be relevant.

  • Enable content on SharePoint sites to be crawled as HTTP pages. This option enables the index server to crawl SharePoint sites that are behind a firewall or in scenarios in which the site being crawled restricts access to the Web service used by the crawler.

  • Specify whether to use the default content access account, a different content access account, or a client certificate for crawling the specified URL.

Note Note:

Crawl rules apply simultaneously to all content sources.

Often, most of the content for a particular site address is relevant, but not a specific subsite or range of sites below that site address. By selecting a focused combination of URLs for which to create crawl rules that exclude unneeded items, search services administrators can maximize the relevance of the content in the index while minimizing the impact on crawling performance and the size of search databases. Creating crawl rules to exclude URLs is particularly useful when planning start addresses for external content, the impact on resource usage of which is not under the control of people in your organization.

When creating a crawl rule, you can use standard wildcard characters in the path. For example:

  • http://server1/folder* contains all Web resources with a URL that starts with http://server1/folder.

  • *://*.txt includes every document with the .txt file name extension.

Because crawling content consumes resources and bandwidth, it is better to include a smaller amount of content that you know is relevant than a larger amount of content that might be irrelevant. After the initial deployment, you can review the query and crawl logs and adjust content sources and crawl rules to be more relevant and include more content.

Specify a different content access account

For crawl rules that include content, administrators have the option of changing the content access account for the rule. The default content access account is used unless another account is specified in a crawl rule. The main reason to use a different content access account for a crawl rule is that the default content access account does not have access to all start addresses. For those start addresses, you can create a crawl rule and specify an account that does have access.

Note Note:

Ensure that the domain account used for the default content access account or any other content access account is not the same domain account that is used by an application pool associated with any Web application you crawl. Doing so can cause unpublished content in SharePoint sites and minor versions of files (history) in SharePoint sites to be crawled and indexed.

Plan search settings that are managed at the farm level

In addition to the settings that are configured at the Search Administration level, several settings that are managed at the farm level affect how content is crawled. Consider the following farm-level search settings while planning for crawling:

Contact e-mail address Crawling content affects the resources of the servers that are being crawled. Before you can crawl content, you must provide in the configuration settings the e-mail address of the person in your organization whom administrators can contact in the event that the crawl adversely affects their servers. This e-mail address appears in logs for administrators of the servers being crawled so that those administrators can contact someone if the impact of crawling on their performance and bandwidth is too great, or if other issues occur.

The contact e-mail address should belong to a person who has the necessary expertise and availability to respond quickly to requests. Alternatively, you can use a closely monitored distribution-list alias as the contact e-mail address. Regardless of whether the content crawled is stored internally to the organization or not, quick response time is important.

Proxy server settings You can choose whether to use a proxy server when crawling content. The proxy server to use depends on the topology of your Search Server 2008 deployment and the architecture of other servers in your organization.

  • Time-out settings The time-out settings are used to limit the time that the search server waits while connecting to other services.

  • SSL setting The Secure Sockets Layer (SSL) setting determines whether the SSL certificate must exactly match to crawl content.

Indexing content in different languages

When crawling content, the crawler determines each individual word in the content it finds. Languages that have words separated by spaces make it relatively easy for the crawler to distinguish each word. In other languages, finding the boundary between words can be more complex.

Search Server 2008 provides word breakers and stemmers by default to help crawl and index content in many languages. Word breakers find word boundaries in full-text indexed data, while stemmers conjugate verbs.

If you are crawling any of the languages listed in the following table, Search Server 2008 automatically uses the appropriate word breaker and stemmer for that language. An asterisk (*) indicates that the stemming feature is on by default.

Language supported by default | Language supported by default
Arabic | Lithuanian*
Bengali | Malay
Bulgarian* | Malayalam*
Catalan | Marathi
Croatian | Norwegian_Bokmaal
Czech* | Polish*
Danish | Portuguese
Dutch | Portuguese_Brazilian
English | Punjabi
Finnish* | Romanian*
French* | Russian*
German* | Serbian_Cyrillic*
Greek* | Serbian_Latin*
Gujarati | Slovak*
Hebrew | Slovenian*
Hindi | Spanish*
Hungarian* | Swedish
Icelandic* | Tamil*
Indonesian | Telugu*
Italian | Thai
Japanese | Turkish*
Kannada* | Ukrainian*
Korean | Urdu*
Latvian* | Vietnamese

When the crawler indexes content for a language that is not supported, the neutral breaker is used. If the neutral breaker does not give you the results you expect, you can try third-party solutions that work with Search Server 2008.

See Also

Concepts

Working with federation (Search Server 2008)


Plan the end-user search experience (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this section:

  • Plan what users see when performing a query

  • Plan what users see in search results

Search administrators can improve the relevance and presentation of search results by carefully planning the end-user search experience. The goal of the planning is to create a search experience that enables users to quickly find the information they need. This article contains information that can help search services administrators and site collection administrators optimize the end-user search experience.

The first section of this article:

  • Describes the search user interface for performing search queries.

  • Discusses advanced searches and how properties can be used to filter search results. Administrators can use this information to understand the options they have for managing keywords and properties to optimize users' ability to perform powerful advanced searches.

  • Discusses the benefit of using property searches with scopes. This includes how crawled properties relate to managed properties and how to plan for them.

The second section of this article discusses search results pages and the features that administrators can control that affect what users see in search results.

The second section of this article:

  • Describes how to plan for keywords and Best Bets. This includes how to plan for effective keywords, Best Bets for a particular organization and how associating synonyms with keywords can enhance the end-user experience.

  • Discusses how administrators can control the relevance ranking of particular sites to improve the relevance of search results.

  • Describes the new federated locations feature that can be used to search multiple sources and combine results into a single search results page.

  • Describes how to control the links that appear in search results.

  • Discusses how to plan for search-based alerts.

The abilities described in this article enable administrators to control many of the features of the end-user search experience. Although we recommend that you regularly evaluate the effectiveness of search queries, good planning prior to initial deployment can help create effective search queries from the start and may reduce future administration costs.

Plan what users see when performing a query

To effectively plan for the configuration choices that help you realize your goal of helping users find the content for which they are searching, it helps to first consider what end-users see in the user interface.

The search user interface

To understand how to plan the end-user search experience, it is helpful to first become familiar with the user interface that end users use when performing queries. As you might expect, this user interface is straightforward. The focal point of this user interface is a search box where users can enter search queries. A search box is provided on all non-administrative pages in the site collection and also in the Search Center. For example, the search box appears, by default, at the site and list levels as well as on the Search Center. The Search Center itself is a site collection.

The following sections describe the search user interface at each level of the site collection.

Site-level search user interface

Site-level search user interface

The site-level search box (callout 2) is a text box on the top-right corner of Web site pages in which users can enter their search queries and then click the Go Search icon (callout 3) to run their query.

The first thing you might expect users to ask when looking at a search box in a user interface is, "what body of content will my query be run against?" The Search Scope list (callout 1) next to the search box specifies the body of information in the content index that the query will be run against. Search scopes, also referred to as scopes, are filters that are applied to search results to narrow (that is, filter) the items that are displayed on the search page based on whether those items are included in the scope. This enables users to perform queries against subsets of content in the content index, which improves the relevance of their search results.

By default, the site-level search box uses the This Site scope. This means that queries are run against all content that is associated with the current site and all of its subsites.

List-level search user interface

The search user interface at the list level looks and functions the same as the site-level search user interface, except that an additional default search scope, called This List, is available. The list-level search box is at the top-right corner of each list and library in all site collections and is set to use the This List scope, by default. However, users can select the This Site scope or a custom scope, if available.

Search Center search user interface

The Search Center provides a centralized and highly customizable user interface where users can perform search queries. The Search Center consists of a search box for entering search queries, and a link to the Advanced Search page so users can construct advanced search queries. By default, the search box is set to the All Sites scope so users search across all content in the index.

Search Center in SharePoint Server 2007 for Search

Similar to the search box at the site-level, the search box in the Search Center (callout 1) is a text box in which users can type their search queries. Users then click the Go Search button (callout 2) to run their query. Advanced users can click the Advanced Search link (callout 3) to use the Advanced Search page to construct queries. Information about the Advanced Search page is provided later in this article.

If Microsoft Search Server 2008 was installed using the basic install option, the Search Center template is used to create the top-level Web site. This means that the top-level site of your site collection is the Search Center.

The following table shows the scopes that are available in Search Server 2008, by default, and the levels at which they are available.

This scope | Enables users to | At this level
All Sites | Search across all content in the index | Search Center Top-level site Subsite Lists and libraries
This Site: Site name | Search across the current site and all of its subsites | Top-level site Subsite Lists and libraries
This List: List name | Search across the current list | Lists and libraries

Plan custom scopes

This section provides information about the default scopes that can be used to filter the content included in a search query. As a search administrator, you can help identify when your organization might need to supplement the default scopes by creating custom scopes. You can use custom scopes with scope rules to group certain content in the index into individually searchable pieces of content.

For example, you can make it possible to search a specific set of Web sites, or all Word documents that were authored by a particular person or were authored during a period of time or a combination of these parameters.

You can create custom scopes at the site collection level, which makes the custom scopes available to the site collection on which they were created.

When planning search scopes, you look at your information architecture to identify broad content sets on which people are likely to search. Some of these sets will span across many sites, and some will span subsets of information within site collections.

Plan scopes for site collections

During planning, each site collection administrator will want to create scopes based on the information architecture within the site.

The following is a list of tasks related to scopes that site collection administrators can do at the site level:

  • Choose how to display search scopes (search dropdown, advanced search, or both).

  • Create site collection level scopes.

  • Edit site collection level scopes (more information provided below).

  • Add scope rules.

  • Delete site collection level scopes.

  • View the status. For example what scope rules they contain and the order in the scopes list in which they appear.

When creating or editing a new site-collection-level scope, you specify the following:

  • Unique title.

  • Description for the scope (optional).

  • Display group, sometimes called scope group. Site collection administrators can assign scopes to display groups to determine where they appear on the site. By default, Search Server 2008 provides display groups for the search box drop-down list and the Advanced Search page. Site collection administrators can assign one or more scopes to any display group or create new display groups.

  • Results page. You can choose to use the default search results page to display search results when this scope is used or specify a different page. Note that if you choose to use a different page, you must first create that search results page.

Plan display groups

Display groups provide a way to assign scopes to a particular search box. Site collection administrators have several options for configuring the existing display groups or they can choose to create one or more new display groups. Typically, a site owner identifies a particular need for a display group. For example, users of a particular team site might frequently need to search for content that is scattered across multiple document libraries. To narrow the body of content they are searching over, they currently have to either perform separate searches in different search boxes, for example, the search box of each library, or construct an advanced query to filter the search results. To provide users with an easier way to perform this frequent search, the site collection administrator creates a display group and assigns the appropriate scope to it. Site Owners can then associate this display group with a particular search box. For example, a search box on a custom search page on the site. Users then use that search box to search over the content defined by the scope, in this case, the document libraries. Search Server 2008 provides two display groups, by default:

  • Search Dropdown The All Sites scope is assigned to this display group and it is used by the search box, by default.

  • Advanced Search The All Sites scope is assigned to this display group and it is used by the search box on the Advanced Search page, by default.

Site collection administrators can perform the following actions:

  • Add scopes to any display group.

  • Remove scopes from any display group.

  • Create new display groups and assign the scopes they want to them.

  • Change the order in which scopes appear in the Search Scopes list.

  • Specify which scope is selected, by default, in the Search Scopes list.

Site Owners can perform the following

  • Assign different display groups to the search box and the Advanced Search page in the Search Center site.

  • Create new search pages using the Search Box and Advanced Search Box Web parts and assign the display group or groups that they want to use.

Plan scope rules

You define a scope by adding scope rules to the scope. Scope rules define what content to associate with the scope and what content to not associate with it. Scope rules added to a particular scope define the extent of the scope.

Each scope rule is based upon a particular scope rule type, which defines the properties, locations, and sources of content. The following table lists the scope rule types that are available to site-collection-level search scopes.

This scope rule type | Is available to site-collection-level search scopes | Tests content by
Web address (http://server/site) | Yes | Location
Property Query (Author=Jane Dow) | Yes | Single property
Content Source | No | A particular content source
All Content | Yes | All content in the content index

The All Content scope rule type is the simplest because it associates all crawled content with the scope. For each of the other three scope rule types, a search services administrator can specify the behavior of the scope rule which determines the content to associate with the scope. These behaviors are described in the following list:

  • Include Items matching this rule appear in search results unless another rule removes them. When combining rules, this behavior is similar to the OR logical operator.

  • Require Items matching other rules must also match this rule to appear in search results. This behavior is equivalent to the AND logical operator.

  • Exclude Items matching this rule are excluded from search results even if they match other rules. This behavior is equivalent to the AND NOT logical operator.

Scopes will often be based on a single scope rule. However, there are good reasons to use scopes with multiple rules. You can create scopes based around a specific theme or conceptually-related set of content. To do this, you can include and exclude several locations, properties, or a combination of locations and properties that are conceptually related. The logical combination of rules determines the content that is either included or excluded from the scope.

Using scope rules that are based on location

You can create rules based on the location (Web address or UNC path) of content using the Web Address scope rule type. Several usage scenarios require rules of this kind, including searching for content:

  • In a group of document libraries.

  • Within a set of folders in a single large document repository, for example, when searching a company archive.

  • On external sites for a particular subject.

  • On other servers in your organization.

Each Web address scope rule contains a single location, defined by a single folder, domain name, or server name. Depending on what set of content you want to make available in a scope, you add matching rules until all relevant locations are included in the scope and all irrelevant locations are excluded. Examine the information architecture and site structure planning to help you decide which locations to include in each scope.

Using scope rules that are based on managed properties

You can base scope rules on a specific value for a single managed property using the Property Query scope rule type. Before you create such a scope rule, verify that:

  • The managed property that you want to use exists, either because it is a default managed property or was created by a search services administrator.

  • The managed property is configured to be available for use in scopes. Several managed properties are created, but only a few are configured to be available for use in scopes, by default. Only managed properties that search services administrators have specifically made available for scopes can be used in search scopes.

    Note Note:

    Search services administrators can enable a property to be available for use in scopes by using the Edit Managed Property page for the particular property.

After the scope rule is created, each item of content that matches the property query is tested against that specific value and included or excluded based on the rule. Rules based on properties can only be queried by using the Is exactly operator and not against other operators such as Contains.

For example, a site collection administrator for a sales portal site can create scopes for each sales office by using the SalesOffice managed property and setting the value for the rule in each scope to the value for the relevant office. Because this managed property is used to define the scope, the search results will include only content for the sales office when using this scope.

When your organization plans managed properties, consider scopes. To create a scope for a certain set of content, you must ensure that there are properties of that content that are mapped to managed properties that can be included in scope rules.

Using scope rules that are based on a content source

When you have Search Server Administrator permissions, you can create scope rules on site collection-level content sources. You might do this for several reasons:

  • To create additional content sources that crawl content on a different schedule.

  • To create a separate content source to crawl content on a different SharePoint Services and Technologies farm or on a file share.

  • To divide the content into smaller sets with which to combine scope rules and to create a narrower scope of content.

For more information about planning for content sources, see Plan to crawl content (Search Server 2008).

Using the All Content scope rule type

When you create a scope rule using the All Content scope rule type, all content in the content index is available to the scope. If you want to create a narrower scope, you can add scope rules to a scope that uses the All Content scope rule type to exclude particular content from the scope.

Excluding content using a scope rule with the exclude behavior

The All Sites scope can be copied and used as a starting point to include all content in the content index. Then you can add scope rules that exclude content from search results to create scopes that are broad but do not include a certain set of search results. It is sometimes easier to use a copy of the All Sites scope with exclusion rules than to create a complex search scope containing rules that include every subset of content on the site.

Regardless of whether you start with a copy of the All Sites scope or another scope, you might want to consider adding scope rules that exclude content as a separate step from adding scope rules that include content because reasons to exclude content from search results can differ substantially from the reasons to include content.

Advanced Searches

In many cases, users type a keyword phrase in the search box and then click the Go Search button or press ENTER to execute their query. If this technique does not produce the result they are looking for on the first few pages of search results, some users will give up. However, advanced users tend try again by using a more advanced query to target the content they are looking for.

Note Note:

As the volume of content users are searching over increases, the chance that they will find what they are looking for by using a simple keyword phrase decreases.

Very advanced users can construct advanced search queries in the search box. For example, to find content that contains the word "negotiate" that was authored by David Jones, they could type the following query in the search box:

negotiate author:jones

However, most users are not familiar with the syntax required to construct advanced queries in this way. Therefore, most users construct an advanced query by using the Advanced Search page which enables them to target the content they are searching for using syntax. The following table describes the options on the Advanced Search page that are related to keywords.

Find documents with this option | Does this
All of these words | Searches for content that contains all of the keywords the user types, but the words do not have to be in the content in any particular order.
The exact phrase | Searches for content that contains the words the user types in the exact order.
Any of these words | Searches for content that contains any of the words the user types.
None of these words | Searches for content that contains none of the words the user types.

Users can also use the Advanced Search page to narrow their search to a specific language or document type. Finally, users can select property restrictions to filter their search results based on whether the value of the property they select matches the value that they enter. For example, users can select the Author property, select the Contains inclusion operator, type a value and then click Search.

Several properties, called managed properties, are provided, by default, such as Author and Title. However, most of the default managed properties are not made available to use in scopes. Search services administrators choose which managed properties they want to make available to scopes and can create additional properties to meet their organization's needs.

Plan properties for search

One way to organize content in your site collections in a way that can be effectively searched is to group content that has a common theme in the same location. This way, you can take advantage of the default scopes at the site and list level for searching over your content. For example, you can create a site to store all the information for a particular project. Within that site, you can create separate document libraries and lists to store different kinds of information related to that project. Users use the default This Site scope to search over all content in the site or the This List scope to search on content in a particular list or library in the site. Search Service and site collection administrators can create custom scopes as needed for users to search over different portions of content.

Although this is a relatively easy way to organize your content for effective searches, this approach by itself does not meet the needs of all organizations, especially when a large amount of content is being searched. Some reasons for this are:

  • It is not always possible to organize all content with a common theme in the same location.

  • Even if all content with a common theme is organized in the same location at deployment, content can become scattered across a site collection over time.

We recommend that you organize your content by location when it makes sense to do so, and then supplement that organization by using properties.

Managed and crawled properties

When content is crawled, the crawler also crawls the properties associated with that content. Crawled properties include the metadata of content that is stored in files, and databases used by your organization. Crawled properties can represent different kinds of information, such as author, title, and e-mail address.

Search Server 2008 enables search services administrators to create managed properties. They can then map crawled properties, which are the properties that the crawler collects and adds to the property store when crawling content, to managed properties that are used by search queries.

The relationship between managed properties and crawled properties is a simple but powerful one. Search services administrators can map one or more crawled properties (the properties discovered by the crawler) with managed properties (properties that can be used in scope rules and queries). This mapping is important because many crawled properties contain the same kind of metadata and crawled properties often have names that are not intuitive. For example, by default, the crawled properties named "Mail:6" and "Office:4" are mapped to a managed property named Author. This is because the values of these two crawled properties contain the name of the author. This mapping of crawled properties to managed properties eases administration and benefits users. Administrators benefit because they have fewer properties to work with when creating scopes. End users that construct advanced queries in the search box benefit because they also have fewer and more intuitive property names to remember.

Managed properties have the following benefits:

  • Users can use managed properties to construct queries in the search box that filter search results.

  • You can use properties on the Advanced Search page to enable end users to easily filter search results.

  • Site owners can customize the Advanced Search page to use different managed properties.

  • Search services administrators and site collection administrators can create custom scopes with rules that filter search results based on queries. End users benefit from advanced property-based queries without the need to learn how to construct an advanced query.

Several managed properties are created and mapped to crawled properties, by default. Search services administrators can map additional crawled properties to existing managed properties and create new managed properties.

Using properties in queries

For the value of crawled properties to affect a search query, the crawled properties must be mapped to a managed property, the managed property has to be made available to scopes, and the user must perform a search against that managed property. Including the values of too many crawled properties can have a negative effect on search relevance and performance.

Administrators planning the initial deployment of Search Server 2008 should record the initial set of managed properties planned for the search service.

Many of these crawled properties can be found by looking at the properties displayed in applications for content types such as Microsoft Office Word or Office Excel documents.

If you have access to a test server, you can crawl high-priority content and use the crawled properties that appear to help with planning.

You can make the content on your site easier to find by carefully planning your managed properties and how you implement them. When planning your deployment, we recommend that you keep the number of managed properties to a minimum. This means carefully considering what properties are most useful for your organization and deploying those as a starting point. You can always create additional managed properties after deployment, if needed.

Plan managed properties

One practical way to identify potential managed properties is to examine your existing content and its high-priority metadata. If you have access to a test farm prior to active deployment of Search Server 2008, you can crawl your content and see what crawled properties appear, and use those properties to identify part of your information architecture. However, most organizations will benefit from planning information architecture on paper before staging a deployment, because it can help to focus your planning and identify content and processes that are not as well-organized as they could be.

The key to creating a useful set of managed properties is to determine the most important concepts and find properties in your content that you can map to managed properties that enable users to find relevant content when searching. Mapping more properties increases the size of the database, and reduces performance accordingly, so it's a good idea to map properties only when you are confident that the mapping is relevant.

Some concepts are used to suggest site collection structure and content within site collections. Others are used to create special terms such as keywords to highlight relevant search results.

It is difficult to discover properties of content without first crawling content. Therefore, it is best to wait to plan managed properties until you already have a good idea of the content of each site collection. Then, on a test server, you can crawl all that content so that you have a list of crawled properties to compare against your information architecture when creating managed properties. It can be difficult to map properties even after crawling content because it is difficult to identify the content type or application that uses the property. If you are unsure of the nature and content of a particular property, you might want to set up a mapping in a test environment and experiment with searches over this property.

Many of the most useful managed properties are automatically created when Search Server 2008 is installed. Use these managed properties as a starting point when planning your other managed properties. The automatically created properties include:

  • Author

  • Description

  • Site Name

  • Type

  • File Size

  • Last Modified Date

  • URL

  • Title

Keep in mind that to effectively search by using properties, the crawled properties must first be assigned values. For example, if you have a document that has a property that maps to a managed property called Author, and no value is assigned to that property on that document, the document will not be displayed in search results when users query using the Author property for a particular author.

Avoid duplicating managed properties

Some properties are fairly basic and might appear as different properties in different types of content. Examples include the Author and Title properties for documents.

The most important thing you can do with these basic properties during planning is to reduce duplication by creating one set of managed properties and mapping the crawled properties with the same meaning to properties in the set of managed properties. In the case of the Author property, you can map each unique appearance of a crawled property for authors with a single Author managed property.

You can map one or more crawled properties to one or more managed properties.

Tip Tip:

Adding each Author property as a separate managed property doesn't make sense, because it adds additional managed properties to the database without increasing relevance.

You can choose to prioritize multiple crawled properties so that if more than one property is found during crawling, only the value of the highest priority property is used for queries using the managed property or properties. If you don't prioritize crawled properties, values for all crawled properties mapped to the managed property are used for queries, so that the managed property becomes multi-valued. This means the search result returns results for all content that contains values for any of the mapped properties that match the query. A sensible approach for a single-value property is to choose the most common crawled property as the managed property, and then prioritize mapped properties by how often they occur. It is not always easy to determine which property is crawled most often, but one strategy is to prioritize properties that you know are associated with commonly used applications.

When you map properties with different data types, the data type of the managed property is used by search in most cases.

Be careful when mapping properties that you do not map poorly matched or irrelevant properties because imprecise mappings can actually reduce the relevance of search results. If possible, test searches for managed properties before initial deployment, and plan to review usage data for search queries during normal operations to fine tune the properties you have mapped.

Add properties to present key concepts in the information architecture

In addition to the crawled properties that are mapped to managed properties, by default, other crawled properties might clearly map to concepts in your information architecture that are not already captured by existing managed properties. For example, a company might identify customer service as a key business process in its information architecture. Key concepts associated with customer service in the information architecture might include customers, customer service representatives, and customer service regions.

For each concept in your information architecture, ask yourself if there's a crawled property that represents this concept that can be mapped to a managed property. If so, make the property a managed property.

Note that although many concepts in the information architecture aren't represented by properties, those concepts are useful during site structure planning and the implementation of other search features. The information architecture can identify managed properties that you overlooked, but just because a concept is listed in the information architecture doesn't mean that there is or should be a managed property for that concept.

Use managed properties in search scopes

Each managed property can be exposed as a property for search scope rules. For more information about planning search scopes, see the "Plan search scopes" section earlier in this article.

Plan to integrate properties for new file types by using IFilters

Search Server 2008 uses property categories to crawl properties by documents within each category. Property categories include the protocol handler and IFilter used by search when it indexes content. Before you crawl content, you want to associate the content with the property categories that will most effectively find the crawled properties you need before you create managed properties. To register IFilters with Search Server 2008, see How to register Microsoft Filter Pack with SharePoint Server 2007 and with Search Server 2008.

If you want to add content to your content index that requires different IFilters or protocol handlers, you can programmatically create a new property category for that content. As part of your initial planning process, you should identify what content needs new IFilters and protocol handlers. This might require custom code, though some IFilters and protocol handlers are provided.

For information about property categories, see Manage metadata property mappings (Search Server 2008). For more information about crawling content, see Plan to crawl content (Search Server 2008).

Plan what users see in search results

Search Server 2008 provides several settings that enable search services and site collection administrators to control what users see in search results pages. Although you can control the search results in numerous different ways, during deployment we recommend that you:

  • Plan for keywords, Best Bets, and synonyms.

  • Plan what sites are most and least relevant to control how close they appear to the top of search results.

  • Plan whether to use federated locations and federation Web Parts.

  • Plan the appearance of links.

  • Plan whether users can use search-based alerts.

Plan keywords and Best Bets

Keywords, sometimes called keyword phrases, are the words that users type into a search box when constructing a query. When users perform a simple keyword search, for example entering the word "widget" in the search box and clicking the Go Search button, Search Server 2008 displays the search results of all content in the selected scope that contains that keyword.

Search Server 2008 enables site collection administrators to create an entity called a keyword that is directly related to keyword phrases of the same name that are in the index. A site collection administrator can create a keyword using one or more words. For example, a keyword can be a single word, such as "OOF" or a group of words that must be typed in a particular order, such as "out of office".

In addition to the name of the keyword, also called the keyword phrase, site collection administrators can create keywords that are composed of one or more of the following options:

  • A definition of the keyword that appears in search results

  • One or more synonyms

  • One or more Best Bets, which are the URLs that search services administrators specify as being highly relevant for a particular keyword

Note Note:

Although you can create a keyword that does not contain any of the optional information listed above, doing so does not improve the relevance of search results.

Keywords enable site collection administrators to improve the relevance of end user queries. The search results for any site collection can be modified to promote specific content so that it appears more prominently in response to queries that use particular search terms. Although keywords are planned, implemented, and managed at the site collection level, it is a good idea to make sure your planning and implementation is consistent throughout your organization.

Keyword definitions are a good way to provide easy access to information about high-priority concepts in each site collection. For each concept, site collection administrators can create a keyword so that the definition of the keyword appears in the Search Best Bets Web Part next to the search results. For example, a sales portal devoted to selling a particular line of products might provide definitions for the major items in the product line. These definitions can be used to help sales associates understand their products better, or the definitions can be displayed in search results on a public-facing portal site for customers.

Keyword example

A site collection administrator knows that end users are having difficulty finding the calendar that is used to track when team members are out of the office. Users report that when they search for the calendar, their queries produce several pages of irrelevant search results, and that they give up after looking through the first few pages.

The site collection administrator decides to create a keyword named "oof" containing the following:

Keyword definition: This is the acronym we use to mean out of office.

Synonym: time off

Best Bet: URL to the calendar and a description for the Best Bet.

The site collection administrator then asks the end users to use this new keyword "oof" or its synonym "time off" when searching for the calendar.

The following figure shows an example of the default search results page that end users see when searching on the keyword "oof" from the Search Center in this scenario. Note that Best Bets and keyword descriptions only appear on search results pages for searches that are run using the Search Center, by default.

Office SharePoint Server end-user search

In the figure above, the query that the end user ran is shown (callout 1). The keyword highlighting feature also shows the keywords in the content as bold text (callout 2). The description that the site collection administrator assigned to this keyword appears in the top-right corner of the search results page, by default (callout 3). Each keyword can be associated with a definition and you can include a URL in definitions. Accordingly, it is a good idea to:

  • Identify definition sources during planning.

  • Include a separate step during planning to design a glossary of all definitions used by keywords in each site collection.

  • Create some keywords for the sole purpose of associating the keywords with a definition.

The Best Bet (callout 4) appears directly below the keyword description, if there is one. A Best Bet is more than a URL. They also have a title and can optionally have a description. In this example, the site collection administrator named the Best Bet "Out of Office page". The description that the administrator assigned to the Best Bet appears directly below its name, and then the URL of the Best Bet appears below that.

Specific documents, sites, and people with expertise in the concept associated with a search term are common uses of Best Bets. It is important to consider the title and description of each Best Bet during content planning to increase the relevance and usability of each Best Bet. You can associate up to 25 Best Bets with each keyword in the administration user interface, and many more with the object model, but it is a good idea to not overuse Best Bets. Effective content planning can help you identify an appropriate number of Best Bets for each keyword that balances the number of search results with search relevancy.

Note Note:

Because the URL of a Best Bet is hard coded by the site collection administrator, it can be any URL. It can even point to content that has not been crawled.

You can use the same Best Bet for more than one keyword. If the Best Bet already exists, you can add it to any keyword without having to enter the properties for the Best Bet again and possibly introduce redundant Best Bets. You can also simultaneously change the URL and description for that Best Bet for all keywords that use it. This is particularly useful if you are using a test site during planning and before initial deployment.

Understanding synonyms

A synonym is one or more words that closely relate to a particular keyword. For example, an effective synonym for the keyword "car" might be "auto", "automobile", or "SUV". These are all effective synonyms for that particular keyword because you would expect that some users that are searching for cars to type one of those words into the search box instead. Site collection administrators can define one or more synonyms for each keyword. The purpose of a synonym is to display the same keyword definition and Best Bet on the search results page that is displayed when using the keyword. Following the previous example, if end users run a search query using the synonym "out of office" they see the same keyword description and Best Bets that they see when they run the search query using the keyword "oof." The difference, however, is that they see search results for only content that contains the words "out of office" instead of content that contains the word "oof".

Synonyms are useful when several search terms are used for the same concept and content, so that search results are consolidated and not scattered across several search terms. The list that is updated when a site collection administrator creates keywords and adds synonyms is called a thesaurus. The thesaurus for Search Server 2008 is compatible with the thesaurus for Microsoft Office SharePoint Portal Server 2003.

Use information architecture to identify keywords

You can use the information architecture created by your content planning teams to identify high-priority content to associate with keywords. Because your information architecture contains a list of terms, you can quickly use some of those terms to create keywords that you can associate with specific and highly relevant content.

Relevant content is anything specific that you want people to see first or most prominently when they search using a specific keyword. Examples of relevant content for each major business concept or content area include:

  • Documents

  • Sites

  • People

  • Definitions

  • Approved or official terms that mean the same thing, but were not included in the search query

Associating keywords with a Best Bet is helpful to encourage people to view the key documents that are needed to collaborate on key business processes. For example, a business might have a special template for expense reports, and a keyword "expense report" that promotes that template to the top of search results. Without that keyword, each employee might spend several minutes asking their colleagues for the appropriate URL or browsing the company Web site. With the keyword associated with the URL to the expense report template as a Best Bet, employees can quickly locate the template.

Keywords for sites are helpful for identifying the location of sites for relevant information in a large organization. For example, "holidays" could be a keyword associated with a Best Bet that contains the URL of the human resources site that contains information about paid time off for employees. Ideally, the Best Bet could contain the URL of the exact page that provides company holiday information.

Security considerations for keywords

Unlike previous versions of Office SharePoint Portal Server, keywords and Best Bets are not affected by security permissions, and all readers on the site collection can see all Best Bets and keywords for that site collection that appear in search results. Users who do not have permissions to see the page to which a Best Bet is linked cannot go to the page. However, they can see the description of the Best Bet on the search results page and the URLs to the content. This could expose information that some users were not intended to see.

Keywords are meant to provide high-priority results for all users. If you want to target content to certain users based on their permissions, you can use audiences and targeted Web Parts in the appropriate places on the site collection.

Plan keywords across your organization

It is important to plan keywords in advance to help ensure consistency of keywords across your organization. Even though keywords are implemented at the site collection level, you should ensure consistency of keywords across site collections whenever possible.

Example of poor keyword planning

A site collection administrator creates a keyword named "super list" on the marketing site collection and creates a best bet for that keyword that contains a URL to company's customer list. Another site collection administrator creates a keyword named "Master list" on the sales site collection and creates a best bet for that keyword that contains a URL to the same customer list.

Users that use the both site collections will become confused when their keyword search does not consistently display the Best Bet they expect to see on the search results page. For example, an employee that primarily uses the marketing site collection is accustomed to searching using the keyword "super list" and would expect it to work from either site collection.

Tip Tip:

Planning for consistency of keywords across your organization requires good collaboration among site collection administrators.

In small organizations, the content planning team is likely to be small and organized around a single site collection, and planning for keywords might be organized by only one or two people. In large organizations, on the other hand, a larger planning team can be helpful. You should include business planners and administrators at each level to make sure all business needs are addressed.

Best Bets appear in search results even if the content hasn't been crawled. This is another reason to plan keywords during initial deployment, so that high-priority content can be available in the early stages of a deployment before all content sources have been crawled. In rare cases where content cannot be crawled because search is missing a relevant IFilter or for any other technical reason, you can use Best Bets to make the content easier to find even though it hasn't been crawled.

Key people at each level of the organization plan keywords for their site collections. Those people use the same overall content plan, adapted for the content on the site collections that they are planning. When planning keywords, which starts before deployment and continues after deployment in waves over time, each set of content planners can communicate with each other to keep consistency in the overall plan.

Not all keywords will be planned before deployment. The role of your content planning teams is to identify the high-priority concepts that are most relevant to search queries in your organization, so that search queries are relevant to users from the first day of your deployment. The planning team can identify a contact person for each keyword who may or may not be someone on the planning team. After deployment, site collection administrators can expand the keyword list after identifying common search terms in the query logs.

In the planning phase, keyword list managers should consider how keywords match to queries. Keywords must match the complete string of search terms exactly, and must not use special syntax such as + and - when searching for content in lists. This prevents the return of multiple lists of keywords for the same search query, which streamlines search results.

Plan keyword management

The details of keyword management are mostly relevant to the daily operations of your site collections, but there are some aspects of administration that are worth considering when planning your deployment. Specifically the optional contact and publishing properties that site collection administrators can assign to properties.

Tip Tip:

The more planning you do before deployment, the less management will be needed during day to day operations.

Each keyword has the following optional properties:

  • Start, end (expiration), and review dates

  • Contact

Keywords can be required to go through approval before they affect search results, and can also be set to start or expire after a certain amount of time. The high-priority keywords identified during initial planning are unlikely to be temporary, except for content that is relevant to people using a site collection during the initial deployment.

The contact for each keyword is the person who should be contacted when a keyword expires, if it is set to expire. Content planners for each site collection should consider who is going to be managing keywords after the initial deployment, and include at least some of those people in the planning process at the site collection level.

However, part of the planning process is anticipating who will make decisions about keywords in the future. Making those decisions during the planning process can improve the transition to regular operations of the site collection, and promote consistent and efficient use of keywords in the future.

For more information about managing keywords, see Manage settings to improve search results (Search Server 2008).

Plan the relevance of search results

The greater the body of content that is being searched over, the more likely it is that several pages of search results will be displayed for a particular query. This is especially true when basic keyword queries instead of advanced queries are used. To facilitate a positive end-user experience, ensure that links to the most relevant content are displayed as early as possible on the search results pages.

Search Server 2008 enables search services administrators to assign indexed Web pages relevance settings. Each relevance setting, which is associated with a particular Web page, determines how early on the search results page the link to a particular page appears. Pages that are assigned a relevance setting are known as authoritative pages.

Authoritative page settings are one factor in prioritizing search results, and do not outweigh all other factors such as keywords managed by site collection administrators, managed properties that are managed by the search services administrator, or the automatic weighting applied to content by the search technology.

Authoritative page settings are configured at the Search Administration level and search services administrators can assign sites to one of four authoritative page levels:

  • Most authoritative

  • Second-level authoritative

  • Third-level authoritative

  • Sites to demote

Web pages are weighted based on how authoritative they are, with each level receiving proportionate relevance weighting. By default, all top-level pages for Web applications are automatically added as most authoritative. You can move these pages to other authoritative page levels or remove them from authoritative page settings completely.

Sites that are assigned the Sites to demote setting will typically appear towards the end of the search results after all other relevance weighting factors have been considered.

This means that they often appear on the search results page after pages that are not even specified as an authoritative page. We recommend that you use this setting for sites that contain irrelevant information (for example, an archive site).

When planning authoritative page settings, consider the purpose of each site, and review its subsites. Group authoritative sites into the three levels by importance and group the sites that are not likely to be relevant as sites to demote.

Good practices to use when planning authoritative page settings include:

  • SharePoint sites central to high-priority business processes will typically be most authoritative.

  • Sites that encourage collaboration or action are likely to be more authoritative than sites that are merely informative.

  • Sites that are informative but not central to high-priority business processes or used for collaboration are likely to be in the second or third level of authoritative sites.

  • External sites will typically be less authoritative, because your organization cannot control the content on those sites.

  • You don't need to assign an authoritative page setting to every site. It is a good idea to select relevance for a small number of sites that you know are most authoritative or less relevant, and adjust the authoritative page settings during normal operations based on feedback from users and information in the query logs and crawl logs.

Plan whether to use federated locations and federation Web Parts

Federation, a new feature in Search Server 2008, can be planned with the rest of the end user search experience. Federation enables end users to issue a query that searches multiple sources and combines results into a single search results page. These sources can include:

  • Your company's enterprise content repositories

  • Internet search engines or subscriptions services used by your company

  • Enterprise documents indexed by Search Server 2008 in other divisions or world regions

When the end user issues a query, Search Server 2008 formats and renders the results alongside your indexed results by using new federation Web Parts.

When you plan the experience you want for your users when they search federated locations, try to target the searching needs and habits of users in your company. Ask yourself these questions: What content do your users need to find most to be productive? What queries are they currently using? Target your federated locations to solve the key information problems in your company.

When using federation it is tempting to add many federated locations to satisfy all the possible needs of your users. Unfortunately, this leads many users to disregard federated results as clutter.

To help ensure that federated results target useful answers to queries, federated locations can match specific query formats with trigger rules. When you create a trigger rule for a federated location, the Web Part that is associated with that location displays results only for queries that match the pattern or prefix that you specify.

For example, let's say that you work at a company called Contoso, where employees manufacture a product called a widget. Employees need to find these widgets many times a day by using a ten-digit widget ID. Widgets are stored in a database that cannot be crawled by Search Server 2008. To enable Contoso employees to search for widgets, you build a federation connector that searches the widget database. However, displaying widget information for every query would likely frustrate your users. So, you create a federated location trigger by using a pattern that recognizes ten-digit queries. Now, when users search for widget IDs, they get a top federated result from the widget database.

For more information about using triggers and trigger rules, see Work with triggers and query templates in the Search Server 2008 Help.

You can add and configure federated results on the search results page with either a Federated Results Web Part or a Top Federated Results Web Part. By default, the search results page contains two Federated Search Results Web Parts and one Top Federated Results Web Part. You set the federated location and its properties in the Web Parts on the search results page.

For more information about federation, see Federating search results from other locations in the Search Server 2008 Help.

Plan the appearance of links

Search services administrators can use server name mappings to change how particular URLs or ranges of URLs are displayed in search results. Server name mappings are set at the Search Administration level for all content that is crawled by that Search Service, and are applied whenever queries are performed. You might want to use server name mappings in the following scenarios:

  • You want to prevent access problems and possible security vulnerabilities caused by links that show the local addresses on the server. For example, depending on how content is crawled, a URL might display a local path on the server.

  • You want to obscure complex URLs in search results, so you replace them with a more concise name on the server.

  • For security reasons, you want to hide the name of the original source of the content such as the server or share name.

Use server name mappings only when you have one of the display problems described in the previous list. In most cases, planning for server name mappings prior to the initial deployment will be minimal.

Plan search-based alerts

A search services administrator can decide whether search-based alerts will be activated for a particular Search Center. If search-based alerts are activated and the server is configured to send e-mail, end users can click the Alert Me link at the top of search results pages and specify what kind of changes they want to be alerted to and how frequently they want to receive an alert in e-mail. Note that when you allow search-based alerts, your system uses additional resources on mail servers, and increases the load on query servers because queries for each search-based alert run every time a search-based alert is processed. When planning the initial deployment, consider the resources available for alerts and the likelihood that people using your sites will use alerts productively. Search-based alerts are activated, by default.

During operations, search-based alerts are automatically disabled whenever content sources are reset in order to avoid sending notifications for all search-based alerts. Administrators then have to re-enable search-based alerts.


Plan for redundancy (Search Server 2008)
DropDown image

Updated: 2008-07-31

In this article:

  • About redundancy

  • Define server redundancy requirements

  • Plan for a minimum level of server redundancy

  • Choose a baseline server farm topology

  • Plan query server redundancy

  • Plan database server redundancy

  • Evaluate the risks of server failures

This article describes the options for scaling out redundant server roles included in a Microsoft Search Server 2008 farm. After reading this article, you will be able to determine and record the redundancy options that are appropriate for the environment.

Before you read this topic, read the following topics:

  • Plan to deploy Search Server 2008 or Search Server 2008 Express

  • Determine hardware and software requirements (Search Server 2008)

  • Plan for availability (Search Server 2008)

Note that Search Server 2008 and Search Server 2008 Express do not typically host content. Instead, they are primarily used to host Search services, crawl content on Windows SharePoint Services and Microsoft Office SharePoint Server farms or other remote content sources, and respond to queries. In some environments, Search Server 2008 and Search Server 2008 Express can be used to host content. If you plan to use Search Server 2008 or Search Server 2008 Express for hosting content, read the articles in Plan for performance and capacity (Windows SharePoint Services) to ensure that you understand the requirements for hosting content and running Search Server 2008 or Search Server 2008 Express in the same farm.

About redundancy

The term redundancy is often misinterpreted to be synonymous with availability. Although these concepts are related, they are not the same. Redundancy refers to the use of multiple servers in a load-balanced environment for any of several purposes, such as to improve farm performance, to scale out to accommodate additional users, and to improve availability.

Availability is a more specialized concept that refers to a multiple-server environment that is designed to accept connections and operate normally even when one or more of the servers in the farm are not operational. Therefore, availability implies redundancy, and additionally implies a failover mechanism and several other possible characteristics. However, a redundant system might not be highly available.

For more information about availability, see Plan for availability (Search Server 2008).

This article describes how to implement redundant servers in a Search Server 2008 farm.

Define server redundancy requirements

Search Server 2008 supports scalable server farms for capacity, performance, and availability. Typically, capacity is the first consideration in determining the number of server computers to start with. After factoring in performance, availability also plays a role in determining both the number of servers and the size or capacity of the server computers in a server farm.

By the end of this section, you will be able to determine whether you have to build expandable capacity into the server deployment topology by deploying redundant servers, or if it makes sense for the organization to plan for a limited server deployment that has no redundant servers.

Plan for a minimum level of server redundancy

To deploy a redundant solution, you must deploy a server farm.

There are several different server topologies that can be used as a baseline. Each of these topologies builds in a level of server redundancy. This section summarizes these server farms.

Note Note:

In the following descriptions, we refer to servers on which the index role has been installed as index servers, and servers on which the query role has been installed as query servers.

Redundant topologies

This sections contains examples of redundant topologies.

Five or more server farm

The optimal redundant server farm topology introduces a separate index server and consists of five or more server computers, including at least two database server computers in a clustered configuration and at least two query server computers.

Given this topology, you can install the index server role on the dedicated application server. This design optimizes the performance of the query server computers by enabling you to offload indexing to the middle tier.

Note that this topology shows a SQL Server clustering configuration that provides manual failover. For more information about how to configure a SQL Server cluster for automatic failover, see SQL Server 2005 Failover Clustering White Paper or Installing a SQL Server 2008 Failover Cluster, depending on which version of SQL Server you are using.

Four-server farm

The smallest server farm that builds in redundancy consists of four servers:

  • Servers 1 and 2: Query role installed on both computers.

  • Servers 3 and 4: Clustered or mirrored database server.

When you use a four-server farm, you must carefully decide where to deploy the index server role. The query role cannot be deployed to both the index server and another server in the farm to achieve redundancy. This is because, when the index role is installed on the same server computer as the query role, the index role no longer propagates content indexes to other query servers. Consequently, if you install the index server role to one of the Web servers, you lose the ability to host the query role on both Web servers. You can install the index role on the database server, achieving redundancy of the query role on the Web servers. However, the performance of the database server will be affected, especially when content is being crawled.

Three-server farm

There is another alternative for achieving redundancy when you deploy fewer servers. When you use a three server farm, you must decide which of the server roles to make redundant: either the Web server role or the database server role.

By adding a third server to the Web server tier, you achieve redundancy of the Web server role. The query and index roles can be either installed on the same Web server (see Option A in this section), or they can be installed on different Web servers (see Option B in this section).

Three-server farm with redundant Web servers

Given this topology, the query role cannot be deployed to both Web servers to achieve redundancy. This is because, if the query server role is installed on the same server as the index server, the index server will not propagate the index to other query servers. However, you can install the index role on the database server. This enables you to deploy the query role on both Web servers. However, the performance of the database server will be affected.

Although availability is limited, dedicating two servers to the Web server role increases the overall performance of the small farm. Use this topology when performance is more important than data redundancy.

Non-redundant topologies

Non-redundant topologies might contain more than one server, but are not redundant because there is only one server for each server role. For example, a farm that contains one query server, one index server, and one database server is not redundant.

If you do not have to build additional capacity and performance into the server deployment, the starting point for the server topology is one or two servers. For a limited-use purpose, you can deploy a single Search Server 2008 server or deploy Microsoft Search Server 2008 Express, which is limited by design to a single application server.

The following diagrams show examples of non-redundant topologies.

Choose a baseline server farm topology

Each of the server farm topologies described earlier in this article represents a baseline starting point for designing the deployment. The starting point that best suits the organization depends on the server roles for which you must have redundancy.

The rest of this article describes the redundancy options for each of the server roles. When you are finished with this article, you will be able to determine the baseline topology that can deliver the redundancy that the organization requires. This is the topology that you will use as a baseline when you plan for capacity and performance.

Plan query server redundancy

Use this section to:

  • Determine if the organization requires redundancy built into the Web tier.

  • Plan which query server load balancing technology to implement.

The query server role can be deployed to multiple servers. The code that is deployed to each server is identical and the query servers do not store any data. In other words, each instance of the query server role remains identical. If one of the server computers fails, no saved data is lost. The query servers automatically load balance requests to these server roles across the available server computers.

The query role can be deployed to any number of Web servers. However, there is one limitation. If the query role is deployed to the same server that hosts the index role, the query role should not be deployed to any other server computers. This is because the index role recognizes that the query role is located on the same server. Therefore, it does not attempt to propagate the index.

The index application server role cannot be redundant in Search Server 2008.In Search Server 2008, the index role is associated with a Shared Services Provider (SSP). The index role builds one index per SSP. You cannot deploy multiple index servers to improve capacity. The index server is associated with a single SSP, and in Search Server 2008, you can only have a single SSP.

The next step is to plan which load balancing technology to implement. Search Server 2008 supports two methods of load balancing:

  • Software, such as Network Load Balancing (NLB) services in the Windows Server 2003 operating system. NLB runs on the query servers, and uses TCP/IP to route requests. Because NLB and other software load balancing solutions run on the query servers, they use query server system resources. This reduces the resources that can be used for serving queries. However, the effect on system resources is not great, and a software solution can handle up to 32 query servers.

  • Hardware, such as a router or a switch box. Load-balancing hardware uses the network to direct query traffic between the query servers. Load-balancing hardware is more expensive to set up than software. However, it does not affect resource use on the query servers. Search Server 2008 can be used with any load balancing hardware.

Although not recommended, there is a third method of load balancing, round-robin load balancing with Domain Name System (DNS). Round-robin DNS load balancing can use significant resources on the query servers, is slower than either load balancing software or hardware. We do not recommend that you use it with Search Server 2008. Also, round-robin DNS load balancing does not take session load into account when routing a user to a server, which can lead to a server being overloaded.

The article How To Configure Network Load Balancing Parameters in Windows Server 2003 (http://go.microsoft.com/fwlink/?LinkId=124067&clcid=0x409) provides instructions for configuring NLB. If you decide to implement a different technology for load balancing, factor this into the planning and deployment process.

Plan database server redundancy

Use this section to help you determine whether redundancy of the database server role is required for the solution. Subsequent planning topics will help you decide which database redundancy technology is most appropriate for the environment. For more information, see Plan for and design database storage and management.

The database server role affects the availability of your solution more than any other role. If a query server or the index server fails, these roles can quickly be restored or redeployed. However, if a database server fails, your solution depends on restoring the database server. This can potentially include rebuilding the database server and then restoring data from the backup media. In this case, you can potentially lose any new or changed data dating back to the last backup job, depending on how SQL Server 2005 is configured. Additionally, the solution will be completely unavailable for the time that is required to restore the database server role.

Evaluate the risks of server failures

This section summarizes the expected consequences of a single query server or index server failure. In other words, if you deploy the query server role to only one server and the server fails, what are the potential consequences? Understanding the potential consequences will help you prioritize the allocation of servers in the farm. The following table lists application server roles and describes the consequences of downtime for each.

Server role | Consequences of downtime
Query | Users cannot issue full-text queries. Users can still browse through sites and access content exposed through the sites. If your application depends on users or customers being able to find content by searching, plan to deploy the query server role to multiple servers. In a five-server farm, this can easily be done by deploying the query role to the two Web server computers.
Index | Query servers continue to use existing content indexes until the index service is restored and new or updated indexes are generated. Consequently, search results do not include new or changed content while the index role is unavailable.
Database | The farm will be inaccessible to users. Attempts to view pages in the farm will result in error messages. If your application depends on users or customers being able to find content by searching, plan to deploy a clustered database server configuration.

The general redundancy recommendation is to plan to install the query server role to at least two server computers if the availability requirement for the query server role is 99 percent or greater.

If your organization can tolerate temporary loss of this functionality for the time it takes the IT team to deploy an application server role to a different server or to restore service to the existing server, you can consider deploying the role to a single application server.

See Also

Concepts

Plan for availability (Search Server 2008)

Other Resources

Plan for and design database storage and management
How To Configure Network Load Balancing Parameters in Windows Server 2003
SQL Server 2005 Failover Clustering White Paper
Installing a SQL Server 2008 Failover Cluster


Plan for availability (Search Server 2008)
DropDown image

Updated: 2009-03-11

This article describes availability in general, costs and challenges for availability in a SharePoint Products and Technologies environment, and strategies and solutions that you can use in the environment. You should read this paper if your farm is running Microsoft Search Server 2008. You may want to download and print the Office SharePoint Server 2007 Availability model (http://go.microsoft.com/fwlink/?LinkId=122369) that accompanies this article. It provides a poster-sized summary of the content in this article.

What is availability?

Availability is the degree to which a SharePoint Products and Technologies environment is perceived by users to be available. To ensure availability means to ensure that a system is resilient — that is, that service-affecting incidents occur infrequently, and that timely and effective action is taken when they do. Availability strategies minimize the user perception of planned and unplanned downtime.

One of the most common measures of availability is percentage of uptime expressed as number of nines — that is, the percentage of time that a given system is active and working. For example, a system with a 99.999 uptime percentage is said to have five nines of availability.

The following table correlates the number of nines to calendar time equivalents.

Acceptable uptime percentage | Downtime per day | Downtime per month | Downtime per year
95 | 72.00 minutes | 36 hours | 18.26 days
99 | 14.40 minutes | 7 hours | 3.65 days
99.9 | 86.40 seconds | 43 minutes | 8.77 hours
99.99 | 8.64 seconds | 4 minutes | 52.60 minutes
99.999 | 0.86 seconds | 26 seconds | 5.26 minutes

If you can make an educated guess as to the number of total hours downtime you are likely to have, you can use the following formulas to calculate the uptime percentage for a year, a month, or a week:

% Uptime/year = 100 - (8760 - number of total hours down per year)/8760

% Uptime/month = 100 - ((24 * number of days in the month) - number of total hours down in that calendar month)/(24 * number of days in the month)

% Uptime/week = 100 - (168 - number of total hours down in that week)/168

What availability is not

Availability is not data protection and recovery, nor is it disaster recovery, although these concepts are related, and you should have data protection and disaster recovery plans in any highly available system. Protecting and recovering data is the general business need that underlies the following specific business needs:

  • Keeping and being able to review more than one version of an item or site.

  • Recovering accidentally deleted items or sites.

  • Archiving data for legal, regulatory, or business reasons.

  • Restoring systems in the event of unexpected hardware or software failure.

Moreover, availability is not business continuation management (BCM). BCM consists of the business decisions, processes and tools you put in place in advance to handle crises. A crisis can be a local, regional, or national event, or a crisis can relate to only your business.

SharePoint Products and Technologies availability and data protection management strategies may be part of your technical BCM plan, but your overall BCM plan should be much more comprehensive, including the following elements:

  • Clearly documented procedures.

  • Offsite storage of key business records.

  • Clearly designated contacts.

  • Ongoing staff training.

  • Offsite recovery mechanisms.

Costs of availability

Availability is one of the more expensive requirements for a system. The higher the level of availability and the more systems you protect, the more complex and costly an availability solution is likely to be. When you invest in availability, costs include:

  • Additional hardware and software, often involving complex operations between software, such as custom scripts for failover and recovery.

  • Additional operational complexity.

The costs of attaining availability should be evaluated based on your business needs — not all solutions within an organization are likely to require the same level of availability. You can offer different levels of availability for different sites, different services — for example, search and business intelligence, or different farms.

Availability is a key area in which information technology (IT) groups offer service level agreements (SLAs) to set expectations with customer groups. Many IT organizations offer a variety of SLAs that are associated with different chargeback levels.

Note Note:

When calculating availability, most organizations specifically exempt or add hours for planned maintenance activities.

Challenges for availability in SharePoint Products and Technologies

A SharePoint Products and Technologies deployment poses the following challenges for providing availability:

  • While you are applying patches or upgrading the farm, the farm is unavailable.

  • Index server redundancy cannot be achieved by installing the index role on multiple servers. To overcome the loss of an index server, you will need to reinstall the server and either restore from a backup, or rely on slightly stale results while search recrawls the content. Alternatively, you can use one of the techniques described in the section Availability of Search after failover to reduce the time it takes to recover search.

  • SharePoint Products and Technologies is not aware of SQL Server mirroring. Although we recommend that you consider using SQL Server mirroring as an availability technique, doing so requires additional automation.

When to consider availability

We recommend that you consider availability requirements as part of the core design of the SharePoint solution. You can also provide enhanced availability after the solution is deployed. Operationally, we recommend that you deploy and tune the core solution within a farm, and then test the availability solutions.

Determining availability requirements

To gauge the organization's tolerance of downtime for a site, service, or farm, answer the following questions for the site, service, or farm.

  • If the site, service, or farm becomes unavailable, will employees of the organization be unable to perform their expected job responsibilities?

  • If the site, service, or farm becomes unavailable, will business and customer transactions be halted, leading to loss of business and customers?

If you answered yes to any of these questions, you should invest in an availability solution.

Choose an availability strategy

You can choose among many different approaches to enhance availability, including:

  • Fault tolerance of components.

  • Redundancy and failover between server roles within a farm.

  • Redundancy and failover between server farms.

System requirements for availability

In an ideal scenario, the failover components and systems match the primary components and system in all ways: platform, hardware, number of servers. At a minimum, the failover environment must be able to handle the expected traffic during a failover. Keep in mind that only a subset of users may be served by the failover site. The systems must match in at least the following:

  • Operating system version and all updates

  • SQL Server versions and all updates

  • SharePoint Products and Technologies versions and all updates

Although this article primarily discusses the availability of SharePoint Products and Technologies, the system uptime will also be affected by the other components in the system. In particular, consider the following:

  • You should ensure that infrastructure dependencies such as power, cooling, network, directory, and SMTP are fully redundant.

  • Choose a switching mechanism for the system, whether DNS or hardware load balancing, that meets your needs. Best practices for load-balancing Web servers can be found in the following articles:

    • Enterprise Design for Load Balancing (http://go.microsoft.com/fwlink/?LinkId=122194&clcid=0x409)

    • Enterprise Design for DNS (http://go.microsoft.com/fwlink/?LinkId=122196&clcid=0x409)

Component fault tolerance

In any system, we recommend that you work with hardware vendors to procure fault-tolerant hardware that is appropriate for the system, including Redundant Array of Independent Disks (RAID) arrays. For recommendations, see Plan for performance and capacity (Windows SharePoint Services).

When planning for component fault tolerance, consider the following:

  • Complete redundancy of every component within a server may not be possible or may be impractical. Use additional servers for additional redundancy.

  • Consider component redundancy for the index server role, because the index server role cannot be made redundant.

  • Ensure that servers have multiple power supplies connected to different power sources for maximum redundancy.

Redundancy and failover between server roles within a farm

SharePoint Products and Technologies supports running server roles on redundant computers (that is, scaling out) within a farm to increase capacity and improve performance and to provide basic availability. Capacity and performance determine both the number of servers and the size of the servers in a farm. After you have met base requirements, you may want to add more servers to increase the overall availability of the service.

Availability within a single-server farm

Single farm availability

The following table describes the servers and server roles in a SharePoint Products and Technologies environment as listed on the Services on Server page on the SharePoint Central Administration Web site, and the basic redundancy strategies that can be used for each within a farm.

Services on server | Preferred basic redundancy strategy within a farm
SQL Server | Clustering or synchronous mirroring. Clustering is easier to implement but can be more expensive. For more information about using synchronous mirroring, see White paper: Using database mirroring.
Web servers | Deploy to multiple servers and load balance by using software or hardware load balancing.
Web server for medium server farms (Web application and search query services) | Deploy to multiple servers.
Search indexing | Cannot be deployed to multiple servers and be redundant. You must use a different availability strategy. For more information, see Availability of Search after failover.
Excel Calculation | Deploy to multiple servers.
Project Application | Deploy to multiple servers.

For more information, see Plan for availability (Office SharePoint Server).

Comparison of database availability strategies for a single farm: SQL Server failover clustering vs. SQL Server high availability mirroring

The following table compares failover clustering to synchronous SQL Server high availability mirroring.

SQL Server failover clustering | SQL Server high availability mirroring
Mirror takes over immediately upon failure. | Mirror takes over immediately upon failure.
Transactionally consistent. | Transactionally consistent.
Transactionally concurrent. | Transactionally concurrent.
Shortest time to recovery (seconds to minutes). | Slightly longer time to recovery (seconds to minutes).
Failure is automatically detected by database nodes; SharePoint Products and Technologies references the cluster, so failover from a SharePoint Products and Technologies perspective is seamless and automatic. | Requires scripting to achieve SharePoint Products and Technologies failover.
Does not protect against failed storage, because storage is shared between nodes in the cluster. | Protects against failed storage because both the principal and mirror database servers write to local disks.
Requires more expensive shared storage. | Can use less-expensive direct-attached storage (DAS).
Same subnet. | Up to 1 millisecond (ms) in latency between SQL Server and Web servers.
Can use SQL Server simple recovery model, although the only available recovery point if the cluster is lost will be the last full backup. | Requires SQL Server full recovery model.
No performance overhead. | Introduces transactional latency. Adds memory and processor overhead.
Minimal operational burden. | Additional operational burden, including scripting and setting up SQL Server aliases.

Redundancy and failover between closely located data centers configured as a single farm ("stretched" farm)

Some enterprises have data centers that are closely located with high-bandwidth connections, so that they can be configured as a single farm. This is called a "stretched" farm. For a stretched farm to work, there must be less than 1 millisecond latency between SQL Server and the Web servers in one direction, and at least 1 gigabit per second bandwidth.

  • In this scenario, you can provide redundancy for databases by using synchronous mirroring. Within a stretched farm, you can mirror the configuration database and content databases. For a case study of how one company used a stretched farm, see White paper: Case Study of High Availability for SharePoint using Database Mirroring.

  • Consult with your SAN vendor to determine whether you can use SAN replication or another supported mechanism to provide availability across data centers, such as SQL Server running on geographically dispersed server clusters. Ensure that the SAN replication solution offers a sufficient level of concurrency and transactional consistency.

Within a stretched farm, you can provide fault tolerance for application servers that are running SSPs by having:

  • Multiple query servers

  • Multiple servers running Excel Calculation Services

The index server is a single point of failure within this scenario. You can either back up and restore search, or, if search currency upon recovery is vital, use a failover SSP farm. For more information, see Availability of Search after failover.

"Stretched" farm

Redundancy and failover between data centers with multiple farms

You can set up a failover farm to provide availability in a separate data center from the primary farm. An environment with a separate failover farm has the following characteristics:

  • A separate configuration database and Central Administration content database must be maintained on the failover farm.

    Note Note:

    If you have configured alternate access mapping for the primary farm, it is especially important to configure it identically on the failover farm.

  • All customizations must be deployed on both farms.

  • Patches must be applied to both farms, individually.

  • Only content databases can be successfully asynchronously mirrored or log shipped to the failover farm.

  • Mirrored or log-shipped databases must be set to use the full recovery model.

  • SSP databases can be backed up and restored to the failover farm.

Consult with your SAN vendor to determine whether you can use SAN replication or another supported mechanism to provide availability across data centers.

This topology can be repeated across many data centers, if you configure SQL Server log shipping to one or more additional data centers.

Note Note:

SQL Server mirroring can only be used with one mirror server, but you can log ship to multiple secondary servers.

Primary and failover farms before failover

Primary and failover farms before failover

The following table describes the servers and server roles in a SharePoint Products and Technologies environment, and the basic redundancy strategies that can be used for each between server farms.

Server or server role Preferred basic redundancy strategy between farms

SQL Server

SQL Server asynchronous database mirroring, SQL Server log-shipping, or other asynchronous replication mechanism.

Note Note:

Cannot be used for the SSP databases that host search information.

Front-end Web servers

Deploy on both farms, including customizations.

Web server for medium server farms (Web application and Search Query services)

Deploy on both farms.

Search indexing

Deploy on both farms. Recover backup from original farm to move to failover farm.

Excel Calculation

Deploy on both farms. If SSP does not host search, can use asynchronous database mirroring, SQL Server log shipping, or other asynchronous replication mechanism to move data to failover farm.

If SSP also hosts Search, must recover backup from original farm to move.

Project Application

Deploy on both farms. Recover backup from original farm to move to failover farm.

Asynchronous replication and search

Search requires complete synchronization between the Search database, SSP database, and index. Because of this requirement, search cannot be replicated between farms by using an asynchronous replication mechanism (asynchronous database mirroring, log shipping, or asynchronous SAN replication). To provide search on a failover farm, you must recover the Search SSP.

Note Note:

If you are running an SSP without search or Project, you can use an asynchronous replication mechanism to move data.

Availability of search after failover

The index server role cannot be redundant within a farm. The needs of the business for search currency after failover may determine the logical architecture of the solution.

  • If the business does not require immediate search currency and availability after failover, you can back up and restore the Search SSP to the failover site.

  • If the business requires rapid search currency and availability, you can use one of the following:

  • A single farm architecture with two identical SSPs.

  • A centralized parent farm that hosts search and other SSPs. The search service at the central farm crawls content at all other farms. This architecture can be used to support one or more farms.

Important Important:

If the business requires rapid search concurrency and availability, and you are using profiles, the profiles on the failover SSPs are not synchronized to the profiles on the primary SSPs—they will be in the state they were in when initially imported. To keep the profiles on all SSPs synchronized, you must use the User Profile Replication Engine that is included in the 32-bit SharePoint Administration Toolkit (http://go.microsoft.com/fwlink/?LinkId=119535) or the 64-bit SharePoint Administration Toolkit (http://go.microsoft.com/fwlink/?LinkId=119536). For more information, see User Profile Replication Engine (Office SharePoint Server).

Single farm with two SSPs

The following architecture protects against failure of an index server. In this topology, both SSPs crawl the same content, using the same rules. The failover SSP is not attached to the primary Web site unless a failover occurs.

Single farm with two Shared Services Providers

Farm with two SSPs

This topology has the following limitations:

  • Requires twice the space for indexes on each query server

  • Requires manually switching a Web application to use the failover SSP (can be scripted).

  • Reduces the size of the corpus you can crawl by half.

  • By default, if profiles are enabled, the profiles on the failover SSP are not synchronized to the profiles on the primary SSP. Instead, they will be in the state they were in when initially imported. To keep the profiles on all SSPs synchronized, you must use the User Profile Replication Engine that is included in the 32-bit SharePoint Administration Toolkit (http://go.microsoft.com/fwlink/?LinkId=119535) or the 64-bit SharePoint Administration Toolkit (http://go.microsoft.com/fwlink/?LinkId=119536). For more information, see User Profile Replication Engine (Office SharePoint Server).

The ability to crawl large data sets in a timely fashion is affected by several factors including the latency and bandwidth between index servers and Web servers.

In an environment with limited bandwidth, this topology can significantly reduce performance. Crawling content twice places additional load on the content repositories being crawled, which can affect repository performance. The ability of search to keep the index fresh may also be negatively affected.

Centralized SSP farms

In the following architecture, the use of a parent SSP farm protects against failure of an index server. Although this may appear to be a hardware-intensive solution, separate SSP farms can share some hardware such as a clustered or mirrored database server, as long as the index servers reside on separate servers. For more information about planning and configuring SSP farms, see Plan SSP architecture.

This topology has the following benefits:

  • SSP management is centralized.

  • Failure of a farm does not require a recrawl.

Centralized SSP farms

SSP failover farms

This topology has the following limitations:

  • Content crawling over a wide-area network (WAN) uses bandwidth.

  • Keeping indexes current can be difficult in environments with high volumes of data and high rates of change.

  • Query performance may be affected by the performance of WAN links.

  • By default, if profiles are enabled, the profiles on the failover SSP farm are not synchronized to the profiles on the primary SSP. Instead, they will be in the state they were in when initially imported. To keep the profiles on all SSPs synchronized, you must use the User Profile Replication Engine that is included in the 32-bit SharePoint Administration Toolkit (http://go.microsoft.com/fwlink/?LinkId=119535) or the 64-bit SharePoint Administration Toolkit (http://go.microsoft.com/fwlink/?LinkId=119536). For more information, see User Profile Replication Engine (Office SharePoint Server).

Summary

Carefully review your availability requirements. The higher the level of availability and the more systems you protect, the more complex and costly an availability solution is likely to be.

The costs of attaining availability should be evaluated based on business needs. Not all solutions within an organization are likely to require the same level of availability. You can offer differing levels of availability for different sites, different services (for example, search and business intelligence), or different farms.

Acknowledgements

The Microsoft Office SharePoint Server Content Publishing team thanks the following technical reviewers on this paper:

  • Bill Baer, Microsoft Online Services, Hosted SharePoint, Technology Architect

  • James Petrosky, Microsoft Consulting Services, Senior Consultant

  • Steve Peschka, Microsoft Consulting Services, IW Senior Architect

  • Dan Winter, Microsoft Customer Support Services, Escalation Engineer

  • Sean Livingston, Microsoft SharePoint Products and Technologies, Program Manager

  • Mike Watson, Technology Architect

  • Todd Carter, Microsoft Premier Field Engineering, Principal Premier Field Engineer

  • Mike Plumley, Microsoft Office Project Server, Writer

  • Christophe Fiessinger, Microsoft Office Project, Senior Technical Product Manager

  • Sid Shah, Microsoft Search, Program Manager

  • Luca Bandinelli, Microsoft SharePoint Products and Technologies, Program Manager


Plan for authentication (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Microsoft Search Server 2008 is built on Windows SharePoint Services 3.0 and therefore has all of the capabilities of Windows SharePoint Services 3.0. This includes the ability to create Web applications and sites for storing content. The articles in this section describe the authentication methods that are supported and how your implementation of them can affect crawling. If you use Search Server 2008 for crawling or federating content, you can use the guidance in these articles to help you plan authentication for your Search Center.

In this section:

  • Plan authentication methods (Search Server 2008)

  • Plan authentication settings for Web applications (Search Server 2008)

  • Authentication samples (Search Server 2008)


Plan authentication methods (Search Server 2008)
DropDown image

Updated: 2009-04-16

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

This article describes the authentication methods that are supported by Search Server 2008. After reading this article, you will be able to:

  • Understand how authentication is implemented in Search Server 2008.

  • Identify the authentication methods that are appropriate for your environment.

In this article:

  • About authentication

  • Supported authentication methods

  • Configure authentication

  • Plan authentication for crawling content

  • Planning zones for your authentication design

  • Choose methods of authentication allowed in your environment

  • Worksheet

About authentication

Authentication is the process of validating a user's identity. In Search Server 2008, Internet Information Services (IIS) performs the authentication of users. After a user's identity is validated, Search Server 2008 performs the authorization process to determine which sites, content, and other features the user can access. Part of this process begins when the content items are crawled. As the crawler opens each content item to extract the content, it also retrieves content item metadata including the access control list (ACL) for each content item. After the content from each content item is parsed and processed, it is then added to the full-text index, also called the content index. The metadata and ACL information is added to a separate index called the search database.

When a user submits a query, the Web server obtains both the search results from the content index and each content item's metadata, including ACLs, from the search database. The Web server compares the credentials of the user who submitted the query to the ACLs of the content items included in the search results. Any content items that the user does not have permission to access are not included in the search results. This process is known as security trimming.

Supported authentication methods

Search Server 2008 provides a flexible and extensible authentication system, which supports authentication for identity management systems that are based or are not based on the Windows operating system. By integrating with ASP.NET pluggable authentication, Search Server 2008 supports various forms-based authentication schemes. Authentication support in Search Server 2008 enables various authentication scenarios. They include the following:

  • Using standard Windows authentication methods.

  • Using a simple database of user names and passwords.

  • Connecting directly to an organization's identity management system.

  • Using two or more methods of authentication for accessing partner applications (for example, connecting to your partner company's identity management system for authenticating partner employees while you are using Windows authentication methods to authenticate your internal employees).

  • Participating in federated identity management systems.

The following table lists the supported authentication methods:

Authentication method Description Examples

Windows

The standard IIS Windows authentication methods are supported.

  • Anonymous

  • Basic

  • Digest

  • Certificates

  • Kerberos (Integrated Windows)

  • NTLM (Integrated Windows)

ASP.NET forms

Search Server 2008 adds support for identity management systems that are not based on Windows by integrating with the ASP.NET forms authentication system. ASP.NET authentication enables Search Server 2008 to work with identity management systems that implement the MembershipProvider interface. You do not have to rewrite the security administration pages or manage shadow Active Directory directory service accounts.

  • Lightweight Directory Access Protocol (LDAP)

  • SQL database or other database

  • Other ASP.NET-based forms authentication solutions

Web Single Sign-On (SSO)

Search Server 2008 supports federated authentication through Web SSO vendors. Web SSO enables SSO in environments that include services that are running on different platforms. You do not have to manage separate Active Directory accounts.

  • Active Directory Federation Services (AD FS)

  • Other identity management systems

Authentication of system accounts

ASP.NET forms authentication and Web SSO can be used to authenticate only user accounts. The process accounts that are used to connect to Microsoft SQL Server database software and run the scale-out deployment must be Windows accounts, even when you use alternative methods of authentication to authenticate users.

Search Server 2008 supports SQL Server authentication and local computer process accounts for farms that are not running Active Directory. For example, you can implement local accounts by using identical user names and passwords across all servers in a farm.

Configure authentication

Although configuring Windows authentication is straightforward, configuring authentication to use ASP.NET forms or Web SSO requires more planning. This section provides a summary of how authentication is configured in Search Server 2008. This information will help you understand how to design an authentication strategy for your solution and determine who in your organization has to be involved in planning for authentication.

Connect to identity management systems that are external or not based on Windows

To use ASP.NET forms or Web SSO to authenticate users against an identity management system that is not based on Windows or that is external, you must register the membership provider in the Web.config file. In addition to registering a membership provider, you can register a role manager also. Search Server 2008 uses the standard ASP.NET role manager interface to gather group information about the current user. Each ASP.NET role is treated like a domain group by the authorization process in Search Server 2008. You register role managers in the Web.config file the same way that you register membership providers for authentication.

If you want to manage membership user or roles from the Central Administration site, you can optionally register the membership provider and the role manager in the Web.config file for the Central Administration site (in addition to registering these in the Web.config file for the Web application that hosts the content).

Ensure that the membership provider name and role manager name that you registered in the Web.config file is the same as the name that you entered in the Central Administration Authentication.aspx page. If you do not enter the role manager in the Web.config file, the default provider specified in the machine.config file might be used instead.

For example, the following string in a Web.config file specifies a SQL membership provider:

CopyCode image Copy Code
<membership defaultProvider="AspNetSqlMembershipProvider">

For additional information about how to use ASP.NET forms authentication to connect to a SQL Server authentication provider, see Authentication samples (Search Server 2008).

Finally, if you are using Web SSO to connect to an external identity management system, you must also register an HTTP module for the Web SSO. An HTTP module is an assembly that is called on every request made to your application. HTTP modules are called as part of the ASP.NET request pipeline. For more information, see Introduction to HTTP Modules (http://go.microsoft.com/fwlink/?LinkId=77954&clcid=0x409).

Integrating with ASP.NET forms authentication puts additional requirements on the authentication provider. In addition to registering the various elements in the Web.config file, the membership provider, role manager, and HTTP module must be programmed to interact with Search Server 2008 and ASP.NET methods, as indicated in the following table:

Category Description

Membership provider

To work with Search Server 2008, the membership provider must implement the following methods:

  • GetUser (String) Search Server 2008 calls this method to resolve user names during invitations and to get the user's display name.

  • GetUserNameByEmail Search Server 2008 calls this method to resolve user names in invitations.

  • FindUsersByName, FindUsersByEmail Search Server 2008 calls these methods to populate the user picker control on the Add Users page. If the membership provider returns no users, the picker will not function and administrators will have to type the user name or e-mail address in the Add User text box.

Role manager

The role manager must implement the following methods:

  • RoleExists Search Server 2008 calls this method during invitations to verify that a role name exists.

  • GetRolesForUser Search Server 2008 calls this method at access check to gather the roles for the current user.

  • GetAllRoles Search Server 2008 calls this method to populate the group and role picker. If the role provider returns no groups or roles, the Search Server 2008 picker will not function and the administrator will have to type the name of the role in the Add User text box.

HTTP module

The HTTP module must handle the following events:

  • AuthenticateRequest This event is called when ASP.NET is ready to authenticate the user. The Web SSO module must unpack the user's authentication cookie and set the HttpContext.User object with the identity of the current user.

  • EndRequest This is the last event in the ASP.NET pipeline. This event is called just before it returns the code to the client. The Web SSO module must capture 401 responses coming from Search Server 2008 and turn these into an appropriate 302 redirect for authentication to the Web SSO logon server.

Enabling Anonymous Access

You can enable anonymous access for a Web application in addition to configuring a more secure authentication method. By using this configuration, administrators of sites within the Web application can choose to allow anonymous access. If anonymous users want to gain access to secured resources and capabilities, they can click a logon button to submit their credentials.

Plan authentication for crawling content

To perform successful crawls of content in a Web application, you must understand the authentication requirements of the index component of the index server (also known as the crawler). This section describes how to configure authentication for Web applications to ensure that content in the Web applications can be successfully crawled.

When a farm administrator creates a Web application by using all default settings, the default zone for that Web application is configured to use NTLM. The farm administrator can change the authentication method for the default zone to any authentication method supported by Search Server 2008.

The farm administrator can also extend a Web application one or more times to enable additional zones. Up to five zones can be associated with a particular Web application, and each zone can be configured to use any authentication method supported by Search Server 2008.

By default, the crawler uses NTLM when crawling content. A search service administrator can also create a crawl rule to configure the crawler to use a different authentication method, such as basic authentication or a client certificate, instead of NTLM, when crawling a particular range of URLs. For more information about crawl rules, see Plan to crawl content (Search Server 2008).

Order in which the crawler accesses zones

When planning the zones for a Web application, consider the polling order in which the crawler accesses zones when it is trying to authenticate. The polling order is important, because if the crawler encounters a zone configured to use digest authentication or Kerberos authentication that does not use a standard port (80 or 443), authentication fails and the crawler does not attempt to access the next zone in the polling order. If this occurs, the crawler will not crawl content on that Web application.

Tip Tip:

Ensure that the authentication method configured for the crawler is earlier in the polling order than a zone configured for Kerberos that uses a non-standard port or digest authentication.

The crawler polls the zones in the following order:

  • Default zone

  • Intranet zone

  • Internet zone

  • Custom zone

  • Extranet zone

The following figure shows the decisions that are made by the authentication system when the crawler attempts to authenticate:

How the crawler polls zones

Polling order used by the crawler

The following table describes the actions associated with each callout in the figure.

Callout Action

1

Crawler attempts to authenticate by using the default zone.

Note Note:

The crawler always attempts to use the default zone first when it is trying to authenticate.

2

If the authentication methods configured for the crawler and the zone are the same, the crawler is authenticated and continues to the authorization phase. Otherwise, proceed to step 3.

3

If the zone is configured for Kerberos authentication, proceed to step 4. Otherwise, proceed to step 5.

4

If the zone is configured to use either port 80 or port 443, the crawler is authenticated and continues to the authorization phase. Otherwise, authentication fails and the crawler does not attempt to authenticate by using another zone. This means the content is not crawled.

5

If there are no more zones in the polling order, authentication fails and the content is not crawled. Otherwise, proceed to step 6.

6

Crawler attempts to authenticate by using the next zone in the polling order. Return to step 2.

If you configure the default zone to use an authentication method that the crawler does not support — for example, Web SSO — you must create at least one additional zone and configure this zone to use certificates, basic authentication, Kerberos protocol using a standard port, or NTLM. If certificates or basic authentication is used to crawl the Web application, the search service administrator must create a crawl rule to configure the crawler to use the appropriate authentication method when crawling that Web application. Consider the following scenario.

Authentication scenario

The farm administrator creates a Web application and configures it to use forms authentication. Because the farm administrator wants the content in the Web application to be crawled and indexed, and because she knows that the crawler requires a zone configured with NTLM, basic authentication, or certificates, the farm administrator extends the Web application and configures the intranet zone to use NTLM.

When the crawler attempts to authenticate by using the default zone, the authentication system discovers that the crawler and the zone are not configured to use the same authentication method. Because the zone is not configured for Kerberos authentication using a non-standard port or digest authentication and there is at least one additional zone in the polling order, the crawler attempts to authenticate by using the intranet zone. Because the intranet zone is configured to use NTLM and the crawler also uses NTLM, then by default authentication succeeds.

Note that, if the farm administrator had configured the intranet zone for basic authentication instead of NTLM, the search service administrator would have to create a crawl rule to configure the crawler to use basic authentication when crawling that particular Web application. Otherwise, authentication would fail and the content would not be crawled. Likewise, if the farm administrator had configured the intranet zone to use a client certificate, the search service administrator would have to create a crawl rule to configure the crawler to use a client certificate when crawling that particular Web application. Additionally, a server administrator must register the client certificate with the index server; otherwise, authentication would fail and the content would not be crawled.

Tip Tip:

Effective planning of authentication for Web applications, and planning to crawl the content that is contained by those Web applications, requires collaboration between farm administrators who create the Web applications and search service administrators who configure the crawler.

Remember that, if you configure a zone to use either basic authentication or certificates and you want the crawler to authenticate by using that zone, the search service administrator must create a crawl rule to configure the crawler to use the same authentication method as the zone that you intend it to authenticate with. Otherwise, the crawler attempts to use the next available zone.

In addition to appropriately configuring the authentication method, you must ensure that the crawler is authorized to crawl content within the Web application. The search service administrator must ensure that the content access account has the Read permission level to content accessed through this zone. Farm administrators can do this by creating a policy that gives the content access account the Read permission level on a particular Web application.

Planning zones for your authentication design

If you plan to implement more than one authentication method for a Web application by using zones, use the following guidelines:

  • Use the default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and other security policies of the default zone are applied. The default zone is the zone that is created when you create a Web application. Typically, the most secure authentication settings are designed for end-user access. Consequently, the default zone will likely be the zone that is accessed by end-users.

  • Use the minimum number of zones that is required by the application. Each zone is associated with a new IIS site and domain for accessing the Web application. Only add new access points when these are required.

  • If you want content within the Web application to be included in search results, ensure that at least one zone is configured to use NTLM, basic, or forms-based authentication. One of these authentication methods is required by the index component to crawl content. Do not create a dedicated zone for the index component unless it is necessary.

Choose methods of authentication allowed in your environment

In addition to understanding how authentication is configured, planning for authentication includes the following:

  • Considering the security context or environment of your Web application in Search Server 2008.

  • Evaluating the recommendations and tradeoffs for each method.

  • Understanding how user credentials and related identity data are cached and consumed by Search Server 2008.

  • Understanding how user accounts are managed.

  • Ensuring that authentication methods are compatible with browsers that are used by users.

Worksheet action

Use the Authentication methods worksheet (http://go.microsoft.com/fwlink/?LinkId=77970&clcid=0x409) to identify which authentication methods you are willing to support in your environment and to record your decisions and recommendations for each. This worksheet will be used when planning authentication methods for individual Web applications in Search Server 2008.

Recommendations for specific security environments

Your choice of authentication methods will be primarily driven by the security context of your application. The following table provides recommendations based on the most common security environments:

Environment | Considerations
Internal intranet | At a minimum, protect user credentials from plain view. Integrate with the user management system that is implemented in your environment. If Active Directory is implemented, use the Windows authentication methods built into IIS.
External secure collaboration | Configure a separate zone for each partner company that connects to the site. Use Web SSO to authenticate against each partner's own identity management system. This eliminates the requirement to create accounts in your own identity management system and also ensures that contributor identities continue to be maintained and validated by partner employers. If a contributor is no longer employed by a partner company, the contributor cannot continue to gain access to your partner application.
External anonymous | Enable anonymous access (no authentication) and allow Read-Only permissions for users who connect from the Internet. If you want to provide targeted or role-based content, you can use ASP.NET forms authentication to register users by using a simple database of user names and roles. Use the registration process to identify users by role (such as doctor, patient, or pharmacist). When users log on, your site can present content that is specific to the user role. In this scenario, authentication is not used to validate credentials or to limit who can access the content. The authentication process merely provides a method of targeting content.

Recommendations and tradeoffs for authentication methods

Understanding the advantages, recommendations, and tradeoffs for each specific authentication method can help you determine which methods to use in your environment. The following table highlights the recommendations and tradeoffs for each authentication method. For more information about each of the Windows authentication methods supported by IIS, see IIS Authentication (http://go.microsoft.com/fwlink/?LinkId=78066&clcid=0x409).

Authentication method Advantages and recommendations Tradeoffs

Windows

  • Authenticate by using existing Active Directory accounts.

  • Simplify user management.

  • Take advantage of Active Directory groups when you configure Search Server 2008 authorization.

  • Avoid writing custom code.

  • Each of the methods has its own associated pros and cons.

  • Some IIS authentication protocols are not supported by all Web browsers.

ASP.NET forms

  • Set up Search Server 2008 in an environment that does not use Active Directory (does not require Windows accounts).

  • Authenticate against two or more different identity management systems when you are creating partner applications.

  • Implement a custom authentication scheme by using arbitrary criteria.

  • Authenticate users coming from the Internet.

  • Requires customization of the Web.config file.

  • Subject to replay attacks for the lifetime of the cookie, unless using SSL Transport Layer Security (TLS).

Web SSO

  • Implement Search Server 2008 in an environment that uses federated authentication to secure digital identities across organizations and security environments.

  • Implement Search Server 2008 in an environment that provides SSO to services that are running on different platforms, including environments that do not use Active Directory.

  • Take advantage of AD FS.

  • Authenticate against two or more different identity management systems when you create partner applications.

  • Requires an existing federated authentication system.

  • Requires customization of the Web.config file.

  • AD FS requires SSL. Other SSO systems might have other requirements.

Management of user identity information

How user credentials and other identity information is processed and used by Search Server 2008 can influence your decision about which of the authentication options is best for your intended purpose. This section details how user identity information is processed in the following categories:

  • Binary IDs How user binary identifiers (IDs) are created or used by Search Server 2008.

  • Caching The process of retaining a user's identity for a while to avoid repeating the authentication process for each request.

  • Role and group membership In addition to determining who users are, the authentication process also determines which groups or roles a user belongs to. This information is used during the authorization process to determine which actions a user has permissions to perform. For the purpose of authorization, Search Server 2008 treats Active Directory groups and ASP.NET roles as the same kind of entity.

The following table details how Search Server 2008 manages user binary IDs, cached user data, and role and group membership data depending on which authentication method is used:

Item | Windows authentication | ASP.NET forms and Web SSO
Binary IDs | Search Server 2008 uses the Windows security identifier (SID). | Search Server 2008 creates a unique binary ID by combining the provider name with the user name.
Caching | User credentials are cached and managed by IIS, Internet Explorer, and Windows. | ASP.NET uses an encrypted cookie to keep the user's credentials during a session.
Role and group membership | Windows maintains the list of Active Directory domain groups the user belongs to in the access token. Search Server 2008 uses information that is stored in the access token. | When a role manager is registered, Windows SharePoint Services uses the standard role manager interface to gather group information about the current user. Each ASP.NET role is treated like a domain group by the authorization process. ASP.NET can cache the roles the user belongs to in a cookie, depending on the settings that are configured in the Web.config file.

Management of user accounts

Understanding how Search Server 2008 handles typical user account management tasks can also influence which authentication method you choose. Generally, users who are members of an authentication provider in one zone can manage accounts across all zones as long as they are granted permissions. The information in the following list applies regardless of which authentication method is implemented:

  • Adding and inviting new users You can add or invite a new user from any zone and all authentication methods that are configured if the membership provider and role manager are registered in the current Web.config file. When you add a new user, Search Server 2008 resolves the user name against the following sources in the following order:

    • The UserInfoList table that is stored by Search Server 2008. User information will be in this list if users have already been added to another site.

    • The authentication provider that is configured for the current zone. For example, if a user is a member of the authentication provider that is configured for the default zone, Search Server 2008 first checks this associated membership provider.

    • All other authentication providers.

  • Deleting users User accounts are marked as deleted in the Search Server 2008 database. However, the user record is not removed.

Some user account management behavior within Search Server 2008 differ, depending on the authentication provider. The following table highlights several common user account tasks that differ depending on the authentication method that is implemented:

Task | Windows authenticated accounts | ASP.NET forms-authenticated and Web SSO-authenticated accounts
Adding and inviting new users | Search Server 2008 validates user identities by using Active Directory. | Search Server 2008 calls the membership provider and the role manager to verify that the user and roles exists.
Changes to logon names | Updated user names are automatically recognized by Search Server 2008. New entries are not added to the UserInfoList table. | You must delete the old user name and then add the new user name. Permissions cannot be migrated.
Logging on | If Integrated Windows authentication (Kerberos protocol or NTLM) is used and the browser is configured to automatically log on, users do not have to manually log on to SharePoint sites. By default, Internet Explorer is configured to automatically log on to intranet sites. If a logon is required (for example, sites that require a different set of credentials), users are prompted only for a user name and password. However, if basic authentication is used, or the user is using a browser that is not configured to automatically log on, users might be prompted for logon credentials when they access a SharePoint site. | Search Server 2008 provides a standard logon page for use with forms authentication. This page includes the following fields: user name, password, sign in automatically (to persist the cookie). You can create your own logon page to add logon controls (for example, create a new account, or reset password).

Browser support

Not all browsers work with each authentication method that is supported. Before selecting authentication methods to allow in your environment, determine which browsers you have to support. Then, determine which authentication methods are supported by the browsers. Internet Explorer works with each supported authentication method. Additional browsers that are supported by Search Server 2008 include the following:

  • Netscape 8.0

  • Netscape 7.2

  • Mozilla 1.7.12

  • Firefox 1.5

  • Safari 2.02

Worksheet

Use the following worksheet to record which authentication methods are appropriate for your environment:

  • Authentication methods worksheet (http://go.microsoft.com/fwlink/?LinkId=77970&clcid=0x409)

The following table represents an example of a completed worksheet:

Authentication method | Allow | Don't allow | Notes and recommendations
Anonymous |  | x |
Basic |  | x |
Digest |  | x |
Certificates |  | x |
NTLM (Integrated Windows) | x |  | "Use NTLM for all department sites except finance."
Kerberos (Integrated Windows) | x |  | "Use Kerberos authentication for sites with a high security service level agreement."
ASP.NET forms | x |  | "Use forms authentication to allow partner company access to sites hosted in the partner extranet. We currently allow authentication against the following identity management systems: Active Directory, LDAP. Work with Sidney Higa to develop authentication settings for use with forms authentication."
Web SSO | x |  | "Use this method for partner applications only if a partner company is participating in federated identity management systems. See David Jones for more information."

Additional Notes: "Work with Denise Smith to sign off on all authentication settings for SharePoint Web applications prior to implementing."

See Also

Concepts

Plan for authentication (Search Server 2008)
Plan authentication settings for Web applications (Search Server 2008)
Authentication samples (Search Server 2008)


Plan authentication settings for Web applications (Search Server 2008)
DropDown image

Updated: 2009-04-16

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Plan authentication settings

  • Plan authentication exclusions

  • Worksheet

This article discusses the authentication configuration settings that need to be planned for individual Web applications in Search Server 2008. Use this article with the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409). Complete a separate worksheet for each of the following elements that are a part of your solution design in Search Server 2008:

  • New or extended Web applications in Search Server 2008.

  • Additional zones within a Web application (other than the default zone). Include zones that are created for the search account.

Plan authentication settings

This section discusses each of the settings on the Edit Authentication page of the Central Administration Web site. To get to this page, on the Application Management page, in the Application Security section, click Authentication providers. Click the zone that you want to modify authentication settings for. The Edit Authentication page opens.

Depending on the authentication options you choose, you might be able to specify your authentication settings directly when you create or extend the Web application in Search Server 2008. However, not all options are available when you initially create or extend a Web application. If you cannot configure authentication when you create or extend the Web application, you can accept the default authentication settings initially and then edit the settings on the Edit Authentication page.

Authentication type

Select the method that you want to use. If you are planning to allow anonymous access instead of implementing an authentication method listed in this section, select Windows authentication.

If you select Windows, specify the Windows authentication method in the IIS Authentication Settings section of the Edit Authentication page. If you select Forms or Web single sign on, the options on the Edit Authentication page change to allow you to enter the membership provider name and the role manager name.

If you want to use Certificate authentication or Kerberos authentication, review the following table to identify the additional configuration steps required to configure these methods.

Authentication method Additional configuration Specialized roles

Certificates

  1. Select Windows authentication in Central Administration.

  2. Configure Internet Information Services (IIS) for certificates.

  3. Enable Secure Sockets Layer (SSL).

  4. Obtain and configure certificates from a certification authority (CA).

Microsoft Windows Server 2003 administrator, to obtain and configure certificates

Kerberos (Integrated Windows)

  1. Select Kerberos authentication in Central Administration.

  2. Configure a Service Principal Name (SPN) for the domain user account that is used for the application pool identity (application pool process account).

  3. Register the SPN for the domain user account in Active Directory.

IIS administrator

Worksheet action

Record the additional configuration necessary in the Additional Configuration section of the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409).

Anonymous access

Indicate whether anonymous access is allowed. If you selected Forms or Web single sign-on in the Authentication Type section, select the Enable anonymous access check box.

Client integration

You can disable client integration, which removes features that start client applications. This is the optimal configuration for some scenarios, such as publishing read-only content to the Web for anonymous access. Additionally, if you select forms authentication or Web Single Sign-On (SSO) authentication, client integration is set to No by default.

If you have installed Microsoft Office SharePoint Server 2007 with Service Pack 2 (SP2) , client integration is supported except for Outlook Integration. All other client integration is supported including SharePoint Designer authoring.

If you have not installed Search Server 2008 with SP2, client integration is disabled by default when you use forms-based authentication. This is because client integration does not natively support forms-based authentication prior to Search Server 2008 with SP2.

Note Note:

Client integration is disabled by default when you use forms-based authentication. This is because client integration does not natively support forms-based authentication. You might be able to use many client integration features with forms-based authentication, and there are workarounds available to implement varying levels of client integration functionality with forms-based authentication. However, if published workarounds are inadequate, or if you find unexpected issues using workarounds, we do not provide support and there are no product changes to address these issues. If you plan to use client integration with forms-based authentication, you must fully test any available solutions or workarounds to determine if the performance and functionality are acceptable in your environment.

Product Support can provide commercially reasonable support to help you troubleshoot published workarounds.

Expected behaviors when client integration is disabled

When client integration is disabled, sites behave in the following ways:

  • Links that start client applications are not visible.

  • Documents are opened in the browser. Documents cannot be opened by client applications.

  • Users cannot edit documents on the site directly from the client applications. However, users can download the document, edit the document locally, and then upload the document.

The following table lists specific menu commands and features that are not available when client integration is disabled.

Category | Command or feature that is unavailable
Toolbars | New document Work in Microsoft Office Outlook Open in Windows Explorer Export to spreadsheet Open with Database Program
Editing documents | Edit in Microsoft Office applications such as Word and Excel.
Views | Explorer view Create an Access view
Picture libraries | Upload multiple Edit picture Download Send to
Slide libraries | Publish slide Send to Microsoft Office PowerPoint
Other | Discuss Connect to Office Outlook

Behaviors of specific authentication methods

In addition to the deployment scenario (such as publishing read-only content), the choice of authentication method might determine how to configure client integration. Some authentication methods behave differently with client applications. In some cases, the behavior depends on whether client browsers are configured to use persistent cookies or session cookies.

The following table summarizes the potential behaviors of client integration when used with specific authentication methods.

Authentication method Behavior

Basic

Users are prompted to enter their credentials each time they access a document. Other features might also require that they enter their credentials again.

ASP.NET forms and Web SSO

If the following conditions are true, a persistent cookie is created:

  • The authentication provider supports persistent cookies.

  • The user clicks Sign me in automatically when they log in.

The persistent cookie is shared by all applications that use the same cookie store and the user can open documents in the client applications. The persistent cookie is created with a default time-out value of 30 minutes. This value can be changed by adding or updating the time-out parameter in the forms node in the Web.config file. For example:

<forms loginUrl="login.aspx" name=".ASPXFORMSAUTH" timeout="100" />

When the cookie expires, client integration stops working. If users are in a browser, they will be prompted to re-enter credentials.

If the authentication provider does not support persistent cookies or the user did not click Sign me in automatically when they logged in, a session cookie is used. A session cookie is only accessible by the browser. The user will not be able to open document directly in the client applications.

If the authentication provider does not provide support for persistent cookies or if persistent cookies are not allowed in your environment, turn off client integration. For example, Active Directory Federation Services (AD FS) does not provide support for persistent cookies.

Anonymous

When opening a document, users are repeatedly prompted for their credentials. If they click Cancel in the authentication dialog box 10 times, the site might open the document by using the client application. Because of this poor experience, it is recommended that client integration be turned off for anonymous access scenarios.

Using the Windows Vista operating system with Internet Explorer 7

In Windows Vista, Internet Explorer 7 includes an additional security feature called protected mode. By default, protected mode is enabled for the Internet, Intranet, and Restricted Sites zones. Because this feature places persistent cookies in a location that prevents sharing across applications, client integration does not work as intended.

To configure Internet Explorer 7 to work with client integration, do one of the following:

  • Disable protected mode.

  • If protected mode is enabled, add SharePoint sites to the Trusted sites zone in Internet Explorer.

For information about disabling protected mode, see "Configuring Protected Mode" in Understanding and Working in Protected Mode Internet Explorer (http://go.microsoft.com/fwlink/?LinkId=78098&clcid=0x409).

Testing client integrations settings

If you are uncertain about how to configure the client integration setting, test the results in a test environment before deploying sites into production. If this setting is changed after it is applied, sites and client applications might behave unusually.

Worksheet action

On the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409), in the Enable Client Integration section, select Yes or No.

Settings for ASP.NET forms authentication and Web SSO

If you are implementing ASP.NET forms authentication or Web SSO, you must develop the configuration settings to insert into the applicable Web.config files. See Authentication samples (Search Server 2008) to review examples of properly configured strings for several common scenarios.

Worksheet action

On the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409), enter the following two types of information:

  • Name The name of the membership provider, role manager, and HTTP module (if applicable). These names appear in the Central Administration site.

  • Web.config configuration Paste the appropriate configuration strings into the worksheet. These strings can be copied from the worksheet into the Web.config files when the Web application is deployed.

Ensure that the MembershipProvider name and RoleManager name you registered in the Web.config file is the same as the name that you entered in the Central Administration authentication.aspx page. If you do not enter the role manager in the Web.config file, the default provider specified in the machine.config file might be used instead.

For example, the following string in a Web.config file specifies a SQL membership provider:

<membership defaultProvider="AspNetSqlMembershipProvider">

For more information about requirements for membership providers and role managers, see "Connect to identity management systems that are not based on Windows or that are external" in Plan authentication methods (Search Server 2008).

Plan authentication exclusions

If you are implementing ASP.NET forms authentication or Web SSO, you need to plan for authentication exclusions. If you are implementing Windows authentication, you do not need to read this section.

When you create or extend a Web application or when you add a zone to a Web application, IIS creates a new Web site. Authentication settings that are registered in the Web.config file for this Web application are inherited by virtual directories below the Web site. Virtual directories that are added below a Web application in Search Server 2008 are not managed by Search Server 2008 and are considered to be excluded virtual directories.

If you are implementing ASP.NET forms authentication or Web SSO and you plan to add virtual directories below these Web sites, you need to decide whether you want these excluded virtual directories to inherit the ASP.NET forms authentication or Web SSO settings.

Worksheet action

On the Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409), indicate whether excluded virtual directories will be added in IIS beneath the Web site that corresponds to this Web application in Search Server 2008. If excluded virtual directories will be added, indicate whether authentication settings should be inherited.

Use the following procedure to configure IIS so authentication settings are not inherited.

Configure IIS so authentication settings are not inherited

  1. Add a new IIS virtual directory beneath the IIS Web site that corresponds to the applicable Web application or zone in Search Server 2008.

  2. In IIS Manager, right-click the new virtual directory, and then click Properties.

  3. Click the Virtual Directory tab.

  4. Click Create (this makes the virtual directory an application).

  5. Click Configuration.

  6. Select the wildcard application maps, and then click Remove.

  7. Click Yes, and then click OK.

  8. Create a new Web.config file at the root of the new virtual directory file system path, and add the following entries:

    CopyCode image Copy Code
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>
 <system.web>
  <httpModules>
   <clear />
  </httpModules>
  <httpHandlers>
   <clear />
  </httpHandlers>
 </system.web>
</configuration>

Worksheet

Use the following worksheet to plan and record configuration settings for each of your Web applications in Search Server 2008.

  • Web application authentication settings worksheet (http://go.microsoft.com/fwlink/?LinkID=73334&clcid=0x409).


Authentication samples (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This article includes sample configuration settings for several common forms-based authentication and Web single sign-on (SSO) authentication providers.

In this article:

  • SQL membership provider

  • Active Directory membership provider

  • LDAP membership provider

  • Web SSO with AD FS

SQL membership provider

The following table provides examples of Web.config file entries for using ASP.NET forms-based authentication to connect to a SQL membership provider.

Configuration steps Description and example Web.config file entries

Turn on ASP.NET forms-based authentication.

You can set the authentication type for a particular zone to forms-based authentication on the Edit Authentication page on the Search Central Administration Web site.

This automatically changes the mode specified in the authentication element of the Web.config file for that zone to forms.

For example:

CopyCode image Copy Code
<authentication mode="Forms">
</authentication>

Register the membership provider.

If you are using Microsoft SQL Server database software on the local server as your membership provider database, and you specify AspNetSqlMembershipProvider for the membership provider name, you might not have to make any additional changes to the Web.config file. In this scenario, if the machine.config file has the correct configuration for the AspNetSqlMembershipProvider, you can use it for Windows SharePoint Services without making any changes.

If the default configuration in the machine.config file does not apply (for example, if you want to use a SQL Server database on a remote server), you must edit the Web.config files for both the Web application and the Central Administration Web site to specify the connection information in the connectionStrings element for the membership provider database.

For example:

<connectionStrings>

<add name="SqlProviderConnection" connectionString="server=SQLSERVERMACHINE;database=aspnetdb;Trusted_Connection=True" />

</connectionStrings>

Replace SQLSERVERMACHINE with the name of server computer on which you have installed the SQL Server membership database.

Next, add the membership and providers elements to register the membership provider in the Web.config file. Because a default provider is already registered in the machine.config file, you must include a <remove> element in front of the <add> element.

For example:

<membership defaultProvider="AspNetSqlMembershipProvider">

<providers>

<remove name="AspNetSqlMembershipProvider" />

<add connectionStringName="SqlProviderConnection" name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

The membership element must be included within the system.web element of the Web.config file for both the Web application and the Central Administration site.

Register the role manager (optional).

You can use the default role provider for ASP.NET by adding a roleManager element to the system.web element of the Web.config file. For example:

CopyCode image Copy Code
<roleManager enabled="true" />

The previous syntax uses the AspNetSqlRoleProvider, which is defined in the machine.config file. This role manager can connect to the ASPNETDB database in either the local or remote instance of SQL Server. If you want to use a SQL Server database on a remote server as your role provider database, you must edit the Web.config file to specify the connection information for the remote database server.

For example:

<connectionStrings>

<add

name="SqlProviderConnection"

connectionString="server=SQLSERVERMACHINE; database=aspnetdb; Trusted_Connection=True"

/>

</connectionStrings>

Replace SQLSERVERMACHINE with the name of the remote server that hosts the SQL database. You can specify the same connectionStringName element value for both the membership provider and role manager. Therefore, you do not have to add a new connectionStrings element for the role provider. However, if you want to use a different database for the role provider, you must add a separate connectionStrings element for the role provider.

Next, you must add the roleManager and providers elements to register the roleManager provider in the Web.config. Because a default provider is already registered in the machine.config file, you must include a <remove> element in front of the <add> element.

For example:

<roleManager enabled="true" defaultProvider="AspNetSqlRoleProvider">

<providers>

<remove name="AspNetSqlRoleProvider" />

<add connectionStringName="SqlProviderConnection" applicationName="/" description="Stores and retrieves roles data from the local Microsoft SQL Server database" name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

The roleManager element must be included within the system.web element of the Web.config file for both the Web application and the Central Administration Web site.

Register the HTTP module.

Not applicable

Active Directory membership provider

The following table provides examples of Web.config file entries for using ASP.NET forms-based authentication to use an Active Directory directory service membership provider.

Note Note:

This will only work in a scenario with a single domain.

Configuration steps Description and example Web.config file entries

Turn on ASP.NET forms-based authentication.

You can set the authentication type for a particular zone to forms-based authentication on the Edit Authentication page in Central Administration.

This automatically changes the mode specified in the authentication element of the Web.config file for that zone to forms.

For example:

CopyCode image Copy Code
<authentication mode="Forms">
</authentication>

You can also specify the logon page URL in the forms element, for example:

CopyCode image Copy Code
<authentication mode="Forms">
    <forms loginUrl="/_layouts/login.aspx"></forms>
</authentication>

Register the membership provider.

If you want to use an Active Directory server for a membership provider, you must edit the Web.config file to register the membership provider. To do this, you must specify the connection information to the Active Directory server in the connectionStrings element.

For example:

<connectionStrings>

<add name="ADConnectionString"

connectionString=

"LDAP://DirectoryServer/CN=Users,DC=DirectoryServer " />

</connectionStrings>

Replace DirectoryServer with the name of membership directory server.

<membership defaultProvider="MembershipADProvider">

<providers>

<add name="MembershipADProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

connectionStringName="ADConnectionString"/></providers>

</membership>

Note Note:

The previous example does not specify account credentials. If you do not specify account credentials, your application's process identity is used to access Active Directory.

If another account is required to access Active Directory, you can specify different account credentials in the connectionUsername and connectionPassword attributes, which means that you are supplying the user name and password in plaintext. As a result, we recommend that you encrypt this configuration section. For more information, see the following articles:

  • How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI (http://go.microsoft.com/fwlink/?LinkId=78123&clcid=0x409)

  • How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA (http://go.microsoft.com/fwlink/?LinkId=76778&clcid=0x409)

Register the role manager (optional).

Register the HTTP module.

Not applicable

LDAP membership provider

The following table provides examples of Web.config file entries for using ASP.NET forms-based authentication with a Lightweight Directory Access Protocol (LDAP) membership provider.

Configuration steps Description and example Web.config file entries

Turn on ASP.NET forms-based authentication.

You can set the authentication type for a particular zone to forms-based authentication from the Edit Authentication page in Central Administration.

This automatically changes the mode specified in the authentication element of the Web.config file for that zone to forms.

CopyCode image Copy Code
<system.web>
 <!-mode=[Windows|Forms|Passport|None]>
 <authentication mode="Forms" />
</system.web>

Register the membership provider.

The membership element must be included within the system.web element of the Web.config file.

<membership defaultProvider="LdapMembershipProvider">

<providers>

<add

name="LdapMembership"

type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"

server="DC"

port="389"

useSSL="false"

userDNAttribute="distinguishedName"

userNameAttribute="sAMAccountName"

userContainer="CN=Users,DC=userName,DC=local"

userObjectClass="person"

userFilter="(|(ObjectCategory=group)(ObjectClass=person))"

scope="Subtree"

otherRequiredUserAttributes="sn,givenname,cn"

/>

</providers>

</membership>

You will have to change the values specified for the server and userContainer attributes to match your environment.

Register the role manager (optional).

<roleManager defaultProvider="LdapRoleProvider" enabled="true" cacheRolesInCookie="true" cookieName=".PeopleDCRole">

<providers>

<add

name="LdapRoleProvider"

type="Microsoft.Office.Server.Security.LDAPRoleProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"

server="DC"

port="389"

useSSL="false"

groupContainer="DC=userName,DC=local"

groupNameAttribute="cn"

groupMemberAttribute="member"

userNameAttribute="sAMAccountName"

dnAttribute="distinguishedName"

groupFilter="(ObjectClass=group)"

scope="Subtree"

/>

</providers>

</roleManager>

You will have to change the values specified for the server and groupContainer attributes to match your environment.

Register the HTTP module.

Not applicable

Web SSO with AD FS

The Microsoft Windows Server 2003 R2 operating system introduces Active Directory Federation Services (AD FS), which enables organizations to securely share a user's identity information. AD FS provides Web single sign-on (SSO) technologies to authenticate a user to multiple Web applications during a single online session.

The following two membership and role provider pairs are included with AD FS:

  • SingleSignOnMembershipProvider/SingleSignOnRoleProvider The standard membership provider and role provider included with Windows Server 2003 R2.

  • SingleSignOnMembershipProvider2/SingleSignOnRoleProvider2 The membership provider and role provider that operate in partial trust environments. These providers are included in Service Pack 2 of Windows Server 2003 R2.

SingleSignOnMembershipProvider/SingleSignOnRoleProvider

The following table provides examples of Web.config file entries for a Web SSO AD FS environment that uses the standard provider.

Configuration steps Description and example Web.config file entries

Turn on ASP.NET forms-based authentication.

CopyCode image Copy Code
<system.web>
 <!-mode=[Windows|Forms|Passport|None]>
 <authentication mode="Forms" />
</system.web>

Register the membership provider.

<membership defaultProvider="SingleSignOnMembershipProvider">

<providers>

<add

name="SingleSignOnMembershipProvider"

type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

fs="https://FEDERATIONSERVER/adfs/fs/federationserverservice.asmx"

/>

</providers>

</membership>

For the fs attribute, replace FEDERATIONSERVER with the actual server name.

The membership element must be included within the system.web element of the Web.config file.

Register the role manager (optional).

<roleManager enabled="true" defaultProvider="SingleSignOnRoleProvider">

<providers>

<add

name="SingleSignOnRoleProvider"

type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

fs="https://FEDERATIONSERVER/adfs/fs/federationserverservice.asmx"

/>

</providers>

</roleManager>

For the fs attribute, you will have to replace FEDERATIONSERVER with the actual server name.

Register the HTTP module.

<httpModules>

<add name="Identity Federation Services Application Authentication Module" type="System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null" />

</httpModules>

SingleSignOnMembershipProvider2/SingleSignOnRoleProvider2

If you are implementing the second AD FS provider set, the settings for registering the membership provider and role manager are different. The following table provides examples of Web.config file entries for a Web SSO AD FS environment that uses the provider that operates in partial trust environments.

Configuration steps Description and example Web.config file entries

Turn on ASP.NET forms-based authentication.

CopyCode image Copy Code
<system.web>
 <!-mode=[Windows|Forms|Passport|None]>
 <authentication mode="Forms" />
</system.web>

Register the membership provider.

<membership defaultProvider="SingleSignOnMembershipProvider2">

<providers>

<add name="SingleSignOnMembershipProvider2"

type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

fs=https://FEDERATIONSERVER/adfs/fs/federationserverservice.asmx

/>

</providers>

</membership>

For the fs attribute, replace FEDERATIONSERVER with the actual server name.

The membership element must be included within the system.web element of the Web.config file.

Register the role manager (optional).

<roleManager enabled="true" defaultProvider="SingleSignOnRoleProvider2">

<providers>

<add

name="SingleSignOnRoleProvider2"

type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

fs="https://FEDERATIONSERVER/adfs/fs/federationserverservice.asmx"

/>

</providers>

</roleManager>

For the fs attribute, you will have to replace FEDERATIONSERVER with the actual server name.

Register the HTTP module.

<httpModules>

<add name="Identity Federation Services Application Authentication Module" type="System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null" />

</httpModules>


Plan for data protection and recovery (Search Server 2008)
DropDown image

Updated: 2009-04-28

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Data protection and recovery features in Search Server 2008

  • Additional data protection and recovery tools

  • Service level agreements

  • Data protection and recovery strategy

Data protection and data recovery processes support the following business needs:

  • Keeping and being able to review more than one version of an item or site.

  • Capturing and recovering deleted items or sites.

  • Archiving data for legal, regulatory, or business reasons.

  • Restoring systems if there are unexpected hardware or software failure (disaster recovery).

Data protection and recovery features in Search Server 2008

Microsoft Search Server 2008 includes the following features for data protection and recovery:

  • Versioning: Users can lose data by overwriting a document. Versioning enables users to keep multiple copies of the same document in a document library. In the event of an unwanted change, an overwritten document, or document corruption, the user can easily restore the earlier version. The versioning offered in SharePoint Products and Technologies is often known as content versioning. For more information, see Protect and restore content by using Recycle Bins and versioning (Search Server 2008).

    Versioning does not support site versioning, although you can use other tools to capture and refer to previous versions of a site. See Site Versioning later in this article.

  • Recycle Bin: Search Server 2008 includes a two-stage Recycle Bin. The first-stage Recycle Bin gives site end-users the appropriate permissions to recover accidentally deleted files, documents, list items, lists, and document libraries. The second-stage Recycle Bin enables site collection administrators to recover items that have been deleted from Recycle Bins. For more information, see Protect and restore content by using Recycle Bins and versioning (Search Server 2008).

    The Recycle Bin does not support recovering deleted sites, although you can use other tools to capture and recover deleted sites. See Protecting Sites From Deletion later in this article.

  • Backup and recovery: You can use the Stsadm command-line tool or the Central Administration Web site to back up and recover farms, databases, Web applications, and site collections. There are also many Microsoft and third-party tools that you can use to back up and recover data. For more information, see Plan for backup and recovery (Search Server 2008).

Additional data protection and recovery tools

In addition to using built-in features, enterprises often use the following tools to protect and recover data:

  • Site versioning: In site versioning, you use a Microsoft SQL Server database snapshot to capture the current look, feel, and content of a site. A database snapshot is not a backup. Moreover, a site that you have returned to a previous version by using a database snapshot is read-only and will not function without the current live database. For more information, see Use alternative methods to back up and restore content (Search Server 2008).

  • Protecting sites from deletion: You can write code or use a tool to detect the Web Delete event that is generated when a site is deleted, and then, at that point, back up the site by using the Stsadm export option. Detecting Web Delete events essentially creates a site-level recycle bin. For more information, see Use alternative methods to back up and restore content (Search Server 2008).

  • Other Microsoft backup and recovery tools: You can use SQL Server backup and recovery tools to protect and recover your databases. You can use Microsoft System Center Data Protection Manager 2007 to protect farms, databases, Web applications, site collections, sites, and documents.

  • Third-party backup and recovery tools: Search Server 2008 can be protected by many third-party backup and recovery tools built on technologies supported by Microsoft, such as the Volume Shadow Copy Service (VSS). To find third-party solutions built by Microsoft partners, visit Solution Finder.

Service level agreements

Information technology groups offer service level agreements (SLAs) to set customer expectations for data protection and recovery. Many IT organizations offer various SLAs that are associated with different chargeback levels. SLAs often vary by kind of site, size of site, dedicated or shared hardware, availability of server-side customizations, whether a site is centrally managed or self-managed, recovery time objective, and recovery point objective.

The following list describes common features of data protection and recovery SLAs.

  • Versioning:

    • Whether offered.

    • Amount of space allocated.

    • Level offered (content or site).

  • Recycle Bins:

    • Whether offered.

    • Space allocated for the first-stage Recycle Bin and the second-stage Recycle Bin.

    • Length of time that items are held before permanent deletion in each Recycle Bin stage.

    • Additional charges for recovering items that have been permanently deleted from the second-stage Recycle Bin.

  • Protecting sites from deletion:

    • Whether offered.

    • Length of time that backups of deleted sites are held before they are deleted.

  • Recovery time objective. Recovery time objective is the goal for how long a data recovery process will take. This includes the interval for search to become current again. Different recovery time objectives are often set for standard circumstances, local emergency, and regional emergency.

  • Recovery point objective. Recovery point objective is the maximum time period between the last available backup and any potential failure point.

Data protection and recovery strategy

You should develop a data protection and recovery strategy for each site or kind of site that you support. For each kind of site, evaluate the following:

  • Do you have to support content versioning?

  • Do you have to support site versioning?

  • Do you have to support Recycle Bins?

  • Do you have to protect sites from deletion?

  • What level of specificity do you have to provide for recovery (farm, database, site collection, site, item)?

  • How large is your maintenance window?

  • How large are your databases now—including your content databases and search databases—and how much and how fast do you think they will grow?

  • What is your fastest recovery time objective?

  • What is your shortest recovery point objective?

  • What is your average recovery point objective?

For information about recommended strategies for specific site types, see Recommendations for data protection and recovery scenarios (Search Server 2008).

See Also

Concepts

Recommendations for data protection and recovery scenarios (Search Server 2008)
Use alternative methods to back up and restore content (Search Server 2008)
Protect and restore content by using Recycle Bins and versioning (Search Server 2008)
Plan for backup and recovery (Search Server 2008)
Plan for authentication (Search Server 2008)


Plan for backup and recovery (Search Server 2008)
DropDown image

Updated: 2009-04-28

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Disaster Recovery

  • Migrating Data

  • Choosing what to protect

  • Choosing backup and recovery tools

The most common business scenarios supported by data backup and recovery are as follows:

  • Disaster Recovery — that is, recovering from an unexpected failure or disaster.

  • Migrating Data between installations as part of a staging process.

Determine which scenarios your business requires you to address, and then determine how you will address each one.

Disaster Recovery

Disaster recovery, which includes planning and preparing for how to restore your Microsoft Search Server 2008 implementation after a failure or disaster, is a key part of business continuance planning and risk management.

When you plan for how you will use backup and recovery for disaster recovery, consider common events, failures, and errors, and also local and regional emergencies.

Common events, failures, and errors

Common events, failures, and errors that require you to back up or recover sites include the following:

  • Accidental or incorrect deletions.

  • Software updates. For a list of product upgrade options, see Upgrade paths (Search Server 2008).

  • Hardware failure.

Circumstances that take a Search Server site offline are best dealt with by setting up a system with redundant components that fails over gracefully. For more information, see Plan for redundancy (Search Server 2008). Moreover, recovering from common failures often involves a combination of redundancy, availability, and backup and recovery techniques.

Local emergencies

Depending on your need for availability, you might want to have redundant farms within your region to which the system can fail over. If you do not have redundant farms, we recommend that you store recent backups offsite so that you can quickly obtain equipment, rebuild, and restore your farm in the event of a fire, flood, or other catastrophic event. A farm-level backup is often appropriate for this purpose.

Regional Emergencies

To prepare contingencies for regional emergencies, you might want to put contracts in place for emergency server rentals in another region. We recommend that you store recent backups outside of your region so that you can quickly obtain equipment, rebuild, and restore your farm. As with local emergencies, a farm-level backup is appropriate for this purpose.

Migrating Data

You can use backups to move data to a different server.

Move Data to a different server

Using backup and recovery to move data to a new server is a common process. When you plan to move content between servers, consider the following:

  • Is this a one-time or recurring action? If it is a one-time action, perform the backup and recovery manually. On the other hand, if you want regularly to move data between servers, plan for an automated and scheduled process, taking into consideration the potential disruption to end-users.

  • Is this a temporary or a permanent move? If you are moving your content permanently to a new server, review the planning information at Plan for performance and capacity (Search Server 2008).

For more information, see Move and migrate servers and server farms (Search Server 2008).

Choosing what to protect

Within a farm, there are many components that require protection:

  • Content stored in SQL Server databases

  • Content stored in external storage devices

  • Shared services, such as the search service database and index

  • Configuration settings for Microsoft Search Server 2008 that are stored in IIS and the configuration database

  • Customizations

  • Binary files for both the operating system and Microsoft Search Server 2008

Protecting content databases

Search Server 2008 content is stored in Microsoft SQL Server databases. We recommend that you back up all content databases by using one of the following tools:

  • Search Server built-in tools

  • SQL Server tools

  • Third-party tools that are built on supported Application Programming Interfaces (APIs) and SharePoint Products and Technologies, such as the Volume Shadow Copy Service (VSS).

Your backup and recovery strategy should address each of these components on the servers in the system.

Protecting content stored in external data sources

An external storage API is available for Search Server 2008. The external storage API lets you store documents or files on an external storage application other than Microsoft SQL Server. You cannot use the backup and recovery tools built in to Search Server 2008 to back up data that is stored in external data sources. However, you can use the Stsadm export and import operations. For more information about export and import, see:

  • Export: Stsadm operation (Windows SharePoint Services)

  • Import: Stsadm operation (Windows SharePoint Services)

Protecting Search

Search content for Microsoft Search Server 2008 is stored in both the [Shared Services Provider name]_Search_DB database and in the search index file. Because search data in the database and index must be synchronized, you should only back up search using SharePoint Products and Technologies tools such as the Stsadm command-line tool, or Central Administration backup and recovery, or tools that are based on the SharePoint VSS, such as Microsoft System Center Data Protection Manager 2007. These tools synchronize the database backup with the search index file backup, and both can be restored together. For more information about these tools, see Choosing backup and recovery tools later in this article.

We do not recommend that you back up the search databases by using SQL Server, because the search indexes are not stored in SQL Server and cannot be synchronized with the search database after a database-only backup. If you must restore a search database backed up with SQL Server tools, Search Server must re-create the index and perform a full crawl of the content.

Search consists of the following services:

  • Office SharePoint Server Search. Enables searching of content that is defined as searchable.

  • Windows SharePoint Services Help Search (optional). Enables searching of the Help system that is built into Search Server 2008.

Each service is used to crawl, index, and query content, and each service uses a separate index.

You must back up the search databases and indexes in the system to be able to restore search.

Protecting SSP databases

Configuration information for Search Server 2008 SSPs is stored in Microsoft SQL Server databases. We recommend that you back up all SSP databases, except Search databases by using any of the following tools:

  • Office SharePoint Server built-in tools

  • SQL Server tools

  • Third-party tools that are built on supported APIs and SharePoint Products and Technologies, such as the VSS.

The tool that you select to back up your SSP databases determines the granularity with which you can restore objects from a database. For more information about choosing tools, see Choosing backup and recovery tools later in this article.

Protecting configuration settings

To make sure that you can restore your configuration after a disaster, you must protect IIS configuration settings and configuration settings for Search Server 2008.

Protecting and recovering IIS configuration settings

You can set IIS configurations in IIS Manager or on the Central Administration Web site. IIS configurations are stored in the IIS metabase on each front-end Web server in the system.

You can also set IIS configurations on any front-end Web computers that are running Microsoft SQL Server Reporting Services.

IIS configurations include the following:

  • Application pool settings, including service accounts

  • HTTP compression settings

  • Time-out settings

  • Custom Internet Server Application Programming Interface (ISAPI) filters

  • Computer domain membership

  • Internet Protocol security (IPsec) settings

  • Network load balancing settings

  • Host header entries

  • Secure Sockets Layer (SSL) certificates

  • Dedicated IP address settings

We recommend that you document all IIS configurations for each front-end Web server, if you can do this, by using a tool that provides Desired Configuration Monitoring (DCM).

Protecting and recovering the configuration database and the Central Administration content database

Configurations in Search Server 2008 are set in Central Administration and stored in the configuration database.

Important Important:

Although the configuration database and the Central Administration content database can be backed up, restoring backups of the configuration database and Central Administration content database taken from a running farm by using the tools built in to SharePoint Products and Technologies or SQL Server is not supported.

This is because data in these databases may not be synchronized with data in other Search Server 2008 or Windows SharePoint Services 3.0 databases. If this data is not synchronized, users might experience various random errors. Therefore, the tools built in to SharePoint Products and Technologies do not recover these databases during a farm-level restore operation.

You can recover a farm, including the configuration database and Central Administration content database, in the following ways:

  • You can use farm-level backups of a running farm taken with System Center Data Protection Manager to recover the complete farm, including the configuration database and Central Administration content database. For more information, see How to Recover a Windows Sharepoint Services Farm (http://go.microsoft.com/fwlink/?LinkId=102831&clcid=0x409).

  • You can restore a backup of the configuration database and Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (Search Server 2008).

If the configuration and Central Administration content databases of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products and Technologies Configuration Wizard or the Psconfig command-line tool.

To protect the configuration database and Central Administration content database:

  • Document all configuration settings and all the customizations so that you can correctly re-create the databases. For more information about how to recover a farm, see Restore a farm after a configuration database problem (Search Server 2008).

  • Consider a redundancy solution, such as clustering or mirroring, for the computer that is running SQL Server that is hosting the configuration database. For more information about how to use mirroring, see Using Database Mirroring with Office SharePoint Server and Windows SharePoint Services.

We strongly recommend that you document all configuration settings and all the customizations so that you can correctly re-create the configuration and Central Administration content databases.

Configuration settings in Search Server 2008 that you should document include the following:

  • Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account)

  • Alternate access mapping settings

  • Farm-level search settings

  • External service connection settings

  • Workflow management settings

  • E-mail settings

  • Antivirus settings

  • Usage analysis processing settings

  • Diagnostic logging settings

  • Timer job settings

  • HTML viewer settings

  • Recycle Bin settings and other Web application general settings

  • Administrator-deployed form templates

  • Default quota templates

  • Database names and locations

  • Web application names and databases. Be sure to document the content database names associated with each Web application

  • Crawler impact rules

  • Activated features

  • Blocked file types

Protecting Customizations

Customizations to sites can include the following:

  • Master pages, page layouts and cascading style sheets; these objects are stored in the content database for a Web application.

  • Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, coded workflows, or workflow activities and conditions.

  • Third-party solutions and their associated binary files and registry keys, such as IFilters.

  • Changes to standard XML files.

  • Custom site definitions (Webtemp.xml).

Protecting solution packages

We recommend that you use solution packages when possible to deploy site customizations. A solution is a container for one or more customizations. Solutions can contain features, Web Parts, security policy changes, and other files, together with a detailed guide that allows the automated deployment to the file system by the deployment mechanisms in SharePoint Products and Technologies. Solutions include IFilters. Features are parts of solutions that can be enabled by the server administrator against the farm, a specific Web application, a specific site collection, or a specific Web site. For more information about solutions, see: Solutions Overview.

You can use solution packages to simplify the backup and recovery process. Back up each solution package, both onsite and offsite, and then, in the event of a disaster, redeploy the solution to the appropriate servers.

Protecting customizations that are not packaged as solutions

For systems in which customizations are not or cannot be packaged as solutions, backing up and restoring customizations is a more complex process. The following table lists the locations where customizations are often stored on front-end Web servers.

Location | Description
%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12 | Commonly updated files, custom assemblies, custom templates, and custom site definitions. In particular, the Web.config file is often modified.
Inetpub | Location of IIS virtual directories.
C:\WINNT\assembly | Global assembly cache (GAC). The GAC is a protected operating system location where .NET Framework code assemblies are installed to provide full system access.

Consult with your development team or customization vendor to determine whether your customizations involve additional add-in software or files in other locations. We recommend that you back up these directories by using the Windows Server backup utility.

Protecting binary files

In the event that you must restore a system, we recommend that you reinstall the operating system, Search Server 2008, and software updates. Keep copies of all the operating system, software, and software update media both onsite and offsite.

Choosing backup and recovery tools

The tools that you decide to use for backing up and recovering the system are based on your needs, constraints, and on the service level agreements (SLAs) that you have with your customers.

Key things to consider in determining which tools to use include the following:

  • Backup type supported (full, differential, incremental)

  • Completeness of recovery and types of objects that can be recovered

  • Complexity of managing the solution

  • Ability of the solution to adapt to your maintenance window and database size

In some business situations, you may be able to use a high-availability solution, such as database clustering, log shipping, or mirroring—to meet your data protection and recovery needs. For more information about planning for high-availability solutions, see Plan for availability (Search Server 2008).

Available tools

The following table lists Microsoft tools that you can use for disaster recovery.

Tool Source of tool User Interface Backup type Level of backup and recovery Notes

Search Server 2008 Central Administration

Built-in

Graphical

Full and differential

Farm

Web application

Shared Services Providers (SSPs), including Search database and Search index

Content database

Cannot be used to schedule backups.

As part of a farm backup, can back up the configuration database and the Central Administration content database, but will not restore them. For more information, see Restore a farm after a configuration database problem (Search Server 2008).

Cannot back up directly to tape.

Search Server 2008: Stsadm.exe backup and recovery operations

Built-in

Command line

Full and differential

Farm

Web application SSPs, including Search database and Search index

Content database

Site collection

Can be used with Windows Task Scheduler to schedule backup jobs.

Can back up the configuration database and the Central Administration content database, but will not restore them. For more information, see Restore a farm after a configuration database problem (Search Server 2008).

Cannot back up directly to tape.

Microsoft SQL Server 2005 Backup and Recovery

Graphical

Full and differential

Content database

Configuration database and Central Administration content database

Can be used to schedule backups.

Can back up the configuration database and Central Administration content database, but restoring is not supported. For more information, see Restore a farm after a configuration database problem (Search Server 2008).

Not recommended for use with search, because indexes are not stored in SQL Server. If used for search, requires a full crawl on recovery.

Can back up directly to tape.

Microsoft System Center Data Protection Manager 2007

Incremental

Farm

Database

SSP, including search database and search index

Site

Content item

Can be used to schedule backups.

Can back up files and folders containing customizations.

Can back up directly to tape.

Can back up the configuration database and Central Administration content database, and restore as part of a farm recovery. For more information, see Restore a farm after a configuration database problem (Search Server 2008).

Windows Server 2003 Backup tool (Ntbackup.exe)

Graphical

Full

Specified folder and file

Can be used to schedule backups.

Can back up files and folders containing customizations.

Windows Server 2008 Backup

Graphical

Full

Specified folder and file

You must configure specific registry keys for Windows Server Backup to work. For more information, see Windows SharePoint Services 3.0 does not appear in the list of the components that can be backed up when you use Windows Server Backup in Windows Server 2008 in the Microsoft Knowledge Base.

Built-in backup and recovery tools

Search Server 2008 provides two built-in backup and recovery tools: Central Administration and the Stsadm command-line tool.

The following figure illustrates how built-in Search Server 2008 backup works. A backup is triggered from either Central Administration or the Stsadm command-line tool. The Central Administration application pool writes files to the specified file server and triggers a SQL Server database backup to the same file server. The path provided to the backup is the location of the folder created for the backup (spbr0000, spbr0001, and so on).

Illustration 1: Search Server 2008 built-in backup

Built-in back up and recovery tools

The following table compares the functionality available in the built-in backup and recovery tools.

Functionality | Central Administration | Stsadm command-line tool
Backup the server farm | Yes | Yes
Recover the server farm, except the configuration and Central Administration databases | Yes | Yes
Recover the configuration and Central Administration databases | No | No
Back up Web applications | Yes | Yes
Back up an SSP | Yes | Yes
Back up site collections | No | Yes
Back up content databases | Yes | Yes
Back up customizations | No | No
Schedule backups | No | Yes, if used with Windows Task Scheduler

Performance

Your hardware configuration and the size of the database, site collection, or Web application that you are working with can significantly affect the performance of the built-in backup and recovery tools.

Note Note:

Search databases can become very large. One way to manage the size of your search backup is to ensure that the database index is defragmented. You may want to use the defragmentation script provided in the Microsoft Knowledge Base article How to defragment Windows SharePoint Services 3.0 databases and SharePoint Server 2007 databases (http://go.microsoft.com/fwlink/?LinkId=102795&clcid=0x409).

If your system exceeds the following limits, or if backing up your system exceeds the maintenance window that you have available, we recommend that you consider using external backup and recovery tools, such as Microsoft SQL Server 2005 Backup and Recovery or Microsoft System Center Data Protection Manager 2007.

  • Content databases larger than 100 gigabytes (GB)

  • Site collections that are larger than 15 GB that you want to back up by using the Stsadm command-line tool

Recovering the configuration database and Central Administration content database

Configurations are set in Central Administration and stored in the configuration database.

Important Important:

Although the configuration database and the Central Administration content database can be backed up, restoring backups of the configuration database and Central Administration content database taken from a running farm by using the tools built in to SharePoint Products and Technologies or SQL Server is not supported.

This is because data in these databases may not be synchronized with data in other Search Server 2008 or Windows SharePoint Services 3.0 databases. If this data is not synchronized, users might experience various random errors. Therefore, the tools built in to SharePoint Products and Technologies do not recover these databases during a farm-level restore operation.

You can recover a farm, including the configuration database and Central Administration content database, in the following ways:

  • You can use farm-level backups of a running farm taken with System Center Data Protection Manager to recover an entire farm, including the configuration database and Central Administration content database. For more information, see How to Recover a Windows SharePoint Services Farm.

  • You can restore a backup of the configuration database and Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (Search Server 2008).

If the configuration and Central Administration content databases of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products and Technologies Configuration Wizard or the Psconfig command-line tool.

To protect the configuration database and Central Administration content database:

  • So that you can correctly re-create the databases, document all configuration settings and all your customizations. For more information about recovering a farm, see Restore a farm after a configuration database problem (Search Server 2008).

  • Consider a redundancy solution, such as clustering or mirroring, for the computer running SQL Server that is hosting the configuration database. For more information about using mirroring, see Using Database Mirroring with Office SharePoint Server and Windows SharePoint Services

Central Administration

Central Administration provides an easy way to back up your Search Server 2008 system.

The processes that are running and the accounts that they are running as —the Central Administration application pool and the account that the SQL Server services is running as — must be granted permissions to write to the directory that you are backing up to. To perform a backup, you must be a member of the Farm Administrators group. To run a recovery operation, you must be a farm administrator and a member of the Administrators group on each front-end Web server. For a detailed overview of preparing to back up, see Prepare to back up and restore a farm (Search Server 2008).

You can back up and recover at various levels: The highest level is the entire farm and the lowest level is a content database. Full and differential backups are also available. The backup and recovery jobs for Central Administration are run by the SPTimer service.

Using Central Administration to back up and recover your system provides the following benefits:

  • Ability to back up and recover at the farm, Web application, SSP, and content database level

  • Restorable backups for Search

  • For backups that initially run 17 hours, the system automatically restarts the backup and allots an appropriate amount of time for the process (longer than 17 hours)

Using Central Administration to back up and recover your system has the following limitations:

  • As part of a farm backup, Central Administration backs up but cannot restore the configuration database or Central Administration content database. For more information, see Restore a farm after a configuration database problem (Search Server 2008).

  • Does not provide scheduling functionality.

  • Cannot back up directly to tape; the backup location must be a UNC path or local drive.

  • Does not automatically delete old backup files; you may want to use the backup file deletion script provided in Clean up backup files (Search Server 2008).

  • Does not back up any configuration changes, including:

    • IIS settings including host headers, dedicated IP addresses, and SSL certificates

    • Alternate access mappings

    • The inetpub directory

    • Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account)

    • Farm-level search settings

    • External service connection settings

    • Workflow management settings

    • E-mail settings

    • A/V settings

    • Usage analysis processing settings

    • Diagnostic logging settings

    • Timer job settings

    • HTML viewer settings.

    • Recycle Bin settings and other Web application general settings

  • Does not back up any customizations, including:

    • The %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12 directory

    • Any customizations made to the Web.config file

    • Default quota templates

    • Blocked file types

    • Administrator-deployed form templates

    • Database names and locations

    • Web application names and databases. Be sure to document the content database names associated with each Web application

    • Crawler impact rules

    • Activated features

  • If a backup or recovery job is not successful, the unsuccessful job must be manually deleted from the Timer job list on the Backup and Restore Status page. If the failed job is not deleted manually, subsequent backup or recovery jobs will fail.

For more information about using Central Administration, see the following resources:

  • Back up a farm by using Central Administration (Search Server 2008)

  • Restore a farm by using Central Administration (Search Server 2008)

Stsadm command-line tool

Search Server 2008 includes the Stsadm command-line tool for administration of servers and sites. You can use the Stsadm backup and restore operations to protect and recover your data.

The account that you use to run the Stsadm command-line tool must be a member of the Administrators group on the local computer, as well as a member of the dbowner fixed database role in SQL Server.

The Stsadm command-line tool has the following benefits:

  • Provides the ability to back up and restore at the farm level, Web application level, or site collection level.

  • Provides restorable backups for Search.

  • Can be used with Windows Task Scheduler to schedule backups.

  • For backups that initially run 17 hours, the system automatically restarts the backup and allots an appropriate amount of time for the process to perform (longer than 17 hours).

The Stsadm command-line tool has the following limitations:

  • As part of a farm backup, the Stsadm command-line tool backs up, but cannot restore the configuration database or Central Administration content database. For more information, see Recovering the configuration database and Central Administration content database.

  • Site collection backups affect performance and can cause access errors. They are not designed to be used when the server is under active load. Site collection backups can be slow when working with collections larger than 15 GB. We recommend that you use database backups if you are working with site collections larger than 15 GB.

    Note Note:

    If you want to individually back up a site collection that is larger than 15 GB, we recommend that you move it to its own database, and then use a database backup.

  • Cannot back up directly to tape. The backup location must be a UNC path or local drive.

  • Does not provide automatic deletion of old backup files. You may want to use the backup file deletion script provided in Clean up backup files (Search Server 2008).

  • Does not back up any configuration changes, including:

    • IIS settings including host headers, dedicated IP addresses, and SSL certificates

    • Alternate access mappings

    • The inetpub directory

    • E-mail settings

    • Recycle Bin settings and other Web application general settings

    • A/V settings

    • Usage analysis processing settings

    • Diagnostic logging settings

    • Timer job settings

    • HTML viewer settings

  • Does not back up any customizations, including the following:

    • The %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12 directory

    • Any customizations made to the Web.config file

    • Default quota templates

    • Blocked file types

For more information about the Stsadm command-line tool, see the following resources:

  • Back up a farm by using the Stsadm command-line tool (Search Server 2008)

  • Restore a farm by using the Stsadm command-line tool (Search Server 2008)

External backup and recovery tools

You can protect Search Server 2008 by using other Microsoft backup and recovery tools. These include the following:

  • Microsoft SQL Server 2005

  • Microsoft System Center Data Protection Manager 2007

  • Windows Server Backup tool

Microsoft SQL Server 2005 Backup and Recovery

The SQL Server databases used by Search Server 2008 contain site content and are therefore key components to protect. If your company has database administrators who back up other SQL Server databases, you may want to include the databases used by Search Server 2008 in your standard processes. The following list describes the benefits and limitations of using SQL Server backups.

Benefits:

  • Existing SQL Server data protection strategies can be re-used

  • Full and differential backups can be configured to have added verification

  • Can be faster than Search Server 2008 backups

  • Can back up directly to tape

Limitations:

  • Can back up running instances of the configuration database and Central Administration content database but restoring is not supported. For more information, see Recovering the configuration database and Central Administration content database.

  • Should not be used to back up the search database, because the search indexes are not stored in SQL Server and cannot be synchronized with the search database after a database-only backup.

  • Requires that you manually reattach your databases to Web applications after a recovery.

  • Cannot be used to recover at any level smaller than a database. Recovering a single item using a restored database can be complex.

  • Does not back up any configuration changes, including the following:

    • IIS settings including host headers, dedicated IP addresses, and SSL certificates

    • Alternate access mappings

    • The inetpub directory

    • E-mail settings

    • Recycle Bin settings and other Web application general settings

    • A/V settings

    • Usage analysis processing settings

    • Diagnostic logging settings

    • Timer job settings

    • HTML viewer settings

  • Does not back up any customizations, including the following:

    • The %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12 directory

    • Any customizations made to the Web.config file

    • Default quota templates

    • Blocked file types

For more information about how to use SQL Server backup and recovery, see the following resources:

  • Back up a farm by using SQL Server tools (Search Server 2008)

  • Restore a farm by using SQL Server tools (Search Server 2008)

  • Backing up and Restoring databases in SQL Server

  • Optimizing Backup and Restore Performance in SQL Server

Microsoft System Center Data Protection Manager 2007

Microsoft System Center Data Protection Manager 2007 enables disk and tape-based data protection and recovery for servers in and across Active Directory directory service domains. System Center Data Protection Manager performs replication, synchronization, and recovery point creation for reliable protection and rapid recovery of data by both system administrators and by end-users.

System Center Data Protection Manager can be used to protect Search Server 2008 in addition to Office SharePoint Server 2007; Microsoft SQL Server 2000 SP4, SQL Server 2005 with Service Pack 1 (SP 1), SQL Server 2005 with Service Pack 2 (SP2) or SQL Server 2008; Exchange Server 2003 with SP2 and Exchange Server 2007; Microsoft Virtual Server 2005 R2 with SP1 and its virtual machines; Windows Server 2008 operating system; files on workstations and laptops running Windows XP Professional with SP2 or SP3, and all Windows Vista editions except the Home Edition; files and application data on clustered servers; and the server system state.

The following list describes the benefits of this tool.

Benefits:

  • Provides the ability to back up and restore at the farm, database, Web application, site, or content item level.

  • Provides the ability to back up and restore directories that contain customizations.

  • Can be used to back up and recover the server system state, including IIS configuration settings.

  • Farm-level backups taken while the system is running can be used to recover a farm, including the configuration database and the Central Administration database. For more information, see Recovering the configuration database and Central Administration content database.

  • Can back up to tape.

  • Requires less processing on the server.

  • If System Center Data Protection Manager has not already been purchased for your environment, you may require additional funding and equipment.

  • Protecting search requires scripting. Consult the topics below for updated guidance.

For more information about installing, deploying, and configuring Data Protection Manager, see System Center Data Protection Manager 2007.

System Center Data Protection Manager can be used to recover content items, sites, Web applications, and farms. For more information, see the following resources:

  • White paper: Backing up Search Server 2008 by using System Center Data Protection Manager

  • How to Recover a Windows SharePoint Services Item

  • How to Recover a Windows SharePoint Services Site

  • How to Recover a Windows SharePoint Services Farm

Windows Server Backup

You can use the Windows Server Backup tool to back up your home directories, Web.config file, custom assemblies, customizations, site definitions, and list definitions.

Note Note:

If you are using Windows Server 2008, you must configure specific registry keys for Windows Server Backup to work. For more information, see Windows SharePoint Services 3.0 does not appear in the list of the components that can be backed up when you use Windows Server Backup in Windows Server 2008 in the Microsoft Knowledge Base.

The Windows Server Backup tool has the following benefits:

  • Provides the ability to back up and restore directories that contain customizations; for more information, see Choosing what to protect.

  • Can back up to tape

The Windows Server Backup tool has the following limitation:

  • Cannot be used to back up databases, farms, Web applications, or Search

Third-party solutions and custom tools

Based on the needs of your business, you may want to choose a third-party solution or build a custom tool to meet your backup and recovery needs.

Third-party solutions

To find third-party solutions built by Microsoft partners on technologies supported by Microsoft, visit Solution Finder .

Solutions built on Volume Shadow Copy Service

The Volume Shadow Copy Service (VSS) was introduced in Windows XP and Windows Server 2003. VSS is a framework that facilitates communication between applications, storage subsystems, and storage management applications (including backup applications). This framework enables you to define, persist, and use point-in-time copies of storage data. The Windows SharePoint Services VSS Writer enables a requestor to ask a front-end Web server to provide a VSS backup (full or differential), and Search Server 2008 then points the requestor to the SQL databases and the search index to be backed up by using VSS. For more information about VSS, see the Microsoft Developer Network article Volume Shadow Copy Service. You can download the Volume Shadow Copy Service SDK 7.2 from the Microsoft Download Center.

See Also

Concepts

Recommendations for data protection and recovery scenarios (Search Server 2008)


Recommendations for data protection and recovery scenarios (Search Server 2008)
DropDown image

Updated: 2009-04-28

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

A system-wide strategy for data protection and recovery should include the plans that you have created for the sites and Web applications in your farm, and address the specific scenarios that you support.

Steps in the planning process include the following:

  • Analyze and summarize the data protection and recovery needs of the sites that support your business scenarios.

  • Select tools that enable you to simplify maintenance and administration.

  • Decide whether you will perform farm-level backups. Many administrators will perform farm-level backups, but your farm might be too large to back up within your maintenance window. Moreover, there might be parts of the farm that are not important to your business. Therefore, you might plan to reassemble your farm from lower-level backups.

  • Determine whether your availability infrastructure provides sufficient protection to reduce the quantity of or the level of backups. Some administrators decide to protect the data by using only availability tools.

Note Note:

If you use Search Server 2008 to index content that is stored elsewhere—such as in Web sites, file shares and other locations—you may have no content that is stored in the Search Server farm. However, even in this situation you should consider how to protect your farm configuration and index from catastrophic failure.

For more information about availability, see Plan for redundancy (Search Server 2008).

The topics in this section include the following:

  • Protecting and recovering data for a site (Search Server 2008)

  • Protecting and recovering data when working with software updates (Search Server 2008)

  • Protecting and recovering data in a non-production environment (Search Server 2008)

See Also

Concepts

Plan for backup and recovery (Search Server 2008)
Plan for redundancy (Search Server 2008)


Protecting and recovering data for a site (Search Server 2008)
DropDown image

Updated: 2009-04-28

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Most Microsoft Search Server 2008 sites should follow a similar data protection and recovery strategy. This topic provides basic recommendations for protecting and recovering data for sites.

Versioning

  • Content versioning Recommended. Be sure to provide site owners with a good understanding of the space that is available relative to the number of versions, and work with site owners to ensure that they monitor and manage sites that have versioning turned on.

  • Database snapshot Not recommended. We recommend that you use database snapshots only when you want to protect the look of a site as versions change over time.

Deletion protection

  • Recycle Bin Recommended. We strongly recommend that you enable users to recover deleted items.

  • Site capture Recommended. We strongly recommend that you protect all sites against accidental deletion.

Backup and recovery

Plan to back up your sites regularly. Use the tool that best meets your needs. For more information, see Plan for backup and recovery (Search Server 2008).

If you are using built-in backup and recovery tools, plan to back up at least at the content database level.

How often you back up a site depends on the amount of change to the site and the service level agreements that you have in place.

See Also

Concepts

Protecting and recovering data in a non-production environment (Search Server 2008)
Protecting and recovering data when working with software updates (Search Server 2008)
Plan for backup and recovery (Search Server 2008)


Protecting and recovering data in a non-production environment (Search Server 2008)
DropDown image

Updated: 2009-04-28

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Development environment

  • Staging environment

This article contains recommendations for protecting and recovering data in non-production environments such as development and staging environments.

Development environment

We recommend that you use a source control system to manage code projects in a development environment. We assume that you are not creating code in your source control system and that you are not creating valuable content in a development environment. Therefore, we do not recommend that you protect the data in a development environment.

Versioning

  • Content versioning: Not recommended.

  • Database snapshot: Not recommended.

Deletion protection

  • Recycle Bin: Not recommended.

  • Site capture: Not recommended.

Content backup and recovery

Use a backup and recovery system that supports the source control system.

Farm backup and recovery

Expect to frequently rebuild a development environment or to build new development environments. You may want to keep a server image for installation. Keep all configurations simple and document them thoroughly.

Staging environment

We assume that the staging environment is identical to the production environment. We recommend that you do not protect it with versioning, deletion protection, or backup and recovery.

Versioning

  • Content versioning: Not recommended.

  • Database snapshot: Not recommended.

Deletion protection

  • Recycle Bin: Not recommended.

  • Site capture: Not recommended.

Content backup and recovery

Not recommended.

Farm backup and recovery

Expect to frequently rebuild the staging environment. You may want to keep stored server images for installation. Keep all configurations simple and document them thoroughly. Be sure that customizations are packaged and easy to deploy.

See Also

Concepts

Protecting and recovering data for a site (Search Server 2008)
Protecting and recovering data when working with software updates (Search Server 2008)


Protecting and recovering data when working with software updates (Search Server 2008)
DropDown image

Updated: 2009-04-28

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Back up the SSP

  • Back up databases

  • After backing up, and before you apply a software update

  • Using database backups after a software update

Before applying software updates, you should take your servers offline and then back up the Shared Services Provider (SSP) and all databases related to your environment.

Back up the SSP

Use the full backup operation from Central Administration or the Stsadm command-line tool to back up the SSP. The backup operation includes both the database and configuration settings for the SSP, global search settings, search database, and the content index, also known as the search index files.

Note Note:

Before you back up, verify that the drive that you are backing up to has sufficient free space to back up the whole farm. Even though you are only backing up the SSP that provides search services, the backup operation will fail if you do not have sufficient free space for the whole farm. For more information, see Back up a farm by using built-in tools (Search Server 2008).

Back up databases

The following sections describe recommendations for how to back up each kind of database for Microsoft Search Server 2008.

Configuration database and Central Administration content database

Perform a full backup operation on the configuration database and the Central Administration content database by using either the Stsadm command-line tool or SQL Server tools. If you are using SQL Server tools, use the simple recovery model to truncate your transaction log.

Content databases

Perform a full backup operation by using either the Stsadm command-line tool or SQL Server tools to back up all content databases. If you are using SQL Server tools, use the simple recovery model to truncate your transaction log.

After backing up, and before you apply a software update

After backing up, verify that you can restore the databases.

After you have backed up all the databases, use SQL Server Management Studio or the SQL Server DBCC shrinkfile command to free unused log space. For more information, see Shrinking the Transaction Log (http://go.microsoft.com/fwlink/?LinkId=105233&clcid=0x409).

Using database backups after a software update

After you apply a software update, verify that the update applied successfully across the farm. One way to do this is to search for the Finished upgrading SPFarm Name=<Name of Configuration Database> entry in the Upgrade.log file that is located in the following directory:

%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS

Note Note:

You can restore a content database to a version of Search Server later than the version that was running when you made the backup.

See Also

Concepts

Protecting and restoring the farm (Search Server 2008)
Upgrade paths (Search Server 2008)
Protecting and recovering data for a site (Search Server 2008)
Protecting and recovering data in a non-production environment (Search Server 2008)


Plan for security (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This article contains a methodical approach to building stronger security into your solution design for Microsoft Search Server 2008. This approach is based on a foundation of the following security guides, which are provided in Microsoft patterns and practices:

  • Securing Your Web Server

  • Securing Your Database Server

  • Securing Your Network

These guides explain practical and secure configurations for specific server roles. The guidance for each server role includes recommended security settings for the network, the operating system, and the installed applications. This includes Internet Information Services (IIS), Microsoft ASP.NET Framework, and Microsoft SQL Server.

The information in this article supplements the Microsoft patterns & practices security guidance in several ways:

  • Provides recommendations for each server role in a server farm.

  • Identifies additional networking, operating system, and application settings that are appropriate for server roles.

  • Provides recommendations for securing the specific applications and features that are installed by Search Server 2008.

  • Targets security recommendations to environments that are common for Search Server 2008 solutions.

Plan for improved security by using the following steps:

  1. Plan the security environment. The security guidance that is recommended for your organization depends on which environment best matches your intended use of Search Server 2008. Use the following article to help plan the security environment:

    • Choose the security environment (Search Server 2008) describes the three key security environments: internal team or department, external secure access, and external anonymous access.

  2. Plan server farm security. Plan how to secure individual servers in a server farm. The Microsoft patterns & practices security guides are used as a foundation for securing Search Server 2008 environments. Use the following articles to help plan server farm security:

    • Review the secure topology design checklists (Search Server 2008) to ensure that the topology and logical architecture meet the criteria for a more secure design.

    • Plan for secure communication within a server farm (Search Server 2008) to ensure that the methods for achieving more secure communication are most appropriate for your solution.

    • Plan security hardening for server roles within a server farm (Search Server 2008) to determine the specific hardening settings for each of the server roles in the server farm.

    • Plan security hardening for an extranet (Search Server 2008) to determine the security settings to allow content to be more securely accessed from the Internet or the corporate network.

  3. Plan secure configurations for features. Plan how to configure Search Server 2008 features in a more secure manner. Use the following article to help plan more secure configurations:

    • Plan secure configurations for Search Server 2008 features provides recommendations for more securely configuring Search Server 2008 features. The recommendations in this article are usually configured by using Central Administration, instead of in in the network, operating system, IIS, or .NET Framework.

  4. Plan environment-specific security. Plan security targeted to the specific environment. Use the following articles to help plan environment-specific security:

    • Plan security for an internal team or department environment (Search Server 2008) provides additional security guidance targeted to the internal team or department environment.

    • Plan security for an external secure search environment (Search Server 2008) provides additional security guidance targeted to the external secure search environment.

    • Plan security for an external anonymous access environment (Search Server 2008) provides additional security guidance targeted to the external anonymous access environment.

  5. Plan security roles. Use the following article to plan for and design security roles:

    • Plan for security roles (Search Server 2008) describes planning roles for administrators and for users.

See Also

Tasks

Best practices for search performance (Search Server 2008)


Plan server farm security (Search Server 2008)
DropDown image

Updated: 2009-07-13

Planning server farm security includes the following tasks:

  • Review the secure topology design checklists (Search Server 2008)

  • Plan security hardening for server roles within a server farm (Search Server 2008)

  • Plan for secure communication within a server farm (Search Server 2008)

  • Plan security hardening for an extranet (Search Server 2008)

Use these tasks with the following security environments:

  • External secure access

  • External anonymous access

See Also

Concepts

Plan for security (Search Server 2008)
Choose the security environment (Search Server 2008)
Plan secure configurations for Search Server 2008 features
Plan environment-specific security (Search Server 2008)
Plan for security roles (Search Server 2008)


Review the secure topology design checklists (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Server topology design checklist

  • Networking topology design checklist

  • Logical architecture design checklist

  • Operating system design checklist

In Microsoft Search Server 2008, successful server hardening depends on designing a server topology and logical architecture that target isolation and secure communication.

You can use the following checklists to ensure that your plans meet the criteria for a more secure design.

Use the secure topology design checklists with the following security environments:

  • External secure access

  • External anonymous access

Server topology design checklist

Review the following checklist to ensure that your plans meet the criteria for a more secure server topology design.

[ ] | The topology incorporates dedicated front-end Web servers.
[ ] | Servers that host application server roles and the database server role are protected from direct user access.
[ ] | The Central Administration site is hosted on a dedicated application server, such as the index server. This is not possible in Search Server 2008 Express.

Networking topology design checklist

Review the following checklist to ensure that your plans meet the criteria for a more secure networking topology design.

[ ] | All servers within the farm reside inside a single data center and on the same VLAN.
[ ] | Access is allowed through a single point of entry, which is a firewall.
[ ] | For a more secure environment, the farm is separated into three tiers (front-end Web, application, and database), which are separated by routers or firewalls at each VLAN boundary. A Search Server 2008 Express farm can only be separated into two tiers (that is, a Web tier and a database tier).

Logical architecture design checklist

Review the following checklist to ensure that your plans meet the criteria for a more secure logical architecture design.

[ ]

At least one zone in each Web application uses NTLM authentication. This is required to enable the search account to crawl content within the Web application. For more information, see Plan authentication methods (Search Server 2008).

[ ]

Web applications are implemented by using host names instead of the randomly generated port numbers that are automatically assigned. Do not use Internet Information Services (IIS) host header bindings if the Web application will be hosting host-named site collections.

[ ]

Consider using separate Web applications for the following circumstances:

  • Your company policy requires process isolation for content and applications.

  • You are implementing sites that integrate with external data sources, where the content that is provided by these data sources is sensitive or requires better security.

[ ]

In a reverse proxy environment, consider using the default port for the public-facing network while you are using a non-default port on your internal network. This can help prevent simple port attacks that assume HTTP will always be on port 80 on your internal network.

[ ]

When deploying custom Web Parts, only trustworthy Web Parts are deployed within Search Center sites. This protects the sensitive content against intradomain scripting attacks.

[ ]

Separate application pool accounts are used for Central Administration and for each unique Web application.

Operating system design checklist

Review the following checklist to ensure that your plans meet the criteria for a more secure operating system design.

[ ] | The server operating system is configured to use the NTFS file system.
[ ] | Clocks on all servers within the farm are synchronized.

See Also

Concepts

Plan server farm security (Search Server 2008)
Plan for secure communication within a server farm (Search Server 2008)
Plan security hardening for server roles within a server farm (Search Server 2008)
Plan security hardening for an extranet (Search Server 2008)


Plan security hardening for server roles within a server farm (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • About security hardening

  • Application server recommendations

  • Secure communication with the Microsoft SQL Server database

  • File and Printer Sharing service requirements

  • Office Server Web services

  • Connections to external servers

  • Search Server 2008 services

  • Accounts and groups

  • Web.config file

  • Secure snapshot additions

Use this article to plan server farm security. The tasks in the article are appropriate for the following security environments:

  • External secure access

  • External anonymous access

About security hardening

In a server farm environment, individual servers play specific roles. Security hardening recommendations for these servers depend on the role each plays.

The server hardening recommendations are built on the recommendations provided in the following security guidance in Microsoft patterns & practices:

  • Securing Your Web Server

  • Securing Your Database Server

  • Securing Your Network

These guides follow a methodical approach to securing servers for specific roles and for securing the supporting network. The order in which settings are applied and applications are installed and hardened is prescribed also, starting with applying patches and updates, then hardening networking settings and operating system settings, and then application-specific hardening. For example, Securing Your Web Server recommends that you install and harden Internet Information Services (IIS) only after patching and hardening the operating system. Additionally, this guide prescribes installing the Microsoft .NET Framework only after IIS is fully patched and hardened.

The following figure illustrates categories of security settings that are methodically prescribed in Securing Your Web Server.

Categories of security settings

Additionally, each of the three guides includes a secure snapshot and a list of recommended security settings for either the specific server role or for the network. The snapshot lists are organized by categories that correspond to security settings illustrated in the previous figure.

The security design and hardening guidance provided in this article are based on the guidance published in these three guides. This guidance assumes that you will use these guides as a baseline for securing and hardening your server farm.

This article describes the exceptions or additions to the snapshots that we recommend for your environment. These are described in table format by using the same categories and order as the three security guides. This format is intended to make it easy to determine and apply specific recommendations as you use the guides.

The guide Deployment for Search Server 2008 includes instructions for applying specific security guidance that is not covered in the Microsoft patterns & practices security guides.

The nature of server-to-server communication in a server farm and the specific features that are provided by Microsoft Search Server 2008 are the primary reasons for specific hardening recommendations. This article also describes how key communication channels and Search Server 2008 features affect security requirements.

Application server recommendations

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

In Search Server 2008, application server roles are not typical middle-tier application servers that are packaged inside Enterprise Services applications. Consequently, the recommendations in Securing Your Application Server do not apply for Search Server 2008 application servers. Instead, use the guidance provided in Securing Your Web Server to harden Search Server 2008 application servers:

  • Apply the guidance for networking and operating system settings to all application servers in the server farm. This guidance is contained in the following categories: patches and updates, services, protocols, accounts, files and directories, shares, ports, registry, and auditing and logging.

  • Apply the guidance for hardening IIS and other Web settings only on the application server that hosts the Central Administration Web site. This guidance includes the following categories: IIS, Machine.config, code access security, LocalIntranet_Zone, and Internet_Zone.

In addition to using the secure snapshot in Securing Your Web Server, also apply the recommendations provided in the Secure snapshot additions section later in this article.

Secure communication with the Microsoft SQL Server database

Securing Your Database Server recommends restricting access to two default Microsoft SQL Server communications ports: TCP port 1433 and UDP port 1434. For more secure server farm environments, we recommend that you do the following:

  • Block UDP port 1434 completely.

  • Configure SQL Server named instances to listen on a non-standard port (other than TCP port 1433 or UDP port 1434).

  • For additional security, block TCP port 1433 and reassign the port that is used by the default instance to a non-standard port.

  • Configure SQL client aliases on all front-end Web servers and application servers in the server farm. After you block TCP port 1433 or UDP port 1434, SQL client aliases are necessary on all computers that communicate with the computer that is running SQL Server.

This approach provides a much better degree of control over how SQL Server is deployed and run, including the ability to ensure that only authorized computers can communicate with the computer that is running SQL Server.

The hardening steps for creating a SQL client alias must be completed before you install Search Server 2008. When you run Setup for Search Server 2008 and you are prompted to enter the name of the SQL Server computer to which to connect, you must enter the name of the SQL client alias.

Blocking the standard SQL Server ports

The specific ports that are used to connect to SQL Server are affected by whether databases are installed on a default instance of SQL Server or a named instance of SQL Server. The default instance of SQL Server listens for client requests on TCP port 1433. A named instance of SQL Server listens on a randomly assigned port number. Additionally, the port number for a named instance can be reassigned if the instance restarts (depending on if the previously assigned port number is available).

By default, client computers that connect to SQL Server first connect by using TCP port 1433. If this communication is unsuccessful, then the client computers query the SQL Server Resolution Service listening on UDP port 1434 to determine on which port the database instance is listening.

The default port-communication behavior of SQL Server introduces several issues that affect server hardening. First, the ports that are used by SQL Server are well-publicized ports and the SQL Server Resolution Service is the target of buffer overrun attacks and denial-of-service attacks, including the "Slammer" worm virus. Even if SQL Server is patched to reduce security issues in the SQL Server Resolution Service, the well-publicized ports remain a target. Second, if databases are installed on a named instance of SQL Server, the corresponding communication port is randomly assigned and can change. This behavior can potentially prevent server-to-server communication in a hardened environment. The ability to control which TCP ports are open or blocked is necessary to help secure your environment.

Consequently, the recommendation for a server farm is to assign static port numbers to named instances of SQL Server and to block UDP port 1434 to prevent a potential attacker from accessing the SQL Server Resolution Service. Additionally, consider reassigning the port that is used by the default instance and blocking TCP port 1433 also.

There are several methods that you can use to block ports. You can block these ports by using a firewall. However, unless you will know for sure that there are no other routes into the network segment and that there are no malicious users that have access to the network segment, the recommendation is to block these ports directly on the server that hosts SQL Server. This can be done by using Windows Firewall in Control Panel.

Configuring SQL Server database instances to listen on a non-standard port

SQL Server provides the ability to reassign the ports that are used by the default instance and any named instances. In SQL Server 2000, you reassign ports by using Server Network Utility. In SQL Server 2005, you reassign ports by using SQL Server Configuration Manager.

Configuring SQL client aliases

In a server farm, all front-end Web servers and application servers are SQL Server client computers. If you block UDP port 1434 on the SQL Server computer or you change the default port for the default instance, you must configure a SQL client alias on all servers that connect to the SQL Server computer.

To connect to an instance of SQL Server 2000, you install the SQL Server client tools on the target computer and then configure the SQL client alias. You install these by running Setup for SQL Server and selecting SQL Server Client Tools.

To connect to an instance of SQL Server 2005, you install SQL Server client components on the target computer and then configure the SQL client alias by using SQL Server Configuration Manager. To install SQL Server client components, run Setup and select only the following client components to install:

  • Connectivity Components

  • Management Tools (includes SQL Server Configuration Manager)

SQL Server client components work with SQL Server 2000 and can be used instead of the SQL Server client tools.

Hardening steps

Configure SQL Server

Configure a SQL Server 2000 instance to listen on a nondefault port

Use Server Network Utility to change the TCP port that is used by an instance of SQL Server 2000.

  1. On the SQL Server computer, run Server Network Utility.

  2. On the Instance(s) on this server menu, select the instance. Ensure that you have selected the intended instance. By default, the default instance listens on port 1433. Named instances of SQL Server 2000 are assigned a random port number. Therefore, you might not know the current port number assigned to a named instance when you run Server Network Utility.

  3. In the Enabled Protocols pane on the right side of the Server Network Utility interface, click TCP/IP, and then click Properties.

  4. In the Network Protocol Default Value Setup dialog box, change the TCP port number. Avoid using any of the well-known TCP ports. For example, select a higher-range port number, such as 40000. Do not select the Hide Server check box.

  5. Click OK.

  6. In the Server Network Utility dialog box, click OK. You will receive a message that states that the change will not take effect until the SQL Server service is restarted. Click OK.

  7. Restart the SQL Server service and confirm that your SQL Server computer is listening on the port that you selected. You can confirm this by looking in the event viewer log after restarting the SQL Server service. Look for an information event similar to the following event:

    Event Type:Information

    Event Source:MSSQLSERVER

    Event Category:(2)

    Event ID:17055

    Date:3/6/2008

    Time:11:20:28 AM

    User:N/A

    Computer:computer_name

    Description:

    19013:

    SQL Server listening on 10.1.2.3: 40000

Configure a SQL Server 2005 instance to listen on a non-default port

Use SQL Server Configuration Manager to change the TCP port that is used by an instance of SQL Server 2005.

  1. Use SQL Server Configuration Manager to change the TCP port that is used by an instance of SQL Server 2005.

  2. On the SQL Server computer, open SQL Server Configuration Manager.

  3. In the left pane, expand SQL Server 2005 Network Configuration.

  4. Under SQL Server 2005 Network Configuration, click the corresponding entry for the instance that you are configuring. The default instance is listed as Protocols for MSSQLSERVER. Named instances will appear as Protocols for named_instance.

  5. In the right pane, right-click TCP/IP, and then click Properties.

  6. Click the IP Addresses tab. For every IP address assigned to the SQL Server computer, there is a corresponding entry on this tab. By default, SQL Server is listening on all IP addresses assigned to the computer.

  7. To globally change the port that the default instance is listening on, perform the following:

    1. For each IP except IPAll, clear all values for both TCP dynamic ports and TCP Port.

    2. For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.

  8. To globally change the port that a named instance is listening on, perform the following:

    1. For each IP including IPAll, clear all values for TCP dynamic ports. A value of 0 for this field indicates that SQL Server uses a dynamic TCP port for the IP address. A blank entry for this value means that SQL Server 2005 will not use a dynamic TCP port for the IP address.

    2. For each IP except IPAll, clear all values for TCP Port.

    3. For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.

  9. Click OK. You will receive a message that states that the change will not take effect until the SQL Server service is restarted. Click OK.

  10. Close SQL Server Configuration Manager.

  11. Restart the SQL Server service and confirm that the SQL Server computer is listening on the port that you selected. You can confirm this by looking in the event viewer log after restarting the SQL Server service. Look for an information event similar to the following event:

    Event Type:Information

    Event Source:MSSQL$MSSQLSERVER

    Event Category:(2)

    Event ID:26022

    Date:3/6/2008

    Time:1:46:11 PM

    User:N/A

    Computer:computer_name

    Description:

    Server is listening on [ 'any' <ipv4>50000]

Configure Windows Firewall

Configure Windows Firewall to block default SQL Server listening ports

  1. In Control Panel, open Windows Firewall.

  2. On the General tab, click On. Ensure that the Don't allow exceptions check box is cleared.

  3. On the Exceptions tab, click Add Port.

  4. On the Add a Port dialog box, enter a name for the port. For example, enter UDP-1434. Then, enter the port number. For example, enter 1434.

  5. Select the appropriate option button: UDP or TCP. For example, to block port 1434, click UDP. To block port 1433, click TCP.

  6. Click Change Scope and ensure that the scope for this exception is set to Any computer (including those on the Internet).

  7. Click OK.

  8. On the Exceptions tab, locate the exception that you created. To block the port, clear the check box for this exception. By default, this check box is selected, which means that the port is open.

Configure Windows Firewall to open manually assigned ports

  1. Follow steps 1-7 in the previous procedure to create an exception for the port that you manually assigned to a SQL instance. For example, create an exception for TCP port 40000.

  2. On the Exceptions tab, locate the exception that you created. Ensure that the check box for the exception is checked. By default, this check box is selected, which means that the port is open.

    Note Note:

    For more information about how to use Internet Protocol security (IPsec) to help secure communication to and from your SQL Server computer, see the Microsoft Knowledge Base article 233256: How to Enable IPSec Traffic Through a Firewall.

Configure a SQL client alias

Configure a SQL client alias

If you block UDP port 1434 or TCP port 1433 on the SQL Server computer, you must create a SQL client alias on all other computers in the server farm. You can use SQL Server client components to create a SQL client alias for computers that connect to SQL Server 2000 or SQL Server 2005.

  1. Run Setup for SQL Server 2005 on the target computer and select the following client components to install:

    1. Connectivity Components

    2. Management Tools

  2. Open SQL Server Configuration Manager.

  3. In the left pane, click SQL Native Client Configuration.

  4. In the right pane, right-click Aliases, and select New Alias.

  5. In the Alias dialog box, enter a name for the alias and then enter the port number for the database instance. For example, enter SharePoint_alias.

  6. In the Port No field, enter the port number for the database instance. For example, enter 40000. Ensure that the protocol is set to TCP/IP.

  7. In the Server field, enter the name of the SQL Server computer.

  8. Click Apply, and then click OK.

Test the SQL client alias

Test connectivity to the SQL Server computer by using Microsoft SQL Server Management Studio, which is available by installing SQL Server client components.

  1. Open SQL Server Management Studio.

  2. When you are prompted to enter a server name, enter the name of the alias that you created, and then click Connect. If the connection is successful, SQL Server Management Studio is populated with objects that correspond to the remote database.

    Note Note:

    To check connectivity to additional database instances in SQL Server Management Studio, click the Connect button and select Database Engine.

File and Printer Sharing service requirements

Several core features depend on the File and Printer Sharing service and the corresponding protocols and ports. These include, but are not limited to, the following:

  • Search queries All search queries require the File and Printer Sharing service.

  • Crawling and indexing content To crawl internal content, the index component sends requests through the front-end Web server. The front-end Web server communicates with content databases directly and sends results back to the index server. This communication requires the File and Printer Sharing service.

  • Index propagation If the query role is installed on a different server than the index role, the index server copies content indexes to the query servers. This action requires the File and Printer Sharing service and the corresponding protocols and ports.

The File and Printer Sharing service requires you to use named pipes. Named pipes can communicate by using either direct-hosted SMB or NetBIOS over TCP/IP (NetBT) protocols. For a secure environment, direct-hosted SMB is recommended instead of NetBT. The hardening recommendations provided in this article assume that SMB is used.

The following table describes the hardening requirements that are introduced by the dependency on the File and Printer Sharing service.

Category | Requirement | Notes
Services | File and Printer Sharing | Requires use of named pipes.
Protocols | Named pipes that use direct-hosted SMB Disable NBT | Named pipes can use NBT instead of direct-hosted SMB. However, NBT is not considered as secure as direct-hosted SMB.
Ports | TCP/UDP port 445 | Used by direct-hosted SMB.

For more information about disabling NBT, see the Microsoft Knowledge Base article 204279: Direct hosting of SMB over TCP/IP.

Office Server Web services

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

The Office Services Web service is used by Search Server 2008 as a communication channel between Web servers and application servers. This service uses the following ports:

  • TCP 56737

  • TCP/SSL 56738

Connections to external servers

Search Server 2008 can be configured to access content that resides on server computers outside the server farm. If you configure access to content on external server computers, ensure that you enable communication between the appropriate computers. In most cases, the ports, protocols, and services that are used depend on the external resource. For example:

  • Connections to file shares use the File and Printer Sharing service.

  • Connections to external SQL Server databases use the default or customized ports for SQL Server communication.

  • Connections to Oracle typically use OLE DB.

  • Connections to Web services use both HTTP and HTTPS.

The following table lists features that can be configured to access content that resides on server computers outside the server farm.

Feature | Description
Content Crawling | You can configure crawl rules to crawl content that resides on external resources, including Web sites, file shares, and Exchange public folders. When crawling external content sources, the index role communicates directly with these external resources. For more information, see Plan to crawl content (Search Server 2008).

Search Server 2008 services

Do not disable services that are installed by Search Server 2008.

The following services are installed on all front-end Web servers and application servers and appear in the Microsoft Management Console (MMC) Services snap-in (alphabetical order):

  • Office SharePoint Server Search

  • Windows SharePoint Services Administration

  • Windows SharePoint Services Search

  • Windows SharePoint Services Timer

  • Windows SharePoint Services Tracing

  • Windows SharePoint Services VSS Writer

If your environment disallows services that run as a local system, you can consider disabling the Windows SharePoint Services Administration service only if you are aware of the consequences and can work around them. This service is a Win32 service that runs as a local system.

This service is used by the Windows SharePoint Services Timer service to perform actions that require administrative credentials on the server, such as to create IIS Web sites, deploy code, and stop and start services. If you disable this service, you cannot run deployment-related tasks from the Central Administration site. You will have to use the Stsadm.exe command-line tool and run the execadminsvcjobs command to complete multi-server deployments for Search Server 2008, and to run other deployment-related tasks.

Accounts and groups

The secure snapshots in the Microsoft patterns & practices security guidance provide recommendations for securing accounts and groups.

For recommendations about how to plan for accounts, see Plan for administrative and service accounts (Search Server 2008).

For recommendations about how to plan for administrative and user roles, see Plan for security roles (Search Server 2008).

Web.config file

The .NET Framework, and ASP.NET in particular, uses XML-formatted configuration files to configure applications. The .NET Framework relies on configuration files to define configuration options. The configuration files are text-based XML files. Multiple configuration files can, and typically do, exist on a single system.

System-wide configuration settings for the .NET Framework are defined in the Machine.config file. The Machine.config file is located in the %SystemRoot%\Microsoft.NET\Framework\%VersionNumber%\CONFIG\ folder. The default settings that are contained in the Machine.config file can be modified to affect the behavior of applications on the whole system that use the .NET Framework. For recommendations about how to configure Machine.config files, see Securing Your Web Server.

You can change the ASP.NET configuration settings for a single application if you create a Web.config file in the root folder of the application. When you do this, the settings in the Web.config file override the settings in the Machine.config file.

When you extend a Web application by using Central Administration, Search Server 2008 automatically creates a Web.config file for the Web application.

The Secure snapshot additions section later in this topic lists recommendations for configuring Web.config files. These recommendations are intended to be applied to each Web.config file that is created, including the Web.config file for the Central Administration site.

For more information about ASP.NET configuration files and editing a Web.config file, see ASP.NET Configuration.

Secure snapshot additions

This section lists the additions to snapshots in the Microsoft patterns & practices security guidance that we recommend for Search Server 2008 environments. These are described in table format by using the same categories and order as the patterns & practices security guides.

This format is intended to make it easy to determine and apply specific recommendations as you use the Microsoft patterns & practices security guides. Except for some noted exceptions, these hardening recommendations are intended to be applied before you run Setup for Search Server 2008.

For more information about communication between specific server roles in a server farm, see Plan security hardening for extranet environments.

Securing the network snapshot additions

The following table describes recommendations for securing the network additions.

Component | Characteristic exception
All | No additional recommendations

Securing your Web server snapshot additions

The following table describes recommendations for securing your Web server additions.

Component Characteristic

Services

Enable:

  • File and Printer Sharing

  • Office SharePoint Server Search

  • World Wide Web Publishing Service

Ensure these services remain enabled after you run Setup:

  • Office SharePoint Server Search

  • Windows SharePoint Services Administration

  • Windows SharePoint Services Search

  • Windows SharePoint Services Timer

  • Windows SharePoint Services Tracing

  • Windows SharePoint Services VSS Writer

Protocols

Enable:

  • SMB

Disable:

  • NetBT

Accounts

If the Microsoft Directory Management Service is enabled as part of e-mail integration, configure your Active Directory environment to allow write access to the account that is used by the Microsoft Directory Management Service (the server farm account).

For additional guidance about how to configure accounts, see Plan for administrative and service accounts (Search Server 2008) for Search Server 2008 account requirements and recommendations.

Shares

No additional recommendations

Ports

  • Open TCP/UDP port 445.

  • Open TCP ports 56737 and 56738 for the Office Server Web services.

  • If UDP port 1434 is blocked on the SQL Server computer and databases are installed on a named instance, configure a SQL client alias for connecting to the named instance.

  • If TCP port 1433 is blocked on the SQL Server computer and databases are installed on the default instance, configure a SQL client alias for connecting to the named instance.

  • Ensure that ports remain open for Web applications that can be accessed by users.

  • Block external access to the port that is used for the Central Administration site.

Auditing and logging

If log files are relocated, ensure that the log file locations are updated to match.

IIS

See guidance for IIS later in this topic.

Sites and virtual directories

No additional recommendations

Script mappings

No additional recommendations

ISAPI filters

No additional recommendations

IIS metabase

No additional recommendations

.NET Framework

See guidance for the .NET Framework later in this topic.

Machine.config: HttpForbiddenHandler

No additional recommendations

Machine.config: Remoting

No additional recommendations

Machine.config: Trace

No additional recommendations

Machine.config: compilation

No additional recommendations

Machine.config: customErrors

No additional recommendations

Machine.config: sessionState

No additional recommendations

Code access security

Ensure that you have a minimal set of code access security permissions enabled for your Web application. (The <trust> element in Web.config for each Web application should be set to WSS_Minimal (where WSS_Minimal has its low defaults as defined in 12\config\wss_minimaltrust.config) or your own custom policy file, which is minimally set.)

LocalIntranet_Zone

No additional recommendations

Internet_Zone

No additional recommendations

Web.config

Apply the following recommendations to each Web.config file that is created after you run Setup:

  • Do not allow compilation or scripting of database pages via the PageParserPaths elements.

  • Ensure <SafeMode> CallStack=""false"" and AllowPageLevelTrace=""false"".

  • Ensure that the Web Part limits around maximum controls per zone is set low.

  • Ensure that the SafeControls list is set to the minimum set of controls that that you must have for your sites.

  • Ensure that your Workflow SafeTypes list is set to the minimum level of SafeTypes needed.

  • Ensure that customErrors is turned on (<customErrors mode=""On""/>).

  • Consider your Web proxy settings as needed (<system.net>/<defaultProxy>).

  • Set the upload.aspx limit to the highest size that you reasonably expect users to upload (default is 2 GB). Performance can be affected by uploads larger than 100 MB.

Securing your database server snapshot additions

The following table describes recommendations for securing your database server additions.

Component Characteristic exception

Services

No additional recommendations

Protocols

No additional recommendations

Accounts

Manually and regularly remove unused accounts.

Files and directories

No additional recommendations

SQL Server settings

See guidance for SQL Server settings later in this topic.

Shares

No additional recommendations

Ports

  • Block UDP port 1434.

  • Consider blocking TCP port 1433.

Registry

No additional recommendations

Auditing and logging

No additional recommendations

SQL Server security

No additional recommendations

SQL Server logins, users, and roles

No additional recommendations

SQL Server database objects

No additional recommendations

See Also

Concepts

Plan server farm security (Search Server 2008)
Review the secure topology design checklists (Search Server 2008)
Plan for secure communication within a server farm (Search Server 2008)
Plan security hardening for an extranet (Search Server 2008)


Plan for secure communication within a server farm (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Plan server-to-server communication

  • Plan client-server communication

  • Plan for using SSL

Use this article to plan server farm security. This article contains guidance about how to secure server-to-server communication and client-server communication.

The tasks in this article are appropriate for the following security environments:

  • External secure access

  • External anonymous access

Plan server-to-server communication

If servers are not inside a physically secure data center in which the threat of network eavesdropping is less significant, you must use an encrypted communication channel to protect data sent between servers.

In Microsoft Search Server 2008, server-to-server communication in a server farm is extensive. Securing this communication helps reduce the risk that sensitive data will be compromised, and also helps protect the servers from malicious attacks or unintentional threats.

The following figure shows several common communication transactions among servers in a farm.

Secure server farm communications model

Common communication transactions among servers in a farm include the following:

  1. Configuration changes Front-end Web servers communicate with the configuration database to communicate configuration changes for farm settings.

  2. Search requests Front-end Web servers first communicate with the query server to generate results for search queries. Next, for content that is stored locally, the front-end Web servers communicate with the content database to satisfy user requests for specific documents within the search results.

  3. Indexing The indexing component communicates through a front-end Web server to crawl local content that is stored in the content databases to include in the index. For information about the different kinds of external sources that the index server can crawl, see Plan to crawl content (Search Server 2008).

Note Note:

In a Search Server 2008 environment, the search service is provided by two roles: query and index. These roles can be installed on different server computers.

The Advanced installation of Microsoft Search Server 2008 Express can have multiple Web front-end servers. However, the Query and Index roles can only exist on one physical application server.

The Advanced installation of Microsoft Search Server 2008 can have multiple Web front-end servers, and multiple instances of query server running on separate application servers. There can still only be one instance of the Index role.

Internet Protocol security (IPsec) and Secure Sockets Layer (SSL) can both be used to help protect communication between servers by encrypting traffic. Each of these methods works well. The choice of which method to use depends on the specific communication channels you are securing and the benefits and tradeoffs that are most appropriate for your organization.

IPsec

IPsec is generally recommended for protecting the communication channel between two servers and restricting which computers can communicate with one another. For example, you can help protect a database server by establishing a policy that permits requests only from a trusted client computer, such as an application server or a Web server. You can also restrict communication to specific IP protocols and TCP/UDP ports.

The networking requirements and recommendations for a server farm make IPsec a good option for the following reasons:

  • All servers are contained on one physical LAN (to improve IPsec performance).

  • Servers are assigned static IP addresses.

IPsec can also be used between trusted Windows Server 2008, Windows Server 2003, or Windows 2000 Server domains. For example, you can use IPsec to help secure communication of a Web server or application server in a perimeter network that connects to a computer that is running Microsoft SQL Server on an internal network. For more information, see Selecting IPSec Authentication Methods in the Windows Server 2003 Deployment Guide.

For more information about recommended environments for IPsec, see Determining Your IPSec Needs in the Windows Server 2003 Deployment Guide.

SSL

The general recommendation for SSL is to use this encryption method when you want granular channel protection for a particular application instead of for all applications and services that are running on a computer. SSL must be implemented by individual applications. Therefore, you cannot use SSL to encrypt all communications between two hosts.

Additionally, SSL is less flexible than IPsec because it only supports authentication by using public key certificates. SSL does provide several distinct advantages, however. Most significantly, SSL is supported by a wide variety of servers and client computers, and the maturity of the standard has almost eliminated interoperability problems.

Scenarios to consider for SSL

There are several scenarios that make SSL a good option. They include the following:

  • Administration The Central Administration site can be secured by using SSL.

  • Searching sensitive content If Search Server indexes sensitive content, malicious users could intercept information about that content in query results. You can prevent this interception by using SSL.

Plan client-server communication

It might not be practical to secure all client-server communication. However, there are several scenarios that justify the additional configuration that is required to provide more secure communication between client computers and servers within the server farm:

  • Secure collaboration with partners Partners run searches from outside the local network in an extranet environment.

  • Remote employee access Employees access Search Server remotely to run searches when they are off-site.

  • Customers searching for sensitive data Customers log on and search content that includes sensitive information. For example, customers may be required to log on to search through knowledge base articles about a product.

  • Basic or forms-based authentication If users authenticate with either of these methods, credentials are sent in plain text. At a minimum, secure the client-server communication for the logon page.

SSL is generally recommended to help secure communications between users and servers when sensitive information must be passed. SSL can be configured to require server authentication or both server and client authentication.

Plan for using SSL

SSL can decrease the performance of the network. There are several common guidelines that you can use to optimize pages that use SSL. First, use SSL only for pages that require it. This includes pages that contain or capture sensitive data, such as passwords or other personal data. Use SSL only if the following conditions are true:

  • You want to encrypt the page data.

  • You want to guarantee that the server to which you send the data is the server that you expect.

For pages where you must use SSL, follow these guidelines:

  • Make the page size as small as possible.

  • Avoid using graphics that have large file sizes. If you use graphics, use graphics that have smaller file sizes and lower resolution.

See Also

Concepts

Plan server farm security (Search Server 2008)
Review the secure topology design checklists (Search Server 2008)
Plan security hardening for server roles within a server farm (Search Server 2008)
Plan security hardening for an extranet (Search Server 2008)


Plan security hardening for an extranet (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Extranet hardening planning tool

  • Network topology

  • Domain trust relationships

  • Communication with server-farm roles

  • Communication with infrastructure server roles

  • Communication between network domains

  • Connections to external servers

This article details the hardening requirements for an extranet environment in which a Microsoft Search Server 2008 server farm is put inside a perimeter network and content is available from the Internet or from the corporate network.

Extranet hardening planning tool

The following planning tool is available for use with this article: Extranet hardening planning tool: back-to-back perimeter. Based on the back-to-back perimeter topology, this tool articulates the port requirements for each of the computers that are running Microsoft Internet Security and Acceleration (ISA) Server and each of the routers or firewalls. This tool is an editable Microsoft Office Visio file that you can revise for your environment. For example, you can:

  • Add your custom port numbers, where applicable.

  • Where a choice of protocols or ports is provided, indicate which ports you will use.

  • Indicate the specific ports that are used for database communication in your environment.

  • Add or remove requirements for ports based on:

    • Whether you are configuring e-mail integration.

    • Which layer you deploy the query role to.

    • If you are configuring a domain trust relationship between the perimeter domain and the corporate domain.

Network topology

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

The hardening guidance in this article can be applied to many extranet configurations. The following back-to-back perimeter network topology diagram shows a sample implementation and illustrates the server and client roles across an extranet environment. The purpose of the diagram is to explain each of the possible roles and their relationship to the overall environment. Consequently, the query role appears twice. In a real implementation, the query role is deployed either on Web servers or as an application server, but not both. And, if the query role is deployed to the Web servers, it is deployed to all Web servers in a farm. For the purpose of communicating security hardening requirements, the diagram illustrates all options. The routers illustrated can be exchanged for firewalls. The content deployment service is not a feature of Search Server 2008.

Extranet security hardening diagram

Domain trust relationships

The requirement for a domain trust relationship depends on how the server farm is configured. This section discusses two possible configurations.

Server farm resides in the perimeter network

The perimeter network requires its own Active Directory directory service infrastructure and domain. Typically, the perimeter domain and the corporate domain are not configured to trust one another. However, to authenticate intranet users and remote employees who are using their domain credentials (Windows authentication), you must configure a one-way trust relationship in which the perimeter domain trusts the corporate domain. Forms authentication does not require a domain trust relationship.

Server farm is split between the perimeter network and the corporate network

If the server farm is split between the perimeter network and the corporate network with the database servers residing inside the corporate network, a domain trust relationship is required if Windows accounts are used. In this scenario, the perimeter network must trust the corporate network. If SQL authentication is used, a domain trust relationship is not required. The following table summarizes the differences between these two approaches.

Aspect Windows authentication SQL authentication

Description

Corporate domain accounts are used for all Search Server 2008 service and administration accounts, including application pool accounts.

A one-way trust relationship, in which the perimeter network trusts the corporate network, is required.

Search Server 2008 accounts are configured in the following ways:

  • SQL authentication is used for every database that is created.

  • All other administration and service accounts are created as domain accounts in the perimeter network.

  • Web servers and application servers are joined to the perimeter network.

A trust relationship is not required but can be configured to support client authentication against an internal domain controller.

Note Note:

If the application servers reside in the corporate domain, a one-way trust relationship, in which the perimeter network trusts the corporate network, is required.

Setup

Setup includes the following:

  • Search Server 2008 administration and service accounts are created in the corporate domain.

  • Web servers and application servers are joined to the perimeter network.

  • A trust relationship is established in which the perimeter domain trusts the corporate domain.

Setup includes the following:

  • All database accounts must be created as SQL login accounts in SQL Server 2000 Enterprise Manager or in SQL Server Management Studio for SQL Server 2005 or 2008. These accounts must be created before the creation of any Search Server 2008 databases, including the configuration database and the AdminContent database.

  • You must use the Psconfig command-line tool to create the configuration database and the SharePoint_AdminContent database. You cannot use the SharePoint Products and Technologies Configuration Wizard to create these databases. In addition to using the -user and -password parameters to specify the server farm account, you must use the -dbuser and -dbpassword parameters to specify SQL authentication accounts.

  • You can create additional content databases in Central Administration by selecting the SQL authentication option. However, you must first create the SQL login accounts in SQL Server 2000 Enterprise Manager or SQL Server Management Studio for SQL Server 2005 or 2008.

  • Secure all communication with the database servers using SSL.

  • Ensure that ports that are used to communicate with SQL Server remain open between the perimeter network and the corporate network.

Additional information

The one-way trust relationship allows the Web servers and application servers that are joined to the extranet domain to resolve accounts that are in the corporate domain.

SQL login accounts are encrypted in the registry of the Web servers and application servers.

The server farm account is not used to access the configuration database and the SharePoint_AdminContent database. The corresponding SQL login accounts are used instead.

The information in the previous table assumes the following:

  • Both the Web servers and the application servers reside in the perimeter network.

  • All accounts are created with the least privileges necessary, including the following recommendations:

    • Separate accounts are created for all administrative and service accounts.

    • No account is a member of the Administrators group on any computer, including the server computer that hosts SQL Server.

If you are using SQL authentication, the following SQL logins must be created with the following permissions:

  • SQL login for the account used to run the Psconfig command-line tool The account must be a member of the following SQL roles: dbcreator and securityadmin. The account must be a member of the Administrators group on each server on which Setup is run, but not on the database server.

  • SQL login for the server farm account This login is used to create the configuration database and the SharePoint_AdminContent database. The login must include the dbcreator role. The login does not have to be a member of the securityadmin role. The login must be created by using SQL authentication. Configure the server farm account to use SQL authentication with the password that is specified when you create the SQL login.

  • SQL login for all other databases The login must be created by using SQL authentication. The login must be a member of the following SQL roles: dbcreator and securityadmin.

For more information about Search Server 2008 accounts, see Plan for administrative and service accounts (Search Server 2008).

For more information about how to create databases by using the Psconfig command-line tool, see Command-line reference for the SharePoint Products and Technologies Configuration Wizard (Office SharePoint Server).

Communication with server-farm roles

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

When configuring an extranet environment, you should understand how the various server roles communicate within the server farm.

Communication between server roles

The following figure illustrates the communication channels in a server farm. The table directly after the figure indicates the ports and protocols that are represented in the figure. The black solid arrows indicate which server role initiates communication. A red dotted arrow indicates that either server initiates communication. This is important to know when you configure inbound and outbound communication on a firewall.

Interfarm server communication
Callout Ports and protocols

1

Client access (including Information Rights Management (IRM) and search queries), one or more of the following:

  • TCP port 80

  • TCP port 443 (SSL)

  • Custom ports

2

File and printer sharing service — Either of the following:

  • Direct-hosted server message block (SMB) (TCP/UDP 445) — Recommended

  • NetBIOS over TCP/IP (TCP/UDP ports 137, 138, 139) — Disable if not used

3

Office Server Web Services — Both:

  • TCP port 56737

  • TCP 56738 (SSL)

4

Database communication:

  • TCP/SSL port 1433 (default) for default instance (customizable)

  • TCP/SSL random port for named instances (customizable)

5

Search crawling — Depending on how authentication is configured, Search Server sites might be extended with an additional zone or Internet Information Services (IIS) site to ensure that the index component can access content. This configuration can result in custom ports.

  • TCP 80

  • TCP 443 (SSL)

  • Custom ports

Web servers automatically load-balance query requests to the available query servers. Consequently, if the query role is deployed across Web server computers, these servers communicate with one another using the File and Printer Sharing service and the Office Server Web services. The following figure illustrates the communication channels between these servers.

Web server to query server

Communication between the Central Administration site and server roles

The Central Administration site, which is hosted on the Central Administration Web Application, is used for all administration functions in Search Server 2008.

This section details the port and protocol requirements for communication between an administrator workstation and server roles within the farm. The Central Administration site can be installed on any Web server. Configuration changes that are made through the Central Administration site are communicated to the configuration database. Other server roles in the farm pick up configuration changes that are registered in the configuration database during their polling cycles. Consequently, the Central Administration site does not introduce any new communication requirements to other server roles in the server farm.

The following figure illustrates the communication channels from an administrator workstation to the Search Center, Central Administration site, and the configuration database.

Administrator Site Administration Topology

The following table describes the ports and protocols illustrated in the previous illustration.

Callout Ports and protocols

A

Search Center site — One or more of the following:

  • TCP 80

  • TCP 443 (SSL)

  • Custom ports

B

Central Administration site — One or more of the following:

  • TCP 80

  • TCP 443 (SSL)

  • Custom ports

C

Database communication:

  • TCP/SSL port 1433 (default) for default instance (customizable)

  • TCP/SSL random port for named instances (customizable)

Communication with infrastructure server roles

When configuring an extranet environment, you should understand how the various server roles communicate within infrastructure server computers.

Active Directory domain controller

The following table lists the port requirements for inbound connections from each server role to an Active Directory domain controller.

Item | Web Server | Query Server | Index Server | Database Server
TCP/UDP 445 (Directory Services) | X | X | X | X
TCP/UDP 88 (Kerberos authentication) | X | X | X | X
Lightweight Directory Access Protocol (LDAP)/LDAPS ports 389/636 by default, customizable | X |  | X |

LDAP/LDAPS ports are required for server roles based on the following conditions:

  • Web servers Use LDAP/LDAPS ports if LDAP authentication is configured.

DNS server

The following table lists the port requirements for inbound connections from each server role to a Domain Name System (DNS) server. In many extranet environments, one server computer hosts both the Active Directory domain controller and the DNS server.

Item | Web Server | Query Server | Index Server | Database Server
DNS, TCP/UDP 53 | X | X | X | X

Communication between network domains

Active Directory communication

Active Directory communication between domains to support authentication with a domain controller inside the corporate network requires at least a one-way trust relationship in which the perimeter network trusts the corporate network.

In the example illustrated in Network topology, the first figure in this article, the following ports are required as inbound connections to ISA Server B to support a one-way trust relationship:

  • TCP/UDP 135 (RPC)

  • TCP/UDP 389 by default, customizable (LDAP)

  • TCP 636 by default, customizable (LDAP SSL)

  • TCP 3268 (LDAP GC)

  • TCP 3269 (LDAP GC SSL)

  • TCP/UDP 53 (DNS)

  • TCP/UDP 88 (Kerberos)

  • TCP/UDP 445 (Directory Services)

  • TCP/UDP 749 (Kerberos-Adm)

  • TCP port 750 (Kerberos-IV)

When configuring ISA Server B (or another device between the perimeter network and the corporate network), the network relationship must be defined as routed. Do not define the network relationship as Network Address Translation (NAT).

For more information about security hardening requirements related to trust relationships, see the following resources:

  • How to configure a firewall for domains and trusts

  • Active Directory in Networks Segmented by Firewalls

Connections to external servers

Search Server 2008 can be configured to index content that resides on server computers outside the server farm. If you configure access to content on external server computers, ensure that you enable communication between the appropriate computers. In most cases, the ports, protocols, and services that are used depend on the external resource. For example:

  • Connections to file shares use the File and Printer Sharing service.

  • Connections to external SQL Server databases use the default or customized ports for SQL Server communication.

  • Connections to Oracle typically use OLE DB.

  • Connections to Web services use both HTTP and HTTPS.

The following table lists features that can be configured to access content that resides on server computers outside the server farm.

Feature | Description
Content crawling | You can configure crawl rules to crawl content that resides on external resources, including Web sites, file shares, Exchange public folders, and business data applications that have an appropriate source connector. When crawling external data sources, the index role communicates directly with these external resources. For more information, see Plan to crawl content (Search Server 2008).

See Also

Concepts

Plan server farm security (Search Server 2008)
Review the secure topology design checklists (Search Server 2008)
Plan for secure communication within a server farm (Search Server 2008)
Plan security hardening for server roles within a server farm (Search Server 2008)


Choose the security environment (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Use this article to determine the security environment that most closely matches the intended use of Microsoft Search Server 2008.

The security guidance that is recommended for your organization depends on the environment. This article describes the following three security environments:

  • Internal team or department

  • External secure access

  • External anonymous access

Review the description for each environment and determine the one that most closely matches your environment.

Note Note:

All these security environments apply to Search Server 2008 installations and Search Server 2008 Express installations. However, in Search Server 2008 Express, scalability is restricted because all roles run on a single server.

Internal team or department

Security guidance for an internal team or department environment in a larger organization focuses on recommending practical security configurations and settings for a team or department that uses Search Server 2008 for search.

This environment is a one-server (for Search Server 2008 Express) or two-server deployment in which the servers are not hosted by the primary IT team within the organization. Although the guidance for this environment requires some IT knowledge, it is not necessary for server farm administrators to be IT specialists.

The guidance for the internal team or department environment relies on the security of the overall network environment. Many of the default settings are intended to be used with this environment.

This environment is not intended for multiple teams. If the team or department requires a larger number of servers, or a higher level of security than is provided by the overall network environment, use the guidance for the internal IT-hosted environment.

If the environment most closely matches the internal team or department environment, go to the article Plan secure configurations for Search Server 2008 features.

External secure access

An external secure access environment is one in which users can query Search Server from a location outside the local network, such as from home or from a customer site. This environment enables external users to search for content quickly, exactly as internal users do. This environment is only practical if external users also have access to the content that Search Server indexes.

Security guidance for this environment focuses on the following:

  • Authenticating and securing communication between users and the server farm.

  • Protecting database and application servers from direct user interaction and securing the server farm against risks associated with hosting Internet-facing servers.

If the environment most closely matches the external secure access environment, see Plan server farm security (Search Server 2008). The articles in this section describe designing solutions for securing server-to-server communication and client-server communication, and hardening servers for specific roles.

External anonymous access

An external anonymous access environment is one that gives users anonymous access to content and search features from the Internet while protecting the server farm from the risks associated with hosting Internet-facing servers.

Security guidance for this environment focuses on the following:

  • Securing communication between servers.

  • Ensuring that content caching does not expose sensitive data.

  • Protecting database servers from direct user interaction and securing the server farm against risks associated with hosting Internet-facing servers in an anonymous environment.

If the environment most closely matches the external anonymous access environment, see Plan server farm security (Search Server 2008). The articles in this section describe designing solutions for security, securing server-to-server communication and client-server communication, and hardening servers for specific roles.

See Also

Concepts

Plan server farm security (Search Server 2008)
Plan secure configurations for Search Server 2008 features
Plan environment-specific security (Search Server 2008)
Plan for security roles (Search Server 2008)


Plan environment-specific security (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

The articles in this section describe planning environment-specific security. The articles describe the following three environments:

  • Plan security for an internal team or department environment (Search Server 2008)

    For the internal team or department environment, these recommendations are intended to be used instead of the recommendations provided in Plan server farm security (Search Server 2008). This approach relies on the security implemented in an organization's overall network environment, and greatly simplifies the degree of security configuration that is required for a specific team or department.

  • Plan security for an external secure search environment (Search Server 2008)

    The recommendations provided represent additional guidance that is intended to be used together with the recommendations provided in Plan server farm security (Search Server 2008).

  • Plan security for an external anonymous access environment (Search Server 2008)

    The recommendations provided represent additional guidance that is intended to be used together with the recommendations provided in Plan server farm security (Search Server 2008).

Each of the articles provides the following information for each environment, as applicable:

  • Server design checklist, including topology and logical architecture

  • Security hardening for server roles

  • Secure configurations for Search Server 2008 features

See Also

Concepts

Plan for security (Search Server 2008)
Choose the security environment (Search Server 2008)
Plan server farm security (Search Server 2008)
Plan secure configurations for Search Server 2008 features
Plan for security roles (Search Server 2008)


Plan security for an internal team or department environment (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Secure design checklist

  • Plan security hardening for server roles

  • Plan secure configurations for Search Server 2008 features

Security guidance for an internal team or department focuses on recommending practical security configurations and settings for a team or department inside a larger organization. This guidance assumes that the servers are not hosted by the primary IT team within the organization.

Whereas the guidance for this environment requires some IT knowledge, it is not necessary for farm administrators to be dedicated IT specialists. If more specialized roles are required to implement a setting, these roles are noted.

This guidance is intended to be used together with the guidance provided in Plan secure configurations for Search Server 2008 features.

Secure design checklist

Review the following checklist to ensure that your plans meet the criteria for a secure server topology design.

Topology

[ ]

For a team or department deployment that has internal access only, Microsoft Search Server 2008 can be installed on a single server or on two servers. (Search Server 2008 Express can be installed on only one server.)

[ ]

In a deployment with two or more servers, the Central Administration site should be hosted on a different server than the front-end Web server, where you can. This can only be done if application server roles are hosted on a different server than the front-end Web server role.

For example, if Server A hosts the front-end Web server role and Server B hosts the database and application server roles, the most secure location for the Central Administration site is on Server B. However, if Server A hosts the front-end Web server and application server roles and Server B hosts only the database role, the only option is to host the Central Administration site on Server A.

Note Note:

Search Server 2008 Express can be installed on only a single server.

Logical architecture

[ ] | At least one zone in each Web application uses NTLM authentication. This is required for the search account to crawl content within the Web application. The search account cannot use Kerberos authentication to crawl content. For more information, see Plan authentication methods (Search Server 2008).
[ ] | When deploying custom Web Parts, ensure that only trustworthy Web Parts are deployed within Web applications that host sensitive or secure content. This protects the sensitive content against intra-domain scripting attacks.

Plan security hardening for server roles

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

Guidance for an internal team or department environment assumes that only internal access is enabled for the servers, sites, and content, and that the overall network environment is secured by policies developed by an IT department. Consequently, hardening servers for specific roles is not necessary to the same extent as for other environments.

Plan secure configurations for Search Server 2008 features

The following table describes additional recommendations for securing Search Server 2008 features. These recommendations are appropriate for an internal team or department environment.

Feature or area Recommendation

Authentication

Authenticate against the existing identity management system. If this is not the Active Directory directory service, use ASP.NET forms-based authentication to connect to your identity management system. Using forms-based authentication might require assistance from the following roles:

  • ASP.NET developer to develop the authentication provider.

  • Administrator of the identity management system to which you are connecting.

Central Administration site

  • Restrict access to the Central Administration site to appropriate users only.

  • If you are enabling the Central Administration site for remote administration, secure the Central Administration site by using Secure Sockets Layer (SSL).

  • Administrators who run deployment operations must be members of the local Administrators group on the server that hosts the Central Administration site.

Windows SharePoint Services Administration service

In a single-server deployment, the Windows SharePoint Services Administration service is disabled by default for the following reasons:

  • This service, which is used to run deployment tasks that are initiated from the Central Administration site, is generally not required for a single-server deployment. However, deployment tasks can be run by using the stsadm.exe command-line tool, which does not require you to use this service.

  • The account that is used for the Central Administration site may be shared with all other processes. Consequently, disabling this service results in a more secure configuration.

For a secure single-server deployment, we recommend that you:

  • Change the server farm account after you run Setup.

  • Start the Windows SharePoint Services Administration service.

Performing these actions will enable you to perform deployment-related tasks directly from the Central Administration site.

See Also

Concepts

Plan environment-specific security (Search Server 2008)
Plan security for an external secure search environment (Search Server 2008)
Plan security for an external anonymous access environment (Search Server 2008)


Plan security for an external secure search environment (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Protect back-end servers

  • Secure client-server communication

  • Secure the Central Administration site

  • Secure design checklist

  • Plan security hardening for server roles

  • Plan secure configurations for Search Server 2008 features

Security guidance for an external secure environment is targeted to providing access to search facilities for extranet users. This environment enables external users, such as home workers or partners, to search for content exactly as internal users do. If you set up a Search Server 2008 system for external secure access, ensure that external users also have access to the content that Search Server indexes.

There are several unique recommendations for an external secure search environment. Some of these recommendations might not be practical for all solutions. For example, Search Server 2008 Express only supports a single application server which runs the Index server and Query server roles.

Protect back-end servers

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

External secure search access requires Internet-facing servers. You can limit the exposure to traffic from the Internet by protecting back-end servers:

  • Protecting database servers At a minimum, place a firewall between front-end Web servers and servers that host databases. Some environments dictate that database servers be hosted in an internal network instead of directly in an extranet environment.

  • Protect application servers At a minimum, protect application servers by requiring Internet Protocol security (IPsec) to help secure communication between server farm computers. Additionally, you can put application servers behind the firewall used to protect database servers. Or, you can introduce an additional firewall between front-end Web servers and application servers.

  • Protect the index role The index component communicates through a front-end Web server to crawl content in sites. To protect this communication channel, consider configuring a dedicated front-end Web server for use by the index server. This isolates crawling communication to a front-end Web server that is inaccessible to users. Additionally, configure Internet Information Services (IIS) to restrict SiteData.asmx (the crawler SOAP service) to let only the index server (or other crawlers) to access it. Providing a front-end Web server dedicated to content crawling also improves performance by reducing the load on the main front-end Web servers. This improves the user experience.

Secure client-server communication

Secure search access in an extranet environment relies on secure communication between client computers and the server farm environment. Where appropriate, use Secure Sockets Layer (SSL) to help secure communication between client computers and servers. To increase security, consider the following:

  • Require certificates on client computers. SSL can be implemented without requiring client certificates. You can improve the security of external search access by requiring certificates on all client computers.

  • Use IPsec. If client computers support IPsec, you can configure IPsec rules to achieve a greater level or granularity of security compared with SSL.

Secure the Central Administration site

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

Because external users have access to the network zone, it is important to secure the Central Administration site to block external access and secure internal access. The Central Administration site includes the Search Administration pages:

  • Ensure that the Central Administration site is not hosted on a front-end Web server.

  • Block external access to the Central Administration site. This can be achieved by placing a firewall between front-end Web servers and the server that hosts the Central Administration site.

  • Configure the Central Administration site by using SSL. This ensures that communication from the internal network to the Central Administration site is secured.

Secure design checklist

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

Use this design checklist together with the checklists in Plan server farm security (Search Server 2008).

Topology

[ ] | Protect back-end servers by positioning at least one firewall between front-end Web servers and the application and database servers.
[ ] | Plan a dedicated front-end Web server for crawling content. Do not include this front-end Web server in the end-user front-end Web rotation.

Logical architecture

[ ]

Block access to the Central Administration site and configure SSL for this site.

Plan security hardening for server roles

The following table describes additional hardening recommendations for an external secure search access environment.

Component | Recommendation
Ports | Block external access to the port for the Central Administration site.
IIS | Restrict SiteData.asmx (the crawler SOAP service) to let only the index server (or other crawlers) to access it.

Plan secure configurations for Search Server 2008 features

The following table describes additional recommendations for securing Microsoft Search Server 2008 features. These recommendations are appropriate for an external secure search access environment.

Feature or area | Recommendation
Authenication | Use SSL for authenticated users.
Authorization | Use security policy to restrict external users' permission (that is, create deny policies to limit what external users can do).

See Also

Concepts

Plan environment-specific security (Search Server 2008)
Plan security for an internal team or department environment (Search Server 2008)
Plan security for an external anonymous access environment (Search Server 2008)


Plan security for an external anonymous access environment (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Security guidance for an external anonymous access environment is to enable anonymous access to search functions while protecting back-end servers in the farm from direct user access or malicious actions that come through front-end Web servers.

There are several unique recommendations for an external anonymous access environment. Some of these recommendations might not be practical for all solutions.

In this article:

  • Protect back-end servers

  • Configure anonymous access

  • Secure the Central Administration site

  • Secure design checklist

  • Plan security hardening for server roles

  • Plan secure configurations for Search Server 2008 features

Protect back-end servers

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

Hosting sites for anonymous use requires Internet-facing servers. You can limit the exposure to traffic from the Internet by protecting back-end servers. This includes the index server and other application server roles and servers that host databases:

  • Protect database servers At a minimum, place a firewall between front-end Web servers and servers that host databases. Some environments dictate that database servers be hosted in an internal network instead of directly in an extranet environment.

  • Protect application servers At a minimum, protect application servers by requiring Internet Protocol security (IPsec) to help secure communication between server farm computers. Additionally, you can put application servers behind the firewall used to protect database servers. Or, you can introduce an additional firewall between front-end Web servers and application servers.

  • Protect the index role The index component communicates through a front-end Web server to crawl content in sites. To protect this communication channel, consider configuring a dedicated front-end Web server for use by the index server. This isolates crawling communication to a front-end Web server that is inaccessible to users. Additionally, configure Internet Information Services (IIS) to restrict SiteData.asmx (the crawler SOAP service) to enable only the index server (or other crawlers) to access it. Providing a front-end Web server dedicated to content crawling also improves performance by reducing the load on the main front-end Web servers. This improves the user experience.

Configure anonymous access

For content to be available for anonymous access, the following must be configured:

  • The site or site collection must be configured to enable anonymous access.

  • At least one zone in the Web application must be configured to allow anonymous access.

Enable anonymous access only for Web applications that require unauthenticated access. If you want to use authentication for personalization, implement forms-based authentication by using a simple database authentication provider.

Secure the Central Administration site

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

Because external users have access to the network zone, it is important to secure the Central Administration site to block external access and secure internal access:

  • Ensure that the Central Administration site is not hosted on a front-end Web server.

  • Block external access to the Central Administration site. This can be achieved by placing a firewall between front-end Web servers and the server that hosts the Central Administration site.

  • Configure the Central Administration site by using Secure Sockets Layer (SSL). This ensures that communication from the internal network to the Central Administration site is more secure.

Secure design checklist

Use this design checklist together with the checklists in Review the secure topology design checklists (Search Server 2008).

Topology

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

[ ] | Protect back-end servers by positioning at least one firewall between front-end Web servers and the application and database servers.
[ ] | Plan a dedicated front-end Web server for crawling content. Do not include this front-end Web server in the end-user front-end Web rotation.

Logical architecture

[ ] | Enable anonymous access only for Web application zones that host sites or site collections that are configured to allow anonymous access. For more information, see Plan authentication methods (Search Server 2008).
[ ] | Block access to the Central Administration site and configure SSL for the site.

Plan security hardening for server roles

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

The following table describes additional hardening recommendations for an external anonymous access environment.

Component | Recommendation
Ports | Block external access to the port for the Central Administration site.
Protocols | Turn off SMTP.
IIS | If you are configuring a dedicated front-end Web server for indexing, configure IIS to restrict SiteData.asmx (the crawler SOAP service) to allow only the index server (or other crawlers) to access it.

Plan secure configurations for Search Server 2008 features

The following table describes additional recommendations for securing Microsoft Search Server 2008 features in an external anonymous access environment.

Feature or area | Recommendation
Authentication | Specify Anonymous authentication in IIS.

See Also

Concepts

Plan environment-specific security (Search Server 2008)
Plan security for an internal team or department environment (Search Server 2008)
Plan security for an external secure search environment (Search Server 2008)


Plan for security roles (Search Server 2008)
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Farm-level administration

  • Site-level administration

  • Worksheet

Microsoft Search Server 2008 supports a two-tier administrative model that centralizes configuration and administration tasks, enables administrative roles to be differentiated, and administration to be delegated and assigned to the appropriate people in your organization. The administrative model can help IT organizations perform administrative tasks more efficiently and effectively. You can use the administrative model and SharePoint groups to give only the permissions that are required to perform specific tasks based on specific roles in your organization. To more effectively work within the two-tier administrative model, many organizations designate specific administrative roles within each tier. This article discusses administrative roles within each tier that you can use to help administer your solution.

The following list describes each administrative tier.

  • Tier 1: Farm-level administrators Administrators in this tier are the top-level administrators and have permissions to and responsibility for all servers and farm-level services in the server farm. Members can perform all administrative tasks in the Central Administration Web site and in the Search Administration pages for the server or server farm.

  • Tier 2: Site collection administrators Site collection administrators have the Full Control permission level on their site collections. In Search Server 2008, there is single site collection by default that contains the Search Center. Site collection administrators have full control over the Search Center. You can also choose to create other site collections and subsites.

Search Server 2008 provides flexibility in how you assign administrative roles. In a centralized administration model, you can assign all administrative roles to one or two people in the organization. Alternatively, in a distributed administration model, you can delegate farm-level and site collection administrative roles to different people in the organization.

Farm-level administration

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

Farm-level administration typically is performed by the following roles:

  • Farm administrators

  • Server-level administrators

Farm administrators

The farm administrator has permissions to and responsibility for all servers in the server farm. Members of the Farm Administrators SharePoint group do not have to be added to the Administrators group for each server. Farm administrators are members of the WSS_WPG and WSS_RESTRICTED_WPG groups on the computers where Central Administration is hosted and have the Full Control permission level on all servers in the environment. By default, members of the Administrators group are members of the Farm Administrators group.

Members of the Farm Administrators group have broad ability to manage the Central Administration site and Search Administration pages, but are restricted in performing some actions (that is, create Internet Information Services (IIS) Web sites, create or delete SharePoint Web applications, update account passwords or Windows services) because of certain constraints in IIS and the Microsoft .NET Framework. The Farm Administrators group is used in Central Administration and Search Administration only, and is not available for any sites.

Note Note:

Carefully decide to whom you grant memberships in the Administrators group on the local database server computer and to whom you grant memberships in fixed database roles and fixed server roles in Microsoft SQL Server. This is because this group and these roles have the Full Control permission level on the SharePoint Products and Technologies configuration database.

The following table lists tasks that members of the Farm Administrators group can perform.

SharePoint group | Does role exist by default? | Can do this | Cannot do this
Farm Administrators | Yes | Perform administrative tasks in Central Administration. Perform administrative tasks in Search Administration. Take ownership of the Search Center or any content site. | Administer other sites or site content unless they take ownership.

Server-level administrator

Members of the Administrators group on the local server computer are automatically added to the Farm Administrators SharePoint group and can perform all farm administrator actions. The Administrators group is a Windows group, not a SharePoint group, but the Administrators group on the local computer runs certain administrative tasks in Search Server 2008.

The following table describes the server-level administrator role.

Group Does role exist by default? Can do this Cannot do this

Administrators

Yes. Windows group that exists by default; not a SharePoint group.

Install products.

Create new Web applications and new Internet Information Services (IIS) Web sites.

Start services.

Deploy Web Parts and new features to the global assembly cache.

Perform all farm-level tasks in Central Administration and Search Administration (as long as the Central Administration site is located on the local computer).

Run the Stsadm command-line tool.

Note Note:

Being a server-level administrator is a pre-requisite of running the Stsadm command-line tool. Depending on which command you actually run, you might need additional permissions. For example, if you run stsadm.exe -o deleteweb, the command requires that the account have write access to the content database that contains the Web application.

Administer the Search Cetner or other sites or site content.

Administer databases.

Site-level administration

When you install Microsoft Search Server 2008, a site collection is created to host the Search Center. In most cases, no additional site collections or subsites are required and site-level administrators are those who control the Search Center. Optionally, you can create other site collections or subsites with other site-level administrators, but this is not typical in a Search Server 2008 deployment.

Site-level administration includes the following roles:

  • Site collection administrators

  • Site owners

Site collection administrators

Site collection administrators have the Full Control permission level on the Search Center. From the site collection level, site collection administrators manage settings (such as site collection features, site collection audit settings, and site collection policies) from the Site Settings page for the top-level site. When you create a site collection, you can specify the primary and secondary site collection administrators. A site collection administrator is a user with a flag in the content database that states they can perform all tasks in a site collection, including all tasks for specific sites in a site collection. This flag can be changed by using the Site Collection Administrators page in Central Administration, by using the Site Settings page on a top-level site, or by using the site owner operation with the Stsadm command-line tool. Generally, you designate site collection administrators when you create the site, but you can change them as needed in Central Administration or by using the Site Settings pages.

The following table describes the site collection administrator role.

SharePoint group | Does role exist by default? | Can do this | Cannot do this
Site collection administrator | Yes | Perform all administration tasks for the Search Center or other site collection or subsites. | Access the Central Administration site or the Search Administration pages.

Site owners

Site owners are those who have been specifically granted the Full Control permission level on the site, either directly or by being a member of a SharePoint group — for example, the Owners group — that has the Full Control permission level on the site. Site owners can perform tasks related to the site only, not the whole site collection.

Note Note:

In a typical Search Server 2008 system, there is only one site - the Search Center. Therefore, site owners and site collection administrators have the same role. If you decide to create subsites, the site owner and site collection administrator roles are differentiated because the site owner can administer only a subsite. The site collection administrator can administer all sites in the site collection.

Note Note:

The user who creates the site is automatically added to the Owners group for the site.

The following table describes tasks that site owners can perform.

SharePoint group | Does role exist by default? | Can do this | Cannot do this
<Site name> Owners | Yes | Perform administration for the site only, not the whole site collection. Perform administrative tasks for documents, lists, and libraries. | Access the Central Administration site. Access the Search Administration pages. Perform site collection administration tasks, such as restoring items from the second-stage Recycle Bin and managing the site hierarchy.

For more information about site-level administration, see Choose administrators and owners for the administration hierarchy (Office SharePoint Server).

Worksheet

Use the following worksheet to plan for security roles.

  • Administrators and owners worksheet

See Also

Concepts

Plan for security (Search Server 2008)
Choose the security environment (Search Server 2008)
Plan server farm security (Search Server 2008)
Plan secure configurations for Search Server 2008 features
Plan environment-specific security (Search Server 2008)


Plan secure configurations for Search Server 2008 features
DropDown image

Updated: 2009-07-13

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Use this article to find recommendations for configuring and managing Microsoft Search Server 2008 features in a more secure manner. You will usually perform the recommended configurations in Central Administration, instead of in the network, operating system, Internet Information Services (IIS), or the Microsoft .NET Framework. The recommendations in this article are appropriate for the following security environments:

  • Internal team or department

  • External secure access

  • External anonymous access

For more information about these environments, see Choose the security environment (Search Server 2008).

Recommendations for Search Server 2008 features

The following table describes more secure recommendations for Search Server 2008 features.

Feature or area Description and recommendation

Authentication

  • Do not use client-side automatic logon when you are using the Central Administration site.

  • Allow only front-end Web server computers to perform authentication of users. Do not enable end-user accounts or groups to authenticate against the database server computer.

Authorization

Assign permissions to groups instead of individual accounts.

Permission levels

Assign users the least permissions that are required to complete their tasks.

Administration

Use access permissions to help secure the Central Administration site and let administrators connect to the site remotely, instead of enabling the Central Administration site for local computer use only. This removes the requirement that administrators log on locally to the computer that is hosting Central Administration. Configuring Terminal Services access to the computer creates a larger security risk than leaving the Central Administration Web site available for remote access.

Web Part storage and security

  • Ensure that you deploy only trusted code to your server farm. All code, XML, or ASP.NET code that you deploy should be from a trusted source, even if you intend to tighten security after deployment with defense-in-depth measures such as code access security.

  • Ensure that the SafeControl list in the Web.config file contains the set of controls and Web Parts that you want to enable.

  • Ensure that custom Web Parts that you plan to reinforce with defense-in-depth measures are installed into the bin directory of the Web application (where partial trust is turned on), with specific permissions for each assembly.

  • Consider removing the Content Editor Web Part from the SafeControl list. This prevents users from adding JavaScript into the page as a Web Part and using JavaScript that is hosted on external servers.

  • Ensure that appropriate people in your organization are granted the Design and Contribute permission levels in your site. In Search Server 2008 the default end-user site is the Search Center. A user who has the Contribute permission level can upload Active Server Page Extension (ASPX) pages to a library and add Web Parts. Users with the Design permission level, who can add Web Parts, can edit pages. This includes the home page on your site (Default.aspx).

Search

  • The default content access account must not be a member of the Farm Administrators group; otherwise, the Search Server 2008 Search service indexes unpublished versions of documents.

  • Ensure that additional IFilters and word breakers that you deploy are trusted by the IT team.

  • By default, the search index file is accessible only by members of the Farm Administrators group. Ensure that this file cannot be accessed by users who do not belong to this group. The index file is, by default, located in the C:\Indexes\Office Server\Applications folder.

Self-service site creation

You can use the Self-Service Site Management page to let users automatically create and manage their own top-level Web sites. If the Search Server system is primarily intended for search and not collaboration, you should turn off self-service site creation. If you want to use the collaboration features that are available in Search Server 2008, consider the following points before you enable self-service site creation.

When you enable self-service site creation for a Web application, users can create their own top-level Web sites under a specific path (by default, the /sites path). When self-service site creation is enabled, an announcement is added to the top-level site at the root path of the Web application, and users who have permissions to view that announcement can link to the new site.

Whether you should enable self-service site creation depends on the environment:

  • Intranet environment Enable self-service site creation according to business need.

  • Secure collaboration environment Enable self-service site creation only for people or groups that have a business need for this feature.

  • External anonymous environment Do not enable self-service site creation on the Internet.

See Also

Concepts

Plan for security (Search Server 2008)
Choose the security environment (Search Server 2008)
Plan server farm security (Search Server 2008)
Plan environment-specific security (Search Server 2008)
Plan for security roles (Search Server 2008)


Deployment for Search Server 2008
DropDown image

Updated: 2008-03-03

In this section:

  • Install Search Server 2008 or Search Server 2008 Express — See this topic for installation instructions for both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

  • Add query servers to expand a farm (Search Server 2008) — See how to add an additional application server and configure it as a query server in an existing Search Server 2008 deployment.

  • Deploy language packs (Search Server 2008) — See this topic for information about language packs.


Install Search Server 2008 or Search Server 2008 Express
DropDown image

Updated: 2008-03-03

This article explains how to install Microsoft Search Server 2008 or Microsoft Search Server 2008 Express on the first computer in a Search Server deployment. This installation produces a fully functional Search Server configuration.

This article contains the following main sections:

  • Prepare for installation

  • Install and configure Search Server

Prepare for installation

In this section:

  • Determine the kind of deployment you need

  • Prepare hardware and software

Determine the kind of deployment you need

Before you begin an installation, ensure that you understand the differences between Search Server 2008 and Search Server 2008 Express, as well as the installation options for each product. Certain installation options enable you to add servers at any time to expand an existing deployment. For more information, see Plan to deploy Search Server 2008 or Search Server 2008 Express.

Prepare hardware and software

Ensure that the host computer meets the minimum requirements described in Determine hardware and software requirements (Search Server 2008).

Note Note:

If you install Search Server 2008 or Search Server 2008 Express with the Advanced installation option, you must specify an existing database server that is running either Microsoft SQL Server 2005 with at least SP2, or SQL Server 2000 with at least SP3a. Some advanced features require SQL Server 2005 Analysis Services with at least SP2. For information about hardware and software requirements for deploying a database server running SQL Server 2005, see SQL Server 2005 System Requirements.

Install and configure Search Server

Ensure that you are logged on with an account that has local administrator permissions, and then do the following.

  • Start the installation

  • Run the Search Server Preparation Tool

  • Install Search Server 2008 or Search Server 2008 Express

Start the installation

Follow this procedure to begin the setup process.

To start the installation

  • Start the installation by doing one of the following:

  • Download and install Search Server 2008 Express:

    1. Download Search Server 2008 Express from the Microsoft Enterprise Search Web site. Select the download option that corresponds to the x86 or x64 operating system architecture (32-bit-based or 64-bit-based) on which you plan to install Search Server Express.

    2. Navigate to and run the downloaded file, SearchServerExpress.exe, which is a self-extracting archive. The file automatically uncompresses and the Search Server Express installation Start screen appears.

  • To install Search Server 2008 or Search Server 2008 Express from a product disc, insert the disc in the CD-ROM drive. The product installation Start screen appears.

    Note Note:

    If the installation Start screen does not appear automatically after a short time, navigate to the root folder of the product disc and double-click the file Splash.hta.

  • To install Search Server 2008 or Search Server 2008 Express from a local disk or file share, navigate to the product location and double-click the file Splash.hta. The product installation Start screen appears.

Run the Search Server Preparation Tool

The Search Server Preparation Tool checks your computer for required components and updates. The tool performs each of the following tasks, if necessary:

  • For Windows Server 2003 operating systems:

    • Downloads and installs Service Pack 1 if no service pack is installed.

    • Downloads and installs Microsoft .NET Framework 3.0 if .NET Framework 2.0 and Windows Workflow Foundation Runtime Components are not installed.

  • Activates the IIS Application Server role and enables ASP.NET Web Server extensions.

To run the Search Server Preparation Tool

  1. On the Search Server installation Start screen, under Install, click Run the Search Server Preparation Tool. The Welcome to the Microsoft Search Server 2008 Preparation Tool screen appears.

  2. Follow the instructions as the Search Server Preparation Tool runs. The time required to complete the procedure varies depending on the number of components that the tool must install and the speed of your network connection.

  3. On the Installation Complete screen, click Finish.

Install Search Server 2008 or Search Server 2008 Express

Follow this procedure to continue the installation process.

To install Search Server 2008 or Search Server 2008 Express

  1. On the installation Start screen, click Install Search Server.

  2. For Search Server 2008 only:

    1. On the Enter your Product Key screen, enter your Product Key. After the installation program validates the Product Key, it places a green check mark next to the Product Key box.

    2. Click Continue after the installation program verifies your Product Key.

  3. On the Read the Microsoft Software License Terms screen, review the terms, select the I accept the terms of this agreement check box, and click Continue.

  4. On the Choose the installation you want screen, click Basic or Advanced.

    For an explanation of the Basic and Advanced installation options, see "Choosing Basic or Advanced installation" in Plan to deploy Search Server 2008 or Search Server 2008 Express.

Depending on whether you chose the Basic or Advanced installation option, proceed to one of the following sections in this article to complete your installation:

  • Run a Basic installation

  • Run an Advanced installation

Run a Basic installation

Follow this procedure to complete a Basic installation.

To complete a Basic installation

  1. On the Choose the installation you want screen, click Basic. The Installation Progress screen appears. This part of the setup process takes several minutes to complete.

  2. On the nextscreen, which prompts you to complete the configuration:

    1. Ensure that the Run the SharePoint Products and Technologies Configuration Wizard now check box is selected.

    2. To start the Configuration Wizard, click Close.

  3. On the Welcome to SharePoint Products and Technologies screen, click Next.

  4. In the dialog box that notifies you that some services might be restarted or reset during configuration, click Yes.

    The Configuration Wizard runs for several minutes to automate configuration tasks such as installing Search Server services, installing and configuring SQL Server databases, and creating the Search Server Web applications and sites for Central Administration, Search Administration, and the Search Center.

  5. On the Configuration Successful screen, click Finish. Your Basic installation is now complete. A Web browser opens the Welcome to Microsoft Search Server 2008 page, which provides guidance for configuring your Search Server installation.

    Note Note:

    If you are prompted for your user name and password, type the credentials you used to log on to the computer. Add the site to the list of trusted sites in Windows Internet Explorer when you are prompted.

  6. On the Welcome to Microsoft Search Server 2008 page, follow the instructions to do the following:

    1. Open the Search Administration Web site to configure and monitor Search Server.

    2. Begin crawling content to build a content index.

    3. Open the Search Center site to try a search.

Note Note:

This completes the Basic installation process. The remaining procedures in this article pertain to Advanced installation only.

Run an Advanced installation

Use the following procedure to run an Advanced installation. Then proceed to the following section, Complete the Search Server Configuration page, to configure and complete your Advanced installation.

To run an Advanced installation

  1. On the Choose the installation you want screen, click Advanced. The Server Type screen appears.

  2. On the Server Type screen:

    • In the Server Type tab, click Complete. This option installs the application server role and Web front-end server (WFE) role.

      For an explanation of the application server role and WFE server role, see "Choosing Basic or Advanced installation" in Plan to deploy Search Server 2008 or Search Server 2008 Express.

    • Optional: In the File Location tab, change the installation path or the location for content index files.

    • Optional: In the Feedback tab, specify whether you want to participate in the Customer Experience Improvement Program.

  3. Click Install Now. The Installation Progress screen appears. The process takes several minutes to complete.

  4. On the nextscreen, which prompts you to complete the configuration:

    1. Ensure that the Run the SharePoint Products and Technologies Configuration Wizard now check box is selected.

    2. Click Close to start the Configuration Wizard.

  5. On the Welcome to SharePoint Products and Technologies screen, click Next.

  6. In the dialog box that notifies you that some services might be restarted or reset during configuration, click Yes.

  7. On the Connect to Server Farm screen, click No, I want to create a new server farm, and then click Next.

  8. On the Specify Configuration Database Settings screen, fill in the following fields as appropriate for your organization:

    • Database Server - Name of an existing SQL Server host running one of the following product versions:

      - SQL Server 2000 with at least SP3a.

      - SQL Server 2005 with at least SP1. Some advanced features require SQL Server 2005 Analysis Services with at least SP2.

    • Database Name - Accept the default database name (SharePoint_Config) or type a different name. If the specified database already exists, it must be empty. If the database does not exist, it is created.

      Make a note of the database name you specify here in case you add servers to your Search Server deployment later. It might be helpful to specify a friendly name that you can remember. You need to specify the database name again when you install Search Server on additional servers for your farm.

    • Database Access Account - Follow the instructions on the screen.

  9. Click Next.

  10. On the Completing the SharePoint Products and Technologies Configuration Wizard screen, confirm your settings, ensuring that you entered the correct Configuration Database Server name and Configuration Database Name.

  11. Click Next. The Configuration Wizard runs for several minutes to automate a number of configuration tasks.

  12. On the Configuration Successful page, click Finish. A Web browser opens and loads the Search Server Configuration page.

    Note Note:

    If you are prompted for your user name and password, type the credentials you used to log on to the computer. Add the site to the list of trusted sites in Windows Internet Explorer when you are prompted.

Complete the Search Server Configuration page (Advanced installation only)

The Search Server Configuration page appears at the end of the Advanced installation process. You complete the Search Server Configuration page only once for any particular server farm. There are two main groups of settings on the page:

  • Required For most deployments, you need to specify settings in the Required group only. Configure these settings as appropriate for your organization.

  • Optional All settings in this group are default values. To modify any of these values, expand the appropriate section and modify the default values.

To complete Search Server Configuration page Required settings

  1. In the Default Account For Services section, type the user name and password for the default services account.

  2. In the Search Center Account section, type the user name and password for the account for the application pool identity of the default Search Center site.

  3. In the Search Contact E-mail section, type the e-mail address of a person in your organization.

  4. If you do not need to configure any of the settings in the Optional section of the Search Server Configuration page:

    1. Click OK. The Operation in Progress page displays the progress of starting services, creating the shared services provider, and creating the Web applications and sites for Central Administration, Search Administration, and the default Search Center site. This configuration takes several minutes. Your Advanced installation and configuration is now complete.

    2. On the Search Server Configuration is Complete screen, click OK. A Web browser opens the Welcome to Microsoft Search Server 2008 page, which provides guidance for configuring your Search Server installation.

    3. On the Welcome to Microsoft Search Server 2008 page, follow the instructions to do the following:

      i. Open the Search Administration Web site to configure and monitor Search Server.

      ii. Begin crawling content to build a content index.

      iii. Open the Search Center site to try a search.

To complete Search Server Configuration page Optional settings

  1. In the Search Center Site section, specify whether to create a Search Center site. The Search Center site hosts the end-user search page and results pages.

    • To create a Search Center site using default settings, click Yes.

    • If you do not need a Search Center site, or if you plan to create and configure a Search Center site later, click No. If you click No, a default Search Center site is not created.

  2. In the Index File Location section, accept the default setting or specify a different path for the index files.

  3. In the Search Services Administration Account section, to use an account other than the default account for services, specify credentials of an existing user account.

  4. In the Database for Search Administrative Settings section:

    • Type the name of the search services database for query logs and administrative settings.

    • Specify the Database authentication method. We recommend using Windows authentication.

  5. In the Search Service Account section, to use an account other than the default account for services, specify credentials of an existing user account.

  6. In the Database for the Search Service section:

    • Specify the database server and database for volatile search-related data, or accept the default settings.

    • Specify the Database authentication method. We recommend using Windows authentication.

  7. In the Help Search Service Account section, to use an account other than the default account for services, specify credentials of an existing user account.

  8. In the Database for the Help Search Service section:

    • Specify the database server and database for data for the service that indexes Help content.

    • Specify the Database authentication method. We recommend using Windows authentication.

  9. In the SSL for Web Services section, specify whether to use secure sockets layer (SSL) encryption to protect servers using Web services.

    Note Note:

    If you click Yes to use SSL, Web services are not available until you use Internet Information Services (IIS) Manager to add an SSL certificate to each farm server.

  10. After you finish specifying configuration settings:

    1. Click OK. The Operation in Progress page displays the progress of starting services, creating the shared services provider, and creating the Search Server Web applications and sites for Central Administration, Search Administration, and the default Search Center if you are creating one. This configuration takes several minutes. Your Advanced installation and configuration is now complete.

    2. On the Search Server Configuration is Complete screen, click OK. A Web browser opens the Welcome to Microsoft Search Server 2008 page.

  11. On the Welcome to Microsoft Search Server 2008 page, follow the instructions to do the following:

    1. Open the Search Administration Web site to configure and monitor Search Server.

    2. Begin crawling content to build a content index.

    3. Open the Search Center site to try a search.

Note Note:

After you install Search Server 2008 with the Advanced installation option, you can add query servers to expand your deployment at any time. For information about Search Server topology options and the advantages of adding query servers to a deployment, see Plan to deploy Search Server 2008 or Search Server 2008 Express. To add one or more query servers to your deployment, follow the instructions in Add query servers to expand a farm (Search Server 2008).

See Also

Concepts

Determine hardware and software requirements (Search Server 2008)
Planning and architecture for Search Server 2008
Plan to deploy Search Server 2008 or Search Server 2008 Express
Add query servers to expand a farm (Search Server 2008)


Use scripts to install Search Server 2008
DropDown image

Updated: 2008-09-25

Using scripts to install Microsoft Search Server 2008 enables you to perform unattended installations of Search Server 2008, maintain consistency across installations, and position you for server recovery in the event of a system failure.

This article is based on the white paper written by Ben Curry, CISSP, Office SharePoint Server MVP. It is modified, with the author's permission, for publishing to Microsoft TechNet. The original white paper and accompanying scripts are available for download from the Mindsharp Web site.

Overview

This article describes how to create scripts that you can use to install and configure the basic functionality of Search Server 2008. For ease of creation, management, and portability, we will create three separate scripts. Each of these scripts will perform a different function in the installation.

Note Note:

You could combine all the scripts into one master script. However, we have found that keeping them separate and calling them from a master script is the best practice.

This article describes how to change existing scripts available from http://www.mindsharp.com premium content area (free), or create new scripts that you can use to install Search Server 2008 in a farm environment. The basic process is as follows.

  1. Create a very simple configuration file that is named config.xml. This configuration file is used by setup.exe to determine what binaries have to be installed, the installation method, and product key information.

  2. Create three scripts.

    • bits.cmd This script will install the binaries for the specific installation, and requires the configuration file config.xml.

    • farm-build.cmd This script will build the initial configuration database, create and provision Central Administration, and start the required services in the farm.

    • farm-connect.cmd (optional) If you will have multiple servers in the search farm you need this script to attach the additional servers to the previously created configuration database.

  3. Run the preceding scripts in the order they were created.

  4. Debug and fix any errors in the scripts — for example, typographical errors, user name and password errors, and server names.

    Continue testing the scripts until they complete without error.

    Important Important:

    It is very important to get an error-free installation if you will be doing remote installations or using scripts for disaster recovery.

Before you begin

Before continuing to the script creation phase, you have to determine how the Search Server 2008 farm will be deployed. If you use a stand-alone installation, the installer will install Microsoft SQL Server 2005 Express Edition. Although this greatly simplifies installation, most administrators will not install with this method because you are limited to a single server. Instead, this article describes a Search Server 2008 installation that uses either SQL Server 2005 Standard Edition or SQL Server 2005 Enterprise Edition.

Note Note:

These scripts have not been re-factored using variables because every farm installation is unique. You will have to edit the scripts to reflect the specific implementation. For reference, these scripts were designed for a computer that is running SQL Server named app1, and a computer that is running Search Server 2008 named app2. You will have to edit the server names, Active Directory domain, and user names as required.

Prerequisites and assumptions

Review the hardware and software requirements that are regularly updated at http://technet.microsoft.com/en-us/library/bb905370.aspx.

Because these scripts also need a basis for an Active Directory name, user names, password, and server names, we have used the following names that you will have to change for the deployment.

  • contoso.msft - Active Directory name

  • contoso\mossfarm - Farm Account (Central Admin App Pool Id)

  • contoso\mosscrawler - Search Crawler Account (default content access account for Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0)

  • contoso\mossservice - Core Service Account

  • contoso\sspapid - Shared Services Host App Pool Identity

  • contoso\sspservice - SSP Services Account

  • contoso\portalapid - Search Portal App Pool Identity

The Farm Administrator account must be a member of the dbcreator and securityadmin fixed server roles in SQL Server. It must also be a member of the Administrators group on the local server during installation. All other permissions will be granted automatically during installation. You must log on as the Farm Administrator account for installation, or create another account to use as the installer account.

If you want additional service account isolation, you should change the script as needed. These scripts assume a common service account. If you want a single application pool and associated identity, you should change the script accordingly. These scripts create a separate application pool and associated identity for every Web application that is created.

The servers in the testing farm for the scripts are as follows.

  • App1 - Microsoft SQL Server 2005 Service Pack 2 (SP2) default install and part of the Active Directory contoso.msft domain.

  • App2 - Part of the contoso.msft Active Directory domain.

  • QueryN - Query servers that will use the farm-connect.cmd script. They should also be part of the Active Directory contoso.msft domain.

Modifying config.xml and installing the binaries

to start scripting a Search Server 2008 installation, you have to create a copy of the config.xml file that comes on the installation media. The config.xml file is used by setup.exe as instructions for the binaries installation. After you have modified a copy of this file, it will be used during setup and will affect what software is installed and how it is installed, automate entry of the product ID that is located on the installation media, and define if you will have a graphical representation of the installation process.

You can find several examples on the installation media under x86\Files\Setup<type> for 32-bit media, and x64\Files\Setup<type> for 64-bit media. If you are using the downloadable trial version of Search Server 2008, you have to first extract the contents by the running the following command at a command prompt:

searchservertrial.exe /extract: <drive> :\ <folder>

where:

  • <drive> is the drive letter on which you want to extract the contents of the executable file.

  • <folder> is the name of the folder on which you want to extract the contents of the executable file.

In the <drive>:\<folder>\files\SetupFarmSilent directory, you will find a copy of config.xml. To completely automate the installation of Search Server 2008, you must edit this file. For script creation and testing, you should create a directory, such as c:\scripts, and copy the config.xml file to this location. We recommend that you do not use an XML editor, such as Microsoft Visual Studio, to edit this file. We recommend that you use notepad.exe so the formatting is not modified. The following is an example of the default config.xml file.

CopyCode image Copy Code
<Configuration>
<Package Id="sts">
<Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes"/>
<Setting Id="REBOOT" Value="ReallySuppress"/>
<Setting Id="SETUPTYPE" Value="CLEAN_INSTALL"/>
</Package>

<Logging Type="verbose" Path="%temp%" Template="Search Server Setup(*).log"/>
<Display Level="none" CompletionNotice="no" />
<Setting Id="SERVERROLE" Value="APPLICATION"/>
<Setting Id="USINGUIINSTALLMODE" Value="0"/>
</Configuration>

Before you modify config.xml

Depending on which binaries and services that you have to install, you have two choices for the kind of installation to perform. The options are as follows:

  • SINGLESERVER The SINGLESERVER option, set by modifying the 'SERVERROLE' parameter, will install Microsoft SQL Server 2005 Express Edition, together with the Search Server 2008 binaries. This article does not include instructions on how to use this option.

  • APPLICATION The APPLICATION option will install all binaries required to support Search Server 2008, except SQL Server. You must already have an instance of SQL Server 2005 Standard or Enterprise edition installed that can be accessed by the server that will host Search Server 2008. This is the installation option that is used in this article.

Modifying config.xml

The "Display Level" setting should be set to "none" because setting it to "Basic" will keep the installation script from using custom parameters. You should also leave the setting "USINGUIINSTALLMODE" set to "0".

Next, you have to insert an entry for the product ID (PIDKEY Value) that is found on the installation media. The following example shows these settings.

CopyCode image Copy Code
<Configuration>
<Package Id="sts">
<Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes"/>
<Setting Id="REBOOT" Value="ReallySuppress"/>
<Setting Id="SETUPTYPE" Value="CLEAN_INSTALL"/>
</Package>
<Logging Type="verbose" Path="%temp%" Template="Search Server Setup(*).log"/>
<Display Level="none" CompletionNotice="no" AcceptEULA="Yes" />
<PIDKEY Value="D2KBC-9JQ6T-4P6C2-F7BFF-BB96D" />
<Setting Id="SERVERROLE" Value="APPLICATION"/>
<Setting Id="USINGUIINSTALLMODE" Value="0"/>
</Configuration>
Note Note:

The previous example uses a key for the trial version of Search Server 2008. You have to provide the key for a fully functional version of the product.

You will want robust logging if installing remotely. Therefore, make sure that you define a logging location that you can access from the remote location. The default logging location is in %temp%. This location is for the binary installs only, not for farm provisioning. Farm provisioning logs are in the 12 \Logs directory.

Create the bits.cmd script

The bits.cmd script is used to install the binaries. It uses setup.exe and references the config.xml file that you modified. Create this script using the following example.

CopyCode image Copy Code
:: Installs binaries
:: Requires .NET2, .NET3, and IIS. As an alternative run the prerequisite installer.
@echo off
c:\searchiso\setup.exe /config c:\scripts\config.xml

At this point, you have created the first script that installed the binaries on the first server in the farm. You still have to create the server farm (server farm = configuration database) and create the required Web applications.

Create the farm-build.cmd script

After the binaries are installed, you must continue provisioning the Search Server 2008 farm. Remember, a server "farm" = configuration database. A complete server farm typically has several servers. However, for the purposes of this article we are installing Search Server 2008 on one computer. Doing so will not prevent you from scaling out this farm in the future. We will not discuss how to build a multi-server farm in this article. For more information, see Plan for redundancy (Search Server 2008). Instead, we will focus on how to use psconfig.exe and stsadm.exe commands to build a script for provisioning a single server farm.

Note Note:

There is a short sample script at the end of this article that shows how to connect additional servers to the farm.

After you installed the binaries with bits.cmd, you have access to psconfig.exe in the 12 hive, specifically, %COMMONPROGRAMFILES %\ Microsoft Shared\web server extensions\12\BIN\psconfig.exe. To create the server farm, define the instance of SQL Server and database name, as follows:

psconfig.exe -cmd configdb -create -server app1 -database ContosoSearch_SharePoint_ConfigDB -user contoso\mossfarm -password P@ssw0rd -admincontentdatabase Central_Admin_Content

The previous command creates a server farm on an instance of SQL Server named app1, with a configuration database named ContosoSearch_SharePoint_ConfigDB. It also created a content database and embedded site collection for Central Administration. This occurs when you are using the graphical user interface, you merely do not see it.

Note Note:

We are using the contoso\mossfarm account as the installer account. This account only needs administrative permission during installation, and you can remove its local administrator permissions after installation is completed.

The next step is to provision Central Administration on at least one server in the farm. You have already created the Web application when you created the farm. However, you must still provision an Internet Information Services (IIS) server to render the content. For this example, we will install on app2, the first server in the farm by using the following command:

psconfig.exe -cmd adminvs -provision -port 12345 -windowsauthprovider onlyusentlm

After provisioning Central Administration, you must install all services associated with the installed server role. This is performed by the following command:

psconfig.exe -cmd services install

The next, and very important step, is setting the security on registry settings and the file system. If you do not do so, the installation will complete correctly. However, you will have miscellaneous errors.

psconfig.exe -cmd secureresources

After you have created the farm, provisioned Central Administration, installed services, and secured resources, you have to start required services, most notably, the search services. First, we start Search Server 2008 by using stsadm.exe, which is located in the 12 hive \Bin directory. You should define parameters, such as performance level and index location.

Note Note:

Although the following script example shows c:\ as the index location, it is a best practice to put the index files on a volume other than the system drive.

stsadm.exe -o osearch -action start -role query -farmcontactemail administrator@contoso.msft -farmperformancelevel maximum -farmserviceaccount "contoso\mossservice" -farmservicepassword P@ssw0rd -propagationlocation c:\indexes

After starting the Search service, start Windows SharePoint Services 3.0 search by using the following command:

stsadm.exe -o spsearch -action start -farmserviceaccount contoso\mossservice -farmservicepassword P@ssw0rd -farmcontentaccessaccount contoso\mosscrawler -farmcontentaccesspassword P@ssw0rd -databaseserver app1 -databasename Contoso_WSS_App2_Search

At this point, verify that all the features have been installed correctly by using the following command:

psconfig.exe -cmd installfeatures

Now you must create a Web application to host the Shared Services Provider for Search Server 2008.

stsadm.exe -o extendvs -url http://ssp.contoso.msft -exclusivelyusentlm -databaseserver app1 -databasename Contoso_WSS_Content_SSP -donotcreatesite -description "Search Admin Host" -sethostheader -apidname SSP -apidtype configurableid -apidlogin contoso\sspapid -apidpwd P@ssw0rd

After you have created a Web application to host the Shared Services Administration Web site, you have to create a Shared Services Provider to manage Search, as shown in the following example:

stsadm.exe" -o createssp -title "Contoso Search" -url http://ssp.contoso.msft -ssplogin contoso\sspservice -indexserver app2 -indexlocation c:\indexes -ssppassword P@ssw0rd -sspdatabaseserver app1 -sspdatabasename Contoso_SSP_Config -searchdatabaseserver app1 -searchdatabasename Contoso_SSP_Search -ssl no

The final bit of code that is required is used to create the Search Provider Web application. This should be its own Web application to host the Search Center. The following example creates a Web application that has the URL http://search.contoso.msft.

stsadm.exe -o extendvs -url http://search.contoso.msft -ownerlogin "contoso\administrator" -owneremail "administrator@contoso.msft" -exclusivelyusentlm -ownername "Administrator" -databaseserver app1 -databasename Contoso_WSS_Content_Search_Center -sitetemplate srchcenterlite#1 -description "Contoso Search Center" -sethostheader -apidname PortalAppPool -apidtype configurableid -apidlogin contoso\portalapid -apidpwd P@ssw0rd

Some explanation is warranted on the previous command. First, we are using the extendvs parameter to created a new Web application (used to be virtual server, hence the vs in the command name). Next, we define the owner, contoso/administrator in our example. If you are using Kerberos authentication, refer to the stsadm.exe reference for more information about verbiage. We must also define the instance of SQL Server and database name. We used app1 as the name of the instance of SQL Server and Contoso_WSS_Content_Search_Center as the database name.

We must create a site collection in the root managed path. In our example, the URL would be http://search.contoso.msft/, with '/' hosting the Search Center. The correct site collection template is srchcenterlite#1. Finally, we configure an application pool named PortalAppPool and an identity using contoso/portalapid. The portal application pool identity should have already been created in the Active Directory directory service.

When you have finished adding all the necessary commands, save this file as farm-build.cmd.

The following code illustrates a complete farm-build.cmd script.

CopyCode image Copy Code
:: @Echo off
:: leaving echo ON for demonstration purposes
:: Farm_Build.cmd
:: Provisions configuration database and Central Administration
:: Creates http://ssp.contoso.msft, then creates SSP Admin in that Web app
:: Installer account requires DB Creator and Security Administrator on SQL Server
:: Pauses are for command verification and demonstration. you can remove if you want.
:: App1 is SQL Server
:: App2 is Search Server

:: Calling bits.cmd to install binaries
@call bits.cmd
Echo Ready to connect server to farm
pause
::Create Index Location on Index Server
@Echo Creating Index Location
mkdir \\app2\c$\indexes
@Echo Creating Farm
:: Creating Farm via populating the ConfigDB. Set SQL Servername, configDB name, Central Admin ContentDB, and Farm Account.
"c:\program files\common files\microsoft shared\web server extensions\12\bin\psconfig.exe" -cmd configdb -create -server app1 -database ContosoSearch_SharePoint_ConfigDB -user contoso\mossfarm -password P@ssw0rd -admincontentdatabase Central_Admin_Content
@Echo Provision Central Admin
::  Provision Central Admin Application on this server. Uses configDB and ContentDB above. Set port number to suit your requirements.
"c:\program files\common files\microsoft shared\web server extensions\12\bin\psconfig.exe" -cmd adminvs -provision -port 12345 -windowsauthprovider onlyusentlm
@Echo Install all Services
::  Install all services on the server
"c:\program files\common files\microsoft shared\web server extensions\12\bin\psconfig.exe" -cmd services install
@Echo Securing File System and Registry Keys
:: Set Security on File System and Registry Keys
"c:\program files\common files\microsoft shared\web server extensions\12\bin\psconfig.exe" -cmd secureresources
@Echo Starting MOSS Search
::  Start SharePoint Server Search Service with IndexQuery.Verify database and services names. Change role to Index if you are scaling out Search Server in the farm.Subsequent servers would only be Query.
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o osearch -action start -role IndexQuery -farmcontactemail administrator@contoso.msft -farmperformancelevel maximum -farmserviceaccount "contoso\mossservice" -farmservicepassword P@ssw0rd
@Echo Starting WSS Search
::  Start WSS Search. Verify database and service names.
"c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm.exe" -o spsearch -action start -farmserviceaccount contoso\mossservice -farmservicepassword P@ssw0rd -farmcontentaccessaccount contoso\mosscrawler -farmcontentaccesspassword P@ssw0rd -databaseserver app1 -databasename Contoso_WSS_App2_Search
@Echo Installing all Features
::  Install all features on machine
"c:\program files\common files\microsoft shared\web server extensions\12\bin\psconfig.exe" -cmd installfeatures
@Echo Creating SSP Web
::  Create SSP Web application. Verify database and apid names. (APID = Application Pool Identity)
"c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm.exe" -o extendvs -url http://ssp.contoso.msft -exclusivelyusentlm -databaseserver app1 -databasename Contoso_WSS_Content_SSP -donotcreatesite -description "SSP Admin Host" -sethostheader -apidname SSP -apidtype configurableid -apidlogin contoso\sspapid -apidpwd P@ssw0rd
::  We must reset IIS before building the SSP. If you are local on the box, you can check all services are created before creating SSP.
iisreset
@Echo Creating SSP
::  Create Search SSP. Verify all names and URLs.
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o createssp -title "Contoso Search" -url http://ssp.contoso.msft -ssplogin contoso\sspservice -indexserver app2 -indexlocation c:\indexes -ssppassword P@ssw0rd -sspdatabaseserver app1 -sspdatabasename Contoso_SSP_Config -searchdatabaseserver app1 -searchdatabasename Contoso_SSP_Search -ssl no
@Echo Creating Search Center
::  Creating Search Center. Change the URL if you will have a different URL than 'search'.
"c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm.exe" -o extendvs -url http://search.contoso.msft -ownerlogin "contoso\administrator" -owneremail "administrator@contoso.msft" -exclusivelyusentlm -ownername "Administrator" -databaseserver app1 -databasename Contoso_WSS_Content_Search_Center -sitetemplate srchcenterlite#1 -description "Contoso Search Center" -sethostheader -apidname PortalAppPool -apidtype configurableid -apidlogin contoso\portalapid -apidpwd P@ssw0rd
:: If you receive an error during build, check that you have correctly modified the server :: names, database names, domain name, account names, and passwords for your specific
:: implementation.

Create the farm-connect.cmd script

After you have finished configuring the first server in the farm, you have to connect from every other server that you add to the farm. This script, farm-connect.cmd, is executed on servers other than the first server in the farm. The following series of commands are used to build this script.

Connect to an existing farm by specifying the instance of SQL Server and configuration database, as shown in the following example:

psconfig.exe -cmd configdb -connect -server app1 -database ContosoSearch_SharePoint_ConfigDB -user contoso\mossfarm -password P@ssw0rd

Now you have to install services, features, secure resources, and start services as you did before. The following example starts all services, features, and starts/configures the query role.

Note Note:

You must first start the search service on subsequent servers and then define the Search parameters.

psconfig.exe -cmd services install psconfig.exe -cmd installfeatures psconfig.exe -cmd secureresources

stsadm.exe -o osearch -action start -role query -farmcontactemail administrator@contoso.msft -farmperformancelevel maximum -farmserviceaccount "contoso\mossservice" -farmservicepassword P@ssw0rd

stsadm.exe-o osearch -action start -role query -farmcontactemail administrator@contoso.msft -farmperformancelevel maximum -farmserviceaccount "contoso\mossservice" -farmservicepassword P@ssw0rd -propagationlocation c:\indexes

Important Important:

If you will have more than one query server in the farm, you must verify that the index server does not also host the query role.

The following code illustrates a complete farm-connect.cmd script.

CopyCode image Copy Code
:: Farm_Connect.cmd
:: Use on all WFE (query) Servers in Farm
:: Verify query role is not turned on for Index Server
:: @Echo On (off for demo)
:: Calling bits.cmd to install binaries
@call bits.cmd
Echo Ready to connect server to farm
pause
"c:\program files\common files\microsoft shared\web server extensions\12\bin\psconfig.exe" -cmd configdb -connect -server app1 -database ContosoSearch_SharePoint_ConfigDB -user contoso\mossfarm -password P@ssw0rd
"c:\program files\common files\microsoft shared\web server extensions\12\bin\psconfig.exe" -cmd services install
"c:\program files\common files\microsoft shared\web server extensions\12\bin\psconfig.exe" -cmd installfeatures
:: Setting Security on Registry and File System
@Echo Ready to Set Security on File System and Registry
"c:\program files\common files\microsoft shared\web server extensions\12\bin\psconfig.exe" -cmd secureresources
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o osearch -action start -role query -farmcontactemail administrator@contoso.msft -farmperformancelevel maximum -farmserviceaccount "contoso\mossservice" -farmservicepassword P@ssw0rd
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o osearch -action start -role query -farmcontactemail administrator@contoso.msft -farmperformancelevel maximum -farmserviceaccount "contoso\mossservice" -farmservicepassword P@ssw0rd -propagationlocation c:\indexes
iisreset / noforce

Conclusion

Always test and debug farm installation scripts against a test server farm before you use them in a production environment. Scripts rarely work correctly the first time. It is an iterative process.

Fully tested and functional scripts are especially important if their intended use is for disaster recovery. You only get one try. Don't depend on guesses as to where the script went wrong. As always, use these examples at your own risk. Test, test, and then test some more!


Add query servers to expand a farm (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

This article applies to Microsoft Search Server 2008 only. It does not apply to Microsoft Search Server 2008 Express.

This article explains how to add query servers to a Search Server 2008 deployment. To add a query server, you must complete the following tasks:

  • Task 1: Add an application server to the farm

  • Task 2: Configure application server roles

The following sections explain how to complete these tasks. You can repeat Tasks 1 and 2 at any time to add more query servers as appropriate for your organization.

Important Important:

Before you can add a query server, you must install and configure Search Server 2008 on the first computer in the deployment by following the instructions under "Run an Advanced installation" in Install Search Server 2008 or Search Server 2008 Express. After you complete that procedure, you can add query servers or Web front-end (WFE) servers to the deployment at any time. For information about Search Server 2008 planning, server roles, and topology options, see Plan to deploy Search Server 2008 or Search Server 2008 Express.

Task 1: Add an application server to the farm

This section explains how to add an application server after you install Search Server 2008 on the first computer in a deployment. Follow these steps when you install the product on another computer:

  • Step 1: Prepare hardware and software

  • Step 2: Start the installation

  • Step 3: Run the Search Server Preparation Tool

  • Step 4: Complete the installation

You can repeat these steps to add more application servers to the farm.

Note Note:

This article explains all of the steps that you must take to complete Task 1. This includes many of the same actions that are described in Install Search Server 2008 or Search Server 2008 Express. However, there are a few important differences, especially in Step 4: Complete the installation. Follow the procedures here carefully to complete Task 1 correctly.

Step 1: Prepare hardware and software

Before you begin a new installation, ensure that the computer that you want to add to the existing deployment meets the minimum requirements described in Determine hardware and software requirements (Search Server 2008).

Step 2: Start the installation

Use this procedure to begin the setup process on the computer that you want to add to the existing deployment. Ensure that you are logged on with an account that has local administrator permissions.

To start the installation

  • To install Search Server 2008 from a product disc, insert the disc in the CD-ROM drive. The product installation Start screen appears.

    Note Note:

    If the installation Start screen does not appear automatically after a short time, navigate to the root folder of the product disc and double-click the file Splash.hta.

  • To install Search Server 2008 from a local disk or file share, navigate to the product location and double-click the file Splash.hta. The product installation Start screen appears.

Step 3: Run the Search Server Preparation Tool

The Search Server Preparation Tool checks your computer for required components and updates. The tool performs each of the following tasks, if necessary:

  • For Windows Server 2003 operating systems:

    • Downloads and installs Service Pack 1 if no service pack is installed.

    • Downloads and installs Microsoft .NET Framework 3.0 if .NET Framework 2.0 and Windows Workflow Foundation Runtime Components are not installed.

  • Activates the IIS Application Server role and enables ASP.NET Web Server extensions.

To run the Search Server Preparation Tool

  1. On the installation Start screen, under Install, click Run the Search Server Preparation Tool. The Welcome to the Microsoft Search Server 2008 Preparation Tool screen appears.

  2. As the Search Server Preparation Tool runs, follow the instructions to complete the procedure. The time required to complete the procedure varies depending on the number of components that the tool must install and the speed of your network connection.

  3. On the Installation Complete screen, click Finish.

Step 4: Complete the installation

Use this procedure to complete the installation process.

To complete the installation

  1. On the installation Start screen, click Install Search Server.

  2. On the Enter your Product Key screen, enter your Product Key. After the installation program validates the Product Key, it places a green check mark next to the Product Key box.

  3. Click Continue after the installation program verifies your Product Key.

  4. On the Read the Microsoft Software License Terms screen, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  5. On the Choose the installation you want screen, click Advanced. The Server Type screen appears.

  6. On the Server Type screen:

    • In the Server Type tab, click Complete. This option installs the application server role and WFE server role. Installing the application server role enables you to configure this computer as a query server after the installation is complete.

    • Optional: In the File Location tab, change the installation path or the storage location for content index files.

    • Optional: In the Feedback tab, specify whether you want to participate in the Customer Experience Improvement Program.

  7. Click Install Now. The Installation Progress screen appears. The process takes several minutes to complete.

  8. On the nextscreen, which prompts you to complete the configuration:

    1. Ensure that the Run the SharePoint Products and Technologies Configuration Wizard now check box is selected.

    2. Click Close to start the Configuration Wizard.

  9. In the Welcome to SharePoint Products and Technologies screen, click Next.

  10. In the dialog box that notifies you that some services might be restarted or reset during configuration, click Yes.

  11. On the Connect to Server Farm screen, click Yes, I want to connect to an existing server farm, and then click Next.

    Note Note:

    This differs from the option that you select on the Connect to Server Farm screen in the procedure "Run an Advanced installation" in Install Search Server 2008 or Search Server 2008 Express.

  12. In each of the fields on the Specify Configuration Database Settings screen, specify the same values that you specified for the first server in the farm.

    Note Note:

    To join the new server to the existing farm, you must specify the same values here that you specified for the first server.

    • Database Server - Name of the SQL Server host that you specified when you installed Search Server 2008 on the first computer in this farm.

    • Database Name - Name of the database that you specified when you installed Search Server 2008 on the first computer in this farm. You can click Retrieve Database Names to view a list of the databases that are on the SQL Server host.

    • Database Access Account - The database access account that you specified when you installed Search Server 2008 on the first computer in this farm.

  13. Click Next. On the Completing the SharePoint Products and Technologies Configuration Wizard screen:

    1. Confirm your settings, ensuring that you entered the correct configuration database server name and configuration database name.

    2. If you want to use this computer to host the Central Administration Web site, click Advanced Settings. On the Advanced Settings screen, click Use this machine to host the web site, and then click OK.

      Note Note:

      When you install Search Server 2008 on the first computer in a farm, that computer automatically hosts the Central Administration Web site. It is not necessary to host this Web site on more than one computer in the farm.

  14. Click Next. The Configuration Wizard runs for several minutes to automate configuration tasks such as installing Search Server 2008 services and updating the farm configuration database with information for this new server.

  15. On the Configuration Successful page, click Finish.

    Note Note:

    If you are prompted for a user name and password, type the credentials for an account that has access to the Central Administration Web site. Add the site to the list of trusted sites in Windows Internet Explorer when you are prompted.

This completes the process of joining a new application server to a Search Server 2008 farm.

Important Important:

After you complete Task 1, you must complete Task 2 to configure the index server and query server roles on each application server in the farm. This procedure is explained in the following section.

Task 2: Configure application server roles

You must now configure the application servers in your farm by doing the following:

  • Step 1: Configure the index server

  • Step 2: Configure query servers

Important Important:

Task 2 applies only to a farm that has more than one application server.

Step 1: Configure the index server

The instructions under "Run an Advanced installation" in Install Search Server 2008 or Search Server 2008 Express explain how to deploy the first computer in a farm so that it is configured with the application server role and the WFE server role. As the sole application server for the deployment, that computer is automatically configured as the index server and query server. When you add an application server to a farm, we recommend that you continue to use the first server in the deployment as the index server. To do so, you must enable the index server role and disable the query server role on that first farm server as explained in the following procedure. Typically you need to perform this procedure only once for any farm that has multiple application servers.

To configure the index server

  1. From the Central Administration Web site, click Operations.

  2. On the Operations page, under Topology and Services, click Services on server.

  3. On the Services on Server page, under Complete all steps below, click the first computer that you deployed for this farm. If the first computer that you deployed for the farm does not appear:

    1. Click the server name that currently appears.

    2. Click Change Server.

    3. In the Select Server dialog box, click the first computer that you deployed for this farm.

  4. On the Services on Server page, in the Service column, find the service named Office SharePoint Server Search.

  5. In the Status column for the Office SharePoint Server Search service, ensure that the status is Started.

  6. In the Service column, click Office SharePoint Server Search.

  7. On the Configure Office SharePoint Server Search Service Settings page, in the Query and Indexing section:

    1. Ensure that the Use this server for indexing content check box is selected.

    2. Clear the Use this server for serving search queries check box.

  8. Click OK.

Configuration of the index server is now complete.

Important Important:

You must now configure your other application servers as query servers, as explained in the following section.

Step 2: Configure query servers

Use this procedure to configure each of your other application servers as query servers. On each of these servers, you enable the query server role and ensure that the index server role is disabled.

To configure a query server

  1. From the Central Administration Web site, click Operations.

  2. On the Operations page, under Topology and Services, click Services on server.

  3. On the Services on Server page, under Complete all steps below, click an application server that you want to configure as a query server. If the computer that you want to configure as a query server does not appear:

    1. Click the server name that currently appears.

    2. Click Change Server.

    3. In the Select Server dialog box, click the computer that you want to configure as a query server.

  4. In the Status column for the Office SharePoint Server Search service, if the status is Stopped, in the Action column, click Start. The Configure Office SharePoint Server Search Service Settings page opens.

  5. On the Configure Office SharePoint Server Search Service Settings page, in the Query and Indexing section:

    1. Clear the Use this server for indexing content check box.

    2. Select the Use this server for serving search queries check box.

  6. Click Start. The configuration of the application server as a query server is now complete.

See Also

Concepts

Plan to deploy Search Server 2008 or Search Server 2008 Express
Install Search Server 2008 or Search Server 2008 Express


Presentation: Understanding and deploying hotfixes, public updates, and service packs (Search Server 2008)
DropDown image

Updated: 2008-08-21

This presentation, given by Daniel Winter at the SharePoint Products and Technologies conference in March 2008, provides valuable information about the different types of software updates that Microsoft releases for Windows SharePoint Services. Because Microsoft Search Server 2008 is built on Windows SharePoint Services, all of the concepts in this presentation apply to Search Server 2008.

Using Service Pack 1 for Windows SharePoint Services 3.0 as an example, Daniel provides detailed information about pre-upgrade steps, deploying the upgrade, validating the upgrade, and troubleshooting the upgrade.

Download the video (AG313.wmv) of this presentation and save it on your computer.

After you download the file, double-click the file name or right-click and select Play to view the video.

Presentation: Understanding and deploying hotfixes, public updates, and service packs (http://go.microsoft.com/fwlink/?LinkId=121946&clcid=0x409)


Install the Infrastructure Update for Microsoft Office Servers (Search Server 2008)
DropDown image

Updated: 2008-08-21

The Infrastructure Update for Microsoft Office Servers provides quality and performance enhancements when installed on a server that is running Microsoft Search Server 2008 or Microsoft Search Server 2008 Express. For more information about the update, see the Microsoft Knowledge Base Article Description of the Infrastructure Update for Microsoft Office Servers (KB951297) (http://go.microsoft.com/fwlink/?LinkID=121886).

This article assumes that either Microsoft Search Server 2008 or Microsoft Search Server 2008 Express is installed on the computers that you are updating. We recommend that you also install the Infrastructure Update for Windows SharePoint Services 3.0 on all servers in the server farm before you install the Infrastructure Update for Microsoft Office Servers.

Important Important:

If you are upgrading an x86 installation of Search Server 2008 or Search Server 2008 Express, you must ensure that you use only x86 components when upgrading. These components include the operating system, Search Server 2008 or Search Server 2008 Express, and the Infrastructure Update for Microsoft Office Servers. Likewise, if you are upgrading an x64 installation, you must ensure that you use all x64 components.

High level steps

The following list shows the high-level steps for installing the Infrastructure Update for Microsoft Office Servers.

  1. Step 1: View the presentation Presentation: Understanding and deploying hotfixes, public updates, and service packs (Search Server 2008).

  2. Follow the preliminary steps described in the Before you begin section.

  3. Step 3: (Optional) Download and install the Infrastructure Update for Windows SharePoint Services 3.0. For more information, see To install the Infrastructure Update for Windows SharePoint Services 3.0.

  4. Step 4: Download and install the Infrastructure Update for Microsoft Office Servers.

  5. Step 5: (Optional) Download and install Language Packs. For more information, see Deploy language packs (Search Server 2008)

Before you begin

This section provides an overview of recommendations to consider before you install a software update.

  • Schedule the upgrade for a time that causes the least amount of disruption for your users.

    You do not need to stop services, timer jobs, or crawls during the upgrade. The Setup Wizard stops or pauses and then resumes them as needed. The setup wizard restarts the following services during upgrade: Internet Information Services, SharePoint Administration Service, and SharePoint Timer Services.

    Note Note:

    You do not have to stop the World Wide Web Publishing service on the Web front-end servers. However, access to the sites will be temporarily affected during the upgrade when the setup Wizard restarts services during the upgrade.

  • Communicate the proposed schedule to users and the key people involved with the Web sites hosted on the servers that are running Search Server 2008 and, if necessary, adjust the schedule.

Back up the server farm before you start the software update installation. You should create a backup of search and all databases. We recommend that you follow these guidelines:

  • Search: Use the full backup operation from SharePoint Central Administration or the stsadm command-line tool to back up the Shared Services Provider (SSP) that is associated with the index server. The backup operation includes both the SSP database and content index in the file system.

    Important Important:

    Before you back up, verify that the drive that you are backing up to has enough free space to back up the entire farm. Although you are only backing up the SSP, the backup operation will fail if you do not have free space for the entire farm.

  • Configuration database and Central Administration content database: You must back up your databases by using SQL Server tools after you have stopped your farm. Use the simple recovery model so that your transaction log is truncated. For more information, see Move all databases (Search Server 2008).

  • Content databases: Perform a full backup operation with either the stsadm command-line tool or SQL Server to back up all content databases. If you are using SQL Server, use the simple recovery model, so that your transaction log is truncated.

  • Front-end Web server: If you have customized the front-end Web server or are unsure of the extent of the customizations to your Web applications, we recommend that you make a backup image of your front-end Web server. Make sure that you have a backup of any solution packages that you have deployed on your front-end Web servers.

    Note Note:

    Ideally, if you are customizing front-end Web computers, the customization should be managed by using a robust build process or script that allows the customizations to be applied to a new computer.

  • If you experience an unrecoverable failure during upgrade, you may have to restore your server from the backup image that you created. You would need to manually apply all customizations to your front-end Web server.

    Note Note:

    We recommend that you back up the server farm after you have verified that the software update installation succeeded.

Caution Caution:

Back up operations that are running during the upgrade will fail. Because of this, we recommend that you wait for all backups to complete before you upgrade.

For more information about backing up and restoring your server farm, see Protecting and restoring the farm (Search Server 2008). For more general information about preparation steps to installing a software update, see Deploy software updates.

Installing the Infrastructure Update for Windows SharePoint Services 3.0

We recommend that you install the Infrastructure Update for Windows SharePoint Services 3.0 on all servers in the server farm because it provides updates that are not included in the Infrastructure Update for Microsoft Office Servers. For example, key updates for the Infrastructure Update for Windows SharePoint Services 3.0 include:

  • Platform performance improvements and fixes.

  • Several backup and restore fixes.

  • Several core Workflow fixes.

If you install the Infrastructure Update for Windows SharePoint Services 3.0, you must do so before you install the Infrastructure Update for Microsoft Office Servers.

You can either download the Infrastructure Update for Windows SharePoint Services 3.0 to each computer that you are updating or download it to a file share. If you use a file share as an installation source, you must ensure that a minimum of Read permissions have been granted to each server administrator that will be accessing that share.

To install the Infrastructure Update for Windows SharePoint Services 3.0

This section includes all required procedures to install the Infrastructure Update for Windows SharePoint Services 3.0 in any size server farm. If you are installing on a multiple computer server farm, install the update on each server in the server farm running Search Server 2008 or Search Server 2008 Express.

Install the Infrastructure Update for Windows SharePoint Services 3.0

  1. Download the Infrastructure Update for Windows SharePoint Services 3.0.

    You can download the 32-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121881).

    You can download the 64-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121883).

  2. Disconnect users from the server farm by stopping the World Wide Web Publishing service (W3SVC) on all Web servers.

    Note Note:

    This manual step is done as a precaution to ensure that the service is fully stopped.

  3. On the first server, in Windows Explorer, double-click the .exe that you downloaded.

    By default, the file name for the x86 version is infrastructureupdateforwindowssharepointservices3.0-kb951695-fullfile-x86.exe and the file name for an x64 system is infrastructureupdateforwindowssharepointservices3.0-kb951695-fullfile-x64.exe.

    Important Important:

    Perform these steps on the index server first, then the query servers, and finally the front-end Web servers.

  4. If the Security Warning dialog box appears, click Run to continue.

  5. On the Microsoft Software License Terms page, select the Click here to accept the Microsoft Software License Terms check-box and then click Continue.

    At the end of the software update installation, the SharePoint Products and Technologies Configuration Wizard starts.

    Note Note:

    If the wizard does not start automatically, click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.

  6. On the Welcome to SharePoint Products and Technologies page, click Next.

  7. In the dialog box that notifies you that some services might need to be restarted during configuration, click Yes.

    Important Important:

    User access to your server farm will be temporarily disrupted while the Internet Information Services, SharePoint Administration Service, and SharePoint Timer Service are restarted. Typically restarting these services takes only a few moments to complete.

  8. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

  9. When the dialog box about installation in a server farm appears, do not click OK. Instead, leave each server with the following dialog box displayed:

    You must run Setup to install new binary files for every server in your server farm. If you have multiple servers in your server farm, run Setup and the configuration wizard on the other servers now, and then return to this server and click OK to continue.

  10. When the dialog box from the previous step is displayed on all servers in the server farm, use one server that hosts the Central Administration Web site to finalize the installation.

  11. On the server you selected in the previous step, click OK.

  12. On the Configuration Successful page, click Finish.

  13. After you have finished updating one Web server that hosts the Central Administration Web site, you should follow the procedures in the "Verify installation" section on this one Web server to ensure that the software update installation was successful.

  14. Continue updating the remaining computers in the server farm, one at a time, by clicking OK in the dialog box.

    Note Note:

    It is important that the SharePoint Products and Technologies Configuration Wizard perform the configuration procedures on only one computer at a time.

Verification step

To verify that the Infrastructure Update for Windows SharePoint Services 3.0 is installed, see the "How to determine whether this update is installed" section of Microsoft Knowledge Base Article Description of the Infrastructure Update for Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=125366).

Installing the Infrastructure Update for Microsoft Office Servers

Use this procedure to install the Infrastructure Update for Microsoft Office Servers on Search Server 2008 or Search Server 2008 Express on a single server or a server farm. You must install the Infrastructure Update for Microsoft Office Servers on each server in the server farm.

You can either download the Infrastructure Update for Microsoft Office Servers to each computer that you are updating or download it to a file share. If you use a file share as an installation source, you must ensure that a minimum of Read permissions have been granted to each server administrator that will be accessing that share.

To install the Infrastructure Update for Microsoft Office Servers

You must install the Infrastructure Update for Microsoft Office Servers on each server in the server farm.

Install the Infrastructure Update for Microsoft Office Servers

  1. Download the Infrastructure Update for Microsoft Office Servers.

    You can download the 32-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121879).

    You can download the 64-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121880).

  2. Ensure that the World Wide Web Publishing service (W3SVC) is stopped on all Web servers.

    Note Note:

    This manual step is done as a precaution to ensure that the service is fully stopped so that users cannot access the server farm during the update.

  3. On the first server, in Windows Explorer, double-click the .exe that you downloaded.

    By default, the file name for the x86 version is infrastructureupdateformicrosoftofficeservers-kb951297-fullfile-x86.exe and the file name for an x64 system is infrastructureupdateformicrosoftofficeservers-kb951297-fullfile-x64.exe.

    Important Important:

    Perform these steps on the index server first, then the query servers, and finally the front-end Web servers.

  4. If the Security Warning dialog box appears, click Run to continue.

  5. On the Microsoft Software License Terms page, select the Click here to accept the Microsoft Software License Terms check-box and then click Continue.

    The SharePoint Products and Technologies Configuration Wizard starts at the end of the software update installation.

    Note Note:

    If the wizard does not start automatically, click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.

  6. On the Welcome to SharePoint Products and Technologies page, click Next.

  7. In the dialog box that notifies you that some services might need to be restarted during configuration, click Yes.

    Important Important:

    User access to your server farm will be temporarily disrupted while the Internet Information Services, SharePoint Administration Service, and SharePoint Timer Service are restarted. Typically restarting these services takes only a few moments to complete.

  8. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

  9. When the dialog box about installation in a server farm appears, do not click OK. Instead, leave each server with the following dialog box displayed:

    You must run Setup to install new binary files for every server in your server farm. If you have multiple servers in your server farm, run Setup and the configuration wizard on the other servers now, and then return to this server and click OK to continue.

  10. When the dialog box from the previous step is displayed on all servers in the server farm, use one server that hosts the Central Administration Web site to finalize the installation.

  11. On the server you selected in the previous step, click OK.

  12. On the Configuration Successful page, click Finish.

  13. After you have finished updating one Web server that hosts the Central Administration Web site, you should follow the procedures in the "Verify installation" section on this one Web server to ensure that the software update installation was successful.

  14. Continue updating the remaining computers in the server farm, one at a time, by clicking OK in the dialog box.

    Note Note:

    It is important that the SharePoint Products and Technologies Configuration Wizard perform the configuration procedures on only one computer at a time.

  15. When the software update installation and configuration is complete on all the servers in the server farm, make the Web servers available to users by manually starting the World Wide Web Publishing service on each server on which you manually stopped the service.

Verification step

To verify that the Infrastructure Update for Microsoft Office Servers is installed, see the "How to determine whether this update is installed" section of Microsoft Knowledge Base Article Description of the Infrastructure Update for Microsoft Office Servers (KB951297) (http://go.microsoft.com/fwlink/?LinkID=121886).


Deploy language packs (Search Server 2008)
DropDown image

Updated: 2009-07-23

Note Note:

In this article, the term Search Server refers to Microsoft Search Server 2008 or Microsoft Search Server 2008 Express. The information in this article applies to both products.

Language packs enable site owners and site collection administrators to create sites and site collections in multiple languages without requiring separate installations of Search Server. You install language packs, which contain site templates for specific languages, on front-end Web servers. When an administrator creates a site or a site collection that is based on a site template for a specific language, the text on the site or the site collection appears in the site template's language. Language packs are typically used in multinational deployments where a single server farm supports users in different locations, or in situations where sites and Web pages must be replicated in one or more languages. For more information about language packs, see Plan for multilingual sites.

In this article:

  • About language IDs and language packs

  • Downloading language packs

  • Preparing front-end Web servers for language packs

  • Installing language packs on front-end Web servers

  • Uninstalling language packs

About language IDs and language packs

When site owners or site collection administrators create sites or site collections, they can choose a language for each site or site collection.

The language they choose represents the language identifier (ID). The language ID determines the language that is used to display and interpret text on the site or site collection. For example, when a site administrator creates a site in French, the site's toolbars, navigation bars, lists, and column headings appear in French. Likewise, if a site administrator creates a site in Arabic, the site's toolbars, navigation bars, lists, and column headings appear in Arabic. In addition, the default left-to-right orientation of the site changes to a right-to-left orientation to correctly display Arabic text.

The list of languages that a site administrator can use to create a site or site collection is generated by the language packs that are installed on the front-end Web servers. By default, sites and site collections are created in the language in which Search Server was installed. For example, if you install the Spanish version of Search Server, the default language for sites, site collections, and Web pages is Spanish. If a site administrator has to create sites, site collections or Web pages in a language other than the default language, you must install the language pack for that language on the front-end Web servers. For example, if you are running the French version of Search Server and a site administrator wants to create sites in French, English, and Spanish, you must install the English and Spanish language packs on the front-end Web servers.

Note Note:

By default, when a site administrator creates a new Web page within a site, the site displays text in the language that is specified by the language ID.

Language packs are not bundled into multilingual installation packages. You must install a specific language pack for each language that you want to support. Also, language packs must be installed on each front-end Web server.

Important Important:

You must install language packs on the front-end Web server before you create any site collections. If you create site collections and then install language packs, any subsites that you create will not be available.

You cannot change an existing site, site collection, or Web page from one language to another by applying different language-specific site templates. After you choose a language-specific site template for a site or a site collection, the site or site collection always displays content in the language of the original site template.

The following table lists the language packs that are available:

Language | Language ID
Arabic | 1025
Bulgarian | 1026
Catalan | 1027
Chinese (Simplified) | 2052
Chinese (Traditional) | 1028
Croatian | 1050
Czech | 1029
Danish | 1030
Dutch | 1043
English | 1037
Estonian | 1061
Finnish | 1035
French | 1036
German | 1031
Greek | 1032
Hebrew | 1037
Hindi | 1081
Hungarian | 1038
Italian | 1040
Japanese | 1041
Kazakh | 1087
Korean | 1042
Latvian | 1062
Lithuanian | 1063
Norwegian | 1044
Polish | 1045
Portuguese (Brazil) | 1046
Portuguese (Portugal) | 2070
Romanian | 1048
Russian | 1049
Serbian (Latin) | 2074
Slovak | 1051
Slovenian | 1060
Spanish | 3082
Swedish | 1053
Thai | 1054
Turkish | 1055
Ukrainian | 1058

Although a site administrator specifies a language ID for a site, some user interface elements such as error messages, notifications, and dialog boxes do not display in the language that was specified. This is because Search Server relies on several supporting technologies — for example, the Microsoft .NET Framework, Microsoft Windows Workflow Foundation, Microsoft ASP.NET, and Microsoft SQL Server 2005 — some of which are localized into only a limited number of languages. If a user interface element is generated by any of the supporting technologies that is not localized into the language that the site administrator specified for the site, the user interface element appears in English. For example, if a site administrator creates a site in Hebrew, and the .NET Framework component displays a notification message, the notification message will not display in Hebrew because the .NET Framework is not localized into Hebrew. This situation can occur when sites are created in any language except the following: Chinese, French, German, Italian, Japanese, Korean, and Spanish.

In some cases, some text might originate from the original installation language, which can create a mixed-language experience. This type of mixed-language experience is typically seen only by content creators or site administrators and is not seen by site users.

Downloading language packs

You must perform the following steps for each language that you want to support.

Important Important:

When you download language packs for more than one language, a unique file is downloaded for each language. However, each unique file has the same name. Therefore, ensure that you download each language pack to a separate folder on your hard disk so that you do not overwrite a language pack of a different language.

Note Note:

For any language that you want to support, you must download and install the Windows SharePoint Services 3.0 language pack and the Search Server language pack.

Download the language pack

  1. Download the 32-bit or 64-bit version of the language pack by using one of the download links that follow.

  2. On the download page, select the language that you want from the Change Language list, and then click Change.

  3. Click Download on the Web page.

  4. In the dialog box that appears, click Save to download a copy of the file to your local computer.

Download links

Use the following links to download the language packs that are appropriate for the platform and service pack version:

32-bit

For the 32 bit version of Search Server, download the following language packs:

Windows SharePoint Services 3.0 Language Pack (http://go.microsoft.com/fwlink/?LinkID=91343)

Search Server 2008 (x86) Language Pack (http://go.microsoft.com/fwlink/?LinkId=154971)

64-bit

For the 64-bit version of Search Server, download the following language packs:

Windows SharePoint Services 3.0 Language Pack x64 (http://go.microsoft.com/fwlink/?LinkID=82241)

Search Server 2008 (x64) Language Pack (http://go.microsoft.com/fwlink/?LinkId=154972)

32-bit, SP2

For the 32-bit version of Search Server with the 2007 Microsoft Office Servers Service Pack 2 (SP2), download the following language packs:

Windows SharePoint Services 3.0 Language Pack (http://go.microsoft.com/fwlink/?LinkID=91343)

Search Server 2008 (x86) Language Pack (http://go.microsoft.com/fwlink/?LinkId=154971)

Windows SharePoint Services Language Template Pack Service Pack 2 (SP2) (http://go.microsoft.com/fwlink/?LinkID=154963)

Microsoft Office Language Pack 2007 Service Pack 2 (SP2) (http://go.microsoft.com/fwlink/?LinkId=154966)

64-bit, SP2

For the 64-bit version of Search Server with the 2007 Microsoft Office Servers Service Pack 2 (SP2), download the following language packs:

Windows SharePoint Services 3.0 Language Pack x64 (http://go.microsoft.com/fwlink/?LinkID=82241)

Search Server 2008 (x64) Language Pack (http://go.microsoft.com/fwlink/?LinkId=154972)

Windows SharePoint Services 3.0 Language Pack Service Pack 2 (SP2), 64-Bit Edition (http://go.microsoft.com/fwlink/?LinkID=149245)

The 2007 Microsoft Office Servers Language Pack Service Pack 2 (SP2), 64-Bit Edition (http://go.microsoft.com/fwlink/?LinkID=149246)

Note Note:

If you are uninstalling Search Server 2008, you must uninstall all language packs before you uninstall Search Server 2008.

Preparing front-end Web servers for language packs

Before you install language packs on front-end Web servers, you must do the following:

  1. Install the necessary language files on each front-end Web server.

  2. Install Search Server on each front-end Web server.

  3. Run the SharePoint Products and Technologies Configuration Wizard on each front-end Web server.

Language files are used by the operating system and provide support for displaying and entering text in multiple languages. Language files include the following:

  • Keyboard files

  • Input Method Editors (IMEs)

  • TrueType font files

  • Bitmap font files

  • Code page conversion tables

  • National Language Support (.nls) files

  • Script engines for rendering complex scripts

Most language files are installed by default on the Microsoft Windows Server 2003 operating system. However, you must install supplemental language files for East Asian languages and languages that use complex script or require right-to-left orientations. The East Asian languages include Chinese, Japanese, and Korean; the complex script and right-to-left oriented languages include Arabic, Armenian, Georgian, Hebrew, the Indic languages, Thai, and Vietnamese. Instructions for installing these supplemental language files are provided in the following procedure.

We recommend that you install these language files only if you need them. The East Asian files require about 230 megabytes of hard disk space. The complex script and right-to-left languages do not use much disk space, but installing either set of files might reduce performance when entering text.

Note Note:

You must be a member of the Administrators group on the front-end Web server to install these language files. After the language files are installed, the languages are available to all users of the computer.

You do not need to stop services, timer jobs, or crawls during the upgrade. Setup stops or pauses and then resumes them as needed. Setup restarts the following services during installation: Internet Information Services, SharePoint Administration Service, and SharePoint Timer Services.

Note Note:

You will need your Windows Server 2003 product disc to perform this procedure, or you will need to know the location of a shared folder that contains your operating system installation files.

Note Note:

You must restart your computer after you install supplemental language files.

Install additional language files on Windows Server 2003

  1. On your front-end Web server, click Start, point to Settings and then Control Panel, and then click Regional and Language Options.

  2. In the Regional and Language Options dialog box, on the Languages tab, in the Supplemental Language Support section, select one or both of the following check boxes:

    • Install files for complex script and right-to-left languages

    • Install files for East Asian languages

  3. Click OK in the dialog box that alerts you that additional disk space is required for the files.

  4. Click OK to install the additional language files.

  5. When prompted, insert your Windows Server 2003 product disc or provide the location of your Windows Server 2003 installation files.

  6. When prompted to restart your computer, click Yes.

Install additional language files on Windows Server 2008

  1. On your front-end Web server, click Start, point to Settings and then Control Panel, and then click Regional and Language Options.

  2. In the Regional and Language Options dialog box, on the Keyboards and Languages tab, in the Display Language section, click Install/Uninstall languages.

  3. In the Install or Uninstall Languages dialog box, click Install languages.

  4. On the Select the Languages to Install page, select the language to install from the list of available languages. If the language does not appear, click Browse folder to navigate to where you downloaded the language file. The language file is a .cab file.

  5. Select all the languages that you want to install, and then click Next.

  6. Accept the terms, and then click Next.

  7. Click Install.

After you install the necessary language files on your front-end Web servers, you must install Search Server and run the SharePoint Products and Technologies Configuration Wizard. The wizard creates and configures the configuration database and performs other configuration tasks that must be done before you install language packs. For more information, see Install Search Server 2008 or Search Server 2008 Express.

Installing language packs on front-end Web servers

After you install the necessary language files on the front-end Web servers, you can install the language packs. Language packs are available as individual downloads (one or more downloads for each supported language). For each language that you want to support, you must install the corresponding language packs on each front-end Web server.

Important Important:

You must install the language packs in the correct order. For Search Server, you must install the language packs in the following order:

  1. Windows SharePoint Services 3.0 language pack

  2. Search Server language pack

For Search Server with 2007 Microsoft Office Servers Service Pack 2 (SP2), you must install the language packs in the following order:

  1. Windows SharePoint Services 3.0 language pack

  2. Windows SharePoint Services 3.0 SP2 language pack

  3. Search Server language pack

  4. Office SharePoint Server 2007 SP2 language pack

A language pack installs in its native language. For example, the Russian language pack executable file is in Russian. The procedure that follows is for the English language pack.

Install a language pack

  1. Run Setup.

  2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  3. Setup runs and installs the language pack.

After you install all of the language packs required for the language, platform, and product version that you want to support, you must rerun the SharePoint Products and Technologies Configuration Wizard according to the steps in the following procedure. (The first time you run the SharePoint Products and Technologies Configuration Wizard is when you install the product.)

Important Important:

  • Do not rerun the SharePoint Products and Technologies Configuration Wizard before you install all of the language packs that are required for a language, platform, and product version that you want to support. If you run the SharePoint Products and Technologies Configuration Wizard before all of the required language packs are installed, the language packs will not be deployed correctly.

  • If you identify another language that you want to support after you rerun the Configuration Wizard, you must install all of the language packs that are required for the language, platform, and product version and then run the SharePoint Products and Technologies Configuration Wizard again.

Rerun the SharePoint Products and Technologies Configuration Wizard

  1. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.

  2. On the Welcome to SharePoint Products and Technologies page, click Next.

  3. Click Yes in the dialog box that alerts you that some services might need to be restarted during configuration.

    Note Note:

    End-user access to sites and services will be temporarily interrupted while the services restart.

  4. On the Modify Server Farm Settings page, click Do not disconnect from this server farm, and then click Next.

  5. If the Modify SharePoint Central Administration Web Administration Settings page appears, do not modify any of the default settings, and then click Next.

  6. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

  7. On the Configuration Successful page, click Finish.

After you install a language pack, site owners and site collection administrators can create sites and site collections based on the language-specific site templates by specifying a language when they create a new SharePoint site or site collection.

Uninstalling language packs

If you no longer have to support a language for which you installed a language pack, you can remove the language pack by using Add/Remove Programs in Control Panel. Removing a language pack removes the language-specific site templates from your computer. All sites that were created with those language-specific site templates will no longer work. (The URL will produce an HTTP 500 - Internal server error page.) Reinstalling the language pack will make the site functional.

Note Note:

You cannot remove the language pack for the version of Search Server that you have installed on your server. For example, if you are running the Japanese version of Search Server, you cannot uninstall the Japanese language support for Search Server.

See Also

Concepts

Deployment for Search Server 2008


Upgrade paths (Search Server 2008)
DropDown image

Updated: 2008-03-03

This topic provides links to topics that explain how to upgrade to Microsoft Search Server 2008. This topic also provides information about specific unsupported upgrade paths to Search Server 2008 and Microsoft Search Server 2008 Express. Finally, this topic provides information about how each installation type impacts upgrade.

Supported upgrade paths

The following articles explain how you can upgrade to Search Server 2008 from either Search Server 2008 Express or Windows SharePoint Services 3.0.

  • Upgrade to Search Server 2008 from Search Server 2008 Express

  • Upgrade to Search Server 2008 from Windows SharePoint Services 3.0

The following article explains how you can upgrade to Office SharePoint Server 2007 from Search Server 2008 or Search Server 2008 Express.

  • Upgrade to Office SharePoint Server 2007 from Search Server 2008 or Search Server 2008 Express

Unsupported upgrade paths to Search Server 2008

The following table contains information about upgrade paths to Search Server 2008 or Search Server 2008 Express that are not supported.

Upgrading from this product | Is not supported for this reason
Microsoft Office SharePoint Server 2007 for Search | Prior to installing Search Server 2008 or Search Server 2008 Express, any existing deployment of Microsoft Office SharePoint Server 2007 for Search must be uninstalled.
Microsoft Search Server 2008 Express Release Candidate | Prior to installing the final release version of Search Server 2008 or Search Server 2008 Express, any pre-release version of Search Server 2008 or Search Server 2008 Express must first be uninstalled.
Windows SharePoint Services 2.0 | Before upgrading to Search Server 2008, you must first upgrade Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0. For more information, see Upgrade to Search Server 2008 from Windows SharePoint Services 3.0.

Note on installation types and databases

When upgrading to or from Search Server 2008 or Search Server 2008 Express, the installation type of the upgrade must be the same as the original installation. The possible installation types are:

  • Basic A basic installation of Search Server or Office SharePoint Server 2007 uses the Microsoft SQL Server 2005 Express Edition database.

    Note Note:

    A basic installation of Windows SharePoint Services uses the Windows Internal Database. Installing Search Server or Office SharePoint Server 2007 over Windows SharePoint Services will use SQL Server 2005 Express Edition for all Search Server and Office SharePoint Server 2007 databases. Existing Windows SharePoint Services databases will continue to use the Windows Internal Database. New SharePoint sites created after the upgrade can use either database instance.

  • Advanced An advanced installation of Search Server, Windows SharePoint Services, or Office SharePoint Server 2007 uses a Microsoft SQL Server 2005 database.

In other words, Basic installations remain basic, and Advanced installations remain advanced. You cannot switch installation types during upgrade.

See Also

Concepts

Operations for Search Server 2008


Upgrade to Search Server 2008 from Search Server 2008 Express
DropDown image

Updated: 2008-07-15

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

You can upgrade a Microsoft Search Server 2008 Express Advanced deployment to Microsoft Search Server 2008 Advanced to enable the addition of one or more separate query servers to your configuration.

Important Important:

A Basic deployment, whether Search Server 2008 Express or Search Server 2008, does not enable adding additional query servers to the farm. If you want to add query servers, but are working with an installation of Search Server 2008 Express Basic, you must uninstall Search Server 2008 and install Search Server 2008 Advanced. This article explains only how to upgrade from Search Server 2008 Express Advanced to Search Server 2008 Advanced.

A deployment of Search Server 2008 Express provides only one application server. On this server, the following two roles are enabled:

  • The index server role, which crawls content and indexes the crawled content.

  • The query server role, which serves user search queries.

Upgrading to Search Server 2008 allows multiple application servers to be joined in a farm. In a farm that has multiple application servers, the index server role is enabled on one and only one computer, and the query server role is enabled on one or more computers. Distributing the index and query server roles in this way helps balance the load and contributes to increasing system performance, capacity, and availability. For information about Basic and Advanced installation options and server roles in Search Server 2008 and Search Server 2008 Express, see Plan to deploy Search Server 2008 or Search Server 2008 Express.

Upgrade to Search Server 2008 from Search Server 2008 Express

To upgrade, contact Microsoft Corporation or your vendor for the installation media for Search Server 2008, and a Product Key, and then use the following procedure.

Important Important:

You must be a local server administrator to perform this task. For more information about installing Search Server 2008, see Install Search Server 2008 or Search Server 2008 Express.

To upgrade to Search Server 2008 from Search Server 2008 Express

  1. On the installation Start screen, click Install Search Server.

  2. On the Enter your Product Key screen, enter your Product Key. After the installation program validates the Product Key, it places a green check mark next to the Product Key box.

  3. After the installation program verifies your Product key, click Continue.

  4. On the Read the Microsoft Software License Terms screen, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  5. The upgrade continues based on the current installation of Search Server 2008 Express.

    Note Note:

    If Search Server 2008 Express was installed by using the Basic installation option, you can upgrade only to Search Server 2008 Basic. Alternatively, if Search Server 2008 Express was installed by using the Advanced installation option, you can upgrade only to Search Server 2008 Advanced.

    If Search Server 2008 Express was installed by using the Basic installation option, you cannot add additional query servers after you complete the upgrade. For information about Basic and Advanced installation options and server roles in Search Server 2008 and Search Server 2008 Express, see Plan to deploy Search Server 2008 or Search Server 2008 Express.

  6. Follow the steps in the SharePoint Products and Technologies Configuration Wizard.

    Important Important:

    Search Server 2008 Express is still visible in Control Panel after you install Search Server 2008. Do not uninstall Search Server 2008 Express. Doing so will uninstall your server farm, and this action is not recoverable.

Add a query server

After you complete the installation, you can optionally add a query server to the deployment by installing Search Server 2008 with the Advanced installation option on another host computer, and then doing the following during the installation:

  • Specify the Complete option that installs all Search Server 2008 components, including the application server role.

  • Specify the same SQL Server host computer and database that was specified when Search Server 2008 Express was installed on the original computer.

See Also

Concepts

Add query servers to expand a farm (Search Server 2008)


Upgrade to Search Server 2008 from Windows SharePoint Services 3.0
DropDown image

Updated: 2008-06-12

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

You can add enhanced enterprise search capability to an existing Windows SharePoint Services 3.0 deployment by upgrading to Microsoft Search Server 2008 or Microsoft Search Server 2008 Express. To upgrade, you install Search Server over Windows SharePoint Services 3.0 on each server in your Windows SharePoint Services deployment, and then configure Search Server as necessary for your organization. Installing Search Server always upgrades an existing installation of Windows SharePoint Services 3.0. This article provides instructions and considerations regarding this upgrade process.

Important Important:

Before you upgrade to Search Server, we recommend that you carefully plan your Search Server installation and configuration. For example, it is important to plan your Search Server topology, as Search Server topology options differ from those in Windows SharePoint Services. For more information, see Plan to deploy Search Server 2008 or Search Server 2008 Express.

In this article:

  • Upgrade Paths

  • Before you upgrade to Search Server

  • Start the upgrade to Search Server

  • Upgrade a Basic installation of Windows SharePoint Services 3.0 SP1

  • Upgrade an Advanced installation of Windows SharePoint Services 3.0 SP1

  • Configure Search Server

  • About reversing an upgrade

Upgrade paths

This article applies to upgrading to Search Server 2008 or Search Server 2008 Express from either of the following products:

  • Windows SharePoint Services 3.0

  • Windows SharePoint Services 3.0 with Service Pack 1 (SP1). If Windows SharePoint Services 3.0 SP1 is not installed, you are prompted and required to install it on each Windows SharePoint Services server when Search Server installation begins. Search Server installation cannot proceed until Windows SharePoint Services 3.0 with SP1 is installed on each server.

    Note Note:

    If you are using Windows SharePoint Services 2.0, you must upgrade to Windows SharePoint Services 3.0 before you can upgrade to Search Server. For information about downloading Windows SharePoint Services 3.0 for installation, see Download Windows SharePoint Services 3.0.

You can upgrade either of the following types of Windows SharePoint Services 3.0 deployments to Search Server 2008 or Search Server 2008 Express:

  • Basic installation If Windows SharePoint Services 3.0 was installed with the Basic installation option, you can upgrade to Search Server only as a single-server, stand-alone deployment. When you upgrade a Basic installation, your Windows SharePoint Services databases remain in Windows Internal Database, and Search Server automatically installs and uses Microsoft SQL Server 2005 Express Edition for creating new databases.

    Note Note:

    When you create a SharePoint Web application after the upgrade, you can configure that application to use SQL Server 2005 Express Edition or Windows Internal Database. SQL Server 2005 Express Edition limits maximum database size to 4 gigabytes. Windows Internal Database is not subject to that database size restriction.

  • Advanced installation If Windows SharePoint Services 3.0 was installed with the Advanced installation option, you can upgrade to Search Server only with the Advanced installation option. When you upgrade an Advanced installation, your SQL Server databases are carried over to Search Server 2008 from Windows SharePoint Services.

Before you upgrade to Search Server

Before you upgrade to Search Server, do the following:

  • Upgrade to Windows SharePoint Services 3.0 SP1 if you are using Windows SharePoint Services 2.0. You cannot upgrade to Search Server 2008 directly from Windows SharePoint Services 2.0. For information about downloading Windows SharePoint Services 3.0 for installation, see Download Windows SharePoint Services 3.0. To download the product with SP1, see Download Windows SharePoint Services 3.0 with Service Pack 1.

  • Recommended: Install Windows SharePoint Services 3.0 SP1 if it is not on the computer. We recommend installing Windows SharePoint Services 3.0 SP1 before you begin the Search Server upgrade. Otherwise, you are prompted and required to install Windows SharePoint Services 3.0 SP1 when you begin the upgrade. The upgrade to Search Server proceeds more quickly if Windows SharePoint Services 3.0 SP1 is already installed. To download this service pack for installation, see Windows SharePoint Services 3.0 SP1.

    Important Important:

    When you install Windows SharePoint Services 3.0 SP1, you must run the SharePoint Products and Technologies Configuration Wizard before you install Search Server. For more information and related considerations, see the instructions in Deploy software updates for Windows SharePoint Services 3.0.

  • If language packs are installed for Windows SharePoint Services 3.0, install the corresponding language packs for Search Server. For more information, see Deploy language packs (Search Server 2008).

  • Plan to use the enterprise search capability that Search Server provides. For more information, see Introducing Microsoft Search Server 2008 and Introducing Microsoft Search Server 2008 Express.

  • Consider the implications in case you want to reverse an upgrade and return to using Windows SharePoint Services. For more information, see About reversing an upgrade later in this article.

  • Back up your entire Windows SharePoint Services environment, including your custom templates, features, and solutions.

  • Inform your Windows SharePoint Services users of forthcoming changes to their sites and of anticipated site unavailability during the upgrade process.

Start the upgrade to Search Server

Use this procedure to begin the upgrade to Search Server.

To start the upgrade to Search Server

  1. Start the installation by doing one of the following:

    • Download and install Search Server 2008 Express:

      a. Download Search Server 2008 Express from the Microsoft Enterprise Search Web site. Click the download option that corresponds to the x86 or x64 operating system architecture (32-bit-based or 64-bit-based) on which you plan to install Search Server Express.

      b. Navigate to and run the downloaded file, SearchServerExpress.exe, which is a self-extracting archive file. The file automatically uncompresses and the Search Server Express installation Start screen appears.

    • To install Search Server 2008 or Search Server 2008 Express from a product disc, insert the disc in the CD-ROM drive. The product installation Start screen appears.

      Note Note:

      If the installation Start screen does not appear automatically after a short time, navigate to the root folder of the disc, and then double-click the file Splash.hta.

    • To install Search Server 2008 or Search Server 2008 Express from a local disk or file share, navigate to the product location and then double-click the file Splash.hta. The product installation Start screen appears.

  2. On the Search Server installation Start screen, under Install, click Install Search Server.

  3. The following message appears if Windows SharePoint Services 3.0 SP1 is not installed:

    "Setup is unable to proceed due to the following error(s): http://go.microsoft.com/fwlink/?LinkId=103318. Correct the issue(s) listed above and re-run setup."

    If this message appears, do the following:

    1. Click OK.

    2. Download the version of Windows SharePoint Services 3.0 SP1 that matches your computer architecture (x86 or x64).

    3. Install Windows SharePoint Services 3.0 SP1 on each server in the existing Windows SharePoint Services 3.0 deployment.

      Important Important:

      As previously mentioned, when you install Windows SharePoint Services 3.0 SP1, you must run the SharePoint Products and Technologies Configuration Wizard before you continue with Search Server installation. For more information and related considerations, see the instructions in Deploy software updates for Windows SharePoint Services 3.0.

  4. For Search Server 2008 only:

    1. On the Enter your Product Key screen, enter your Product Key. After the installation program validates the Product Key, it places a green check mark next to the Product Key box.

    2. Click Continue after the installation program verifies your Product Key.

  5. On the Read the Microsoft Software License Terms screen, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  6. Continue the installation by using one of the following procedures to install Search Server over Windows SharePoint Services 3.0 SP1:

    • Upgrade a Basic installation of Windows SharePoint Services 3.0 SP1

    • Upgrade an Advanced installation of Windows SharePoint Services 3.0 SP1

      Important Important:

      After you complete either of these procedures to install Search Server over Windows SharePoint Services, you must finish the upgrade by following the procedures in Configure Search Server later in this article.

Upgrade a Basic installation of Windows SharePoint Services 3.0 SP1

Use this procedure to upgrade to a Search Server Basic installation from a Windows SharePoint Services 3.0 SP1 Basic installation.

To upgrade a Basic installation of Windows SharePoint Services SP1

  1. On the Server Type screen, Stand-alone is the only available server type.

    • Optional: In the File Location tab, change the installation path or the location for content index files.

    • Optional: In the Feedback tab, specify whether you want to participate in the Customer Experience Improvement Program.

  2. On the Server Type screen, click Install Now. The Installation Progress screen appears. This phase of the installation takes several minutes to complete.

  3. On the nextscreen, which prompts you to complete the configuration:

    1. Ensure that the Run the SharePoint Products and Technologies Configuration Wizard now check box is selected.

    2. Click Close to start the Configuration Wizard.

  4. On the Welcome to SharePoint Products and Technologies screen, click Next.

  5. In the dialog box that notifies you that some services might be restarted or reset during configuration, click Yes.

  6. By default, the Search Server 2008 upgrade wizard creates the default Search Center site on port 80. If there is an existing SharePoint site on that port, the Overwrite Default SharePoint Site screen appears. On this screen, click one of the following options:

    • Yes, overwrite the existing site with a new default SharePoint site.

    • No, do not overwrite the existing site. Create a new SharePoint site.

    • No, do not create a default site.

      If you select the latter option, no Search Center site is created. However, you can create and configure your own Search Center site and other sites when the upgrade process is complete.

  7. The Configuring SharePoint Products and Technologies Wizard screen appears. The Configuration Wizard runs for several minutes to automate configuration tasks such as installing Search Server services, installing and configuring SQL Server databases, and creating the Search Server Web site for Search Administration.

  8. On the Configuration Successful page, click Finish. Your Basic installation is now complete. A Web browser opens the Welcome to Microsoft Search Server 2008 page, which provides guidance for configuring your Search Server installation.

    Note Note:

    If you are prompted for a name and password, type the credentials for an account that has access to the Central Administration Web site. Add the site to the list of trusted sites in Windows Internet Explorer when you are prompted.

Note Note:

This completes the process of installing Search Server over a Windows SharePoint Services 3.0 SP1 Basic installation. You must now finish the upgrade by following the procedures in Configure Search Server later in this article.

Upgrade an Advanced installation of Windows SharePoint Services 3.0 SP1

Use this procedure to upgrade to a Search Server Advanced installation from a Windows SharePoint Services 3.0 SP1 Advanced installation.

To upgrade an Advanced installation of Windows SharePoint Services SP1

  1. On the Server Type screen, click one of the following:

    • Complete Installs the application server role and the Web front-end (WFE) server role. We recommend choosing this option under either of the following conditions:

      - This is the first server in your Search Server deployment.

      - You want to configure this computer as an application server for the Search Server 2008 farm that you are creating with this upgrade.

    • Web Front End Installs only the WFE server role.

  2. On the Server Type screen:

    • Optional: In the File Location tab, change the installation path or the location for content index files.

    • Optional: In the Feedback tab, specify whether you want to participate in the Customer Experience Improvement Program.

  3. On the Server Type screen, click Install Now. The Installation Progress screen appears. This phase of the installation takes several minutes to complete.

  4. On the nextscreen, which prompts you to complete the configuration:

    1. Ensure that the Run the SharePoint Products and Technologies Configuration Wizard now check box is selected.

    2. Click Close to start the Configuration Wizard.

  5. On the Welcome to SharePoint Products and Technologies screen, click Next.

  6. In the dialog box that notifies you that some services might be restarted or reset during configuration, click Yes.

  7. On the Completing the SharePoint Products and Technologies Configuration Wizard screen, click Next.

  8. On the Configuration Successful screen, click Finish.

  9. If this is the first server in your Windows SharePoint Services farm that you are upgrading to Search Server, a Web browser opens the Search Server Configuration page. You complete this page only once for any Search Server farm. For instructions on completing this procedure, see "Complete the Search Server Configuration page" in Install Search Server 2008 or Search Server 2008 Express.

  10. Repeat steps 1 through 8 in this procedure for each server in your Windows SharePoint Services farm.

Configure Search Server

After you install Search Server over Windows SharePoint Services, you must complete the upgrade by performing each of the following procedures:

  • Activate features for Web applications carried over to Search Server

  • Configure site collections to use the Search Center

  • Verify start addresses for crawls

  • Configure application server roles

Activate features for Web applications carried over to Search Server

After you install Search Server over Windows SharePoint Services, you must activate features for the Windows SharePoint Services Web applications that were carried over to Search Server. Use the following procedure to activate features for these Web applications.

To activate features for Web applications carried over to Search Server

  1. From the Central Administration Web site, click Application Management.

  2. On the Application Management page, under SharePoint Web Application Management, click Manage Web application features.

  3. On the Manage Web Application Features page, click a Web application.

  4. Next to the description for Office Server Enterprise Search, click Activate.

  5. Next to the description for Office Server Site Search, click Activate.

  6. Repeat steps 3 through 5 for each Web application listed on the Manage Web Application Features page.

Configure site collections to use the Search Center

After you activate features for the Web applications carried over to Search Server, configure each Windows SharePoint Services site collection to use the new Search Center user interface. Use the following procedure to configure these Windows SharePoint Services site collections.

To configure site collections to use the Search Center

  1. From the Central Administration Web site, on the Site Actions menu, click Site Settings.

  2. In the Site Collection Administration section, click Search Settings.

  3. On the Search Setting page, click Use Custom Scopes.

  4. Type the address of your Search Center in the text box, for example, http://servername:port.

  5. Navigate to a page in your original Windows SharePoint Services site.

  6. Verify that the Scopes list now includes All Sites.

    You can add more scopes by clicking Search Scopes on the Search Settings page in the Site Collection Administration section of the Central Administration Web site.

  7. Type a query and verify that you see the results in the Search Center's results.aspx page.

Verify start addresses for crawls

After you install Search Server over Windows SharePoint Services, use the following procedure to verify that all start addresses for crawls in your Windows SharePoint Services deployment were carried over to your Search Server installation.

To verify start addresses for crawls

  1. From the Central Administration Web site, click Shared Services.

  2. On the Search Administration page, in the Crawling section, click Content sources.

  3. On the Manage Content Sources page, point to Local Office SharePoint Server sites, click the down arrow, and click Edit.

  4. On the Edit Content Source page, under Start Addresses, verify that all SharePoint sites from your Windows SharePoint Services deployment are listed. There should be one start address corresponding to each Web application that was in your Windows SharePoint Services deployment.

  5. Verify that search continues to work on all SharePoint sites that were carried over from your Windows SharePoint Services deployment.

Configure application server roles

If you upgraded a multiple-server Windows SharePoint Services 3.0 farm to a Search Server 2008 farm that has multiple application servers, you must configure the Search Server 2008 application servers as follows:

  • On one and only one application server, enable the index server role and disable the query server role.

  • On each other application server, enable the query server role and ensure that the index server role is disabled.

For instructions on how to perform these steps, see "Task 2: Configure application server roles" in Add query servers to expand a farm (Search Server 2008). For information about topology options for Search Server 2008 deployments, see "Topology options" in Plan to deploy Search Server 2008 or Search Server 2008 Express.

About reversing an upgrade

You cannot reverse an upgrade to a Basic configuration of Search Server from a Basic configuration of Windows SharePoint Services. After you upgrade a Basic configuration, you cannot uninstall Search Server and return to a working installation of Windows SharePoint Services.

In contrast, you can reverse an upgrade to an Advanced configuration of Search Server from an Advanced configuration of Windows SharePoint Services. However, reversing this type of upgrade might require configuring SQL Server accordingly. When you configure SQL Server so that you can return to working with Windows SharePoint Services, do the following:

  • To keep the configuration database, stop the Search Server services before completing the uninstall process.

  • To roll back the content databases and rebuild your former farm configuration, uninstall Search Server and then run the SharePoint Products and Technologies Configuration Wizard to rejoin the Windows SharePoint Services server farm.

Important Important:

Before you reverse an upgrade on a production server, we recommend that you back up your environment and then reverse an upgrade on a test server.

See Also

Concepts

Plan to deploy Search Server 2008 or Search Server 2008 Express
Install Search Server 2008 or Search Server 2008 Express
Add query servers to expand a farm (Search Server 2008)


Upgrade to Office SharePoint Server 2007 from Search Server 2008 or Search Server 2008 Express
DropDown image

Updated: 2008-08-21

You can upgrade from Microsoft Search Server 2008 or Search Server 2008 Express to Office SharePoint Server 2007, the Infrastructure Update for Microsoft Office Servers, and optionally Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) and the Infrastructure Update for Windows SharePoint Services 3.0 by using either of the following methods:

  • Perform a slipstream installation This method is appropriate when upgrading a multiple computer server farm.

  • Install each component separately This method is usually performed if you are upgrading a single computer server farm.

Note that the Infrastructure Update for Microsoft Office Servers is a required part of this upgrade. For more information about the update, see the Microsoft Knowledge Base Article Description of the Infrastructure Update for Microsoft Office Servers (KB951297) (http://go.microsoft.com/fwlink/?LinkID=121886).

In this section:

  • Upgrade to Office SharePoint Server 2007 by performing a slipstream installation

  • Upgrade to Office SharePoint Server 2007 by installing each component separately


Upgrade to Office SharePoint Server 2007 by performing a slipstream installation
DropDown image

Updated: 2008-08-21

Use the following procedures in the listed order to upgrade from Microsoft Search Server 2008 or Search Server 2008 Express to Office SharePoint Server 2007, the Infrastructure Update for Microsoft Office Servers, and optionally Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) and the Infrastructure Update for Windows SharePoint Services 3.0 by performing a slipstream installation.

In this article:

  • Before you begin

  • High-level steps

  • Prerequisites

  • Create a shared folder

  • Copy all Office SharePoint Server 2007 files to the shared folder

  • Download and extract Office SharePoint 2007 SP1 to the Upgrades folder (optional step)

  • Download and extract files from the Infrastructure Update for Microsoft Office Servers

  • Run Setup.exe to install all components

  • Post setup configuration

  • Move the SSP to a new Web application

  • Optional Steps

Before you begin

This section provides an overview of recommendations to consider before you install a software update.

  • Schedule the upgrade for a time that causes the least amount of disruption for your users.

    You do not need to stop services, timer jobs, or crawls during the upgrade. The Setup Wizard stops or pauses and then resumes them as needed. The setup wizard restarts the following services during upgrade: Internet Information Services, SharePoint Administration Service, and SharePoint Timer Services.

    Note Note:

    You do not have to stop the World Wide Web Publishing service on the Web front-end servers. However, access to the sites will be temporarily affected during the upgrade when the setup Wizard restarts services during the upgrade.

  • Communicate the proposed schedule to users and the key people who are involved with the Web sites that are hosted on the servers that are running Microsoft Search Server 2008 or Search Server 2008 Express and, if necessary, adjust the schedule.

Back up the server farm before you start the software update installation. You should create a backup of search and all databases. We recommend that you follow these guidelines:

  • Search: Use the backup operation from SharePoint Central Administration or the stsadm command-line tool to create a full backup of the Shared Services Provider (SSP). The backup operation includes both the SSP database and content index in the file system.

    Caution Caution:

    Before you back up, verify that the drive that you are backing up to has enough free space to back up the entire farm. Although you are only backing up the SSP, if you do not have free space for the entire farm, the backup operation will fail.

  • Configuration database and Central Administration content database: You must back up your databases by using SQL Server tools after you have stopped your farm. Use the simple recovery model so that your transaction log is truncated. For more information, see Move all databases (Search Server 2008).

  • Content databases: Perform a full backup operation with either the stsadm command-line tool or SQL Server to back up all content databases. If you are using SQL Server, use the simple recovery model, so that your transaction log is truncated.

  • Front-end Web server: If you have customized the front-end Web server or are unsure of the extent of the customizations to your Web applications, we recommend that you make a backup image of your front-end Web server. Make sure that you have a backup of all solution packages that you have deployed on your front-end Web servers.

    Note Note:

    Ideally, if you are customizing front-end Web computers, the customization should be managed by using a robust build process or script that allows the customizations to be applied to a new computer.

  • If you experience an unrecoverable failure during upgrade, you may have to restore your server from the backup image that you created. You would need to manually apply all customizations to your front-end Web server.

    Note Note:

    We recommend that you back up the server farm after you have verified that the software update installation succeeded.

Important Important:

Backup operations that are running during the upgrade will fail. Because of this, we recommend that you wait for all backups to complete before you upgrade.

For more information, see Protecting and restoring the farm (Search Server 2008).

High-level steps

The following list describes the high level steps that you must perform to upgrade Microsoft Search Server 2008 or Microsoft Search Server 2008 Express to Office SharePoint Server 2007 by using a slipstream installation:

  • Create a shared folder. This folder will contain the Office SharePoint Server 2007 installation files, the Infrastructure Update for Microsoft Office Servers, and optionally, Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) and the Infrastructure Update for Windows SharePoint Services 3.0.

  • Copy Office SharePoint Server 2007 files to the shared folder.

  • Either copy the svrsetup.dll from the shared folder to the Upgrades folder or optionally download and extract Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) to the Upgrades folder within the shared folder.

  • (Optional) Download and extract files from the Infrastructure Update for Windows SharePoint Services 3.0 to the shared folder. We recommend that you install this update because it provides updates that are not included in the Infrastructure Update for Microsoft Office Servers.

  • Download and extract files from the Infrastructure Update for Microsoft Office Servers to the shared folder.

  • Run Setup.exe to install all components and then run the post setup configuration.

After the post setup configuration steps are completed, we recommend several additional steps:

  • Move the Shared Services Provider (SSP) Web site to a new Web application.

    By default, the Central Administration Web site and the SSP Web site reside in the same Web application. After upgrading to Office SharePoint Server 2007 we recommend that you move the SSP Site to a new Web application. Otherwise, you will not be able to back up the SSP.

  • Optionally replace the Search Center site with a site created by using a different site template, such as the Collaboration Portal template.

The procedures in this article apply to upgrading a server farm or a single server installation.

Prerequisites

This section discusses the items and information that must be available before you can upgrade from Microsoft Search Server 2008 or Microsoft Search Server 2008 Express to Office SharePoint Server 2007.

Software requirements

The procedures in this article assume that either Microsoft Search Server 2008 or Microsoft Search Server 2008 Express is already running on one or more computers that you are upgrading to Office SharePoint Server 2007. You must have access to the Internet to download the updates described earlier in this article.

Important Important:

If you are upgrading an x86 installation of Microsoft Search Server 2008 or Microsoft Search Server 2008 Express, you must ensure that you use only x86 components when upgrading. These components include the operating system, Office SharePoint Server 2007, Infrastructure Update for Windows SharePoint Services 3.0, and the Infrastructure Update for Microsoft Office Servers. Likewise, if you are upgrading an x64 installation of Microsoft Search Server 2008 or Microsoft Search Server 2008 Express, you must ensure that you use all x64 components.

Required permissions

To perform the tasks in this article, you must be a member of the Administrators group on each computer in the server farm, a farm administrator, and a shared services provider administrator.

Note Note:

If you are upgrading a multiple computer server farm, you must perform the steps in this article on each computer in the farm in the following order: index server, query servers, and finally the front-end Web servers.

Create a shared folder

Note Note:

To create a shared folder, you must be a member of the Administrators group on the server on which you want to create the shared folder.

  1. Log on to the computer on which you want to create a shared folder as a member of the Administrators group.

  2. Create a shared folder to hold all the files that you want to include in the slipstream installation.

  3. Ensure that all administrators that will install from this share are granted read permissions or a higher level of permissions on this shared folder.

Copy all Microsoft Office SharePoint Server 2007 files to the shared folder

  1. Copy all Office SharePoint Server 2007 files and folders to the shared folder.

    For example, you can copy the files from the Office SharePoint Server 2007 CD. Ensure that the folder hierarchy remains the same as the folder hierarchy on the CD.

    Note Note:

    An important part of this folder hierarchy is a folder named Updates. Later in this article, you will copy other files to the Updates folder that will be automatically used when you run the Office SharePoint Server 2007 Setup Wizard.

  2. Do the following:

    • If you want to install Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1), proceed to Download and extract Office SharePoint Server 2007 SP1 to the Upgrades folder (optional step). We recommend that you install Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1).

    • If you do not want to install Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1), proceed to step 3.

  3. Copy the svrsetup.dll file from the root of the shared folder to the Updates folder in the shared folder that you created earlier.

  4. Proceed to the Download and extract files from the Infrastructure Update section.

Download and extract Office SharePoint Server 2007 SP1 to the Upgrades folder (optional step)

Perform the following steps to install Office SharePoint Server 2007 SP1. Note that it is not necessary to install Windows SharePoint Services SP1 because it is already built into Search Server 2008.

  1. Download Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) to the Updates folder within the shared folder that you created earlier.

    You can download Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkID=105636).

  2. Open a command prompt and navigate to the Updates folder within the shared folder that you created earlier.

  3. To extract the files from the service pack, type the following at a command prompt, and then press Enter.

    filename .exe /extract: drive :\ folder

    Where filename is the file name of the service pack. By default, the file name for an x86 computer is officeserver2007sp1-kb936984-x86-fullfile.exe and the filename for an x64 computer is officeserver2007sp1-kb936984-x64-fullfile-en-us.exe.

    drive is the drive letter on which you created the temporary folder.

    folder is the name of your temporary folder.

  4. On the Microsoft Software License Terms page, select the Click here to accept the Microsoft license terms check box, and then click Continue.

  5. After the files are extracted, proceed to the next section.

Optionally download and extract files from the Infrastructure Update for Windows SharePoint Services 3.0

Download and extract files from the Infrastructure Update for Windows SharePoint Services 3.0

  1. Download the Infrastructure Update for Windows SharePoint Services 3.0 to the Updates folder that is in the shared folder you created earlier.

    You can download the 32-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121881).

    You can download the 64-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121883).

  2. Open a command prompt and navigate to the Updates folder in the shared folder that you created in an earlier procedure.

  3. To extract the files from the Infrastructure Update for Windows SharePoint Services 3.0 executable file that you downloaded, type the following at a command prompt, and then press Enter.

    filename .exe /extract: drive :\ Sharename \Updates

    Where filename is the file name of the Infrastructure Update for Windows SharePoint Services 3.0. By default, the file name for the x86 version is infrastructureupdateforwindowssharepointservices3.0-kb951695-fullfile-x86.exe and the file name for an x64 system is infrastructureupdateforwindowssharepointservices3.0-kb951695-fullfile-x64.exe.

    drive is the drive letter on which you created the share.

    Sharename is the name of the share you created for the slipstream installation.

  4. On the Microsoft Software License Terms page, select the Click here to accept the Microsoft license terms check box, and then click Continue. After all files have been extracted, you can optionally remove all .exe files from the Updates folder to save disk space.

Download and extract files from the Infrastructure Update for Microsoft Office Servers

Note Note:

To perform this procedure, you must be a server administrator on the server on which you created the shared folder for the slipstream installation.

  1. Download the Infrastructure Update for Microsoft Office Servers to the Updates folder that is in the shared folder that you created earlier.

    Note Note:

    If you are upgrading an x86 installation of Office SharePoint Server 2007, you must ensure that you use only x86 components when upgrading. These components include the operating system, Office SharePoint Server 2007, and the Infrastructure Update for Microsoft Office Servers. Likewise, if you are upgrading an x64 installation of Office SharePoint Server 2007, you must ensure that you use all x64 components.

    You can download the 32-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121879).

    You can download the 64-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121880).

  2. Open a command prompt and navigate to the Updates folder in the shared folder that you created in an earlier procedure.

  3. To extract the files from the Infrastructure Update for Microsoft Office Servers executable file that you downloaded, type the following at a command prompt, and then press Enter.

    filename .exe /extract: drive :\ Sharename \Updates

    Where filename is the file name of the Infrastructure Update for Microsoft Office Servers. By default, the file name for the x86 version is infrastructureupdateformicrosoftofficeservers-kb951297-fullfile-x86.exe and the file name for an x64 computer is infrastructureupdateformicrosoftofficeservers-kb951297-fullfile-x64.exe.

    drive is the drive letter on which you created the share.

    Sharename is the name of the share you created for the slipstream installation.

  4. On the Microsoft Software License Terms page, select the Click here to accept the Microsoft license terms check box, and then click Continue. After all files have been extracted, you can optionally remove all .exe files from the Updates folder to save disk space.

Run Setup.exe to install all components

Now that all components are in place, you can install them all at once by using the Setup Wizard for Office SharePoint Server 2007. This section includes all procedures that are required to install a software update successfully in any size server farm.

Note Note:

You must perform steps 1 through 5 from the following procedure on every server that is running Search Server 2008 in the server farm before you complete the installation on any one server that is running Search Server 2008.

  1. Log on to the computer that is running either Search Server 2008 or Search Server 2008 Express that you want to upgrade.

    Note Note:

    Remember that you must upgrade the index server first, then the query servers, and finally Web front-end servers.

  2. In Windows Explorer navigate to the shared folder that you created for the slipstream installation and then double-click Setup.exe.

  3. On the Enter your Product Key page, type your Microsoft Office SharePoint Server 2007 product key, and then click Continue.

  4. On the License Terms page, select I accept the terms of this agreement, and then click Continue.

  5. When the Run the SharePoint Products and Technologies Configuration Wizard now page appears, do the following:

    • If you are installing on a single computer server farm, proceed to Post setup configuration. Otherwise, if you are installing on a server farm in which more than one server is running Search Server 2008 or Search Server 2008 Express, do not run the SharePoint Products and Technologies Configuration Wizard. Instead go to step 6.

  6. Repeat steps 1 through 6 on each additional server in the server farm. When the Run the SharePoint Products and Technologies Configuration Wizard now page appears on those servers, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box, and then click Close.

  7. After you have performed steps 1 through 6 on all servers in the farm, proceed to post setup configuration.

Post setup configuration

Perform the following steps on the index server only. This is typically the server that also hosts the Central Administration Web site.

  1. Log on to the index server as a member for the Administrators group.

  2. On the SharePoint Products and Technologies Configuration Wizard page, select the Run the SharePoint Products and Technologies Configuration Wizard now check box, and then click Close.

  3. On the Welcome to SharePoint Products and Technologies page, click Next.

  4. In the dialog box that appears, click Yes to allow services to be restarted.

    Important Important:

    User access to your server farm will be temporarily disrupted while the Internet Information Services, SharePoint Administration Service, and SharePoint Timer Service are restarted. Typically restarting these services takes only a few moments to complete.

  5. On the completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

  6. On the Configuration Successful page, click Finish.

    The Central Administration Web site appears.

Move the SSP to a new Web application

We recommend that you move the Shared Services Provider (SSP) to a different Web application. Otherwise, you will not be able to restore backups of your SSP.

To move the SSP to a different Web application, perform the following sequence of procedures.

Note Note:

The procedures shown in this section apply regardless of whether you upgrade to Office SharePoint Server 2007 by performing a slipstream installation or install each component individually.

Create a new Web application

You must be a farm administrator to perform the following steps.

  1. Create a Web application for your SSP site. For information about creating a new Web application, see Create or extend Web applications. Note the following:

    • In step 5 you must choose to create a new Web site.

      If you are upgrading a server farm, you must assign a domain user account as the Application pool account. You cannot use a Predefined account.

    • Note the port number for this Web application. You will need to know this number when performing steps later in this article.

  2. When the Application Created page appears, do not create a site collection because you will create a site collection for this Web application later in this article.

Verify the name of your Shared Services Provider

Use the following steps to verify the name of your SSP. You will need to know this name during the next procedure.

  1. In Central Administration, click Application Management.

  2. In the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.

  3. The name of your SSP appears in the SSP and associated Web applications column. Note that by default, the SSP name is SharedServices.

Move the SSP to the Web application you created

You must be a server administrator on the server on which you perform these steps.

  1. On an application server in your server farm, open a command prompt.

  2. Either navigate to the directory that contains the stsadm.exe file or ensure that it is included in the system path. To navigate to the directory that contains stsadm.exe, type the following in a command prompt, and then press Enter.

    CD %COMMONPROGRAMFILES%\Microsoft shared\web server extensions\12\bin

  3. At a command prompt, type the following, and then press Enter. This step adds the folder structure to your Web application that is needed by the SSP.

    stsadm -o addpath -url http:// hostname : port /ssp/admin -type explicitinclusion

    Where hostname is the host name of the Web application that you created in the previous procedure and port is the port number that you assigned to that Web application.

  4. At a command prompt, type the following and then press Enter. This step creates a site collection in the new Web application by using the SSP template.

    stsadm -o createsite -url "http:// hostname : port /ssp/admin" -owneremail email -ownerlogin login -sitetemplate "OSRV#0" -title "Shared Services Administration: SSP name "

    Where hostname and port are the same values that you used in step 3.

    email is the email address that you want to assign as the contact e-mail address for search. This should be in the form of emailalias@contoso.com.

    login is the domain account that you want to assign as the site collection administrator for this site collection. Note that this login account can be used to administer all services in the SSP. For more information about the contact e-mail address, see Change the contact e-mail address (Office SharePoint Server 2007).

    SSP name is the name of your SSP.

  5. At a command prompt, type the following, and then press Enter. This step assigns the SSP to the new Web application that you created.

    stsadm -o editssp -title " SSP name " -sspadminsite http:// hostname : port /ssp/admin

    Where SSP name is the name of your SSP

    hostname and port are the same values that you used in steps 3 and 4.

Test your new SSP

To use your new SSP Web site, do the following:

  1. In Central Administration, click Application Management.

  2. In the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.

  3. On the Manage this Farm's Shared Services page, rest the mouse on the name of your SSP, and then click Open Shared Services Admin Site from the list that appears.

    Note Note:

    The hostname and port number in the Web site's URL should match the host name and port number that you used in the previous procedure.

    The Shared Services Administration site appears.

Restart IIS

Perform the following steps on all servers in the server farm.

Note Note:

You must be a server administrator on each server in the server farm to perform the following steps.

  1. Open a command prompt.

  2. Run the following command to restart IIS: iisreset /noforce.

Optional Steps

After upgrading your server farm, the default top-level Web site on the Web application that is configured for port 80 is the same Search Center site that you had when you were running Microsoft Search Server 2008 or Microsoft Search Server 2008 Express. You can choose to delete your original Search Center site and replace it with a site that was created by using another site template, such as the Collaboration Portal template. A site created with this template provides you with a collaboration portal site that also contains a Search Center site. For more information, see Create a site collection (Office SharePoint Server).


Upgrade to Office SharePoint Server 2007 by installing each component separately
DropDown image

Updated: 2009-07-09

Use the following procedures in the listed order to upgrade from Microsoft Search Server 2008 or Search Server 2008 Express to Office SharePoint Server 2007, the Infrastructure Update for Microsoft Office Servers, and optionally Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) and the Infrastructure Update for Windows SharePoint Services 3.0 by installing each component separately.

In this article:

  • High-level steps

  • Before you begin

  • Prerequisites

  • Install Office SharePoint Server 2007

  • Optionally install Office SharePoint Server 2007 SP1

  • Install the Infrastructure Update for Microsoft Office Servers

  • Move the SSP to a new Web application

  • Optional Steps

High-level steps

The following list describes the high-level steps that you must perform to upgrade Microsoft Search Server 2008 or Microsoft Search Server 2008 Express to Office SharePoint Server 2007 by installing each component separately.

  1. View the presentation Presentation: Understanding and deploying hotfixes, public updates, and service packs (Search Server 2008).

  2. Follow the preliminary steps described in the Before you begin section.

  3. Install Office SharePoint Server 2007 on each server in the server farm.

  4. Optionally install Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) on each server in the server farm (recommended). Note that it is not necessary to install Windows SharePoint Services SP1 because it is already built into Search Server 2008.

  5. (Optional but recommended) Download and install the Infrastructure Update for Windows SharePoint Services 3.0. For more information, see To install the Infrastructure Update for Windows SharePoint Services 3.0.

  6. Install the Infrastructure Update for Microsoft Office Servers on each server in the farm.

After the post setup configuration steps are completed, we recommend several additional steps:

  1. Move the Shared Services Provider (SSP) Web site to a new Web application.

    By default, the Central Administration Web site and the SSP Web site reside in the same Web application. After upgrading to Office SharePoint Server 2007 we recommend that you move the SSP Site to a new Web application. Otherwise, you will not be able to back up the SSP.

  2. Optionally replace the Search Center site with a site that was created by using a different site template, such as the Collaboration Portal template.

The procedures in this article apply to upgrading either a server farm or a single server installation.

Before you begin

This section provides an overview of recommendations to consider before you install a software update.

  • Schedule the upgrade for a time that causes the least amount of disruption for your users.

    You do not need to stop services, timer jobs, or crawls during the upgrade. The Setup Wizard stops or pauses and then resumes them as needed. The setup wizard restarts the following services during upgrade: Internet Information Services, SharePoint Administration Service, and SharePoint Timer Services.

    Note Note:

    You do not have to stop the World Wide Web Publishing service on the Web front-end servers. However, access to the sites will be temporarily affected during the upgrade when the setup Wizard restarts services during the upgrade.

  • Communicate the proposed schedule to users and the key people who are involved with the Web sites that are hosted on the servers that are running Microsoft Search Server 2008 or Search Server 2008 Express and, if necessary, adjust the schedule.

Back up the server farm before you start the software update installation. You should create a backup of search and all databases. We recommend that you follow these guidelines:

  • Search: Use the backup operation from SharePoint Central Administration or the stsadm command-line tool to create a full backup of the Shared Services Provider (SSP). The backup operation includes both the SSP database and content index in the file system.

    Caution Caution:

    Before you back up, verify that the drive that you are backing up to has enough free space to back up the entire farm. Although you are only backing up the SSP, if you do not have free space for the entire farm, the backup operation will fail.

  • Configuration database and Central Administration content database: You must back up your databases by using SQL Server tools after you have stopped your farm. Use the simple recovery model, so that your transaction log is truncated. For more information, see Move all databases (Search Server 2008).

  • Content databases: Perform a full backup operation with either the stsadm command-line tool or SQL Server to back up all content databases. If you are using SQL Server, use the simple recovery model, so that your transaction log is truncated.

  • Front-end Web server: If you have customized the front-end Web server or are unsure of the extent of the customizations to your Web applications, we recommend that you make a backup image of your front-end Web server. Make sure that you have a backup of all solution packages that you have deployed on your front-end Web servers.

    Note Note:

    Ideally, if you are customizing front-end Web computers, the customization should be managed by using a robust build process or script that allows the customizations to be applied to a new computer.

  • If you experience an unrecoverable failure during upgrade, you may have to restore your server from the backup image that you created. You would need to manually apply all customizations to your front-end Web server.

    Note Note:

    We recommend that you back up the server farm after you have verified that the software update installation succeeded.

Caution Caution:

Back up operations that are running during the upgrade will fail. Because of this, we recommend that you wait for all backups to complete before you upgrade.

For more information about backing up and restoring your server farm, see Protecting and restoring the farm (Search Server 2008). For more general information about preparation steps to installing a software update, see Deploy software updates.

Prerequisites

This section discusses the items and information that must be available before you can upgrade from Microsoft Search Server 2008 or Microsoft Search Server 2008 Express to Office SharePoint Server 2007.

Software requirements

The procedures in this article assume that either Microsoft Search Server 2008 or Microsoft Search Server 2008 Express is already running on one or more computers that you are upgrading to Office SharePoint Server 2007. You must have access to the Internet to download the updates described earlier in this article.

Important Important:

If you are upgrading an x86 installation of Microsoft Search Server 2008 or Microsoft Search Server 2008 Express, you must ensure that you use only x86 components when upgrading. These components include the operating system, Office SharePoint Server 2007, Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1), Infrastructure Update for Windows SharePoint Services 3.0, and the Infrastructure Update for Microsoft Office Servers. Likewise, if you are upgrading an x64 installation, you must ensure that you use all x64 components.

Required permissions

To perform the tasks in this article, you must be a member of the Administrators group on each server in the server farm, a farm administrator, and a shared services provider administrator.

Important Important:

If you are upgrading a server farm, you must perform the steps in this article on each server in the farm in the following order: index server, query servers, and finally the front-end Web servers.

Install Office SharePoint Server 2007

Note Note:

To install Office SharePoint Server 2007, you must be a member of the Administrators group on each computer that you are upgrading.

  1. Log on to the first computer that is running either Microsoft Search Server 2008 or Microsoft Search Server 2008 Express that you want to upgrade. Note that you must upgrade the index server first, then the query servers, and finally Web front-end servers.

  2. In Windows Explorer, navigate to the shared folder or CD-ROM drive, and then double-click Setup.exe.

  3. On the Enter your Product Key page, type your Microsoft Office SharePoint Server 2007 product key, and then click Continue.

  4. On the License Terms page, select I accept the terms of this agreement, and then click Continue.

  5. On the SharePoint Products and Technologies Configuration Wizard page, clear the Run the SharePoint Products and Technologies Configuration Wizard now check box, and then click Close.

  6. Repeat steps 1 through 5 on each server in the server farm. After you have performed these steps on all servers in the farm, proceed to Optionally install Office SharePoint Server 2007 SP1.

Optionally install Office SharePoint Server 2007 SP1

You can choose to install Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1). We recommend that you install this service pack. To do so, perform the following steps on each server in the server farm. Otherwise, if you do not want to install this service pack, proceed to Install the Infrastructure Update for Microsoft Office Servers.

Important Important:

Remember to perform the following steps on the index server first, then the query servers, and finally the front-end Web servers.

  1. Download Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1).

    You can download Microsoft Office SharePoint Server 2007 with Service Pack 1 (SP1) from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkID=105636&clcid=0x409).

  2. In Windows Explorer, double-click the .exe that you downloaded.

  3. If the Do you want to run this file? dialog box appears, click Run.

  4. On the Microsoft License Terms page, select the Click here to accept the Microsoft Software License Terms check box and then click Continue.

  5. On the Welcome to SharePoint Products and Technologies page, click Next.

  6. In the dialog box that notifies you that some services might need to be restarted during configuration, click Yes.

  7. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Cancel.

  8. In the dialog box that asks if you are sure you want to exit the configuration wizard, click Yes.

To install the Infrastructure Update for Windows SharePoint Services 3.0

This section includes all required procedures to install the Infrastructure Update for Windows SharePoint Services 3.0 in any size server farm. If you are installing on a multiple computer server farm, install the update on each server in the server farm running Search Server 2008 or Search Server 2008 Express.

Install the Infrastructure Update for Windows SharePoint Services 3.0

  1. Download the Infrastructure Update for Windows SharePoint Services 3.0.

    You can download the 32-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121881).

    You can download the 64-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121883).

  2. Disconnect users from the server farm by stopping the World Wide Web Publishing service (W3SVC) on all Web servers.

    Note Note:

    This manual step is done as a precaution to ensure that the service is fully stopped.

  3. On the first server, in Windows Explorer, double-click the .exe that you downloaded.

    By default, the file name for the x86 version is infrastructureupdateforwindowssharepointservices3.0-kb951695-fullfile-x86.exe and the file name for an x64 system is infrastructureupdateforwindowssharepointservices3.0-kb951695-fullfile-x64.exe.

    Important Important:

    Perform these steps on the index server first, then the query servers, and finally the front-end Web servers.

  4. If the Security Warning dialog box appears, click Run to continue.

  5. On the Microsoft Software License Terms page, select the Click here to accept the Microsoft Software License Terms check-box and then click Continue.

    At the end of the software update installation, the SharePoint Products and Technologies Configuration Wizard starts.

    Note Note:

    If the wizard does not start automatically, click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.

  6. On the Welcome to SharePoint Products and Technologies page, click Next.

  7. In the dialog box that notifies you that some services might need to be restarted during configuration, click Yes.

    Important Important:

    User access to your server farm will be temporarily disrupted while the Internet Information Services, SharePoint Administration Service, and SharePoint Timer Service are restarted. Typically restarting these services takes only a few moments to complete.

  8. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

  9. When the dialog box about installation in a server farm appears, do not click OK. Instead, leave each server with the following dialog box displayed:

    You must run Setup to install new binary files for every server in your server farm. If you have multiple servers in your server farm, run Setup and the configuration wizard on the other servers now, and then return to this server and click OK to continue.

  10. When the dialog box from the previous step is displayed on all servers in the server farm, use one server that hosts the Central Administration Web site to finalize the installation.

  11. On the server you selected in the previous step, click OK.

  12. On the Configuration Successful page, click Finish.

  13. After you have finished updating one Web server that hosts the Central Administration Web site, you should follow the procedures in the "Verify installation" section on this one Web server to ensure that the software update installation was successful.

  14. Continue updating the remaining computers in the server farm, one at a time, by clicking OK in the dialog box.

    Note Note:

    It is important that the SharePoint Products and Technologies Configuration Wizard perform the configuration procedures on only one computer at a time.

Verification step

To verify that the Infrastructure Update for Windows SharePoint Services 3.0 is installed, see the "How to determine whether this update is installed" section of Microsoft Knowledge Base Article Description of the Infrastructure Update for Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=125366).

Installing the Infrastructure Update for Microsoft Office Servers

Use this procedure to install the Infrastructure Update for Microsoft Office Servers on Search Server 2008 or Search Server 2008 Express on a single server or a server farm. You must install the Infrastructure Update for Microsoft Office Servers on each server in the server farm.

You can either download the Infrastructure Update for Microsoft Office Servers to each computer that you are updating or download it to a file share. If you use a file share as an installation source, you must ensure that a minimum of Read permissions have been granted to each server administrator that will be accessing that share.

To install the Infrastructure Update for Microsoft Office Servers

You must install the Infrastructure Update for Microsoft Office Servers on each server in the server farm.

Install the Infrastructure Update for Microsoft Office Servers

  1. Download the Infrastructure Update for Microsoft Office Servers.

    You can download the 32-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121879).

    You can download the 64-bit version of the update from the following location:

    Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=121880).

  2. Ensure that the World Wide Web Publishing service (W3SVC) is stopped on all Web servers.

    Note Note:

    This manual step is done as a precaution to ensure that the service is fully stopped so that users cannot access the server farm during the update.

  3. On the first server, in Windows Explorer, double-click the .exe that you downloaded.

    By default, the file name for the x86 version is infrastructureupdateformicrosoftofficeservers-kb951297-fullfile-x86.exe and the file name for an x64 system is infrastructureupdateformicrosoftofficeservers-kb951297-fullfile-x64.exe.

    Important Important:

    Perform these steps on the index server first, then the query servers, and finally the front-end Web servers.

  4. If the Security Warning dialog box appears, click Run to continue.

  5. On the Microsoft Software License Terms page, select the Click here to accept the Microsoft Software License Terms check-box and then click Continue.

    At the end of the software update installation, the SharePoint Products and Technologies Configuration Wizard starts.

    Note Note:

    If the wizard does not start automatically, click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.

  6. On the Welcome to SharePoint Products and Technologies page, click Next.

  7. In the dialog box that notifies you that some services might need to be restarted during configuration, click Yes.

    Important Important:

    User access to your server farm will be temporarily disrupted while the Internet Information Services, SharePoint Administration Service, and SharePoint Timer Service are restarted. Typically restarting these services takes only a few moments to complete.

  8. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

  9. When the dialog box about installation in a server farm appears, do not click OK. Instead, leave each server with the following dialog box displayed:

    You must run Setup to install new binary files for every server in your server farm. If you have multiple servers in your server farm, run Setup and the configuration wizard on the other servers now, and then return to this server and click OK to continue.

  10. When the dialog box from the previous step is displayed on all servers in the server farm, use one server that hosts the Central Administration Web site to finalize the installation.

  11. On the server you selected in the previous step, click OK.

  12. On the Configuration Successful page, click Finish.

  13. After you have finished updating one Web server that hosts the Central Administration Web site, you should follow the procedures in the "Verify installation" section on this one Web server to ensure that the software update installation was successful.

  14. Continue updating the remaining computers in the server farm, one at a time, by clicking OK in the dialog box.

    Note Note:

    It is important that the SharePoint Products and Technologies Configuration Wizard perform the configuration procedures on only one computer at a time.

  15. When the software update installation and configuration is complete on all the servers in the server farm, make the Web servers available to users by manually starting the World Wide Web Publishing service on each server on which you manually stopped the service.

Verification step

To verify that the Infrastructure Update for Microsoft Office Servers is installed, see the "How to determine whether this update is installed" section of Microsoft Knowledge Base Article Description of the Infrastructure Update for Microsoft Office Servers (KB951297) (http://go.microsoft.com/fwlink/?LinkID=121886).

Move the SSP to a new Web application

We recommend that you move the Shared Services Provider (SSP) to a different Web application. Otherwise, you will not be able to restore backups of your SSP.

To move the SSP to a different Web application, perform the following sequence of procedures.

Note Note:

The procedures shown in this section apply regardless of whether you upgrade to Office SharePoint Server 2007 by performing a slipstream installation or install each component individually.

Create a new Web application

You must be a farm administrator to perform the following steps.

  1. Create a Web application for your SSP site. For information about creating a new Web application, see Create or extend Web applications. Note the following:

    • In step 5 you must choose to create a new Web site. If you are upgrading a server farm, you must assign a domain user account as the Application pool account. You cannot use a Predefined account.

    • Note the port number for this Web application. You will need to know this number when performing steps later in this article.

  2. When the Application Created page appears, do not create a site collection because you will create a site collection for this Web application later in this article.

Verify the name of your Shared Services Provider

Use the following steps to verify the name of your SSP. You will need to know this name during the next procedure.

  1. In Central Administration, click Application Management.

  2. In the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.

  3. The name of your SSP appears in the SSP and associated Web applications column. Note that by default, the SSP name is SharedServices.

Move the SSP to the Web application you created

You must be a server administrator on the server on which you perform these steps.

  1. On an application server in your server farm, open a command prompt.

  2. Either navigate to the directory that contains the stsadm.exe file or ensure that it is included in the system path. To navigate to the directory that contains stsadm.exe, type the following at a command prompt, and then press Enter.

    CD %COMMONPROGRAMFILES%\Microsoft shared\web server extensions\12\bin

  3. At a command prompt, type the following, and then press Enter. This step adds the folder structure to your Web application that is needed by the SSP.

    stsadm -o addpath -url http:// hostname : port /ssp/admin -type explicitinclusion

    Where hostname is the host name of the Web application that you created in the previous procedure and port is the port number that you assigned to that Web application.

  4. At a command prompt, type the following, and then press Enter. This step creates a site collection in the new Web application using the SSP template.

    stsadm -o createsite -url "http:// hostname : port /ssp/admin" -owneremail email -ownerlogin login -sitetemplate "OSRV#0" -title "Shared Services Administration: SSP name "

    Where hostname and port are the same values that you used in step 3.

    email is the email address that you want to assign as the contact e-mail address for search. This should be in the form of emailalias@contoso.com.

    login is the domain account that you want to assign as the site collection administrator for this site collection. Note that this login account can be used to administer all services in the SSP. For more information about the contact e-mail address, see Change the contact e-mail address (Office SharePoint Server 2007).

    SSP name is the name of your SSP.

  5. At a command prompt, type the following, and then press Enter. This step assigns the SSP to the new Web application that you created.

    stsadm -o editssp -title " SSP name " -sspadminsite http:// hostname : port /ssp/admin

    Where SSP name is the name of your SSP.

    hostname and port are the same values that you used in steps 3 and 4.

Test your new SSP

To use your new SSP Web site, do the following:

  1. In Central Administration, click Application Management.

  2. In the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.

  3. On the Manage this Farm's Shared Services page, rest the mouse on the name of your SSP, and then click Open Shared Services Admin Site from the list that appears.

    Note Note:

    The hostname and port number in the Web site's URL should match the host name and port number that you used in the previous procedure.

    The Shared Services Administration site appears.

Restart IIS

Perform the following steps on all servers in the server farm.

Note Note:

You must be a server administrator on each server in the server farm to perform the following steps.

  1. Open a command prompt.

  2. Run the following command to restart IIS: iisreset /noforce.

Optional Steps

After upgrading your server farm, the default top-level Web site on the Web application that is configured for port 80 is the same Search Center site that you had when you were running Microsoft Search Server 2008 or Microsoft Search Server 2008 Express. You can choose to delete your original Search Center site and replace it with a site that was created by using another site template, such as the Collaboration Portal template. A site created with this template provides you with a collaboration portal site that also contains a Search Center site. For more information, see Create a site collection (Office SharePoint Server).

See Also

Concepts

Upgrade to Office SharePoint Server 2007 from Search Server 2008 or Search Server 2008 Express


Configure the farm for search (Search Server 2008)
DropDown image

Updated: 2008-10-30

The articles in this section provide information and procedures for search configuration.

In this section:

  • Configure global search settings (Search Server 2008)

    Learn about how to change the contact e-mail address and about how to specify time-out settings and proxy settings for the crawler.

  • Configure Web servers (Search Server 2008)

    Learn how to put the query server role on Web servers and how to configure a dedicated Web server for crawling.

  • Configure index and query servers (Search Server 2008)

    Learn about how to configure index and query server roles and about how to view or change the location of the content index for index servers and query servers.


Configure global search settings (Search Server 2008)
DropDown image

The articles in this section explain how to change the contact e-mail address and how to specify time-out and proxy settings.

In this section:

  • Change the contact e-mail address (Search Server 2008)

    Use this procedure to provide the e-mail address of a contact person in your organization. You must provide a contact e-mail address before Microsoft Search Server 2008 can crawl any content sources.

  • Specify time-out settings (Search Server 2008)

    Use this procedure to specify how long the crawler will wait to connect to other services and how long it will wait to receive acknowledgement of content requests.

  • Configure proxy settings (Search Server 2008)

    Use this procedure to specify proxy server settings for sending HTTP requests to crawl content and query federated sources.


Change the contact e-mail address (Search Server 2008)
DropDown image

Updated: 2008-07-15

Note Note:

The information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Before Search Server can crawl any content sources, you must provide the e-mail address of a contact person in your organization. This enables an external administrator to contact you in case a crawl is contributing to a problem such as performance degradation on a server that you are crawling.

The administrator of a server that you crawl can find the contact e-mail address in the server event logs. For example, if Search Server is crawling Web-based content, the contact e-mail address appears in the Internet Information Services (IIS) logs on the crawled server.

How the contact e-mail address is established during deployment

You establish the contact e-mail address differently depending on whether you install Search Server by using the Basic installation option or the Advanced installation option:

  • Basic installation option

    When you install Search Server by using the Basic option, the installation sets the contact e-mail address to somebody@example.com. After the installation completes, we recommend that you change this to the address of a contact in your organization.

  • Advanced installation option

    After you install Search Server on the first computer in a deployment by using the Advanced option, the Search Server Configuration page appears. On this page, in the Required section, in the Search Contact E-mail section, you must specify the e-mail address of a contact. After you complete the fields on the Search Server Configuration page and click OK to accept the settings, you cannot return to that page. However, you can change the contact e-mail address at any time after that by using the following procedure.

Note Note:

You must be a search services administrator to complete this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

To change the contact e-mail address

Use this procedure to change the contact e-mail address.

Change the contact e-mail address

  1. On the Search Administration page, do one of the following:

    • In the Crawling section, click Proxy and timeouts.

    • In the System Status section, next to Contact e-mail address, click the e-mail address.

  2. On the Manage Farm-Level Search Settings page, in the Contact E-mail Address section, type the e-mail address of a contact in your organization.

  3. Click OK.


Specify time-out settings (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

You must be a search services administrator to complete this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

Farm administrators can specify the amount of time they want the server to wait while connecting to other services, and how long the server will wait for a request for content to be acknowledged. If you add content sources to crawl servers that you know are slow, you can configure the time-out settings as a proactive measure or you can change the time-out settings at any time that you discover a performance related problem.

To specify time-out settings for search

Use this procedure to specify the time-out settings for the Office SharePoint Server Search service.

Specify timeout settings

  1. In Central Administration, on the Application Management tab, in the Search section, click Manage search service.

  2. On the Search Administration page, under Crawling, click Proxy and timeouts.

  3. On the Manage Farm-Level Search Settings page, in the Timeout Settings section, do the following:

    • In the Connection time (in seconds) box, type the number of seconds you want the server to wait while connecting to other services.

    • In the Request acknowledgement time (in seconds) box, type the number of seconds you want the server to wait for another service to acknowledge a request to connect to that service.

  4. Click OK.


Configure proxy settings (Search Server 2008)
DropDown image

Updated: 2008-09-11

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

A search services administrator can specify proxy server settings for sending HTTP requests to crawl content and query federated sources. A proxy server is a computer that functions as an intermediary to forward a client request to another server and return the results to the client. Using a proxy server can help enhance intranet security and help improve response times for client requests.

Important Important:

This article explains how to configure proxy server settings on the Manage Farm-Level Search Settings page. You must be a search services administrator to configure proxy settings on this page. For more information, see Add or remove a search services administrator (Search Server 2008).

In this article:

  • Configuring Search Server 2008 to use a proxy server

  • Specifying that a proxy server should not be used

  • Understanding proxy settings for federated sources

Configuring Search Server 2008 to use a proxy server

Use this procedure to specify proxy server settings for crawling content and querying federated sources on computers in other networks.

To configure proxy server settings for search

  1. On the Search Administration page, in the Crawling section, click Proxy and Timeouts. The Manage Farm-Level Search Settings page appears.

  2. In the Proxy Server Settings section, click Use the proxy server specified, and then do the following steps:

    • To use the same proxy server settings when querying any federated source, select the Use these proxy settings for access to federated sites check box. For more information, see Understanding proxy settings for federated sources later in this article.

    • In the Address box, type either the NetBIOS name or the IP address of the proxy server.

    • In the Port box, type the port number to use for this proxy server.

    • To bypass this proxy server when crawling local addresses, select the Bypass proxy server for local (intranet) addresses check box.

    • To bypass the proxy server when crawling particular IP addresses, type the site host names or IP addresses in the Do not use proxy server for addresses beginning with box. Separate host names or IP addresses with semicolons (;).

  3. Click OK.

Specifying that a proxy server should not be used

Follow this procedure to specify that a proxy server should not be used for crawling content or querying federated sources on computers in other networks.

To specify that a proxy server should not be used for search

  1. On the Search Administration page, in the Crawling section, click Proxy and Timeouts.

  2. On the Manage Farm-Level Search Settings page, in the Proxy Server Settings section, click Do not connect by using a proxy server.

  3. Click OK.

Understanding proxy settings for federated sources

In Search Server 2008, there are two ways to specify proxy server settings for querying federated sources. Before querying a federated source, Search Server checks in the following order for proxy settings and uses the first settings it finds to connect to the federated source:

  1. The Manage Farm-Level Search Settings page. Proxy settings specified on this page apply to all federated locations.

    We recommend using this method if your organization has only one proxy server for querying federated sources.

  2. The .NET web.config file of the SharePoint site hosting the federated location. There is one web.config file for each SharePoint site. This file is used by all federated locations on that site. Search Server uses the settings in the web.config file as the default proxy settings for federated locations on that site.

    This method allows you to specify a proxy server for each SharePoint site that hosts federated locations. However, using web.config file settings for this purpose can be slow or unsuccessful.

See Also

Concepts

Specify time-out settings (Search Server 2008)
Change the contact e-mail address (Search Server 2008)


Configure Web servers (Search Server 2008)
DropDown image

Updated: 2009-06-04

This section provides information about how to configure all Web servers as query servers and to designate a particular Web server as the server to be crawled in a Microsoft Search Server 2008 farm.

In this section:

  • Configure all Web servers as query servers (Search Server 2008) Learn about how to put the query role on each Web server in the farm.

  • Configure a dedicated front-end Web server for crawling (Search Server 2008) Learn about the advantages of designating one Web server as the server to be crawled in a farm.


Configure all Web servers as query servers (Search Server 2008)
DropDown image

Updated: 2009-06-04

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

This article describes how to add the query server role to existing Web servers. The query server role can be deployed to any number of Web servers. However, if the query server role is deployed to the same server that hosts the index server role, you should not enable additional query servers. This is because the index role recognizes that the query role is located on the same server. Therefore, it does not attempt to propagate the content index to any other query servers.

Note Note:

Before you can add a query server, you must install and configure Search Server 2008 on the first computer in the deployment by following the instructions under "Run an Advanced installation" in Install Search Server 2008 or Search Server 2008 Express. After you complete that procedure, you can add query servers or Web servers to the deployment at any time. For information about Search Server planning, server roles, and topology options, see Plan to deploy Search Server 2008 or Search Server 2008 Express.

Configure all Web servers as query servers

Use this procedure to configure existing Web servers so that they are also query servers. Perform this procedure on all Web servers to which you want to add the query server role.

Important Important:

To perform the following procedure, you must be a farm administrator.

To configure all Web servers as query servers

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Services on server.

  2. On the Services on Server page:

    1. If the server name that appears is not the Web server that you want to also configure as a query server, click the arrow next to the server name, click Change Server, and then click the appropriate Web server.

    2. In the Start services in the table below section, verify that this server is a Web server by checking whether the Windows SharePoint Services Web Application service is started, and then click Office SharePoint Server Search.

  3. On the Configure Office SharePoint Server Search Service Settings page, in the Query and Indexing section, select the Use this server for serving search queries check box.

    Note Note:

    If the Use this server for indexing content check box is selected, you should stop this procedure because the server that you are configuring is the index server and should not be configured as a query server if you want multiple query servers. For more information, see Plan to deploy Search Server 2008 or Search Server 2008 Express.

  4. In the Query Server Index File Location section, type the path to which you want to save the content index in the Query server index file location box. This path can be a local or a mapped drive.

  5. The location in the Query server index file location must be shared to allow the index server to propagate the content index to it. Depending on how you want to configure the share, select one of the following choices:

    • If the location in the Query server index file location is not configured as a share, click Configure share automatically. In the User name box, type the name of a user account that is a member of the Administrators group on this query server. In the Password box, type the password of the user account named in the User name box.

    • Select I will configure the share with STSAdm, if you want to configure the path of the content index using the Stsadm command-line tool with the Osearch operation and the propagationlocation parameter. For more information, see Osearch: Stsadm operation (Office SharePoint Server). This operation shares the location and gives the search service account write permission to the share.

    • Select Do nothing. The share is already configured if the location for the content index is already shared and the search service account has write access to that share.

  6. Repeat steps 2 through 5 until all Web servers have the added role of query server.

  7. To save the changes and return to the Services on Server page, click OK.

See Also

Concepts

Configure Web servers (Search Server 2008)
Configure a dedicated front-end Web server for crawling (Search Server 2008)


Configure a dedicated front-end Web server for crawling (Search Server 2008)
DropDown image

Updated: 2009-06-04

Note Note:

The information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

By default, Search Server 2008 uses all of the front-end Web servers in a server farm to crawl content in the farm. When a farm is configured in this way, crawler behavior depends on the number of front-end Web servers in the farm. If the farm has only one front-end Web server, the index server sends get requests directly to that server. If the farm has multiple front-end Web servers, the index server sends get requests to the network load balancer, which forwards each request to one of the front-end Web servers. (If a server farm has more than one front-end Web server, the farm must use a network load balancer to distribute user content requests across the front-end Web servers.) Over time, the network load balancer spreads requests across all front-end Web servers. When a front-end Web server receives a content request, it gets the content from content databases that are associated with the SharePoint sites that are being crawled and returns that content to the index server.

In this article:

  • Performance issues caused by using all front-end Web servers for crawling

  • Recommended solution

  • About configuring a dedicated front-end Web server for crawling

Performance issues caused by using all front-end Web servers for crawling

Using all front-end Web servers for crawling in a farm can work well for small to medium-size organizations. Large organizations, however, tend to crawl more content. Such organizations might crawl gigabytes or even terabytes of content. Crawling content in a farm can cause surges in network traffic and can place considerable demands on front-end Web server resources such as the disk, processors, and memory. Crawling a large amount of content can produce more network traffic with the farm's front-end Web servers than all user requests combined. This traffic can adversely affect the performance of all front-end Web servers in the farm and thereby decrease response times for end-user requests for SharePoint site content.

Recommended solution

We recommend that you use a dedicated front-end Web server for crawling, especially if crawling content is producing more traffic on the front-end Web servers than user requests. You can specify any front-end Web server in your farm for crawling. However, for best performance, we recommend that you configure the index server as the dedicated front-end Web server for crawling if the index server has the capacity for both roles. By using the same computer as both the index server and dedicated front-end Web server, you eliminate the need for the index server to send requests to a different computer when crawling content. This reduces overall network traffic and improves crawl performance.

We also recommend that you do not include the dedicated front-end Web server in the network load balancing rotation for incoming user requests for content. Otherwise, user requests that the network load balancer directs to the dedicated front-end Web server for crawling might be subjected to inconsistent performance.

When not to configure a dedicated front-end Web server for crawling

Do not configure a dedicated front-end Web server for crawling under any of the following conditions:

  • Another application (such as the Excel Calculation service) is running on the index server. Configuring a dedicated front-end Web server for crawling might prevent that application from communicating with other servers in the farm.

    If other applications are running on the index server, move those applications to another application server before configuring a dedicated front-end Web server for crawling.

  • You want to use the index server as the dedicated front-end Web server for crawling and the index server is also configured as a query server.

  • The NetBios name of your query server is also the host name of your SharePoint site.

In either of the preceding two cases, configuring a dedicated front-end Web server for crawling can prevent the index server from propagating the index to another server.

About configuring a dedicated front-end Web server for crawling

There are two ways to configure a dedicated front-end Web server for crawling:

  • Use the Configure Office SharePoint Server Search Service Settings page in Central Administration.

  • Update the Hosts file directly.

Before you configure a dedicated front-end Web server for crawling, we recommend that you read the following section to determine which configuration method to use.

How the Hosts file is affected when you use the user interface to configure a dedicated front-end Web server for crawling

When crawling content, Search Server 2008 reads the Hosts file on the index server to determine whether to use all front-end Web servers for crawling (the default), or to use a dedicated front-end Web server for crawling.

When you use the Configure Office SharePoint Server Search Service Settings page in Central Administration to select a dedicated front-end Web server for crawling, the SharePoint timer service writes the following entries to the Hosts file:

  • One entry that specifies the IP address and the computer name of the front-end Web server.

  • One entry for each Web application on the front-end Web server that you configured to use a host header. Each such entry specifies the IP address of the front-end Web server, followed by the host header.

Each entry is on a separate line in the Hosts file, like this:

111.11.111.111 MyMossMachine #Added by Office SharePoint Server Search (7/15/2008 2:56 PM).

111.11.111.111 Marketing #Added by Office SharePoint Server Search (7/15/2008 2:56 PM).

111.11.111.111 Human Resources #Added by Office SharePoint Server Search (7/15/2008 2:57 PM).

Possible problems

In some cases, the timer service writes the incorrect IP address to your Hosts file. (For more information, see the blog post at http://go.microsoft.com/fwlink/?LinkId=135698.) This can cause problems ranging from inability to crawl content to inability to view sites, such as the Search Services Provider (SSP) or Central Administration site. The timer service can add an incorrect IP address to the Hosts file in cases such as the following:

  • The server that you specified as your dedicated front-end Web server for crawling has multiple IP addresses assigned to one or more network cards.

  • Your server farm is using network load balancing.

If either of these conditions is true, we recommend that you add the entries to the Hosts file directly instead of using the user interface to specify a dedicated front-end Web server for crawling.

Important Important:

When you use the Configure Office SharePoint Server Search Service Settings page in Central Administration to specify a dedicated front-end Web server for crawling, you cannot change the Hosts file manually if the timer service adds the wrong IP address. This is because the timer service repeatedly overwrites the entries in the Hosts file every few minutes. If this occurs, use the Configure Office SharePoint Server Search Service Settings page in Central Administration to specify that all front-end Web servers are used for crawling, and then remove the entries in the Hosts file that were made by the timer service.

To configure a dedicated front-end Web server for crawling, perform one of the following procedures:

  • Configure a dedicated front-end Web server for crawling by using the user interface (Search Server 2008)

  • Configure a dedicated front-end Web server for crawling by editing the Hosts file (Search Server 2008)


Configure a dedicated front-end Web server for crawling by editing the Hosts file (Search Server 2008)
DropDown image

Updated: 2009-06-04

Before you perform this procedure, confirm that:

  • You have read the topic Configure a dedicated front-end Web server for crawling (Search Server 2008).

Use the following procedures in the order listed to configure a dedicated front-end Web server for crawling by editing the Hosts file directly.

In this article:

  • Ensure that the dedicated front-end Web server for crawling is not in the network load balancing rotation

  • Start the Windows SharePoint Services Web Application service on the front-end Web server

  • Specify the dedicated front-end Web server to use for crawling

  • Configure the Hosts file

Ensure that the dedicated front-end Web server for crawling is not in the network load balancing rotation

Because crawling content typically places the front-end Web server under heavy load, we recommend that you remove the dedicated front-end Web server from the network load balancing rotation. Otherwise, user requests that the network load balancer directs to the dedicated front-end Web server for crawling will be subjected to inconsistent performance. For more information about network load balancing, see Remove a host from a Network Load Balancing cluster (http://go.microsoft.com/fwlink/?LinkID=91030).

Start the Windows SharePoint Services Web Application service on the front-end Web server

You must ensure that the Windows SharePoint Services Web Application service is running on the front-end Web server that you want to use for crawling content.

Important Important:

You must be a farm administrator to complete this procedure.

Starting the Windows SharePoint Services Web Application service

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Servers in farm.

  2. On the Servers in Farm page, in the Server column, click the name of the server that you want to configure as your dedicated front-end Web server for crawling.

  3. On the Services on Server page, in the Start services in the table below section, find the Windows SharePoint Services Web Application row. Verify that the Status column displays Started. If this service is started, no further action is needed. Otherwise, click Start.

Specify the dedicated front-end Web server to use for crawling

Important Important:

You must be a server administrator to complete this procedure.

Before you can configure the Hosts file, you must collect the following information:

  • The base or host header name of each Web application in your farm that you will crawl.

  • IP address of the server that you want to use as the dedicated front-end Web server for crawling.

Obtain the base or host header names

Important Important:

You must be a farm administrator to perform the following procedure.

Obtain Web application names

  1. In Central Administration, on the Application Management tab, in the SharePoint Web Application Management section, click Web application list.

  2. On the Web Application List page, in the URL column, note the base or host header names of the Web applications that you want to crawl. For example, if the URL is http://contoso, the base or host header name is contoso.

Determine the IP address of the dedicated front-end Web server for crawling

If you configure the index server as the dedicated front-end Web server for crawling, you can skip to Configure the Hosts file. Otherwise, note the IP address of the server that you want to configure as the dedicated front-end Web server for crawling. If you know the NetBIOS name of the server, you can use the ping command to determine the IP address.

Configure the Hosts file

Important Important:

You must be a member of the administrators group on the index server to complete the following procedure.

Configure the Hosts file to specify a dedicated front-end Web server for crawling

  1. In Windows Explorer, navigate to the <systemdrive>:\winnt\system32\drivers\etc folder.

  2. Open the Hosts file in Notepad.

  3. On the line below the entry 127.0.0.1 localhost, add the entries for the Web applications that you want to crawl.

  4. On the File menu, click Save As.

  5. In the Save as type list, select All Files.

  6. Click Save and then close Notepad.

Hosts file examples

The following examples show how you might configure the Hosts file for different scenarios. These scenarios assume the following:

  • You have removed the server that you are specifying as the dedicated front-end Web server for crawling from network load balancing rotation, if applicable. For more information about network load balancing, see Remove a host from a Network Load Balancing cluster (http://go.microsoft.com/fwlink/?LinkID=91030).

  • You have started the Windows SharePoint Services Web Application service on the server that you are specifying as the dedicated front-end Web server for crawling, as described earlier in this article.

Scenario 1 - Configure the index server as the front-end Web server for crawling

Your server farm has three Web applications that you crawl. The application names are Contoso, Marketing, and Support. Because you are using the index server as the front-end Web server for crawling, you can use the loopback IP address (127.0.0.1) to specify the index server as the front-end Web server for crawling.

You add the following entries to your Hosts file below the entry 127.0.0.1 localhost:

127.0.0.1 Contoso

127.0.0.1 Marketing

127.0.0.1 Support

Scenario 2 - Configure a server other than the index server as the front-end Web server for crawling

Your server farm has four Web applications that you want to crawl. The application names are Contoso, Marketing, Sales, and Support. Because you are not using the index server as the Web front-end for crawling, you must add the actual IP address of the server that you want to specify as the dedicated Web front-end for crawling. In this example, the IP address of the dedicated front-end Web server for crawling is 10.10.10.4.

You add the following entries to your Hosts file below the entry 127.0.0.1 localhost:

10.10.10.4 Contoso

10.10.10.4 Marketing

10.10.10.4 Sales

10.10.10.4 Support

See Also

Concepts

Estimate performance and capacity requirements for Search Server 2008
Configure a dedicated front-end Web server for crawling (Search Server 2008)
Configure a dedicated front-end Web server for crawling by using the user interface (Search Server 2008)


Configure a dedicated front-end Web server for crawling by using the user interface (Search Server 2008)
DropDown image

Updated: 2009-06-04

Before you perform this procedure, confirm that:

  • You have read the article Configure a dedicated front-end Web server for crawling (Search Server 2008).

Use the following procedures in the order listed to configure a dedicated front-end Web server for crawling by using the Configure Office SharePoint Server Search Service Settings on server page in Central Administration.

In this article:

  • Ensure that the dedicated front-end Web server for crawling is not in the network load balancing rotation

  • Start the Windows SharePoint Services Web Application service on the front-end Web server

  • Specify the dedicated front-end Web server to use for crawling

  • Verify that the Hosts file is correct

Ensure that the dedicated front-end Web server for crawling is not in the network load balancing rotation

Because crawling content typically places the front-end Web server under heavy load, we recommend that you remove the dedicated front-end Web server from the network load balancing rotation. Otherwise, user requests that the network load balancer directs to the dedicated front-end Web server for crawling will be subjected to inconsistent performance. For more information about network load balancing, see Remove a host from a Network Load Balancing cluster (http://go.microsoft.com/fwlink/?LinkID=91030).

Start the Windows SharePoint Services Web Application service on the front-end Web server

You must ensure that the Windows SharePoint Services Web Application service is running on the front-end Web server that you want to use for crawling content.

Important Important:

You must be a farm administrator to complete this procedure.

Starting the Windows SharePoint Services Web Application service

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Servers in farm.

  2. On the Servers in Farm page, in the Server column, click the name of the server that you want to configure as your dedicated front-end Web server for crawling.

  3. On the Services on Server page, in the Start services in the table below section, find the Windows SharePoint Services Web Application row. Verify that the Status column displays Started. If this service is started, no further action is needed. Otherwise, click Start.

Specify the dedicated front-end Web server to use for crawling

Important Important:

You must be a farm administrator to complete this procedure.

Specifying the front-end Web server to use for crawling

  1. In Central Administration, on the Operations tab, click Servers in farm.

  2. On the Servers in Farm page, in the Server column, click the name of the index server.

  3. On the Services on Server page, in the Service column, click Office SharePoint Server Search.

  4. On the Configure Office SharePoint Server Search Service Settings on server page, in the Web Front End And Crawling section, select Use a dedicated web front end computer for crawling and then select the computer that you want to use from the list.

  5. Click OK.

Verify that the Hosts file is correct

Important Important:

You must be a server administrator to complete this procedure.

After completing the previous procedure, the Office SharePoint Server Search service automatically updates the Hosts file with the IP address of the dedicated front-end Web server that you specified for crawling.

Note Note:

The Office SharePoint Server Search service uses the Hosts file to locate the IP address of the front-end Web server to use for crawling instead of using a domain name server (DNS).

In some cases, the Office SharePoint Server Service updates the Hosts file with an incorrect IP address, which could prevent you from accessing any SharePoint sites on your sever farm. Such an error can occur if the servers in your farm have been configured with multiple static IP addresses or have implemented network load balancing. Because of this, we highly recommend that you verify that the Office SharePoint Server Search service updated the Hosts file with the IP address of the front-end Web server that you specified for crawling.

Use the following procedure to view the Hosts file to determine if the correct IP address for the server that you specified as the dedicated front-end Web server for crawling was added.

View the Hosts file

  1. Log on to the index server as a member of the Administrators group.

  2. Navigate to <systemdrive>:\winnt\system32\drivers\etc.

  3. Open the Hosts file in a text editor, such as Notepad.

  4. View the IP addresses assigned to the server that you specified as the front-end Web server for crawling.

    Note Note:

    The IP address that the Office SharePoint Server Search service adds to the Hosts file is appended with a comment similar to the following:

    #Added by Office SharePoint Server Search (5/1/2007 1:26 PM)

If the Office SharePoint Server Search service did add the wrong IP address to the Hosts file, do the following:

  1. Repeat the steps in Specify the front-end Web server to use for crawling and select Use all web front-end computers for crawling in step 4 to remove the entries from the Hosts file.

  2. Update the Hosts file directly to configure a dedicated front-end Web server for crawling. For more information, see Configure a dedicated front-end Web server for crawling by editing the Hosts file (Search Server 2008).

See Also

Concepts

Estimate performance and capacity requirements for Search Server 2008
Configure a dedicated front-end Web server for crawling (Search Server 2008)
Configure a dedicated front-end Web server for crawling by editing the Hosts file (Search Server 2008)


Configure index and query servers (Search Server 2008)
DropDown image

The articles in this section discuss configuration of index servers and query servers in a Microsoft Search Server 2008 deployment.

In this section:

  • Configure index and query server roles (Search Server 2008)

    This article describes how you must configure index server and query server roles when you add a query server to an existing deployment.

  • View or change content index locations (Search Server 2008)

    This article describes how to view or change the location of the content index for an index server or a query server.


Configure index and query server roles (Search Server 2008)
DropDown image

Updated: 2008-10-30

Note Note:

The information in this article pertains to Microsoft Search Server 2008 only. It does not pertain to Microsoft Search Server 2008 Express.

After you install Search Server 2008 on the first computer in a deployment by using the Advanced installation option, you can add application servers and front-end Web servers to the deployment according to your needs. Each time that you add an application server, you must configure the index server role and the query server role on all application servers in the farm so that exactly one application server functions as the index server and the remaining application servers function as query servers. (A Search Server 2008 farm has exactly one index server and can have multiple separate query servers.) This article explains how to enable index and query server roles as necessary for a Search Server 2008 farm.

Understanding index and query server roles

In a Search Server 2008 deployment, an application server is a computer on which one or both of the following roles are installed and enabled:

  • The index server role, which crawls and indexes content.

  • The query server role, which serves search queries.

An application server that has the index server role enabled functions as the index server for the farm. An application server that has the query server role enabled functions as a query server for the farm.

In a single-server deployment, Search Server 2008 automatically enables the index server role and query server role on the stand-alone server. In this way, the single application server functions as both index server and query server for the deployment.

Configuring index and query server roles when you add application servers

When you add a second application server to a deployment, typically you separate the index server role and query server role to different computers in the following way:

  • On the original application server, disable the query server role and ensure that the index server role remains enabled. In this way, the original application server continues to function as the index server, but not as a query server.

  • On the second application server, enable the query server role but not the index server role. In this way, the second application server functions as a query server, but not as the index server.

Each time subsequently that you add an application server to the deployment, you must ensure that the query server role, but not the index server role, is enabled on that application server.

Note Note:

For more information about using query servers, see the following resources:

  • For complete instructions for adding a query server to an existing deployment, see "Task 2: Configure application server roles" in Add query servers to expand a farm (Search Server 2008).

  • For information about the benefits of adding query servers to a farm, see "Advantages of deploying separate query servers" in Plan to deploy Search Server 2008 or Search Server 2008 Express.

To enable or disable the index server role or query server role

Use this procedure to enable or disable the index server role or query server role on a particular application server.

Note Note:

To perform this procedure you must be a search services administrator and a member of the Administrators group on the server that you are configuring. For more information, see Add or remove a search services administrator (Search Server 2008).

Enable or disable the index server role or query server role

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Services on server.

  2. On the Services on Server page:

    1. If the server name that appears is not the server you want to configure, click the arrow next to the server name, click Change Server, and then click the index server.

    2. In the Start services in the table below section, click Office SharePoint Server Search.

  3. On the Configure Office SharePoint Server Search Service Settings page, in the Query and Indexing section, assign application server roles for the server as appropriate:

    • To enable the index server role on the computer, select Use this server for indexing content.

    • To enable the query server role on the computer, select Use this server for serving search queries.

  4. To return to the Services on Server page, click OK.

See Also

Concepts

Install Search Server 2008 or Search Server 2008 Express
Plan to deploy Search Server 2008 or Search Server 2008 Express
Add query servers to expand a farm (Search Server 2008)


View or change content index locations (Search Server 2008)
DropDown image

Updated: 2008-11-30

This article provides information about viewing or changing the location of the content index for an index server or a query server.

Note Note:

In this article, information about viewing or changing the content index location for the index server applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express. However, information about viewing or changing the location for a separate query server applies only to Microsoft Search Server 2008. (A Search Server 2008 Express deployment cannot have separate index and query servers. Such a deployment has only one application server, which functions as both the index server and the query server for the deployment.)

About content index locations

As Search Server 2008 crawls content, it creates or updates a content index. The content index stores text from crawled documents.

In a deployment that contains one or more query servers that are separate from the index server, Search Server continually propagates the content index from the index server to each query server. Thus, the content index is on the index server and a copy of the content index is on each separate query server. (This enables each query server to serve queries from its copy of the content index.)

When you deploy the index server or add a query server, you establish the location, or path, of the content index for that server. The content index location can be different for each index and query server, and you can change the location for any index server or query server later according to your needs. For example, you might want to make such a change if the current location has limited disk space, or if you want to move the index to a storage area network (SAN). The default location for the content index on an index server or a query server is: C:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications

In this article:

  • How you establish the content index location for the index server during deployment

  • How you establish the content index location for a query server during deployment

  • Viewing or changing the content index location for index and query servers

How you establish the content index location for the index server during deployment

The first computer that you deploy for a Search Server farm is automatically configured as the index server for the deployment. During the installation, you establish the location of the content index on the index server. The location is established differently depending on whether you install Search Server by using the Basic installation option or the Advanced installation option:

  • Basic installation option

    During a Basic installation, the content index location is set to the default path. There is no option to specify a different path.

  • Advanced installation option

    During an Advanced installation on the first computer in a deployment, you can specify the content index location in either of the following places:

    • On the Server Type page, on the File Location tab.

    • On the Search Server Configuration page, in the Optional section, in the Content index location section.

For more information, see Install Search Server 2008 or Search Server 2008 Express.

How you establish the content index location for a query server during deployment

When you add a query server to an existing Search Server deployment, you establish the content index location for that server. This is the location to which the content index continually propagates from the index server. During installation, on the Server Type page, on the File Location tab, you can accept the default path for the content index or you can specify a different path.

Viewing or changing the content index location for index and query servers

After you deploy the index server or a query server, you can perform any of the following procedures at any time:

  • View the content index location for the index server (Search Server 2008)

  • Change the content index location for the index server (Search Server 2008)

  • View the content index location for a query server (Search Server 2008)

  • Change the content index location for a query server (Search Server 2008)

See Also

Concepts

Plan to deploy Search Server 2008 or Search Server 2008 Express
Add query servers to expand a farm (Search Server 2008)


View the content index location for the index server (Search Server 2008)
DropDown image

Updated: 2008-10-30

Note Note:

The information in this article pertains to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

As Search Server 2008 crawls content, it creates or updates a content index. The content index stores text from crawled documents and grows as the index server crawls more content. When you deploy the index server, you establish the location of the content index that is associated with that server. After you deploy the index server, you can change the location of the associated content index according to your needs.

This article explains how to view the location of the content index that is associated with the index server. You might want to check this location in situations such as the following:

  • You want to determine if the content index location has enough disk space to accommodate the content index as it grows.

  • An administrator changed the content index location after the index server was deployed. In such a case, the old content index is not automatically deleted, but it remains in its previous location. To remove the old content index, you must delete it manually from its previous location. For more information, see Change the content index location for the index server (Search Server 2008).

In this article:

  • To view the original location of the content index for the index server

  • To view the current location of the content index for the index server

Note Note:

To view the location of the content index, you must be a search services administrator and a member of the Administrators group on the local computer. For more information, see Add or remove a search services administrator (Search Server 2008).

To view the original location of the content index for the index server

Use this procedure to view the original location of the content index that is associated with the index server. This is the location you established for the content index when you installed Search Server on the index server.

View the original location of the content index for the index server

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Services on server.

  2. On the Services on Server page:

    1. If the server name that appears is not the index server, click the arrow next to the server name, click Change Server, and then click the index server.

    2. In the Start services in the table below section, click Office SharePoint Server Search.

  3. On the Configure Office SharePoint Server Search Service Settings page, in the Index Server Default File Location section, you can view the original index file location.

  4. To return to the Services on Server page, click OK.

To view the current location of the content index for the index server

Use this procedure to view the current location of the content index for the index server.

View the current location of the content index for the index server

  1. In Central Administration, in the Quick Launch, click Shared Services Administration.

  2. On the Manage this Farm's Shared Services page, point to the Shared Services Provider, click the arrow, and then click Edit Properties.

  3. In the Index Server section, in the Path for index file location box, you can view the location of the content index on the index server.

  4. To return to the Manage this Farm's Shared Services page, click OK.


Change the content index location for the index server (Search Server 2008)
DropDown image

Updated: 2008-08-28

When deploying Microsoft Search Server 2008, you can choose to specify the location of the index file, also referred to as the content index, on the index server or accept the default setting which is drive:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications\

where drive is the drive partition on which Office SharePoint Server 2007 is installed

After the index file is created at the location you chose, you might later decide to change the location of the file for one of the following reasons:

  • You forgot to specify the location you wanted during deployment or you performed a basic installation, so the default index file location was used.

  • You have added an additional hard drive or storage area network (SAN) to your index server to store the index file.

  • You have discovered that the location you chose does not have enough available disk space.

Regardless of the reason for changing the location, you can use the following procedures in the order shown to change the location of your index file. You can use these procedures in a production environment. Note that these procedures not only assign a different file location for the content index but also copy the content index to the new location that you specify.

Warning Warning:

If an index server is also configured as a query server, users will be unable to get search results from their queries while the index is being moved to the new location. This is because when one server is used as both an index server and query server the index is not propagated to other servers. If an index server is also a query server, we recommend that you schedule the index file location change for a time that will be least disruptive to your end users. This always applies to Search Server 2008 Express because it can only be deployed on one server.

Prerequisites

To perform the procedures shown in this article, you have to be a Search Service administrator, and a member of the Administrators group on the index server.

Do not allow crawls to occur during the change

We recommend that do not change the index location while content is being crawled. Otherwise, you might have to perform a full crawl of the content sources that were crawling during the move. To ensure that crawls do not occur during the file location change, do the following:

  • Pause all content sources that are currently crawling content. After the index has been moved to the new location you will resume the crawls that you paused. We recommend that you do not stop crawls because the next time you crawl the affected content source, the system will force a full crawl of that content source even if an incremental crawl is requested. For more information about stopping crawls, see Pause and resume a crawl (Search Server 2008).

  • Remove all crawl schedules that might start a crawl while the index file location is being changed. You do not need to remove crawl schedules for crawls that are paused.

Remove a crawl schedule for a particular content source

Perform the following steps on content sources that have scheduled crawls that might start while the content index location is being changed. Note that you do not need to perform these steps for content sources that are paused.

  1. On the Search Administration page, in the Crawling section of the Quick Launch, click Content sources.

  2. On the Manage Content Sources page, point to the content source for which you want to remove a crawl schedule, click the arrow that appears, and then click Edit.

  3. On the Edit Content Source page, in the Crawl Schedules section, if the Full Crawl list is set to None or set to a schedule that will not start during the time that the index location is being changed, proceed to step 7. Otherwise continue to step 4.

  4. In the Crawl Schedules section, below the Full Crawl list click Edit schedule.

    The Manage Schedules dialog box appears.

  5. Write down the settings of the crawl schedule and the content source for which it is configured so that you can recreate this crawl schedule after the index file location has been changed. Click Cancel to close the Manage Schedules page.

  6. Select None in the Full Crawl list.

  7. On the Edit Content Source page, in the Crawl Schedules section, if the Incremental Crawl list is set to None or set to a schedule that will not start during the time that the index location is being changed, proceed to step 11. Otherwise, continue to step 8.

  8. In the Crawl Schedules section, below the Incremental Crawl list click Edit schedule.

    The Manage Schedules dialog box appears.

  9. Write down the settings of the crawl schedule and the content source for which it is configured so that you can recreate this crawl schedule after the index file location has been changed. Click Cancel to close the Manage Schedules page.

  10. Select None in the Incremental Crawl list.

  11. Click OK to close the Edit Content Source page.

  12. Repeat steps 2 through 11 for each remaining content source that is not paused.

Ensure delete crawls are not taking place

Delete crawls occur when a search service administrator deletes a content source or a start address from a content source. When either of these actions occurs, the system deletes the items associated with the affected URLs from the index.

We recommend that you verify whether delete crawls are taking place, and if they are, wait for them to complete before you move the index file location.

Verify whether delete crawls are taking place

  1. On the Search Administration page, in the System Status section, verify that the Crawl status is Idle. You can also view the Active crawls section of the Search Administration page to verify that no crawls are occurring.

    Tip Tip:

    If a delete crawl is taking place, the Crawl status row displays "Deleting content from the index".

  2. If a delete crawl is taking place, wait for it to stop before proceeding to the next step. We recommend that you refresh the page periodically to ensure that you are viewing the latest status.

Back up the Shared Services Provider

Before you change the index file location, we recommend that you create a full backup of the Shared Services Provider. Doing so backs up the following items that are related to search:

  • Search data, including the search database

  • Content index that is in the file system of the index server.

For more information, see Back up and restore SSPs (Office SharePoint Server 2007).

Change the location of the index file

Use the following procedures to change the location of the index file.

Verify the name of the shared services provider

Note Note:

You must be a farm administrator to perform the following steps.

  1. In Central Administration, on the Application Management tab, in the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.

  2. On the Mange this Farm's Shared Services page, in the SSP and associated Web applications column, you can see the name of the shared services provider. Write this name down - you will need it in a later step.

Change the index file to a new location

Note Note:

You must be a member of the Administrators group on the index server to perform these steps.

Perform the following steps to change the index file location. Note that this procedure copies the index to the new location - it does not delete the content index in the original location. You can choose to delete the files in the original location later in this article.

  1. Log on to the index server as a member of the Administrators group.

  2. Open a command prompt.

  3. Type the following and then press ENTER to go to the folder that contains the stsadm.exe command-line utility.

    cd %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\bin

  4. Type the following and then press ENTER to move the content index to the new location.

    stsadm -o editssp -title sspname -indexlocation drive:\folder

    where sspname is the name of the shared services provider that is associated with the content index.

    drive:\folder is the new location to which you want to move the content index.

    Important Important:

    The -indexlocation property must refer to an NTFS partition on a hard drive or SAN that is attached to the index server.

  5. After the command prompt displays "Operation completed successfully" proceed to the next step.

(Optional) Delete the content index from the original location.

You can choose to delete the content index from the original location. To do so, use Windows Explorer to delete the original file location.

Resume crawls and restore

If you paused crawls earlier, you can now resume those crawls. For more information, see Pause and resume a crawl (Search Server 2008).

Note Note:

When resuming a crawl, if the "Crawling might be paused because a backup or an index move operation is in progress" dialog box appears, click OK to continue.

Restore crawl schedules

If you removed any crawl schedules earlier, you can recreate them now. For more information, see Schedule a full crawl (Search Server 2008) and Schedule an incremental crawl (Search Server 2008).

You can start new incremental crawls after the index is moved. You are not required to perform full crawls.


View the content index location for a query server (Search Server 2008)
DropDown image

Updated: 2008-10-30

Note Note:

This article applies to Microsoft Search Server 2008 only. It does not pertain to Microsoft Search Server 2008 Express.

This article explains how to view the location of the content index for a query server. This is the location on the query server to which the content index continually propagates from the index server. You might want to check this location, for example, to determine whether it provides enough disk space to accommodate the propagated index. For more information, see View or change content index locations (Search Server 2008).

Note Note:

To perform the following procedure, you must be a search services administrator and a member of the Administrators group on the local computer. For more information, see Add or remove a search services administrator (Search Server 2008).

To view the location of the content index for a query server

Use this procedure to view the location of the content index on any query server that is on a separate computer from the index server.

View the location of the content index for a query server

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Services on server.

  2. On the Services on Server page:

    1. If the server name that appears is not the query server that you want to view, click the arrow next to the server name, click Change Server, and then click the appropriate query server.

    2. In the Start services in the table below section, click Office SharePoint Server Search.

  3. On the Configure Office SharePoint Server Search Service Settings page, in the Query Server Index File Location section, you can view the current propagation location setting for the content index on that query server.

  4. To return to the Services on Server page, click OK.

See Also

Concepts

Plan to deploy Search Server 2008 or Search Server 2008 Express
Add query servers to expand a farm (Search Server 2008)


Change the content index location for a query server (Search Server 2008)
DropDown image

Updated: 2009-06-04

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

This article describes how to change the location of the content index that is saved to the file system of a query server. The content index continually propagates from the index server to each query server in the farm. After you assign the query server role to a server, you may want to change the location of the content index that is propagated to the query server for one of the following reasons:

  • You want to use a different drive than the default content index location.

  • You have added a hard disk drive or storage area network (SAN) to store the content index for this query server.

  • You discover that the location that you chose has insufficient available disk space.

Note Note:

Do not perform this procedure if the query server role is deployed to the same server that hosts the index server role. In this case the index server recognizes that the query server role is located on the same server. It does not attempt to propagate the content index to other query servers and the setting configured in this procedure is not used.

Important Important:

To perform this procedure, you must be a farm administrator.

Change the location of the content index on a query server

Use this procedure to change the location of the content index on the file system of a query server.

Change the location of the content index on a query server

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Services on server.

  2. On the Services on Server page:

    1. If the server name that appears is not the query server that you want to view, click the arrow next to the server name, click Change Server, and then click the appropriate query server.

    2. In the Start services in the table below section, click Office SharePoint Server Search.

  3. On the Configure Office SharePoint Server Search Service Settings page, in the Query Server Index File Location section, type the path of the new location for the content index in the Query server index file location box. This path can be a local or a mapped drive.

  4. The location in the Query server index file location must be shared to allow the index server to propagate the content index to it. Depending on how you want to configure the share, select one of the following choices:

    • If the location in the Query server index file location is not configured as a share, click Configure share automatically. In the User name box, type the name of a user account that is a member of the Administrators group on this query server. In the Password box, type the password of the user account named in the User name box.

    • Select I will configure the share with STSAdm, if you want to change the path of the content index using the Stsadm command-line tool with the Osearch operation and the propagationlocation parameter. For more information, see Osearch: Stsadm operation (Office SharePoint Server). This operation shares the location and gives the search service account write permission to the share.

    • Select Do nothing. The share is already configured if the location for the content index is already shared and the search service account has write access to that share.

  5. To save the changes and return to the Services on Server page, click OK.

See Also

Concepts

View or change content index locations (Search Server 2008)
View the content index location for the index server (Search Server 2008)
Change the content index location for the index server (Search Server 2008)
View the content index location for a query server (Search Server 2008)


Operations for Search Server 2008
DropDown image

Updated: 2008-03-03

This topic provides links to topics that help you to get started with crawling content and federation in Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Crawl content

Before users can use the enterprise search functionality in Search Server 2008 to search for content, the content must first be crawled so that it is available for users to query. Content is any item that can be crawled, such as a Web page, a Microsoft Office Word document, or a SharePoint site. For more information, see How to crawl content (Search Server 2008).

The following topics provide information on specific tasks when crawling content:

  • Preparing to crawl content (Search Server 2008) — Prepare to crawl content after you have identified the content sources.

  • Crawl content (Search Server 2008) — Set up full and incremental crawls, and then schedule them to occur automatically.

  • Limit or increase the quantity of content that is crawled (Search Server 2008) — Update the quantity of content being crawled by using crawl rules, crawl settings in content sources, and file type inclusions.

  • Manage crawler impact (Search Server 2008) —Add or edit crawler impact rules to reduce the load on servers that are being crawled and improve response time for users of that server.

  • Configure how the crawler authenticates (Search Server 2008) — Specify or change a content access account for the crawler to authenticate to servers that hosts content.

  • Install protocol handlers (Search Server 2008) — Install and configure the protocol handler to crawl Lotus Notes.

Federation

Federation enables users to issue a query that searches multiple sources and displays results in separate Web Parts on a single search results page. For more information, see Working with federation (Search Server 2008).


Permissions for common administrative operations (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

The information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Search Server 2008 has several levels of search administration:

  • Server administrator

  • Farm administrator

  • SSP administrator

  • Site collection administrator

  • Site administrator

You can download a poster, Permissions for common administrative operations, which provides information about operations and permissions for each of these administrative levels. To download, right-click the link, click Save Target As, navigate to a directory to which to download the file, and then click Save. If you do not have Microsoft Office Visio 2007 installed, you can view the file by installing the free Visio 2007 Viewer (http://go.microsoft.com/fwlink/?LinkID=118761).

Note Note:

This poster does not address site administrator permissions because operations at the site administrator level need not be performed by IT professionals. Such operations can be performed by information workers.


How to crawl content (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Before end users can use the enterprise search functionality in Microsoft Search Server 2008 to search for content, you must first crawl the content that you want to make available for the end users to query. For the purpose of this article, content is an item that can be crawled, such as a Web page, a Microsoft Office Word document, or a SharePoint site.

This article describes the basic process needed to get started crawling content and gives you links to articles that can help you by providing more information and procedures.

  1. Create a content source A content source defines the type of repository that contains the content you want to crawl, the start addresses from which to start crawling, the behavior to use when crawling, and the crawling schedule. For information about creating a content source, see About content sources (Search Server 2008) and Add a content source to crawl SharePoint sites, Web sites, file shares, or Microsoft Exchange Server public folders (Search Server 2008).

  2. Specify the credentials to use when crawling all URLs or a specific range of URLs By default, the default content access account uses Windows domain user credentials to crawl the content repositories that are defined by content sources. You can use a crawl rule to specify a different content access account, which can be a client certificate, forms credentials, a cookie, or a different content access account. For information about setting the default content access account, see Change the default content access account (Search Server 2008). For information about using a crawl rule, see Use crawl rules to determine what content gets crawled (Search Server 2008).

  3. Configure proxy server settings for search When you crawl content that is hosted outside your network, you probably set up a proxy server to reach the host server. In this case, it is important to verify the settings for the proxy server and configure them in Search Server 2008. To do this, on the Search Administration page, under Crawling, click Proxy and timeouts. Usually, you only need to set this option once.

  4. Start a full crawl You can begin by crawling small amounts of content defined in a particular content source to test your setup configuration. After you have a small amount of content working, increase your criteria to build your index. For information about starting a full crawl, see Start a full crawl (Search Server 2008).

  5. View the crawl log During the crawl, we recommend that you view the crawl log to check on its progress. This allows you to confirm that the crawl is successful or to detect problems. Common problems are that the authorization fails or that the host is unreachable. When you see problems in the log file, you can stop the crawl, adjust the settings on the Manage Content Sources, Manage Crawl Rules, and Manage Farm-Level Search Settings pages, and then try the crawl again. If you encounter problems with federated locations, see Repair federated locations (Search Server 2008).

See Also

Concepts

Plan to crawl content (Search Server 2008)
Operations for Search Server 2008


Preparing to crawl content (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

During the indexing process, content items are accessed and read by the crawler. The process of extracting the information from these files results in a content index that is located in the file system of the index server and a Search database that is located in the database used by Search Server 2008. User search queries are run against this content index and the Search database. The articles in this section describe the default settings that are used by the crawler and what you can do to aid the crawling process and produce better search results for users.

  • Add content sources (Search Server 2008). Content sources define what content to crawl, how to access the content, and how to behave when crawling that content.

  • About content sources (Search Server 2008). You can specify settings that define when content is crawled and crawl behavior, such as how deep to crawl within a Web site or how many server hops are allowed.

  • IFilters and protocol handlers (Search Server 2008). Search Server installs with the ability to read and index a specific set of file types. This initial list of file types can be increased by installing and registering additional IFilters.

See Also

Concepts

Plan to crawl content (Search Server 2008)


Add content sources (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

A content source is a set of rules that tells the crawler where it can find content, how to access the content, and how to behave when it is crawling the content. The settings that you specify apply to all addresses in the content source. A content source includes a set of addresses that connect the indexing engine to the content that you want to crawl. Search Server 2008 has one Shared Services Provider (SSP) that can support up to 500 content sources.

This section contains the following articles:

  • About content sources (Search Server 2008)

  • Add a content source to crawl SharePoint sites, Web sites, file shares, or Microsoft Exchange Server public folders (Search Server 2008)

  • Configure searches to return blog post results (Search Server 2008)

  • Configure client certificates for crawling an SSL site (Search Server 2008)

See Also

Concepts

Preparing to crawl content (Search Server 2008)
IFilters and protocol handlers (Search Server 2008)


About content sources (Search Server 2008)
DropDown image

Updated: 2009-04-28

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Content is any item that can be crawled, such as a Web page, a Microsoft Office Word document, business data, or an e-mail message. Content resides in a content repository, such as a Web site, file share, or SharePoint site. A content source specifies settings that define how and on what schedule content is crawled. It includes one or more addresses of a content repository from which to start crawling, also named start addresses. These settings apply to all start addresses within the whole content source.

Default content source

If your organization has to crawl only the content that is contained in the SharePoint sites, you might not have to create an additional content source. Search Server 2008 defines a default content source during its initial deployment. The default content source is named Local Office SharePoint Server sites. The start addresses of all Web applications in the server farm are automatically included as part of the default content source. This content source is not crawled, by default. To index the content in the default content source, you have to either manually start or schedule crawls for it.

Creating a new content source

When you create a content source, you specify settings that define the kind of content it crawls, when the content is crawled, and crawling behavior, such as how deep to crawl within the namespace of the start address or how many server hops to allow. If you have multiple kinds of content repositories that you want to crawl, or you want crawl some content repositories on different schedules, you have to create additional content sources. Search Server has one Shared Service Provider (SSP) that supports up to 500 content sources. For more information, see the "Plan content sources" section of Plan to crawl content (Search Server 2008). For more information about how to configure crawling behavior, see Limit or increase the quantity of content that is crawled (Search Server 2008).

Types of content repositories

You can crawl only one kind of content per content source. That is, you can create a content source that contains URLs for SharePoint sites and another that contains URLs for file shares. But you cannot create a single content source that contains URLs for both SharePoint sites and file shares.

The following table lists the kinds of content that Search Server can crawl and index:

This kind of content source Includes this kind of content

SharePoint sites

  • SharePoint sites from the same farm or different Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0, or Search Server 2008 farms

  • SharePoint sites from Microsoft Office SharePoint Portal Server 2003 or Microsoft Windows SharePoint Services 2.0 farms

    Note Note:

    The Search Server 2008 crawler can automatically crawl all Office SharePoint Server 2007, Windows SharePoint Services 3.0, and Search Server 2008 sites and subsites. The crawler can crawl previous versions of SharePoint products and technologies. But you must specify the URL of each top-level site (site collection) and each subsite that you want to crawl.

    Sites listed in the Site Directory of Microsoft Office SharePoint Portal Server 2003 farms are crawled when the portal site is crawled. For more information about the Site Directory, see About the Site Directory (http://go.microsoft.com/fwlink/?LinkId=88227).

Web sites

  • Web content within your organization not found on SharePoint sites

  • Content on Web sites on the Internet

    Note Note:

    The crawler behaves in the same manner when it uses the Web sites content type or the SharePoint sites content type. Only the crawl settings that you can configure for these content source types differ.

File shares

  • Content on file shares within your organization

Exchange public folders

  • Microsoft Exchange Server content

Lotus Notes

  • Content stored in Lotus Notes databases

    Note Note:

    The Lotus Notes content source option does not appear in the user interface until you have configured the index server to work with Lotus Notes. For more information, see Prepare to crawl Lotus Notes (Search Server 2008).

Start address of content

Each content source maintains a list of start addresses that the crawler uses to connect to the repository of content. Each content source can contain up to 500 start addresses. You cannot crawl the same address using multiple content sources. For example, if you use a particular content source to crawl a site collection and all its subsites, you cannot use a different content source to crawl one of those subsites on a different schedule.

Crawling content

You can use a content source to manually start a crawl or schedule when and how often the selected content source is crawled. If you want to crawl content in a part of your content source on a different schedule, you must create a separate content source for that content. For performance and manageability reasons, we recommend that you use as few content sources as possible. For more information about starting a crawl manually or scheduling a crawl, see Crawl content (Search Server 2008).

Authentication

When the crawler accesses the start addresses listed in a content source, the crawler must be authenticated by and granted access to the servers that host that content. The user account that is used by the crawler must have at least read permission to crawl content. By default, Search Server uses the default content access account and uses NTLM when authenticating with servers. For more information, see Configure how the crawler authenticates (Search Server 2008).

See Also

Concepts

Plan to crawl content (Search Server 2008)
Configure searches to return blog post results (Search Server 2008)
Configure client certificates for crawling an SSL site (Search Server 2008)


Add a content source to crawl SharePoint sites, Web sites, file shares, or Microsoft Exchange Server public folders (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Important Important:

You must be a search services administrator to complete this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

Use the following procedure to create a content source for any of the following content source types in Microsoft Search Server 2008 or Microsoft SharePoint Products and Technologies:

  • SharePoint sites

  • Web sites

  • File shares

  • Microsoft Exchange Server public folders

Add content sources for SharePoint sites, Web sites, file shares, or Microsoft Exchange Server public folders

  1. In Central Administration, on the Application Management tab, in the Search section, click Manage search service.

  2. On the Search Administration page, under Crawling, click Content sources.

  3. On the Manage Content Sources page, click New Content Source.

  4. On the Add Content Source page, in the Name section, in the Name box, type a name for the content source.

  5. In the Content Source Type section, select the type of content you want to crawl by using this content source.

  6. In the Start Addresses section, in the Type start addresses below (one per line) box, type the URLs from which the search system should start crawling.

    Note Note:

    For performance reasons, you cannot add the same start addresses to multiple content sources.

  7. In the Crawl Settings section, select the behavior for the type of content you selected.

    For more information about the behaviors that you can select for different content source types, see Limit or increase the quantity of content that is crawled (Search Server 2008).

  8. In the Crawl Schedules section, you can specify when to start full and incremental crawls:

    • You can create a full crawl schedule by clicking the Create Schedule link below the Full Crawl list.

    • You can create an incremental crawl schedule by clicking the Create Schedule link below the Incremental Crawl list.

  9. Click OK.

  10. Repeat steps 4 through 9 for any additional content sources you want to create.


Configure searches to return blog post results (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Search Server 2008 can crawl and index blog Web sites so that users' queries include results from blog posts. By default, blogs that are in the default content source are automatically crawled and available for searches. Blog posts can also be added to existing Web site content sources. You can create a separate source for the blogs you want to index. When creating a content source there is no option specifically labeled for blogs. Search service administrators need only to select the Web sites option when they create a content source for blogs.

Important Important:

You must be a search service administrator to perform this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

To configure a search to return blog post results

Use this procedure to create a content source for Web sites that contain blogs.

Configure a search to return blog post results

  1. On the Search Administration page, under Crawling, click Content sources.

  2. On the Manage Content Sources page, click New Content Source.

  3. On the Add Content Source page, in the Name section, in the Name box, type the name that you want to use for the content source.

  4. In the Content Source Type section, click Web Sites.

  5. In the Start Addresses section, in the Type start addresses below (one per line) box, type the URLs of the blog Web sites that you want the search system to crawl.

    Note Note:

    For performance reasons, you cannot add the same start addresses to multiple content sources.

  6. In the Crawl Settings section, select the crawl behavior you want for this content source.

  7. In the Crawl Schedules section, specify when the crawler should perform full and incremental crawls of these sites.

  8. Click OK.

See Also

Concepts

Add content sources (Search Server 2008)
Add a content source to crawl SharePoint sites, Web sites, file shares, or Microsoft Exchange Server public folders (Search Server 2008)
IFilters and protocol handlers (Search Server 2008)
Configure client certificates for crawling an SSL site (Search Server 2008)


Configure client certificates for crawling an SSL site (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

When crawling content, the crawler uses NTLM for authentication, by default. Some content sources that you want to crawl may use Secure Sockets Layer (SSL) and require client certificates for authentication. A search service administrator can create a crawl rule to configure the crawler to use a client certificate, instead of NTLM, when crawling a particular URL or range of URLs. For more information about how to create and configure crawl rules, see Plan to crawl content (Search Server 2008).

Important Important:

You must be a search services administrator to perform this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

To configure client certificates for crawling an SSL site

Before performing this procedure, a server administrator must register the client certificate with the index server; otherwise, authentication fails and the content is not crawled. Use the following procedure to create a crawl rule that configures the crawler to use a client certificate when crawling a particular path. For more information about server certificates, see Server Certificate Deployment (http://go.microsoft.com/fwlink/?LinkId=144649).

Configure client certificates for crawling an SSL site

  1. On the Search Administration page, in the Crawling section, click Crawl Rules.

  2. On the Manage Crawl Rules page, click New Crawl Rule.

  3. On the Add Crawl Rule page, in the Path section, in the Path box, type the path of the content that requires the crawler to use SSL and client certificates.

  4. In the Crawl Configuration section, click Include all items in this path.

  5. In the Specify Authentication section, click Specify client certificate, and then on the Certificate list, click the certificate that you want to use.

  6. Click OK.

See Also

Concepts

Add content sources (Search Server 2008)
IFilters and protocol handlers (Search Server 2008)
Configure searches to return blog post results (Search Server 2008)
Plan to crawl content (Search Server 2008)
Configure how the crawler authenticates (Search Server 2008)


IFilters and protocol handlers (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

The crawler in Search Server 2008 uses protocol handlers to access content and then IFilters to extract content from files that are crawled. IFilters remove application-specific formatting before the engine indexes the content of a document. Only file types for which a protocol handler and IFilter are installed are crawled by Search Server.

This section describes the IFilters and protocol handlers that are included by default in a Search Server installation and describes how you can install and register additional IFilters and protocol handlers.

The crawler uses protocol handlers and IFilters as follows:

  1. The crawler retrieves the start addresses of content sources and calls the protocol handler based on the URL's prefix.

  2. The protocol handler connects to the content source and extracts system-level metadata and access control lists information.

  3. The protocol handler identifies the file type of each content item, based on the file name extension, and calls the appropriate IFilter associated with that file type.

  4. The IFilter extracts content, removing any embedded formatting, and then retrieves content item metadata.

  5. Content is parsed by one or more language-appropriate word breakers and is added to the full-text index, also called the content index. Metadata and access control lists are added to the search database.

In this section:

  • About IFilters (Search Server 2008)

  • Install the Microsoft Filter Pack (Search Server 2008)

  • About protocol handlers (Search Server 2008)

See Also

Concepts

Add content sources (Search Server 2008)


About IFilters (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

The content that is contained in each file that is crawled must be stripped of formatting before it can be added to the content index. The formatting of a file depends on the application that created it. For example, a document created in Microsoft Office Word is in a different format than slides that are created in Microsoft Office PowerPoint. The Search Server 2008 indexing engine uses IFilters to remove embedded formatting from the content that is extracted from crawled items.

The following table summarizes the behavior of the indexing system depending on whether an IFilter is installed on the index server and whether the file type is listed on the Manage File Types page in Search Administration.

IFilter installed? | File type listed on the Manage File Types page? | Result
Yes | Yes | The content in the file and its properties are indexed.
No | Yes | The content in the file is not indexed but its properties are indexed.
No | No | Neither the content in the file nor its properties are indexed.

IFilters and file types

Each IFilter must be associated with the kind of file that it can filter. A file's type is identified by the three- or four-letter extension of the file name. You can view a list of file types for which Search Server has an IFilter installed on the Manage File Types page in Search Administration. If there is no IFilter for a file type that you want to crawl, the content index in Search Server can only include the file's properties, and not the file's content. If you want to index content that does not have an IFilter installed by default, you have to install and register an IFilter for that file type.

The following table lists the default settings on the Manage File Types page. This includes file types that are supported by an IFilter, but are not enabled, by default. Also, some file types are listed on the Manage File Types page that do not have IFilter support, by default. For information about how to update the Manage File Types page, see Specify file types to crawl (Search Server 2008).

File name extension | Default IFilter Support | Default file type inclusion
ascx | Yes | Yes
asm | Yes | No
asp | Yes | Yes
aspx | Yes | Yes
bat | Yes | No
c | Yes | No
cmd | Yes | No
cpp | Yes | No
css | Yes | No
cxx | Yes | No
def | Yes | No
dic | Yes | No
doc | Yes | Yes
docm | Yes | Yes
docx | Yes | Yes
dot | Yes | Yes
eml | Yes | Yes
exch | No | Yes
h | Yes | No
hhc | Yes | No
hht | Yes | No
hpp | Yes | No
hta | Yes | No
htm | Yes | Yes
html | Yes | Yes
htw | Yes | No
htx | Yes | No
jhtml | No | Yes
jsp | No | Yes
lnk | Yes | No
mht | Yes | Yes
mhtml | Yes | Yes
mpx | Yes | No
msg | Yes | Yes
mspx | No | Yes
nsf | No | Yes
odc | Yes | Yes
one | No | No
php | No | Yes
pot | Yes | No
pps | Yes | No
ppt | Yes | Yes
pptm | Yes | Yes
pptx | Yes | Yes
pub | Yes | Yes
stm | Yes | No
tif | Yes | Yes
tiff | No | Yes
trf | Yes | No
txt | Yes | Yes
url | No | Yes
vdx | No | Yes
vsd | No | Yes
vss | No | Yes
vst | No | Yes
vsx | No | Yes
vtx | No | Yes
xlb | Yes | No
xlc | Yes | No
xls | Yes | Yes
xlsm | Yes | Yes
xlxs | Yes | Yes
xlt | Yes | No
xml | Yes | Yes
Note Note:

IFilters that enable Office SharePoint Server 2007 to index Adobe Portable Document Format (PDF) are provided by Adobe. For more information about installing and configuring these IFilters, see Icons are not displayed for Adobe PDF documents that are listed in the search results when you search your portal site in SharePoint Portal Server 2003 or in SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=144596&clcid=0x409).

Microsoft Filter Pack

Microsoft provides a filter pack that contains a set of IFilters that are in addition to the IFilters that install automatically with Search Server 2008. The Microsoft Filter Pack installs and registers IFilters for the following file formats: .docx, .docm, .pptx, .pptm, .xlsx, .xlsm, .xlsb, .zip, .one, .vdx, .vsd, .vss, .vst, .vdx, .vsx, and .vtx.

For more information, see Install the Microsoft Filter Pack (Search Server 2008).

Custom filters

If you have to crawl documents that are of a file type that is not supported by an IFilter provided with Search Server or included in the Microsoft Filter Pack, you must install the appropriate IFilter on the index server. Check with the company that created the application to see whether it has an IFilter for Microsoft search products. If the application was created within your own organization, the software developers who created or maintain the application can create an IFilter for it. For more information, see Microsoft Search Server 2008 Software Development Kit (SDK) (http://go.microsoft.com/fwlink/?LinkId=141179).

After you install the IFilter, you must also register the IFilter with the operating system and associate it with the kind of file that it can process. The installation and registration steps are different for each IFilter. Read the IFilter's documentation for more information.

See Also

Concepts

Install the Microsoft Filter Pack (Search Server 2008)
About protocol handlers (Search Server 2008)


Crawl more file types by installing IFilters (Search Server 2008)
DropDown image

Updated: 2008-09-11

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Content is only crawled if the relevant file name extension is included in the file-type inclusions list and an IFilter is installed on the index server that supports those file types. Several file types are included automatically during initial installation. When you plan for content sources in your initial deployment, determine whether content you want to crawl uses file types that are not included. If file types are not included, you must add those file types on the Manage File Types page during deployment and ensure that an IFilter is installed and registered to support that file type.

Search Server 2008 provides several IFilters, and more are available from Microsoft and third-party vendors. If necessary, software developers can create IFilters for new file types. For more information about how to install and register additional IFilters that are available from Microsoft, see How to register Microsoft Filter Pack with SharePoint Server 2007 and with Search Server 2008 (http://go.microsoft.com/fwlink/?LinkId=110532).

On the other hand, if you want to exclude certain file types from being crawled, you can delete the file name extension for that file type from the file type inclusions list. Doing so excludes file names that have that extension from being crawled.

The following table lists which file types are supported by the IFilters that are installed by default and which file types are enabled on the Manage File Types page by default.

File name extension | Default IFilter support | Default file type inclusions
ascx | Yes | Yes
asm | Yes | No
asp | Yes | Yes
aspx | Yes | Yes
bat | Yes | No
c | Yes | No
cmd | Yes | No
cpp | Yes | No
css | Yes | No
cxx | Yes | No
def | Yes | No
dic | Yes | No
doc | Yes | Yes
docm | Yes | Yes
docx | Yes | Yes
dot | Yes | Yes
eml | Yes | Yes
exch | No | Yes
h | Yes | No
hhc | Yes | No
hht | Yes | No
hpp | Yes | No
hta | Yes | No
htm | Yes | Yes
html | Yes | Yes
htw | Yes | No
htx | Yes | No
jhtml | No | Yes
jsp | No | Yes
lnk | Yes | No
mht | Yes | Yes
mhtml | Yes | Yes
mpx | Yes | No
msg | Yes | Yes
mspx | No | Yes
nsf | No | Yes
odc | Yes | Yes
one | No | No
php | No | Yes
pot | Yes | No
pps | Yes | No
ppt | Yes | Yes
pptm | Yes | Yes
pptx | Yes | Yes
pub | Yes | Yes
stm | Yes | No
tif | Yes | Yes
tiff | No | Yes
trf | Yes | No
txt | Yes | Yes
url | No | Yes
vdx | No | Yes
vsd | No | Yes
vss | No | Yes
vst | No | Yes
vsx | No | Yes
vtx | No | Yes
xlb | Yes | No
xlc | Yes | No
xls | Yes | Yes
xlsm | Yes | Yes
xlsx | Yes | Yes
xlt | Yes | No
xml | Yes | Yes

IFilters and Microsoft Office OneNote

An IFilter is not provided for the .one file name extension used by Microsoft Office OneNote. If you want users to be able to search content in Office OneNote files, you must install an IFilter for OneNote. To do this, you must do one of the following.

  • Install the Microsoft Office OneNote 2007 client application on the index server.

    The IFilter provided by Office OneNote 2007 can be used to crawl both Office OneNote 2003 and Office OneNote 2007 files. The IFilter installed by Office OneNote 2003 can crawl Office OneNote 2003 files only.

  • Install and register the Microsoft Filter Pack.

    The OneNote IFilter provided by this filter pack can be used to crawl Office OneNote 2007 files only. For more information, see How to register Microsoft Filter Pack with SharePoint Server 2007 and with Search Server 2008 (http://go.microsoft.com/fwlink/?LinkId=110532).


Install the Microsoft Filter Pack (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This article describes how to install the Microsoft Filter Pack and configure Search Server 2008 to recognize and use the IFilters contained in the pack. IFilters are used by Search Server to index the contents of content items it crawls. The Microsoft Filter Pack includes IFilters for the following formats: .docm, .docx, .one, .pptm, .pptx, .xlsb, .xlsm, .xlsx, .vdx, .vsd, .vss, .vst, .vsx, .vtx, and .zip.

A file type can be crawled by Search Server if the IFilter is installed and associated with the appropriate file type on the index server and the file type is listed in the Manage File Types page. Some of the file types in the Microsoft Filter Pack are already listed in the Manage File Types page even though they do not have IFilter support, by default. Also, some of the file types are already associated with the IFilter on the index server. The procedure in this article specifies which IFilters need to be added to the Manage File Types page and which need to be associated with the appropriate file types on the index server.

Important Important:

You must be a member of the Administrators group on the index server and a member of the Farm Administrators group in Search Server to perform this procedure.

To install the Microsoft Filter Pack

Use this procedure to install the Microsoft Filter Pack on the index server.

Install the Microsoft Filter Pack

  1. Download and install the Microsoft Filter Pack.

    1. Download the Microsoft Filter Pack. For more information, see 2007 Office System Converter: Microsoft Filter Pack (http://go.microsoft.com/fwlink/?LinkID=120247&clcid=0x409).

    2. If the index server is running a 64-bit operating system, download FilterPackx64.exe. If the index server is running a 32-bit operating system, download FilterPackx86.exe.

    3. After the download is complete, double-click FilterPackx64.exe or FilterPackx86.exe to begin the installation. When prompted, click Run. The Microsoft Filter Pack Setup Wizard starts.

    4. Click Next.

    5. Read the end-user license agreement, and then select I accept the terms in the License Agreement to continue.

    6. After the installation completes, click OK.

  2. Add file types included in the Microsoft Filter Pack to the Manage File Types page.

    1. On the Search Administration page, on the Quick Launch, in the Crawling section, click File types.

    2. On the Manage File Types page, click New File Type.

    3. On the Add File Types page, type the file name extension for the file type that you want to add in the File extension box. Do not include the period (.) character.

    4. Click OK.

    5. Continue to add new file types for each extension that you want to add to the Manage File Types page.

  3. Associate file types with IFilters.

    Important Important:

    The IFilters for .docx, .pptm, .pptx, .xslm, .xslx, and .xlsb associate with these file types on the index server automatically. For these file types, this step is not needed.

    Warning Warning:

    Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

    1. Click Start, click Run, type regedit, and then click OK.

    2. In Registry Editor, expand and select the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\ registry subkey. The file types are listed in the left-hand pane under this subkey.

    3. On the Edit menu, point to New, and then click Key. Type the three or four letter file name extension that identifies the file type, such as .one, and then press ENTER. Be sure to include the period character in the file name extension.

    4. In the right-hand pane, right-click the registry entry that you created in the previous step, and then click Modify. The Edit String dialog box appears. Copy the GUID for that file type, from the table in the next step and paste the GUID value into the Value data box, and then click OK.

    5. Continue the two previous steps to add subkeys from the following table for the file types that you want to associate to an IFilter:

    File name extension GUID

    .zip

    {20E823C2-62F3-4638-96BD-90F4F6784EBC}

    .one

    {B8D12492-CE0F-40AD-83EA-099A03D493F1}

    .vsd

    {FAEA5B46-761B-400E-B53E-E805A97A543E}

    .vss

    {FAEA5B46-761B-400E-B53E-E805A97A543E}

    .vst

    {FAEA5B46-761B-400E-B53E-E805A97A543E}

    .vdx

    {FAEA5B46-761B-400E-B53E-E805A97A543E}

    .vsx

    {FAEA5B46-761B-400E-B53E-E805A97A543E}

    .vtx

    {FAE5B46-761B-400E-B53E-E805A97A543E}

  4. Restart the Office SharePoint Server Search service.

    1. Open an elevated Command Prompt window. To do this in Windows Server 2008, click Start, right-click Command Prompt, and then click Run as administrator.

    2. At the command prompt, type net stop osearch, and then press ENTER.

    3. At the command prompt, type net start osearch, and then press ENTER.

    4. Type exit, and then press ENTER to exit the command prompt.

  5. Click OK. A full crawl is required to add the data from the content items that are of the newly associated file types.

See Also

Concepts

IFilters and protocol handlers (Search Server 2008)
About IFilters (Search Server 2008)
About protocol handlers (Search Server 2008)
Start a full crawl (Search Server 2008)


About protocol handlers (Search Server 2008)
DropDown image

Updated: 2009-04-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

The crawler uses protocol handlers to access content. When creating a content source, search service administrators specify the protocol handler that the crawler will use when crawling the URLs specified in that content source. Search Server 2008 provides protocol handlers for all common Internet protocols. The following table shows the protocol handlers that are installed by default.

Protocol handler | Used to crawl
File | File shares
http | Web sites
https | Web sites over Secure Sockets Layer (SSL)
Notes | Lotus Notes databases
Rb | Exchange public folders
Rbs | Exchange public folders over SSL
Sps | People profiles from Windows SharePoint Services 2.0 server farms
Sps3 | People profiles of Windows SharePoint Services 3.0 server farms only
Sps3s | People profiles from Windows SharePoint Services 3.0 server farms only over SSL
Spsimport | People profile import
Spss | People profile import from Windows SharePoint Services 2.0 server farms over SSL
Sts | Windows SharePoint Services 3.0 root URLs (internal protocol)
Sts2 | Windows SharePoint Services 2.0 sites
Sts2s | Windows SharePoint Services 2.0 sites over SSL
Sts3 | Windows SharePoint Services 3.0 sites
Sts3s | Windows SharePoint Services 3.0 sites over SSL
Note Note:

The notes:// protocol handler is installed, but not enabled, by default. For information about how to enable this protocol handler, see Configure Search Server to crawl Lotus Notes (Search Server 2008).

If you want to crawl content that does not have a protocol handler installed, you must install a third-party or custom protocol handler before you can crawl that content. Several third-party protocol handlers, with accompanying installation instructions, are available for Search Server. Check with the third-party manufacturer for instructions when you install third-party protocol handlers.

Crawling content from enterprise content management systems

Search Server has connectors that enable it to connect to and index content from other enterprise content management systems. Since the content is indexed into a Search Server content index, users can search and get results from these content sources by using the SharePoint search user interface.

Enterprise Search Indexing Connector 2008 for EMC Documentum

The Microsoft Enterprise Search Indexing Connector 2008 for EMC Documentum includes a protocol handler that enables Search Server to index content from EMC Documentum content sources. This connector also allows metadata to be indexed for advanced searches. Users can perform searches and review search results from the SharePoint search user interface.

For information about installing and administering this protocol handler, see the Microsoft Enterprise Search Indexing Connector for EMC Documentum Installation and Administration Guide (http://go.microsoft.com/fwlink/?LinkID=113947&clcid=0x409). For information about system requirements and additional configuration considerations, see the Microsoft Enterprise Search Indexing Connector 2008 for EMC Documentum Release Notes (http://go.microsoft.com/fwlink/?LinkId=113951&clcid=0x409). For information about known issues, see Microsoft Enterprise Search Indexing Connector 2008 for EMC Documentum Known Issues (http://go.microsoft.com/fwlink/?LinkId=119736&clcid=0x409).

Enterprise Search Indexing Connector 2008 for IBM FileNet

The Enterprise Search Indexing Connector 2008 for IBM FileNet enables Microsoft enterprise search systems to index the contents of an IBM FileNet repository. Once indexed, this connector also allows IBM FileNet search results to be displayed for users from within the Microsoft enterprise search system. These capabilities are based on the connector's ability to natively access the appropriate file formats, data structures, and security implementation of the IBM FileNet document management system. This protocol handler also integrates metadata for advanced searches.

For information about installing and administering this protocol handler, see the Microsoft Enterprise Search Indexing Connector for IBM FileNet Installation and Administration Guide (http://go.microsoft.com/fwlink/?LinkId=113952&clcid=0x409). For information about system requirements and additional configuration options, see the Microsoft Enterprise Search Indexing Connector 2008 for IBM FileNet Release Notes (http://go.microsoft.com/fwlink/?LinkId=120643&clcid=0x409). For information about known issues, see Microsoft Enterprise Search Indexing Connector 2008 for IBM FileNet Known Issues (http://go.microsoft.com/fwlink/?LinkId=119737&clcid=0x409).

See Also

Concepts

Configure Search Server to crawl Lotus Notes (Search Server 2008)
IFilters and protocol handlers (Search Server 2008)
About IFilters (Search Server 2008)
Install the Microsoft Filter Pack (Search Server 2008)


Install protocol handlers (Search Server 2008)
DropDown image

Updated: 2009-04-02

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

All crawled content requires the use of a protocol handler to gain access to that content. Microsoft Office SharePoint Server 2007 for Search provides protocol handlers for all common Internet protocols, such as HTTP, and HTTPS. However, if you want to crawl content that requires a protocol handler that is not installed with Search Server 2008, you must install the third-party or custom protocol handler before you can crawl that content. Check with the third-party manufacturer for instructions when installing third-party protocol handlers.

The following protocols are supported by the default protocol handlers: file, http, https, rb, rbs, sps, sps3, sps3s, spsimport, spss, sts, sts2, sts2s, sts3, sts3s, and notes.

Note Note:

The notes:// protocol handler is installed, but not enabled, by default. For information about enabling this protocol handler, see Configure Search Server to crawl Lotus Notes (Search Server 2008).

To install a protocol handler, refer to the procedure in the following topic:

Configure Search Server to crawl Lotus Notes (Search Server 2008)


Configure Search Server to crawl Lotus Notes (Search Server 2008)
DropDown image

Updated: 2009-10-22

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Microsoft Search Server 2008 enables search services administrators to crawl Lotus Notes documents that are stored in Lotus Domino databases and hosted by a Lotus Domino server. Search Server 2008 enables search services administrators to configure an index server to crawl one or more Lotus Domino databases on one Lotus Domino server.

This article helps you gain an understanding of the prerequisites you need, the decisions you must make, and the information you must gather from the Domino administrator to accomplish the procedures listed in Prepare to crawl Lotus Notes (Search Server 2008).

In this article:

  • About this article

  • Prerequisites

  • OSearch service and the Lotus Notes user ID

About this article

This article assumes the following:

  • A 32-bit version of Search Server 2008 is installed on the index server and the Office SharePoint Server Search service is running.

Caution Caution:

You cannot use the 64-bit version of Search Server 2008 to crawl Lotus Notes because the Lotus C++ API Toolkit is available only in a 32-bit version. Attempting to perform the procedures described in Prepare to crawl Lotus Notes (Search Server 2008) using a 64-bit version of Search Server 2008 will result in the Lotus Notes client application crashing when configuring the system. The index server can, however, have either a 64-bit or 32-bit version of Windows Server 2003 installed.

  • The Domino server that contains the Domino databases you want to crawl is running.

Prerequisites

This section discusses the items and information that must be available before you can perform the procedures provided in Prepare to crawl Lotus Notes (Search Server 2008).

Preparing your index server to crawl Lotus Notes content hosted by one or more Lotus Domino databases requires the involvement of the following types of administrators:

  • An administrator of the Lotus Domino server that you want to crawl

  • A server administrator of the index server from which you want to crawl Lotus Notes content

  • A search services administrator

Software requirements

Software requirements include:

  • The Lotus Notes client application, available for purchase from IBM.

    This table shows the supported Lotus Notes client and Domino server versions.

    Supported Domino Server Versions Supported Lotus Notes Client Versions

    5.5

    5.5

    6.0 or 5.5

    6.0

    6.5 or 6.0

    6.5

    7.0 or 6.5

    7.0

    7.5 or 7.0

    7.5

    8.0 or 7.5

    8.0

    Important Important:

    Because a 64-bit version of the Lotus C++ API is not available from IBM at the time of this writing, you must use the 32-bit version of the Lotus Notes client application.

  • Lotus C++ API Toolkit for Notes, available for free from the IBM software downloads page. For more information, see the "Download the Lotus C++ API Toolkit for Notes" section in Prepare to crawl Lotus Notes (Search Server 2008).

    Note Note:

    The Lotus Notes client application and the Lotus C++ API Toolkit for Notes work together to enable the protocol handler for accessing Lotus Notes databases.

Note Note:

You will need an IBM ID and password to sign onto the IBM download Web site. If you do not currently have an IBM ID, you can request one by using the IBM software Web site.

User accounts required to crawl Lotus Domino databases

A Domino administrator must grant a Lotus Notes user ID (which represents a Domino user) at least the Reader permission to the Lotus Domino databases and individual documents that the search services administrator wants to crawl. The Domino administrator must also add this Lotus Notes user ID and the Windows domain account that is assigned to the OSearch service to a mappings database on the Lotus Domino server that you want to crawl.

Note Note:

Only the account assigned to the OSearch service can be used to crawl Lotus Domino databases. You cannot use the default content access account or a crawl rule to specify a different account to crawl Lotus Domino databases.

The following table summarizes the accounts required to crawl Lotus Domino databases.

Required account Comment Example

Windows domain account

The account assigned to the OSearch service must also be a member of the Administrators group on the index server.

Contoso\User1, where Contoso is the domain name and User1 is the name of the Windows domain account.

Lotus Notes user ID

Must be granted at least Reader access on the Lotus Domino databases and on the individual documents that you want to crawl. The Domino certificate also contains this Lotus Notes user ID.

User2

Note Note:

The name of this account and its password do not need to match the Windows domain account. You will map the Windows domain account to this user ID later in Prepare to crawl Lotus Notes (Search Server 2008).

More information about this mappings table is provided later in this article.

OSearch service and the Lotus Notes user ID

The search services administrator must provide the Lotus Domino administrator with the Windows domain user account that is assigned to the OSearch service. The Domino administrator must then use the mappings database to map this Windows domain account to a Lotus Notes user ID. This Lotus Notes user ID is added to the Domino certificate that will be used to authenticate the crawler with the Lotus Domino servers.

Note Note:

Search services administrators cannot use a crawl rule to use a different content access account for crawling a Lotus Domino database. Only the Windows domain account assigned to the OSearch service can be used. Because of this, the same certificate must be used when crawling multiple Lotus Domino servers.

We recommend that you use the account that is already assigned to the OSearch service. The exception to this is if the account assigned to the OSearch service is a service account (such as Local Service) instead of a Windows domain account. In this case, you will need to change the service account to a Windows domain user account.

Use the following procedure to verify that the account assigned to the OSearch service is a Windows domain account.

Important Important:

You must be a farm administrator to perform the following procedure.

Verify OSearch service account

  1. In the SharePoint Central Administration Web site, on the Operations tab, in the Topology and Services section, click Services on server.

  2. Click Office SharePoint Server Search.

  3. On the Configure Office SharePoint Server Search Service Settings page, in the Farm Search Service Account section, ensure that a Windows domain user account is specified in the User name box. The user name must be in the form of domain\username.

    Important Important:

    If a Windows domain name is already selected, do not change it.

The Lotus Domino administrator must provide the Domino certificate to the server administrator of the index server. Note that the Lotus Notes user ID associated with this certificate must have at least Reader permissions on the following:

  • All Lotus Domino databases on the Domino server that you want to crawl.

  • All Lotus Notes documents within those databases that you want to crawl.

  • Each Lotus Domino mappings database that stores the mappings between the Lotus Notes user ID and Windows domain users.

Information provided by the Lotus Domino administrator

The following table describes the information that must be provided by the Domino administrator of the Lotus Domino server that hosts the Lotus Domino databases you want to crawl. This information is required to do the procedures provided in Prepare to crawl Lotus Notes (Search Server 2008).

Item Description

User name

User name of the Lotus Notes user ID in the Domino certificate.

Note Note:

This user name is case sensitive, for example, ContosoUser.

Password

Password for the user name that is associated with the Lotus Notes user ID in the Domino certificate.

Domino server name

Hierarchical name of the Lotus Domino server, for example, Contoso/marketing/west.

Note Note:

Domino server names use forward slashes instead of backward slashes.

Lotus Domino server's NetBIOS name or IP address

IP address or NetBIOS name of the Lotus Domino server, for example, 10.10.10.10 or Contoso.

Lotus Domino database names

Names of the Lotus Domino databases that you want to crawl.

Note Note:

Lotus Domino database names are case sensitive, for example, EngineeringSpecs.

Security considerations

One of the choices you must make when preparing an index server to crawl Lotus Notes is whether to ignore Lotus Domino security while crawling and indexing Lotus Domino databases. If you choose to do so, all Lotus Notes documents that are indexed appear on search results pages for all users of SharePoint sites.

Conversely, if you want the security trimming functionality of Search Server 2008 to filter search results based on the security that has been set on individual Lotus Notes documents, you must choose to recognize Lotus Domino security while indexing the content. Furthermore, the administrator of the Lotus Domino server must map the Windows domain accounts of SharePoint users to the Lotus Notes user IDs of the Domino users before the search services administrator crawls the Lotus Domino databases. This mapping is necessary because Windows domain accounts are not associated directly with Lotus Notes documents. However, Lotus Domino servers do provide a mechanism—sometimes called a mappings database—that an administrator of a particular Lotus Domino server can use to map Lotus Notes user IDs to Windows domain accounts.

Note Note:

The mappings database must be populated with the necessary user accounts before the content is crawled. If you add user accounts to the mappings database after crawling a Domino database, you must restart the OSearch service on the index server and start a full crawl of the affected Domino database. This enables the index server to cache an updated copy of the mappings database.

When a mappings database is used to map Windows domain accounts to Lotus Notes User IDs, end users who click a search result for a Lotus Notes file see a log on prompt. They must then enter their Lotus Notes user ID and password to access the file.

Note Note:

Blank passwords are not supported. Therefore, Lotus Notes users who have a Lotus Notes user ID with a blank password will not be able to view Lotus Notes files through search results pages.

Default security mapping

If you do not map Domino users to Windows users, Search Server 2008 attempts to authenticate using the default security mapping that is configured for the Domino database. To crawl Lotus Notes documents, the default security mapping must provide Reader access to the database and documents that you want to crawl.

Required security mappings

At a minimum, a Lotus Domino administrator must create a mappings database to map the Lotus Notes user ID in the Domino certificate to the Windows domain account.

To continue preparing to crawl Lotus Notes, perform the procedures shown in Prepare to crawl Lotus Notes (Search Server 2008).


Prepare to crawl Lotus Notes (Search Server 2008)
DropDown image

Updated: 2009-10-22

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Before you perform the procedures in this article, confirm that:

You have read the topic:

  • Configure Search Server to crawl Lotus Notes (Search Server 2008)

This article provides the procedures for preparing Microsoft Search Server 2008 to crawl Lotus Notes content. You must do the procedures in the order listed.

Important Important:

Some procedures in this article require the involvement of a Domino administrator of the Domino server that you want to crawl and other procedures require a server administrator of the index server.

This table shows the supported Lotus Notes client and Domino server versions.

Supported Domino Server Versions | Supported Lotus Notes Client Versions
5.5 | 5.5
6.0 or 5.5 | 6.0
6.5 or 6.0 | 6.5
7.0 or 6.5 | 7.0
7.5 or 7.0 | 7.5
8.0 or 7.5 | 8.0

Note Note:

For more information about Lotus Notes and Domino server configurations, see Supported Configurations of Notes and Domino 7.0 (http://go.microsoft.com/fwlink/?LinkId=132808).

In this article:

  • Add the Windows account assigned to the OSearch service to the Administrators group

  • Install the Lotus Notes client application

  • Grant permissions to the data folder

  • Configure the Lotus Notes client application

  • Verify access to the Lotus Domino database you want to crawl

  • Configure security mappings

  • Reboot the index server

  • Download the Lotus C++ API Toolkit for Notes

  • Register Lotus Notes with the index server

  • Restart the Office SharePoint Server Search service

  • Create a content source and crawl content

Add the Windows account assigned to the OSearch service to the Administrators group

For more information about adding a Windows domain account to a group, see "Add a member to a local group" in Windows Server 2003 Help.

Install the Lotus Notes client application

Use the following procedure to install the Lotus Notes client application on the index server in your server farm with which you want to crawl a Lotus Domino database. Note that this client application serves as a protocol handler and is used to configure the Notes.ini file, both of which are used by the crawler when crawling Lotus Domino databases.

Because a 64-bit version of the Lotus C++ API is not available from IBM, you must use the 32-bit version of the Lotus Notes client application.

Important Important:

You must be a server administrator of the index server to do the following procedure.

Install Lotus Notes

  1. Copy the Lotus Notes client application to the index server from which you want to crawl Lotus Notes documents.

  2. Start the Lotus Notes Installation Wizard.

  3. In the Welcome to the Installation Wizard for Lotus Notes dialog box, click Next.

  4. On the License Agreement page, select I accept the terms in the license agreement and then click Next to continue.

  5. On the Customer Information page, type a user name in the User Name box and the name of your organization in the Organization box, or accept the default settings, and then click Next.

  6. On the Installation Path Selection page, specify the path you want to use for the program and data files, or accept the default installation paths, and then click Next.

    Note Note:

    By default, program files are stored in the <SystemDrive>:\Program Files\lotus\notes\ folder and data files are stored in the <SystemDrive>:\Program Files\lotus\notes\data\ folder, where <SystemDrive> is the drive on which Lotus Notes is installed.

  7. On the Custom Setup page, select the program features you want to install on the local hard drive and then click Next.

    The following table shows the features and subfeatures that are required.

    Feature Subfeature

    Notes Client

    Client Help Files

    Domino Enterprise Connection Services (DECS)

    Domino Designer

    Designer Help

  8. On the Ready to Install the Program page, if you do not want Lotus Notes to be your default e-mail program, clear the selection Make Notes my default e-mail program.

  9. Click Install.

    The Installing Lotus Notes page shows the installation status.

  10. On the Install Wizard Completed page, click Finish.

Grant permissions to the data folder

Use the following procedure to grant Full Control permissions for the WSS_WPG group on the <SystemDrive>:\Program Files\Lotus\Notes\Data folder on the index server.

Important Important:

You must be a server administrator of the index server to do the following procedure.

Grant permissions to the data folder

  1. On the index server, click Start, point to All Programs, point to Accessories, and then click Windows Explorer.

  2. In Windows Explorer, go to the <SystemDrive>:\Program Files\Lotus\Notes\Data folder, where <SystemDrive> is the drive on which Lotus Notes is installed.

  3. Right-click the Data folder, and then click Sharing and Security.

  4. In the Properties dialog box, on the Security tab, click Add.

  5. In the Select the object names to select box, do one of the following, and then click OK:

    • If Search Server 2008 is installed on an Active Directory domain controller, type domain\WSS_WPG, where domain is the name of the domain associated with the domain controller.

    • If Search Server 2008 is installed on a server that is not an Active Directory domain controller, type server\WSS_WPG, where server is the NetBIOS name of the index server.

  6. In the Properties dialog box, in the Permissions for WSS_WPG section, select the Allow box in the Full control row and then click OK.

Configure the Lotus Notes client application

Use the following procedure to configure the Lotus Notes client application. Note that the configuration settings selected in this procedure are written to the Notes.ini file, which the crawler uses to discover how to connect to the Lotus Domino server.

To perform the following procedure, you must know the user name that is associated with the Domino certificate that you copied to the index server in the "Install Domino certificate" procedure. You also need to know the name of the Lotus Domino server that you want to crawl.

Note Note:

If you have previously performed any of the steps in the following procedure, some steps might appear out of sequence.

Configure Lotus Notes

  1. On the index server, click Start, point to All Programs, point to Lotus Applications, and then click Lotus Notes.

  2. On the Welcome page, click Next.

  3. On the User Information page, enter the user name associated with your Domino certificate in the Your name box.

  4. Enter the hierarchical name of the Domino server you want to crawl in the Domino server box, for example, Contoso/marketing/west.

  5. Ensure that I want to connect to a Domino server is selected, and then click Next.

  6. On the Notes ID File page, click Browse and then go to the location where the certificate is stored. Select your certificate click Open, and then click Next.

  7. Click Yes to copy the certificate to the specified location.

Note Note:

If you are not prompted for a Domino certificate, click Previous and ensure that you have entered the correct info.

  1. If a dialog box appears that informs you that you are not authorized to access the specified directory, click OK to close the dialog box. Note that this error is expected if the account you are logged in with does not have access to the mail folder on the Domino server.

  2. On the Instant Messaging Setup page, cancel the selection Setup instant messaging.

  3. Click Next.

  4. On the Additional Services page, click Next.

  5. In the Lotus Notes message box, click OK.

    The Lotus Notes Welcome screen appears.

  6. Leave the Lotus Notes client application open. You will need it for the next procedure.

Verify access to the Lotus Domino database you want to crawl

Use the following procedure to verify that the certificate you installed has access rights to the database that you want to crawl.

Verify access

  1. In Lotus Notes, click File, point to Database, and then click Open.

  2. In the Open Database dialog box, select the Lotus Domino server you want to connect to from the Server list.

  3. In the Database list, select the database that you want to connect to and then click Open.

  4. The documents that are contained by the database you selected are displayed in the Document Name section. This means that the index server has the necessary permissions to crawl these documents.

  5. Repeat steps 1 through 4 for each additional database you want to verify access permissions to.

  6. On the File menu, click Exit Notes.

Configure security mappings

The following table describes the items you will be asked to name when doing the following two procedures.

Item Comment

Mappings database name

Name of the Lotus Domino database used to map Lotus Notes user IDs to Windows domain accounts

Lotus Notes field name

Name of the field in the Lotus Domino database file used to store Lotus Notes user IDs.

Windows user field name

Name of the field in the Lotus Domino database file that is used to store Windows user names.

Form name

Name of the form that stores the Lotus Notes field name and Windows user field name fields.

View name

Name of the view for the form that stores the Lotus Notes user IDs to Windows user name mappings.

Note Note:

This name is case sensitive.

Create the mappings database

Use this procedure to create a mappings database using Domino Designer. You need only one mappings database for each forest of Domino servers that contain databases that you want to crawl.

The following procedure assumes you have a licensed copy of either version 6.0 or 6.5 of the Lotus Notes client application installed on the index server. The following procedure is based on version 6.5 of the Lotus Notes client application.

Important Important:

To perform this procedure, you must be an administrator on the index server and have at least Manager permissions on the Domino server you want to crawl.

Create mappings database

  1. On the index server, open Domino Designer.

  2. Click File, point to Database, and then click New.

  3. In the New Database dialog box, do the following:

    • Select the Domino server from the Server name list.

    • In the Title box, type a title for your new database.

      This content automatically populates the File Name box, appended with the .nsf file extension.

      Note that if the title you chose is more than eight characters in length, the file name will be truncated.

    • Enter the file name shown in the File Name box into the Mappings database name row.

    • Click OK to close the New Database dialog box.

  4. Click Create, point to Design, and then click Form.

  5. Click Create, and then click Field.

  6. In the Field dialog box, in the Name box, type a name for this field. Note that this field will be used to store the Lotus Notes user IDs. Enter the name you chose for this field in the Lotus Notes field name row.

  7. Close the dialog box to save the field.

  8. Click Create, and then click Field.

  9. In the Field dialog box, in the Name box, type a name for this field. Note that this field will be used to store the Windows domain user accounts. Enter the name you chose for this field in the Windows user field name row.

  10. Close the dialog box to save the field.

  11. Click File, click Save, and then do the following:

    • Enter a name for this form in the Save Form as box.

    • Enter the name you chose for this form in the Form name row.

    • Click OK to close the dialog box.

  12. On the Create menu, point to Design, and then click View.

  13. In the Create View dialog box, do the following:

    • Enter the name you want for this view in the View name box.

    • Enter the name you chose in the View name row. Note that this name is case sensitive.

    • Select Shared from the View type list.

    • Click OK to save the view.

  14. Open the view that you created in step 13.

  15. Create a column using the name you entered in the Lotus Notes field name row.

  16. On the Objects tab, select the column you created in step 10. In the bottom right pane, select Field and then select the field with the same name.

  17. Create a column using the name you entered in the Windows user field name row.

  18. On the Objects tab, select the column you created in step 12. In the bottom right pane, select Field and then select the field of the same name.

  19. Click File and then click Save to save the view and then close Domino Designer.

Add user accounts to the mappings database

The following procedure assumes you have a licensed copy of either version 6.0 or 6.5 of the Lotus Notes client application installed on the index server. The following procedure is based on version 6.5 of the Lotus Notes client application.

Tip Tip:

At a minimum, you must map the Lotus Notes user ID in the Domino certificate to the account you listed in the Search service row

Important Important:

You must be a server administrator of the index server and have at least Manager permissions on the Domino server to perform this procedure.

Add user accounts to the mappings table

  1. On the index server, open the Lotus Notes client application.

  2. Click File, point to Database, and then click Open.

  3. In the Open Database dialog box, do the following:

    • Select the Domino server from the Server name list. This name is listed in the Domino server name row.

    • Select the mappings database that you created earlier. The name of this database is listed in the Mappings database name row.

    • Click Open.

  4. In the left pane, select the view that you created for this database. This view name is listed in the View name row.

  5. Click Create, and then click the name of the form you created earlier. This form name is listed in the Form name row.

  6. In the form, in the field that you created to store the Lotus Notes user IDs, enter a Lotus Notes user ID that you want to map to a Windows domain account. Note that this field is case sensitive, for example, ContosoUser.

  7. In the field that you created to map to the Lotus Notes user IDs, enter the Windows domain account that you want to map to the Lotus Notes user ID that you entered in step 6. Note that this must be in the form of domain\user, for example, Contoso\user1.

  8. Click File and then click Save to save the document.

  9. Repeat steps 6 through 8 if you want to add additional mappings. Otherwise, go to step 10.

  10. When finished, save the form and then close the Lotus Notes client application.

Reboot the index server

You must reboot the index server before continuing to the next procedure.

Important Important:

After the index server reboots, do not open the Lotus Notes client application again. This is because the Lotus Notes client application might lock files that could cause the following procedures and crawling Lotus Domino databases to fail.

Download the Lotus C++ API Toolkit for Notes

Use the following procedure to download the Lotus C++ API Toolkit for Notes. This toolkit contains a .dll file that the crawler uses to access Lotus Notes databases.

Download the toolkit

  1. In your browser, go to the IBM software downloads page.

  2. In the IBM software downloads page, download the Lotus C++ API Toolkit 2.x & 3.x for Multiplatform self-extracting file.

    Note Note:

    We do not support the Lotus C++ API Toolkit for Notes/Domino 7.0 Multiplatform at this time.

  3. After downloading the toolkit, in Windows Explorer, go to the folder to which you downloaded the file and double-click the file. For release 2.x & 3.x of this toolkit, the filename is c55svna.exe.

  4. In the Lotus C++ API Release 3.0 for Domino and Notes 6.0 dialog box, click Finish and then click Yes.

  5. Copy the lcppn30.dll file from the c:\notescpp\lib\mswin32 folder to the <SystemDrive>:\Program Files\Microsoft Office Servers\12.0\Bin folder on the index server, where <SystemDrive> is the drive on which Search Server 2008 is installed.

Register Lotus Notes with the index server

Use the following procedure to register Lotus Notes with the operating system of the index server. This procedure must be done on the index server by a server administrator.

Register Lotus Notes

  1. On the index server, in Windows Explorer, go to the <SystemDrive>:\Program Files\Microsoft Office Servers\12.0\Bin folder, where <SystemDrive> is the drive on which Search Server 2008 is installed.

  2. Double-click NotesSetup.ex1e.

  3. On the Welcome to the Lotus Notes Index Setup Wizard page, click Next.

  4. In the Register Lotus Notes for use with Microsoft Office Server dialog box, do the following:

    • In the Location of the notes.ini file box, ensure that the correct path to your Notes.ini file is specified. The default path to this file is <SystemDrive>:\Program Files\lotus\notes\notes.ini, where <SystemDrive> is the drive on which Lotus Notes is installed.

    • In the Location of the Lotus Notes install directory box, ensure that the correct path to the Lotus Notes install directory is specified. The default path to this directory is <SystemDrive>:\Program Files\lotus\notes.

    • In the Password box, type the password for the user name that is associated with the Domino certificate. This password is listed in the Password row.

    • In the Confirm Password box, retype the password for the user name that is associated with the Domino certificate.

  5. We recommend that you leave the Ignore Lotus Notes security while building the index box unselected. If you choose to ignore Lotus Notes security, all Lotus Notes documents are crawled and indexed without security information. This means that these documents will appear on search results pages to all users of SharePoint sites.

    Note Note:

    Search Server 2008 does not use the Lotus Notes security information directly. To ensure that users of Search Server 2008 see only the Lotus Notes documents in search results that they are intended to see, the Domino administrator must use the mapping file to map Lotus Notes users to Windows domain users before the search services administrator crawls the Lotus Notes documents.

  6. Click Next.

  7. On the Specify Lotus Notes Owner Field to Windows User Name Mapping page, do the following:

    • In the Lotus Notes server name box, type the NetBIOS name or IP address of your Domino server. This is listed in the Lotus Domino server's NetBIOS name or IP address row.

    • In the Lotus Notes database file name box, type the file name of the Lotus Domino database that maps the Lotus Notes user IDs to Windows domain accounts. Be sure to include the .nsf file extension with this name, for example, Mappings.nsf.

    Important Important:

    This name is case sensitive.

    • In the View name box, type the view name of the Lotus Domino database that stores the Lotus Notes user IDs to Windows user name mappings.

    Important Important:

    This name is case sensitive.

    • In the Lotus Notes field name column title box, type the name of the column in the Lotus Notes database file used to store Lotus Notes user IDs.

    Important Important:

    This name is case sensitive.

    • In the Windows user name column title box, type the name of the column in the Lotus Notes database file used to store the Windows user accounts.

    Important Important:

    This name is case sensitive.

  8. Click Next.

  9. On the Completing the Lotus Notes Index Setup Wizard page, click Finish.

Restart the Office SharePoint Server Search service

The server administrator of the index server must restart the Office SharePoint Server Search (OSearch) service before a content source can be created to crawl Lotus Domino databases.

Important Important:

Do not use the Services on Server page on the SharePoint Central Administration Web site to restart this service. Doing so resets the content index, which requires the search services administrator to do a full crawl of all content to rebuild the index.

Restart the OSearch service

  1. On the index server, click Start, point to All Programs, point to Administrative Tools, and then click Services.

  2. In the Name column, double-click Office SharePoint Server Search.

  3. In the Office SharePoint Server Search Properties box, click Stop.

  4. After the service stops, click Start.

After the service starts, click OK, and then close the Services page.

Create a content source and crawl content

A search services administrator can now create one or more content sources to crawl Lotus Domino databases. The search services administrator must know the names of the Lotus Domino servers and databases you want to crawl to create the content sources.

Note Note:

You must create one content source for each Domino database that you want to crawl.

For more information about creating content sources, see About content sources (Search Server 2008) and Add a content source to crawl Lotus Notes (Search Server 2008).

You can download a third-party tool from CodePlex to help automatically manage content sources for crawling Lotus Notes databases.


Add a content source to crawl Lotus Notes (Search Server 2008)
DropDown image

Updated: 2009-04-02

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Important Important:

You must be a shared services administrator to complete this procedure.

Use the following procedure to create a content source of the IBM Lotus Notes content source type.

Important Important:

You must be a search services administrator to complete this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

Add a content source to crawl Lotus Notes

  1. On the Search Administration page, under Crawling, click Content sources.

  2. On the Manage Content Sources page, click New Content Source.

  3. On the Add Content Source page, in the Name section, in the Name box, type a name for the content source.

    Note Note:

    Each content source name must be unique.

  4. In the Content Source Type section, select Lotus Notes.

    Note Note:

    This option does not appear in the Content Source Type section until the protocol handler for Lotus Notes has been enabled and configured. For more information, see Install protocol handlers (Search Server 2008).

  5. In the Server, Database, and Properties section, select one of the following:

    • Select a server from the following list. Then, from the list, select the name of the Lotus Domino server you want to crawl.

      -or-

    • Enter a server name. Next, enter the name of the Lotus Domino server that you want to crawl.

  6. From the Select a Lotus Notes database to index list, select the name of the Lotus Notes database you want to crawl.

  7. In the Crawl Schedules section, you can specify the schedules you want for full and incremental crawls.

  8. If you want to perform a full crawl of this database immediately, in the Start Full Crawl section, select the Start full crawl of this content source box.

  9. Click OK.


FAQ: Crawling Lotus Notes (Search Server 2008)
DropDown image

Updated: 2008-03-03

Draft content - please comment
Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This article answers frequently asked questions about crawling Lotus Notes databases, as follows:

  • What is the purpose of the Lotus Notes user ID file?

  • What metadata in a Domino database is indexed?

  • Where is the MissingIdLog.txt file located and what is its use?

  • What type of changes would require me to run NotesSetup again?

  • What does NotesSetup capture and store from the Lotus Notes client configuration that I should be aware of?

What is the purpose of the Lotus Notes user ID file?

The Lotus Notes user ID file is used by the Lotus Notes C++ API to connect to the Domino server and crawl the Domino database. The Lotus Notes user ID file contains the following three things:

  • A Domino client certificate issued by a Domino certification authority

  • A pair of public/private keys

  • A password used to encrypt the private key

What metadata in a Domino database is indexed?

Microsoft Search Server 2008 indexes the metadata for any property that appears in quotes in the right pane of the Document properties window. For example, if you select a field in the left pane named Form and "Secure" appears in the right pane, the metadata for the property named Secure is indexed for the Form field.

Where is the MissingLogId.txt file located and what is its use?

The MissingIdLog.txt file contains a list of Lotus Notes user IDs that are not mapped to valid Windows user accounts in the mappings table. For example, if the Lotus Notes user ID LotusManager1 is mapped to the Windows user account Contoso\User1, but User1 is not a valid user in the Contoso domain, the MissingIdLog.txt file will have an entry for Contoso\User1.

The MissingIdLog.txt file is located in the root directory of the index server's drive on which you installed Lotus Notes. To ensure that all missing IDs are listed in this file before you view it, we recommend that you stop and restart the OSearch service after all crawls are complete before viewing the MissingIdLog.txt file.

The index server does not overwrite this file. Instead, new entries are appended to the MissingIdLog.txt file.

Important Important:

Do not use the Services on Server page on the SharePoint Central Administration Web site to stop and start this service. Doing so removes the service and deletes the index and associated configuration. Instead, use the following steps.

Stop and restart the Office SharePoint Server Search service

  1. On the index server, click Start, click Administrative Tools, and then click Services.

  2. Scroll down the list, right-click the Office SharePoint Server Search service, and then click Properties. The properties page appears.

  3. Click Stop. After the service is stopped, click Start.

  4. Ensure that the Startup Type is not set to Disabled.

What type of changes would require me to run NotesSetup again?

If you want to specify a different mappings database or change the Domino server on which the mappings database is located, run the NotesSetup application again to specify the new mappings database or location.

What does NotesSetup capture and store from the Lotus Notes client configuration that I should be aware of?

NotesSetup writes entries in the registry of the index server under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\Notes Configs

The following entries are written to the registry using NotesSetup:

  • The name of the Domino server where the Mappings.nsf database is located

  • The name of mappings database

  • The view name of Mappings file

  • The location of the MissingIdLog.txt file

  • Names of the columns used to store the Lotus Notes user Ids and Windows domain accounts

See Also

Concepts

Configure Search Server to crawl Lotus Notes (Search Server 2008)


Crawl content (Search Server 2008)
DropDown image

Updated: 2008-09-11

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Crawling content is the process by which a system accesses and parses content and its properties, sometimes called metadata, to build a content index from which search queries can be served.

The result of successfully crawling content is that the individual files or pieces of content that you want to make available to search queries are accessed and read by the crawler. The keywords and metadata for those files are stored in the content index, sometimes called the index. The index consists of the keywords that are stored in the file system of the index server and the metadata that is stored in the search database. The system maintains a mapping between the keywords, the metadata associated with the individual pieces of content, and the URL of the source from which the content was crawled.

Note Note:

The crawler does not change the files on the host servers. Instead, the files on the host servers are accessed and read, and the text and metadata for those files are sent to the index server to be indexed. However, because the crawler reads the content on the host server, some servers that host certain sources of content might update the last accessed date on files that have been crawled.

Determining when to crawl content

After a server farm has been deployed and running for some time, a search services administrator typically must change the crawl schedule. This might need to be done for the following reasons:

  • To accommodate changes in downtimes and periods of peak usage.

  • To accommodate changes in the frequency at which content is updated on the servers hosting the content.

  • To schedule crawls so that:

    • Content that is hosted on slower host servers is crawled separately from content that is hosted on faster host servers.

    • New content sources are crawled.

    • Crawls occur as often as targeted content is updated. For example, you might want to perform daily crawls on repositories that are updated each day and crawl repositories that are updated infrequently less often.

Performing crawls

Typically, you want to automate most crawls by scheduling them. However, sometimes you might want to manually start a crawl. For example, you might start a crawl to apply administrative changes such as crawl rules to the content you crawl and index or to determine if an error in the crawl log has been resolved.

In addition, whether a crawl is started manually or by a schedule, you might need to stop or pause one or more crawls. For example, an administrator whose server hosts the content you are crawling might notify you that crawling is placing too much load on the server or you might be alerted that the server you are crawling is currently offline. In either of these cases, you might want to stop or pause the crawl.

You should consider that more time and server resources are required to perform a full crawl than are required to perform an incremental crawl. Full crawls:

  • Consume more memory and CPU cycles on the index server than incremental crawls.

  • Consume more memory and CPU cycles on the Web front-end servers when crawling content in your server farm. This does not apply to content that is external to your server farm.

  • Use more network bandwidth than incremental crawls.

Important Important:

When you stop a crawl of any content source, the next time you crawl that content source, Microsoft Search Server 2008 automatically performs a full crawl of the content source the next time it is crawled. This is true even if you attempt to perform an incremental crawl. Therefore, carefully consider whether you should pause the crawl instead of stopping the crawl.

You must also be careful not to pause crawls for too many content sources at the same time, because each content source that is paused consumes memory and CPU resources on the index server.

To start a full or incremental crawl, stop, pause, or resume a crawl, do one of the following:

  • Start a full crawl (Search Server 2008)

  • Start an incremental crawl (Search Server 2008)

  • Stop a crawl (Search Server 2008)

  • Pause and resume a crawl (Search Server 2008)

Scheduling crawls

The following sections provide more information about considerations for crawling content on a schedule.

Downtimes and periods of peak usage

Consider the downtimes and peak usage times of the servers that host the content you want to crawl. For example, if you are crawling content hosted by many different servers outside your server farm, it is likely that these servers are backed up on different schedules and have different peak usage times. The administration of servers outside your server farm is typically out of your control. Therefore, we recommend that you coordinate your crawls with the administrators of the servers that host the content you want to want to crawl to ensure you do not attempt to crawl content on their servers during a downtime or peak usage time.

Note Note:

Because the times of peak usage and downtimes for host servers can change, we recommend that you periodically reevaluate your crawl schedules for all content sources, not just the new ones you create.

A common scenario involves content outside the control of your organization that relates to the content on your SharePoint sites. You can add the start addresses for this content to an existing content source or create a new content source for external content. Because availability of external sites varies widely, it is helpful to add separate content sources for different external content. In this way, the content sources for external content can be crawled at different times than your other content sources. You can update external content on a crawl schedule that accounts for the availability of each site.

Content that is updated frequently

When planning crawl schedules, consider that some sources of content are updated more frequently than others. For example, if you know that content on some site collections or external sources is updated only on Fridays, it wastes resources to crawl that content more frequently than once each week. However, your server farm might contain other site collections that are continually updated Monday through Friday, but not typically updated on Saturdays and Sundays. In this case, you might want to crawl those sites several times during the week and not at all on weekends.

The way in which content is stored across the site collections in your environment can guide you to create additional content sources for each of your site collections in each of your Web applications. For example, if a site collection stores only archived information, you might not need to crawl that content as frequently as you crawl a site collection that stores frequently updated content. In this case, you might want to crawl these two site collections using different content sources so that they can be crawled on different schedules.

Full and incremental crawl schedules

As a search services administrator, you can independently configure crawl schedules for each content source. For each content source, you can specify a time to do full crawls and a different time to do incremental crawls.

Note Note:

You must run a full crawl for a particular content source before you can run an incremental crawl.

We recommend that you plan crawl schedules based on the availability, performance, and bandwidth considerations of the servers running the search service and the servers hosting the crawled content.

When you plan crawl schedules, consider the following best practices:

  • Group start addresses in content sources based on similar availability and with acceptable overall resource usage for the servers that host the content.

  • Schedule incremental crawls for each content source during times when the servers that host the content are available and when there is low demand on the resources of the server. You can also add or edit one or more crawler impact rules to reduce the load on the servers that are being crawled. For information about crawler impact rules, see Manage crawler impact (Search Server 2008).

  • Stagger crawl schedules so that the load on the servers in your farm is distributed over time.

  • Schedule full crawls only when necessary for the reasons listed in the next section. We recommend that you do full crawls less frequently than incremental crawls.

  • Schedule administration changes that require a full crawl to occur shortly before the planned schedule for full crawls. For example, we recommend that you attempt to schedule the creation of the crawl rule before the next scheduled full crawl so that an additional full crawl is not necessary.

  • Base simultaneous crawls on the capacity of the index server to crawl them. We recommend that you stagger your crawl schedules so that the index server does not crawl using multiple content sources at the same time. The performance of the index server and the performance of the servers hosting the content determine the extent to which crawls can be overlapped. A strategy for scheduling crawls can be developed over time as you can become familiar with the typical crawl durations for each content source. We recommend that you record trend data of how long crawls take in your environment.

Reasons to perform a full crawl

Reasons for a search services administrator to do a full crawl include:

  • One or more hotfix or service pack was installed on servers in the farm. See the instructions for the hotfix or service pack for more information.

  • A search services administrator added a new managed property.

  • To re-index ASPX pages on Windows SharePoint Services 3.0 sites.

    Note Note:

    The crawler cannot discover when ASPX pages on Windows SharePoint Services 3.0 sites have changed. Because of this, incremental crawls do not re-index views or home pages when individual list items are deleted. We recommend that you periodically do full crawls of sites that contain ASPX files to ensure that these pages are re-indexed.

  • To detect security changes that were made on a file share after the last full crawl of the file share.

  • To resolve consecutive incremental crawl failures. In rare cases, if an incremental crawl fails one hundred consecutive times at any level in a repository, the index server removes the affected content from the index.

  • Crawl rules have been added, deleted, or modified.

  • To repair a corrupted index.

  • The search services administrator has created one or more server name mappings.

  • The account assigned to the default content access account or crawl rule has changed.

The system does a full crawl even when an incremental crawl is requested under the following circumstances:

  • A search services administrator stopped the previous crawl.

  • A content database was restored.

    Note Note:

    If you are running the Infrastructure Update for Microsoft Office Servers, you can use the restore operation of the stsadm command-line tool to change whether a content database restore causes a full crawl.

  • A farm administrator has detached and reattached a content database.

  • A full crawl of the site has never been done.

  • The change log does not contain entries for the addresses that are being crawled. Without entries in the change log for the items being crawled, incremental crawls cannot occur.

  • The account assigned to the default content access account or crawl rule has changed.

  • To repair a corrupted index.

    Depending on the severity of the corruption, the system might attempt to perform a full crawl if corruption is detected in the index.

You can adjust schedules after the initial deployment based on the performance and capacity of servers in the farm and the servers hosting content.

See Also

Concepts

How to crawl content (Search Server 2008)
Schedule a full crawl (Search Server 2008)
Schedule an incremental crawl (Search Server 2008)


Start a full crawl (Search Server 2008)
DropDown image

Updated: 2008-09-11

Before you perform this procedure, we recommend that:

  • You have read the topic Crawl content (Search Server 2008).

Important Important:

You must be a search services administrator to perform the following procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

When you perform a full crawl, all content specified by the content source you are crawling is crawled even if the content already exists in the index. To perform a full crawl, you must crawl the content defined in a particular content source individually. Note that using the Start all crawls link on the Manage Content Sources page results in all content sources being crawled using an incremental crawl, unless the system detects that a full crawl is required.

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

To start a full crawl of a particular content source

Use the following procedure to crawl content defined in a particular content source.

Crawl content defined in a particular content source

  1. On the Search Administration page, in the Search section, click Search settings.

  2. On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.

  3. On the Manage Content Sources page, click the content source, and select Start Full Crawl in the dropdown list.

    Note Note:

    The value in the Status column changes to Crawling Full for the content source you selected in this step.

  4. Repeat step 3 for each content source for which you want to do a full crawl.

    Note Note:

    The value in the Status column does not automatically change when the crawl is complete. To update the Status column, refresh the Manage Content Sources page by clicking Refresh on the toolbar.

See Also

Concepts

Schedule a full crawl (Search Server 2008)


Schedule a full crawl (Search Server 2008)
DropDown image

Updated: 2008-09-11

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Before you perform this procedure, confirm that:

  • You have read the topic Crawl content (Search Server 2008).

Important Important:

You must be a search services administrator to complete this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

To schedule a full crawl

Use this procedure to create a new or change an existing full-crawl schedule for a particular content source.

Schedule a full crawl for a particular content source

  1. On the Search Administration page, under Crawling, click Content sources.

  2. On the Manage Content Sources page, right click the content source for which you want to schedule a full crawl, and then click Edit.

  3. On the Edit Content Source page, in the Crawl Schedules section, do the following:

    • If a full crawl has never been created for this content source, click the Create schedule link below the Full Crawl list.

      -or-

    • If you are changing the full-crawl schedule, click the Edit schedule link below the Full Crawl list.

  4. In the Manage Schedules dialog box, in the Type section, select Daily, Weekly, or Monthly.

  5. In the Settings section, do the following:

    • In the Run every box, type the number of days between crawls. For example, to schedule a full crawl to start every other day, type 2.

    • In the Starting time list, select the time of the day from which to start the scheduled crawl.

    • If you want to crawl more frequently than once a day, select the Repeat within the day box, type the number of minutes to wait between crawls in the Every box, and type the total number of minutes in which to repeat the crawl within the same day in the For box. For example, if you select Repeat within the day and type 60 in the Every box and 720 in the For box, a full crawl of the content source you are configuring starts every 60 minutes up to 720 minutes (12 hours) after the first scheduled full crawl for this content source ran.

    • Click OK.

  6. Click OK.

See Also

Concepts

Schedule an incremental crawl (Search Server 2008)


Start an incremental crawl (Search Server 2008)
DropDown image

Updated: 2008-09-11

In this article:

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Before you perform this procedure, we recommend that:

  • You have read the topic Crawl content (Search Server 2008).

Important Important:

You must be a search services administrator to perform the following procedures. For more information, see Add or remove a search services administrator (Search Server 2008).

When you perform an incremental crawl, Microsoft Search Server 2008:

  • Crawls the content specified in the content source you are crawling that does not already exist in the index.

  • Crawls content that does exist in the index but has been updated on the host server since the last crawl.

  • Removes from the index all content for the content source being crawled that no longer exists on the host server or can no longer be reached due to errors, such as denial of permissions.

Start an incremental crawl of a particular content source

Use the following procedure to start an incremental crawl of a particular content source.

Start an incremental crawl of a particular content source

  1. On the Search Administration page, in the Search section, click Search settings.

  2. On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.

  3. On the Manage Content Sources page, click the content source that you want to crawl, and select Start Incremental Crawl in the dropdown list.

    Note Note:

    The value in the Status column changes to Crawling Incremental for the content source you selected unless the system detects that a full crawl is required, in which case the Status column changes to Crawling Full and the system performs a full crawl.

  4. Repeat step 3 for each content source for which you want to do an incremental crawl.

    Note Note:

    The value in the Status column does not change when the crawl is complete. To update the Status column, refresh the Manage Content Sources page by clicking Refresh on the toolbar.

See Also

Concepts

Schedule an incremental crawl (Search Server 2008)


Schedule an incremental crawl (Search Server 2008)
DropDown image

Updated: 2008-09-11

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Before you perform this procedure, confirm that:

  • You have read the topic Crawl content (Search Server 2008)

Important Important:

You must be a search services administrator to complete this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

To schedule an incremental crawl

Use this procedure to create a new or change an existing incremental-crawl schedule for a particular content source.

Schedule an incremental crawl for a particular content source

  1. On the Search Administration page, under Crawling, click Content sources.

  2. On the Manage Content Sources page, right click the content source for which you want to schedule an incremental crawl and then click Edit.

  3. On the Edit Content Source page, in the Crawl Schedules section, do the following:

    • If an incremental crawl has never been created for this content source, click the Create schedule link below the Incremental Crawl list.

      -or-

    • If you are changing the incremental-crawl schedule, click the Edit schedule link below the Incremental Crawl list.

  4. In the Manage Schedules dialog box, in the Type section, select Daily, Weekly, or Monthly.

  5. In the Settings section, do the following:

    • In the Run every box, type the number of days between crawls. For example, to schedule an incremental crawl to start every other day, type 2.

    • In the Starting time list, select the time of the day from which to start the scheduled crawl.

    • If you want to crawl more frequently than once a day, select the Repeat within the day box and type the number of minutes to wait between crawls in the Every box and type the total number of minutes in which to repeat the crawl within the same day in the For box. For example, if you select Repeat within the day and type 60 in the Every box and 720 in the For box, an incremental crawl of the content source you are configuring starts every 60 minutes up to 720 minutes (12 hours) after the first scheduled incremental crawl for this content source ran.

  6. Click OK.

See Also

Concepts

Schedule a full crawl (Search Server 2008)


Pause and resume a crawl (Search Server 2008)
DropDown image

Updated: 2008-09-11

In this article:

  • Pause a crawl of a particular content source

  • Resume a crawl of a particular content source

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Before you perform the following procedures, we recommend that:

  • You have read the topic Crawl content (Search Server 2008).

Important Important:

You must be a search services administrator to perform the following procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

Pause a crawl of a particular content source

Use the following procedure to pause a crawl of a particular content source.

Important Important:

We recommend not pausing crawls for too many content sources at the same time, because each content source that is paused consumes memory on the index server.

Pause a crawl of a particular content source

  1. On the Search Administration page, in the Search section, click Search settings.

  2. On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.

  3. On the Manage Content Sources page, click the content source that you want to pause, and then select Pause Crawl in the dropdown list.

    The value in the Status column changes to Pausing for the content source you selected.

  4. Note that the value in the Status column on the page does not change when the crawl is paused. To update the Status column, refresh the Manage Content Sources page by clicking Refresh on the toolbar. When the crawl is paused, the value in the Status column changes to Paused.

    Note Note:

    Depending on the content being crawled, this might take several minutes to complete.

Resume a crawl of a particular content source

Use the following procedure to resume a crawl of a particular content source.

Resume a crawl of a particular content source

  1. On the Search Services Administration page, in the Search section, click Search settings.

  2. On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.

  3. On the Manage Content Sources page, click the content source that you want to resume, and select Resume Crawl in the dropdown list.

    Note Note:

    The value in the Status column for the content source changes to Crawling Full or Crawling Incremental depending on the type of crawl that was running at the time it was paused.


Stop a crawl (Search Server 2008)
DropDown image

Updated: 2008-09-11

In this article:

  • Stop a crawl of a particular content source

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Before you perform the following procedures, we recommend that:

  • You have read the topic Crawl content (Search Server 2008).

Important Important:

You must be a search services administrator to perform the following procedures. For more information, see Add or remove a search services administrator (Search Server 2008).

Stop a crawl of a particular content source

Use the following procedure to stop a crawl of a particular content source.

Important Important:

When you stop a crawl of any content source, the next time you crawl that content source, Microsoft Search Server 2008 automatically performs a full crawl of the content source. This is true even if you attempt to perform an incremental crawl. Therefore, carefully consider whether you should pause the crawl instead of stopping the crawl.

Stop a crawl of a particular content source

  1. On the Search Administration page, in the Search section, click Search settings.

  2. On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.

  3. On the Manage Content Sources page, point to the content source you want to crawl, click the arrow that appears, and then click Stop Crawl on the menu that appears.

    A dialog box displays to remind you that if you stop this crawl, the only type of crawl you can execute next on this content is a full crawl.

  4. Click OK in the dialog box to close the warning message. The value in the Status column for the content source that you stopped changes to Stopping.

  5. To refresh the Status column, click Refresh on the toolbar. After the crawl is stopped, the value in the Status column for the content source that you stopped changes to Idle.

    Note Note:

    Depending on the content being crawled, this might take several minutes to complete. This is because the search service must flush all items that are currently being crawled.

See Also

Concepts

Pause and resume a crawl (Search Server 2008)


Limit or increase the quantity of content that is crawled (Search Server 2008)
DropDown image

Updated: 2008-10-23

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

During operations, you typically need to change the quantity of content that you are currently crawling. For example, you might want to:

  • Discontinue crawling some sites within a particular namespace that is defined by an existing content source.

  • Crawl sites at a different depth.

  • Change the number of file types to crawl — that is, start crawling file types that you have not crawled before, discontinue crawling of certain file types that you are currently crawling, or both.

As the needs of your organization change, you might also crawl entirely new sources of content. For more information about crawling entirely new sources of content, see About content sources (Search Server 2008).

You can increase or limit the quantity of content that is crawled by using:

  • Crawl settings in the content sources For example, you can specify to crawl only the start addresses that are specified in a particular content source, or you can specify how many levels deep in the namespace (from those start addresses) to crawl and how many server hops to allow. Note that the options that are available within a content source for specifying the quantity of content that is crawled vary by content-source type.

  • File type inclusions You can choose the file types that you want to crawl.

  • Crawl rules You can use crawl rules to exclude all items in a given path from being crawled. This is a good way to ensure that subsites that you do not want to index are not crawled with a parent site that you are crawling. You can also use crawl rules to increase the amount of content that is crawled — for example crawling complex URLs for a given path.

Crawl settings

For each content source, you can select how extensively to crawl the start addresses in that content source. You also specify the behavior of the crawl, sometimes called the crawl settings. The options you can choose for a particular content source vary somewhat based on the content source type that you select. However, most options determine how many levels deep in the hierarchy from each start address listed in the content source are crawled. Note that this behavior is applied to all start addresses in a particular content source.

The options available in the properties for each content source vary depending upon the content source type that is selected. The following table describes the crawl settings options for each content source type.

Content source type Crawl settings options

SharePoint sites

  • Everything under the host name for each start address

  • Only the SharePoint site of each start address

Web sites

  • Only within the server of each start address

  • Only the first page of each start address

  • Custom — Specify page depth and number of server hops.

    Note Note:

    The default setting for this option is unlimited page depths and server hops.

File shares

  • The folder and all subfolders of each start address

  • Only the folder of each start address

Exchange public folders

  • The folder and all subfolders of each start address

  • Only the folder of each start address

As the preceding table shows, search services administrators can use crawl setting options to limit or increase the quantity of content that is crawled.

The following table describes best practices when configuring crawl setting options.

For this content source type If this pertains Use this crawl setting option

SharePoint sites

You want to crawl the content on a particular site collection on a different schedule than other site collections.

Crawl only the SharePoint site of each start address

Note Note:

This option accepts any URL, but will start the crawl from the top-level site of the site collection that is specified in the URL you enter. For example, if you enter http://contoso/sites/sales/car but http://contoso/sites/sales is the top-level site of the site collection, the site collection http://contoso/sites/sales and all of its subsites are crawled.

SharePoint sites

You want to crawl all content in all site collections in a particular Web application on the same schedule.

Crawl everything under the host name of each start address

Note Note:

This option accepts only host names as start addresses, such as http://contoso. You cannot enter the URL of a subsite, such as http://contoso/sites/sales when using this option.

Web sites

Content on the site itself is relevant.

-or-

Content available on linked sites is not likely to be relevant.

Crawl only within the server of each start address

Web sites

Relevant content is on only the first page.

Crawl only the first page of each start address

Web sites

You want to limit how deep to crawl the links on the start addresses.

Custom — Specify the number of pages deep and number of server hops to crawl

Note Note:

We recommend you start with a small number on a highly connected site because specifying more than three pages deep or more than three server hops can crawl the entire Internet.

Note Note:

You can also use one or more crawl rules to specify what content to crawl. For more information, see Use crawl rules to determine what content gets crawled (Search Server 2008).

File shares

Exchange public folders

Content available in the subfolders is not likely to be relevant.

Crawl only the folder of each start address

File shares

Exchange public folders

Content in the subfolders is likely to be relevant.

Crawl the folder and subfolder of each start address

File-type inclusions and IFilters

Content is only crawled if the relevant file name extension is included in the file-type inclusions list and an IFilter is installed on the index server that supports those file types. Several file types are included automatically during initial installation. By analyzing the query logs, you can discover which file types contain content that your end users want to query. You might discover the need to crawl a file type that you are not currently crawling or you might want to exclude certain file types from being crawled.

When you add file types to the file type inclusions list, you must also ensure that you have an IFilter that can be used to parse the file type when crawled. If such an IFilter is not installed, the content in the files of that file type will not be indexed, and will not be searchable. However, the metadata of files of that particular file type will be crawled and will be searchable. For example, if you add PDF to the file type inclusions list but do not install an IFilter for the PDF file type, the content of PDF files will not be indexed, but the metadata of PDF files will.

Microsoft Search Server 2008 provides several IFilters, and more are available from Microsoft and third-party vendors. If necessary, software developers can create IFilters for new file types. To install and register additional IFilters proved by Microsoft with Search Server 2008, see How to register Microsoft Filter Pack with SharePoint Server 2007 and with Search Server 2008 (http://go.microsoft.com/fwlink/?LinkId=110532). For more information about IFilters, including those from third-party vendors, see Filter Central (http://go.microsoft.com/fwlink/?LinkID=131255).

For a list of the file types that are supported by the IFilters that are installed by default and which file types are enabled for crawling by default, see Crawl more file types by installing IFilters (Search Server 2008).

Limit or exclude content by using crawl rules

You can edit existing crawl rules or create new crawl rules to exclude all items or include specific items for a particular path.

Note Note:

When you add a start address to a content source and accept the default behavior, all subsites or folders below that start address are crawled unless you exclude them by using one or more crawl rules.

Crawl rules apply to a particular URL, or to a set of URLs represented by wildcards. (This URL is also referred to as the path affected by the rule.) You use crawl rules to do the following things:

  • Avoid crawling less relevant content by excluding one or more URLs. This also helps to reduce the use of server resources and network traffic, and to increase the relevance of search results.

  • Crawl links on the URL without crawling the URL itself. This option is useful for sites with links of relevant content when the page containing the links does not contain relevant information or should not be exposed to end users in search results pages.

  • Enable complex URLs to be crawled. This option crawls URLs that contain a query parameter specified with a question mark. Depending upon the site, these URLs might or might not include relevant content. Because complex URLs can often redirect to less relevant sites, it is a good idea to enable this option on only sites where the content available from complex URLs is known to be relevant.

    Note Note:

    This option has no effect when crawling SharePoint sites, because Search Server 2008 enumerates all content when crawling SharePoint sites.

Note Note:

Crawl rules apply simultaneously to all content sources.

Often, most of the content for a particular site address is relevant, but not a specific subsite or range of sites below that site address. By selecting a focused combination of URLs for which to create crawl rules that exclude unneeded items, search services administrators can maximize the relevance of the content in the index while minimizing the impact on crawling performance and the size of search databases. Creating crawl rules to exclude URLs is particularly useful when planning start addresses for external content because the impact on resource usage is not under the control of people in your organization.

When creating a crawl rule, you can use standard wildcard characters in the path. For example:

  • http://server1/folder* contains all Web resources with a URL that starts with http://server1/folder.

  • *://*.txt includes every document with the .txt file name extension.

Because crawling content consumes resources and bandwidth, it is better to include a smaller amount of content that you know is relevant. After the initial deployment, you can review the query and crawl logs and adjust content sources and crawl rules to be more relevant and include more content.

To limit or increase the quantity of content that is crawled, you can perform the following procedures:

  • Use crawl rules to determine what content gets crawled (Search Server 2008)

  • Specify file types to crawl (Search Server 2008)


Use crawl rules to determine what content gets crawled (Search Server 2008)
DropDown image

Updated: 2009-08-10

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this article:

  • Create a crawl rule

  • Edit a crawl rule

  • Delete a crawl rule

  • Reorder crawl rules

Before you perform these procedures, confirm that:

  • You have read the topic Limit or increase the quantity of content that is crawled (Search Server 2008).

Important Important:

You must be a search services administrator to perform the procedures in this article. For more information, see Add or remove a search services administrator (Search Server 2008).

You can create new crawl rules or edit existing crawl rules to determine what content gets crawled. You can also reorder crawl rules to specify the order in which these rules are applied.

Create a crawl rule

Use the following procedure to create a crawl rule.

Create a crawl rule

  1. On the Search Administration page, in the Crawling section, click Crawl rules.

  2. On the Manage Crawl Rules page, click New Crawl Rule.

  3. On the Add Crawl Rule page, in the Path section, in the Path box, type the path affected by this rule. You can use standard wildcard characters in the path. For example:

    • http://server1/folder* contains all Web resources with a URL that starts with http://server1/folder.

    • *://*.txt includes every document with the txt file extension.

  4. In the Crawl Configuration section, select one of the following:

    • Exclude all items in this path. Select this option if you want all items in the specified path to be excluded from the crawl.

    • Include all items in this path. Select this option if you want all items in the path to be crawled.

  5. If you chose to exclude all items in this path, skip to step 7. Otherwise, you can further refine the inclusion by selecting any combination of the following:

    • Follow links on the URL without crawling the URL itself. Select this option if you want to crawl links contained within the URL, but not the URL itself.

    • Crawl complex URLs (URLs that contain a question mark (?)). Select this option if you want to crawl URLs that contain parameters that use the question mark (?) notation.

    • Crawl SharePoint content as HTTP pages. Normally, SharePoint content is crawled by using a special protocol. Select this option if you want SharePoint content to be crawled as HTTP pages instead. When the content is crawled by using the HTTP protocol, item permissions are not stored. This means that all items that match a particular search query appear on search results pages, regardless of whether the user that initiated the query has access to those items.

      The purpose of this setting is to enable search administrators to crawl remote SharePoint sites that they do not have explicit control over and therefore cannot enforce that the domain account used to crawl those remote sites has been granted full-read permissions on those sites.

    Note Note:

    For information about the settings in the Specify Authentication section, see Use crawl rules to specify a different content access account or authentication method (Search Server 2008)

  6. Click OK.

  7. Repeat steps 2 through 5 for each new crawl rule you want to create.

Edit a crawl rule

You can edit an existing crawl rule at any time by clicking it, and then making the necessary changes to the path and configuration, as described in the previous procedure.

Note Note:

This will require a full crawl of the content impacted by the altered crawl rule.

Delete a crawl rule

Use the following procedure to delete a crawl rule that is no longer needed.

Delete a crawl rule

  1. On the Shared Services Administration page, in the Search section, click Search settings.

  2. On the Configure Search Settings page, in the Crawl Settings section, click Crawl rules.

  3. On the Manage Crawl Rules page, point to the crawl rule that you want to delete, click the arrow that appears, and then click Delete on the menu that appears.

  4. Click OK to confirm the deletion.

Note Note:

This will require a full crawl of the content impacted by the deleted crawl rule.

Reorder crawl rules

After you create new crawl rules, we recommend that you specify the order in which you want the rules to be applied while content is being crawled. Crawl rules are applied in the order in which they are listed. Therefore, if two rules cover the same or overlapping content, the first rule that is listed is applied. Use the following procedure to specify the order of your crawl rules.

Reorder crawl rules

  • On the Shared Services Administration page, in the Search section, click Search settings.

  • On the Configure Search Settings page, in the Crawl Settings section, click Crawl rules.

  • On the Manage Crawl Rules page, in the Order column in the list of crawl rules, select a value in the list that specifies the position you want the rule to occupy. Other values are shifted accordingly.

    You can also use a global exclusion rule, which applies regardless of the order in which it is listed. For more information about administering crawl rules, see the Administrating Crawl Rules section in the following resource: Book Excerpt - Chapter 16 Enterprise search and indexing architecture and administration.

Note Note:

This will require a full crawl of the content that is affected by the repositioned crawl rule.


Specify file types to crawl (Search Server 2008)
DropDown image

Updated: 2008-09-11

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Before you perform this procedure, confirm that:

  • You have read the topic Limit or increase the quantity of content that is crawled (Search Server 2008).

Important Important:

You must be a search services administrator to complete this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

To specify file types to include in the content index

Use the following procedure to add file types to the File Types list.

Note Note:

Adding file types will require a full crawl of the content impacted by such changes.

Add file types

  1. On the Search Administration page, under Crawling, click File Types.

  2. In the Manage File Types page, click New File Type.

  3. In the Add File Type page, in the File extension box, type the file name extension for the file type that you want to add (for example, type doc).

    Note Note:

    Do not add a period (.) character before the file type.

  4. Click OK.

  5. Repeat steps 3 through 5 for each file type that you want to add.

You can also delete file types from this list for the file types you do not want the crawler to include in the content index. Use the following procedure to delete file types from the File Types list.

Note Note:

Deleting file types will require a full crawl of the content impacted by such changes.

Delete file types

  1. In the Manage File Types page, click the file name extension for the file type that you want to delete, and then click Delete in the dropdown menu.

  2. Click OK to confirm the deletion.


Configure how the crawler authenticates (Search Server 2008)
DropDown image

Updated: 2008-09-11

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

When Search Server 2008 crawls the content specified by your content sources, the crawler uses the default content access account, by default, to authenticate to the server that hosts the content. Therefore, you must request that the owners of the content that you are crawling grant full Read permissions to the account that you assigned as the default content access account and any other accounts that are provided through a crawl rule.

In some cases, especially if you are crawling content that is external to your organization, administrators might not want to grant access to the default content access account. In these cases, you might have to create a crawl rule that uses a different account to crawl that content.

Task requirements

Before you perform the procedures to complete this task, determine the authentication method that is used by the server that hosts the content that you are crawling. By default, Search Server uses NTLM authentication. Other supported authentication methods are Basic authentication, client certificates, forms-based authentication, and cookie authentication.

To change how the crawler authenticates to other servers, you can perform the following procedures:

  • Use crawl rules to specify a different content access account or authentication method (Search Server 2008)

  • Change the default content access account (Search Server 2008)

See Also

Concepts

Configure the farm for search (Search Server 2008)


Change the default content access account (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

  • Before you perform this procedure, we recommend that you have read the topic Configure how the crawler authenticates (Search Server 2008).

Important Important:

You must be a search services administrator to perform the following procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

Use the following procedure to change the default content access account.

Change the default content access account

  1. On the Search Administration page, in the Crawling section, click Default content access account.

  2. On the Default Content Access Account page, in the Account box, type the domain and user name for the account in the form DomainName\UserName.

  3. In the Password and Confirm Password boxes, type the password for the account.

  4. Click OK.

See Also

Concepts

Use crawl rules to specify a different content access account or authentication method (Search Server 2008)


Use crawl rules to specify a different content access account or authentication method (Search Server 2008)
DropDown image

Updated: 2008-09-11

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In Microsoft Search Server 2008, you can create new crawl rules or edit existing crawl rules to specify a different content access account or authentication method to use when crawling a particular path. You can also specify the order in which crawl rules are applied.

In this article:

  • Crawling sites that use forms-based authentication

  • Create a crawl rule

  • Edit a crawl rule

  • Delete a crawl rule

  • Reorder crawl rules

Crawling sites that use forms-based authentication

Search Server 2008 supports crawling sites that use forms-based authentication (FBA), when FBA is implemented by using an input Submit type. Search Server 2008 does not support crawling content on sites that have logon pages that contains a series of forms that span multiple pages (wizard-based forms), or forms that use dynamic content rendered by using AJAX, JavaScript, or other dynamic scripting methods. Sites that use the following types of forms-based authentication forms are not supported:

  • Wizard-style logon pages Search Server 2008 does not crawl sites that use a series of screens to authenticate users. These wizard-style forms present one or more pages based on the user's input in a form on a previous page. Because Search Server 2008 cannot crawl multiple logon pages, the creation of a crawl rule for a site that uses this type of authentication is not supported.

  • Logon forms that change dynamically Search Server 2008 does not crawl sites that have logon pages that change dynamically, because they are designed to use technologies such as AJAX. A logon screen that uses AJAX can present new options to a user without a visible postback — in other words, scripting enables the display of new data without the need to refresh the page in the browser. When a user interacts with a logon page that uses this technology, he or she might type a password, and then be presented with a new form to answer a security question, without seeing the page refresh in the browser. The creation of a crawl rule for a site that uses this type of design is not supported.

Note Before you perform the procedures in this article, confirm that you have read the topic Configure how the crawler authenticates (Search Server 2008).

Important Important:

You must be a search services administrator to perform the following procedures. For more information, see Add or remove a search services administrator (Search Server 2008).

Create a crawl rule

Use the following procedure to create a crawl rule that specifies a different content access account or authentication method to use when crawling a particular path.

Create a crawl rule

  1. On the Search Administration page, in the Crawling section, click Crawl rules.

  2. On the Manage Crawl Rules page, click New Crawl Rule.

  3. On the Add Crawl Rule page, in the Path section, in the Path box, type the path affected by this rule. You can use standard wildcard characters in the path. For example, you can type:

    • http://server1/folder* to include all Web resources with a URL that starts with http://server1/folder.

    • *://*.txt to include every document with the .txt file name extension.

  4. In the Crawl Configuration section, to prevent a folder or subsite in the path from being crawled, click Exclude all items in this path.

  5. To select whether items in the path are included, click Include all items in this path, and then select any combination of the following check boxes:

    • Follow links on the URL without crawling the URL itself Select this check box if you want the links on the logon page to be crawled, but you do not want the text on the logon page to be indexed.

    • Crawl complex URLs (URLs that contain a question mark (?)) Select this check box if you want to crawl URLs that use parameters to display additional content.

    • Crawl SharePoint content as Http pages Normally, content on SharePoint sites is crawled by using a special protocol. Select this check box if you want content on SharePoint sites to be crawled as HTTP pages instead.

    Note Note:

    When the content is crawled by using the HTTP protocol, the item permissions are not stored.

  6. In the Specify Authentication section, do one of the following:

    Note Note:

    To select any of the options in this section, make sure to click Include all items in this path under Crawl configuration.

    • To use the default content access account when crawling URLs affected by this crawl rule, click Use the default content access account.

    • If you want to use a different content access account, click Specify a different content access account, and then do the following:

      In the Account box, type the account name that can access the paths defined by this crawl rule — for example, user_name or DOMAIN\user_name.

      In the Password and Confirm Password boxes, type the password for the account.

      If you want to prevent Basic authentication from being used, select the Do not allow Basic Authentication check box. Otherwise, if you want to use Basic authentication, clear the Do not allow Basic Authentication check box.

      Note Note:

      You cannot use Basic authentication if the domain account assigned to the content access account that is used to crawl the content affected by this crawl rule is from a different domain than your server farm.

    • To use a client certificate for authentication, click Specify client certificate, and then on the Certificate menu, click a certificate.

    • To use forms-based authentication, click Specify forms credentials, type the form location in the Form URL box, and then click Enter Credentials.

      Note Note:

      Search Server 2008 supports crawling sites that use forms-based authentication (FBA), when FBA is implemented by using an input Submit type. Search Server 2008 does not support crawling content on sites whose logon pages contain a series of forms that span multiple pages (wizard-based forms) or forms that use dynamic content rendered by using AJAX, JavaScript, or other dynamic scripting methods.

    • To use cookie authentication, click Use cookie for crawling, and then do one of the following:

      • To obtain a cookie from a URL, type the full location in the Obtain cookie from a URL box, and then click Get Cookie.

      • To select a specific cookie from your computer or your network, click Specify cookie for crawling, click Browse, and then select the cookie to be used.

      • To specify the error pages that display when a cookie is expired, in the Error Pages (semi-colon delimited) box, type the URLs for the pages, separated by semi-colons.

  7. Click OK.

Edit a crawl rule

You can edit an existing crawl rule at any time by going to the Manage Crawl Rules page, clicking the crawl rule, and then making the necessary changes to the path and configuration, as described in the previous procedure.

Delete a crawl rule

Use the following procedure to delete a crawl rule that you no longer need.

To delete a crawl rule

  1. On the Search Administration page, in the Crawling section, click Crawl rules.

  2. On the Manage Crawl Rules page, point to the crawl rule that you want to delete, click the arrow that appears, and then click Delete on the menu that appears.

  3. Click OK to confirm the deletion.

Reorder crawl rules

After you create new crawl rules or edit existing ones, we recommend that you specify the order in which you want the rules to be applied when content is crawled. Crawl rules are applied in the order in which they are listed. Therefore, if two rules cover the same or overlapping content, the first rule that is listed is applied. Use the following procedure to specify the order of your crawl rules.

Reorder crawl rules

  1. On the Search Administration page, in the Crawling section, click Crawl rules.

  2. On the Manage Crawl Rules page, in the Order column in the list of crawl rules, select a value in the list that specifies the position you want the rule to occupy. Other values are shifted accordingly.


Working with federation (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In Search Server, federation enables end users to issue a query that searches multiple sources and displays results in separate Web Parts on a single search results page. These sources can be enterprise content repositories, other search engines, or portions of your Search Server index. Using federation enables you to provide more extensive query results for your users without devoting your server resources to crawling and indexing content.

The following articles provide information to help you understand and use federation.

Getting started

The following articles provide an introduction to federation.

  • Federating search results from other locations (Search Server 2008) This article in the Search Server product Help introduces federation concepts and features. To read this article, go to the Search Administration page in Search Server, and then in the I Want To section, click Federate results from other locations.

  • Set up a federation connector (Search Server 2008) This article explains how to locate a data source in your enterprise or on the Web that provides information that your users need, and how to connect to the data source by using federation.

  • Work with triggers and query templates (Search Server 2008) This article describes the two types of triggers that are available and how to construct a query template for a federated location.

  • Federated Search Overview This article provides a more technical overview of federation concepts. It discusses the differences between indexing and federation, the details of a federated location, representation of federation to the end user, and programmatic access to federation.

  • Plan the end-user search experience (Search Server 2008) This article provides information about how you can use federation to help end users quickly find the information they need.

Building or customizing a federated connector

The following technical articles on MSDN discuss common federation customizations and guide the technical administrator or developer in creating more complex federated connectors. A complex connector is required when the source is not the local search index and does not natively provide a searchable feed.

  • Architecture Guidance for Building Federated Search Connectors This article discusses requirements for creating a federated connector for Search Server and provides some architectural guidance.

  • Customizing the Search User Interface This article contains multiple topics that address the most common visual customization scenarios for federation. The article walks you through the rendering transformation (XSLT) for federated locations and describes customizations you can use to change how the results are displayed in the federated search Web Parts.

  • Location Definition File Schema Reference This article discusses each element of the federated location definition schema. The article explains how locations are defined and how to create raw location definition (.fld) files.

  • Creating a Custom Federated Search Web Part with a Credentials UI This article explains how to create a user interface that collects user credentials for federated locations.

Connector examples and code samples

The following technical articles on MSDN provide examples of federated connectors to sources that do not have searchable feeds. The articles include code samples and walkthroughs.

  • SQL Server Database Federated Connector Sample This article includes a code sample to walk you through creating a federated connector to a SQL database.

  • HTML to RSS Federated Connector Sample This article includes a code sample to help explain how to create a federated connector that converts HTML into an RSS feed that can be consumed by a federated location.

  • Federation Code Samples This MSDN code gallery provides samples of federation connector code that is used in MSDN articles.

Troubleshooting

The following articles address issues that you may encounter while you are configuring federated locations.

  • Configure proxy settings for federated sources (Search Server 2008) This article explains how to specify a proxy server for federation so that the server does not block federated queries.

  • Repair federated locations (Search Server 2008) This article provides troubleshooting information for resolving common configuration issues related to federation.


Set up a federation connector (Search Server 2008)
DropDown image

Updated: 2008-03-03

Federation in Microsoft Search Server 2008 enables end users to submit a query that searches multiple data sources and combines the results into a single search results page.

These data sources can include:

  • Your company's enterprise content repositories.

  • Internet search engines or subscription-based services used by your company.

  • Enterprise documents indexed by Search Server 2008 in other company division or world regions.

When the end user submits a query, Search Server 2008 formats and renders the results together with your indexed results.

This article summarizes step-by-step how to use federation connectors to connect to data sources in the enterprise or on the World Wide Web.

Step 1: Identify the need for specific information

Consider the searching needs and habits of the end users in your company. What content do end users need to find to be productive? What search queries are they currently using?

If you have never worked with federation before, see Plan the end-user search experience (Search Server 2008) for a list of issues to consider when planning the search experience for the end users in your organization.

Step 2: Locate a suitable data source

After you have identified a specific need for information, you need to find a data source that provides that information. One example of a suitable data source is a searchable XML feed, preferably RSS that returns information based on a query. You can look for and evaluate existing data sources and feeds within your organization and on the World Wide Web that might provide the content that your end users need.

The following are some of the ways of finding and obtaining a suitable feed for a data source:

  • Check the Online Gallery to see if a federated connector already exists. You can download and import connectors that meet your needs.

  • Check to see if your repository, Web site, or application already has a feed. You can use Windows Internet Explorer 7 to help you detect if a Web site has an existing RSS feed. When a compatible feed is available on a site, the RSS icon on the Internet Explorer toolbar turns orange. If a feed is available, make sure the feed is query-dependent by using a parameter such as ?q=searchTerms.

  • If you are looking for Web content, try using a search engine with a restricted search to your content. For example, you can use Live Search to search Wikipedia content by using the following query: search terms site:www.wikipedia.com.

  • If you are looking for Web content but there isn't a feed or it is not being searched by a search engine, try using an interface to convert HTML to RSS. For more information, see Architecture Guidance for Building Federated Search Connectors.

  • If you control the repository or application, you can expose a feed through code.

  • If you don't control the source, you can create an interface that exposes a feed to allow communication between Search Server 2008 federation and the data source. For example, you can create a simple .aspx page that runs a database query based on passed parameters and returns XML. For more information, see Federated Search Connector Sample).

    You can also create a more sophisticated transform that calls the repository's Object Model based upon the query, and then formats the search results before returning XML.

Note Note:

If you create your own feed, we recommend making the location OpenSearch and RSS-compliant.

You should consider including a mix of internal and external data sources in your federated search solution. For a technical background about federation in Search Server 2008, see the Federated Search Overview.

Step 3: Connect the data feed to a federated location

After you have located a feed, it is easy to connect it to a federated location. You can create a new federated location for the feed, or import and customize an existing one, by using the Manage Federated Locations page in Search Server 2008 or by creating your own definition text. In either case, a federated location is comprised of the following information:

  • Location type

  • Query and More Results link templates

  • Triggers

  • Display information

  • Restrictions

  • Authentication and credentials information

This information is stored in the Search Server 2008 federation system and can be exported and imported through a Federation Location Definition (*.fld) file.

Search Server 2008 allows you to connect to the most popular data sources without writing any code by downloading federated connectors from the Online Gallery. These connectors are authored by the Search Server 2008 partner community.

Note Note:

To use *.fld files that you have downloaded, open the Search Administration page in Search Server 2008, click Federated Locations, and then click Import Location.

See Also

Concepts

Configure proxy settings (Search Server 2008)
Repair federated locations (Search Server 2008)

Other Resources

Federated Search Overview
OpenSearch Specification
Architecture Guidance for Building Federated Search Connectors
Location Definition File Schema Reference
Creating a Custom Federated Search Web Part with a Credentials UI
Federated Search Connector Sample


Repair federated locations (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In Microsoft Search Server 2008, federation enables end users to issue a query that searches multiple sources and combines the results into a single search results page. These sources can be enterprise content repositories, other search engines, or portions of your Search Server 2008 index. The source is defined by a federated location.

Configuration issues might occasionally cause federated search results to appear incorrectly or not at all. This article describes some of the common scenarios in which federated locations can stop working correctly and it provides troubleshooting information to help you resolve such issues.

Note Note:

If you are unfamiliar with federated locations, please read the federation overview before attempting to troubleshoot a location. To find this overview, on the Search Server 2008 Search Administration page, in the I Want To section, click Federate results from other locations, and then read the article that is displayed.

Correcting configuration errors

Search Server 2008 provides limited contextual error checking when you create or import a federated location by attempting to verify the information that you enter on the Add Federated Location or Edit Federated Location pages. For example, omitting required information or entering invalid data in the fields on the Add Federated Location page will cause an error message to be displayed, in which case the location cannot be saved until the problem is corrected.

Note Note:

Error checking on Search Server 2008 federation configuration pages does not provide validation of feed URLs, security credentials, or custom XSL code. You should manually verify such information before entering it on the configuration pages for federated locations.

Testing search results

After you have created a federated location, ensure that it is correctly configured by connecting it to the Federated Search Results and the Top Federated Results Web Parts and then submitting a test query.

At first glance, a federated location that returns search results might appear be working correctly. However, if the location was newly created, imported or recently modified, you should carefully review the search results before you make them available to your users.

Resolving incorrect search results

If the search results appear incorrect or incomplete, try one or more of the following troubleshooting steps:

Problem Verification Test More Information

Federated results are different from source results.

Verify that you have specified a valid Query Template.

On the Edit Federated Location page, in the Location Information section, verify the syntax of the Query Template that you have specified.

If the template is invalid, it will not correctly pass queries to its associated location.

Note Query templates are case-sensitive.

"More Links" does not work or does not go to its expected destination.

Verify that you have specified a valid "More Results" Link Template.

On the Edit Federated Location page, in the Location Information section, verify the syntax of the "More Results" Link Template that you have specified.

If the template is invalid, full search results will not be correctly displayed when a user clicks the More Results link.

Search results appear poorly formatted, do not incorporate the expected source metadata (text or images), or the location does not render properly in a Windows SharePoint Services-compatible editor.

Verify the validity of any custom XSL code, formatting properties, or sample data that you have entered for either the Federated Results Web Part or the Top Federated Results Web Part.

If you have not done so already, you may want to customize the XSL and Properties defaults to return more appropriate data for the location.

On the Edit Federated Location page, in the Display Information section, verify the validity of any custom code you have entered in the XSL, Properties, or Sample Data fields. Search Server 2008 does not automatically validate code in these fields, and it is the responsibility of the administrator to ensure that valid code is entered.

If you suspect an error in the XSL or Properties code, copy any customized code you have entered, select the Use Default Formatting check box to reset the default code, and then carefully re-add any custom code to resume testing.

As with all custom coding, start with a simple modification, save it, and test the location. Then, gradually add more complex code to the fields in this section and test the results again.

Results appear altered or do not appear properly in different browsers or at screen resolutions.

Verify the results in another Web browser and at different screen resolutions.

End users might have different computer and monitor configurations than you do. To thoroughly verify the expected display of federated search results, test the location in different Web browsers and at higher and lower screen resolutions.

If there are problems with the rending, you can likely resolve this through modifications to the location's XSL.

Other issues.

Check the ULS server logs for error messages that were logged at the time the federated location query was executed.

Unified Logging Service (ULS) log files in Windows SharePoint Services provide a running audit trail that warns of any error conditions that are detected. In most cases, checking the ULS logs can uncover important troubleshooting clues.

Resolving missing search results

If the location does not appear to return any search results, try one or more of the following troubleshooting steps:

Problem Verification Test More Information

No results are displayed, or a Location not found error message appears.

Verify that the source or host feed is working correctly.

A temporary problem at the host source might occasionally prevent a federated location from fetching and displaying search results from that source.

Try manually browsing or connecting to the host source to ensure that it is working correctly outside of the federation system.

Ensure also that the Query Template is specified correctly.

No results are displayed, or a Location not found error message appears.

Verify that Search Server 2008 is properly configured to use a proxy server for search.

Search services administrators can specify proxy server settings for crawling content and querying federated sources on computers in other networks, such as the Internet. In many cases it is necessary to use a proxy server to bypass intranet security restrictions.

If the ULS logs for your server contain HTTP errors (such as 404 Not Found errors), and your corporate network uses a proxy server to connect to the Internet, ensure that federation proxy settings are properly configured.

For more information, see Configure proxy settings (Search Server 2008).

No results are displayed or an Invalid Authentication error message appears.

Verify that locations requiring authentication are properly passing the necessary credentials.

If one or more of your federated locations requires user authentication, verify that you have specified the necessary credentials in the Specify Credentials section on the Edit Federated Location page.

If, on the Edit Federated Location page, the Location Type is set to Search Index on this Server, Search Server 2008 uses default authentication. However, if the Location Type is set to OpenSearch 1.0/1.1, the Specify Credentials section will offer advanced options, including several user-based authentication protocols. If you are using a user-based authentication protocol, ensure that you either have Kerberos enabled or you are collecting user credentials through your own Web Part.

No results are displayed or a visualization error appears.

Verify the validity of any custom XSL code, formatting properties, or sample data that you have entered for either the Federated Results Web Part or the Top Federated Results Web Part.

On the Edit Federated Location page, in the Display Information section, verify the validity of any custom code you have entered in the XSL, Properties, or Sample Data fields. Search Server 2008 does not automatically validate code in these fields, and it is the responsibility of the administrator to ensure that valid code is entered.

If you suspect an error in the XSL or Properties code, copy any customized code you have entered, select the Use Default Formatting check box to reset the default code, and then carefully re-add any custom code to resume testing.

As with all custom coding, start with a simple modification, save it, and test the results. Then, gradually add more complex code to the fields in this section and test the results again.

No results are displayed.

Verify that the trigger type you have selected matches the query for your location.

A federated location is searched only when a user's query matches the trigger for that location.

On the Edit Federated Location page, in the General Information section, verify that the appropriate Trigger type is selected. If the current selection is set to Prefix or Pattern, try changing it to Always and test whether any search results appear.

Other issues.

Check the ULS server logs for error messages that were logged at the time the federated location query was executed.

Unified Logging Service (ULS) log files in Windows SharePoint Services 3.0 provide a running audit trail that warns of any error conditions that are detected. In most cases, checking the ULS logs can uncover important troubleshooting clues.


Configure proxy settings for federated sources (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

A search services administrator can specify proxy server settings for sending HTTP requests to crawl content and query federated sources. A proxy server is a computer that functions as an intermediary to forward a client request to another server and return the results to the client. Using a proxy server can help enhance intranet security and help improve response times for client requests.

Important Important:

This article explains how to configure proxy server settings on the Manage Farm-Level Search Settings page. You must be a search services administrator to configure proxy settings on this page. For more information, see Add or remove a search services administrator (Search Server 2008).

In this article:

  • Configuring Search Server 2008 to use a proxy server

  • Specifying that a proxy server should not be used

  • Understanding proxy settings for federated sources

Configuring Search Server 2008 to use a proxy server

Use this procedure to specify proxy server settings for crawling content and querying federated sources on computers in other networks.

To configure proxy server settings for search

  1. On the Search Administration page, in the Crawling section, click Proxy and Timeouts. The Manage Farm-Level Search Settings page appears.

  2. In the Proxy Server Settings section, click Use the proxy server specified, and then do the following steps:

    • To use the same proxy server settings when querying any federated source, select the Use these proxy settings for access to federated sites check box. For more information, see Understanding proxy settings for federated sources later in this article.

    • In the Address box, type either the NetBIOS name or the IP address of the proxy server.

    • In the Port box, type the port number to use for this proxy server.

    • To bypass this proxy server when crawling local addresses, select the Bypass proxy server for local (intranet) addresses check box.

    • To bypass the proxy server when crawling particular IP addresses, type the site host names or IP addresses in the Do not use proxy server for addresses beginning with box. Separate host names or IP addresses with semicolons (;).

  3. Click OK.

Specifying that a proxy server should not be used

Follow this procedure to specify that a proxy server should not be used for crawling content or querying federated sources on computers in other networks.

To specify that a proxy server should not be used for search

  1. On the Search Administration page, in the Crawling section, click Proxy and Timeouts.

  2. On the Manage Farm-Level Search Settings page, in the Proxy Server Settings section, click Do not connect by using a proxy server.

  3. Click OK.

Understanding proxy settings for federated sources

In Search Server 2008, there are two ways to specify proxy server settings for querying federated sources. Before querying a federated source, Search Server checks in the following order for proxy settings and uses the first settings it finds to connect to the federated source:

  1. The Manage Farm-Level Search Settings page. Proxy settings specified on this page apply to all federated locations.

    We recommend using this method if your organization has only one proxy server for querying federated sources.

  2. The .NET web.config file of the SharePoint site hosting the federated location. There is one web.config file for each SharePoint site. This file is used by all federated locations on that site. Search Server uses the settings in the web.config file as the default proxy settings for federated locations on that site.

    This method allows you to specify a proxy server for each SharePoint site that hosts federated locations. However, using web.config file settings for this purpose can be slow or unsuccessful.

See Also

Concepts

Specify time-out settings (Search Server 2008)
Change the contact e-mail address (Search Server 2008)


Federating search results from other locations (Search Server 2008)
DropDown image

Updated: 2008-07-31

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

A federated search is the simultaneous querying of multiple online databases (locations) for the purpose of generating a single search results page for end users.

When you add a federated location to Search Server 2008, end users can search for and retrieve content that has not been crawled by your server. Federated locations allow queries to be sent to remote search engines and feeds, after which Search Server 2008 formats and renders the results to your end users as part of your crawled content.

This article provides an overview of getting started with federated locations in Search Server 2008 — administrator tasks, supported technologies, and security considerations.

In this article

Overview of federated locations

Managing federated locations

Security considerations for federated locations

Modifying Web Part properties for federated locations

Overview of federated locations

If a specific site is not crawled by the index server in your server farm directly, you can add it as a federated location and include its search results for users of the Search Center site.

Search Server 2008 supports the following types of federated locations:

  • Search index on this server

    You can use any local or remote site in your organization that has a server that is running Search Server 2008 as a federated location. For example, imagine that a SharePoint site on a Human Resources server in your company is the only available source of employee contact information. Even if the site is not part of your crawl scope, you can configure a federated location for it so that users who initiate a search from your Search Center site can retrieve employee contact information results.

  • OpenSearch 1.0 or 1.1

    You can use any public Web site that supports the OpenSearch standard as a federated location. An example of such a location is an Internet search engine such as Live Search, or a search results page that supports RSS or Atom protocols. For example, imagine that you want users who search your internal sites for proprietary technical research to also see related research information from public Web sites. By configuring a federated location for a Live Search query, up-to-the-minute Web search results will be automatically included for your users.

When a search query is sent to a federated location, it is sent as URL parameters in a format called a query template. Office SharePoint Server then formats and renders the results as XML for users of the Search Center site. The XML is displayed in a Web Part on the search results page as readable text.

You can add and configure Web Parts on the search results page as either a Federated Search Results Web Part or a Top Federated Results Web Part. By default, the search results page contains three Federated Search Results Web Parts.

Tip Tip:

To display federated search results on a page other than the default search results page, simply add a Federated Search Results Web Part or a Top Federated Results Web Part to the page on which you want to display the federated search results.

By editing the properties and Extensible Stylesheet Language (XSL) code of a federated location, you can control aspects of its search results, such as the metadata that will be shown or the number of links that will be displayed. You can also control the appearance of the search results, such as the color or font style of the link text. If you use trigger rules, you can modify the query that is sent to the federated location when a user types a specific prefix or pattern.

Using federated locations with the Search Index on this Server option

When adding local index federated locations to Search Server 2008, the following conditions apply:

  • The location is set to Search Index on this Server.

  • No query template is required. Search Server 2008 uses the object model to query a location.

  • Default server authentication is used.

  • Advanced search queries are not supported.

Note Note:

Federated locations for remote search indexes are configured in the same way as for a location that is based on OpenSearch, by using the remote server's RSS feed.

Using federated locations with OpenSearch

When adding federated locations that are based on OpenSearch to Search Server 2008, the following conditions apply:

  • Queries can be sent to a search engine as a URL, such as http://www.example.com/search.aspx?q=TEST.

  • Search results are returned in RSS, Atom, or another structured XML format.

  • Note Note:

    Search Server 2008 does not support HTML or XHTML.

  • Location capabilities, query templates, and response elements are part of a Federated Location Definition (.fld) file that is associated with the location.

  • Extensions to OpenSearch that are specific to Search Server 2008 support the ability to include triggers and the ability to associate XSL code with search results.

  • The choice of metadata to display in the search results is determined by the OpenSearch location.

For more information about OpenSearch, visit http://www.opensearch.org.

Deciding whether to use federated locations

Consider the following questions when determining whether you want to display federated search results to users:

  • Do you want to display custom results for particular searches?

    To help ensure that the federated location returns results that match specific queries, you can use trigger rules. When you create a trigger rule for a federated location, the Web Part that is associated with that location displays results only for user queries that match the pattern or prefix that you specify. For example, let's say that you work at a company named Contoso, where employees and users of Search Server 2008 manufacture a product commonly referred to as a widget. If you add a federated location for Live Search, you can create a trigger for the product name that will ensure that any search for "widget" consistently returns results for "Contoso widget."

  • Can you use a URL to specify which results to retrieve for a query?

    To create a federated location, you need the query template, which is the combination of the URL and the parameters that are required to send a search query and return the results as XML. When you add this information to the Query template field on the Add Federated Location page, you must format the string correctly (as shown in the example on the page) or the federated location will not return any results.

  • Can users access the links that are provided by the federated location?

    If your organization grants only limited access to Internet resources — for example, if your users can navigate only to your company's external Web site but not to other external sites — using an Internet search engine as a federated location might frustrate users because they won't be able to view some of the search results.

  • Is authentication required?

    If the federated location requires authentication, you must provide the correct credentials. Credentials are required only for SharePoint sites. Most federated locations, such as Internet search engines, do not require credentials. For more information, see Security considerations for federated locations later in this article.

Managing federated locations

To get started with federated locations, click Federated Locations on the Search Administration page. On the Manage Federated Locations page, you can do any of the following:

  • Add or import a federated location

    You can create a new federated location by entering its settings and properties on the Add Federated Location page, or you can start by importing an existing Federated Location Definition (.fld) file. You can download definition files by clicking the Online Gallery link on the Manage Federated Locations page. For more information about importing definition files, see Downloading location definition files later in this article.

  • Edit a federated location

    You can edit a federated location by pointing to the name of the location on the Manage Federated Locations page, clicking the arrow that appears, and then clicking Edit Location. On the Edit Federated Location page, you can modify the properties and metadata for the location, such as how search results are displayed or whether to add trigger rules that return results only when user queries match a specific pattern or prefix. You can also modify the XSL code in the Federated Search Results Display Metadata section or the Top Federated Results Display Metadata section to change the formatting of elements, such as the title or links in the Federated Search Results Web Part or the Top Federated Results Web Part.

  • Copy a federated location

    You can copy a federated location by pointing to the name of the location on the Manage Federated Locations page, clicking the arrow that appears, and then clicking Copy Location.

  • Delete a federated location

    If you no longer want to use a federated location, you can remove it from your Office SharePoint Server site by pointing to the name of the location on the Manage Federated Locations page, clicking the arrow that appears, and then clicking Delete Location. If the federated search results page still refers to a location that has been deleted, the page will no longer include any results for that location.

    Note Note:

    You can stop displaying search results from a federated location without deleting it from the server. To do this, either delete the Web Part that you configured to display results from that location, or modify the properties for the Web Part to display search results for another federated location.

  • Export a federated location

    You can save the properties and metadata for your federated location by exporting them as a Federated Location Definition (.fld) file. You can export a federated location by pointing to the name of the location on the Manage Federated Locations page, clicking the arrow that appears, and then clicking Export Location. After you export a definition file, you can import it to another Search Center site or place it on a file share for others to use.

    Note Note:

    When exporting a federated location to a definition file, Office SharePoint Server does not include your security credentials or settings with the file.

  • View federated location details

    When you have added one or more federated locations to Office SharePoint Server, the Manage Federated Locations page automatically reports the number of user queries and clickthroughs that have been registered for all listed locations during the past 30 days. Administrators should be aware that certain search results from federated locations might never be clicked. For example, the phone number that is displayed in response to a query of "John Smith phone number" might result in the user dialing the phone number manually instead of clicking a hyperlink on the search results page.

    Tip Tip:

    You might occasionally encounter problems with a federated location, such as search results not appearing or taking a long time to appear. When you notice issues such as these, you can take steps to repair the federated location. More information about troubleshooting federated locations is available in the article "Repair federated locations" on Office SharePoint Server 2007 on TechNet (http://go.microsoft.com/fwlink/?LinkID=84739).

Downloading location definition files

The Office SharePoint Server 2007 Online Gallery has several Federated Location Definition (.fld) files that are available for download. You can access this site by clicking the Online Gallery link on the Manage Federated Locations page. After you have downloaded a definition file, save it to your hard drive, and then use the Import Location button on the Manage Federated Locations page to add the location to your site. After the location appears in the list, you can edit its settings and customize its properties.

When you create a federated location by importing a definition file, the XSL code that determines how the search results are formatted and displayed is already created for you. If you create a custom location by manually typing the properties and metadata in the Add Federated Location page, and you want to change the default appearance of the search results, you must know how to edit the XSL code for the federated location. After you configure a federated location for your site, you can also export it to be used as a federated location in another Search Center site.

Security considerations for federated locations

Depending on the location type that you specified when creating or modifying a federated location, your federated location may require authentication, in which case you must specify the authentication method that should be used.

If Search Index on this Server is selected as the Location Type the federated location, no additional authentication information is required. Users who can access the search results page will automatically see results from the federated location based on their credentials. However, if OpenSearch 1.0/1.1 is selected as the location type for a federated location, you must specify how to authenticate security credentials for that location.

Federated search locations configured for OpenSearch 1.0 or 1.1 can be authenticated in any of the following ways:

  • Anonymous Access

    Grants everyone in your organization access to federated search results in the associated location without authentication of any account credentials. To select this option, click Anonymous: This location does not require authentication in the Specify Credentials section on the Add Federated Location page or Edit Federated Location page.

  • Common Authentication

    Grants everyone in your organization a single user name and password that are used to display federated search results in the associated location. To enable this option, click the authentication option that you want under Common in the Specify Credentials section on the Add Federated Location or Edit Federated Location pages.

  • User-level Authentication

    Authenticates individual user credentials to display federated search results in the associated location. To enable this option, click the authentication option that you want under User in the Specify Credentials section on the Add Federated Location page or the Edit Federated Location page.

    Note Note:

    Although Search Server 2008 does not provide a user interface for capturing single-user account authentication credentials, it does provide APIs for validating credentials from a custom user interface.

Modifying Web Part properties for federated locations

All search results for federated locations are displayed by using two types of Web Parts: the Federated Search Results Web Part and the Top Federated Results Web Part. Before you can display search results from a federated location, you must click the name of the federated location in the Location list of the tool pane for the Web Part.

On the search results page, on the Site Actions menu, click Edit Page. Click Edit on the Web Part menu, and then click Modify Shared Web Part to open the tool pane.

You can change the following properties, which are available in the Federated Search Results Web Part and the Top Federated Results Web Part:

  • Location

    Specify the name of the federated location or locations.

  • Display Properties

    Specify the number of results to display per page, whether to limit the number of characters in the summary text or the URL that is displayed, and whether to use Location Visualization settings. In the properties of the Federated Search Results Web Part, you can additionally specify whether to display an animated graphic to indicate that the image is still loading, or whether to return results asynchronously rather than waiting to load the entire page.

  • Results Query Options

    Specify whether to remove duplicate results, whether to enable search term stemming, and whether to ignore noise words.

  • More Results Link

    Specify whether to show a More Results link, and what the text of the link should be.

Note Note:

In addition to the unique properties for federation Web Parts, all Web Parts share a common set of properties that control their appearance, layout, and advanced characteristics. You can view and modify these properties in federation Web Parts in the same ways as you can for any non-federation Web Parts. For more information about using common property settings, see "Customize Web Parts" in the Microsoft Windows SharePoint Services Help.


Work with triggers and query templates (Search Server 2008)
DropDown image

Updated: 2008-07-31

If a specific site is not crawled by Microsoft Search Server 2008 directly, you can add it as a federated location and include its search results for users of the Search Center site. When you add a federated location, you must specify the query template that is used for the query URL of the federated location. Optionally, you can also specify one or more query constraints, known as triggers, to restrict the queries that are passed to the federated location.

In this topic you'll learn more about specifying triggers and how to construct the query template for a federated location.

Triggers

A trigger is a query constraint that determines when a query is passed. When you create a federated location you can specify triggers that determine when a query is passed to it. Only queries that match the pattern specified for the triggers in the location definition are forwarded to the federated location.

There are two types of triggers:

  • Prefix

    The query must be prefixed with the exact term that is specified as the trigger. For example, if "weather" is specified as the prefix trigger, for the query "weather New York, NY" the prefix is dropped and only "New York, NY" is forwarded."

    Note Note:

    Only the portion of the query that follows the prefix is forwarded; in the example "weather New York, NY", only "New York, NY" is forwarded to the federated location.

  • Regex

    The query must match the specified regular expression pattern. For more information about creating regular expressions, see .NET Framework Regular Expressions (http://go.microsoft.com/fwlink/?LinkId=117945).

Query templates

The query template contains the parameterized URL for the federated location, and search queries are passed to this URL. The parameterized URL must return structured XML results (for example, RSS or Atom results).

Search Server 2008 supports two types of federated locations:

  • Search Index on this Server

    The query template for the Search Index on this Server federated location type should contain the searchTerms parameter that you specify as follows: {searchTerms}

    It should also contain any additional query restrictions, such as a search for content from a specific author, as shown in the following example: Author:"{searchTerms}"

    The query template for this type of federated location should not include the search results URL.

  • OpenSearch

    Any Internet site that supports the OpenSearch standard

The query template is equivalent to the URL template in the OpenSearch Specification (http://go.microsoft.com/fwlink/?LinkId=111090). The syntax is based on the URL template syntax (http://go.microsoft.com/fwlink/?LinkId=100718). Following is a simple example of a location query template that contains a parameterized URL to connect to the Live Search service: http://search.live.com/results.aspx?q={searchTerms}&format=rss

In this example, the query template contains the OpenSearch template parameter searchTerms. The searchTerms parameter is a placeholder for the search words that are forwarded to the federated location. You can specify additional parameters in the query template. For more information about these parameters, see the OpenSearch 1.1 parameters section (http://go.microsoft.com/fwlink/?LinkId=100720) in the OpenSearch specification.

You can indicate whether a parameter is optional by including a question mark character (?) after the parameter name. In the following example, the searchTerms parameter is required, but the startIndex parameter is not: http://search.live.com/results.aspx?q={searchTerms}&format=rss&first={startIndex?}

Note Note:

Parameters that you specify in the URL template must be URL-encoded. In the previous example, the ampersand character (&) is replaced with the URL encoding for this character, "&".


Wiley: Professional Microsoft Search: SharePoint 2007 and Search Server 2008
DropDown image

Updated: 2009-07-23

Read excerpts from the Wiley book, Professional Microsoft Search: SharePoint 2007 and Search Server 2008.

Buy this book

Professional Microsoft Search: SharePoint 2007 and Search Server 2008 sheds light on SharePoint Search in the enterprise and focuses solely on Microsoft Search technology. This book is intended for a range of folks from the IT administrator to the developer writing search applications. The book tries to cover the breadth of using, administering, and developing on the SharePoint Search technologies. The developer chapters will be important for the administrator to understand, since developers and administrators have to work together to make Search work. On the flip side, the administrator chapters will be important for developers to understand the architecture and administration of Search because, without this knowledge, writing to the APIs will be more difficult. Most readers will benefit from reading all the chapters in this book

Contents

Book excerpt - Chapter 7: Extending Search with Federation

Authors

Tom Rizzo is a director in the Microsoft SharePoint product management team. Before joining the SharePoint team, Tom worked in the Microsoft Exchange and SQL Server product management teams. Tom is the author of six development books on a range of Microsoft technologies.

Richard Riley is a senior technical product manager in the Microsoft SharePoint product management team. He is responsible for driving Technical Readiness, both within, and outside of, Microsoft and specializes in Search Server 2008 and the Search features of SharePoint Server 2007. He has more than seven years of experience at Microsoft and has worked as a consultant in Microsoft Consultancy Services, and as a technical specialist in sales. He has over 10 years of industry experience and is a frequent speaker at Microsoft Technical Events.

Shane Young is a recovering Server Farm Administrator and active SharePoint zealot. From his home base in Cincinnati, Ohio, he travels the country, and sometimes the world, supporting, teaching, and evangelizing for all things Office SharePoint Server. He is the founder of his own Office SharePoint Server consulting company, and has recently been invited to speak at TechEd on the subject of upgrading SharePoint. When he is not living the glamorous life of a Microsoft MVP, he can be found spending time with his lovely new bride, Nicola, and their dogs, Tyson and Pugsley.


Helping users make successful queries (Search Server 2008)
DropDown image

Updated: 2009-07-23

Some features in Microsoft Search Server 2008 that can be used to enhance the end-user experience are search scopes — properties assigned to content, stored during indexing, and mapped to managed properties made available for searches; and keywords defined by the search services administrator, with their definitions, synonyms, and Best Bet sites.

This topic provides links to articles that describe the features that can enhance the search experience in Search Server 2008, while also providing information about its usage and how Search Server 2008 employs these features.

Features enhancing the search end-user experience

The subsequent sections describe the different features in Search Server 2008 that can help in getting better search results, with links to topics for more help.

For more information, see Manage settings to improve search results (Search Server 2008).

Configure Web Part properties

Search Server 2008 includes a number of Web Parts that allow users to perform actions such as performing queries and viewing search results. Each Web Part has properties that are unique to that Web Part as well as properties that are common to many Web Parts, which include properties that affect the appearance of the Web Part.

For more information, see Configure Web Part properties (Search Server 2008)

Provide scopes

Scopes are properties assigned to content, stored during indexing, and mapped to managed properties made available for searches. The search services administrator defines the default scopes that can be used by the entire site collection. Site collection administrators add and modify scopes, add scope display groups, and choose and arrange scopes within them.

For more information on scopes, see Define scopes for searches (Search Server 2008).

Define pages to influence ranking of search results

Authoritative pages are sites that link to the most relevant information. You can specify authoritative pages from the most valuable links to the least valuable. Search Server 2008 uses this list of authoritative pages to calculate the rank of every page in the content index.

For more information, see Configure authoritative pages (Search Server 2008).

Add keywords with Best Bets

Site collection administrators define keywords with Best Bets for use on their sites. Keywords provide definitions for common terms used within your organization. Each keyword also can include a list of synonyms and the Web addresses (URLs) for several Best Bets sites with related content.

When a query includes a keyword or any of its synonyms, the definition for that keyword and its Best Bet sites, if any, are typically displayed prominently on the search results page, above the core search results. Keywords can be used to provide a working glossary of names and terms used within your organization. When configured with synonyms and Best Bets, keywords can also enhance search results by guiding users to recommended resources.

Best Bets can link to recommended Web sites, data stores, and documents that help to explain a keyword and expand upon its meaning. When a user includes a keyword or one of its synonyms in a query, the search results page features links to its associated Best Bets above the core results. You can use Best Bets to promote recommended sites and authoritative pages.

For more information on adding keywords with Best Bets, see Add keyword terms with Best Bets (Search Server 2008).

Server name mappings

Server name mapping override how search results are displayed and how users access content after you create a content index.

For more information on server name mappings, see Manage server name mappings (Search Server 2008).

Metadata properties

Content creators assign property values to their content, including document titles, file names, and author. Web site owners manage shared libraries and lists that can also assign further properties to content. For example, libraries can provide defined content types that require content creators to assign values to properties in order to check in a document. Custom columns within document lists also assign property values to content.

For more information about using metadata properties, see Manage metadata property mappings (Search Server 2008).

Query processing

Search Server 2008 with Service Pack 2 (SP2) includes the following two query-related Stsadm operations:

  • Setqueryprocessoroptions: Stsadm operation (Office SharePoint Server)

  • Listqueryprocessoroptions: Stsadm operation (Office SharePoint Server)

Results highlighting

The April 2009 cumulative update for Search Server 2008 includes the following two Stsadm operations:

  • Getosearchsetting: Stsadm operation (Office SharePoint Server)

  • Setosearchsetting: Stsadm operation (Office SharePoint Server)


Define scopes for searches (Search Server 2008)
DropDown image

Updated: 2008-03-03

To focus a search on particular locations or content, end users select scopes from the scope list beside the Search box. They can choose All Sites to search all available locations and their content. They can also limit their searches to certain locations or to content marked with particular property values. For example, a query on the This Site scope (if available) focuses the search on the current site and its subsites.

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Default scopes, such as All Sites, are defined by default and are shared among all end-user site collections. A site collection administrator can copy a default scope and modify that copy and can add more scopes for use within the site collection. The site collection administrator creates scope display groups and arranges scopes within them, so that site owners can apply them to modify instances of the scope list on their pages.

Note Note:

By default, the scopes picker on the Advanced Search page is hidden. However, an administrator with permission to edit the Advanced Search page can choose to modify the Advanced Search Web part to display its list and assign a display group to populate it with scopes.

In this article:

  • Planning scopes

  • Displaying the View Scopes page

  • Defining or editing a scope

  • Adding or editing scope rules

  • Deleting a scope or scope rules

  • Configuring scope display groups

  • Assigning a display group to a scope list

Planning scopes

An administrator defines scopes so that users can focus their searches on particular locations and content. When defining a scope, you can combine location rules with property rules to limit searches as desired. For example, a scope can direct a query to particular sites, or to documents marked with particular property values.

Note Note:

Property values are available to searches by using the managed properties feature to which certain content properties are mapped. A drop-down list of the managed properties that can be used in scopes appears in the Property Query section of the Create Scope page and the Edit Scope page. See the later section Adding or editing scope rules.

Displaying the View Scopes page

To access the View Scopes page to add or modify scopes and scope display groups, you need to have site collection administrator permissions.

Display the View Scopes page

  1. Log on to the Search Center site with site collection administrator permissions.

  2. Click the Site Actions menu, and choose Site Settings.

  3. On the Site Settings page, in the Site Collection Administration section, click Search scopes. This displays the View Scopes page.

  4. To define a new scope, click New Scope, and then follow the steps in the next section, Defining or editing a scope.

    To edit the rules for an existing scope, click the Add rules link when it appears under Update Status, and then follow the steps in the later section Adding or editing scope rules.

    To define a custom display group and arrange scopes within it, click New Display Group, and then follow the steps in the later section Configuring scope display groups.

Defining or editing a scope

Scopes make it possible to focus searches on particular locations or materials. An administrator with site collection administrator permissions can copy a default scope and modify that copy, and can also add scopes for use within the site collection.

When adding a custom scope to a site collection, it can be helpful to begin by copying a default scope such as All Sites, and then add rules that specify locations, content types, or property values. By combining and adjusting multiple rules, the administrator can design scopes that provide focused searches tailored to the needs of particular work groups.

Define or edit a scope

  1. Follow the steps in the previous section Displaying the View Scopes page.

  2. Click New Scope to display the Create Scope page.

    Or click the name of an existing scope to display the Scope PropertiesandRules page, and then click Change scope settings to display the Edit Scope page.

  3. In the Title box, type a word, name, acronym, or short phrase to display in the Scopes list.

  4. In the Description box, explain the purpose of the scope. This is an optional description, for your reference, and does not display to end users.

  5. In the Display Groups section, choose where to display this scope, for example, Search drop-down list.

  6. In the Target ResultsPage section, choose whether to display the results from searches of this scope on the default search results page or a different Web page. To use a different search results page, select Specify a different page for searching this scope, and type the Web address (URL) for another existing results page in the Target results page box. (For example, http://site/subsite/folder/CustomResultsPage.aspx).

  7. Click OK to save the scope and return to the View Scopes page.

    To add scope rules, click Add rules next to the name of the scope, and then follow the steps in the following section Adding or editing scope rules.

Adding or editing scope rules

Add or edit scope rules

  1. Follow the steps in the previous section Displaying the View Scopes page.

  2. Under Update Status, click the Add rules link next to the name of a scope. This displays the Add Scope Rule page.

    Or click the name of the scope to display the Scope Properties and Rules page, and then, in the Rules section, click an existing rule to edit that rule or click New Rule to display the Edit Scope Rule page and create a new rule.

  3. In the Scope Rule Type section of the page chosen, choose a type of rule. The choices are Web Address, Property Query, Content Source, or All Content.

    • To include or exclude a location, choose Web Address, and type a location in one of the boxes. (To apply rules to multiple locations, define a separate rule for each location.)

      If you type a path in the Folder box (for example, http://site/subsite/folder), the rule applies only to items located within the folder indicated and its subfolders.

      If you type a host name in the Hostname box, the rule applies to items located anywhere on that host.

      If you type a domain name in the Domain or subdomain box (for example, widgets.msn.com), the rule applies to all items located within that domain.

    • To include or exclude content found by searching on a value assigned to a managed property, choose Property Query. Select a property, and then enter a value. (To apply rules to multiple properties or values, define a separate rule for each property setting.)

      To make additional managed properties available for use in scopes, navigate to the managed properties list, and then select Allow this property to be used in scopes for the desired managed properties. To navigate to the managed properties list, go to the Search Administration page, and, under Queries and Results, click Metadata properties.

    • To create a scope that includes anything that is crawled by the content source called Local Office SharePoint Server sites, under Scope Rule Type choose Content Source, and under Content Source select Local Office SharePoint Server sites.

    • To apply a rule to all content from all sites included in the search index, choose All Content.

  4. Select a Behavior to choose how this rule combines with other rules to define the scope. Choose Include for an "OR" rule, or Exclude for an "AND NOT" rule, or Require for an "AND" rule, and click OK to apply the rule.

Note Note:

Search scopes and their rules are compiled on a schedule that is adjusted automatically based on the frequency of past updates. The search services administrator can also set scope updates to occur manually. A new scope does not appear in a Search Box scope list until after its first compilation.

Deleting a scope or scope rules

To delete scopes or scope rules, follow the steps in the previous section Displaying the View Scopes page. Then do the following:

Deleting a scope

Delete a scope

  1. Move the cursor over the name of the scope on the View Scopes page, expand the menu that appears, and then click Delete.

  2. When you are prompted, click OK.

Deleting scope rules

Delete scope rules

  1. Move the cursor over the name of a scope on the View Scopes page, expand the menu that appears, and then click Edit Properties and Rules. This displays the Scope Properties and Rules page.

  2. To delete an individual scope rule:

    1. Click the name of the rule on the Scope Properties and Rules page.

    2. At the bottom of the Edit Scope Rule page, click Delete.

  3. To delete all rules for a scope:

    1. Find the Rules section of the Scope Properties and Rules page.

    2. Click Delete all rules.

Configuring scope display groups

An administrator with site collection administrator permissions can create a new scope display group and arrange scopes within it, or add scopes to existing display groups.

Creating or editing scope display groups

To enable a site owner to change the scopes available from the scope list beside a Search box, a site collection administrator can modify existing display groups, or create new display groups and arrange scopes within them. A site owner can then use this new display group to modify the scope list in instances of the Search Box Web Part.

Create or edit scope display groups

  1. Follow the steps in the previous section Displaying the View Scopes page.

  2. Click New Display Group to display the Create Scope Display Group page.

    Or click the name of a custom display group to display the Edit Scope Display Group page.

  3. On the page selected, type a Title that helps site owners to identify the display group.

  4. Type a Description that explains the range of scopes provided in this display group, and where these choices might be useful.

  5. In the Scopes section, select the check box next to each scope to include in the display group.

  6. Use the Position from Top lists to adjust the order of scopes within the display group.

  7. In the Default Scope list, choose the scope to be selected when the scope list is displayed, and searched if the user does not change the selection.

  8. Click OK to finish creating the new display group.

Including a scope in display groups

A scope can be added to existing display groups from the Edit Scope page.

Include a scope in display groups

  1. Follow the steps in the previous section Displaying the View Scopes page.

  2. Click the name of a scope for which to Edit Properties and Rules.

  3. On the Scope Properties and Rules page, click Change scope settings in the Scope Settings section.

  4. On the Edit Scope page, select any Display Group to include in this scope, and clear any not to include.

  5. Click OK to save your changes.

Assigning a display group to a scope list

Assign a display group to a scope list

  • Log on to the Search Center site with Designer permissions or higher.

Note Note:

An administrator with site collection administrator permissions can modify any Web site within the site collection. A site owner can modify all pages on one site.

  1. Click the Site Actions menu, and choose Edit page.

  2. Move the cursor to the Search Box Web Part, expand its Edit menu, and choose Modify Shared Web Part.

  3. Within the Search Box tool pane, click the plus sign (+) to expand the Miscellaneous section.

  4. Scroll to the Scope Display Group box, type the name of the display group that furnishes the scopes for this scope list, and then click Apply.

  5. Make any other changes desired, and then click OK to close the tool pane.

See Also

Concepts

Helping users make successful queries (Search Server 2008)


Configure Web Part properties (Search Server 2008)
DropDown image

Updated: 2009-07-23

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Search Server 2008 includes a number of Web Parts that allow users to perform actions such as performing queries and viewing search results. Each Web Part has properties that are unique to that Web Part as well as properties that are common to many Web Parts, which include properties that affect the appearance of the Web Part. .

In this section:

  • Configure properties for the Search High Confidence Results Web Part (Search Server 2008)

  • Configure properties for the Search Core Results Web Part (Search Server 2008)

  • Configure properties for the Search Box Web Part (Search Server 2008)

To configure properties that are common across Web Parts

Use this procedure to configure properties that affect the appearance of a Web Part.

Important Important:

Membership in the Designers SharePoint group is the minimum that is required to complete this procedure.

Configure properties that are common across Web Parts

  1. On the Search Center site that you want to configure, click Site Actions, and then click Edit Page. On the Edit menu for the Web Part whose appearance you want to change, click Modify Shared Web Part.

    Note Note:

    To change a Web Part that is on the Search Results page, run a search query. When the Search Results page appears, click Site Actions, and then click Edit Page. On the Edit menu for the Web Part whose appearance you want to change, click Modify Shared Web Part.

  2. Expand the Appearance node:

    • In the Title box, type the text you want to display in the Web Part title bar.

    • In the Height box, type a number of pixels, and then click Yes to set a fixed height for the Web Part frame on the page. If No is selected, the height of the Web Part adjusts automatically within the zone.

    • In the Width box, type a number of pixels, and then click Yes to set a fixed width for the Web Part frame on the page. If No is selected, the width of the Web Part adjusts automatically within the zone.

    • In the Chrome State box, select Minimized to display the Web Part with only the title bar visible. Select Normal to display the Web Part body and title bar.

    • In the Chrome Type box, select the kind of border that you want to display around the Web Part. This also determines how the title bar of the Web Part is displayed.

  3. Expand the Layout node:

    • Select the Hidden check box if you want to hide the Web Part on the page. Clear the check box to display the Web Part.

    • In the Direction box, select Left to Right to display the components in this Web Part from left to right. Select Right to Left to display the components in the Web Part from right to left..

    • In the Zone list, select a zone in which you want the Web Part to display.

    • In the Zone Index box, type the number that determines the order of the Web Part in a zone. Web Parts that are assigned lower numbers are displayed above Web Parts that are assigned higher numbers.

  4. Expand the Advanced node:

    • Select the Allow Minimize check box to allow users to minimize this Web Part.

    • Select the Allow Close check box to allow users to close this Web Part. A closed Web Part is not deleted from a page.

    • Select the Allow Hide check box to allow the value in the Hidden property to be modified. The Hidden property is in the Layout node.

    • Select the Allow Zone Change check box to allow the value in the Zone property to be modified. The Zone property is in the Layout node.

    • Select the Allow Connections check box to allow this Web Part to share data with other Web Parts. Connect data in Web Parts.

    • Select the Allow Editing in Personal View check box to allow users to personalize this Web Part.

      Note Note:

      Some Web Parts do not allow a personal view.

    • In the Export Mode box, select Export All Data to put no restrictions on the data that is exported from the Web Part. Select Non-Sensitive Data Only to restrict the data that is exported from the Web Part.

    • In the Title URL box, type the URL of the page that is opened when a user clicks the title of the Web Part.

    • In the Description box, type the text that displays when the user's mouse hovers over the title bar of this Web Part.

    • In the Help URL box, type the URL of the page that users are directed to when the user clicks the Help icon.

    • In the Help Mode box, select how the Help window displays when the Help icon is clicked.

    • In the Catalog Icon Image URL box, type the path of the image file that displays for this Web Part when the user is browsing a list of available Web Parts that can be added to a page.

    • In the Import Error Message box, type the text that explains that the attempted import of this Web Part failed.

    • In the Target Audiences box, select one or more groups of users who can import this Web Part.

  5. After you have made the changes that you want, click OK to close the tool pane.

See Also

Concepts

Add content sources (Search Server 2008)
Configure searches to return blog post results (Search Server 2008)
Configure client certificates for crawling an SSL site (Search Server 2008)


Configure properties for the Search Box Web Part (Search Server 2008)
DropDown image

Updated: 2009-07-23

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

The Search Box Web Part displays the box in which a user enters a query string for a search. You can edit the properties of this Web Part to change how the Web Part appears and responds to users.

To configure Search Box Web Part properties

Use this procedure to configure the properties of the Search Box Web Part.

Important Important:

You must have at least Designer permissions to complete this procedure.

Configure Search Box Web Part properties

  1. Navigate to the search center site.

  2. In the Search Center, click the Site Actions menu, and then click Edit Page. The Search page opens in Edit mode.

  3. In the Search Box Web Part, expand the Edit drop-down list, and then click Modify Shared Web Part.

  4. In the Search Box tool pane, expand the Scopes Dropdown node.

    • Expand the Scopes drop-down list. In the Dropdown Mode list, select one of the following available options:

      Do not show scopes dropdown

      Does not display a scope drop-down list. This is the default setting for the Search Box Web Part.

      Show scopes dropdown

      Displays the scopes defined in the scope display group in the scopes drop-down list.

      Show, and default to 's' URL parameter

      Displays the scopes defined in the scope display group in the scopes drop-down list. Also, adds the scope to the page URL using the 's' parameter.

      Show, and default to contextual scope

      Displays the scope drop-down list and automatically selects the "This site" or "This list" scope.

      Show, do not include contextual scopes

      Does not display the "This site" and "This list" contextual scopes in the drop-down list of available scopes.

      Show, do not include contextual scopes, and default to 's' URL parameter

      Displays the scopes defined in the scope display group in the scopes drop-down list. Does not display the "This site" and "This list" contextual scopes in the drop-down list of available scopes and adds the scope to the page URL using the 's' parameter.

    • In the Dropdown label box, type the text you want to be displayed as the name for the scope drop-down list on the Search page.

    • In the Fixed dropdown width (in pixels) box, type the maximum number of pixels allowed for the box that contains the drop-down list on the Search page.

  5. Expand the Query Text Box node.

    • In the Query Text Box label box, type the text you want to be displayed as the name for the box in which users enter query terms on the Search page.

    • In the Query text box width (in pixels) box, type the maximum number of pixels allowed for the box in which users enter query terms on the Search page. By default, the width is set to 280 pixels.

    • In the Additional query terms box, type the text that you want to append to all queries submitted by users. This text can be additional terms or a property filter. For more information about keyword terms and property filters, see Using wildcard characters in property searches (Search Server 2008).

    • In the Additional query description label box, type the text that explains the purpose of additional query terms that are added to the user's query.

    • In the Query box prompt string box, type the text that displays in the query box. The text displays only until the user selects the query box.

    • Select the Append Additional Terms To Query box, if you want to display the additional query terms that are added to all user's queries. Clear this check box if you do not want the additional query terms to display in the query box.

  6. Expand the Miscellaneous node.

    • In the Search button image URL box, type the path of the image file that displays when the mouse pauses over the button that submits a query. This image must by 16 × 16 pixels. By default, the value in this box is /_layouts/images/gosearch.gif.

    • In the Search button right-to-left image URL box, type the path of the image file that displays when the mouse pauses over the button that submits a query. This image must by 16 × 16 pixels. By default, the value in this box is /_layouts/images/ goRTL.gif.

    • In the Active search button image URL box, type the path of the image file that displays when the mouse pauses over the active search button. This image must by 16 × 16 pixels. By default, the value in this box is /_layouts/images/gosearch.gif.

    • In the Active search button right-to-left image URL box, type the path of the image file that displays when the mouse pauses over the active search button. This image must by 16 × 16 pixels. By default, the value in this box is /_layouts/images/ goRTL.gif.

    • Select the Use site level defaults check box, if you want to the results page URL defined in the Search Settings page at the site collection level. This setting is overridden if the scopes drop-down list is set to Scopes Dropdown mode. By default, this check box is not selected.

    • Select the Display advanced search link check box, if you want to display a link to a search page that has advanced options. By default, this check box is selected.

    • In the Advanced Search page URL box, type the URL of the page that contains advanced search options. Search Server 2008 includes a default advanced search page for this site collection, /SearchCenter/Pages/advanced.aspx, that contains the Advanced Search Box Web Part.

    • In the Scope Display Group box, type the name of the scope display group that you want to display in the scopes drop-down list. Scope display groups are defined in the Scopes Administration page at the site collection or farm level. By default, the value of this property is Search Dropdown.

  7. After you have made the changes that you want click OK to close the tool pane.

See Also

Concepts

Configure Web Part properties (Search Server 2008)
Configure properties for the Search High Confidence Results Web Part (Search Server 2008)
Configure properties for the Search Core Results Web Part (Search Server 2008)


Configure properties for the Search Core Results Web Part (Search Server 2008)
DropDown image

Updated: 2009-07-23

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

The Search Core Results Web Part displays the relevant results of a search query. It is located on the Search Results page and contains properties that control how search results are displayed.

Note Note:

The Search Core Results Web Part includes settings that configure fixed keyword queries. Fixed keyword queries are queries that you create and configure for users. You set the keywords, property filter, or both keywords and property filters that the query contains, so that users only need to run the query. For example, if you can configure a search that helps users find most recent training videos. You can add the Search Core Results Web Part and create a fixed keyword query for the file type of the training videos and sort the results by date modified.

To configure Search Core Results Web Part properties

Use this procedure to configure the properties of the Search Core Results Web Part.

Important Important:

Membership in the Designers group is the minimum that is required to complete this procedure.

Configure Search Core Results Web Part properties

  1. In the Search Center, open the Search Results page. By default, the Search Results page is at http://searchserver/results.aspx. On the Search Results page, click the Site Actions menu, and then click Edit Page. The Search Results page opens in Edit mode.

  2. In the Search Core Results Web Part, on the Edit menu, click Modify Shared Web Part.

  3. In the tool pane, expand the Results Display/Views node.

    • In the Results Per Page box, type the number of matches that can display in a single Search Results page. The default is 10 matches per page.

    • In the Sentences In Summary box, type the number of sentences that you want to be displayed as a description for each result. The sentences displayed are from the content item that contains the search term. The default is three sentences.

    • In the Highest Result Page box, type the maximum number of pages that display the results of a query. The default is 1000 pages.

    • From the Default Results View drop-down list, select whether search results should be sorted by relevance or date modified. The default setting is to sort the results based on relevance.

    • Select the Display Discovered Definition check box if you want Microsoft Search Server 2008 to identify phrases that look like definitions and to display these at the top of the search results page. A discovered definition is labeled as What people are saying about: search query terms. This check box is selected by default.

  4. Expand the Results Query Options node.

    • Select the Remove Duplicate Results check box if you want duplicate results of the search hidden. This check box is selected, by default.

    • Select the Enable Search Term Stemming check box if you want a stemmer to generate and then add inflectional forms of query terms to the query. Stemmers are language-specific components. The language of the stemmer is determined by the language of the Web browser. For languages that do not support stemming, selecting this check box does not affect the query. The default setting of this option depends on the language.

    • Select the Permit Noise Word Queries check box if you want to allow queries that consist only of noise words. Noise words are determined by language-specific noise word files. If this check box is cleared, noise word queries return no results. By default, this check box is selected.

    • The Selected Columns box contains XML that defines what metadata categories are displayed as part of the search results.

    • From the Cross-Web Part Query ID drop-down list, select query ID that is used to pass data between the Core Results Web Part and other Web Parts that are on the Search Results page. The query ID is, by default, User Query, which means that data generated by users' queries is passed to all other Web Parts that have User Query configured as the value of the Cross-Web Part Query ID property. You must change this value if you configure a fixed keyword query. For information about how to create a fixed keyword query, see the next step in this procedure.

  5. Expand the Fixed Keyword Query node.

    Note Note:

    If you configure a fixed keyword query, you must change the default Cross-Web Part Query ID setting in the Results Query Options node of this Web Part from the default setting of User Query to another query ID on the list, such as Query 2. If you do not change this value, the filter in the Fixed Keyword Query setting is not added to the search query.

    • In the Fixed Keyword Query box, type the keywords or property value that you want to add to all queries. By default, this box contains no text.

    • In the More Results Link Text Label box, type the text that is displayed as a link for users to select if they want to view more results. A fixed query displays only a specified number of results. Users who want to view more results must select this link.

    • In the More Results Link Target Results URL box, type the URL of the page that will display more results of the fixed query. By default, this box contains no text.

  6. In the tool pane, expand the Miscellaneous node.

    • In the Scope box, type the name of the default scope for a query. This value determines the scope used for a query if the user does not or cannot choose a scope from the Scopes drop-down list on the Search page. By default, this box is blank, which means no scopes are applied to queries.

    • Select the Show Messages check box if you want to display error messages in this Web Part. By default, this check box is selected.

    • Select the Show Search Results check box if you want to display search results in this Web Part. By default, this check box is selected. You can clear this check box if you want the search results passed to and displayed in other Web Parts, but not in the Search Core Results Web Part. Only Web Parts that have the same value in the Cross-Web Part Query ID setting, in the Results Query Options section, can receive these search results.

    • Select the Show Action Links check box if you want to include the Action Links in the Search Core Results Web Part. You can also display Action Links by adding the Action Links Web Part to the Search Results page.

    • Select the Display "Relevance" View Option check box if you want to allow users to sort the search results by relevance. By default, this check box is selected.

    • Select the Display "Modified Date" View Option check box if you want to allow users to sort the search results by date last modified. By default, this check box is selected.

    • Select the Display "Alert Me" Option check box if you want to display an Alert Me link. By default, this check box is selected.

    • Select the Display "RSS" Link check box if you want to display an RSS link. By default, this check box is selected.

    • In the Sample Data box, type an XML string that includes the kind of data returned in search results.

    • In the XSL Link box, type the URL of an Extensible Stylesheet Language (XSL) file that contains custom XSL for this Web Part. If you configure this setting, the Sample Data property value is ignored. By default, this box contains no text.

    • Select the Enable Data View Caching check box if you want Search Server 2008 to cache search results. By default, this check box is selected.

    • In the Data View Caching Time-out (Seconds) box, type the number of seconds that you want search results to remain in the cache. The default setting is 86400 seconds, which is 24 hours.

    • Select the Send First Row To Connected Web Parts When Page Loads check box if you want the Search Core Results Web Part to send the row that contains the highest rated match to other Web Parts when the Search Results page loads. By default, this check box is selected.

  7. In the tool pane, expand the Data View Properties section, click XSL Editor button to open a window that displays the XSL that controls how the search results are displayed. You can edit the XSL in this window.

  8. After making the changes that you want to the property values, click OK to close the tool pane.

See Also

Concepts

Configure Web Part properties (Search Server 2008)
Configure properties for the Search High Confidence Results Web Part (Search Server 2008)
Configure properties for the Search Box Web Part (Search Server 2008)


Configure properties for the Search High Confidence Results Web Part (Search Server 2008)
DropDown image

Updated: 2009-07-23

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

By default, the Search High Confidence Web Part includes settings that display an exact match of a people search. Because Search Server 2008 does not crawl or index user profile stores and does not perform people searches, the Search High Confidence Web Part does not return people search results when these settings are enabled. However, the Search High Confidence Results Web Part includes settings that enable you to display the result of many types of automatic searches. These include settings that display keyword and Best Bet search results.

Some configuration is needed for keyword and Best Bet search results to display. A site collection administrator must designate query terms as keywords for a site collection. When a keyword is defined, a site collection administrator can also list specific content items that should be returned when that keyword is included in a search query. These content items are called Best Bets and are configured in the properties of a keyword. For more information, see Add keyword terms with Best Bets (Search Server 2008).

Note Note:

The Search High Confidence Results Web Part and the Search Best Bets Web Part contain identical properties. However, the default values of these properties differ. The Search High Confidence Web Part properties are configured to display results that are defined as high confidence, which are exact matches to people searches. By default, the properties that control keyword and Best Bet search results are not configured to be displayed. The Best Bets Web Part is configured by default to display keyword and Best Bet results, but not to display results defined as high confidence.

To configure Search High Confidence Web Part properties

Use this procedure to configure the properties of the Search High Confidence Web Part.

Important Important:

Membership in the Designers group is the minimum that is required to complete this procedure.

Configure Search High Confidence Results Web Part properties

  1. In the Search Center, open the search results page. On the Search Results page, click the Site Actions menu, and then click Edit Page. The Search Results page opens in Edit mode.

  2. In the Search High Confidence Results Web Part, expand the Edit menu, and then click Modify Shared Web Part.

  3. In the tool pane, expand the Keywords node. The settings in this section display only if a site collection administrator has defined keywords on the Manage Keywords page. For more information, see Add keyword terms with Best Bets (Search Server 2008). Keyword results are not configured to display in this Web Part, by default.

    • Select the Display keyword check box if you want to include administrator-defined keywords as part of the search results. For more information on administrator-defined keywords, see Add keyword terms with Best Bets (Search Server 2008).

    • Select the Display definition check box if you want to include administrator-defined keyword definitions as part of the search results.

  4. In the tool pane, expand the Best Bets node. By default, Best Bet results are not configured to display in this Web Part.

    • Select the Display title check box if you want to display the titles of the content items that are returned as Best Bet search results.

    • Select the Display description check box if you want to display the administrator-defined descriptions of the content items that are returned as Best Bet search results.

    • Select the Display URL check box if you want to display the URLs of the content items that are returned as Best Bet search results.

    • In the Best Bets limit box, type the maximum number of items that you want to be displayed as Best Bet search results.

  5. In the tool pane, the High Confidence Matches node provides options dealing with people search. Search Server does not perform people searches and will not display people search results even if these options are configured to do so.

  6. In the tool pane, expand the Miscellaneous node.

    • Select the Show Messages check box if you want to display error messages in this Web Part. By default, this check box is not selected.

    • In the Sample Data box, type an XML string that includes the kind of data returned in the search results.

    • In the XSL Link box, type the URL of an Extensible Stylesheet Language (XSL) file that contains custom XSL for this Web Part. If you configure this setting, the Sample Data property value is ignored. By default, this box contains no text.

    • Select the Enable Data View Caching check box if you want Search Server to cache these search results. By default, this check box is selected.

    • In the Data View Caching Time-out (Seconds) box, type the number of seconds that you want search results to remain in the cache. The default setting is 86400 seconds, which is 24 hours.

    • Select the Send first row to connected Web Parts when page loads check box if you want this Web Part to send its highest-rated match to other connected Web Parts so that it can be displayed as part of the search results in other Web Parts. Only those Web Parts that have the same value in the Cross-Web Part Query ID property can receive this data. By default, this check box is selected.

  7. In the tool pane, expand the Data View Properties section, click XSL Editor to open a window that displays the XSL that controls how the search results are displayed. You can edit the XSL in this window.

  8. After making the changes that you want to the property values, click OK to close the tool pane.

See Also

Concepts

Configure Web Part properties (Search Server 2008)
Configure properties for the Search Box Web Part (Search Server 2008)
Configure properties for the Search Core Results Web Part (Search Server 2008)


Manage settings to improve search results (Search Server 2008)
DropDown image

Updated: 2009-07-02

You can use various features in Microsoft Search Server 2008 to help users get better search results, such as properties assigned to context, stored during indexing, and mapped to managed properties made available for searches; keywords defined by the search services administrator with their definitions and synonyms; and Best Bets sites.

This topic links to articles that provide information about how an administrator can configure these features, and about where and how search queries employ these features.

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

In this section:

  • How word breakers, stemmers, and noise word files affect search results (Search Server 2008)

  • Configure authoritative pages (Search Server 2008)

  • Add keyword terms with Best Bets (Search Server 2008)

  • Using wildcard characters in property searches (Search Server 2008)

  • Manage server name mappings (Search Server 2008)

  • Manage metadata property mappings (Search Server 2008)

See Also

Concepts

Helping users make successful queries (Search Server 2008)


How word breakers, stemmers, and noise word files affect search results (Search Server 2008)
DropDown image

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Word breakers, stemmers, and noise word files, also known as stop word files, are all components that are part of the indexing and querying processes.

In this article:

  • Word breakers

  • Stemmers

  • Noise word files

Word breakers

A word breaker is a component used to break strings of text into individual words during the indexing and querying processes. During the indexing process, text is extracted from content items as an unbroken string of characters. Word breakers reestablish where each word in the string of characters begins and ends. Additionally, word breakers separate compound words so that users receive a query result on a portion of the original compound word and also on the individual terms that compose the compound word. Word breakers also convert numbers and dates from content items into a standard form.

Each language has a different word breaker. The indexing engine decides which word breaker to use and, if more than one language is detected, can use more than one word breaker for text that comes from a single document. If a word breaker does not exist for a particular language, the neutral word breaker is used.

Word breakers are also used by the query engine. When a user submits a query, a word breaker is used to break apart compound words and phrases. This increases the chances that the user's query can be matched to terms in the content index. During a query, the word breaker's language is determined by the language of the user's Web browser.

By default, Search Server 2008 installs the word breakers that are listed in the following table on each server in a Search Server farm.

Arabic | Hungarian | Punjabi
Bengali | Icelandic | Romanian
Bulgarian | Indonesian | Russian
Catalan | Italian | Serbian_Cyrillic
Croatian | Japanese | Serbian_Latin
Czech | Kannada | Slovak
Danish | Korean | Slovenian
Dutch | Latvian | Spanish
English | Lithuanian | Swedish
Finnish | Malay | Tamil
French | Malayalam | Telugu
German | Marathi | Thai
Greek | Norwegian Bokmaal | Turkish
Gujarati | Polish | Ukrainian
Hebrew | Portuguese | Urdu
Hindi | Portuguese_Brazilian | Vietnamese

Stemmers

A stemmer is a component that finds the root word of a term and can also generate variations of that term. For example, in English, if a query contains the word "bought," the stemmer can add the root term "buy" to the query and can also generate other forms of this term such as "buys" and "buying" to add to the query.

Stemmers are language-specific and can have different capabilities depending on the language they support. Some stemmers find the root word but do not generate additional forms of words. By default, stemming is turned off during queries for many languages. You can enable stemming for search queries in the Search Core Results Web Part.

Note Note:

Every language that has a word breaker has a stemmer, if the language can support stemming. For some languages, stemmers are installed but not enabled. To enable these stemmers, you must edit the registry. For instructions on how to enable stemmers for these specific languages, see How to turn on word breakers and stemmers in SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkId=141180).

Noise word files

Some words in a language are not useful when you perform searches. For example, in the English language, words such as "the" and "an" provide little search value because almost every document written in English will contain these words. Words that provide little search value are called noise words, also known as stop words. During the indexing process, noise words are removed to keep indexes smaller, which can increase performance. Noise words are contained in language-specific text files that you can edit. Removing or adding words to a noise word file requires a full crawl of the content.

Noise word files have significantly changed from previous versions of SharePoint products. Many noise words that were previously included in noise word files are removed from Search Server noise word files and are included in content indexes. By default, users can perform queries on words that were previously excluded as noise words. These queries are called noise word queries. You can disallow these searches in the Search Core Results Web Part. Additionally, if a quoted string in a query includes a noise word, the noise word can be replaced with any word in the query results. For example, if a query includes "configure a server," content items that contain "configure the server" and "configure every server" are included in the query results.

Note Note:

Do not remove all of the words in a noise word file. A noise word file must have at least one entry in it, even if the entry is merely a period (.) character.

See Also

Concepts

Manage settings to improve search results (Search Server 2008)
Configure authoritative pages (Search Server 2008)
Add keyword terms with Best Bets (Search Server 2008)


Configure authoritative pages (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Authoritative pages affect how relevance rankings for items are calculated, which affects the order that search results appear in a search results list. Relevance rankings for items are determined in part by how far away (in clicks) items are from URLs that are listed as authoritative, second-level authoritative, or third-level authoritative. The latter two types of URLs receive a penalty click of one and two, respectively. That is, being close to a third-level authoritative URL is good but it's one click worse than being close to a second-level authoritative URL. The same is true for a second-level authoritative URL and a most authoritative URL.

You can also mark URLs as non-authoritative so that they appear lower in the search results list (the demotion is not accomplished by using a click-distance penalty).

Specifying Web pages as authoritative

Use the following procedure to specify Web pages as authoritative.

Specify web pages as authoritative

  1. On the Search Administration page, under Queries and Results, click Authoritative pages.

  2. On the Specify Authoritative Pages page, in the Most authoritative pages box in the Authoritative Web Pages section, list the URLs that are central or authoritative and separate the URLs by returns so that you list one full URL per line.

  3. In the Second-level authoritative pages box, list the URLs that are secondary.

  4. In the Third-level authoritative pages box, list the URLs that are tertiary.

  5. In the Non-authoritative Sites section, in the Sites to demote box, list the URLs that you want to mark as unimportant when search results are returned (for example, URLs of sites that contain outdated information but are kept for record-keeping).

  6. Any URL or item whose prefix matches the provided URLs in the Sites to demote box is demoted.

    Note Note:

    If you want the ranking calculations to begin after you click OK, select the Refresh now check box in the Refresh Now? Section. If the check box is cleared, ranking calculations occur according to a predetermined schedule

  7. Click OK.

See Also

Concepts

Manage settings to improve search results (Search Server 2008)


Add keyword terms with Best Bets (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Keyword terms are defined by an administrator to enhance search results. They can be used in queries from the Search box, the Search Center site, or Advanced Search. When a query includes a keyword term or one of its synonyms, the definition for that term and links to its featured locations or documents, called "Best Bets," are displayed prominently on the search results page, above the core search results.

By defining terms that are often used in searches as keywords, a site collection administrator can provide a standard glossary of names, processes, and concepts that are part of the "common knowledge" shared by members of an organization. When keywords have synonyms and associated Best Bet links, they also become handy tools for guiding users toward recommended resources.

In this article:

Displaying the Manage Keywords page

Adding keywords

Managing Best Bets

Reviewing keywords and Best Bets

Displaying the Manage Keywords page

To access the Add Keywords page and define keywords and Best Bets there, a site collection administrator goes to the home page for the top-level site in the site collection and uses the Site Actions menu to display the Manage All Site Settings page.

Display the Manage Keywords page

  1. Log on to the home page of your top-level site with site collection administrator permissions.

  2. Click the Site Actions menu, and then click Site Settings.

  3. On the Site Settings page, in the Site Collection Administration section, click Search keywords. This displays the Manage Keywords page.

  4. To define a new keyword and add Best Bets to it, click Add Keyword, and then follow the steps listed in the Adding keywords section.

    Note Note:

    To add Best Bet links to an existing keyword, move the cursor over the keyword, expand the menu that appears, click Edit, and then follow the steps in the Managing Best Bets section.

Adding keywords

Keywords provide definitions for common terms that are used within your organization. Each keyword entry also can include a list of synonyms and the Web addresses (URLs) for several Best Bet links to recommended content.

Add keywords

  1. Follow the steps in the earlier section Displaying the Manage Keywords page.

  2. Click Add Keyword to display the Add Keyword page.

  3. In the Keyword Phrase box, type a word, name, acronym, or phrase to be defined as a keyword.

    Tip Tip:

    Terms that are often used in searches make good keyword terms. When defining keywords, work from a list of popular sites, processes, and tools used by your organization.

  4. Type terms with a similar meaning in the Synonyms box. The definition of the keyword and its Best Bets is featured above the search results when any synonym of the keyword is used in a query. Separate synonyms with a semicolon (";").

  5. In the Definition box, provide a definition to display above the core search results whenever the keyword is used in a query.

  6. To feature Best Bet links above the search results, click Add Best Bet, and then follow the steps in the Managing Best Bets section.

  7. To store contacts for the keyword, for example reviewers, type an e-mail alias in the Contact box. Click Check Names to verify the alias, or click Browse to select a name using a directory service.

  8. In the Publishing section, you can set a Review Date for keyword reviewers, a Start Date when the keyword's definition and Best Bets begin to appear in search results, and (if wanted) an End Date when the keyword ceases to be active. Click the calendar next to each date that you want to set.

    Note Note:

    The current date appears as the default Start Date. If you leave the End Date box empty, the keyword does not expire.

  9. Click OK to finish defining the keyword.

    Note Note:

    Keywords and their Best Bets are stored in their own database tables and become effective immediately.

Managing Best Bets

Best Bets can link to recommended Web sites, data stores, and documents. When a user includes a keyword or one of its synonyms in a query, the search results page features links to its associated Best Bets above the core results, along with its definition. This enables the administrator to guide users toward recommended locations and authoritative pages.

Note Note:

Keyword terms in queries must match the keyword or its synonym exactly. Partial matches won't work. Keywords can only be used within the site collection where they are defined. Keyword definitions and their Best Bet links (if any) are displayed when the Search box sends its query results to a search results page that is within the same site collection, and includes the Best Bets Web part.

For example, you might define payroll as a keyword and include the URL for the home page of your Payroll department as one of its Best Bet links. When a user types the keyword term payroll in the Search box, the search results then includes a link to your company's payroll site.

Manage Best Bets

  1. Follow the steps in the earlier section Displaying the Manage Keywords page.

  2. To add a Best Bets site to an existing keyword, move the cursor over the name of a keyword, expand the menu that appears, and then click Edit to display the Edit Keyword page.

    Or to create a new keyword with Best Bets, click Add Keyword, and then follow the steps in the earlier section Adding keywords.

  3. In the Best Bets section of the Manage Keywords or Add Keyword page, click Add Best Bet.

  4. If you have already created other keywords with Best Bets, the Add Best Bet dialog box offers options to Select existing best bet or to Add new best bet.

    To reuse an existing Best Bet:

    1. Choose Select existing best bet.

    2. Select one or more Best Bets from the list. This adds these Best Bets to the present keyword.

    To create a new Best Bet:

    1. Choose Add new best bet.

    2. In the URL box, type its Web address.

    3. In the Title box, type the link text for the Best Bet link.

    4. In the Description box, type text to display beneath the Best Bet link.

    5. Click OK to finish creating the new Best Bet.

  5. Each Best Bet entry that is associated with a keyword includes links to Edit, Order, or Remove the Best Bet.

    1. To change the URL, Title, or Description of a Best Bet, click Edit, and then type the new information in the box. Click OK to save your changes.

      Note Note:

      When you edit a Best Bet that is shared among several keywords, it is changed for all of the keywords that use it.

    2. If a keyword includes multiple Best Bets, use the Order list to set the order in which they appear on the search results page.

    3. To remove a Best Bet from a keyword, click Remove.

      Note Note:

      A Best Bet can be added from the Select existing best bet list only if it is in use in at least one keyword. When a Best Bet is no longer in use in any keyword, it is deleted.

Reviewing keywords and Best Bets

In the Publishing section of the Add Keyword page, you can set a Review Date for keyword reviewers. To do so, follow the procedures in the earlier section Adding keywords.

Those people asked to review a keyword by a certain date receive an alert to do so. When the expiration date has passed, they receive another alert. These alerts include a link to the Manage Keywords page. Those people notified must have the permissions required to see the Displaying the Manage Keywords page. They can then use the Keywords Requiring Review link to filter the page to display the keywords that require review, or the Expired Keywords link to display the keywords that have expired.

See Also

Concepts

Manage settings to improve search results (Search Server 2008)


Using wildcard characters in property searches (Search Server 2008)
DropDown image

Updated: 2009-07-09

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Property searches are in the format of property:value. If you know the exact value of the property you want to find, enclose the value in quotation marks to return only exact matches. If you are not sure of the exact value you can type the letter or letters that the value begins with to find partial matches. For example, if you look for filename:"Budget" (with quotation marks), your search will return files named "Budget" such as "Budget.xlsx." A search for filename:budget (without quotation marks) will also return that file, as well as the files "Budget_Current.xlsx" and "Budget_Next.xlsx." Only prefix matching is allowed in property searches, which means that you must have at least the first letter of the property value to complete the search.

You can search for multiple property values in one query. The spaces between property:value entries are interpreted as an AND. If a query contains author:"Jane Doe" filetype:docx, the search returns Word 2007 documents that are authored by Jane Doe. This is only true if your query contains different properties. If you use the same property, Search Server interprets the space between the property:value entries as an OR. For example, if the query contains author:"Joe Jones" author:"Mike Jones", the system returns items authored by Joe Jones and items authored by Mike Jones.

You can also use wildcard characters in property searches. Wildcard searches include characters, such as "*", which allows the search engine to substitute any number of characters and "?", which allows the search engine to substitute any single character. Prefix matching is also required when you use wildcard characters. This means that you cannot insert wildcard characters in the middle of a property value such as W*ton or at the beginning of a property value such as *ington.

See Also

Concepts

Manage server name mappings (Search Server 2008)
Manage metadata property mappings (Search Server 2008)


Manage server name mappings (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Add a server name mapping to override how search results are displayed and how users access content after you create a content index. Delete a server name mapping when you no longer want to override how search results are displayed in search results or how users access content after you create a content index.

To manage server name mappings, you must first open the Server Name Mappings page. To do this:

  • On the Search Administration page, under Queries and Results, click Server name mappings.

Adding a server name mapping

Follow this procedure to add a server name mapping.

Add a server name mapping

  1. On the Server Name Mappings page, click New Mapping.

  2. On the Add Server Name Mapping page, in the Address in index box, type the address for the content that will be crawled.

  3. In the Address in search results box, type the address that appears in the search results and from which a user can access the content.

  4. Click OK.

Editing a server name mapping

You can edit either the address used in the index or the address that appears in the search results for the mapping.

Edit a server name mapping

  1. On the Server Name Mappings page, in the Address for indexing column, click the address for which you want to edit the mapping.

  2. On the Edit Server Name Mapping page, in the Server Names section, make your edits in the Address in index and Address in search results boxes.

  3. Click OK.

Deleting a server name mapping

  • On the Server Name Mappings page, in the list of mappings, point to the mapping that you want to delete, click the arrow that appears, and then click Delete.

See Also

Concepts

Manage settings to improve search results (Search Server 2008)


Manage metadata property mappings (Search Server 2008)
DropDown image

Updated: 2008-03-03

Metadata property mappings map properties extracted from documents during crawls, called crawled properties, to managed properties that users can use in search queries.

For example, three different document types might have different names for the property identifying the author. One document type might name this property "author," another "writer," and a third "property3". You can map each of these crawled properties to the Author managed property so that when a user queries by author, appropriate results from the three document types are included. Searches can be performed only on managed properties, not crawled properties.

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

To manage metadata property mappings, you must first open the Metadata Property Mappings page:

  • On the Search Administration page, under Queries and Results, click Metadataproperties.

In this article:

Adding a managed property

Editing a managed property

Deleting a managed property

Mapping a crawled property

Adding a managed property

Add a managed property

  1. On the Metadata Property Mappings page, click New Managed Property.

  2. On the New Managed Property page, in the Property name box in the Name and type section, type the name of the new managed property.

  3. In the Description box, type a description of the property.

  4. Under The type of information in this property, select one of the following as appropriate for the property:

    • Text

    • Integer

    • Decimal

    • Date and Time

    • Yes/No

  5. In the Mappings to crawled properties section, select one of the following:

    • Include values from all crawled properties mapped Select this option if you want values from all crawled properties to be mapped for a given document. A query for a property in a document in which all crawled properties are mapped returns a result if any of the crawled properties that are mapped match.

    • Include values from a single crawled property based on the order specified Select this option if you want only a single value mapped. When multiple crawled properties are mapped to a managed property, the one that is chosen is the first in the list that has a value for a given document. You can reorder the list by using the Move up and Move down buttons.

  6. Click Add Mapping to add a mapping to the list.

  7. The Crawled property selection dialog box appears. Configure the settings as follows:

    1. On the Select a category menu, click either All categories or a specific type of document category (for example, Office or XML).

    2. In Select a crawled property, select a crawled property to map to the managed property that you are adding.

      Because the list of crawled properties is likely to be long, you can type the name (or the first part of the name) of the property that you are looking for in the Crawled property name box, and then click Find.

    3. Click OK.

  8. On the New Managed Property page, in the Use in scopes section, select the Allow this property to be used in scopes check box if you want the property to be available for defining search scopes.

    Tip Only select this check box for those properties you intend to use in scopes. Each property set as a scope increases the size of the index, which you should avoid when possible.

  9. Click OK.

  10. In the message box advising that the changes do not take effect until after the next full crawl, click OK.

Note Note:

Changes to the property mappings take effect on a document-by-document basis as soon as a document is crawled, regardless of the type of the crawl. A full crawl ensures that the changes are consistently applied to the entire index.

Editing a managed property

One reason that you may want to edit a managed property is to map a crawled property to it.

Edit a managed property

  • On the Metadata Property Mappings page, in the Managed Properties View list, click Edit/Map Property on the menu of the managed property that you want to edit.

    You can find information about the managed property settings, including how to add a new mapping, in the Adding a managed property section.

Deleting a managed property

Deleting a managed property has the following consequences:

  • Users no longer able to query by using this property.

  • If a scope uses this property in its rules, the scope is broken.

  • If custom search applications or Web Parts use this property, they are broken.

To delete a managed property:

  • On the Metadata Property Mappings page, in the Managed Properties View list, click Delete on the menu of the managed property that you want to delete.

Mapping a crawled property

You can map crawled properties to managed properties by editing the crawled property.

Map a crawled property

  1. On the Metadata Property Mappings page, click Crawled Properties.

  2. In the Crawled Properties View list, select the category to which the crawled property belongs.

  3. In the list of crawled properties, click Edit/Map Property on the menu of the crawled property that you want to edit.

  4. On the Edit Crawled Property page, in the Mappings to managed properties section, click Add Mapping.

  5. In the Managed property selection dialog box, configure the settings as follows:

    1. In the Select a managed property list, select a managed property, and then click OK.

    2. Click OK.

  6. On the Edit Crawled Property page, if you want to include values for the crawled property in the search index, select the Include values for this property in the search index check box. This option makes values for the crawled property searchable when a full-text search is used. Crawled properties are usually searchable only when a property-based search is used.

  7. Click OK.

  8. In the message box advising that the changes do not take effect until after the next full crawl, click OK.

    Note Note:

    The changes actually take place on a document-by-document basis during the crawl.

See Also

Concepts

Manage settings to improve search results (Search Server 2008)


Protecting and restoring the farm (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Data and files are typically some of the most important assets that an organization possesses.

This section of the operations guide discusses technologies that you can use to protect and recover these important assets. These technologies include:

  • Content versioning

  • Recycle Bins

  • Database snapshots

  • Backups by using:

    • Microsoft Search Server 2008 built-in tools

    • SQL Server tools

The following articles discuss the principal objectives that users, site owners, and administrators of Search Server 2008 must accomplish to administer protection and recovery:

  • Protect and restore content by using Recycle Bins and versioning (Search Server 2008)

  • Back up and restore a farm (Search Server 2008)

  • Use alternative methods to back up and restore content (Search Server 2008)

  • Troubleshooting backup and recovery (Search Server 2008)

See Also

Concepts

Operations for Search Server 2008
How to crawl content (Search Server 2008)
Working with federation (Search Server 2008)


Protect and restore content by using Recycle Bins and versioning (Search Server 2008)
DropDown image

Updated: 2008-07-24

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Unlike previous versions of SharePoint Products and Technologies, you do not need to perform a content database recovery to retrieve deleted objects. Instead, you can use the Recycle Bin and the second-stage Recycle Bin. The Recycle Bin provides a feature that enables users to restore items that are in the Recycle Bin — including deleted files, documents, list items, lists, and document libraries.

You can also use versioning to help prevent data loss that is caused by overwriting a document. When a site owner turns on versioning in a document library or a list, the library or list keeps multiple copies of a document, item, or file. In the event of an unwanted change, an overwritten file, or document corruption, the previous version can be easily restored by the end user.

Protecting content by using the Recycle Bin

The second-stage Recycle Bin (also called the site-collection Recycle Bin) is available to site collection administrators. The second-stage Recycle Bin is organized into two views: objects in the Recycle Bins of all sites in the site collection, and objects in the second-stage Recycle Bin. When an item is deleted from the Recycle Bin, it can only be recovered by a site collection administrator from the second-stage Recycle Bin.

When you enable the second-stage Recycle Bin for a Web application, you must designate how much disk space is available to the second-stage Recycle Bin as a percentage of the quota allotted to the Web application. For example, if you have allotted 100 megabytes (MB) of space for the Web application, allotting a 50% quota for the second-stage Recycle Bin allots 50 MB for the second-stage Recycle Bin and 150 MB for the Web application as a whole. You can allot up to 100% for the second-stage Recycle Bin quota. For more information about planning and creating quota templates, see the following articles:

  • Plan for site maintenance and management (Office SharePoint Server)

  • Create quota templates (Office SharePoint Server)

The following table describes how an item is deleted and recovered from the Recycle Bin and the second-stage Recycle Bin.

When a user does this | The item is | The item can be restored by
Deletes item | Held in the Recycle Bin until the item is deleted from the Recycle Bin or the item has been in the Recycle Bin longer than the configured amount of time for allowed an item to be in the Recycle Bin. | Users or site collection administrators
Deletes an item from the Recycle Bin | Held in the second-stage Recycle Bin | Site collection administrators

For more information about using the Recycle Bin in Microsoft Search Server 2008, see View, restore, or delete items in the Recycle Bin (http://go.microsoft.com/fwlink/?LinkId=90917&clcid=0x409)

To configure Recycle Bins, see Configure the Recycle Bin (Search Server 2008).

Protecting content by using versioning

When properly understood and implemented, versioning provides a user-driven content recovery method and also informs users about the stage of development of a document — for example:

  • Is this document a draft or a published version?

  • Which changes have been made recently?

  • Has the metadata changed, and why?

Before attempting to use versioning to protect and restore your SharePoint content, be sure to read Plan for site maintenance and management (Office SharePoint Server).

You can configure versioning by using the following procedure:

Enable and configure versioning (Search Server 2008)

Administrators need to manage versioning because if sites have many versions of files and documents, the sites can become quite large. If you do not restrict the size of sites, your sites can surpass your storage capacity. Farm administrators can manage this issue by establishing service level agreements with site owners and by setting size quotas on sites. To manage versioning, use the following procedure:

Manage versioning by using quotas (Search Server 2008).

See Also

Concepts

Protecting and restoring the farm (Search Server 2008)
Back up and restore a farm (Search Server 2008)
Use alternative methods to back up and restore content (Search Server 2008)
Troubleshooting backup and recovery (Search Server 2008)


Configure the Recycle Bin (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Before you perform this procedure, confirm that your system is running Microsoft Search Server 2008.

The Recycle Bin provides a safety net when deleting documents, list items, lists, folders and files from Windows SharePoint Services 3.0 or from one of the server products in the 2007 Office release. When you or site visitors delete any of these items from a Web site, the items are placed in the Recycle Bin. The Recycle Bin provides two stages of backup protection. Farm administrators can configure these features and site collection administrators can view, restore, or delete items in the Recycle Bin.

Important Important:

Membership in the Search Server 2008 Farm Administrators group is the minimum required to complete this procedure.

Configure the Recycle Bin

When Search Server 2008 is installed or a new Web application is created, the following default Recycle Bin settings are configured:

  • The Recycle Bin is turned on

  • Items are scheduled to be deleted from the Recycle Bin after 30 days

  • The second-stage Recycle Bin is set to add 50 percent of live site quota for second-stage deleted items

If you are satisfied with these settings, no further action is required. If you want to change these settings, use the following procedure.

Configure the Recycle Bin

  1. On the SharePoint Central Administration Web site, on the Application Management tab, in the SharePoint Web Application Management section, click Web application general settings.

  2. On the Web Application General Settings page, in the Web Application section, choose the Web application that you want to configure from the drop-down list.

  3. On the Web Application General Settings page, in the Recycle Bin section, there are three separate settings that you can configure.

    1. Select On or Off to set the Recycle Bin status. If you choose to turn the Recycle Bin off, the other two options become unavailable.

    2. Select After and type the number of days that you want to retain items in your Recycle Bin or select Never if you do not want items to ever be deleted from the Recycle Bin.

    3. Select Add and type a percentage of live site quota for second-stage deleted items or select Off to disable the second-stage Recycle Bin.

  4. Click Ok.

See Also

Concepts

Protect and restore content by using Recycle Bins and versioning (Search Server 2008)
Enable and configure versioning (Search Server 2008)
Manage versioning by using quotas (Search Server 2008)


Enable and configure versioning (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Versioning is not controlled at the server-farm level. It must be enabled and configured separately by the site owner on each library or list. When you track versions of files or list items, each version is numbered and saved as part of a version history. People in your organization can view the version history and recover earlier versions if needed. In a particular list or library, you can specify the following settings:

  • No versioning

    Previous document versions and the history (such as comments) associated with each version are not retrievable. This is the default setting.

  • Create major versions

    Each iteration becomes a full copy of the document with the versions numbered sequentially (1, 2, 3, and so on). All users with permissions to the document library are able to view every updated version. Use this option if you do not need to differentiate between draft versions and published versions. To control the effect on storage space, you can specify how many previous versions to retain based on the current version.

  • Create major and minor versions

    Versions ending with a zero extension (.0) are major versions and versions ending with a non-zero extensions are minor versions. Only major versions can be published. Additional permission levels can be configured for working with minor versions. In most scenarios, users who can edit major versions are also allowed to edit minor versions, but read-only users can only view major versions. As with the previous option, you can specify how many previous versions to keep based on the current version. You can also specify how many minor versions are kept per major version.

Important Important:

To enable and configure versioning, you must have the Full Control permission level on the list or library.

Enable and configure versioning

Use the following procedure to enable versioning in a list. After completing this procedure, people in your organization will be able to view version history and recover earlier versions of the list if needed.

Enable and configure versioning for a list

  1. Open the list for which you want to enable versioning.

  2. On the Settings menu, click List Settings.

  3. On the <List name> Settings page, in the General Settings section, click Versioning settings.

  4. On the List Versioning Settings page, in the Content Approval section, select the content approval option you want to apply to any list changes.

    For more information about requiring content approval for submitted items, see Require approval of items or files in a list or library (http://go.microsoft.com/fwlink/?LinkId=104971&clcid=0x409).

  5. In the Item Version History section, click Yes to enable the creation of a new version each time the list is edited.

  6. To specify how many versions of items or files to keep. select the Keep the following number of versions check box, and then type the number of versions that you want to keep.

  7. If you chose to require content approval for submitted items, you can specify how many approved versions are kept by selecting the Keep drafts for the following number of approved versions check box, and then type the number of versions that you want to keep.

  8. In the Draft Item Security section, if you chose to require content approval for submitted items, you must choose who should see draft items in this document library. Choose one of the following:

    • Any user who can read items

    • Only users who can edit items

    • Only users who can approve items (and the author of the item)

      For more information about specifying who can view and edit drafts, see Specify who can view drafts (http://go.microsoft.com/fwlink/?LinkId=104975&clcid=0x409).

  9. Click OK.

Use the following procedure to enable versioning in a library. After completing this procedure, people in your organization will be able to view version history and recover earlier versions of library documents if needed.

Enable and configure versioning for a library

  1. Open the library for which you want to enable versioning.

  2. On the Settings menu, click Document Library Settings.

  3. On the Customize <Library name> page, in the General Settings section, click Versioning settings.

  4. On the Document Library Versioning Settings page, in the Content Approval section, select the content approval option you want to apply to any list changes.

    For more information about requiring content approval for submitted items, see Require approval of items or files in a list or library (http://go.microsoft.com/fwlink/?LinkId=104971&clcid=0x409).

  5. In the Document Version History section, select a versioning option:

    • To specify that only one type of version is tracked, click Create major versions.

    • To specify that both major and minor versions are tracked, click Create major and minor (draft) versions.

  6. To specify how many major versions of items or files to keep, select the Keep the following number of major versions check box, and then type the number of versions that you want to keep.

  7. If you chose to create both major and minor versions, you can specify how many minor (draft) versions are kept by selecting the Keep drafts for the following number of major versions check box, and then type the number of versions that you want to keep.

  8. In the Draft Item Security section, if you chose to require content approval for submitted items, you must choose who should see draft items in this document library. Choose one of the following:

    • Any user who can read items

    • Only users who can edit items

    • Only users who can approve items (and the author of the item)

    For more information about specifying who can view and edit drafts, see Specify who can view drafts (http://go.microsoft.com/fwlink/?LinkId=104975&clcid=0x409).

  9. In the Require Check Out section, select the check-out option you want to apply to library edits.

    For more information about requiring check-out, see Require check-out for files in a library (http://go.microsoft.com/fwlink/?LinkId=104974&clcid=0x409).

  10. Click OK.

See Also

Concepts

Protect and restore content by using Recycle Bins and versioning (Search Server 2008)
Configure the Recycle Bin (Search Server 2008)
Manage versioning by using quotas (Search Server 2008)


Manage versioning by using quotas (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Versioning enables you to store, track, and restore items in a Microsoft Search Server 2008 list and files in a Search Server 2008 library as they are changed. Versioning is not controlled at the server-farm level. It must be configured separately on each list or library. For administrators, versioning is a matter of concern. This is because if sites have many versions of files and documents, they can become quite large. If you do not set size quotas on sites, the sites can surpass storage capacity.

For more information about planning versioning, see Plan for versioning (Office SharePoint Server).

To configure versioning, you must be a member of the site owners security group. Because configuring versioning is a matter that is often out of the scope of the administrator's responsibilities, the way that the farm administrator can control the effects of versioning is by establishing service level agreements with site owners and by specifying size quotas on sites.

Create, edit, and delete site quota templates

To create, edit, or delete a site quota template, see Create quota templates (Office SharePoint Server).

See Also

Concepts

Protect and restore content by using Recycle Bins and versioning (Search Server 2008)
Configure the Recycle Bin (Search Server 2008)
Enable and configure versioning (Search Server 2008)


Back up and restore a farm (Search Server 2008)
DropDown image

Updated: 2008-07-24

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This document set is written to meet the requirements of information technology (IT) professionals who are responsible for the planning, design, deployment, and operations of backup and recovery solutions in enterprise, corporate, or branch office environments. The readers of this document set are expected to have an understanding of its technical details. However, service-level expertise is not needed to follow the enterprise-level discussions and to understand the decisions that are made.

A backup is a copy of data that is used to restore and recover that data after a system failure. Backups allow you to restore data after a failure. With proper backups, you can recover from many failures, including:

  • Media failure

  • User errors (such as deleting a file by mistake)

  • Hardware failures (such as a damaged disk drive or permanent loss of a server)

  • Natural disasters

Additionally, keeping backups of data is useful for routine purposes, such as copying a database from one server to another, setting up database mirroring, archiving for governmental purposes, and disaster recovery.

Back up and restore all or part of your farm and content

The following tasks for backup and recovery are performed on databases or on sites, subsites, and files:

  • Back up and restore an entire farm (Search Server 2008).

  • Back up and restore Web applications by using built-in tools (Search Server 2008).

  • Back up and restore site collections by using built-in tools (Search Server 2008).

  • Back up and restore databases (Search Server 2008).

See Also

Concepts

Protecting and restoring the farm (Search Server 2008)
Protect and restore content by using Recycle Bins and versioning (Search Server 2008)
Use alternative methods to back up and restore content (Search Server 2008)
Troubleshooting backup and recovery (Search Server 2008)


Back up and restore an entire farm (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

There are several methods you can use to back up and restore data for Microsoft Search Server 2008. Key factors to consider in determining which tools to use include:

  • Backup type supported (full, differential, incremental).

  • Completeness of recovery and types of objects that can be recovered.

  • Complexity of managing solution.

  • Ability of solution to adapt to the maintenance window and database size.

Back up and restore a server farm

Before beginning any backup or recovery procedure, be sure you have read and understand the guidelines and requirements specified in Prepare to back up and restore a farm (Search Server 2008).

You can back up and restore data for Search Server 2008 by using any of the following mechanisms:

  • Back up a farm by using built-in tools (Search Server 2008)

    Restore a farm by using built-in tools (Search Server 2008)

    You can use the tools included with Search Server 2008 to back up and restore the server farm. The Central Administration Web site offers a simple, UI-based method to manage farm backup and recovery and to view job history and status. The Stsadm command-line tool offers a faster and more flexible command-line-based approach to farm backup and recovery. You can use the Stsadm command-line tool in conjunction with Windows Scheduler to schedule delayed or periodic backups.

  • Back up a farm by using SQL Server tools (Search Server 2008)

    Restore a farm by using SQL Server tools (Search Server 2008)

    You can use SQL Server 2005 to get a full-fidelity, complete backup of the databases used by Search Server 2008 in the server farm. You must be a member of the Administrators group on the local server computer that is running SQL Server. Using SQL Server 2005, it is also possible to implement alternative backup strategies such as database mirroring or log shipping.

For more information about choosing a specific backup and recovery method, see Choose backup and recovery tools (Office SharePoint Server)

See Also

Concepts

Back up and restore a farm (Search Server 2008)
Back up and restore Web applications by using built-in tools (Search Server 2008)
Back up and restore site collections by using built-in tools (Search Server 2008)
Back up and restore databases (Search Server 2008)


Prepare to back up and restore a farm (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Before you back up data, you must create a shared folder on the network in which the data will be stored. You also must ensure that the accounts needed to perform a backup have access to the shared folder. This article and the procedures that follow cover preliminary considerations and the steps that you must take before you back up your data.

Preparation is the key to ensuring that you are backing up and can recover the data that will be needed should a failure occur. Before backing up your deployment, review your backup and recovery plan. Consider the following key activities:

  • When you deploy Microsoft Search Server 2008, keep a record of the accounts that you create, and the computer names, passwords, and setup options that you choose. Keep this information in a safe place.

  • Always keep a copy of all recovery materials, documents, and database and transaction log backups at an offsite location.

    For more information about planning for backup and recovery, see Plan for backup and recovery (Office SharePoint Server).

  • Be certain that your system has adequate space to accommodate your backup. For more information about planning storage capacity, see Planning for Storage.

  • Periodically perform a trial data recovery operation to verify that your files are properly backed up. A trial data recovery can uncover hardware problems that do not show up with software verifications.

  • To safeguard against loss from a catastrophic event, such as a fire or earthquake, maintain duplicate copies of your server backups in a separate location from the servers. Doing so can help protect you against the loss of critical data. As a best practice, keep three copies of the backup media, and keep at least one copy offsite in a properly controlled environment.

The following restrictions and exceptions may apply when backing up or restoring the SharePoint Products and Technologies server farm:

  • SharePoint Products and Technologies built-in tools might not back up or restore the following:

    • Any custom solutions that have been deployed

    • Alternate access mappings

    • The Web application that hosts the SharePoint Central Administration Web site

    • The Internet Information Services metabase

    • The Central Administration content database

    • The configuration database

      Important Important:

      Although the configuration database and Central Administration content database can be backed up, restoring backups of the configuration database and Central Administration content database taken from a running farm by using the tools built in to SharePoint Products and Technologies or SQL Server is not supported.

      This is because data in these databases may not be synchronized with data in other SharePoint Products and Technologies databases. Therefore, the tools built in to SharePoint Products and Technologies do not recover these databases during a farm-level restore operation.

      If this data is not synchronized, users might experience various random errors. For more information, see Microsoft Knowledge Base article 948725: Restoration of the configuration database is not supported in SharePoint Server 2007 and in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=117755&clcid=0x409).

      You can recover a farm, including the configuration database and Central Administration content database, in the following ways:

      • You can use farm-level backups of a running farm taken with Microsoft System Center Data Protection Manager 2007 to recover an entire farm, including the configuration database and Central Administration content database. For more information, see How to Recover a Windows SharePoint Services Farm (http://go.microsoft.com/fwlink/?LinkId=102831&clcid=0x409).

      • You can restore a backup of the configuration database and Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (Search Server 2008).

      If the configuration database and the Central Administration content database of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products and Technologies Configuration Wizard or Psconfig command-line tool.

      To protect the configuration database and the Central Administration content database:

      • Document all configuration settings and all your customizations so that you can correctly re-create the databases. For more information about recovering a farm, see Restore a farm after a configuration database problem (Search Server 2008).

      • Consider a redundancy solution, such as clustering or mirroring, for the computer running SQL Server that is hosting the configuration database. For more information about using mirroring, see Using Database Mirroring with Office SharePoint Server and Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409).

  • Site collection backup and recovery does not support migrating a Central Administration site to a non-Central Administration site.

  • The SQL Server VSS Writer service, which is available with Microsoft SQL Server 2005 database software, must be started for the Windows SharePoint Services VSS Writer service to work properly. By default, the Windows SharePoint Services VSS Writer service is not automatically started.

  • If you want to move the backups that you created by using SharePoint Products and Technologies to another location, be sure to copy and move the entire backup folder and not the individual backup folders under this folder.

  • If you want to schedule backups, you can use the Windows Task Scheduler to run them by using the Stsadm command-line tool.

    Important Important:

    Do not modify the spbackup.xml file. Doing so can corrupt your backup or restored farm and make it unrecoverable.

  • You cannot use a backup made from one version to restore to another version. To do this, use the upgrade process.

  • If you use Central Administration to back up, you cannot use other methods to restore, such as Microsoft SQL Server 2005 tools.

  • If you perform a backup while any task that creates or deletes databases is running, these changes might not be included in the backup.

  • You should maintain a separate backup of all your custom solutions.

  • SQL Server 2005 does not support performing a backup to mapped drives, shares that end in "$" on remote computers, or IP addresses.

  • Backing up the Shared Services Provider (SSP) does not back up the global search settings.

Task Requirements

The following components are required to perform the procedures for this task:

  • Search Server 2008 must be installed. For more information about installing Search Server 2008, see Plan to deploy Search Server 2008 or Search Server 2008 Express.

  • The accounts listed in the following table must be enabled to do backup and recovery.

    Account Description

    SQL Server service account (MSSQLSERVER)

    If the Local System account is used for this service account, and if the shared folder is on another computer, you must give the computer that is running SQL Server Change and Read permissions to the shared folder. Alternatively, you can specify a domain user account and give that account permissions to the shared folder.

    A local administrator's account

    To perform backup and recovery by using the Stsadm command-line tool, you must be logged on as a member of the Administrators group on the computer that holds the Stsadm command-line tool.

    The SharePoint Central Administration application pool identity account in Internet Information Services (IIS)

    This application pool identity account is required to do backup and recovery when you use Central Administration. Therefore, the security account for this application pool must have Change and Read permissions to the shared folder that contains the backup data.

  • If you have changed the farm account, before you back up, you must grant the new account the correct permissions to the shared folder that will contain your backup data.

  • If you are backing up by using Central Administration, the database server's SQL account, the Timer service account, and the Central Administration application pool identity account must have Write permissions to the backup locations. If you are using the Stsadm command-line tool, the account that you use to log on must have Write permissions to the backup locations.

  • The database server and farm server being backed up must be able to connect to one another.

To create a shared folder on the network

Use this procedure to create a shared folder on the network that can receive and hold backed-up data. You can also use this shared folder when you restore data. If you already have a shared folder that serves this purpose, you do not need to perform this procedure. By performing the following procedure, you ensure that you can access the shared folder from the computer that runs Microsoft SQL Server 2005 database software and from the computer that hosts the SharePoint Central Administration Web site.

Important Important:

Membership in the Administrators group on the computer on which the shared folder is located is the minimum requirement to complete this procedure.

Create a shared folder on the network

  1. If you create the shared folder on a computer other than the one running SQL Server, ensure that the service account for SQL Server (MSSQLSERVER) is using a domain user account. For information about accounts in SQL Server, see the following resources:

    • SQL Server 2005 Books Online (http://go.microsoft.com/fwlink/?LinkId=83543)

    • Microsoft SQL Server 2005 Express Edition Books Online (http://go.microsoft.com/fwlink/?LinkId=83544)

    • Microsoft SQL Server 2000 Books Online (http://go.microsoft.com/fwlink/?LinkID=83689&clcid=0x409)

  2. On the server on which you want to store your backup data, create a shared folder.

  3. On the Sharing tab of the Properties dialog box, click Permissions, and then add the following accounts:

    • SQL Server service account (MSSQLSERVER)

    • The SharePoint Central Administration application pool identity account.

  4. Select Allow for the Change and Read permissions and then click OK.

  5. On the Security tab of the Properties dialog box, grant all the permissions except Full Control to the accounts listed in step 3, and then click OK.

Preparing to restore

You should be aware of the following before begin to restore:

Important Important:

Although the configuration database and the Central Administration content database can be backed up, restoring backups of the configuration database and the Central Administration content database taken from a running farm by using the tools built in to SharePoint Products and Technologies or SQL Server is not supported.

This is because data in these databases may not be synchronized with data in other Search Server 2008 or Windows SharePoint Services 3.0 databases. Therefore, the tools built in to SharePoint Products and Technologies do not recover these databases during a farm-level restore operation.

If this data is not synchronized, users might experience various random errors. For more information, see Microsoft Knowledge Base article 948725: Restoration of the configuration database is not supported in SharePoint Server 2007 and in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=117755&clcid=0x409).

You can recover a farm, including the configuration database and the Central Administration content database, in the following ways:

  • You can use farm-level backups of a running farm taken with System Center Data Protection Manager to recover an entire farm, including the configuration database and the Central Administration content database. For more information, see How to Recover a Windows SharePoint Services Farm (http://go.microsoft.com/fwlink/?LinkId=102831&clcid=0x409).

  • You can restore a backup of the configuration database and the Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (Search Server 2008).

If the configuration database and the Central Administration content databases of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products and Technologies Configuration Wizard or Psconfig command-line tool.

To protect the configuration database and the Central Administration content database:

  • Document all configuration settings and all your customizations so that you can correctly re-create the databases. For more information about recovering a farm, see Restore a farm after a configuration database problem (Search Server 2008).

  • Consider a redundancy solution, such as clustering or mirroring, for the computer running SQL Server 2005 that is hosting the configuration database. For more information about using mirroring, see Using Database Mirroring with Office SharePoint Server and Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409).

  • Search Server 2008 does not support a backup made from one version to be restored to another version of Search Server 2008. To do this, use the upgrade process.

  • You must make sure that the Windows SharePoint Services Administration service is started on all farm servers before restoring. This service is not started by default on stand-alone installations.

  • If you are restoring by using the SharePoint Central Administration Web site, the database server's SQL account, the Timer service account, and the Central Administration application pool account must have Read permissions to the backup locations.

  • If you are using the Stsadm command-line tool, the account you logged on with must have Read permissions to the backup locations.

  • If the crawl-related account's credentials have changed between the time you backed up and the time you restore, you must reenter all crawl-related passwords after a restore is performed. This includes the password of the default content access account and each of the include crawl rules that has credentials.

  • Before restoring an SSP on a stand-alone installation, the administrator must manually start the Microsoft SharePoint Services Administration service so that search can be provisioned. This service is required to create the search directories on the local server. These directories hold the search index files.

  • On stand-alone installations, you must restart the Timer service before restoring the SSP.

  • If you are restoring or migrating search services and indexes to a new installation, make sure the search service is running before performing the restore.

  • After restoration, search might take up to 15 minutes to be available again.

  • Make sure that the synchronization service is paused before restoring any Web Applications.

  • You cannot perform more than one restore from the same backup at the same time.

See Also

Concepts

Back up and restore an entire farm (Search Server 2008)
Back up a farm by using built-in tools (Search Server 2008)
Restore a farm by using built-in tools (Search Server 2008)
Back up a farm by using SQL Server tools (Search Server 2008)
Restore a farm by using SQL Server tools (Search Server 2008)
Restore a farm after a configuration database problem (Search Server 2008)


Back up a farm by using built-in tools (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

There are two methods you can use to back up and restore data for Microsoft Search Server 2008 by using SharePoint Products and Technologies:

  • You can use the SharePoint Central Administration Web site to back up and restore Search Server 2008. This tool allows you to perform backups and restorations from the user interface. When you use this method, you can back up the server farm, Web applications, and any or all of the content databases in your server farm. You can use the Stsadm command-line tool to view backup and recovery history and to view backup and recovery job status.

  • You can use the Stsadm command-line tool to back up the server farm, Web applications, and any or all of the content databases in your server farm. You can use Stsadm to view backup and recovery history and to view backup and recovery job status. This method of backing up and restoring data does not require SQL Server 2000 tools or SQL Server 2005 tools. However, you must still be an administrator on a server computer that has Search Server 2008 installed or one of the server products in the Office 2007 release in order to perform this method of backing up and restoring.

Using the built-in tools of Search Server 2008, you can back up and restore an entire server farm or specific Web applications and content databases. These built-in tools allow you to keep elements of your server farm, such as search and the Shared Services Provider, synchronized when backing up and restoring.

For more information about how the data protection tools included with Search Server 2008 compare with other tools for protecting data, see Choose backup and recovery tools (Office SharePoint Server).

You can use the following procedures to back up and restore data for Search Server 2008 by using built-in tools.

Back up your farm by using built-in tools

The following are required to perform the procedures for this task:

  • To back up your farm using the Central Administration Web page, you must be a member of the Farm Administrators SharePoint group.

  • To back up your farm using the Stsadm command-line tool, you must be a member of the Administrators group on the local server computer.

To back up your farm, you can perform either of the following two procedures:

  • Back up a farm by using Central Administration (Search Server 2008)

  • Back up a farm by using the Stsadm command-line tool (Search Server 2008)

Note Note:

The SharePoint Central Administration Web site cannot automate backups. Backup automation using the Stsadm command-line tool requires a custom batch file and use of the Task Scheduler in Microsoft Windows.

See Also

Concepts

Back up and restore an entire farm (Search Server 2008)
Restore a farm by using built-in tools (Search Server 2008)
Back up a farm by using SQL Server tools (Search Server 2008)
Restore a farm by using SQL Server tools (Search Server 2008)
Restore a farm after a configuration database problem (Search Server 2008)


Back up a farm by using Central Administration (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

This article guides you through the process of using the SharePoint Central Administration Web site to back up Microsoft Search Server 2008.

Before you perform these procedures:

  • Be sure that you have read and understand the requirements described in Back up a farm by using built-in tools (Search Server 2008).

  • Confirm that you are logged on to the server that is running the SharePoint Central Administration Web site.

Back up a farm by using Central Administration

Important Important:

You must be a member of the Farm Administrators SharePoint group to complete this procedure.

Back up a farm by using Central Administration

  1. On the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Perform a Backup.

  2. On the Select Component to Backup page, select Farm, and then click Continue to Backup Options.

  3. On the Select Backup Options page:

    1. In the Backup Content section, ensure that Farm is displayed.

    2. In the Type of Backup section, select Full.

    3. In the Backup File Location section, type the Universal Naming Convention (UNC) path to the backup folder.

  4. Click OK.

    You can view the backup job status on the Backup status page by clicking Refresh. The page also refreshes every 30 seconds automatically. Backup and recovery are Timer service jobs, so it may take few seconds for the backup to start.

    If you receive any errors, you can find more information by looking in the spbackup.log at the UNC path that you specified in step 3.

See Also

Concepts

Back up a farm by using built-in tools (Search Server 2008)
Back up a farm by using the Stsadm command-line tool (Search Server 2008)


Back up a farm by using the Stsadm command-line tool (Search Server 2008)
DropDown image

Updated: 2009-06-25

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Before you perform these procedures:

  • Be sure that you have read and understand the requirements described in Back up a farm by using built-in tools (Search Server 2008).

  • Confirm that you are logged on to the server that is running the SharePoint Central Administration Web site.

Back up a farm by using the Stsadm command-line tool

Important Important:

To run the Stsadm command-line tool, you must be a member of the Administrators group on the local computer.

Back up a server farm by using the Stsadm command-line tool

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. Type the following command, and then press ENTER:

    stsadm -o backup -directory <\\server name\folder name> -backupmethod full

    If the backup completes successfully, the command window displays the following text:

    CopyCode image Copy Code
    Completed with 0 warnings.
Completed with 0 errors.
Backup completed successfully.
---------------------------------------------------------
Operation completed successfully.

    If the backup does not complete successfully, review the spbackup.log file.

    For more information, see <Technical reference topic for this Stsadm operation>.

Schedule or delay backups

It is not possible to schedule backups from the SharePoint Central Administration Web site. There is no operation that enables you to automate backups by using the Stsadm command-line tool. You can, however, automate the process by creating a batch file and then using Task Scheduler in Microsoft Windows Server 2003 to run the batch file at a specific time. Because performance can be affected when doing backups with the Search Server 2008 built-in tools, you might want to schedule your backups for off-peak times such as at night or on weekends.

Use this procedure to create a batch file that will run a full backup of your Search Server 2008 server farm. This procedure assumes that you have already created a shared folder for your backups. For more information about how to create a shared folder, see Prepare to back up and restore a farm (Search Server 2008).

Automate or delay backup of your farm

Tip Tip:

To run the Stsadm command-line tool, you must be a member of the Administrators group on the local computer. When using Task Scheduler, ensure that the system date and time on your computer are accurate. To verify or change this information, double-click the time indicator on the taskbar.

Create a batch file

  1. Click Start, and then click Run.

  2. Type notepad, and then click OK.

  3. In Notepad, type the following text:

    CopyCode image Copy Code
    @echo off
echo ===============================================================
echo Back up the farm to C:\backup
echo ===============================================================
cd %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\BIN
@echo off
stsadm.exe -o backup -directory "\backup" -backupmethod full
echo completed
    Note Note:

    Change "C:\backup" and "\backup" to the name of your backup shared folder.

  4. In Notepad, on the File menu, click Save As.

  5. In the Save As box, select the folder where you want to keep your batch file.

  6. Using the ".bat" file name extension, type the name of the file in the File name box, for example, backup_batch.bat.

  7. In the Save as type box, click All files.

  8. Click Save.

Schedule a backup

  1. Start the Scheduled Task Wizard, and then click Next.

  2. Click Browse, navigate to the batch file that you just created, and then click Open.

  3. Type a name for your task, for example, backup_batch.

  4. Select how often you want this task performed (for example, weekly), and then click Next.

  5. To automatically perform this backup periodically, select an interval such as Weekly or Monthly. To perform this backup one time, or to delay a single backup, select One time only.

  6. Choose a time and start date for your backup.

  7. Type a name and password for a user, and then click Next. This task will run as if it were started by that user.

  8. Click Finish.

    To configure advanced settings for the task, select the Open advanced properties for this task when I click Finish check box in the final page of the wizard. This opens the properties dialog box for the task when you click Finish. You can then change the program being run on the Task tab, fine-tune the schedule on the Schedule tab, customize settings on the Settings tab, or set user and group permissions on the Security tab.

See Also

Concepts

Back up a farm by using built-in tools (Search Server 2008)
Back up a farm by using Central Administration (Search Server 2008)


Restore a farm by using built-in tools (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Microsoft Search Server 2008 provides two methods for restoring a server farm, Web applications, and content databases. Restoring by using the SharePoint Central Administration Web site offers the convenience of working from the user interface, whereas restoring by using the Stsadm command-line tool offers a wide range of parameters and allows automation of your recovery process.

Restore your farm by using built-in tools

Before restoring your farm, ensure that the requirements in the following list are met.

  • To restore your farm by using the SharePoint Central Administration Web site, the database server's SQL account, the Timer service account, and the Central Administration pool account must have Read permissions to the backup locations (the Timer service account and the Central Administration pool account are generally the same).

  • To restore your farm using the Stsadm command-line tool, ensure that The Windows SharePoint Services Administration service is started on all farm servers. This service is not started by default on stand-alone installations.

  • Ensure that The Windows SharePoint Services Administration service is started on all farm servers. This service is not started by default on stand-alone installations.

Consider the following before restoring your farm:

  • Restoring from one version of SharePoint Products and Technologies to a different version is not supported.

  • After recovery, search might take up to 15 minutes to be available again and could be longer if search has to re-index all of the content. To avoid having search do a full recrawl, back up and restore the entire SSP node.

  • You cannot perform more than one recovery from the same backup at the same time. Moreover, you can only perform one recovery or one backup operation at a time.

To restore your farm, you can perform either of the following two procedures:

  • Restore a farm by using Central Administration (Search Server 2008)

  • Restore a farm by using the Stsadm command-line tool (Search Server 2008)

See Also

Concepts

Back up and restore an entire farm (Search Server 2008)
Back up a farm by using built-in tools (Search Server 2008)
Restore a farm by using SQL Server tools (Search Server 2008)
Back up a farm by using SQL Server tools (Search Server 2008)
Restore a farm after a configuration database problem (Search Server 2008)


Restore a farm by using Central Administration (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

This procedure can help you restore a Microsoft Office SharePoint Server 2007 for Search server farm by using the SharePoint Central Administration Web site. Using this procedure, the farm is restored to its original location.

Restore a farm by using the SharePoint Central Administration Web site

Important Important:

Membership in the Farm Administrators SharePoint group is the minimum necessary to complete this procedure.

Restore to the original server farm

  1. On the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Restore from Backup.

  2. On the Select Backup Location page, in the Backup File Location section, type the Universal Naming Convention (UNC) path to the backup folder.

  3. On the Select Backup Package to Restore page, select the backup file you want to use to restore, and then click Continue Restore Process.

  4. On the Select Component to Restore page, select the farm you want to restore, and then click Continue Restore Process.

  5. On the Select Restore Options page:

    1. In the Restore Component section, Ensure that Farm is displayed.

    2. In the Restore Options section, select Same configuration.

      A message is displayed, notifying you that the current farm will be overwritten. Click OK.

    3. In the Login Names and Passwords section, type the user name and password for your Farm Administrators account.

    4. In the New Names section, type new names and URLs for each component, or accept the default values.

    5. Click OK.

See Also

Concepts

Restore a farm by using built-in tools (Search Server 2008)
Restore a farm by using the Stsadm command-line tool (Search Server 2008)


Restore a farm by using the Stsadm command-line tool (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Before you perform this procedure, confirm that you are logged on to the server that is running the SharePoint Central Administration Web site. The procedures in this article assume that you are restoring to the server that produced the backup — that is, you are not migrating to a new or different server. For information about how to migrate by using the Stsadm command-line tool, see Move to another farm (Office SharePoint Server 2007).

Restore a server farm by using the Stsadm command-line tool

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete these procedures.

Restore a server farm by using the Stsadm command-line tool

  1. On the drive on which SharePoint Products and Technologies is installed, at a command prompt, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. To obtain the backup GUID for the specific backup that you want to restore, type the following command, and then press ENTER:

    stsadm -o backuphistory -directory <Path>

    where Path is the Universal Naming Convention (UNC) path to the shared folder that contains the backup. For more information, see Backuphistory: Stsadm operation (Office SharePoint Server).

  3. Type the following command, and then press ENTER:

    stsadm -o restore -directory <Path> -backupid <GUID from backuphistory> -restoremethod overwrite

    where Path is the UNC path to the backup shared folder and GUID from backuphistory is the GUID of for the specific backup package that you want to restore. By using the overwrite value for the -restoremethod parameter, you are directing the old farm to be overwritten by the restored one. For more information, see Restore: Stsadm operation (Office SharePoint Server).

  4. When you receive a warning that all selected items will be overwritten, type y and then press ENTER.

  5. When prompted, type the user name and password for the Web application and content databases.

  6. If the recovery completes successfully, the Command Prompt window displays the following text:

    CopyCode image Copy Code
    Completed with 0 warnings.
Completed with 0 errors.
Restore completed successfully.
---------------------------------------------------------
Operation completed successfully.

  7. If the recovery does not complete successfully, refer to the sprestore.log file.

See Also

Concepts

Restore a farm by using built-in tools (Search Server 2008)
Restore a farm by using Central Administration (Search Server 2008)


Back up a farm by using SQL Server tools (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Microsoft SQL Server 2005 provides high-performance backup and restore capability. Using the tools included with SQL Server 2005, you can prepare Microsoft Search Server 2008 to recover quickly from several potential data-loss events:

  • Media failure.

  • User errors — for example, dropping a table by mistake.

  • Hardware failures — for example, a damaged disk drive or permanent loss of a server.

  • Natural disasters.

There are three different kinds of backup that can be performed using SQL Server Management Studio:

  • Full Creates a complete backup of the database. A full backup should be performed the first time you back up a database and periodically thereafter.

  • Differential Backs up only the changes to the database that have occurred since the last full backup.

  • Transaction Log Enables you to recover the database to the point of failure or to a specific point in time.

How you use these backup methods is determined by the recovery model you choose for this data. For more information about recovery models in SQL Server 2005, see Overview of Recovery Models (http://go.microsoft.com/fwlink/?LinkId=114396&clcid=0x409).

Benefits of using SQL Server 2005 to back up and restore your Search Server 2008 farm include:

  • Existing SQL Server disaster recovery strategies can be re-used.

  • Full and differential backups can be configured with added verification.

  • A full-fidelity data backup is provided.

  • Can be faster than backups that are performed by using SharePoint Products and Technologies built-in tools.

For more information about how SQL Server 2005 compares with other tools for protecting data, see Choose backup and recovery tools (Office SharePoint Server).

Back up a Search Server 2008 farm

Warning Warning:

Before you begin, be sure you understand the synchronization problems that can occur when restoring the configuration database and the steps you can take to avoid them.

For more information about using SQL Server 2005 to back up databases, see Backing Up and Restoring Databases in SQL Server (http://go.microsoft.com/fwlink/?LinkID=102629&clcid=0x409).

Important Important:

Membership in the db_backupoperator fixed database role is the minimum required to complete these procedures.

Back up a Search Server 2008 farm

  1. Start SQL Server Management Studio and connect to the database server.

  2. In Object Explorer, expand Databases.

  3. Right-click the configuration database (usually named SharePoint_Config), point to Tasks, and then click Back Up.

  4. In the Back Up Database dialog box, select the type of backup that you want to perform from the Backup type list. For more information about which backup type to use, see Overview of Recovery Models (http://go.microsoft.com/fwlink/?LinkId=114396&clcid=0x409) in the SQL Server 2005 Books Online.

  5. Under Backup component, select the Database option.

  6. In the Name text box, type a name or use the default.

  7. In the Description text box, type a description of the backup.

  8. Under Backup set will expire, specify how long the backup should be kept, or use the default. When the backup set expires, the backup set can be overwritten by any subsequent backups with the same name. The backup set is set to never expire (0 days) by default.

  9. In the Destination section, specify a location to store the backup set, or use the default.

  10. Click OK to back up the database.

  11. Repeat steps 3 through 10 for the following databases

    • Content databases

    • Databases for Shared Services Providers (SSPs)

    • Search databases for the SSPs

    • Search databases

      Note Note:

      The search index is not stored in SQL Server. If you use SQL Server 2005 tools to back up search, you must perform a full crawl upon recovering the database. For more information, see Protecting Search in Choose what to protect (Office SharePoint Server).

Schedule a delayed or recurring backup

  1. In the Backup database dialog box, after you have entered the database backup information (see the Backup a server farm procedure earlier in this article), click the arrow to show the Script menu, and then click Script Action to Job.

  2. In the New Job dialog box, in the Select a page pane, click Schedules, and then click New.

  3. In the New Job Schedule page, specify a name, type, frequency, and duration that you want for the scheduled backup, and then click OK.

  4. Click OK to accept the scheduled job changes.

  5. Click OK to save the job changes and start the database backup.

    For more information about how to schedule a database backup, see How to schedule a database backup operation by using SQL Server Management Studio in SQL Server 2005 (http://go.microsoft.com/fwlink/?LinkId=109568&clcid=0x409).

See Also

Concepts

Back up and restore an entire farm (Search Server 2008)
Prepare to back up and restore a farm (Search Server 2008)
Back up a farm by using built-in tools (Search Server 2008)
Restore a farm by using built-in tools (Search Server 2008)
Restore a farm by using SQL Server tools (Search Server 2008)
Restore a farm after a configuration database problem (Search Server 2008)


Restore a farm by using SQL Server tools (Search Server 2008)
DropDown image

Updated: 2008-07-24

You can use Microsoft SQL Server 2005 tools to restore databases that are used by Microsoft Search Server 2008.

Important Important:

You cannot use the Search Server 2008 restore feature to restore the configuration database or the Central Administration content database. You cannot use the SQL Server 2005 backup and restore tools to restore your configuration database to a different farm or topology configuration.

You can restore the following databases:

  • Content databases

  • Databases for Shared Services Providers (SSPs)

  • Search databases for the SSPs

  • Search databases

    Note Note:

    The search index is not stored in SQL Server. If you use SQL Server 2005 tools to back up and restore search, you must perform a full crawl upon restoring the database. For more information, see Protecting Search in Choose what to protect (Office SharePoint Server).

  • Central Administration content database

  • Configuration database

    Note Note:

    The configuration database and the Central Administration content database contain computer-specific information. Therefore, you can restore them only to an environment that you configure to be precisely the same, including all software updates, server names, and numbers of servers. That is, you cannot back up the configuration database, change your topology or server roles, and then restore the configuration database.

For more information about using SQL Server to restore databases, see Backing Up and Restoring Databases in SQL Server (http://go.microsoft.com/fwlink/?LinkID=102629&clcid=0x409).

Using SQL Server tools to recover a database

Note Note:

When protecting Search Server 2008, we recommend that you configure a recovery farm — a second farm that is only used to restore data — for site and item recovery. The recovery farm is not intended to be a live farm. The recovery farm does not need to have the same hardware as your primary farm — we recommend that you use a single server installation or a virtual farm.

You should recover your database in the following order:

  1. If possible, back up the live transaction log of the current database to protect any changes that have been made since the last full backup.

  2. Restore the last full database backup.

  3. Restore the most recent differential database backup since the last full database backup.

  4. Restore all transaction log backups since the last full or differential database backup.

Warning Warning:

Recovery of the SharePoint configuration database cannot be performed by using this procedure.

Important Important:

Membership in the dbcreator fixed server role is the minimum required to perform this procedure.

Restore an existing database

  1. If the Windows SharePoint Services Timer service is running, stop the service and wait for a few minutes for any currently running stored procedures to complete. Do not restart the service until you have restored all the databases that you need to restore.

  2. Start SQL Server Management Studio and connect to the database server.

  3. In Object Explorer, expand Databases.

  4. Right-click the database that you want to restore, point to Tasks, point to Restore, and then click Database.

    The database is automatically taken offline during the restore operation and cannot be accessed by other processes.

  5. In the Restore Database dialog box, specify the destination and the source, and then select the backup set or sets that you want to restore.

    The default values for destination and source typically suit most recovery scenarios.

  6. In the Select a page pane, click Options.

  7. In the Restore options section, select only Overwrite the existing database. Unless your environment or policies require otherwise, do not select the other options in this section.

  8. In the Recovery state section:

    • If you have included all the transaction logs that you must restore, select RESTORE WITH RECOVERY.

    • If you must restore additional transaction logs, select RESTORE WITH NORECOVERY.

    • The third option, RESTORE WITH STANDBY is not used in this scenario.

      Note Note:

      For more information about these recovery options, see Restore Database (Options Page) (http://go.microsoft.com/fwlink/?LinkId=114420&clcid=0x409).

  9. Click OK to complete the restore operation.

  10. Repeat steps 4 through 9 for each database that you are restoring.

  11. Start the Windows SharePoint Services Timer service.

See Also

Concepts

Back up and restore an entire farm (Search Server 2008)
Prepare to back up and restore a farm (Search Server 2008)
Back up a farm by using built-in tools (Search Server 2008)
Restore a farm by using built-in tools (Search Server 2008)
Back up a farm by using SQL Server tools (Search Server 2008)
Restore a farm after a configuration database problem (Search Server 2008)


Restore a farm after a configuration database problem (Search Server 2008)
DropDown image

Updated: 2008-08-14

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

This article provides information and procedural steps for restoring your Microsoft Search Server 2008 environment when the information in the configuration database is not synchronized with the actual configuration of the farm. This can happen if configuration changes are made and these changes are not recorded in the configuration database — for example, if you move a content database from one Web application to another without detaching and re-attaching the database by using the Central Administration Web site. Similarly, this can happen if you use the Stsadm command-line tool to move the content database, but you do not use the preparetomove operation before you move the content database.

Actions that might lead to a configuration database that is not synchronized with the farm include:

  • Improperly moving a content database.

  • Deleting a Web site by using Internet Information Services Manager instead of removing it by using Search Server 2008 tools.

  • Making configuration changes to your farm by some means other than Search Server 2008 tools.

The symptoms of a configuration database that is not synchronized with the farm include:

  • Sites that should be available are not available (user sees a 404 error in the browser), but a site with that URL cannot be created.

  • Sites that should not be available — that is, they were removed — are available.

Configurations in Search Server 2008 are set in Central Administration and stored in the configuration database and the Central Administration content database. Although the configuration database and the Central Administration content database can be backed up, restoring backups of the configuration database and the Central Administration content database taken from a running farm is not supported.

If the configuration database or the Central Administration content database of a farm is not synchronized, you must re-create both databases by using the Psconfig command-line tool.

We strongly recommend that you document all configuration settings and all your customizations so that you can correctly re-create the databases. If you have not documented these settings, you must re-create them to the best of your ability when you re-create the configuration database and the Central Administration content database.

Configuration settings in Search Server 2008 that you should document include:

  • Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account).

  • Alternate access mapping settings.

  • Farm-level search settings.

  • E-mail settings.

  • Recycle Bin settings and other Web application general settings.

  • A/V settings.

  • Usage analysis processing settings.

  • Diagnostic logging settings.

  • Content deployment settings.

  • Timer job settings.

  • HTML viewer settings.

  • Database names and locations.

  • Web application names and databases. Be sure to document the content database names associated with each Web application.

  • Crawler impact rules.

  • Default quota templates.

  • Blocked file types.

Task requirements

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete these procedures.

Farm recovery overview

The following list provides the basic steps to recover your farm after a configuration database problem.

On the destination server:

  1. Run Setup and select the Complete server installation type.

  2. Run the SharePoint Products and Technologies Configuration Wizard to:

    1. Create a new farm.

    2. Create a new configuration database.

  3. Configure the farm services.

  4. Create Web applications.

  5. Create a Web application for other content as needed.

  6. Follow the procedure for moving to a different database server in Move all databases (Search Server 2008).

See Also

Concepts

Back up and restore an entire farm (Search Server 2008)
Prepare to back up and restore a farm (Search Server 2008)
Back up a farm by using built-in tools (Search Server 2008)
Restore a farm by using built-in tools (Search Server 2008)
Back up a farm by using SQL Server tools (Search Server 2008)
Restore a farm by using SQL Server tools (Search Server 2008)


Back up and restore Web applications by using built-in tools (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

You can use the tools that are included with Microsoft Search Server 2008 to back up and restore Web applications. The Central Administration Web site offers a simple, UI-based method to manage content backup and recovery and also to view job history and status. The Stsadm command line tool offers a faster and more flexible command line-based approach to content backup and recovery. You can use the Stsadm command-line tool together with Windows Scheduler to schedule delayed or periodic backups.

For more information about how the data protection tools that are included with Search Server 2008 compare with other tools for protecting the SharePoint data, see Choose backup and recovery tools (Office SharePoint Server).

You can back up and restore data for Search Server 2008 by using any of the following methods.

Back up Web applications by using SharePoint built-in tools

Use this procedure to back up a Web application by using the SharePoint Central Administration Web site.

Important Important:

Membership in the Farm Administrators SharePoint group is the minimum that you must have to complete this procedure.

To back up a Web application by using the user interface

  1. On the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Perform a backup.

  2. On the Select Component to Backup page, select the check boxes for the Web applications that you want to back up. The check boxes for any subordinate Web applications and content databases are automatically selected. Click Continue to Backup Options.

  3. On the Select Backup Options page, a differential backup backs up data that is created or changed since the last backup. If you are performing a combination of full and differential backups, the recovery process requires that you have the last full backup and the last differential backup.

    • In the Backup Content section, verify that the Web applications that you selected is displayed.

    • In the Type of Backup section, select Full.

    • In the Backup File Location section, type the UNC pat the backup folder.

  4. Click OK.

    You can view the backup job status on the back up status page by clicking Refresh. The page also refreshes every 30 seconds automatically. Backup and recovery is a Timer service job, which may take few seconds for the backup to start.

    If you receive any errors, you can find more information by looking in the spbackup.log at the UNC path you specified earlier.

Use this procedure to back up a Web application by using the Stsadm command-line tool.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete this procedure.

To back up a Web application by using the command line

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. If you do not already know what node you want to back up, type the following command:

    stsadm -o backup -showtree

    Note Note:

    Items enclosed by square brackets ([ ]) cannot be directly selected for backup but are backed up when their parent item is selected.

  3. To back up a Web application, type the following command:

    stsadm -o backup -directory <\\server name\folder name> -backupmethod full -item <Web application name>

    where \\server name\folder name is the UNC path of the backup folder and where Web application name is the name of the Web application that you want to back up. You might use the full farm path notation as displayed by the showtree parameter or the name of the component in the path if it has a unique name — for example, Windows SharePoint Services Web Application\SharePoint-80.

  4. If the backup is completed successfully, the Command Prompt window displays the following text:

    CopyCode image Copy Code
    Completed with 0 warnings.
Completed with 0 errors.
Backup completed successfully.
---------------------------------------------------------
Operation completed successfully.

  5. If there are errors or warnings, or if the backup is not completed successfully, review the spbackup.log file in the folder that you specified in step 3.

Schedule or delay backups

You cannot schedule backups from the SharePoint Central Administration Web site. However, you can automate the process by creating a batch file and then by using Task Scheduler in Windows Server 2003 to run the batch file at a specific time. Because performance can be affected when doing backups with the Search Server 2008 built-in tools, you might want to schedule your backups for off-peak times such as at night or on weekends.

Use this procedure to create a batch file that will run a full backup of the Web application. This procedure assumes that you have already created a shared folder for your backups. For more information about how to create a shared folder, see Prepare to back up and restore a farm (Search Server 2008).

Tip Tip:

When you use Task Scheduler, make sure that the system date and time on your computer are accurate. To verify or change this information, double-click the time indicator on the taskbar.

To create a batch file

  1. Click Start, and then click Run.

  2. Type notepad, and then click OK.

  3. In Notepad, type the following text:

    CopyCode image Copy Code
    @echo off
echo ===============================================================
echo Back up sites for the farm to C:\backup
echo ===============================================================
cd \Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN
@echo off
stsadm -o backup -directory <\\server name\folder name> -backupmethod full -item <Web application name>
echo completed

    where \\server name\folder name is the UNC path of the backup folder and where Web application name is the name of the Web application that you want to back up. You might use the full farm path notation as displayed by the showtree parameter or the name of the component in the path if it has a unique name — for example, Windows SharePoint Services Web Application\SharePoint-80.

  4. In Notepad, on the File menu, click Save As.

  5. In the Save As box, select the folder where you want to keep your batch file.

  6. Use the ".bat" file name extension; type the name of the file in the File name box, for example, backup_batch.bat.

  7. In the Save as type box, click All files.

  8. Click Save.

To schedule a backup

  1. Start the Scheduled Task Wizard, and then click Next.

  2. Click Browse, locate the batch file that you created, and then click Open.

  3. Type a name for your task, for example, backup_batch.

  4. Select how frequently you want this task to be performed (for example, weekly), and then click Next.

  5. To automatically perform this backup periodically, select an interval such as Weekly or Monthly. To perform this backup one time, or to delay a single backup, select One time only.

  6. Determine a time and start date for your backup.

  7. Type a name and password for a user, and then click Next. This task will run as if it were started by that user.

  8. Click Finish.

    To configure advanced settings for the task, select the Open advanced properties for this task when I click Finish check box in the final page of the wizard. This opens the properties dialog box for the task when you click Finish. You can then change the program being run on the Task tab, fine-tune the schedule on the Schedule tab, customize settings on the Settings tab, or set user and group permissions on the Security tab.

Restore SharePoint Web applications by using built-in tools

Use this procedure to restore a SharePoint Web application by using the built-in tools.

Important Important:

Membership in the Farm Administrators SharePoint group is the minimum that is required to complete this procedure.

Restore a Web application by using the user interface

  1. On the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Restore from Backup.

  2. On the Select Backup Location page, in the Backup File Location section, enter the universal naming convention (UNC) path of the backup folder.

  3. On the Select Backup Package to Restore page, select the backup file that you want to use to restore, and then click Continue Restore Process.

  4. On the Select Component to Restore page, select the Web applications that you want to restore, and then click Continue Restore Process.

  5. On the Select Restore Options page:

    1. In the Restore Component section, verify that the Web applications that you selected is displayed.

    2. In the Restore Options section, select Same configuration.

      A message is displayed, notifying you that the current farm will be overwritten. Click OK.

    3. In the New Names section, type new names and URLs for each component, or accept the default values.

  6. Click OK.

Use this procedure to restore a Web application by using the Stsadm command-line tool.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete this procedure.

Restore a Web application by using the command line

  1. On the drive where SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. To obtain the backup GUID for the specific backup that you want to restore, type the following command, and then press ENTER:

    stsadm -o backuphistory -directory <UNC path>

    where UNC path is the path of the shared folder that contains the backup.

  3. If you do not already know the name of the Web applications that you want to restore, type the following command, and then press ENTER:

    stsadm -o restore -showtree -directory <UNC path> -backupid <GUID from backuphistory>

    where UNC path is the path of the path to the shared folder that contains the backup and where GUID from backuphistory is the GUID of the backup package that you want to restore.

    Note Note:

    Items enclosed by square brackets ([ ]) cannot be restored.

  4. To restore a Web application, type the following command, and then press ENTER:

    stsadm -o restore -directory <UNC path> -backupid <GUID from backuphistory> -item <created path from tree> -restoremethod overwrite

    where UNC path is the UNC path of the backup shared folder, GUID from backuphistory is the GUID for the specific backup package that you want to restore, and created path from tree is the full farm path notation as displayed by the -showtree parameter.

  5. When you receive a warning that all selected items will be overwritten, type y, and then press ENTER.

  6. When you are prompted, type the user name and password for the Web application and content database.

  7. If the recovery is completed successfully, the Command Prompt window displays the following text:

    CopyCode image Copy Code
    Completed with 0 warnings.
Completed with 0 errors.
Restore completed successfully.
---------------------------------------------------------
Operation completed successfully.

  8. If the recovery is not completed successfully, you receive the following message:

    CopyCode image Copy Code
    The restore job failed. For more information, see the error log that is located in the backup directory.

    The referenced error log will be the sprestore.log file in the backup shared folder.

See Also

Concepts

Back up and restore a farm (Search Server 2008)
Back up and restore an entire farm (Search Server 2008)
Back up and restore site collections by using built-in tools (Search Server 2008)
Back up and restore databases (Search Server 2008)


Back up and restore site collections by using built-in tools (Search Server 2008)
DropDown image

Updated: 2009-05-14

In this article:

  • Back up a site collection by using SharePoint built-in tools

  • Restore site collections by using SharePoint built-in tools

  • Schedule or delay backups

You can use the tools that are included with Microsoft Search Server 2008 to back up and restore your site collections. The Stsadm command-line tool offers a fast and flexible, command line-based approach to content backup and recovery. You can use the Stsadm command-line tool together with Windows Scheduler to schedule delayed or periodic backups.

For more information about how the data protection tools that are included with Search Server 2008 compare with other tools for protecting the SharePoint data, see Choose backup and recovery tools (Office SharePoint Server).

Important Important:

If changes are made to the site collection during the backup process, the backup can become corrupted. Backing up large site collections can take a long time. To reduce the chance that user activity will interfere with a site collection backup, or that the time that is required to back up large site collections will exceed the available maintenance window, follow these recommendations:

  • For the duration of the backup, set the site collection URL to read-only by using the Setsitelock operation in the Stsadm command-line tool. This lets users view content on the site, but prevents activities such as adding or changing content that interfere with the backup process. When the backup is complete, return the access setting of the site collection URL to its default state.

  • If the size of the site collection that you want to back up is 15 gigabytes (GB) or smaller, use the Stsadm command-line tool as shown in the procedures that follow.

  • If the size of the site collection that you want to back up is from 15 GB through 100 GB, use Microsoft SQL Server 2005 or Microsoft System Center Data Protection Manager 2007 to perform a full backup of the site collection database. For more information, see Back up a farm by using SQL Server tools (Office SharePoint Server 2007) or Back up and restore a site by using DPM (Office SharePoint Server).

  • If the size of the site collection that you want to back up is larger than 100 GB, use System Center Data Protection Manager to perform a differential backup of the site collection database. For more information, see Back up and restore a site by using DPM (Office SharePoint Server).

  • For more information about how to prevent data loss during a site collection backup, see the Knowledge Base article that describes Possible corruption of backup files (http://go.microsoft.com/fwlink/?LinkId=146346).

For more information about backup and recovery tools, see Choose backup and recovery tools (Office SharePoint Server).

Back up a site collection by using SharePoint built-in tools

Use this procedure to restrict access to the site collection during backup by using the Stsadm command-line tool.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete this procedure.

Limit access to the site collection during backup

  1. At a command prompt on the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. To determine the current access level of the site, type the following command, and then press ENTER:

    stsadm -o getsitelock -url <URL name>

    where URL name is the URL of the site collection that you want to back up. For more information, see Getsitelock: Stsadm operation (Office SharePoint Server).

  3. If the current access level allows changes to the site content, change it to read-only by typing the following command, and then pressing ENTER:

    stsadm -o setsitelock -url <URL name> -lock readonly

    where URL name is the URL of the site collection that you want to back up. For more information, see Setsitelock: Stsadm operation (Office SharePoint Server).

  4. When the backup is complete, use this procedure to return access to the site collection to the original setting determined in step 1.

Use the following procedure to back up a site collection by using the Stsadm command-line tool.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete this procedure.

Back up a site collection by using the Stsadm command-line tool

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. Type the following command:

    stsadm -o backup -url <URL name> -filename <\\server. name\folder name\file name> [-overwrite]

    where URL name is the URL of the site collection that you want to back up, and where \\server name\folder name\file name is the UNC path of the backup folder and the name of the file that you are backing up to. If there is an existing file for the backup, use the -overwrite parameter to overwrite the existing file.

  3. If the backup is completed successfully, the Command Prompt window displays the following text:

    CopyCode image Copy Code
    Operation completed successfully.

  4. If the backup is not completed successfully, the Command Prompt window provides additional details about the failure. Most typically, an incorrect URL or file name was given.

For more information about the Backup operation, see Export: Stsadm operation (Office SharePoint Server).

Restore site collections by using SharePoint built-in tools

Use this procedure to restore a site collection by using the Stsadm command-line tool.

Note Note:

A site collection identifier conflict can occur if a backed up site collection is restored to a content database that already contains a copy of the site collection. If a site collection identifier conflict occurs, the following error message will be displayed:

No content databases are available for this operation. Create a content database and then try the operation again. To create a content database, click "Content databases" on the Application Management page, select the Web application to use, and then click "Add a content database".

For more information, see Error message when you try to restore a Windows SharePoint Services 3.0 site collection by using a different name: "No content databases are available for this operation" (http://go.microsoft.com/fwlink/?LinkId=128251).

To avoid site collection identifier conflicts:

  • Restore the site collection to a different content database in the same Web application.

  • If you need to restore the site collection to the same content database, after you back up the site collection and before you restore it, delete the original site collection.

    If you are restoring a large site collection, you may want to restore it to a different content database first, then use the Stsadm deletesite operation with the -gradualdelete parameter in the original database. Finally, use the Stsadm mergecontentdbs operation to move the site collection back to the first content database. The -gradualdelete parameter was added as part of the April Cumulative Update. For more information, see Deploy software updates for Windows SharePoint Services 3.0.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete this procedure.

Restore a site collection by using the Stsadm command-line tool

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. To restore a site collection, type the following command, and then press ENTER:

    stsadm -o restore -url <URL name> -filename <UNC path>

    where URL name is the URL of the site collection that you want to restore and UNC path is the UNC path of the backup shared folder.

  3. When you receive a warning that all selected items will be overwritten, type y, and then press ENTER.

  4. When prompted, type the user name and password for the Web application and content databases.

  5. If the recovery is completed successfully, the Command Prompt window displays the following text:

    CopyCode image Copy Code
    Operation completed successfully.

    If the recovery is not completed successfully, the Command Prompt window provides additional details about the failure. Most typically, an incorrect URL or file name was given.

  6. If access to the site collection was limited during the backup procedure, the restricted access settings might have been applied to the restored sites. If so, you must use the setsitelock operation to return the site lock settings to their pre-backup status.

    1. To determine the current access level of the site, type the following command, and then press ENTER:

      stsadm -o getsitelock -url <URL name>

      where URL name is the URL of the site collection that you want to back up. For more information, see Getsitelock: Stsadm operation (Office SharePoint Server).

    2. If the current access level is too restrictive, change it by typing the following command, and then pressing ENTER:

      stsadm -o setsitelock -url <URL name> -lock <Access Level>

      where URL name is the URL of the site collection that you want to back up and Access Level is the site lock setting the site had before being backed up. For more information, see Setsitelock: Stsadm operation (Office SharePoint Server).

For more information about the Restore operation, see Restore: Stsadm operation (Office SharePoint Server).

Schedule or delay backups

It is not possible to schedule backups from the SharePoint Central Administration Web site. There is no operation that enables you to automate backups by using the Stsadm command-line tool. You can, however, automate the process by creating a batch file and then using Task Scheduler in Windows Server 2003 to run the batch file at a specific time. Because performance can be affected when doing backups with the Search Server 2008 built-in tools, you might want to schedule your backups for off-peak times such as at night or on weekends.

Use this procedure to create a batch file that will run a full backup of your site collection. This procedure assumes that you have already created a shared folder for your backups. For more information about how to create a shared folder, see the following article Prepare to back up and restore a farm (Search Server 2008).

Tip Tip:

When using Task Scheduler, make sure that the system date and time on your computer are accurate. To verify or change this information, double-click the time indicator on the taskbar.

Create a batch file

  1. Click Start, and then click Run.

  2. Type notepad, and then click OK.

  3. In Notepad, type the following text:

    CopyCode image Copy Code
    @echo off
echo ===============================================================
echo Back up sites for the farm to C:\backup
echo ===============================================================
cd \Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN
@echo off
stsadm -o backup -directory <\\server name\folder name> -backupmethod full -item <Web application name>
echo completed

    where \\server name\folder name is the UNC path of the backup folder and where Web application name is the name of the site collection that you want to back up. You might use the full farm path notation as displayed by the showtree parameter or the name of the component in the path if it has a unique name — for example, Windows SharePoint Services Web Application\SharePoint-80.

  4. In Notepad, on the File menu, click Save As.

  5. In the Save As box, select the folder where you want to keep your batch file.

  6. Use the ".bat" file name extension; type the name of the file in the File name box, for example, backup_batch.bat.

  7. In the Save as type box, click All files.

  8. Click Save.

Schedule a backup

  1. Start the Scheduled Task Wizard, and then click Next.

  2. Click Browse, locate the batch file that you just created, and then click Open.

  3. Type a name for your task, for example, backup_batch.

  4. Select how often you want this task performed (for example, weekly), and then click Next.

  5. To automatically perform this backup periodically, select an interval such as Weekly or Monthly. To perform this backup one time, or to delay a single backup, select One time only.

  6. Choose a time and start date for your backup.

  7. Type a name and password for a user, and then click Next. This task will run as if it were started by that user.

  8. Click Finish.

    To configure advanced settings for the task, select the Open advanced properties for this task when I click Finish check box in the final page of the wizard. This opens the properties dialog box for the task when you click Finish. You can then change the program being run on the Task tab, fine-tune the schedule on the Schedule tab, customize settings on the Settings tab, or set user and group permissions on the Security tab.

See Also

Concepts

Back up and restore a farm (Search Server 2008)
Back up and restore an entire farm (Search Server 2008)
Back up and restore Web applications by using built-in tools (Search Server 2008)
Back up and restore databases (Search Server 2008)


Back up and restore databases (Search Server 2008)
DropDown image

Updated: 2008-07-24

Important Important:

Although the configuration database and the SharePoint Central Administration Web site content database can be backed up, restoring backups of the configuration database and Central Administration content database from a farm by using the tools built in to SharePoint Products and Technologies is not supported.

This is because data in these databases may not be synchronized with data in other Microsoft Search Server 2008 databases. Therefore, the tools built in to SharePoint Products and Technologies do not recover these databases during a farm-level recovery.

If this data is not synchronized, users might experience various random errors. For more information, see Microsoft Knowledge Base article 948725: Restoration of the configuration database is not supported in SharePoint Server 2007 and in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=117755&clcid=0x409).

You can recover a farm, including the configuration database and Central Administration content database, in the following ways:

  • You can use farm-level backups of a running farm taken with System Center Data Protection Manager to recover an entire farm, including the configuration database and Central Administration content database. For more information, see How to Recover a Windows SharePoint Services Farm (http://go.microsoft.com/fwlink/?LinkId=102831&clcid=0x409).

  • You can restore a backup of the configuration database and Central Administration content database from a fully stopped farm. For more information, see Move all databases (Search Server 2008).

If the configuration of Central Administration content databases becomes unsynchronized, you must re-create both databases by using the SharePoint Products and Technologies Configuration Wizard or Psconfig command-line tool.

To protect the configuration database and Central Administration content database:

  • Document all configuration settings and all your customizations so that you can correctly re-create the databases. For more information about recovering a farm, see Restore a farm after a configuration database problem (Search Server 2008).

  • Consider a redundancy solution, such as clustering or mirroring, for the computer running SQL Server that is hosting the configuration database. For more information about using mirroring, see Using Database Mirroring with Office SharePoint Server and Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409).

The two most commonly used methods for backing up Search Server 2008 databases are:

  • The built-in backup tools included with Search Server 2008.

  • The database backup tools included with Microsoft SQL Server 2005.

Built-in tools

The Central Administration Web site offers a simple, UI-based method to manage farm backup and recovery as well as view job history and status. The Stsadm command line tool offers a faster and more flexible command line-based approach to farm backup and recovery. You can use the Stsadm command line tool in conjunction with Windows Scheduler to schedule delayed or periodic backups.

Microsoft SQL Server 2005

SQL Server 2005 provides high-performance backup and restore capability. Using the tools included with SQL Server 2005, you can prepare Search Server 2008 to recover quickly from several potential data-loss events:

  • Media failure.

  • User errors, for example, dropping a table by mistake.

  • Hardware failures, for example, a damaged disk drive or permanent loss of a server.

  • Natural disasters.

The benefits of using SQL Server 2005 to back up and restore your Search Server 2008 databases include:

  • Existing SQL Server disaster recovery strategies can be re-used.

  • Full and differential backups can be configured with added verification.

  • Provides a full-fidelity data backup.

  • Can be faster than Office SharePoint Server backups.

Back up and restore databases

Note Note:

If your IT environment requires that the database administrator (DBA) must back up or restore the databases associated with the Shared Services Provider (SSP), you must coordinate backup and restore operations with the DBA. Whether you use built-in tools or SQL Server 2005, the account used to back up the databases must be a member of the SQL Server db_backupoperator fixed database role. The account used to restore the databases must be a member of the SQL Server dbcreator fixed server role.

To back up your Search Server 2008 databases, see Back up databases (Search Server 2008).

To restore your Search Server 2008 databases, see Restore databases (Search Server 2008).

See Also

Concepts

Back up and restore a farm (Search Server 2008)
Back up and restore an entire farm (Search Server 2008)
Back up and restore Web applications by using built-in tools (Search Server 2008)
Back up and restore site collections by using built-in tools (Search Server 2008)


Back up databases (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

This document guides you through the process of using Microsoft SQL Server 2005 tools or SharePoint Products and Technologies built-in tools to restore a database.

Back up databases by using built-in tools

Use this procedure to back up a database by using the SharePoint Central Administration Web site.

To back up your farm using SharePoint Products and Technologies built-in tools, you must use the following accounts and permissions:

  • You must be logged on to the server that runs the SharePoint Central Administration Web site.

  • You must have a shared folder that you will use to store the backup files. For more information about preparing for backup, see Prepare to back up and restore a farm (Search Server 2008).

Important Important:

You must be a member of the Farm Administrators SharePoint group to complete the following procedure.

Back up a database by using the user interface

  1. On the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Perform a backup.

  2. On the Select Component to Backup page, select the check boxes for the databases you want to back up. Click Continue to Backup Options.

  3. On the Select Backup Options page, a differential backup backs up data created or changed since the last backup. If you are performing a combination of full and differential backups, restoring will require you to have the last full backup, the last differential backup, and intervening differential backups.

    • In the Backup Content section, verify that the database you selected is displayed.

    • In the Type of Backup section, select Full.

    • In the Backup File Location section, type the UNC path of the backup folder.

  4. Click OK.

    You can view the backup job status on the backup status page by clicking Refresh. The page also refreshes every 30 seconds automatically. Backup and recovery is a Timer service job, so it may take few seconds for the backup to start.

    If you receive any errors, you can find more information by looking in the spbackup.log at the UNC path you specified above.

Use this procedure to back up a Web application by using the Stsadm command-line tool.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete this procedure.

Back up a database by using the command line

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. If you do not already know what node you want to back up, type the following command:

    stsadm -o backup -showtree

    Note Note:

    Items enclosed by square brackets ([ ]) cannot be directly selected for backup, but are backed up when their parent item is selected.

  3. To back up a database, type the following command:

    stsadm -o backup -directory <\\server name\folder name> -backupmethod full -item <database name>

    where \\server name\folder name is the UNC path to the backup folder and where database name is the name and node of the database that you want to back up, for example: WSS_Content_407f26d96bbf4158b2802a599ecfb718.

  4. If the backup completes successfully, the command window displays the following text:

    CopyCode image Copy Code
    Completed with 0 warnings.
Completed with 0 errors.
Backup completed successfully.
---------------------------------------------------------
Operation completed successfully.

  5. If there are errors or warnings, or if the backup does not complete successfully, review the spbackup.log file in the folder that you specified in step 3.

Back up a server farm by using SQL Server

Important Important:

You must be a member of the db_backupoperator fixed database role to complete the following procedures.

Back up a server farm by using SQL Server

  1. Start SQL Server Management Studio and connect to the database server.

  2. In Object Explorer, expand Databases.

  3. Right-click the configuration database (usually named SharePoint_Config), point to Tasks, and then click Back Up.

  4. In the Back Up Database dialog box, select the type of backup that you want to perform from the Backup type list. For more information about which backup type to use, see Overview of Recovery Models in the SQL Server 2005 Books Online.

  5. Under Backup component, select the Database option.

  6. In the Name text box, type a name or use the default.

  7. In the Description text box, type a description of the backup.

  8. Under Backup set will expire, specify how long the backup should be kept, or use the default. When the backup set expires, the backup set can be overwritten by any subsequent backups with the same name. The backup set is set to never expire (0 days) by default.

  9. In the Destination section, specify a location to store the backup set, or use the default.

  10. Click OK to back up the database.

  11. Repeat steps 3 through 10 for each of the databases you want to back up.

Schedule a delayed or recurring backup

  1. In the Backup Database dialog box, after you have entered the database backup information (see the "Back up a server farm by using SQL Server" procedure above), click the arrow to show the Script menu, and then click Script Action to Job.

  2. In the New Job dialog box, in the Select a page pane, click Schedules, and then click New.

  3. In the New Job Schedule page, specify a name, type, frequency, and duration that you want for the scheduled backup, and then click OK.

  4. Click OK to accept the scheduled job changes.

  5. Click OK to save the job changes and start the database backup.

    For more information about how to schedule a database backup, see How to schedule a database backup operation by using SQL Server Management Studio in SQL Server 2005 (http://go.microsoft.com/fwlink/?LinkId=109568&clcid=0x409).

See Also

Concepts

Back up and restore databases (Search Server 2008)
Restore databases (Search Server 2008)


Restore databases (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

You can restore the following databases:

  • Content databases

    Note Note:

    The search index is not stored in SQL Server. If you use SQL Server 2005 tools to back up and restore search, you must perform a full crawl upon restoring the database. For more information, see Protecting Search in Choose what to protect (Office SharePoint Server).

  • Central Administration content database

  • Configuration database

    Note Note:

    The configuration database and the Central Administration content database contain computer-specific information. Therefore, you can restore them only to an environment that you configure to be precisely the same, including all software updates, server names, and numbers of servers. That is, you cannot back up the configuration database, change your topology or server roles, and then restore the configuration database.

For more information about using SQL Server to restore databases, see Backing Up and Restoring Databases in SQL Server (http://go.microsoft.com/fwlink/?LinkID=102629&clcid=0x409).

Restore Search Server 2008 databases

Note Note:

When protecting Microsoft Search Server 2008, we recommend that you configure a recovery farm—a second farm, that is only used to restore data—for site and item recovery. The recovery farm is not intended to be a live farm. The recovery farm does not need to have the same hardware as your primary farm—we recommend that you use a single server installation or a virtual farm.

If your IT environment requires that your database administrator (DBA) must restore the databases associated with the Shared Services Provider (SSP), you must coordinate your backup and restore operations with your DBA.

Restore a database by using built-in tools

Use this procedure to restore a database by using the SharePoint Products and Technologies built-in tools.

Important Important:

The account used to restore the databases must be a member of the Farm Administrators SharePoint group and the SQL Server dbcreator fixed server role to complete the following procedure.

Restore a database by using the user interface

  1. On the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Restore from Backup.

  2. On the Select Backup Location page, in the Backup File Location section, enter the universal naming convention (UNC) path to the backup folder.

  3. On the Select Backup Package to Restore page, select the backup file you want to use to restore, and then click Continue Restore Process.

  4. On the Select Component to Restore page, select the database you want to restore and then click Continue Restore Process.

  5. On the Select Restore Options page:

    1. In the Restore Component section, verify that the database you selected is displayed.

    2. In the Restore Options section, select Same configuration.

      A message is displayed, notifying you that the current farm will be overwritten. Click OK.

    3. In the New Names section, type new names and URLs for each component, or accept the default values.

  6. Click OK.

Use this procedure to restore a database by using the Stsadm command-line tool.

Important Important:

The account used to restore the databases must be a member of the Administrators group on the local computer and the SQL Server dbcreator fixed server role to complete the following procedure.

Restore a database by using the command line

  1. On the drive where SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. To obtain the backup GUID for the specific backup that you want to restore, type the following command, and then press ENTER:

    stsadm -o backuphistory -directory <UNC path>

    where UNC path is the path to the shared folder that contains the backup.

  3. If you do not already know the name of the database you want to restore, type the following command, and then press ENTER:

    stsadm -o restore -showtree -directory <UNC path> -backupid <GUID from backuphistory>

    where UNC path is the path to the shared folder that contains the backup and where GUID from backuphistory is the GUID of the backup package that you want to restore.

    Note Note:

    Items enclosed by square brackets ([ ]) cannot be restored.

  4. To restore a database, type the following command and then press ENTER:

    stsadm -o restore -directory <UNC path> -backupid <GUID from backuphistory> -item <created path from tree> -restoremethod overwrite

    where UNC path is the UNC path to the backup shared folder, GUID from backuphistory is the GUID for the specific backup package that you want to restore, and created path from tree is the full farm path notation as displayed by the -showtree parameter.

  5. When you receive a warning that all selected items will be overwritten, type y and then press ENTER.

  6. When prompted, type the user name and password for the database.

  7. If the recovery completes successfully, the command window displays the following text:

    CopyCode image Copy Code
    Completed with 0 warnings.
Completed with 0 errors.
Restore completed successfully.
---------------------------------------------------------
Operation completed successfully.

  8. If the recovery does not complete successfully, the following message appears:

    CopyCode image Copy Code
    The restore job failed. For more information, see the error log that is located in the backup directory.

    The referenced error log will be the sprestore.log file in the backup shared folder.

Using SQL Server tools to restore a database

In the event of a failure, you must use your backups to restore the database. You should recover your database in the following order:

  1. If possible, back up the live transaction log of the current database to protect any changes that have been made since the last full backup.

  2. Restore the last full database backup.

  3. Restore the most recent differential database backup since the last full database backup.

  4. Restore all transaction log backups since the last full or differential database backup.

Warning Warning:

Recovery of the configuration database cannot be performed using this procedure. To restore the configuration database, see Restore a farm after a configuration database problem (Search Server 2008).

Important Important:

Membership in the dbcreator fixed server role is the minimum required to perform the following procedure.

Restore an existing database

  1. If the Windows SharePoint Services Timer service is running, stop the service and wait for a few minutes for any currently running stored procedures to complete. Do not restart the service until you have restored all the databases that you need to restore. To stop the Windows SharePoint Services Timer:

    1. In Microsoft Windows Server 2003, start the Services snap-in.

    2. Under Services (local), click Windows SharePoint Services Timer.

    3. Click Stop this service.

    4. Verify that all running jobs are complete before continuing with this procedure.

  2. Start SQL Server Management Studio and connect to the database server.

  3. In Object Explorer, expand Databases.

  4. Right-click the database that you want to restore, point to Tasks, point to Restore, and then click Database.

    The database is automatically taken offline during the restore operation and cannot be accessed by other processes.

  5. In the Restore Database dialog box, specify the destination and the source, and then select the backup set or sets that you want to restore.

    The default values for destination and source typically suit most recovery scenarios.

  6. In the Select a page pane, click Options.

  7. In the Restore options section, select only Overwrite the existing database. Unless your environment or policies require otherwise, do not select the other options in this section.

  8. In the Recovery state section:

    • If you have included all the transaction logs that you must restore, select RESTORE WITH RECOVERY.

    • If you must restore additional transaction logs, select RESTORE WITH NORECOVERY.

    • The third option, RESTORE WITH STANDBY is not used in this scenario.

      Note Note:

      For more information about these recovery options, see Restore Database (Options Page) (http://go.microsoft.com/fwlink/?LinkId=114420&clcid=0x409).

  9. Click OK to complete the restore operation.

  10. Repeat steps 4 through 9 for each database that you are restoring.

  11. Start the Windows SharePoint Services Timer service:

    • In Microsoft Windows Server 2003, start the Services snap-in.

    • Under Services (local), click Windows SharePoint Services Timer.

    • Click Start this service.

See Also

Concepts

Back up and restore databases (Search Server 2008)
Back up databases (Search Server 2008)


Clean up backup files (Search Server 2008)
DropDown image

Most data storage and backup retention policies allow for periodic cleanup of old or obsolete backups. It is very important that you retain backups for the time that is required. However, if you do not periodically remove or archive outdated backup files, short-term backup storage devices fill up quickly. Although SharePoint Products and Technologies does not provide an automated backup removal function, you can implement a simple script to perform this task.

Configure periodic backup removal

The following procedures include a sample Microsoft Visual Basic script that you can use and edit as necessary to do the following:

  • By using a single command, locate and delete backup files older than a specified time period.

  • Update the backup manifest file (spbrtoc.xml) to remove records of the deleted files.

  • Create a log file of backup removal activity.

  • Work together with the task scheduler to automate the periodic removal of obsolete backup files.

Warning Warning:

Use the code in this article at your own risk.

Microsoft provides programming examples for illustration only, without warranty either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or fitness for a particular purpose. This article assumes that you are familiar with the programming language that is being demonstrated and with the tools that are used to create and to debug procedures. Microsoft support engineers can help explain the functionality of a particular procedure. However, they will not edit these examples to provide additional functionality or construct procedures to meet your specific requirements.

If you have limited programming experience, consider contacting a Microsoft Certified Partner or the Microsoft fee-based consulting line at (800) 936-5200. For more information about Microsoft Certified Partners, see the Microsoft Partner Program Web site (http://go.microsoft.com/fwlink/?LinkId=128105).

For more information about the support options that are available and about how to contact Microsoft, see the Microsoft Help and Support Web site (http://go.microsoft.com/fwlink/?LinkId=128109).

The following are required to perform this task:

  • A script editor and debugger such as Microsoft Visual Studio 2008 (recommended) or a text editor such as Notepad.

  • Experience with scripting languages.

  • Backup files must be stored on devices that can be accessed on the network and that are operational.

  • A clear backup retention policy that specifies how long backup files must be kept.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete the following procedure.

Write a backup removal script

  1. Create a folder on the computer that will perform the backup removal task. This folder will contain the backup removal script and the log file.

  2. Start the script editor, and then copy and paste the following code example into the editing window:

    CopyCode image Copy Code
    '       Title: BackupCleanUp
' Description: Deletes SharePoint 2007 backups older than a specified
'              number of days and removes them from the backup history.

Dim nNumberOfDays
Dim strTOCFile
Dim dtDeleteDate

Set objXML = CreateObject("Microsoft.XMLDOM")
Set objFS  = CreateObject("Scripting.FileSystemObject")
Set objLog = objFS.OpenTextFile("BackupCleanUp.log",8,true)

' Validate Command Line Arguments and Initialize Data
If WScript.Arguments.Count = 2 Then
    If IsNumeric(WScript.Arguments(0)) Then
        nNumberOfDays = CInt(WScript.Arguments(0))
        dtDeleteDate = DateAdd("d",nNumberOfDays*-1,Now)
    Else
        WScript.Echo "<NumberOfDays> must be an integer value."
    End If
        strTOCFile = WScript.Arguments(1)
Else
    WScript.Echo "Usage: BackupCleanUp <NumberOfDays> <PathToTOC>"
    WScript.Quit
End If

objLog.WriteLine(Now() &vbTab& "Start: Clean up backups older than " &nNumberOfDays& " days from " &strTOCFile& ".")

' Load SharePoint Backup and Restore TOC File
objXML.Async = false
objXML.Load(strTOCFile)

If objXML.ParseError.ErrorCode <> 0 Then
    objLog.WriteLine(Now() &vbTab& "Error: Could not load the SharePoint Backup / Restore History." &vbCrLf&_
                     Now() &vbTab& "Reason: " &objXML.ParseError.Reason& ".")
    WScript.Quit
End If

' Delete Backup Nodes Older Than Deletion Date
For Each objNode in objXML.DocumentElement.ChildNodes
    If CDate(objNode.SelectSingleNode("SPFinishTime").Text) < dtDeleteDate Then
        If objNode.SelectSingleNode("SPIsBackup").Text = "True" Then
            objFS.DeleteFolder(objNode.SelectSingleNode("SPBackupDirectory").Text)
            objLog.WriteLine(Now() &vbTab& "Deleted: " &objNode.SelectSingleNode("SPBackupDirectory").Text& ".")
            objXML.DocumentElement.RemoveChild(objNode)
        End If
    End If
Next

' Save XML File With Old Nodes Removed
objXML.Save(strTOCFile)
objLog.WriteLine(Now() &vbTab& "Finish: Completed backup clean up.")

    You can edit the script as necessary to meet the requirements of the network, equipment, retention policies, or service agreements.

  3. Save the file as BackUpCleanUp.vbs in the folder that you created earlier.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete the following procedure.

Run the backup removal script

  1. At a command prompt, change to the directory that contains the BackUpCleanUp.vbs file.

  2. Type the following command, and then press ENTER:

    Cscript.exe BackUpCleanUp.vbs <Number of days> <\\server name\folder name>

    where <Number of days> is the maximum age of the backup files you want to keep (backup files older than this will be deleted by the BackUpCleanUp script) and <\\server name\folder name> is the path of the spbrtoc.xml backup manifest file.

  3. To troubleshoot the backup file removal process or to review progress, open the BackUpCleanUp.log file located in the same folder.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete the following procedure.

Schedule or delay backup removal

  1. Start the Scheduled Tasks Wizard, double-click Add Scheduled Task, and then click Next.

  2. Click Browse, navigate to %ROOT%\WINNT\System32\cscript.exe, and then click Open.

  3. Type a name for the task, for example, BackUpCleanUp.

  4. To automatically perform this backup periodically, select an interval such as Weekly or Monthly, and then click Next. To perform this backup one time, or to delay a single backup, select One time only.

  5. Choose a time and start date for the task, and then click Next.

  6. Type a user name and password in the appropriate boxes, confirm the password, and then click Next. This task will run as if it were started by that user.

  7. Select Open advanced properties for this task when I click Finish, and then click Finish.

  8. In the Advanced Properties dialog box, on the Task tab, in the Run text box, type the following command:

    Cscript.exe BackUpCleanUp.vbs <Number of days> <\\server name\folder name>

    where <Number of days> is the maximum age of the backup files that you want to keep (backup files older than this will be deleted by the BackUpCleanUp script) and <\\server name\folder name> is the path of the spbrtoc.xml backup manifest file.

  9. In the Start In text box, type the path of the folder where the BackUpCleanUp.vbs file is located.

  10. Select Enabled (scheduled task runs at specified time), and then clear the Run only if logged in check box.

  11. Click OK.

See Also

Concepts

Back up and restore a farm (Search Server 2008)
Back up and restore an entire farm (Search Server 2008)
Back up and restore Web applications by using built-in tools (Search Server 2008)
Back up and restore site collections by using built-in tools (Search Server 2008)
Back up and restore databases (Search Server 2008)


Use alternative methods to back up and restore content (Search Server 2008)
DropDown image

Updated: 2008-07-24

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Site protection and recovery refers to using tools to back up, version, and recover a site from accidental deletion or data corruption. Directly recovering a deleted site is not a feature that is available in Microsoft Search Server 2008. However, you can protect and recover sites by using the Stsadm export and import operations or tools such as Microsoft Office SharePoint Designer 2007.

Use alternative content protection methods

You can back up and restore specific data related to SharePoint Products and Technologies by using the following mechanisms:

  • Web site delete event

    For information about capturing and restoring content by using the Web site delete event, see Capture and restore content by using the Web site delete event (Search Server 2008).

  • Microsoft Office SharePoint Designer 2007

    For information about using Office SharePoint Designer 2007 to back up and restore content, see Capture and restore content by using SharePoint Designer (Search Server 2008).

  • Stsadm command-line tool

    For information about using Stsadm operations to archive sites, see Archive and retrieve content by using Stsadm import and export operations (Search Server 2008).

  • Database snapshots

    For information about using database snapshots to archive sites, see Archive site versions by using database snapshots (Search Server 2008).

See Also

Concepts

Protecting and restoring the farm (Search Server 2008)
Protect and restore content by using Recycle Bins and versioning (Search Server 2008)
Back up and restore a farm (Search Server 2008)
Troubleshooting backup and recovery (Search Server 2008)


Capture and restore content by using the Web site delete event (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

When a site is deleted, SharePoint Products and Technologies generates a Web Delete event. Microsoft IT (MSIT) has created Microsoft IT Site Delete Capture Feature 1.0 to detect and capture the content from the Web Delete event. When a Web Delete event is detected, the feature archives the site to a file share before the site is removed from the configuration database and the content database. Deleted sites are saved as .bak files in the specified backup directory. You then can use the restore Stsadm operation to restore a site. You can also configure the feature to send e-mail messages when a site has been archived and deleted or if the site was unable to be archived. The Microsoft IT Site Delete Capture Feature 1.0 is available from CodePlex governance.

This tool is not part of SharePoint Products and Technologies, and might not be updated. This tool is built on supported Microsoft technologies, but it is not supported by Microsoft.

Capture site content by using the Web delete event

Use the following procedure to set up the Microsoft IT Site Delete Capture Feature 1.0 on each Web server that you want to protect.

Important Important:

Memberships in the Farm Administrators SharePoint group and in the Administrators group on the local computer are the minimum requirements to complete these procedures.

Set up the Microsoft IT Site Delete Capture Feature 1.0

  1. Go to the CodePlex site (http://go.microsoft.com/fwlink/?LinkID=92875&clcid=0x409) and download the Microsoft IT Site Delete Capture Feature 1.0 (Package).zip file.

  2. Extract the files, and then copy the MSITSiteFeature, MSITDeleteFeature, MSITSiteFeatureStapling, and MSITDeleteFeatureStapling feature folders to the following folder: %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\TEMPLATE\FEATURES.

  3. Copy the MS.IT.SiteDeleteCapture.dll file to the C:\Windows\assembly folder.

  4. Copy the Messages.xml file to the %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\TEMPLATE\LAYOUTS\1033 folder.

    Note Note:

    If multiple language packs are installed on the server farm, the Messages.xml file must be copied to each local ID directory within the %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\TEMPLATE\LAYOUTS folder.

  5. On the drive on which SharePoint Products and Technologies is installed, open a command window and change to the following directory: %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\Bin.

  6. Type the following command, and then press ENTER:

    stsadm -o installfeature -name MSITSiteFeature

  7. Type the following command, and then press ENTER:

    stsadm -o installfeature -name MSITSiteFeatureStapling

  8. Type the following command, and then press ENTER:

    stsadm -o installfeature -name MSITDeleteFeature

  9. Type the following command, and then press ENTER:

    stsadm -o installfeature -name MSITDeleteFeatureStapling

    For more information, see Installfeature: Stsadm operation (Office SharePoint Server).

  10. Using a text editor, open the following file: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\TEMPLATE\FEATURES\MSITDeleteFeature\ConfigurationForReceiverDLL.xml.

  11. Under the BackupFolder node, specify a value for the backup folder location, and then save and close the file.

  12. On the SharePoint Central Administration Web site, on the Application Management tab, in the SharePoint Web Application Management section, click Manage Web application features.

  13. On the Manage Web Application Features page, click the Activate button next to Microsoft IT Site Delete Capture Feature 1.0. For more information about installing and configuring Microsoft IT Site Delete Capture Feature 1.0, refer to the Microsoft IT Site Delete Capture Feature 1.0 document included with the installation files.

Restore content

Use the following procedure to restore site content that has been deleted and captured by the Microsoft IT Site Delete Capture Feature 1.0.

Important Important:

Membership in the Farm Administrators SharePoint group is the minimum requirement to complete the following procedure.

Restore content from site delete capture

  1. Note the URL of the site you want to restore and the name of the backup file (.bak) that contains the desired content. You do not have to restore the site to the same location from which it was deleted.

  2. On the drive on which SharePoint Products and Technologies is installed, open the command line and change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  3. Type the following command, and then press ENTER:

    stsadm -o restore -url <Intended restore location> -filename <path and file name of backup file>

    When specifying the path to the backup file, you can use either a local or Universal Naming Convention (UNC) path.

    For more information, see Restore: Stsadm operation (Office SharePoint Server).

See Also

Concepts

Use alternative methods to back up and restore content (Search Server 2008)
Capture and restore content by using SharePoint Designer (Search Server 2008)
Archive and retrieve content by using Stsadm import and export operations (Search Server 2008)
Archive site versions by using database snapshots (Search Server 2008)


Capture and restore content by using SharePoint Designer (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Microsoft Office SharePoint Designer 2007 provides the ability to back up and restore site collections — down to the individual file level — and to remove them from the network for offline use. Backing up a Web site by using Office SharePoint Designer 2007 creates a content migration package (that is, a .cmp file). When you back up a Web site, you can choose to back up either the top-level Web site or the top-level Web site and any subsites. The backup file that you create includes list or library content, security settings, user information, navigation, customizations, and personalizations (such as views, site templates, and content types). The backup file does not include workflows, alerts, and properties stored at the site-collection level.

Restoring a Web site from Office SharePoint Designer 2007 requires that you create a new empty Web site and then restore the backup file to that site.

Capture site content by using SharePoint Designer

This procedure can help you use the Backup feature in Microsoft Office SharePoint Designer 2007 to make a backup copy of the content of a site or subsite.

Before you perform this procedure, confirm that you have read the topic Plan for backup and recovery (Office SharePoint Server).

Important Important:

To back up a site, you must be a site owner for that site, but you do not need administrative access to the server that is running Microsoft Search Server 2008.

Back up a site by using SharePoint Designer

  1. In Office SharePoint Designer 2007, on the File menu, click Open Site.

  2. In the Open Site dialog box, browse to and click the Web site that you want to back up, and then click Open.

  3. On the Site menu, point to Administration, and then click Backup Web Site.

  4. In the Backup Web Site dialog box, to include all subsites of the current Web site in the backup, select the Include subsites in archive check box.

  5. If the current Web site is low on available storage space, click Advanced, specify a new location, and then click OK.

    Backing up a Web site requires a location to store temporary backup files. By default, Office SharePoint Designer 2007 uses the current Web site. You can use another site on the same server or a location on another server on the same network — for example, \\Server name\Share name.

  6. In the Backup Web Site dialog box, click OK.

  7. In the File Save dialog box, choose a location to store the .cmp file.

  8. In the File name box, type the name for the file, and then click Save.

    If the site that you are backing up or restoring is large, the process can take a long time.

Restore site content by using SharePoint Designer

This procedure can help you use Microsoft Office SharePoint Designer 2007 to restore a site.

Before you perform this procedure, confirm that you have read the topic Plan for backup and recovery (Office SharePoint Server).

Restore a site by using SharePoint Designer

  1. Create a new, empty Web site as a destination site

    1. In Office SharePoint Designer 2007, on the File menu, click New.

    2. In the New dialog box, on the Web Site tab, click General, and then click Empty Web Site.

    3. In the Specify the location of the new Web site box, type or browse to the location to which you want to restore the backup site.

      You can restore the site to a different server and you can restore it as either a new top-level site or a subsite under an existing top-level site.

    4. Click OK.

  2. Restore the backup file to the destination site

    1. With the destination site open, on the Site menu, point to Administration, and then click Restore Web Site.

    2. In the File Open dialog box, browse to and click the .cmp file that you want to restore, and then click Open.

    3. In the Restore Web Site dialog box, click OK to confirm that you want to restore the .cmp file to the current empty Web site.

      If the site that you are backing up or restoring is large, the process can take a long time.

See Also

Concepts

Use alternative methods to back up and restore content (Search Server 2008)
Capture and restore content by using the Web site delete event (Search Server 2008)
Archive and retrieve content by using Stsadm import and export operations (Search Server 2008)
Archive site versions by using database snapshots (Search Server 2008)


Archive and retrieve content by using Stsadm import and export operations (Search Server 2008)
DropDown image

Updated: 2008-10-23

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

Microsoft Search Server 2008 includes the Stsadm.exe tool for command-line administration of servers and sites.

Benefits of this tool:

  • Can be used with Windows Task Scheduler to schedule backups.

  • Does not rely on the Windows SharePoint Services Timer service.

  • Provides restorable backups for Search.

  • Provides the ability to back up and restore at the farm level, Web application level, or site collection level. Stsadm full backups can be used to restore an entire farm or to restore the following objects in a farm: Web application, Shared Services Provider (SSP), or content database.

  • For backups that initially run 17 hours, the system automatically restarts the backup and allots an appropriate amount of time for the process to perform (longer than 17 hours).

Disadvantages of this tool:

  • Cannot back up directly to tape. Backup location must be a Universal Naming Convention (UNC) path.

  • Does not provide automatic deletion of old backup files. You may want to use the backup file deletion script provided in the Microsoft Knowledge Base article, How to automate the deletion of backups in SharePoint Server 2007 and in Windows SharePoint Services 3.0 by using a Visual Basic script.

  • As part of a farm backup, can back up the configuration database and the Central Administration content database, but will not restore them.

  • Does not back up any custom solution files in the Inetpub hive or in the 12 hive (that is, %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12).

  • Does not back up alternate access mappings.

  • Does not back up Internet Information Services (IIS) settings including host headers, dedicated IP addresses, and Secure Sockets Layer (SSL) certificates.

  • Site collection backups affect performance, and can cause access errors. They are not designed to be used when the server is under active load. Site collection backups can be slow when working with site collections larger than 12-15 gigabytes (GB). We recommend that you use SQL Server backups if you are working with site collections larger than 15 GB.

In addition to your hardware configuration, the size of the database, site collection, or Web application that you are working with can significantly affect backup and recovery performance.

The Stsadm command-line tool can be used to back up the configuration database and the Central Administration content database, but the configuration database and the Central Administration content database can only be restored to a server of the same name in the same location.

We recommend that you use differential backup tools outside of SharePoint Products and Technologies for your backup and recovery needs, such as Microsoft System Center Data Protection Manager, if backing up your system exceeds the maintenance window that you have available or if your system exceeds the following limits:

  • Content databases larger than 100 GB.

  • Site collections that you want to back up individually that are larger than 12 GB. If you want to back up a site collection individually that is larger than 12 GB, we recommend that you move it to its own database.

Archive site content by using the Stsadm command-line tool

You can use the Stsadm export operation to save a site or subsite. Although using the export operation saves data for you, it is not the same as using the backup operation. You cannot save a workflow, alerts, features, solutions, or Recycle-Bin state by using the export operation. If you want a full-fidelity backup, use the Stsadm backup operation to back up the site collection as described in Back up a farm by using the Stsadm command-line tool (Search Server 2008).

Before you perform this procedure, confirm that:

  • You have read the topic Plan for backup and recovery (Office SharePoint Server).

Important Important:

The account that you use must be a member of the Administrators group on the local server computer that is hosting the SharePoint Central Administration Web site and a member of the dbowner fixed database role in SQL Server to complete this procedure.

Archive SharePoint sites and content by using the Stsadm export operation

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. Type the following command, and then press ENTER:

    stsadm -o export -url<URL of the site you want to archive>-filename<Archive file name>-includeusersecurity -versions 4

    The includeusersecurity parameter ensures that the archived content or site will have the same permission requirements as the original. Setting the versions value at 4 ensures that all content regardless of version will be included in the archive. For more information, see Export: Stsadm operation (Office SharePoint Server).

    Note Note:

    If there are errors or warnings, or if the export does not complete successfully, see the export log file for the file that you specified in step 2.

Retrieve site content by using the Stsadm command-line tool

You can use the Stsadm import operation to insert an archived site into a different site collection or to move an entire site collection to a different database or Web application. Although using the import operation imports data, it is not the same as using the restore operation. You cannot restore workflow, alerts, features, solutions, or Recycle-Bin state by using the import operation. If you want a full-fidelity recovery, use the restore operation to import the entire the site collection as described in Restore a farm by using the Stsadm command-line tool (Search Server 2008).

Before you perform this procedure, confirm that:

  • You have read the topic Plan for backup and recovery (Office SharePoint Server).

Important Important:

If you export a site and then import that site to another location, the new site retains many of the settings used on the original site. As a result, breadcrumb navigation on the new site might not appear the way you want it to. The UseShared property can be set to False to retain the original breadcrumb links, or to True to adapt them from the parent site. For more information, see the Update UseShared property procedure in this article.

Important Important:

Memberships in the Administrators group on the local computer that is hosting the SharePoint Central Administration Web site and in the dbowner fixed database role in SQL Server are the minimum required to complete this procedure.

Import SharePoint sites and objects by using the Stsadm import operation

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. Type the following command, and then press ENTER:

    stsadm -o import -url<URL of the site you want to import to>-filename<file name of the archive file>-includeusersecurity

    The includeusersecurity option ensures that the imported content or site will have the same permission requirements as the original. For more information, see Import: Stsadm operation (Office SharePoint Server).

    Note Note:

    If there are errors or warnings, or if your import does not complete successfully, the system generates an error message that includes the path of the log file.

Update UseShared property

  1. On the imported site, click Site Actions, and then click Site Settings.

  2. On the Site Settings page, under Look and Feel, click Top link bar.

  3. To inherit the links from the parent site, click Use Links from Parent on the Top Link Bar page.

    -OR-

    To retain the original breadcrumb path, click Stop Inheriting Links on the Top Link Bar page.

  4. Click OK.

See Also

Concepts

Use alternative methods to back up and restore content (Search Server 2008)
Capture and restore content by using the Web site delete event (Search Server 2008)
Capture and restore content by using SharePoint Designer (Search Server 2008)
Archive site versions by using database snapshots (Search Server 2008)


Archive site versions by using database snapshots (Search Server 2008)
DropDown image

Updated: 2008-07-24

Draft content This article was published for an earlier version of this product and is being published without changes for this release.

A Microsoft SQL Server 2005 snapshot is a read-only view of a database as the database existed at the time that the snapshot was created. SQL Server 2005 snapshots are created by using differential copying. After the snapshot is created, the snapshot technology uses a copy-on-write scheme to ensure that the snapshot images are static views of the database.

You can use snapshot technology to create a read-only, point-in-time copy of a SharePoint Products and Technologies content database. You can associate a snapshot content database with a SharePoint site to enable users to retrieve content from a different point in time.

Snapshots can be used for reporting purposes. Also, in the event of a user error on a source database, you can revert the source database to the state it was in when the snapshot was created. Data loss is confined to updates to the database since the snapshot was created.

Note Note:

The snapshot version of the Web site does not have full functionality. For example, you cannot write to the snapshot version or upload a file to it.

For more information about using snapshots with SharePoint Products and Technologies, see the following article in the Microsoft Knowledge Base: How to use SQL Server to take a snapshot of a Windows SharePoint Services 3.0 content database (http://go.microsoft.com/fwlink/?LinkID=99636&clcid=0x409).

Task Requirements

The following is required to perform the procedures for this task:

  • It is recommended that you have a backup server running Microsoft Search Server 2008.

To create or attach database snapshots, you can perform the following procedures:

Important Important:

Memberships in the Administrators group on the computer that is running Microsoft SQL Server 2005 and in the dbowner fixed database role in SQL Server are required to complete the following procedure.

Create a database snapshot

  1. In SQL Server Management Studio, connect to the database server that contains the database you want to take a snapshot of.

  2. In the Object Explorer pane, expand the Databases list.

  3. Right-click the database you want to take a snapshot of, and then click New Query.

  4. Type the following text into the query pane, filling in the placeholder content with your specific data:

    CREATE DATABASE <database snapshot name>

    ON

    (

    NAME = <database name>,

    FILENAME = 'c:\<backup file name>.ss')

    AS SNAPSHOT OF<description of database content>;

  5. On the Query menu, click Execute to take a snapshot of the content database.

Important Important:

You must be a member of the Farm Administrators SharePoint group to complete the following procedure.

Attach and view a database snapshot

  1. On the backup server, on the SharePoint Central Administration Web site, click Application Management.

  2. On the Application Management page, in the SharePoint Web Application Management section, click Create or extend Web application.

  3. On the Create or Extend Web Application page, click Create a new Web application.

  4. On the Create New Web Application page:

    1. In the IIS Web Site section, ensure that the Create a new IIS web site option is selected. You can use the default description or type a new description.

    2. In the Security Configuration section, select an authentication provider, whether to allow anonymous authentication, and whether to use Secure Sockets Layer (SSL).

    3. In the Load Balanced URL section, you can use the default domain name or type a new domain name.

    4. In the Application Pool section, choose an application pool to host the new Web application.

    5. In the Reset Internet Information Services section, select Restart IIS Manually.

    6. In the Database Name and Authentication section, in the Database Server box, type the name of the production database server that contains the snapshot database you created.

    7. Click OK.

  5. To verify your snapshot, open the SharePoint site on the backup server to verify that the site displays the information that you backed up. Changes to your production server do not affect the database snapshot.

See Also

Concepts

Use alternative methods to back up and restore content (Search Server 2008)
Capture and restore content by using the Web site delete event (Search Server 2008)
Capture and restore content by using SharePoint Designer (Search Server 2008)
Archive and retrieve content by using Stsadm import and export operations (Search Server 2008)


Troubleshooting backup and recovery (Search Server 2008)
DropDown image

Updated: 2009-07-16

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Troubleshooting

Use the information in the following tables to troubleshoot problems that you encounter during backup or recovery.

Problems during backup

Problem Description

Unfinished backup package is formed.

Symptom: The backup starts but does not finish.

Cause: This could occur if the Windows SharePoint Services Timer service is restarted during the backup process.

Solution: Make sure that the Windows SharePoint Services Timer service is started, and then perform the backup operation again.

Backup operation is stalled.

Symptom: Status displays In Progress for a long time.

Cause: There are several possible causes.

Solution: Look in the Failure Message column on the Central Administration Web site to determine what action is required.

Backup fails.

Symptoms: The backup failed with the error "System.UnauthorizedAccessException".

Cause: The account performing the backup was not granted write permissions to the remote backup folder.

Solution: Grant write access to the account that runs the Stsadm command-line tool and that you use for the application pool identity.

Problems during recovery

Problem Description

Unable to perform a recovery because the farm account credentials have changed.

Symptom: You cannot perform a recovery, and the error message says "Cannot start service Windows SharePoint Services Timer V3 on computer."

Cause: The farm account credentials have changed since the backup was performed.

Solution: Create a new account that has a password that is identical to the old password for the farm account, and then run the recovery again. On a stand-alone installation, you can use a local account. On a farm installation, you must set up a domain account.

Unable to perform a recovery because the administration content database is corrupted or missing.

Symptoms: You cannot perform a recovery.

Cause: Account credentials are stored in the administration content database. That content database is corrupted or missing.

Solution: Add the account that you want to use to perform the recovery to the Administrators group or the WSS_ADMIN_WPG group on the local computer. After the account is added, you can use it to perform the recovery by using the Stsadm command-line tool.

Unable to perform the recovery because the first attempt failed and you cannot try again.

Symptom: The first cannot at backup or recovery failed, and now you are prevented from trying the operation again.

Cause: The previous timer job became corrupted.

Solution: Delete the previous failed timer job, and then try the operation again.

A host header associated with a Web application is not restored correctly.

Symptom: The Web application is restored without its host header binding.

Cause: This is a known bug.

Solution: First, create the Web application that has the host header binding. Then restore the content database only. Finally, attach the content database to the Web application by using the Stsadm addcontentdb operation. For more information, see Addcontentdb: Stsadm operation (Office SharePoint Server).

Recovery is stalled.

Symptom: Status displays In Progress for a long time.

Cause: There are several possible causes.

Solution: Look in the Failure Message column in Central Administration to determine the action needed.

Recovery fails.

Symptoms: The recovery status page displays the error "Failed in the OnRestore event."

Cause: An attempt to delete a content database by using the Central Administration Web site or the Stsadm command-line tool was not successful. The database still exists. Therefore, the recovery operation could not overwrite the existing database in SQL Server 2005.

Solution: Use a different database name or delete the previous content database by using SQL Server Management Studio, and then try the operation again.

Recovery with new configuration does not overwrite the previous configuration.

Symptoms: The recovery did not overwrite the previous configuration.

Cause: The databases are still attached to the old configuration.

Solution: To restore the backup to a new configuration, you must first remove the databases from the previous Web application. You can do this on the Manage Content Database Settings page on the Central Administration Web site.

Recovery fails in a topology that has multiple front-end Web servers.

Symptoms: Recovery fails with an "OnPostRestore" error in a topology that has multiple front-end Web servers.

Cause: The failure could be caused by any combination of the following:

  • You used the Central Administration Web site.

  • The farm account is not a member of the Administrators group on the local server computer.

  • You are restoring a Web application.

Solution: Do one of the following, and then try the recovery again:

  • Use the Stsadm command-line tool to perform the recovery.

  • Create a new Web application on the server that you are restoring to, and then restore the content databases to the newly created Web application.

  • Add the farm account to the Administrators group on the local server computer.

See Also

Concepts

Protecting and restoring the farm (Search Server 2008)
Protect and restore content by using Recycle Bins and versioning (Search Server 2008)
Back up and restore a farm (Search Server 2008)
Use alternative methods to back up and restore content (Search Server 2008)


Optimize performance (Search Server 2008)
DropDown image

Updated: 2009-07-30

This section provides information about optimizing performance in a Microsoft Search Server 2008 farm.

In this section:

  • Best practices for search performance (Search Server 2008)

    This article describes some best practices that you can use to maintain a healthy and efficient search system in Microsoft Search Server 2008.

  • Change the Indexer Performance setting (Search Server 2008)

    This article discusses considerations regarding the indexer performance setting and explains how to change the current setting.

  • Manage crawler impact (Search Server 2008)

    This article describes how to use crawler impact rules to specify how aggressively the crawler should perform.


Best practices for search performance (Search Server 2008)
CollapseAll image DropDown image

Updated: 2009-07-30

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This article describes some best practices that you can use to maintain a healthy and efficient search system in Microsoft Search Server 2008.

In this article:

  • Reasons for initiating a full crawl

  • Monitoring Web servers

  • Monitoring database servers

  • Monitoring index servers

  • Monitoring Search Server with SharePoint Diagnostics

  • Using Unified Logging Service logs to diagnose query bottlenecks

  • Optimizing SQL Server for Search Server 2008

  • Maintaining SQL Server databases for search

  • Avoiding Crawler Starvation

  • Avoiding bottlenecks caused by Access Control Lists

  • Troubleshooting missing Search Box Web Parts

Expand image Reasons for initiating a full crawl

Crawling and indexing a large volume of information, documents, and Web pages requires a large amount of computer processing. The crawl process also consumes network and other resources. You must configure a Search Server 2008 farm carefully, to ensure that the crawling and indexing process does not adversely affect the service available to users. For example, content is usually crawled and indexed during off-peak hours—when servers are underused—in order to maintain peak-hour services for users.

One way to reduce the impact of crawling is to schedule incremental crawls instead of full crawls. An incremental crawl indexes only items that have changed, so that the process requires far fewer computer resources. You can schedule full crawls and incremental crawls on each content source. For example, you can consider running incremental crawls at midnight on weekdays and full crawls at midnight on Saturdays.

Note Note:

For more information about how to plan crawl schedules, see Plan to crawl content (Search Server 2008).

To ensure that the index is complete, you should manually start a full crawl under the following circumstances:

  • When administrators have applied an update or service pack to the servers in the farm.

  • When administrators have added a new managed property to the search configuration.

  • When administrators have added or modified a crawl rule.

  • When you want to re-index ASP.NET pages on Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007, or Search Server 2008 sites. The crawler cannot detect when such Web pages have changed. Therefore, only a full crawl re-indexes them.

  • When there have been consecutive incremental crawl failures. If incremental crawl fails 100 times consecutively at any level in the repository, the index server removes the affected content from the index.

  • When administrators have repaired a corrupted index.

  • When administrators have created a server name mapping.

  • When you have altered permissions for some content but the content itself has not changed and you do not have the Post-Service Pack 1 hotfix package (KB941442) or a later service pack applied on the servers. Without this hotfix package, incremental crawls do not check Access Control Lists (ACLs). If ACLs are not checked, a user may see an item in the search results even if an administrator has removed permission for that user since the last full crawl.

Under the following circumstances Search Server 2008 performs a full crawl when an incremental crawl was scheduled or manually initiated:

  • When an SSP administrator manually stopped the previous crawl.

  • When an administrator restored a content database from a backup.

    Note Note:

    You can specify whether a restore operation causes a full crawl by using options on the stsadm.exe tool.

  • When a farm administrator has detached and reattached a content database.

  • When Search Server has never run a full crawl on the content.

  • When the change log contains no information for the addresses in the crawl. The change log is used to determine whether an item has changed since the last crawl. Without change log information, incremental crawls cannot occur.

  • When the user account that is used to access content has changed. This user account can be the default content access account or one specified in a crawl rule.

  • When an index corruption has occurred.

You must carefully consider your actions in these circumstances because if you start a crawl manually or with a schedule, the full crawl may require many more resources than the incremental crawl would have required. This could affect the service users receive.

Expand image Monitoring Web servers

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

To maximize Search Server 2008 search performance, you must thoroughly analyze the system. You should create a base line by making a thorough investigation of the servers. You should periodically re-run performance tests to observe any changes and diagnose problems early. When you make an optimization, you can use the base line to characterize the improvements that result. The following sections list performance monitor counters, and data available from other tools, that are relevant to the performance of Search Server 2008.

Note Note:

For more information about general system monitoring, see Monitoring Performance (http://go.microsoft.com/fwlink/?LinkID=105584&clcid=0x409).

In Search Server 2008, Web servers send responses to user search queries. Therefore, Web server performance has a direct effect on search performance. Web servers also affect indexing. This is because the crawler indexes content by sending requests to Web servers.

To monitor the health of Web servers, use the following Performance Monitor counters:

  • Processor/% Processor Time/_Total

    This counter is the primary indicator of processor activity. It measures the proportion of time that the processors spend executing non-idle threads. If this counter averages above 80% over prolonged periods, the processors may be a bottleneck and you should consider an upgrade.

  • Memory/Available Mbytes

    This counter measures the physical memory immediately available to processes or to the system. If this counter drops too low, the system will slow down as it uses more paging. You should consider adding more memory to the server.

  • Web Service/Current Connections

    This counter measures the number of connections to the World Wide Web service. On Search Server 2008 servers, this count includes all the concurrent users and, during indexing, the crawler. Use this counter to profile usage patterns and determine peak hours. There is no limit for this counter; very high values may indicate excellent performance.

    Note Note:

    In a Search Server farm with multiple Web servers, this counter measures connections on only one server. For information about how to monitor user activity across the whole farm, see Monitoring Search Server with SharePoint Diagnostics.

Expand image Monitoring database servers

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

Search Server 2008 uses Microsoft SQL Server 2005 or Microsoft SQL Server 2008 to store content databases. Although the index server stores the content index on the file system—not in a database—it stores document metadata and permissions in the search database. Because many searches check metadata and all searches involve security trimming, the performance of database servers directly affects the performance of search.

To monitor the health of database servers, use the following Performance Monitor counters:

  • Processor/% Processor Time/_Total

    This counter is the primary indicator of processor activity, and therefore is as important on database servers as it is on Web servers.

  • LogicalDisk/% Disk Time/ DiskName

    This counter measures the proportion of elapsed time that the disk spent servicing read or write requests. Monitor this counter for the disk that holds the search database. If this counter frequently averages larger than 90%, the disk may represent a bottleneck for search.

  • System: Processor Queue Length

    This counter should average less than two multiplied by the number of CPU cores on the server.

  • Memory: Available Mbytes

    Ensure that this counter averages at least 20 percent of the total physical RAM.

  • Memory: Pages/sec

    This counter should average under 100.

  • Logical Disk: Disk Transfers/sec

    This counter measures the overall throughput for a partition.

  • Logical Disk: Disk Read Bytes/sec & Disk Write Bytes/sec

    This counter measures the total bandwidth of a particular disk.

  • Logical Disk: Average Disk sec/Read

    Also known as read latency, this counter indicates the time that is required for the disk to retrieve data. Low read latency is important for good responsiveness to user queries.

  • Logical Disk: Average Disk sec/Write

    Also known as write latency, this counter indicates the time that is required for the disk to write the data. Low write latency improves the performance of indexing.

  • LogicalDisk/% Disk Read Time/ DiskName

    This counter measures the proportion of elapsed time that the disk spent servicing read requests. A large proportion of read requests for the search database disk may indicate that users are running a large number searches.

  • LogicalDisk/% Disk Write Time/ DiskName

    This counter measures the proportion of elapsed time that the disk spent servicing write requests. A large proportion of write requests for the search database is expected during the indexing process.

    Note Note:

    When possible, optimize search performance by placing the search database on a separate disk from other databases. If the search database is separated in this manner, these Logical Disk counters are highly diagnostic of search performance because the disk is dedicated to search.

  • SQLServer:Buffer Manager/Page life expectancy

    This counter measures the number of seconds a database page remains in the buffer pool without references. It should remain above 300 seconds. Values lower than 300 seconds are highly diagnostic of a memory bottleneck and should lead you to consider adding memory to the server.

Note Note:

A full description of general SQL Server optimization is beyond the scope of this Search Server 2008 article. For more information, see the following resources:

  • Storage Top 10 Best Practices (http://go.microsoft.com/fwlink/?LinkID=148543&clcid=0x409)

  • SQL Server Predeployment I/O Best Practices (http://go.microsoft.com/fwlink/?LinkID=148544&clcid=0x409)

  • RAID Levels and SQL Server (http://go.microsoft.com/fwlink/?LinkID=105581&clcid=0x409)

  • For more information about Microsoft SQL Server Performance Monitor counters and SharePoint Products and Technologies, see Planning and Monitoring SQL Server Storage for Office SharePoint Server: Performance Recommendations and Best Practices (white paper) (http://go.microsoft.com/fwlink/?LinkID=119398&clcid=0x409).

Expand image Monitoring index servers

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

In Search Server 2008, index servers crawl content and create an index file. When the crawl process is complete, the index is propagated to query servers that respond to search requests from users.

If the index server performs poorly, there may be no direct effect on users. However, the crawl process is lengthened, sometimes to the extent that you cannot limit crawling to off-peak hours and to separate crawling from other off-peak activities such as backup.

Note Note:

The index server may not always be put on a separate server, depending on the number of available servers.

To monitor the health of the index server, use the following Performance Monitor counters during a crawl:

  • Office Server Search Archival Plugin/Total Docs in first queue/Portal_Content

    This counter measures the number of documents in the first queue of the archival plug-in. This should be less than 500 during a crawl, and very low at other times. If the counter is above 500, the search database drive on the database server is probably a bottleneck.

  • Office Server Search Archival Plugin/Total Docs in second queue/Portal_Content

    This counter measures the number of documents in the second queue of the archival plug-in. As with the previous counter, it should be less than 500 during a crawl.

  • Office Server Search Gatherer/Idle Threads

    This counter measures the number of threads in the gatherer process waiting for documents. If this counter is 0, the gatherer is starved for resources. Consider reducing the number of concurrent crawls.

  • Office Server Search Gatherer/Threads Accessing Network

    This counter measures the number of threads in the gatherer process that have sent requests to a remote data store and are either waiting for or processing the response. If this counter is consistently high, network bandwidth may be a bottleneck or the index server may be connected to one or more slow hosts to index content.

  • Office Server Search Gatherer/Filtering Threads

    This counter measures the number of threads that have retrieved content and are filtering it. If this number is high, it may indicate that resources on the index server are acting as a bottleneck.

  • Office Server Search Gatherer/Threads In Plug-Ins

    This counter measures the number of threads that have retrieved content and are processing it through plug-ins such as IFilters. This is the stage in the crawl process when the index and the search database are populated.

  • Office Server Search Gatherer Projects/Crawls in progress

    This counter measures the number of crawls in progress. This value should match the number of content sources with crawls scheduled, unless an administrator has manually initiated a crawl.

Expand image Monitoring Search Server with SharePoint Diagnostics

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

The SharePoint Diagnostics tool v1.0 (also known as SPDiag) is an advanced diagnosis and analysis tool that presents a very large range of information about any server or farm that runs SharePoint Products and Technologies. You can use SPDiag to view highly detailed snapshots of the server and farm configurations. You can also merge and view information from Internet Information Services (IIS), Unified Logging Service (ULS) logs, and Event logs, and investigate performance issues such as slow requests.

Note Note:

SPDiag is part of the Microsoft SharePoint Administration Toolkit v3.0 (http://go.microsoft.com/fwlink/?LinkId=141504).

SPDiag can present graphs of performance counters from any server on the farm. However, it also includes several counters that measure farm-wide data based on IIS logs. Such a farm-wide analysis is not possible with Performance Monitor alone.

Note Note:

To use SPDiag effectively, you must read the SharePoint Diagnostics Tool (SPDiag) User Guide (http://go.microsoft.com/fwlink/?LinkId=141204).

Use the following farm-wide counters to investigate the responsiveness of the Search Server 2008 farm:

  • SharePointRequests/Number of unique client IP

    This counter measures the number of unique clients that have made requests over the specified time period. Note that clients that access the farm through a proxy server appear as a single IP address.

  • SharePointRequests/Number of unique client agents

    This counter measures the number of unique client agents—browsers—that have made requests over the specified time period. This counter can differentiate among clients that access the farm through a proxy server because it is based on the agent specified in the browsers' HTTP requests.

    Note Note:

    The following counters measure numbers of requests. These requests include both search queries and requests for content.

  • SharePointRequests/Total requests

    This counter measures the total number of requests as it varies over the specified time period. You should always monitor this counter together with the following counters to determine the proportion of fast and slow requests.

  • SharePointRequests/Number of requests with time taken < 1 second

    This counter measures the number of requests satisfied within 1 second. In a farm that is performing well, this counter approaches the Total requests counter.

  • SharePointRequests/Number of requests with time taken 1-5 seconds

    This counter measures the number of requests satisfied within 1 to 5 seconds. Such performance is usually acceptable to users, but an increasing proportion of these requests over time may indicate that a bottleneck is developing.

  • SharePointRequests/Number of requests with time taken 5-10 seconds

    This counter measures the number of requests satisfied within 5 to 10 seconds. Users may click away from a page before results are returned.

  • SharePointRequests/Number of requests with time taken > 10 seconds

    This counter measures the number of requests satisfied in more than 10 seconds. If these requests are a significant proportion of the Total requests, the farm is unresponsive and you should investigate bottlenecks and consider upgrading hardware.

Expand image Using Unified Logging Service logs to diagnose query bottlenecks

You can use the Universal Logging Service (ULS) to monitor and optimize the performance of the Search Server 2008 system. You should use the ULS as one method of optimizing the system. Other methods include using the Performance Monitor, Event Logs, and Web logs.

In this section, you will see how to use ULS logs to diagnose delays in the performance of searches. In ULS logs you can diagnose which stages of the search process consume the most time and delay the return of results to the user. You should also use ULS logs to assess the performance improvements made by small changes to the configuration of the system.

Note Note:

Use ULS logging sparingly in order to avoid any effect on performance and use of disk space. After diagnosing performance issues with ULS, you can maximize performance by disabling ULS logging. Take care to store the ULS logs on a disk that has lots of space.

Note Note:

For more information and additional examples of queries to use in Log Parser 2.2, see How to: Mine the ULS logs for query latency (http://go.microsoft.com/fwlink/?LinkId=148540) in the Microsoft Enterprise Search Blog.

Configuring the Unified Logging Service

Start by configuring the ULS in the Search Server 2008 Central Administration Web site.

Important Important:

Membership in the Farm Administrators group is required to complete the following procedure.

To Configure the Unified Logging Service for diagnosing search performance issues

  1. Click Start, click All Programs, click Microsoft Search Server, and then click SharePoint 3.0 Central Administration.

  2. Click the Operations tab.

  3. In the Logging and Reporting section, click Diagnostic logging.

  4. In the Event Throttling section, in the Select a category list, click MS Search Query Processor.

  5. In the Least critical event to report to the trace log, click High.

  6. At the bottom of the page, click OK.

Using the Log Parser tool

Like Internet Information Services (IIS) logs, Search Server 2008 ULS logs are very large text files. To analyze the content of such files, use a log parsing utility to focus on interesting traces and to format the data. The Microsoft Log Parser 2.2 (http://go.microsoft.com/fwlink/?LinkId=148542) tool is free and is ideal for this purpose.

The Log Parser tool is a command-line program. You must use the following parameters to indicate that the ULS logs are Unicode, tab-separated text files:

logparser -i:TSV -iCodepage:-1 -fixedSep:ON

In addition to these parameters, you must provide a Transact-SQL-style query that tells Log Parser how to parse the log file. For example, to focus on query processor timer messages, use the following WHERE clause:

WHERE Category = 'MS Search Query Processor' AND Message LIKE '%Completed query execution with timings:%'

Note Note:

You can type SQL query text directly at the Log Parser command prompt. Alternatively, you can save the query in a text file and use the file: parameter to pass its location to Log Parser. This is helpful for longer or more complex queries and for queries that you expect to use often.

Search messages in the ULS logs

When the ULS is configured as described earlier, the following messages will appear in the log files as users run queries:

  • Completed query execution with timings

    This message indicates that a query has completed and includes six timings that describe the query in milliseconds. The six timings are as follows:

    • v1. The total time that is spent processing the query.

    • v2. The latency of the query measured after duplicate detection.

    • v3. The latency of the query measured after security trimming.

    • v4. The latency of the query measured after joining results from the index with results from the search database.

    • v5. The time that is spent waiting for results from the index server.

    • v6. The time that is spent in calls to the database, excluding fetching properties from the search database.

    From these six timings you can calculate the following information:

    • v1 - v2. The time that is spent retrieving properties and highlighting hits.

    • v2 - v3. The time that is spent detecting duplicates.

    • v3 - v4. The time that is spent in security trimming.

    • v4 - v5. The time that is spent joining index results with search database results.

  • Join retry

    This message indicates that a retry occurred because the results returned from the search database did not match the results returned from the full-text index so they could not be joined.

  • Security Trimming retry

    This message indicates that a user executed a query that returned results the user is not authorized to read. Such a query is retried, with a larger number of results requested, until enough results are returned.

  • Near duplicate removal retry

    This message indicates that many virtually identical documents were trimmed out of the results and query processor did not have enough results to display. Such a query is retried, with a larger number of results requested, until enough results are returned.

Analyzing query timings

Of the messages described earlier in this section, the Completed query execution with timings message is of most use when diagnosing delays in query processing. For example, if security trimming is slow, the v3 - v4 calculation will be a large proportion of the total processing time v1.

To analyze timings, pass the following SQL query to the Log Parser tool. The tool will create a comma separated file that includes the v1 to v6 timings and their differences.

CopyCode image Copy Code
Select  Timestamp,
TO_INT(Extract_token(Message,7, ' ')) as TotalQPTime,
      TO_INT(Extract_token(Message,8, ' ')) as v2,
      TO_INT(Extract_token(Message,9, ' ')) as v3,
      TO_INT(Extract_token(Message,10, ' ')) as v4,
      TO_INT(Extract_token(Message,11, ' ')) as TimeSpentInIndex,
      TO_INT(Extract_token(Message,12, ' ')) as v6,
      SUB(v4, TimeSpentInIndex) as JoinTime,
      SUB(v3, v4) as SecurityTrimmingTime,
      CASE v2
           WHEN 0 THEN 0
           ELSE SUB(v2, v3)
      End as DuplicateDetectionTime,
      SUB(TotalQPTime, v2) as FetchTime
INTO QTiming
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Completed query execution with timings:%'

You can import the resulting CSV file into Microsoft Office Excel or another analysis tool to create graphs and reports. Consider that in a busy system many queries take place. Therefore, you may have to take averages over many results to generate a meaningful analysis.

Analyzing Retries

The timing data available in the Completed query execution with timings message does not include any information about retries—for example, retries caused by security trimming. To analyze how much time the query processor spends on retries, you must compare the total number of queries with the number of retries of different types.

The following query counts the total number of queries executed:

CopyCode image Copy Code
SELECT count (Message)
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Completed query execution%'

The following query counts the total number of retries caused by security trimming:

CopyCode image Copy Code
SELECT count (Message)
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Security trimming retry%'

The following query counts the total number of retries caused by duplicate result removal:

CopyCode image Copy Code
SELECT count (Message)
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Near duplicate removal retry%'

Use these queries to diagnose how retries delay query results. When the number of retries is a significant proportion of the total number of queries, you should consider revising the configuration. For example, if only a few users can access the documents in one of the content sources, this may increase the number of security trimming retries. Consider removing this content source from the index.

Expand image Optimizing SQL Server for Search Server 2008

Microsoft Search Server 2008 uses Microsoft SQL Server to store content, configuration information, and properties of indexed content. You must optimize SQL Server in order to ensure optimal performance from Search Server 2008.

Note Note:

Search Server 2008 can use databases stored in SQL Server 2008 or SQL Server 2005.

General SQL Server optimization

Note Note:

The information in this section does not apply to Microsoft Search Server 2008 Express. It applies to the full version of Microsoft Search Server 2008 only.

Some optimizations improve the performance of SQL Server regardless of the server's purpose. You should ensure that these optimizations are in place for a Search Server 2008 database.

When you plan and deploy the database server, consider the following recommendations:

  • Where possible, run SQL Server on a dedicated server or server farm.

  • Scale out to multiple database servers in a server farm. Generally, you should install a database server for every four Web servers that are running at capacity.

  • Use a 64-bit version of SQL Server on computers together with 64-bit operating systems.

  • Use as many physical disk spindles as the hardware budget allows for.

  • Use high-speed disks.

  • Place databases on RAID 1+0 or RAID 1 disk arrays.

  • Separate log files onto a physical disk that does not store the primary and secondary data files.

Note Note:

A full description of general SQL Server optimization is beyond the scope of this Search Server 2008 article. For more information, see the following resources:

  • Storage Top 10 Best Practices (http://go.microsoft.com/fwlink/?LinkId=148543)

  • SQL Server Best Practices (http://go.microsoft.com/fwlink/?LinkId=148544)

  • RAID Levels and SQL Server (http://go.microsoft.com/fwlink/?LinkID=105581&clcid=0x409)

Optimizing SQL Server for search queries and indexing

A high priority for Search Server 2008 administrators is optimization of crawling, indexing, and queries. The Search Server content index is stored on the file system outside any SQL Server database. However, the search database stores metadata from indexed files and ACLs. As a result, the performance of SQL Server directly affects two search operations:

  • Indexing, when Search Server stores metadata and ACLs.

  • Querying. All Search Server queries involve security trimming, during which Search Server checks the ACLs in the search database and removes results that the user is not permitted to view. In addition, if the user has performed a property search, metadata must be retrieved from the search database.

You should start by following the general SQL Server optimization recommendations given earlier in this article. However, the following optimizations specifically benefit indexing and querying.

Optimize the performance of the tempdb database.

Every user query involves activity in the SQL Server tempdb database. Therefore, the configuration of this database directly affects how quickly query responses are displayed to users.

Take the following steps to optimize tempdb:

  • Set the recovery model to SIMPLE.

  • Allow tempdb files to automatically grow as required.

  • Set the file growth increment to a reasonable value. As a rule, this increment should be approximately 10 percent of the tempdb file size.

  • Pre-allocate space for tempdb files by setting the file size to a value that can accommodate all activity during crawls and queries.

  • Use multiple data files to maximize disk bandwidth. As a rule, use one data file for each CPU core on the computer that is running SQL Server.

  • Make each data file the same size.

  • Put the tempdb database on a separate physical disk from those that store the content databases, configuration database, and search database.

Note Note:

For more information about tempdb optimization, see Optimizing tempdb Performance (http://go.microsoft.com/fwlink/?LinkId=148537).

Use filegroups to improve performance.

The Search Server 2008 crawling and indexing process is I/O intensive and writes a large volume of data to the search database. If the system experiences pronounced off-peak hours, you should schedule indexing to run during those times to ensure that indexing does not compete for resources with user queries. However, in some organizations with global or 24 hour activity, there are no significant drops in demand. If the database server that hosts the search database is close to it I/O capacity, you should consider other ways to separate indexing I/O operations from those associated with user queries.

The search database can be divided into tables that are involved in indexing and tables that are primarily involved in user queries. If you separate these groups of tables onto two physical disks, you ensure that indexing has a minimal effect on query performance. Although the indexing and query tables are in a single database, you can use the Microsoft SQL Server filegroups feature to achieve this separation.

To do this, you create a user filegroup with a secondary data file in it. This data file must be on a dedicated physical disk to achieve a performance improvement. Then move the tables involved in indexing into that filegroup using the following procedure. This procedure can take a significant time, depending on the size of the search database. You should complete the procedure when demand is low.

Note Note:

For more information about how to use filegroups for the search database, including Transact-SQL scripts to move tables, see SQL File groups and Search (http://go.microsoft.com/fwlink/?LinkId=132066&clcid=0x409).

To separate indexing tables into a dedicated filegroup

  1. In SQL Server Management Studio, right-click the search database and then click Properties.

  2. In the Select a page list, click Filegroups.

  3. Click Add and name the new filegroup "CrawlFileGroup".

  4. In the Select a page list, click Files.

  5. Click Add, and then name the new file.

  6. In the Filegroup cell, select CrawlFileGroup.

  7. In the Path cell, select a path on a separate physical disk from the PRIMARY filegroup.

  8. Click OK.

  9. In SQL Server Management Studio, click New Query.

  10. Copy the following query into the query window, and then click Execute. This Transact-SQL code creates a new stored procedure that moves tables into the new filegroup.

    CopyCode image Copy Code
    IF EXISTS (SELECT * FROM sysobjects WHERE type = 'P' AND name = 'proc_MoveTableToFileGroup')
   BEGIN
      DROP  Procedure  dbo.proc_MoveTableToFileGroup
   END
GO
CREATE PROCEDURE [dbo].[proc_MoveTableToFileGroup]
(
   @fileGroup sysname,
   @tableName sysname
)
as
begin
   declare @data_space_id int
   declare @object_id int
   declare @index_id int
   declare @index_name sysname
   declare @object_name sysname
   declare @fileGroupName sysname
   declare @index_cols nvarchar(4000)
   declare @sql nvarchar(4000)
   declare @key_ordinal int
   set @index_id = 0
   set @key_ordinal = 0
   select @data_space_id = data_space_id, @fileGroupName = name from sys.filegroups where name = @fileGroup
   if @data_space_id is null
   begin
      raiserror ('The specified filegroup does not exist.', 16, 1)
      return
   end
   while 1=1
   begin
      select top 1
            @object_id = i.object_id,
            @index_id = i.index_id,
            @index_name = i.name,
            @object_name = o.name
         from
            sys.indexes AS i
         inner join
            sys.objects AS o
         ON
            i.object_id = o.object_id
         where
            i.index_id > 0 and
            o.type = 'U' and
            o.name = @tableName and
            i.index_id > @index_id and
            i.data_space_id <> @data_space_id
         order by i.index_id
      if @@rowcount = 0
      begin
         if @index_id = 0
            print 'There are no indexes to move to filegroup ' + @fileGroupName + ' for table ' + @tableName
         break
      end
      set @index_cols = null
      set @key_ordinal = 0
      while 1=1
      begin
         select top 1
            @index_cols = case when @index_cols is null then '[' + c.name + ']' else @index_cols + ', [' + c.name + ']' end +
            case when i.is_descending_key = 0 then ' asc' else 'desc' end,
            @key_ordinal = i.key_ordinal
         from
            sys.index_columns i
         inner join
            sys.columns as c
         on
            i.object_id = c.object_id and
            i.column_id = c.column_id
         where
            i.object_id = @object_id and
            i.index_id = @index_id and
            i.key_ordinal > @key_ordinal
         order by i.key_ordinal
         if @@rowcount = 0
            break
      end
      select @sql =
         case when i.is_primary_key = 1 then
            N'begin try ' +
            N'begin tran ' +
            N'alter table [' + @object_name + '] drop constraint [' + i.name + '] ' +
            N'alter table [' + @object_name + '] add constraint [' + i.name + '] ' +
            'primary key ' +
            case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
            ' (' + @index_cols + ') ' +
            'with (' +
            'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
            ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
            case when  i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end +
            ') ' +
            'ON [' + @fileGroupName + ']' +
            N' commit ' +
            N'end try ' +
            N'begin catch ' +
            N'rollback ' +
            N'end catch '
         else
            N'create ' +
            case when  i.is_unique = 1 then 'unique ' else '' end +
            case when  i.type = 1 then 'clustered ' else 'nonclustered ' end +
            'index [' + i.name + '] on [' + @object_name + '] (' + @index_cols + ') ' +
            'with (' +
            'IGNORE_DUP_KEY = ' + case when  i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end +
            ', PAD_INDEX = ' + case when  i.is_padded = 1 then 'ON ' else 'OFF ' end +
            case when i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + ', DROP_EXISTING = ON ) ' +
            'ON [' + @fileGroupName + ']'
         end
from
         sys.indexes AS i
      where
         i.object_id = @object_id and
         i.index_id = @index_id
      print 'Moving index ' + @index_name + ' to filegroup ' + @fileGroupName
      print @sql
      print ''
      exec sp_executesql @sql
   end
end

  11. In SQL Server Management Studio, click New Query.

  12. Copy the following query into the query window, and then click Execute. This Transact-SQL code executes the new stored procedure for each indexing table.

    CopyCode image Copy Code
    declare @fileGroup sysname
set @fileGroup = 'CrawlFileGroup'
if not exists (select 1 from sys.filegroups where name = @fileGroup)
begin
   raiserror ('The specified filegroup does not exist.', 16, 1)
   return
end
exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorChangeLog'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorPendingChangeLog'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorText'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorTransactions'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedSourceDocs'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedTargetDocs'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlContent'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedErrorList'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedURL'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlErrorList'
begin try
   begin tran
   IF  EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_MSSCrawlContent_MSSCrawlHistory]') AND parent_object_id = OBJECT_ID(N'[dbo].[MSSCrawlContent]'))
   ALTER TABLE [dbo].[MSSCrawlContent] DROP CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory]
   exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHistory'
   ALTER TABLE [dbo].[MSSCrawlContent]  WITH CHECK ADD  CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory] FOREIGN KEY([CrawlID])
   REFERENCES [dbo].[MSSCrawlHistory] ([CrawlID])
   commit
end try
begin catch
   rollback
end catch
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHostList'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlQueue'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURL'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURLLog'
exec proc_MoveTableToFileGroup @fileGroup, 'MSSTranTempTable0'

Expand image Maintaining SQL Server databases for search

Like any complex system, SQL Server databases require regular maintenance to keep performance at the highest level. In this section, you will see some recommended practices to maintain maximum performance.

The following disk maintenance procedures may increase the performance of the database servers:

  • Maintain at least 25 percent free disk space to allow for databases to grow. Monitor disk size and free space regularly to avoid a drop in this percentage. The search database may increase in size significantly and very quickly if administrators add new content sources.

  • If the disk controller uses Disk Write Cache, make sure that it has a backup battery so that a power failure will not result in an interruption in service.

The following SQL Server maintenance procedures may improve the performance of the database servers:

  • Run the DBCC CHECKDB Transact-SQL routine regularly on all databases. However, this routine places a significant load on the computer that is running SQL Server and may affect responsiveness. Therefore, use the PHYSICAL_ONLY option and schedule DBCC CHECKDB for off-peak hours. Do not run this routine during a crawl.

  • Avoid performing any unsupported operations on the production computers that are running SQL Server. For example, do not change the database collation or add columns to any Search Server database table. For more information about unsupported operations, see Microsoft Knowledge Base article 841057: Support for changes to the databases that are used by Office server products and by Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkID=105589&clcid=0x409).

Over time, fragmentation in the SQL Server indexes that support the search database can affect indexing and query performance. The Microsoft Knowledge Base article KB943345 includes a Transact-SQL script that creates a stored procedure called proc_DefragmentIndices. You can use proc_DefragmentIndices to defragment both the search and content databases in the Search Server farm. However, this stored procedure is very expensive as measured by server resources. Therefore, you must use it with great care to avoid a drop in query responsiveness.

Note Note:

For the proc_DefragmentIndices script and more information about its use, see How to defragment Windows SharePoint Services 3.0 databases and SharePoint Server 2007 databases (http://go.microsoft.com/fwlink/?LinkID=105588&clcid=0x409).

In addition, a defragmentation stored procedure called proc_DefragSearchIndexes that is designed specifically for the Search Server search database is available. It defragments only those indexes that provide the maximum performance benefit, such as IX_MSSDocProps and IX_MSSDocSdids. This minimizes the demand on database server resources. You should schedule the stored procedure to run at off-peak times and carefully monitor the effect on users.

Note Note:

For the proc_DefragSearchIndexes script and more information about its use, see the following entry in the Microsoft Enterprise Search Blog: SQL Index defrag and maintenance tasks for Search (http://go.microsoft.com/fwlink/?LinkID=158799&clcid=0x409).

If you diagnose a disk or RAID bottleneck on a database server in the farm, the following actions may reduce the effect of the problem:

  • Relocate data files and transaction logs to separate disks or RAID arrays. As described earlier in this article, the use of filegroups maximizes performance.

  • Add disks to the RAID array, if you have one.

  • Replace slower disks with faster disks.

Expand image Avoiding crawler starvation

In a large or complex organization, there are significant challenges to overcome when you configure the Search Server 2008 indexing system. You may have many content sources of many kinds with a very large corpus of content that takes a long time to crawl. You should also have carefully planned targets for the freshness of entries in the index to ensure that search results reflect up-to-date content. If you are to achieve your freshness targets, you must optimize the performance of the indexer so that it can crawl all content regularly.

A major obstacle to the speed of indexing is starvation in the crawler. The crawler is in a starved state when it cannot allocate another thread to retrieve the next document in the queue. Starvation can have the following causes:

  • Contention for resources on the database server that hosts the search database

  • Too many hosts participating in the crawl

  • Hosts that do not quickly relinquish a thread. In this article these are known as "hungry" hosts.

  • Backups running concurrently with the crawl

Hungry hosts lock a thread and prevent it from moving to the next document. This lock can occur in the following circumstances:

  • When the host is slow because it lacks CPU, memory, or other resources.

  • When the host requires extra work for incremental crawls. For example, if the source is a Microsoft SharePoint Portal Server 2003 server, the crawler must re-process a complete document if the permissions have changed.

  • Hosts or documents that are rich in properties. When there are many properties for each document, the database server that hosts the search database must work harder. Business Data Catalog content sources and My Sites are typically rich in properties.

The most efficient crawls usually occur with the following kinds of host:

  • Office SharePoint Server 2007 servers. These servers maintain a log of changes that the crawler can use.

  • File shares. The crawler can check for changes at the folder level and does not examine each document.

  • Exchange public folders. The crawler can check for changes at the folder level and does not examine each post.

Guidelines to avoid starvation

You can minimize crawler starvation by using the following best practices:

  • Minimize the number of content sources. It increases efficiency to group hosts of similar size and type into single content sources.

  • Crawl large Office SharePoint Server 2007 hosts first before you add other host types. These hosts are very efficient to crawl and incremental crawls release threads very quickly.

  • Do not schedule crawls for more than one hungry host simultaneously.

  • As a starting point, schedule four concurrent crawls. You may be able to increase this number for some index servers. See the next section for more information.

  • If the crawler becomes starved, pause the crawl for hungry hosts to free threads.

How to diagnose starvation

When you install a new Search Server 2008 search system, build up the crawler configuration by adding new content sources over several days or weeks. Monitor the performance of the system as you add each content source to avoid starvation and ease troubleshooting. In this way, gain a thorough understanding of the system's behavior during crawls.

The number of threads that the crawler uses is determined by the Indexer Performance setting. To change this setting, in Central Administration, click the Operations tab, click Services on Server, and then click Office SharePoint Server Search. The following table shows how the Indexer Performance setting controls crawl threads.

Indexer Performance setting | Total number of threads | Maximum threads for each host
Reduced | Number of processors | Number of processors
Partially reduced | 4 times the number of processors | Number of processors plus 4
Maximum | 16 times the number of processors | Number of processors plus 4

In Search Server 2008, the number of crawl threads never exceeds 64.

The most common cause of starvation is contention for resources on the database server. You can diagnose this by monitoring the Archival Plugin. In Performance Monitor, use the Office Server Search Archival Plugin object and the Total docs in first queue and Total docs in second queue counters. If these counters are both at 500 for the Portal_Content instance or 50 for the ProfileImport instance, the crawler is starved. Consider tuning the database server as described in Optimizing SQL Server for Search Server 2008 earlier in this article.

States of starvation that are not caused by the Archival Plugin can be diagnosed with the Office Server Search Gatherer object in Performance Monitor. Concentrate on the Idle Threads, Threads Accessing Network, and Threads In Plug-ins counters and compare them with the total number of threads for the system. For full descriptions of these counters, see Monitoring index servers earlier in this article.

Expand image Avoiding bottlenecks caused by Access Control Lists

When Search Server 2008 crawls and indexes a content source, it checks Access Control Lists (ACLs) and stores them in the search database. When users search the index, the search database is checked for each result to ensure that the user is authorized to access that result. This process is known as security trimming. Large ACLs with many levels of nesting can adversely affect the performance of both the crawl process and searches within Search Server. This section describes how to minimize such performance degradation.

Active Directory provides the following kinds of security principals that you can use to help secure Search Server sites and indexed content:

  • User accounts

  • Global groups

  • Domain local groups

  • Universal groups

In Search Server, you also have SharePoint groups. This system is very flexible and can include multiple layers of nesting. However, if you use them carelessly, security principals can adversely affect search performance.

To ensure maximum performance from the Search Server crawler and searches, observe the following rules when you are using Active Directory security principals and SharePoint groups:

  • Place user accounts into global groups, and global groups into domain local groups. Assign permissions to domain local groups. This is the recommended best practice for using security principals in Active Directory. It ensures that domain controllers can look up group memberships quickly and that users can access resources throughout the forest.

  • If Universal Groups are necessary, use the same system but put global groups into universal groups and universal groups into domain local groups.

  • Place domain local groups into SharePoint Groups to assign permissions to SharePoint sites and other resources.

  • Limit the number of nesting levels used in group membership.

The following specific situations will harm the performance of search and should be avoided:

  • Do not assign Search Server site permissions to individual users.

    Search Server sites slow down when more than 2,000 security principals are listed in a site's DACL. However, an Active Directory group or SharePoint group is a single security principal, regardless of the number of users it contains. Therefore, use SharePoint groups to assign site permissions and put users or Active Directory groups into SharePoint groups.

  • Do not use deeply nested Active Directory security groups.

    When a user attempts to access a Search Server site, the server must evaluate group memberships to authorize the user. When groups are deeply nested, many queries to the domain controllers are required. In addition, queries to remote domains in the forest may be necessary. These queries must complete before the user is granted access.

  • Do not use distribution lists or security groups that contain contacts.

    Contacts in Active Directory can be added to groups to, for example, distribute e-mail. However, contacts are not security principals and are not involved in authorization. Performance may be decreased if you assign permission to a group that contains contacts.

In Search Server, the site owner for each site can add users and groups to the site DACL. It is important that you educate site owners how to use group memberships responsibly in order to avoid introducing bottlenecks.

Expand image Troubleshooting missing Search Box Web Parts

The Search Box Web Part will not appear in the Search Center and other locations in the Search Server 2008 user interface in the following circumstances:

  • A developer has modified the Search Center content page, or the site master page, to hide or remove the Search Box Web Part.

  • A user who has Full Control or Design permission level on the site has removed or hidden the Search Box Web Part.

  • The Search service is unavailable in the Search Server farm, either because of a service interruption or because administrators have taken it offline.

Expand image See Also

Concepts

Preparing to crawl content (Search Server 2008)
Helping users make successful queries (Search Server 2008)
Protecting and restoring the farm (Search Server 2008)
Permissions for common administrative operations (Search Server 2008)
Plan to crawl content (Search Server 2008)


Change the Indexer Performance setting (Search Server 2008)
DropDown image

Updated: 2008-07-31

Note Note:

The information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This article addresses considerations regarding the Indexer Performance setting and explains how to change the current setting. You use the Indexer Performance setting to specify a base level for indexing activity.

Note Note:

You can use crawler impact rules to modify this base level for indexing activity. Crawler impact rules override the Indexer Performance setting. For more information, see Manage crawler impact (Search Server 2008) .

You can set the Indexer Performance setting to one of the following three values:

  • Reduced

  • Partly reduced

  • Maximum

Reduced is the lowest setting, Partly reduced is a higher setting, and Maximum is the highest setting. The default setting is Partly reduced. These settings are explained in more detail in the following sections.

In this article:

  • How the Indexer Performance setting affects farm servers

  • How the Indexer Performance setting affects the number of threads for crawling

  • Determining the appropriate Indexer Performance setting

  • To change the Indexer Performance setting

How the Indexer Performance setting affects farm servers

Decreasing the Indexer Performance setting curtails the speed at which items are indexed, which can cause search results to become outdated more quickly. Increasing the Indexer Performance setting can affect performance of servers in the farm in various ways:

  • Index server

    Indexing can place considerable demands on index server resources such as the disk, processors, and memory. An index server must have sufficient hardware to accommodate the amount of indexing required by your organization. For more information, see Application server hardware requirements (Advanced installation).

  • Database server

    The index server writes metadata that it collects from crawled documents into tables on the database server. When Indexer Performance is set to Maximum, the index server can generate data at a rate that overloads the database server. This can affect the performance of other applications that are using the same database server. It can also affect the performance of other shared services that are running under the shared services provider (SSP), such as Excel Calculation Services.

  • Web front-end servers

    To crawl content on local SharePoint sites, the index server sends requests to Web front-end servers that host the content. Such requests consume resources on the Web front-end servers and can thus reduce the responsiveness of the SharePoint sites that are hosted on these servers for end users.

    Important Important:

    Changing the Indexer Performance setting can also affect performance on crawled servers outside the farm.

How the Indexer Performance setting affects the number of threads for crawling

The Indexer Performance setting determines a default value for each of the following:

  • Total threads available to the index server for crawling at any given time

  • Maximum threads available to the index server at any given time for crawling any particular host

These values depend on the number of processors on the index server, as shown in the following table:

Indexer Performance setting | Total threads available for crawling | Maximum threads available for crawling any particular host
Reduced | Number of processors on the index server | Number of processors on the index server
Partially reduced | 4 times the number of processors on the index server | Number of processors on the index server plus 4
Maximum | 16 times the number of processors on the index server | Number of processors on the index server plus 4
Note Note:

  • You can use crawler impact rules to modify the number of threads that the index server uses for crawling. This enables you to control more precisely the resource demands that you are placing on each crawled host. For more information, see Manage crawler impact (Search Server 2008). For information about optimizing crawls, see the MSDN blog post Creating crawl schedules to minimize starvation (http://go.microsoft.com/fwlink/?LinkId=123794).

  • The maximum number of threads available for crawling is 64. This is the case regardless of your crawler impact rules or the number of processors on the index server.

Determining the appropriate Indexer Performance setting

Monitoring server performance during crawls can help you determine the appropriate setting for Indexer Performance. We recommend that you conduct your own testing to balance crawl speed, network latency, database load, and the load on content repositories that are being crawled.

Consider the following suggestions regarding adjusting the Indexer Performance setting:

  • If you are using the index server and database server only for searching (using the Office SharePoint Server Search service), you might want to set the Indexer Performance level to Maximum and note how this affects your database server performance. If the increase in database server CPU utilization exceeds 30 percent, we recommend changing the Indexer Performance level to Partly reduced.

  • If the index server and database server are shared across multiple services, such as the Office SharePoint Server Search service and the Excel Calculation Services, we recommend that you select the Partly reduced or Reduced setting for Indexer Performance.

To change the Indexer Performance setting

Use this procedure to view or change the Indexer Performance setting.

Note Note:

Membership in the farm administrators group is the minimum required to complete this procedure.

Change the Indexer Performance setting

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Services on server.

  2. On the Services on Server page:

    1. If the server name that appears is not the appropriate index server, click Change Server, and then click the index server.

    2. In the Start services in the table below section, click Office SharePoint Server Search.

  3. On the Configure Office SharePoint Server Search Service Settings page, in the Indexer Performance section, select one of the following:

    • Reduced

    • Partly reduced

    • Maximum

  4. Click OK to save changes and return to the Services on Server page.

See Also

Concepts

Determine hardware and software requirements (Search Server 2008)


Manage crawler impact (Search Server 2008)
DropDown image

Updated: 2008-09-11

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Content crawls can place a significant load on crawled servers and thereby adversely affect response times for server users. Therefore, we recommend that you use crawler impact rules to specify how aggressively your crawler should perform. A search services administrator can manage the affect of the crawler on a crawled site by using a crawler impact rule to specify one of the following:

  • The maximum number of documents that the crawler can request at a time from the specified site.

  • The frequency with which the crawler can request any particular document from the specified site.

For crawling internal content in your organization, you can set crawler impact rules based on the performance and capacity of the crawled servers. For example, you might try to avoid crawling internal servers at peak load times. However, for crawling external sites, this kind of coordination is usually not feasible. Therefore, it is best to configure crawl requests to minimize consumption of external site resources and bandwidth so that external site administrators are less inclined to restrict your future access.

During initial deployment, set your crawler impact rules to minimize impact on crawled servers while crawling them frequently enough to ensure relatively fresh results. Later, during the operations phase, you can adjust crawler impact rules based on your experience and the data from your crawl logs.

See Also

Concepts

Add a crawler impact rule (Search Server 2008)
Edit a crawler impact rule (Search Server 2008)


Add a crawler impact rule (Search Server 2008)
DropDown image

Updated: 2008-09-11

This article explains how to add a crawler impact rule for crawling a site. For information about the importance of using crawler impact rules, see Manage crawler impact (Search Server 2008).

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

When you add a crawler impact rule, you specify one of the following restrictions for crawling a specified site:

  • The maximum number of documents that the crawler can request at a time from the site.

  • The frequency with which the crawler can request a document from the site.

In this article:

  • Adding a crawler impact rule

  • Using wildcard characters in site names

Adding a crawler impact rule

Use the following procedure to add a crawler impact rule.

Important Important:

You must be a search services administrator to perform this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

To add a crawler impact rule

  1. On the Search Administration page, in the Crawling section, click Crawler impact rules.

  2. On the Crawler Impact Rules page, click Add Rule.

  3. On the Add Crawler Impact Rule page, in the Site section, in the Site box, type the site to associate with this crawler impact rule. For information about using wildcard characters in the site name, see Using wildcard characters in site names.

    Note Note:

    When typing the site name, you must exclude the protocol. For example, do not include http:// or file://.

  4. In the Request Frequency section, select one of the following options:

    • Request up to the specified number of documents at a time and do not wait between requests. From the Simultaneous requests list, select the maximum number of documents you want the crawler to request at a time when it crawls the specified site.

    • Request one document at a time and wait the specified time between requests. In the Time to wait (in seconds) box, type the time (in seconds) to wait between requests. The minimum time is one second; the maximum time is 1,000 seconds.

  5. Click OK.

Using wildcard characters in site names

A crawler impact rule can specify a single site, or you can use wildcard characters so that the rule applies to multiple sites. The following table shows the wildcard characters that you can use in the site name when you add a crawler impact rule.

Use | To
* as the site name | Apply the rule to all sites.
*.* as the site name | Apply the rule to sites with dots in the name.
*.sitename.com as the site name | Apply the rule to all sites in the sitename.com domain (for example, *.adventure-works.com).
*.top-level_domain_name (such as *.com or *.net) as the site name | Apply the rule to all sites that end with a specific top-level domain name (for example, .com or .net).
? | Signify a single character in a site name. For example, *.adventure-works?.com applies to all sites in the domains adventure-works1.com, adventure-works2.com, and so on.

For example, an administrator might create a crawler impact rule for *.com that applies to all Internet sites with addresses that end in .com. The administrator of a portal might add a content source for samples.microsoft.com. The rule for *.com applies to this site unless there is a crawler impact rule specifically for samples.microsoft.com.

See Also

Concepts

Edit a crawler impact rule (Search Server 2008)


Edit a crawler impact rule (Search Server 2008)
DropDown image

Updated: 2008-09-11

This article explains how to edit a crawler impact rule. For information about the importance of using crawler impact rules, see Manage crawler impact (Search Server 2008).

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

When you add a crawler impact rule, you specify one of the following restrictions for crawling a specified site:

  • The maximum number of documents that the crawler can request at a time from the specified site.

  • The frequency with which the crawler can request a document from the specified site.

Editing a crawler impact rule

Use the following procedure to edit a crawler impact rule.

Important Important:

You must be a search services administrator to perform this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

To edit a crawler impact rule

  1. On the Search Administration page, in the Crawling section, click Crawler impact rules.

  2. On the Crawler Impact Rules page, in the Site column, click the crawler impact rule you want to edit. The Edit Crawler Impact Rule page appears.

  3. In the Request Frequency section, select one of the following options:

    • Request up to the specified number of documents at a time and do not wait between requests. From the Simultaneous requests list, select the maximum number of documents you want the crawler to request at a time when crawling this URL.

    • Request one document at a time and wait the specified time between requests. In the Time to wait (in seconds) box, type the time (in seconds) to wait between requests. The minimum time is one second; the maximum time is 1,000 seconds.

  4. Click OK.

See Also

Concepts

Add a crawler impact rule (Search Server 2008)


White paper: Backing up Search Server 2008 by using System Center Data Protection Manager
DropDown image

Updated: 2009-07-16

Microsoft System Center Data Protection Manager 2007 is a server software application that enables data protection and recovery for protected computers within Active Directory domains.

With System Center Data Protection Manager, an administrator can back up Microsoft Search Server 2008 farms. By using the features in System Center Data Protection Manager with Service Pack 1 (SP1), an administrator can now back up the search index without writing additional scripts. For more information, see the following articles:

  • Protecting MOSS 2007 Indexes (http://go.microsoft.com/fwlink/?LinkId=155921)

  • Protecting WSS Indexes (http://go.microsoft.com/fwlink/?LinkId=155922)

  • Recovering Indexes in MOSS 2007 (http://go.microsoft.com/fwlink/?LinkId=155908)

  • Recovering WSS Indexes (http://go.microsoft.com/fwlink/?LinkId=155909)

Important Important:

If you are running System Center Data Protection Managerwithout SP1, the configurations and site collections that are stored in the configuration and content databases are backed up as part of the farm backup; however, the search database and index are not backed up. To back up and recover Search when you are running System Center Data Protection Managerwithout SP1, use the procedures and scripts that are provided in this white paper.

To download the white paper and appropriate files from the Microsoft Download Center, see White Paper: Microsoft Office SharePoint Server 2007 Search Backup for DPM 2007 (http://go.microsoft.com/fwlink/?LinkId=116263&clcid=0x409).


Move and migrate servers and server farms (Search Server 2008)
DropDown image

Updated: 2009-04-02

This topic contains the information that is required to help you select and plan hardware and software changes to your Microsoft Search Server 2008 deployment. There are three specific paths that you can take to change a farm:

  • Move Use the procedures for moving your farm or components when you are changing to different hardware. For example, use these procedures if you move to computers that have faster processors or larger hard disks.

  • Migrate Use the procedures for migrating your farm or components when you are changing to a different platform or operating system. For example, use these procedures if you change from Microsoft SQL Server 2005 to SQL Server 2008.

  • Upgrade Use the procedures for upgrading your farm or components when you are changing to a different version of Search Server 2008.

Decide whether to move, migrate, or upgrade

The following examples can help you understand the differences between moving, migrating, and upgrading:

  • Changing from a test farm environment to a production environment involves moving your farm. If you have set up a new Search Server 2008 farm in a test environment and want to transition to a production environment that uses similar hardware, use the Move to another farm (Search Server 2008) procedure.

  • Changing from 32-bit to 64-bit hardware is a migration process. You might have to change to 64-bit hardware if you intend to run Search Server 2008 in a Windows Server 2008 Hyper-V environment. To change to 64-bit hardware, use the Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007) procedure.

  • If you have run out of space on your current database server, you can move the databases to a new, larger disk.

    • If you want to move all the databases that are associated with your farm, use the Move all databases (Search Server 2008) procedure.

    • If you want to move only content databases, use the Move content databases (Search Server 2008) procedure.

Migration procedures

The following article provides information to help you migrate your Search Server 2008 farm, databases, and other components:

  • Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)

Moving procedures

The following articles provide information to help you move your Search Server 2008 farm, databases, and other components:

  • Move to another farm (Search Server 2008)

  • Move all databases (Search Server 2008)

  • Move content databases (Search Server 2008)

  • Move an SSP to another farm (Search Server 2008)

See Also

Concepts

Operations for Search Server 2008
How to crawl content (Search Server 2008)
Working with federation (Search Server 2008)
Protecting and restoring the farm (Search Server 2008)
Change the Indexer Performance setting (Search Server 2008)
White paper: Backing up Search Server 2008 by using System Center Data Protection Manager
Maintaining databases (Search Server 2008)


Move all databases (Search Server 2008)
DropDown image

Updated: 2009-06-11

This article contains information and steps for moving all the databases associated with Microsoft Search Server 2008 from one database server to another database server. This article includes two different procedures for moving databases:

  • To move all databases to a database server that has a different name, use the Move all databases to a different database server procedure.

  • To move all databases to an identically named or upgraded database server, use the Move all databases to a database server that has the same name procedure.

Important Important:

The procedures in this article require you to stop the complete farm. This will make all farm sites and assets unavailable to users until the process is complete.

The following databases can be moved by using the procedures in this article:

  • Database for the Shared Services Provider (SSP)

  • Content databases

  • Search database

  • Central Administration content database

  • Configuration database

Move all databases to a different database server

This is a procedure for moving all the databases in a Search Server 2008 farm to a new database server that has a different name. The new database server must use the same version of Windows Server and SQL Server as the old database server. To move the databases to an identically named or upgraded server, use the Move all databases to an upgraded database server procedure.

The procedures that follow use several different Search Server 2008 and Microsoft SQL Server 2005 or SQL Server 2008 built-in tools such as the Central Administration Web site and the Stsadm command-line tool. The process of moving all the databases from one database server to another database server includes the following steps:

  1. Prepare the new database server.

  2. Record which Web applications are associated with the SSP. This information can be used to reassociate Web applications with the restored SSP.

  3. Back up the SSP.

  4. Remove the SSP from the farm.

  5. Stop the farm. Before you can move all the databases, you must stop the farm to ensure that no changes are made while the databases are moved.

  6. Back up the configuration database and the Central Administration content database.

    Note Note:

    The other databases in the farm are backed up and restored at the same time as the SSP.

  7. Copy or move the database backup files to the destination database server.

  8. On the destination database server, restore the databases that you backed up.

  9. Copy to the destination database server all the SQL Server logins, fixed server roles, fixed database roles, and permissions for these databases.

  10. Redirect the farm to reference the new database server.

    Important Important:

    We recommend that you direct the farm to the new database server by using a SQL Server connection alias. You must create a SQL Server connection alias that can be used by all servers (including the front-end Web servers and application servers) to connect to the instance of SQL Server. A connection alias is an alternative name that you can use to make a connection to an instance of SQL Server.

  11. Restart the server that is running Central Administration to apply the changes and ensure that the services, Web sites, and application pools that are associated with Search Server 2008 are started.

  12. Restore the SSP from the backup.

  13. Associate Web applications to the SSP.

Important Important:

The following are the minimum required to perform this procedure:

  • You must be a member of the Farm Administrators SharePoint group.

  • On the computer that is running the SharePoint Central Administration Web site, you must be a member of the Administrators group.

  • On the database server from which the databases are being moved:

    • You must be a member of the Administrators group.

    • You must be a member of the db_backupoperator fixed database role.

  • On the database server to which the databases are being moved:

    • You must be a member of the Administrators group.

    • You must be a member of the db_owner fixed database role.

  • In some environments, you must coordinate the move procedures with the database administrator. Be sure to follow any applicable policies and guidelines for handling databases.

Move all databases to a different database server

  1. Prepare the new database server by using the Prepare the database servers procedure.

  2. Record which Web applications are associated with the SSP by performing the following steps:

    1. On the SharePoint Central Administration Web site, on the Application Management page, in the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.

    2. Record the associated Web applications that are listed on the Manage This Farm's Shared Services page.

  3. Back up an SSP by performing the following steps:

    1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

    2. If you do not already know which node you want to back up, type the following command:

      stsadm -o backup -showtree

      Note Note:

      This command displays the list of objects in the farm that will be backed up, but does not perform a backup. Items that cannot be backed up will be enclosed in brackets ([ ]).

    3. To back up an SSP, type the following command:

      stsadm -o backup -directory <UNC path> -backupmethod full -item <SSP name>

      where UNC path is the UNC path (\\server name\folder name) of the backup folder and where SSP name is the name of the SSP that you want to back up. All databases associated with the SSP will be automatically included in the backup.

  4. Remove the SSP by performing the following steps:

    1. On the disk on which Microsoft SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

    2. To remove an SSP, type the following command, and then press ENTER:

      stsadm -o deletessp -title <SSP name> -deletedatabases -force

      where SSP name is the name of the SSP that you want to remove.

    3. To detach the SSP content database from the SharePoint farm, type the following command, and then press ENTER:

      stsadm -o -deletecontentdb -url <URL> -databasename <database name>

      where URL is the URL of the Web application from which the content database will be detached and database name is the name of the content database to be detached.

  5. Delete the SSP content databases.

    1. Start SQL Server Management Studio and connect to the database server.

    2. In Object Explorer, expand Databases.

    3. Right-click an SSP content database, point to Tasks, and then click Delete.

    4. On the Delete Object page, check that the database you want to delete is highlighted, and then click OK.

    5. Perform steps c and d for each SSP content database.

  6. Stop the farm by performing the following steps:

    1. On the server that is running the Central Administration Web site, in the Services snap-in, stop the following services:

      • Windows SharePoint Services Administration service

      • Windows SharePoint Services Search service

      • Windows SharePoint Services Timer service

      • Windows SharePoint Services Tracing service

      • Windows SharePoint Services VSS Writer service

    2. On the server that is running the Central Administration Web site, at the command prompt, type iisreset /stop.

    3. Repeat step 6 on each server in the farm.

  7. Back up the databases on the source database server.

    1. Start SQL Server Management Studio and connect to the database server.

    2. In Object Explorer, expand Databases.

    3. Right-click the configuration database (usually named SharePoint_Config), point to Tasks, and then click Back Up.

    4. In the Back Up Database dialog box, in the Source area, select the type of backup that you want to perform from the Backup type list. For more information about which backup type to use, see Overview of Recovery Models (http://go.microsoft.com/fwlink/?LinkId=114396&clcid=0x409) in the SQL Server 2005 Books Online.

    5. Click Database.

    6. In the Backup set area, in the Name text box, type a name or use the default.

    7. In the Description text box, type a description of the backup.

    8. Specify how long the backup should be kept, or use the default. When the backup set expires, the backup set can be overwritten by any subsequent backups that have the same name. By default, the setting for the backup set is 0 days so that it never expires.

    9. In the Destination section, specify a location to store the backup set, or use the default.

    10. Click OK to back up the database.

    11. Repeat steps c through j for the remaining databases in the farm.

  8. In Windows Explorer, locate the database backup (.bak) files that you want to move, and then copy or move them to the destination server.

    Important Important:

    In some environments, this step must be performed by the database administrator.

    Move only the backup files to the destination database server. Do not move any databases or other files at this time.

  9. Restore databases on the destination database server.

    1. Start SQL Server Management Studio and connect to the database server.

    2. In Object Explorer, expand Databases.

    3. Right-click the database that you want to restore, point to Tasks, point to Restore, and then click Database.

    4. In the Restore Database dialog box, specify the destination and the source, and then select the backup set or sets that you want to restore.

      The default values for destination and source typically suit most recovery scenarios.

    5. In the Select a page pane, click Options.

    6. In the Restore options section, select only Overwrite the existing database. Unless your environment or policies require otherwise, do not select the other options in this section.

    7. In the Recovery state section:

      • If you have included all the transaction logs that you must restore, select RESTORE WITH RECOVERY.

      • If you must restore additional transaction logs, select RESTORE WITH NORECOVERY.

      • The third option, RESTORE WITH STANDBY, is not used in this scenario.

    8. Click OK to complete the restore operation.

    9. Repeat steps c through h for each database that you are restoring.

  10. Use SQL Server to copy to the destination server the logons for all service accounts, including SQL Server logins, fixed server roles, fixed database roles, and permissions for the databases.

    For information about how to copy SQL Server roles and permissions to the destination database server, see Microsoft Help and Support article 246133, How to transfer logins and passwords between instances of SQL Server (http://go.microsoft.com/fwlink/?LinkId=114420&clcid=0x409). For troubleshooting information, see Microsoft Help and Support article 240872, How to resolve permission issues when you move a database between servers that are running SQL Server (http://go.microsoft.com/fwlink/?LinkId=123469&clcid=0x409).

    Important Important:

    In some environments, this step must be performed by the database administrator.

  11. Refer the farm to the new database server by creating a SQL Server connection alias.

    1. Start the SQL Server Native Client Network Utility (%SYSTEM%\cliconfg.exe).

    2. On the General tab, verify that TCP/IP is enabled.

    3. On the Alias tab, click Add.

      The Add Network Library Configuration dialog box appears.

    4. In the Server alias box, enter the name of the current instance of SQL Server.

    5. In the Network libraries area, click TCP/IP.

    6. In the Connection parameters area, in the Server name box, enter the new server name and instance to associate with the alias, and then click OK.

    7. Repeat steps a through f on all servers that connect to SQL Server.

  12. Start the new farm by performing the following steps:

    1. In the Services snap-in, start the following services:

      • Windows SharePoint Services Administration service

      • Windows SharePoint Services Search service

      • Windows SharePoint Services Timer service

      • Windows SharePoint Services Tracing service

      • Windows SharePoint Services VSS Writer service (optional)

    2. At the command prompt, type iisreset /start.

    3. Repeat steps a and b on each server in the farm.

  13. Restore an SSP to the new location.

    1. To obtain the backup GUID for the specific backup that you want to restore, type the following command, and then press ENTER:

      stsadm -o backuphistory -directory <UNC path>

      where UNC path is the path of the shared folder that contains the backup.

    2. To restore a database, type the following command, and then press ENTER:

      stsadm -o restore -directory <UNC path> -restoremethod new -backupid <GUID from backuphistory> -newdatabaseserver <SQL Server instance>

      where UNC path is the UNC path of the backup shared folder, GUID from backuphistory is the GUID for the specific backup package that you want to restore, and SQL Server instance is the name of the SQL Server instance where the SSP databases should be restored.

  14. Associate the Web application to the SSP by performing the following steps:

    1. On the SharePoint Central Administration Web site, on the Application Management page, in the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.

    2. On the Manage This Farm's Shared Services page, if the Web application is not associated with the SSP, click Change Associations.

    3. On the Change Association between Web Applications and SSPs page, select the SSP from the SSP Name list.

    4. In the Web application section, select the Web application that you want to associate to the SSP, and then click OK.

Move all databases to a database server that has the same name

This is a procedure for moving all Search Server 2008 databases to an identically named database server. The new database server can differ in the following ways from the original server:

  • It runs a newer version of SQL Server—for example, SQL Server 2008 instead of SQL Server 2005.

  • It runs a newer version of Windows—for example, Windows Server 2008 instead of Windows Server 2003.

  • It is a 64-bit computer that runs a 64-bit operating system, instead of a 32-bit computer that runs a 32-bit operating system.

This article does not provide information about how to upgrade the database server.

  • For more information about how to upgrade to Windows Server 2008, see Installing Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=140803) or see the documentation that is included with the software.

  • For more information about how to upgrade to Microsoft SQL Server 2008, see Installing SQL Server 2008 (http://go.microsoft.com/fwlink/?LinkID=141021) or see the documentation that is included with the software.

Important Important:

For information about how to migrate the current database server, see the Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007) procedure.

This procedure uses several different Search Server 2008 and SQL Server built-in tools such as the Central Administration Web site, SQL Server Management Studio or SQL Server Management Studio Express (SSMSE), and the Stsadm command-line tool. The process of moving databases to a new database server includes the following steps:

  1. Stop the farm.

  2. Detach the databases.

  3. Shut down the old database server.

  4. Prepare the new database server that has the same name as the old one.

  5. Reattach the databases on the new server.

  6. Restart the server that is running Central Administration to apply the changes and ensure that the services, Web sites, and application pools that are associated with Search Server 2008 are started.

Important Important:

The following are the minimum required to perform this procedure:

  • You must be a member of the Farm Administrators SharePoint group.

  • On the computer that is running the SharePoint Central Administration Web site, you must be a member of the Administrators group.

  • On the new and old database servers:

    • You must be a member of the Administrators group.

    • You must be a member of the db_owner fixed database role.

  • In some environments, you must coordinate the migration procedures with the database administrator. Be sure to follow any applicable policies and guidelines for handling databases.

Move all databases to a database server that has the same name

  1. Stop the farm by following these steps:

    1. On the server that is running the Central Administration Web site, in the Services snap-in, stop the following services:

      • Windows SharePoint Services Administration service

      • Windows SharePoint Services Search service

      • Windows SharePoint Services Timer service

      • Windows SharePoint Services Tracing service

      • Windows SharePoint Services VSS Writer service

    2. On the server that is running the Central Administration Web site, at the command prompt, type iisreset /stop.

  2. Detach the databases on the source database server by following these steps:

    1. Start SQL Server Management Studio and connect to the database server.

    2. In Object Explorer, expand Databases.

    3. Right-click the database that you want to detach, point to Tasks, and then click Detach.

    4. In the Detach Database dialog box, select the database that you want to detach.

    5. Click OK.

    6. Repeat these steps for each database in the deployment.

  3. To prevent loss of data during the move, you can back up the databases on the source database server by using the Back up databases (Search Server 2008) procedure.

  4. Shut down the original database server.

  5. Prepare a new database server that has the same name as the original database server by using the Prepare the database servers procedure. In addition, you can make improvements to the new database server by installing the following software:

    • Windows Server 2008. For more information, see Installing Windows Server 2008 or see the documentation that is included with the software.

    • SQL Server 2008. For more information, see Installing SQL Server 2008 or see the documentation that is included with the software.

  6. Reattach the databases to the new database server by performing the following steps:

    1. Start SQL Server Management Studio and connect to the database server.

    2. In Object Explorer, expand Databases.

    3. Right-click Databases, point to Tasks, and then click Attach.

    4. In the Attach Databases dialog box, in the Databases to attach section, click Add.

      1. In the Locate Database Files dialog box, find the databases that you want to attach.

      2. Click a database and then click OK.

      3. Repeat this step for each database that you want to attach.

    5. Click OK.

    6. To make the databases that you attached appear in the Object Explorer pane, refresh the view.

  7. Restart the farm by performing the following steps:

    1. On the server that is assigned to run the Central Administration Web site, in the Services snap-in, start the following services:

      • Windows SharePoint Services Administration service

      • Windows SharePoint Services Search service

      • Windows SharePoint Services Timer service

      • Windows SharePoint Services Tracing service

      • Windows SharePoint Services VSS Writer service (optional)

    2. On the server that is assigned to run the Central Administration Web site, in the Internet Information Services (IIS) Manager snap-in, start the SharePoint Central Administration v3 and SSP Web services.

See Also

Concepts

Maintaining databases (Search Server 2008)
Add, split, and merge content databases (Search Server 2008)
Move content databases (Search Server 2008)
Move content database from Windows Internal Database or SQL Server Express Edition to an instance of SQL Server (Search Server 2008)


Move content databases (Search Server 2008)
DropDown image

Updated: 2008-08-07

You can move content databases between Microsoft SQL Server 2005 instances, from one server running Microsoft Search Server 2008 to any other server running Search Server 2008, from one Web application to another, or from Windows Internal Database to a SQL Server 2005 instance. You can also move one or all content databases for any Web application to another Web application.

Note Note:

Windows Internal Database uses SQL Server technology as a relational data store for Windows roles and features only, such as Windows SharePoint Services, Active Directory Rights Management Services, UDDI Services, Windows Server Update Services, and Windows System Resources Manager.

You might move content databases as part of an upgrade or migration process, as part of a backup and recovery process, or as part of the process of moving your sites from a development environment to a production environment.

Important Important:

This article covers moving only content databases and does not provide information for moving other databases that are associated with Search Server 2008.

You can perform this task by using either the SharePoint Central Administration Web site or by using the Stsadm command-line tool.

Important Important:

If you detach and reattach a content database, be aware that the next time the content within that content database is crawled a full crawl will occur even if an incremental crawl has been requested. Because a full crawl re-crawls all content that the crawler encounters, regardless of whether that content has been previously crawled, full crawls can take significantly more time to complete than incremental crawls.

If you are running the Infrastructure Update for Microsoft Office Servers, the identifier (ID) of each content database is retained when you restore or reattach the database by using built-in tools. Default change log retention behavior when using built-in tools is as follows:

  • The change logs for all databases are retained when you restore a farm.

  • The change log for a content database is retained when you reattach the database.

  • The change log for a content database is NOT retained when you restore just the content database.

When a database ID and change log are retained, Search continues crawling based on the regular schedule defined by crawl rules. When a change log is not retained, Search performs a full crawl during the next scheduled crawl.

Task Requirements

The following are required to perform the procedures for this task:

  • You must be a member of the Administrators group on the source server computer and the destination server computer.

  • You must have at least the following roles in SQL Server 2005:

    • The dbowner fixed database role for the database on the source server running SQL Server 2005 or SQL Server instance, to detach the database.

    • If you are moving the databases from one farm to another farm, you must make the database access account a member of the Administrators group on the database server during the restore process. This is required for the account to replicate the security setting for the databases. This access level can be removed after the restore process is complete.

    • The dbcreator fixed server role on the destination server running SQL Server 2005 server or SQL Server instance, to attach the database.

To move content databases, you can perform the procedure that corresponds to your environment:

  • Move content databases between instances of SQL Server (Search Server 2008)

  • Move content database from Windows Internal Database or SQL Server Express Edition to an instance of SQL Server (Search Server 2008)

See Also

Concepts

Maintaining databases (Search Server 2008)
Add, split, and merge content databases (Search Server 2008)
Move all databases (Search Server 2008)


Move content databases between instances of SQL Server (Search Server 2008)
DropDown image

Updated: 2009-08-20

You can move content databases between instances of Microsoft SQL Server 2005, from any server running Microsoft Search Server 2008 to any server running Search Server 2008, or from one Search Server 2008 Web application to another.

Important Important:

This article covers moving content databases only and does not provide information about moving other databases that are associated with Search Server 2008.

Important Important:

If you detach and reattach a content database, be aware that the next time the content within that content database is crawled a full crawl will occur even if an incremental crawl has been requested. Because a full crawl re-crawls all content that the crawler encounters, regardless of whether that content has been previously crawled, full crawls can take significantly more time to complete than incremental crawls.

If you are running the Infrastructure Update for Microsoft Office Servers, the identifier (ID) of each content database is retained when you restore or reattach the database by using built-in tools. Default change log retention behavior when using built-in tools is as follows:

  • The change logs for all databases are retained when you restore a farm.

  • The change log for a content database is retained when you reattach the database.

  • The change log for a content database is NOT retained when you restore just the content database.

When a database ID and change log are retained, Search continues crawling based on the regular schedule defined by crawl rules. When a change log is not retained, Search performs a full crawl during the next scheduled crawl.

For more information, see Move all databases (Search Server 2008) and Protecting and restoring the farm (Search Server 2008).

Move content databases between instances of SQL Server

In the move process, you will use Search Server 2008 tools and SQL Server 2005 tools. You can use either the SharePoint Central Administration Web site or the Stsadm command-line tool. The following procedures document the steps for both tools. The process involves the following phases:

  1. Using Search Server 2008 tools, remove the content database from the Search Server 2008 Web application. Removing the content database does not delete the database but only removes the association of the database with the Web application. This task is analogous to detaching a database in SQL Server in that the content of the database remains intact.

    Note Note:

    Record the exact name of the content database. If you are moving or copying several content databases from more than one Web application, record which content databases are associated with each Web application.

  2. By using SQL Server 2005 tools, detach the database from the source instance.

  3. Copy or move the .mdf and .ldf files from the source directory to the destination directory.

  4. By using SQL Server 2005 tools, reattach the database to the destination instance.

  5. By using Search Server 2008 tools, add the content database to the destination Search Server 2008 Web application. Be sure that you use the exact same name to reattach the content database. Otherwise, Search Server 2008 will create a new database.

  6. By using Search Server 2008 tools, perform a full crawl of the newly reattached content database.

Important Important:

Membership in the Administrators group on the local computers is required to complete this procedure. You must have at least the following roles in SQL Server 2005:

  • The dbowner fixed database role for the database on the source running SQL Server 2005 or instance of SQL Server, to detach the database.

  • If you are moving the databases from one farm to another farm, you must make the database access account a member of the Administrators group on the database server during the restore process. This is required for the account to replicate the security setting for the databases. This access level can be removed after the restore process is complete.

  • The dbcreater fixed server role on the destination server running SQL Server 2005 or instance of SQL Server, to attach the database.

Note Note:

Record the exact name of the content database. If you are moving or copying several content databases from more than one Web application, record which content database is associated with each Web application.

Move content databases between instances of SQL Server by using Central Administration

  1. In Central Administration, on the Application Management page, in the SharePoint Web Application Management section, click Content databases.

  2. On the Manage Content Databases page, click the content database you want to move.

    Note Note:

    If the content database does not appear, it might be associated with another Web application. To select another Web application, on the Web Application menu, click Change Web Application.

  3. On the Manage Content Database Settings page, in the Remove Content Database section, select the Remove content database check box, and then click OK.

    Note Note:

    Removing the content database does not delete the database; it only removes the association of the database with the Web application.

  4. Repeat steps 2 and 3 for each content database that you want to move.

  5. In SQL Server 2005 Management Studio, open the source instance of SQL Server, and then expand the Databases node.

  6. Right-click the content database, point to Tasks, and then click Detach. Repeat this step for each content database that you want to move.]

    Note Note:

    Use this procedure to move only content databases. Do not detach any other databases.

  7. In Windows Explorer, browse to the location of the .mdf and .ldf files for the content databases.

  8. Select the .mdf and .ldf files for the database you want to move and either copy or move them to the destination directory.

  9. In SQL Server 2005 Management Studio, open the destination instance of SQL Server.

  10. Right-click the Databases node, point to Tasks, and then click Attach.

  11. In the Attach Database dialog box, browse to the location to which you transferred the .mdf and .ldf files, select the .mdf file for the database you want to attach and click OK.

  12. Repeat steps 10 and 11 for each content database that you are moving.

  13. In Central Administration, on the Application Management page, in the SharePoint Web Application Management section, click Content databases.

  14. On the Manage Content Databases page, click Add a content database.

  15. On the Add Content Database page, verify that the Web Application menu displays the correct Web application.

  16. In the Database Name box, type the exact name of the transferred content database, and then click OK.

  17. Repeat steps 15 and 16 for each database you are adding. Be sure that you select the correct Web application from the Web Application menu for each database.

  18. Start a full crawl of each of the transferred content databases. For more information about starting a full-crawl, see Start a full crawl (Office SharePoint Server 2007).

Move content databases between instances of SQL Server by using the Stsadm command-line tool

  1. On the drive where SharePoint Products and Technologies is installed, change to the following directory where the Stsadm command-line tool is located: %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\Bin.

    Important Important:

    If you have installed a software update that includes the Infrastructure Update for Office Servers (http://go.microsoft.com/fwlink/?LinkID=121886&clcid=0x419), you must not run the preparetomove operation. Skip step 2 and proceed to step 3.

  2. Type the following command, and then press ENTER:

    stsadm -o preparetomove -contentdb <content database name>

    To determine the database name, use the enumcontentdbs operation.

    For more information about the preparetomove operation, see Preparetomove: Stsadm operation (Office SharePoint Server).

  3. Type the following command, and then press ENTER:

    stsadm -o deletecontentdb -url <URL name> -databasename <database name> -[databaseserver <database server name>]

    For more information about the deletecontentdb operation, see Deletecontentdb: Stsadm operation (Office SharePoint Server).

    Note Note:

    You must perform this operation for each content database you want to move. Removing the content database does not delete the database. The operation only removes the association of the database with the Web application.

  4. In SQL Server 2005 Management Studio, open the source instance of SQL Server, and then expand the Databases node.

  5. Right-click the content database that you want to detach, point to Tasks, and then click Detach. Repeat for each content database that you want to move.

    Note Note:

    You can use this procedure to move content databases only. Do not detach any other databases.

  6. In Windows Explorer, browse to the location of the .mdf and .ldf files for the content databases.

  7. Select the files, and then either copy or move them to the destination directory.

  8. In SQL Server 2005 Management Studio, open the destination instance of SQL Server.

  9. Right-click the Databases node, point to Tasks, and then select Attach.

  10. In the Attach Database dialog box, browse to the location to which you transferred the .mdf and .ldf files, select the .mdf file for the database you want to attach, and then click OK.

  11. Repeat steps 8 and 9 for each content database you are moving.

  12. On the drive where SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin

  13. Type the following command, and then press ENTER:

    stsadm -o addcontentdb -url <URL name> -databasename <database name>[-databaseserver <database server name>] [-databaseuser <database user name>][-databasepassword <database password>][-sitewarning <site warning count>] [-sitemax <site max count>]

    For more information about the addcontentdb operation, see Addcontentdb: Stsadm operation (Windows SharePoint Services).

    Note Note:

    You must perform this operation for each content database you want to move. You can create a batch script to do this.

  14. Start a full crawl of each of the transferred content databases. For more information about starting a full-crawl, see Start a full crawl (Office SharePoint Server 2007).

See Also

Concepts

Move content databases (Search Server 2008)
Move content database from Windows Internal Database or SQL Server Express Edition to an instance of SQL Server (Search Server 2008)


Move content database from Windows Internal Database or SQL Server Express Edition to an instance of SQL Server (Search Server 2008)
DropDown image

Updated: 2008-08-07

You can move Microsoft Search Server 2008 content databases from Windows Internal Database or from Microsoft SQL Server 2005 Express Edition to an instance of Microsoft SQL Server 2005. Windows Internal Database uses SQL Server technology as a relational data store for Windows roles and features only, such as Windows SharePoint Services, Active Directory Rights Management Services, UDDI Services, Windows Server Update Services, and Windows System Resources Manager..

If you are running the Infrastructure Update for Microsoft Office Servers, the identifier (ID) of each content database is retained when you restore or reattach the database by using built-in tools. Default change log retention behavior when using built-in tools is as follows:

  • The change logs for all databases are retained when you restore a farm.

  • The change log for a content database is retained when you reattach the database.

  • The change log for a content database is NOT retained when you restore just the content database.

When a database ID and change log are retained, Search continues crawling based on the regular schedule defined by crawl rules. When a change log is not retained, Search performs a full crawl during the next scheduled crawl.

For more information, see Move content databases (Search Server 2008) and Protecting and restoring the farm (Search Server 2008).

Important Important:

This article covers moving content databases only and does not provide information for moving other databases that are associated with Search Server 2008.

Important Important:

If you detach and reattach a content database, be aware that the next time the content within that content database is crawled a full crawl will occur even if an incremental crawl has been requested. Because a full crawl re-crawls all content that the crawler encounters, regardless of whether that content has been previously crawled, full crawls can take significantly more time to complete than incremental crawls.

Move content databases to an instance of SQL Server

In the move process, you will use both Search Server 2008 tools and Microsoft SQL Server 2005 tools. You can use the SharePoint Central Administration Web site or the Stsadm command-line tool. Steps for both are provided. The process involves the following phases:

  1. By using Search Server 2008 tools, remove the content database from the Web application. Removing the content database does not delete the database; it only removes the association of the database with the Web application. This action is analogous to detaching a database in SQL Server in that the content of the database remains intact.

  2. Copy or move the .mdf and .ldf files from the source server to the destination server (if they are different servers).

  3. By using SQL Server 2005 tools, select the transferred files and attach the database to the destination instance of SQL Server.

  4. By using Search Server 2008 tools, add the content database to the destination Web application. Be sure that you use exactly the same name to reattach the content database, or Search Server 2008 will create a new database.

  5. By using Search Server 2008 tools, re-index the content in the newly reattached content database.

The following procedures provide steps for moving content databases by using Central Administration or the Stsadm command-line tool.

Important Important:

Membership in the Administrators group on the local computer is required to complete this procedure. In addition, you must have at least the following roles in SQL Server 2005:

  • The dbowner fixed database role for the database on the source server running SQL Server 2005 or instance of SQL Server, to detach the database.

  • If you are moving the databases from one farm to another farm, you must make the database access account a member of the Administrators group on the database server during the restore process. This is required for the account to replicate the security setting for the databases. This access level can be removed after the restore process is complete.

  • The dbcreater fixed server role on the destination server running SQL Server 2005 or instance of SQL Server, to attach the database.

Move content databases by using Central Administration

  1. In Central Administration, on the Application Management page, in the SharePoint Web Application Management section, click Content databases.

    Note Note:

    Record the exact names of the content databases that you want to move. If you are moving or copying several content databases from more than one Web application, record which content database is associated with each Web application.

  2. On the Manage Content Databases page, click the content database that you want to move.

    Note Note:

    If the content database does not appear, it might be associated with another Web application. To select another Web application, on the Web Application menu, click Change Web Application.

  3. On the Manage Content Database Settings page, in the Remove Content Database section, select the Remove content database check box, and then click OK.

    Note Note:

    Removing the content database does not delete the database; it only removes the association of the database with the Web application.

  4. Repeat steps 2 and 3 for each content database you are moving.]

  5. In Windows Explorer, browse to the location of the .mdf and .ldf files for the content databases.

  6. Select the files, and then either copy or move them to the destination directory.

  7. In SQL Server 2005 Management Studio, open the destination instance of SQL Server.

  8. Right-click the Databases node, point to Tasks, and then click Attach.

  9. In the Attach Database dialog box, browse to the location to which you transferred the .mdf and .ldf files, select the .mdf file for the database you want to attach, and then click OK.

  10. Repeat steps 8 and 9 for each content database that you want to move.]

  11. In Central Administration, on the Application Management page, in the SharePoint Web Application Management section, click Content databases.

  12. On the Manage Content Databases page, click Add a content database.

  13. On the Add Content Database page, in the Database Name box, type the exact name of the transferred content database, and then click OK.

  14. Repeat steps 12 and 13 for each database that you are adding. Be sure that you select the correct Web application for each database from the Web Application menu.

  15. Start a full crawl of each of the transferred content databases. For information about starting a full crawl, see Start a full crawl (Office SharePoint Server 2007).

Move content databases using by using the Stsadm command-line tool

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. At a command prompt, type the following command, and then press ENTER:

    stsadm -o deletecontentdb -url <URL name> -databasename <database name> [-databaseserver <database server name>]

    For more information about the deletecontentdb operation, see Deletecontentdb: Stsadm operation (Office SharePoint Server).

    Note Note:

    You must perform this command for each content database you want to move. Removing the content database does not delete the database but only removes the association of the database with the Web application.

  3. In Windows Explorer, browse to the location of the .mdf and .ldf files for the content databases.

  4. Select the files, and then either copy or move them to the destination directory.

  5. In SQL Server 2005 Management Studio, open the destination instance of SQL Server.

  6. Right-click the Databases node, point to Tasks, and then select Attach.

  7. In the Attach Database dialog box, browse to the location to which you transferred the .mdf and .ldf files, select the .mdf file for the database you want to attach, and then click OK.

  8. Repeat steps 6 and 7 for each content database that you are moving.

  9. On the drive on which SharePoint Products and Technologies is installed, open the command line and change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  10. Type the following command, and then press ENTER:

    stsadm -o addcontentdb -url <URL name> -databasename <database name> [-databaseserver <database server name>]

    For more information about the addcontentdb operation, see Addcontentdb: Stsadm operation (Office SharePoint Server).

    Note Note:

    You must perform this command for each content database you want to move. You can create a batch script to do this.

  11. Start a full crawl of each of the transferred content databases. For more information about starting a full crawl, see Start a full crawl (Office SharePoint Server 2007).

See Also

Concepts

Move content databases (Search Server 2008)
Move content databases between instances of SQL Server (Search Server 2008)


Move to another farm (Search Server 2008)
DropDown image

Updated: 2009-04-02

The following procedures will help you move a Microsoft Search Server 2008 deployment to another farm. Use these procedures to move a farm to the same configuration on identical computers in a different location. If you want to migrate a farm to a new configuration or equipment type, see Deploy a new server farm, then migrate content databases. For more information about the differences between moving, migrating, and upgrading a farm, and about which set of procedures apply most directly to your situation, see Move and migrate servers and server farms (Search Server 2008).

To help prevent loss of data and to minimize downtime, you should move a farm in stages. Each stage corresponds to a tier in the server hierarchy. For more information about Microsoft SharePoint Products and Technologies server architecture, see White paper: Office SharePoint Server farm architecture.

Each stage of moving a farm has different requirements and procedures. After you complete each stage of the move, you should test the farm operation to make sure that the move was successful. The stages are as follows:

  • Move the front-end Web servers.

  • Move the application servers.

  • Move the database server.

Move the front-end Web servers

Important Important:

Be sure to document any customizations that have been made to the front-end Web servers so that you can configure the new servers the same way. Such customizations may include the following:

  • The %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12 directory.

  • Any customizations that are made to the Web.config file.

  • Default quota templates.

  • Blocked file types.

  • Administrator-deployed form templates.

  • Database names and locations.

  • Web application names and databases. Be sure to document the content database names associated with each Web application.

  • Crawler impact rules.

  • Activated features.

The first step in moving the front-end Web servers to their new location is to set up the destination servers. For each front-end Web server in the new farm, perform the Add a Web server to the farm procedure and connect the new server to the current databases. If you are moving an index server, perform the Add an index server to the farm procedure. If you are moving a query server, perform the Add an index server to the farm procedure.

As each new server comes online, you can remove the old servers by using the Remove a server from the farm procedure.

Move the application servers

Move the SSPs on the application servers by using the Move an SSP to another farm (Search Server 2008) procedure.

Move the database server

Move the databases by using the Move all databases (Search Server 2008) procedure.

See Also

Concepts

Move and migrate servers and server farms (Search Server 2008)
Move all databases (Search Server 2008)
Move an SSP to another farm (Search Server 2008)


Move an SSP to another farm (Search Server 2008)
DropDown image

Updated: 2008-10-09

Use these procedures to move a Shared Services Provider (SSP) from one server farm to another. Reasons that you might want to move an SSP include the following:

  • Moving a set of Web applications from one domain to another.

  • Splitting the Microsoft Search Server 2008 functions across two server farms within a domain.

  • Moving the SSP from a development environment to the live server farm.

Moving an SSP consists of the following four basic steps:

  1. Back up the original SSP.

  2. Restore the SSP to the new farm.

  3. Restore SSP associations and configure the SSP.

  4. Delete the original SSP.

Move an SSP

Use the following procedures to move an SSP.

When preparing to migrate an SSP, ensure the following:

  • There is a backup folder on the network in which to store your SSP backup file that is accessible from both the old and new server farms. For more information, see Prepare to back up and restore a farm (Search Server 2008).

  • On the farm from which you are moving the SSP, you are logged on to the server that is running the SharePoint Central Administration Web site.

Important Important:

Membership in the Farm Administrators SharePoint group is the minimum required to complete the following procedure. You must also be a member of the db_backupoperator fixed database role on each database that you are backing up.

The SSP content databases might be on a different database server than the SSP database.

Perform the following procedure on the farm from which the SSP is moving.

Back up the SSP

  1. On the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Perform a backup.

  2. On the Select Component to Backup page, select the check boxes for the SSP that you want to back up, and then click Continue to Backup Options. Verify that all associated databases are automatically checked. For information about how to back up databases separately from the SSP, see Back up databases (Search Server 2008).

  3. On the Select Backup Options page:

    • In the Backup Content section, verify that the SSP that you selected is displayed.

    • In the Type of Backup section, select Full.

    • In the Backup File Location section, type the Universal Naming Convention (UNC) path of the backup folder.

  4. Click OK.

    You can view the backup job status on the status page by clicking Refresh. The page also refreshes every 30 seconds automatically. Backup and recovery use the Windows SharePoint Services Timer Service to schedule jobs. Therefore, it may take few seconds for the backup to start.

    If you receive any errors, you can find more information by viewing the spbackup.log at the UNC path that you specified in the previous step.

Important Important:

Membership in the Farm Administrators SharePoint group is the minimum required to complete the following procedure. You must also be a member of the dbcreator fixed server role on the database server where each database is stored. The SSP content databases might be on a different database server than the SSP database.

Also, the account that you use to restore the SSP to the new server farm should be a member of the Administrators group on the local database server computer to which the SSP database is being restored. Otherwise, site permissions might not be transferred during recovery and the restored Web applications might be inaccessible.

Perform the following procedure on the farm to which you are moving the SSP.

Restore the SSP to the new farm

  1. On the SharePoint Central Administration Web site, on the Operations page, in the Backup and Restore section, click Restore from backup.

  2. On the Select Backup Location page, in the Backup File Location section, specify UNC path of the backup folder that contains the SSP that you want to move, and then click OK.

  3. On the Select Backup Package to Restore page, select the backup file that you want to use to restore, and then click Continue Restore Process.

  4. On the Select Component to Restore page, select the SSP you want to restore, and then click Continue Restore Process.

  5. On the Select Restore Options page:

    1. In the Restore Component section, verify that the SSP that you selected is displayed.

    2. In the Restore Options section, select Same configuration.

      A message is displayed that notifies you that the current farm will be overwritten. Click OK.

    3. In the New Names section, type new names and URLs for each component, or accept the default values.

  6. Click OK.

Important Important:

Membership in the Farm Administrators SharePoint group is the minimum required to complete the following procedure.

The following procedure is to be performed on the farm to which you are moving the SSP.

Restore SSP associations and configure the SSP

  1. On the SharePoint Central Administration Web site, on the Application Management page, in the Office SharePoint Server Shared Services section, click Create or configure this farm's shared services.

  2. On the Manage This Farm's Shared Services page, click Restore SSP.

  3. In the SSP Name section, type a name for the restored SSP, and then on the Web application list, click the Web application that you want to host the administration site for the restored SSP.

    If you want to create a new Web application to host the administration site for the restored SSP, click Create a new Web application. For more information about how to create Web applications, see Create or extend a Web application (Windows SharePoint Services).

    The SSP Administration Site URL box is automatically populated with the URL of the administration site.

  4. In the SSP Service Credentials section, type the user name and password that will be used by SSP Web services for communications between servers and for the Windows SharePoint Services Timer service when it runs timer jobs in the SSP.

  5. In the SSP Database section, type the name of the database server or use the default (recommended), and then type the name of the database.

    Under Database authentication, select one of the following:

    • Windows authentication (recommended)

    • SQL authentication. If you select this, type the account credentials in the Account and Password boxes.

  6. In the Search Database section, type the name of the database server or use the default (recommended), and then type the name of the search database.

    Under Database authentication, select one of the following:

    • Windows authentication (recommended)

    • SQL authentication. If you select this, type the account credentials in the Account and Password boxes.

  7. In the Index Server section, do the following:

    1. Click an index server on the Index Server list, or use the default.

    2. Type the path of the index server that will be used by the restored SSP to crawl content, or use the default.

      Note Note:

      Changing the index server does not move the index. To move an index, you must use the Stsadm command-line tool.

  8. If you want to use Secure Sockets Layer (SSL) to protect communications to and from Web services, in the SSL for Web Services section, select Yes.

  9. Click OK.

Important Important:

Membership in the Administrators group on the local computer is the minimum required to complete the following procedure.

Before deleting the original SSP, be sure that the new SSP is running correctly and that all content was transferred.

Perform the following procedure on the farm from which you are moving the SSP.

Delete the original SSP

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. Type the following command, and then press ENTER:

    stsadm-o deletessp-title<SSP name>-deletedatabases-force

    For more information, see Deletessp: Stsadm operation (Office SharePoint Server).

See Also

Concepts

Move to another farm (Search Server 2008)
Move all databases (Search Server 2008)
Move content databases (Search Server 2008)


Maintaining databases (Search Server 2008)
DropDown image

Updated: 2008-08-07

This section describes ways that you can help improve the performance, reliability, and scalability of SharePoint Products and Technologies databases by using some easily-applied planning, deployment, and maintenance practices.

A correctly planned and configured database farm is important to the optimal performance and reliability of Microsoft Search Server 2008. After the farm is operating, regular database maintenance such as defragmenting drives, managing file sizes, and balancing loads can help the databases to grow as necessary without impeding performance. Moving databases, often a necessary part of an equipment upgrade or service expansion, must be performed without data loss and with minimal downtime.

Before beginning any database maintenance, ensure you have read and understand the requirements and restrictions given in the following articles:

  • Web Site and SQL Server Events (Office SharePoint Server)

  • Database permissions (Office SharePoint Server)

  • Database types and descriptions (Office SharePoint Server)

Task Requirements

The following requirements apply to many database maintenance operations:

  • Whenever a database is manipulated, such as creating, moving, or merging databases, correct SQL Server permissions must be granted to the account that is performing the task. Some operations require that the account have membership in the dbcreator fixed database role.

  • The account that uses the Stsadm command-line tool must be a member of the Administrators group on the local computer.

  • Some database maintenance, such as moving, requires that the databases be stopped. Be sure to perform these tasks during periods of low usage and provide sufficient notice to all users.

  • Before beginning any database maintenance, ensure that the data backups are current.

  • Whenever possible, observe the following database limitations:

    • Databases should not exceed 100 gigabytes (GB). If a database is approaching this limit, consider splitting the database and moving some content to another database or server.

    • Databases perform best when they contain data that is accessed in similar ways. For example, a database that contains a read-write site collection and a read-only site collection may not perform as well as a database that contains only read-write site collections.

    • To avoid bottlenecks, avoid combining resources that are likely to be accessed at the same time into the same database.

To maintain databases, you can perform the following procedures:

  • Add, split, and merge content databases (Search Server 2008)

    Offers step by step procedures to help manage content databases to meet changing demands.

  • Move content databases (Search Server 2008)

    Contains procedures for moving databases as part of an upgrade, recovery process, or deployment to a new farm.

  • Move all databases (Search Server 2008)

    Lists the steps for moving all of the Search Server 2008 databases from one database server to another database server within the same farm

See Also

Concepts

Operations for Search Server 2008
Protecting and restoring the farm (Search Server 2008)
Move and migrate servers and server farms (Search Server 2008)


Add, split, and merge content databases (Search Server 2008)
DropDown image

Updated: 2008-08-07

Rather than rely on Microsoft Search Server 2008 to manage content databases automatically, you can manually associate databases with a Web application, merge existing databases, or split existing databases.

Some reasons why you might want to add, split, and merge databases for a Web application include:

  • Some site collections within a database that hosts multiple site collections are growing faster than expected, and you expect the database to approach its size limit quickly. You can split the database to move the growing site collections to another database or even another server.

  • A database is smaller than expected and it is convenient to combine several site collections into one database to help with load balancing.

  • Databases perform best when they contain data that is accessed in similar ways. For example, a database that contains a read-write site collection and a read-only site collection may not perform as well as a database that contains only read-write site collections.

  • To help maintain peak performance of your databases, we recommend that the number of data files should be less than or equal to the number of core CPUs.

Task Requirements

The following is required to perform the procedures for this task:

  • To use the Stsadm command-line tool, you must be a member of the Administrators group on the source server computer and the destination server computer.

  • To add a database, you must be a member of the dbcreator fixed server role on the destination server running SQL Server 2005 server or SQL Server instance.

  • Read and understand the requirements and recommendations outlined in Physical storage recommendations (Office SharePoint Server).

To add a content database, see Add a content database (Search Server 2008).

To split a content database, see Move site collections to a new database (split a content database) (Search Server 2008)

To merge a content database, see Merge content databases (Search Server 2008)

See Also

Concepts

Maintaining databases (Search Server 2008)
Move content databases (Search Server 2008)
Move all databases (Search Server 2008)


Add a content database (Search Server 2008)
DropDown image

Updated: 2008-08-07

You can use the following procedures to add a new content database to a server.

Add a database to a Web application

In the user interface, use this procedure to create a new database and assign it to a SharePoint Web application.

Before you begin, check that you know the name of the database server used for the farm you are connecting to.

Important Important:

The account used to restore the databases must be a member of the Administrators group on the local computer and the SQL Server dbcreator fixed server role to complete the following procedure.

Add a database to a Web application by using the user interface

  1. Start the SharePoint Central Administration Web site.

  2. On the Application Management page, in the SharePoint Web Application Management section, click Content databases.

  3. On the Manage Content Databases page, click Add a content database.

  4. On the Add Content Database page:

    1. Select a Web application for the new database.

    2. Select a database server to host the new database.

    3. Specify the authentication method the new database will use and supply an account name and password if necessary.

    4. Specify both the total number of top-level sites that can be created in the database and the number at which a warning will be issued.

  5. Click OK.

Use the following procedure to create a new database and assign it to a SharePoint Web application by using the Stsadm command line tool.

Important Important:

You must be a member of the Administrators group on the local server computer and the SQL Server dbcreator fixed server role to complete the following procedure.

Add a database to a Web application by using the Stsadm command line tool

  1. At a command prompt on the drive where SharePoint Products and Technologies is installed, change to the following directory:

    %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\Bin

  2. Type the following command, and then press ENTER:

    Stsadm -o addcontentdb -url<URL name>-databasename<database name>

    where URL name is the URL of the Web application to which the content database is being added and database name is the name of the database that you want to add.

    For more information, see Addcontentdb: Stsadm operation (Office SharePoint Server).

See Also

Concepts

Add, split, and merge content databases (Search Server 2008)
Move site collections to a new database (split a content database) (Search Server 2008)
Merge content databases (Search Server 2008)


Move site collections to a new database (split a content database) (Search Server 2008)
DropDown image

Updated: 2009-05-14

Some site collections within a database that hosts multiple site collections are growing faster than expected, and you expect the database to approach its size limit quickly. You can split the database to move the growing site collections to another database or to another server.

Split a content database

You can use this procedure to split a content database that is associated with your site collections. The process of moving a site collection between databases consists of exporting the site collection URL data to a file and then importing the data to a new database.

Important Important:

We recommend that you install the April Cumulative Update before you split content databases. This update fixes known issues with the Stsadm mergecontentdbs operation. For more information, see Deploy software updates for Office SharePoint Server 2007.

Before you use the Stsadm mergecontentdbs operation, make sure that there is free space available on the hard disk that is equal to at least three times the size of the source site collection. To determine the size of the site collection, refer to the StorageUsedMB attribute of the Stsadm enumsites operation in step 2 of the following procedure.

To complete the following procedure, you must be a member of both the Farm Administrators group and the Administrators group on the local computer. You must have Full Control permission for any site collection that needs to be moved. The account that you use to perform this procedure must be a member of the db_owner fixed database role in SQL Server.

Split a content database (move a site collection to a different database)

  1. At a command prompt on the drive where SharePoint Products and Technologies is installed, change to the following directory:

    %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin

  2. Type the following command, and then press ENTER:

    Stsadm -o enumsites -url<URL><path/file name>.xml

    where url is the address of the Web application that contains the site collection that you want to move, and path/file name is the name of the XML file that you want to create with the site collection data.

    For more information, see Enumsites: Stsadm operation (Office SharePoint Server).

    The previous step creates an XML file that contains all of the site collection URLs in the current database.

  3. Open the XML file that you created in a text editing application. If there are any URLs for site collections that you do not want to move, be sure to delete them from the file. The only URLs that should remain in the XML file should be for the site collections that you want to move.

    Note Note:

    There is no need to change the site count or any of the other site collection information in the file. Only the URLs are relevant to this procedure.

  4. Type the following command, and then press ENTER:

    Stsadm -o mergecontentdbs -url<URL>-sourcedatabasename<database name>-destinationdatabasename<database name>-operation 3 -filename<file name>

    where url is the address of the Web application that contains the site collection that you want; sourcedatabasename is the name of the database that you want to move the site collection from; destinationdatabasename is the name of the database that you want to move the site collection to; operation 3 is the "Read from file" operation; and file name is the name of the file that contains the site collection URLs that you want to move.

    For more information, see Mergecontentdbs: Stsadm operation (Office SharePoint Server).

  5. Restart IIS by typing the following command, and then pressing ENTER:

    iisreset /noforce

See Also

Concepts

Add, split, and merge content databases (Search Server 2008)
Add a content database (Search Server 2008)
Merge content databases (Search Server 2008)


Merge content databases (Search Server 2008)
DropDown image

Updated: 2009-05-14

You can merge content databases when a database is smaller than expected and it is convenient to combine several site collections into one database to help with load balancing.

Merge content databases

Use the following procedure to merge content databases that are associated with your site collections.

Important Important:

We recommend that you install the April Cumulative Update before you merge content databases. This update fixes known issues with the Stsadm mergecontentdbs operation. For more information, see Deploy software updates for Office SharePoint Server 2007.

Before you use the mergecontentdbs operation within the Stsadm command-line tool, make sure that there is free space available on the hard disk that is equivalent to at least three times the size of the source site collection. To determine the size of your site collection, refer to the StorageUsedMB attribute of the enumsites operation. For more information, see Enumsites: Stsadm operation (Office SharePoint Server).

Important Important:

To complete the following procedure, you must be a member of both the Farm Administrators group and the Administrators group on the local computer. You must have Full Control permission for any site collection that needs to be moved. The account that you use to perform this procedure must be a member of the db_owner fixed database role in Microsoft SQL Server.

Merge two or more site collection databases

  1. At a command prompt on the drive where SharePoint Products and Technologies is installed, change to the following directory:

    %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin

  2. Type the following command, and then press ENTER:

    Stsadm -o mergecontentdbs -url<URL>-sourcedatabasename<database name>-destinationdatabasename<database name>-operation 2

    where url is the address of the Web application that contains the site collections that you want to move; sourcedatabasename is the name of the first database that you want to merge; destinationdatabasename is the name of the second database that you want to merge; and operation 2 is the "Full Database Merge" operation.

    For more information, see Mergecontentdbs: Stsadm operation (Office SharePoint Server).

  3. Restart IIS by typing the following command, and then pressing ENTER:

    iisreset /noforce

See Also

Concepts

Add, split, and merge content databases (Search Server 2008)
Add a content database (Search Server 2008)
Move site collections to a new database (split a content database) (Search Server 2008)


Create a custom dictionary (Search Server 2008)
DropDown image

Updated: 2008-10-09

A custom dictionary is a Unicode-encoded file that can be used to specify words that you want the word breaker of the same language to consider as complete words. Custom dictionaries are not provided, by default. To modify the word breaker behavior for more than one language you must create a separate custom dictionary for each language for which you want to modify the word breaker's behavior. You cannot create a custom dictionary for the language-neutral word breaker.

The following table lists the languages and dialects for which Microsoft Search Server 2008 supports custom dictionaries. This table also includes the language code identifier (LCID) and language hex code for each language and dialect.

Note that the first two numbers in the hex code of each language represent the dialect and the last two numbers represent the language. For languages that do not have separate word breakers for separate dialects, the first two numbers in the language hex code are always zeros.

Table 1 - Supported languages

Language / dialect | LCID | Language hex code
Arabic | 1025 | 0001
Bengali | 1093 | 0045
Bulgarian | 1026 | 0002
Catalan | 1027 | 0003
Croatian | 1050 | 001a
Danish | 1030 | 0006
Dutch | 1043 | 0013
English | 1033 | 0009
French | 1036 | 000c
German | 1031 | 0007
Gujarati | 1095 | 0047
Hebrew | 1037 | 000d
Hindi | 1081 | 0039
Icelandic | 1039 | 000f
Indonesian | 1057 | 0021
Italian | 1040 | 0010
Japanese | 1041 | 0011
Kannada | 1099 | 004b
Latvian | 1062 | 0026
Lithuanian | 1063 | 0027
Malay | 1086 | 003e
Malayalam | 1100 | 004c
Marathi | 1102 | 004e
Norwegian_Bokmaal | 1044 | 0414
Portuguese | 2070 | 0816
Portuguese_Braz | 1046 | 0416
Punjabi | 1094 | 0046
Romanian | 1048 | 0018
Russian | 1049 | 0019
Serbian_Cyrillic | 3098 | 0c1a
Serbian_Latin | 2074 | 081a
Slovak | 1051 | 001b
Slovenian | 1060 | 0024
Spanish | 3082 | 000a
Swedish | 1053 | 001d
Tamil | 1097 | 0049
Telugu | 1098 | 004a
Ukrainian | 1058 | 0022
Urdu | 1056 | 0020
Vietnamese | 1066 | 002a

Reasons to use a custom dictionary

Custom dictionaries are used to make the word breaker of a particular language ignore (or not word break) a particular word. To understand whether you need a custom dictionary and what words or entries it should contain, it is helpful to understand the behavior of word breakers.

Word breakers are used by the indexing system to break words into tokens when content is indexed. Word breakers are also used by the query system to break words in a query into tokens. In both cases, if an existing custom dictionary has been created that supports the language and dialect of the word breaker that is being used, the Office Server Search Service determines if the word exists in the custom dictionary before determining whether to use the word breaker for that word. If the word does not exist in the custom dictionary, the word breaker performs its usual actions, which might result in breaking the word into multiple words or tokens. If the word does exist in the custom dictionary, the word breaker does not perform any actions on that word.

The following examples describe typical word breaker behavior and how an entry in the custom dictionary can affect that behavior.

Example 1

A particular word breaker that encounters a word such as IT&T might break the word at the ampersand symbol (&). The result is the words IT and the letter T which the word breaker for most languages would discard as noise words. However, if the word, IT&T, exists in the custom dictionary of the same language as the word breaker that is being used, the word breaker would ignore the word, IT&T. This means that, if a full crawl were being performed, the word would be indexed as IT&T. When a user types a query for the word, IT&T, the word breaker would not break the word. Specifically, queries containing "IT" or "T" would not return search results for documents that do not contain those words but do contain the word "IT&T".

Example 2

Terms like SystemicChemicalNames (SCN) or CAS Numbers can be affected by word-breakers. For example, word breakers typically split single numbers that appear before or after a hyphen or other special character from the rest of the number. An example of a CAS number is 7782-44-7, which is the CAS registry number for oxygen. After word-breaker processing, this word is broken into three separate parts: the numbers 7782, 44, and 7. Adding the SCN and CAS numbers that appear in a corpus to the custom dictionary, for each language in which they apply, enables the system to index the SCN and CAS numbers without breaking them into separate numbers. Because the appropriate word breaker and custom dictionary for the language of the content is used at query time, a user can also include an SCN or CAS number in her query without it being broken into separate parts.

Normalizations and thesaurus files

Named entity normalizations, such as date normalization, that are normally applied by word breakers are not applied to query terms that appear in custom dictionaries. Instead all query terms that appear in custom dictionaries are treated as an exact match. This is especially important if you have words or numbers (such as the ones mentioned earlier) in a thesaurus file. For example, if the CAS number, 7782-44-7, is part of an expansion set in the thesaurus and the word breaker splits that number at the hyphens into three separate numbers, then the expansion set that the number is a part of might not work as expected. In this case, adding the CAS number, 7782-44-7, to the custom dictionary of the appropriate language resolves the problem.

Before you begin

Creating or modifying a custom dictionary is simple. A custom dictionary is simply a Unicode-formatted file with entries (the words you specify) on separate lines separated by a carriage return (CR) and line feed (LF). When adding entries to a custom dictionary, keep the following rules in mind to avoid experiencing unexpected results:

  • Entries are not case sensitive.

  • The pipe (|) character cannot be used anywhere in a custom dictionary.

  • White space cannot be used anywhere in a custom dictionary.

  • The pound sign (#) character cannot be used at the beginning of an entry but it can be used within or at the end of an entry.

  • Except for the pipe, pound sign, and white space characters mentioned earlier, any alphanumeric characters, punctuation, symbols, and breaking characters are valid.

  • The maximum length of an entry is 128 (Unicode) characters.

The following table shows examples of supported and unsupported entries.

Table 2 - Examples of supported and unsupported entries

Supported | Not supported
dogfood | dog food
3# | #3
Four#sale | dog|food
ASP.NET |
IT&T |
(2-Methoxymethylethoxy)propanol |
34590-97-8 |
C7H1603 |

There is no fixed limit to the number of entries in a custom dictionary but we recommend that the total file size of a custom dictionary does not exceed 2 GB. In practice, we suggest that you limit the number of entries to a few thousand.

Creating a custom dictionary

Before you create a custom dictionary, make sure you have read the Before you begin section earlier in this article because it is important to understand the difference between supported and unsupported entries in a custom dictionary.

Note Note:

To perform this procedure, you must be a member of the Administrators group on the index server and each query server in the server farm.

To create a custom dictionary

  1. Log on to the index server as a member of the Administrators group.

  2. Start Notepad and type the words you want in your custom dictionary. Be sure to avoid invalid entries as described in the Before you begin section.

    Tip Tip:

    Remember that each word must be on a separate line and separated by a carriage return (CR) and line feed (LF).

  3. On the File menu, click Save As.

  4. In the Save as type list, select All Files.

  5. In the Encoding list, select Unicode.

  6. In the File name box, type the file name in the following format: CustomNNNN.lex, where NNNN is the language hex code of the language for which you are creating the custom dictionary. See Table 1, earlier in this article for a list of valid file names for supported languages and dialects.

  7. In the Save in list, navigate to the folder that contains the word breakers. By default, this is drive:\program files\Microsoft Office Servers\12\bin, where drive is the drive letter on which Search Server 2008 is installed.

  8. Click Save.

    Perform the following procedure only if you have query servers that are separate from the index server. Otherwise, go to Stop and restart the Office SharePoint Server Search Service.

Copy the custom dictionary to other servers

  1. Log on to the index server as a member of the Administrators group.

  2. Navigate to the folder in which you saved the custom dictionary file.

  3. Copy the custom dictionary file to the folder that contains the word breakers on your first query server. By default, this is drive:\program files\Microsoft Office Servers\12\bin, where drive is the drive letter on which Search Server 2008 is installed.

  4. Perform a full crawl of the affected content. For information about performing a full crawl, see Crawl content (Search Server 2008).

  5. Repeat steps 1 through 3 on each query server in the server farm.

Stop and restart the Office SharePoint Server Search Service

You must restart the OSearch Service on the index server and all query servers.

Important Important:

Do not use the Services on Server page in Central Administration to stop and start these services because doing so removes the service and deletes the index and associated configuration. Instead, use the following steps.

To stop and restart the Office SharePoint Server Search service

  1. Log onto the index server as a member of the Administrators group.

  2. On the Start menu, point to All Programs, point to Administrative Tools, and then click Services.

  3. Scroll down the list, right-click the Office SharePoint Server Search service, and then click Properties. The properties page appears.

  4. Click Stop. After the service is stopped, click Start.

  5. Ensure that the Startup Type is not set to Disabled.

  6. If your server farm has query servers that are separate from the index server, repeat steps 1 through 5 on each query server.

Perform a full crawl

To apply the custom dictionary to the content index, you must perform a full crawl of all content sources that contain the words that you added to the custom dictionary. For information about performing a full crawl, see Crawl content (Search Server 2008).


Security and protection for Search Server 2008
DropDown image

Updated: 2009-08-10

In this section:

  • Security considerations for search (Search Server 2008) — Learn about security trimming and how to exclude content from a crawl so that users get only the search results that they are authorized to view.

  • Security for federation (Search Server 2008) — Learn about security best practices for federated search, including information about authentication types and security trimming.

  • Add or remove a search services administrator (Search Server 2008) — Learn how to become a search services administrator to configure the Shared Services Provider (SSP) settings and access the Search Administration page in Microsoft Search Server 2008.

  • Change passwords for administration accounts and service accounts (Search Server 2008) — Learn how to change the passwords for services, application pool identities, the SSP, the content access account, and more.

  • Configure SSL certificate warning (Search Server 2008) — Learn how to configure Secure Sockets Layer (SSL) certificate warnings on trustworthy sites.

  • Remove URLs from search results (Search Server 2008) — Learn how to exclude specific URLs from being displayed in search results.


Security considerations for search (Search Server 2008)
DropDown image

Updated: 2008-10-09

Microsoft Search Server 2008 uses a technique, sometimes called security trimming, to ensure that users do not see content or links to content that they do not have permissions to view. However, when using either the Office SharePoint Server Search or Windows SharePoint Services Help Search service to perform search queries, certain conditions can exist in which users might see links to content that they do not have permission to access. While they will not be able to use the link on the search results page to view the content, the links that appear on the search results page might be accompanied by text that discloses information the users should not see. This article describes the conditions in which this can occur and how to avoid them.

Sharing data across Web parts

When sharing data between Web parts, to avoid the risk of disclosing information that users should not see in search results pages, we recommend that you do not use fine-grained permissions. Instead, set permissions only at the site or site collection level and do not share data with a Web part that is contained by a page that has different permissions than any of the data being shared.

Note Note:

Permissions can be set at the site, list and library, or item levels.

If you must use fine grained permissions, do not share data between Web parts. If this cannot be avoided either, do not crawl this content. See the following section for information about excluding content from being crawled.

If you have already crawled the content, consider removing it from the index.

Exclude content from a crawl

Site owners and designers can exclude content from being crawled that may pose an information disclosure risk in any of the following ways:

  • Designers can add the <META NAME="ROBOTS" CONTENT="NOHTMLINDEX"/> element manually to all pages that they don't want the index server to crawl.

  • At the site level, use the Search Visibility page (accessed through the Site Settings page) to prevent the index server from crawling a particular site. You can optionally use this page to specify one of the following:

    • Do not index ASPX pages if this site contains fine-grained permissions

    • Always index all ASPX pages on this site

    • Never index any ASPX pages on this site

  • At a list or library level, use the following procedure to specify that content in a list or library does not appear in search results.

    Exclude content from a list or library from search results

    1. In the list or library that contains content that you do not want to appear in search results, on the Settings menu, click <Library type> Library Settings or List Settings.

    2. In the General Settings section, click Advanced Settings.

    3. In the Search section, select No and then click OK.


Security for federation (Search Server 2008)
DropDown image

Updated: 2008-10-09

This article explains the security best practices for the Federation feature of Microsoft Search Server 2008. It should be read by information technology professionals as well as system architects and search services administrators.

Search Federation Overview

Federated search enables end users to issue one query that can query one or more search engines that are compliant with Open-search 1.1 and display results from each search engine in a separate Web Part on a single search results page. These sources can be enterprise content repositories, other search engines, or portions of your content index. For more information about Search Federation, see Federated Search Overview (http://go.microsoft.com/fwlink/?LinkId=122651) and Working with federation (Search Server 2008).

Authentication Types

Several types of user authentication, per-user and common credentials, are available for Federated search. It is important to note, however, that collecting credentials requires a Web Part extension for non-Kerberos authentication types in per-user authentication. In the authentication and credentials information section of the location definition, you specify the authentication type for the federated location. The authentication type can be one of the following:

  • Anonymous

    No credentials are required to connect to the federated location.

  • Common

    Each connection uses the same set of credentials to connect to the federated location.

  • Per-user

    The credentials of the user who submitted the search query are used to connect to the federated location.

For the common and per-user authentication types, you must also specify one of the following authentication protocols:

  • Basic

    Basic authentication is part of the HTTP specification and is supported by most browsers.

    Security note Security Note:

    Web browsers that use Basic authentication transmit passwords in an unencrypted form. By monitoring communications on your network, a malicious user can use publicly available tools to intercept and decode these passwords. Therefore, Basic authentication is not recommended unless you are confident that the connection is secure, such as with a dedicated line or a Secure Sockets Layer (SSL) connection.

  • Digest

    Digest authentication relies on the HTTP 1.1 protocol as defined in the RFC 2617 specification at the World Wide Web Consortium (W3C) Web site. Because Digest authentication requires HTTP 1.1 compliance, some browsers do not support it. If a browser that is not compliant with HTTP 1.1 requests a file when Digest authentication is enabled, the request is rejected because Digest authentication is not supported by the client. Digest authentication can be used only in Windows domains. Digest authentication works with Microsoft Windows Server 2008, Microsoft Windows Server 2003, and Microsoft Windows 2000 Server domain accounts only, and may require the accounts to store passwords as encrypted plain text.

  • NTLM

    User records are stored in the security accounts manager (SAM) database or in the Active Directory database. Each user account is associated with two passwords: the LAN Manager-compatible password and the Windows password. Each password is encrypted and stored in the SAM database or in the Active Directory database.

  • Kerberos (per-user authentication type only)

    By using the Kerberos protocol, a party at either end of a network connection can verify that the party on the other end is the entity it claims to be. Although NTLM enables servers to verify the identities of their clients, NTLM does not enable clients to verify a server's identity, nor does NTLM enable one server to verify the identity of another. NTLM authentication is designed for a network environment in which servers are assumed to be trusted.

  • Forms

    A forms authentication cookie is nothing but the container for a forms authentication ticket. Each request passes the ticket as the value of the forms-authentication cookie and is used by forms authentication, on the server, to identify an authenticated user. However, cookieless forms authentication passes the ticket in the URL in an encrypted format. Cookieless forms authentication is used because client browsers might block cookies. This feature is introduced in the Microsoft .NET Framework 2.0.

Security trimming in Federated search

An important consideration to evaluate when using Federated search is security trimming of search results. Security trimming is a method by which returned results are filtered based on user account permissions. By default, security trimming of search results persists for results returned by the following:

  • Local farm

    In scenarios where the federated location is an Open Search location and the location is configured for per-user authentication, a user's credentials are automatically passed if Kerberos authentication is being used. However, user credentials are not passed automatically for authentication protocols other than Kerberos. To ensure that results are security trimmed for the current user for these scenarios, extend the Federated Results Web part to collect user credentials. For more information, see Creating a Custom Federated Search Web Part with a Credentials UI (http://go.microsoft.com/fwlink/?LinkId=122653).

  • If Kerberos authentication is not used, you also need to extend the Federated search Web parts to collect user credentials if you want to ensure that search results for OpenSearch locations (all locations other than the local farm) are security trimmed for each user.

For more information about Security for Search Server 2008, see Security and protection for Search Server 2008 and Security considerations for search (Search Server 2008).


Add or remove a search services administrator (Search Server 2008)
DropDown image

Updated: 2008-03-03

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

If you are familiar with user groups in Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0, you are probably familiar with the role of a shared services administrator. A shared services administrator can control the services included in the Shared Services Administration Web site, otherwise known as Shared Services Provider (SSP). However, Microsoft Search Server 2008 has only one SSP. Therefore, the role of a shared services administrator is replaced by a search services administrator in Search Server 2008.

A search services administrator can configure SSP settings and access the Search Administration page in Search Server 2008. On the Search Administration page, a search services administrator can change settings for Content Sources, Crawl Rules, Scopes, Authoritative Pages, Federated Locations or Managed Properties, and Usage Reports.

Adding a search services administrator

When you deploy Search Server 2008, you are automatically designated the primary site collection administrator of the SharePoint Central Administration Web site, the SSP, and the site collections in the server farm. By using these permissions, you can add a secondary site collection administrator and grant users site collection administrator permissions to the SSP, site collections, and sites in the farm.

Adding a secondary site collection administrator

A system administrator who has deployed the server farm or system administrators who have permissions only to the Central Administration Web site (who are not site collection administrators) can add a secondary site collection administrator.

The following procedure describes how to add a secondary site collection administrator.

Add a secondary site collection administrator

  1. In Central Administration, click the Application Management tab.

  2. On the Application Management page, under SharePoint site management, click Site collection administrators.

  3. In the Site Collection Administrators page, select a site collection that ends with /ssp/admin in the Site Collection list.

    Note Note:

    If the site collection for the SSP is not visible, click Change Site Collection in the Site Collection list. In the Select Site Collection window, click Change Web Application in the Web Application list, and then click the link that ends with /ssp/admin in the Name column. In the Select Site Collection window, click /ssp/admin in the URL column, and then click OK.

  4. In the Primary site collection administrator box, you can see the name of the system administrator who has set up the farm. Change the name of the user, if necessary.

  5. In the Secondary site collection administrator box, type the name of the user that you want to add as the secondary site collection administrator.

  6. Click OK.

Adding a search services administrator

The following procedure describes how to grant users site collection administrator permissions on the SSP Web site.

Note Note:

You must have site collection administrator permissions on the SSP Web site to perform this procedure.

Add a search services administrator

  1. On the Search Administration page, click Site Actions, and then click Site Settings.

  2. On the Site Settings page, under Users and Permissions, click Site collection administrators.

  3. On the Site Collection Administrators page, under Site Collection Administrators, type the name of the user that you want to add as a site collection administrator.

    Note Note:

    When adding more users to the list, use a semicolon (;) after each user's name.

  4. Click OK.

Removing a search services administrator

The following procedure describes how a search services administrator can be removed from the SSP.

Remove a search services administrator

  1. On the Search Administration page, click Site Actions, and then click Site Settings.

  2. On the Site Settings page, under Users and Permissions, click Site collection administrators.

  3. On the Site Collection Administrators page, under Site Collection Administrators, delete the name in the list.

  4. Click OK.

See Also

Concepts

Security and protection for Search Server 2008
Change passwords for administration accounts and service accounts (Search Server 2008)


Change passwords for administration accounts and service accounts (Search Server 2008)
DropDown image

Updated: 2009-05-22

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Use the procedures in this task to change the passwords for services, application pool identities, and accounts used in Search Server 2008. Domain policies often require that domain account passwords be updated periodically. This change provides additional security in case a password becomes compromised. You can configure each service, application pool identity, and account of Search Server 2008 to run as domain accounts. Because domain policy might require passwords to expire regularly, you might have to change passwords for search-related user accounts for search to continue to function properly.

Important Important:

If the service, feature, or application pool is running as a built-in account, such as Network Service, the password does not expire and therefore does not need to be updated.

The passwords will need to be updated only if they are running under a domain account and domain policies require passwords to be updated.

Passwords for the following must be updated after the passwords are changed on the domain controller:

  • SQL Server (MSSQLSERVER) service

  • SQL Server Agent (MSSQLSERVER) service

  • SQL Server Full Text Search (MSSQLSERVER) service

    Note Note:

    The SQL Server services listed above are installed if the installation of Search Server uses Microsoft SQL Server 2005 or Microsoft SQL Server 2008.

  • SQL Server (OFFICESERVER) service

    Note Note:

    This service is installed only if the Search Server installation uses Microsoft SQL Server 2005 Express or Microsoft SQL Server 2008 Express.

  • SharePoint Central Administration v3 application pool account

  • Office SharePoint Server Search service

  • The content access account for the Windows SharePoint Services Search service

  • The content access account for the Office SharePoint Server Search service

  • Windows SharePoint Services Search service

  • Shared Services Provider application pool account

  • Windows SharePoint Services Timer service

  • Application pool identity for Search Server 2008

    Note Note:

    The OfficeServerApplicationPool identity runs as the Network Service account and will not to have to be changed.

Procedures to change passwords for administrative accounts and service accounts

Note Note:

  • Some of the following procedures require that a Web application service or Windows service be restarted. This might cause services or content to be momentarily unavailable to users. Each procedure listed states what must be restarted and the possible impact on users.

  • Each procedure states the level of access required to perform the procedure.

  • These procedures can only be performed after the password has been changed on the domain controller. The credentials entered are checked against those on the domain controller. If you enter the new password before the password has been changed on the domain controller, an error will result and the settings will not be changed.

To change the passwords, perform the following procedures:

  • Change passwords for SQL Server services (Search Server 2008)

  • Change passwords for Central Administration and the Timer service (Search Server 2008)

  • Change passwords for the Search service accounts (Search Server 2008)

  • Change the password for the content access account (Search Server 2008)

  • Change the password for the Shared Services Provider (Search Server 2008)

  • Change the password for an application pool identity (Search Server 2008)

Note Note:

If Microsoft Search Server 2008 is installed in a least-privilege configuration, use one of the following methods to enable the password to be changed:

  • To change the password by using the Central Administration Web site, use the Services MMC snap-in to start the Windows SharePoint Services Administration (SPAdmin) service on all computers in the farm that are running Search Server before you update the password. Stop the SPAdmin service when the password update is complete.

  • To change the password by using the Stsadm command-line tool, add the server farm account (also known as the database access account) to the Administrators group on each computer that has the query server role enabled. Log on using that account, and then use the Stsadm operation to update the password. When the password update is complete, remove the database access account from the Administrators group on each computer.

See Also

Concepts

Change the default content access account (Search Server 2008)


Change passwords for SQL Server services (Search Server 2008)
DropDown image

Updated: 2009-05-22

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Use the procedures in this article to change the passwords for the following services if the corresponding domain account password has been changed and the Microsoft Search Server 2008 or Microsoft Search Server 2008 Express deployment is using Microsoft SQL Server 2005 or Microsoft SQL Server 2008:

  • SQL Server (MSSQLSERVER) service Used to run SQL Server. If the service is using a domain account, SQL Server will not run if the domain account password expires.

  • SQL Server Agent (MSSQLSERVER) service Used by Search Server 2008 to truncate residual session state information that can accumulate and affect SQL Server performance. It is also used by various other applications. If the service is using a domain account, these applications cannot run tasks in SQL Server if the domain account password expires.

Use the following procedure to change the password for the following service if the corresponding domain account password has been changed and the Microsoft Search Server 2008 or Microsoft Search Server 2008 Express deployment is using Microsoft SQL Server 2005 Express Edition or Microsoft SQL Server 2008 Express:

  • SQL Server (OFFICESERVERS) service Used to run SQL Server Express. If the service is using a domain account, SQL Server will not run if the domain account password expires. Note that this service uses the Network Service account by default.

Note Note:

  • These procedures can be performed only after the password has been changed on the domain controller. The credentials entered are checked against those on the domain controller. If you enter the new password before the password has been changed on the domain controller, an error will result and the settings will not be changed.

  • To save the changes, you must restart the SQL Server service. This will cause the services that the SQL Server service provides to be momentary unavailable while the SQL Server service restarts.

  • Microsoft SQL Server services accounts and passwords are linked to Microsoft Windows user accounts and passwords. Changes in one location might require changes in the other.

Important Important:

  • You should not change the passwords for any of the SQL Server service accounts when a failover cluster node is offline. If you have to do this, you will need to reset the password again by using SQL Server Configuration Manager when all nodes are back online.

  • Membership in the Administrators group on the local computer, or equivalent, is required to complete the following procedures.

To change passwords for SQL Server services

Change the password for the SQL Server (MSSQLSERVER) service

  1. On the Start menu, select Administrative Tools, and then click Services. In Services, locate and right-click the SQL Server (MSSQLSERVER) service, and then click Properties.

  2. In the Properties dialog box, on the Log On tab, type the new password in the Password box and in the Confirm password box.

  3. You must restart the service to save the changes. On the General tab, under Service status, click Stop to stop the service.

  4. When the service has stopped, click Start to start the service.

  5. Click OK to save the changes.

Change the password for the SQL Server Agent (MSSQLSERVER) service

  1. On the Start menu, select Administrative Tools, and then click Services. In Services, locate and right-click the SQL Server Agent (MSSQLSERVER) service, and then click Properties.

  2. In the Properties dialog box, on the Log On tab, type the new password in the Password box and in the Confirm password box.

  3. You must restart the service to save the changes. On the General tab, under Service status, click Stop to stop the service.

  4. When the service has stopped, click Start to start the service.

  5. Click OK to save the changes.

Change the password for the SQL Server (OFFICESERVERS) service

  1. On the Start menu, select Administrative Tools, and then click Services. In Services, locate and right-click the SQL Server (OFFICESERVERS) service, and then click Properties.

  2. In the Properties dialog box, on the Log On tab, type the new password in the Password box and in the Confirm password box.

  3. You must restart the service to save the changes. On the General tab, under Service status, click Stop to stop the service.

  4. When the service has stopped, click Start to start the service.

  5. Click OK to save the changes.

See Also

Concepts

Change passwords for administration accounts and service accounts (Search Server 2008)
Change passwords for Central Administration and the Timer service (Search Server 2008)
Change passwords for the Search service accounts (Search Server 2008)
Change the password for the Shared Services Provider (Search Server 2008)
Change the password for the content access account (Search Server 2008)
Change the password for an application pool identity (Search Server 2008)


Change passwords for Central Administration and the Timer service (Search Server 2008)
DropDown image

Updated: 2009-05-22

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Use the appropriate procedure in this article to change passwords for the application pool for the Central Administration Web site and the Windows SharePoint Services Timer service. The application pool and the Timer service store the credential information and continue to function even after the password has expired. However, if the application pool or the Timer service restarts, the stored credential information is lost, and the application pool or the Timer service cannot be started until the credential information is updated.

If the application pool cannot start, a "Service Unavailable" HTTP error will be displayed to the users of any Web pages or services that the Web application provides. If the Timer service cannot start, timer jobs will not be completed. This will cause a variety of failures.

Note Note:

  • These procedures can be performed only after the password has been changed on the domain controller. The credentials entered are checked against those on the domain controller. If you enter the new password before the password has been changed on the domain controller, an error will result and the settings will not be changed.

  • To save the changes, you must restart the application pool and the Timer service. This will cause the content or services that they provide to be momentarily unavailable while the application pool and the Timer service restart.

  • There is no graphical user interface for these procedures. You must use the command line to perform these password changes. Do not attempt to change the passwords using Windows Service Manager.

Important Important:

Membership in the Administrators group on the local computer is required to complete the following procedures. Membership in the Farm Administrators group is not sufficient to complete these procedures.

To change the passwords if you have access to Central Administration

Change the passwords for the Central Administration application pool identity and the Windows SharePoint Services Timer service by using the command line

  1. On the computer running the Central Administration Web site, at a command prompt, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. Type the following command, and then press ENTER:

    stsadm -o updatefarmcredentials -userlogin <domain\username> -password <newpassword>

    Note Note:

    userlogin is the server farm account.

    For additional information, see Updatefarmcredentials: Stsadm operation (Office SharePoint Server).

  3. You must restart IIS to save the changes. At a command prompt, type the following command, and then press ENTER:

    iisreset /noforce

To change the passwords if you receive a "Service Unavailable" error when trying to access Central Administration

Change the passwords for the Central Administration application pool identity and the Windows SharePoint Services Timer service by using the command line

  1. On the computer running the Central Administration Web site, at a command prompt, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. Type the following command, and then press ENTER:

    stsadm -o updatefarmcredentials -userlogin <domain\username> -password <newpassword>

    Note Note:

    userlogin is the server farm account.

    For additional information, see Updatefarmcredentials: Stsadm operation (Office SharePoint Server).

  3. You must restart IIS to save the changes. At a command prompt, type the following command, and then press ENTER:

    iisreset /noforce

  4. On every other server in the farm, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  5. At a command prompt, type the following command, and then press ENTER:

    stsadm -o updatefarmcredentials -userlogin <domain\username> -password <newpassword> -local

    Note Note:

    userlogin is the server farm account. You must use the -local switch.

    For additional information, see Updatefarmcredentials: Stsadm operation (Office SharePoint Server).

See Also

Concepts

Change passwords for administration accounts and service accounts (Search Server 2008)
Change passwords for SQL Server services (Search Server 2008)
Change passwords for the Search service accounts (Search Server 2008)
Change the password for the Shared Services Provider (Search Server 2008)
Change the password for the content access account (Search Server 2008)
Change the password for an application pool identity (Search Server 2008)


Change passwords for the Search service accounts (Search Server 2008)
DropDown image

Updated: 2009-05-22

Note Note:

The information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

This article explains how to establish or change account credentials (the domain user account and password) for each of the Search services used by Search Server 2008:

  • The Office SharePoint Server Search service. Search Server 2008 uses this service for crawling and indexing enterprise content.

  • The Windows SharePoint Services Search service. Search Server 2008 uses this service for crawling and indexing the product Help content.

Account credentials are used to authenticate the Search services when they connect to SQL Server databases. Each service stores the credential information and continues to function even after a password has expired. However, if there is an attempt to restart the service, the stored credential information is lost, and the service cannot restart until the credential information is updated. If the Office SharePoint Server Search service cannot start, the content indexes cannot be updated and search results are not synchronized.

Note Note:

  • The credentials for a Search service account must match the credentials on the domain controller for the corresponding account.

  • You can change account credentials for the Search services only from a farm server that is hosting the Central Administration Web site. It is not necessary to change the credentials on any other server in the farm.

  • Memberships in the Search Server Farm Administrators group and the Administrators group on the local computer are required to complete each procedure in this article.

In this article:

  • How you establish credentials for the Search service accounts during deployment

  • To change credentials for the Office SharePoint Server Search service by using the user interface

  • To change credentials for the Office SharePoint Server Search service at a command prompt

  • To change credentials for the Windows SharePoint Services Search service by using the user interface

  • To change credentials for the Windows SharePoint Services Search service at a command prompt

How you establish credentials for the Search service accounts during deployment

After you install Search Server on the first computer in a deployment by using the Advanced installation option, the Search Server Configuration page appears. On this page, in the Required section, in the Default Account for Services section, you must specify a domain user account. Search Server uses this account for the Search services and several other services. In the Optional section on the same page, in the Search Service Account section and the Help Search Service Account section, you can specify separate accounts for the Search services if you want to use accounts that differ from the default account for services.

After you complete the fields on the Search Server Configuration page and click OK to accept the settings, you cannot return to that page. However, you can use the following procedures at any time after that to change credentials for the Search service accounts.

To change credentials for the Office SharePoint Server Search service by using the user interface

Note Note:

These procedures can be performed only after the password has been changed on the domain controller. The credentials entered are checked against those on the domain controller. If you enter the new password before the password has been changed on the domain controller, an error will result and the settings will not be changed. To save the changes, you must restart the Search service. This will cause the functionality that it provides to be momentarily unavailable while the Search service restarts.

Use this procedure to change credentials for the Office SharePoint Server Search service by using the user interface.

Change credentials for the Office SharePoint Server Search service by using the user interface

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Services on server.

    On the Services on Server page, a server name appears. For this procedure, any server can be selected in this location, because the Office SharePoint Server Search service account is a setting that applies to the whole farm.

  2. On the Services on Server page, in the Start services in the table below section, click Office SharePoint Server Search.

  3. On the Configure Office SharePoint Server Search Service Settings page, in the Farm Search Service Account section, type the domain user account and password.

    The Office SharePoint Server Search service account cannot be a built-in account, such as Local Service or Network Service.

  4. Click OK.

To change credentials for the Office SharePoint Server Search service by using the Stsadm command-line tool

Use this procedure to change credentials for the Office SharePoint Server Search service at a command prompt.

Change credentials for the Office SharePoint Server Search service by using the Stsadm command-line tool

  1. On a computer that is hosting the Central Administration Web site, open a command prompt and change to the following directory:

    %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin

  2. Type the following command, and then press ENTER:

    stsadm -o osearch -farmserviceaccount domain\username -farmservicepassword password

    Note Note:

    The farmserviceaccount parameter is the Office SharePoint Server Search service account.

    For more information, see Osearch: Stsadm operation (Office SharePoint Server).

To change credentials for the Windows SharePoint Services Search service by using the user interface

Use this procedure to change credentials for the Windows SharePoint Services Search service by using the user interface.

Change credentials for the Windows SharePoint Services Search service by using the user interface

  1. In Central Administration, on the Operations tab, in the Topology and Services section, click Services on server.

    On the Services on Server page, a server name appears. For this procedure, any server can be selected in this location, because the Windows SharePoint Services search service account is a setting that applies to the whole farm.

  2. On the Services on Server page, in the Start services in the table below section, click Windows SharePoint Services Help Search.

  3. On the Configure Windows SharePoint Services Search Settings page, in the Service Account section, type the domain user account and password.

    The Windows SharePoint Services Search service account cannot be a built-in account, such as Local Service or Network Service.

  4. Click OK.

To change credentials for the Windows SharePoint Services Search service by using the Stsadm command-line tool

Use this procedure to change credentials for the Windows SharePoint Services Search service at a command prompt.

Change credentials for the Windows SharePoint Services Search service by using the Stsadm command-line tool

  1. On a computer that is hosting the Central Administration Web site, open a command prompt and change to the following directory:

    %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin

  2. Type the following command, and then press ENTER:

    stsadm -o spsearch -farmserviceaccount domain\username farmservicepassword password

    Note Note:

    The farmserviceaccount parameter is the Windows SharePoint Services Search service account.

    For more information, see Spsearch: Stsadm operation (Windows SharePoint Services).

See Also

Concepts

Security and protection for Search Server 2008
Change passwords for SQL Server services (Search Server 2008)
Change passwords for Central Administration and the Timer service (Search Server 2008)
Change the password for the Shared Services Provider (Search Server 2008)
Change the password for an application pool identity (Search Server 2008)

Other Resources

Index for Stsadm operations and properties (Windows SharePoint Services)
Index for Stsadm operations and properties (Office SharePoint Server)


Change the password for the content access account (Search Server 2008)
DropDown image

Updated: 2009-05-22

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Use this procedure to change the password for the content access account. The content access account is used by the Windows SharePoint Services Search service to crawl content. If the Office SharePoint Server Search service is running, then the Windows SharePoint Services Search service is used only to crawl the product's built-in Help content, not SharePoint content or content external to SharePoint, such as file shares. This account must have read permission for the content that the account is crawling. It is a best practice to limit the account's content access to read-only. If the account password expires and is not updated, this search service will not be able to crawl content.

Note Note:

  • These procedures can be performed successfully only after the password has been changed on the domain controller. The credentials entered are checked against those on the domain controller. If you enter the new password before the password has been changed on the domain controller, an error will result and the settings will not be changed.

  • This procedure needs to be performed only on the server that is running the Central Administration Web site.

Important Important:

Memberships in the Search Server Farm Administrators group and in the Administrators group on the local computer are required to complete each procedure in this article.

To change the password for the content access account

Change the password for the content access account by using the user interface

  1. On the Central Administration Web site, on the Operations tab, in the Topology and Services section, click Services on server.

    On the Services on server page, next to Windows SharePoint Services Search or Windows SharePoint Services Help Search, an entry in the Status column indicates whether the Windows SharePoint Services Search service is Started or Stopped.

  2. Do one of the following, depending on your goal:

    • To change the content access account password when the Windows SharePoint Services Search service is started:

      1. On the Services on Server page, click Windows SharePoint Services Help Search.

      2. On the Configure Windows SharePoint Services Search Services settings page, in the Content Access Account section, do the following:

        • Optional: In the User name box, type a different user name in the form domain_name\user_name. This user name must not be a built-in account such as Local Service or Network Service.

        • In the Password box, type a new password.

      3. Click OK.

    • To change the content access account password when the Windows SharePoint Services Search service is stopped and you want it to remain stopped:

      1. On the Services on Server page, click Windows SharePoint Services Search.

      2. On the Configure Windows SharePoint Services Search Services settings page, in the Content Access Account section, do the following:

        • Optional: In the User name box, type a different user name in the form domain_name\user_name. This user name must not be a built-in account such as Local Service or Network Service.

        • In the Password box, type a new password.

      3. If this is the first time the password has been change since the service was stopped, specify the search database for the Windows SharePoint Services Search service by doing one of the following:

        • Ensure that the search database in use is empty by deleting all associated tables, stored procedures, and other database components.

        • On the Configure Windows SharePoint Services Search Services settings page, in the Search Database section, type the name of an empty database. If the database does not already exist, it is created automatically.

      4. Click OK.

    • To change the content access account password when the Windows SharePoint Services Search service is stopped and you want it to start it:

      1. On the Services on Server page, next to Windows SharePoint Services Search click Start.

      2. On the Configure Windows SharePoint Services Search Services settings page, in the Content Access Account section, do the following:

        • Optional: In the User name box, type a different user name in the form domain_name\user_name. This user name must not be a built-in account such as Local Service or Network Service.

        • In the Password box, type a new password.

      3. If this is the first time the password has been change since the service was stopped, specify the search database for the Windows SharePoint Services Search service by doing one of the following:

        • Ensure that the search database in use is empty by deleting all associated tables, stored procedures, and other database components.

        • On the Configure Windows SharePoint Services Search Services settings page, in the Search Database section, type the name of an empty database. If the database does not already exist, it is created automatically.

      4. Click Start.

Change the password for the content access account by using the Stsadm command-line tool

  1. On the computer that is running the Central Administration Web site, open a command prompt and change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. Type the following command, and then press ENTER:

    stsadm -o spsearch -farmcontentaccessaccount <domain\username> -farmcontentaccesspassword <password>

    Note Note:

    farmcontentaccessaccount is the content access user account.

See Also

Concepts

Change passwords for administration accounts and service accounts (Search Server 2008)
Change passwords for SQL Server services (Search Server 2008)
Change passwords for Central Administration and the Timer service (Search Server 2008)
Change passwords for the Search service accounts (Search Server 2008)
Change the password for the Shared Services Provider (Search Server 2008)
Change the password for an application pool identity (Search Server 2008)


Change the password for the Shared Services Provider (Search Server 2008)
DropDown image

Updated: 2009-05-22

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Use this procedure to change the password for the Shared Services Provider (SSP) service account. This account is used to operate the SSP Web services for inter-server communications and to run the timer jobs for the SSP. These functions will not work properly if the domain account password changes and the password for the SSP service account is not updated accordingly.

Note Note:

  • These procedures can be performed only after the password has been changed on the domain controller. The credentials entered are checked against those on the domain controller. If you enter the new password before the password has been changed on the domain controller, an error will result and the settings will not be changed.

  • To save the changes, you must restart Internet Information Services (IIS). This will cause the services that the application pool provides to be momentarily unavailable while the application pool restarts.

  • This procedure needs to be performed only on the server that is running the Central Administration Web site.

Important Important:

Membership in the Search Server Farm Administrators group, and in the Administrators group on the local computer, is the minimum permission required to complete each procedure in this article.

To change the password for the SSP account

Change the password for the SSP service account by using the user interface

  1. On the Central Administration Web site, on the Quick Launch, click Shared Services Administration.

  2. On the Manage this Farm's Shared Services page, point to the SSP, click the arrow that appears, and then click Edit Properties.

  3. On the Edit Shared Services Provider page, in the SSP Service Credentials section, type the new password in the Password box.

  4. Click OK to save the changes.

  5. At a command prompt, type the following command to restart IIS, and then press ENTER:

    iisreset /noforce

Change the password for the SSP service account by using the Stsadm command-line tool

  1. On the computer that is running the Central Administration Web site, at a command prompt, change to the following directory: %COMMOMPROGRAMFILES%\Microsoft shared\Web server extensions\12\BIN.

  2. Type the following command, and then press ENTER:

    stsadm -o editssp -title <SSP name> -ssplogin <domain\username> -ssppassword <password>

    Note Note:

    By default, <SSP name> is SharedServices.

    ssplogin is the SSP service user account.

    For additional information, see Editssp: Stsadm operation (Office SharePoint Server).

  3. At a command prompt, type the following command to restart IIS, and then press ENTER:

    iisreset /noforce

See Also

Concepts

Change passwords for administration accounts and service accounts (Search Server 2008)
Change passwords for SQL Server services (Search Server 2008)
Change passwords for Central Administration and the Timer service (Search Server 2008)
Change passwords for the Search service accounts (Search Server 2008)
Change the password for the content access account (Search Server 2008)
Change the password for an application pool identity (Search Server 2008)


Change the password for an application pool identity (Search Server 2008)
DropDown image

Updated: 2009-05-22

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Use either procedure in this article to change the password for the application pool identity of a Web application that hosts the Search Center. Because Search Server is built on Windows SharePoint Services, you can create several Web applications. However, typically you will have only one Web application on port 80 that hosts the Search Center site. The application pool is the context in which the Web application runs, and the identity is the account under which the application pool runs. The application pool stores the credential information of the identity account and continues to function even after the password expires. However, if the application pool restarts, the stored credential information is lost, and the application pool cannot restart until the credential information is updated.

If the application pool cannot start, Search Server 2008 displays a "Service Unavailable" HTTP error to users of any Web pages or services that the Web application provides.

Note Note:

  • These procedures can be performed successfully only after the password has been changed on the domain controller. The credentials entered are checked against those on the domain controller. If you enter the new password before the password has been changed on the domain controller, an error will result and the settings will not be changed.

  • To save the changes, you must restart the IIS. This will cause the content or services that the Web application provides to be momentarily unavailable while the application pool restarts.

  • This procedure needs to be run only on the server that is running the Central Administration Web site.

Note Note:

You cannot use these procedures to change the password for the Central Administration Web application. To do this, see Change passwords for Central Administration and the Timer service (Search Server 2008).

To change the password for an application pool identity

Important Important:

Membership in the Search Server Farm Administrators group is the minimum required to complete this procedure by using the user interface.

Change the password for an application pool identity by using the user interface

  1. On the Central Administration Web site, click Operations.

  2. On the Operations page, under Security Configuration, click Service accounts.

  3. On the Service Accounts page, in the Credentials Management section, under Select the component to update, select the Web application pool option.

  4. From the Web service drop-down list, select the service under which the application pool was created. The default is Windows SharePoint Services Web Application.

  5. From the Application pool drop-down list, select the application pool whose credentials you want to update.

  6. Type the new password in the Password box.

  7. Click OK.

  8. Once the new password has been successfully accepted, you will be asked to run the iisreset /noforce command.

    At a command prompt, type the following command, and then press ENTER:

    iisreset /noforce

Note Note:

Memberships in the Search Server Farm Administrators group and in the Administrators group on the local computer are required to complete this procedure.

Change the password for an application pool identity by using the Stsadm command-line tool

  1. On the computer running the Central Administration Web site, at a command prompt, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.

  2. Type the following command, and then press ENTER:

    stsadm -o updateaccountpassword -userlogin <domain\username> -password <newpassword> -noadmin

    Note Note:

    userlogin is the application pool identity account.

    For additional information, see Updateaccountpassword: Stsadm operation (Office SharePoint Server).

  3. At a command prompt, type the following command, and then press ENTER:

    iisreset /noforce

See Also

Concepts

Change passwords for administration accounts and service accounts (Search Server 2008)
Change passwords for SQL Server services (Search Server 2008)
Change passwords for Central Administration and the Timer service (Search Server 2008)
Change passwords for the Search service accounts (Search Server 2008)
Change the password for the Shared Services Provider (Search Server 2008)
Change the password for the content access account (Search Server 2008)


Configure SSL certificate warning (Search Server 2008)
DropDown image

Updated: 2009-04-02

This article was published for an earlier version of this product and is being published without changes for this release. To provide feedback on the content, click the Click to Rate and Give Feedback link at the top of the page.

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Search services administrators can configure the crawler to ignore Secure Sockets Layer (SSL) certificate name warnings that occur when the SSL certificate name does not exactly match the name that was expected. By default, SSL certificate warnings are not ignored. We recommend that you configure the crawler to ignore SSL certificate warnings only if you trust that all sites you crawl using SSL are legitimate.

Note Note:

You must be a search services administrator to perform this procedure. For more information, see Add or remove a search services administrator (Search Server 2008).

Configuring SSL certificate warnings

Use this procedure to configure the SSL certificate warnings.

To configure SSL certificate warnings

  1. On the Search Administration page, in the Crawling section, click Proxy and Timeouts. The Manage Farm-Level Search Settings page appears.

  2. In the SSL Certificate Warning Configuration section, select the Ignore SSL certificate name warnings check box if you want to trust that sites are legitimate even if their certificate names are not exact matches. Otherwise, ensure that the check box is not selected.

  3. Click OK.

See Also

Concepts

Configure proxy settings (Search Server 2008)
Change the contact e-mail address (Search Server 2008)


Remove URLs from search results (Search Server 2008)
DropDown image

Updated: 2008-08-21

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

A search services administrator can exclude specific URLs from being displayed in search results. After a URL is excluded, crawl rules are created to exclude the URLs in future crawls.

Note Note:

Read permission on the Shared Services Provider Administration site collection is the minimum required to complete this procedure.

Removing URLs from search results

Follow this procedure to remove specific URLs from search results.

Remove URLs from search results

  1. On the Search Administration page, under Queries and Results, click Search result removal.

  2. On the Remove URLs from Search Results page, type the fully qualified domain name of the URL that you want to remove from the search results.

  3. Click Remove Now.


Technical reference for Search Server 2008
DropDown image

Updated: 2008-03-03

In this section:

  • Protecting and restoring the farm (Search Server 2008)— See how to create a backup of the server farm and its components, and restore data from the backup.


Registry keys reference (Search Server 2008)
DropDown image

Note Note:

Unless otherwise noted, the information in this article applies to both Microsoft Search Server 2008 and Microsoft Search Server 2008 Express.

Microsoft Search Server 2008 uses registry values to store many configuration values. You can set some of these values in the Central Administration site and you should do so when you can. For example, you should set the ConnectTimeout, DataTimeout and IgnoreCertCNError values by making changes in the Central Administration\Application Management\Search Service\Farm-Level Search Settings page. However, many values can only be set in the registry by using Registry Editor. If you change any of the registry values listed in this article, you must restart the Office SharePoint Server Search service for the changes to take effect. However, if you make registry value changes while the Office SharePoint Server Search service is not running, the changes will be overwritten when the service starts.

Warning Warning:

Do not change any Microsoft Search Server 2008 registry values or keys that are not listed in this article unless advised to do this by Microsoft Support.

Caution Caution:

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. For more information about the registry see the following article: Windows registry information for advanced users (http://go.microsoft.com/fwlink/?LinkID=142984).

You can find the following values in this registry location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Global\Gathering Manager

Name Default Value User Interface Location Description

ByPassList

Blank

Search Server\Search Administration\Farm-Level Search Settings

If the network uses a proxy server for access to the Internet, you can configure the name of that server in the Central Administration site. If you do this, Search Server uses the proxy server during crawls. You can also configure a list of addresses for which the proxy server is not used. This list is stored in the ByPassList registry value. See also the LocalByPassProxy value.

ConnectTimeout

60

Search Server\Search Administration\Farm-Level Search Settings

The time in seconds that the index server waits for a response when it connects to a content source during a crawl. If a content source responds slowly, its content may not be crawled. If you increase this value above 60 seconds, slow content sources are more likely to be crawled but the crawl may take longer. To accelerate crawls, decrease this value. However,, be aware that slow content sources may not be crawled and the index may become out of date.

DataTimeout

60

Search Server\Search Administration\Farm-Level Search Settings

The time in seconds that the index server waits for data after it connects to a content source during a crawl. Content sources can respond to connection requests quickly, and still be slow to return data. You can reduce this value to less than 60 seconds to prevent such content sources from slowing the crawl process. If you do this, be aware that, as with the previous value, that the index may become out of date with slow content sources.

DebugFilters

0

Not available

This value is used by IFilter and Protocol Handler developers when they debug their code. When the value is set to 1 or 2, the indexer will not kill the process if it is slow to complete so that developers have time to step through their code. This value should always be set to 0 in production environments.

DebugWordBreakers

0

Not available

This value is used by Word Breaker developers when they debug their code. When the value is set to 1, developers can easily see the words output by their Word Breaker. This value should always be set to 0 in production environments.

DedicatedFilterProcessMemoryQuota

104857600

Not available

This value places a limit on the memory use of search daemons as described below under FilterProcessMemoryQuota. This value is for single-threaded search daemons.

DeleteOnErrorInterval

100

Not available

After an item is added to the index it is checked at each later crawl. If an error occurs when this check happens, the item remains in the index. However, if the number of consecutive errors exceeds this value the item is removed from the index.

FilterProcessMemoryQuota

104857600

Not available

If a search daemon, such as an IFilter or Protocol Handler, uses an amount of memory that exceeds this value, the crawler kills the process. This limit prevents memory leaks in search daemons. The default value is designed for index servers that have 4 GB of physical memory. If you have more memory in the index server, you can increase this value proportionately to cache more data during crawls. However, because only 64 bit systems can use more than 4 GB of memory, do not increase this value unless you have 64 bit hardware and a 64 bit build of Microsoft Search Server 2008. This value is for multi-threaded search daemons.

FlushLinksCount

200

Not available

When the indexer crawls a document, it caches links found in the document in memory or on the disk. If the number of links exceeds this value, the links are flushed from the cache. See also LinkInMemoryCacheSize.

FlushLinksRollback

0

Not available

This value is not used.

FolderHighPriority

50

Not available

This value limits the number of high-priority folders that the indexer can process at the same time. If the value is set too high, the cache in the daemons will constantly be running out of space. If the value is too low, the crawl will be throttled waiting for more items to process. If you increase this value, you should also increase the FilterProcessMemoryQuota and DedicatedFilterProcessMemoryQuota values, because daemons use more memory, so otherwise the crawler kills them frequently and causes crawl errors.

FullIncrementalInterval

10080

Not available

This value only applies when the indexer crawls content that is stored in Microsoft Office SharePoint Portal Server 2003 or Windows SharePoint Services 2.0.This value defines a limit, in minutes, above which an incremental crawl becomes a full incremental crawl. Such a crawl processes some changes, such as deletes, that are not processed by ordinary incremental crawls.

IgnoreCertCNError

0

Search Server\Search Administration\Farm-Level Search Settings

When this value is set to 0, sites secured with Secure Sockets Layer (SSL) encryption will be crawled only if there are no problems with the certificate. The following example scenarios can cause a certificate error:

  • The certificate has expired.

  • The certification authority that issued the certificate is not trusted by the index server.

  • The server name of the content source does not match that in the certificate.

In each of these examples, the connection between the indexer and the content source will still be encrypted so that, if you trust the source, you can choose to allow connections anyway.

LinksInMemoryCacheSize

100

Not available

When the indexer crawls a document it caches in memory links found in the document. If the number of links in the document exceeds this number, the links are cached on the disk. If the index server has a large amount of memory, you should consider increasing this value for faster indexing.

LocalByPassProxy

0

Search Server\Search Administration\Farm-Level Search Settings

If this value is set to 1, the indexer connects directly to content sources in the local network. If this value is set to 0, and a proxy server is configured, the proxy server is used even for intranet addresses.

LocalStoreAccountSecret

Blank

Not available

This value stores an encrypted password for authentication against the local content store. This value should not be changed in the registry.

MaxAnchorsHttp

80

Not available

When the indexer crawls a Web page, it stores the hyperlinks in the page and later crawls those pages. You can control this behavior when you create a content source. For example, you can specify a maximum depth of links to follow. Web pages with very large numbers of links can slow down the crawl process. Therefore, this registry value limits the number of links crawled from a page. If you have many pages that have lots of links, and have lots of time to complete crawls, increase this value.

MaxAnchorsNonHttp

1000000000

Not available

This value is the equivalent of MaxAnchorsHttp for any document that is not a Web page.

MaxGrowFactor

4

Not available

The indexer uses this value to limit the size of a file that it indexes. Protocol Handlers report the size of each file, but some files, such as dynamically generated Web pages, may be significantly larger than estimated. If the file size is larger than the reported file size multiplied by the MaxGrowFactor value, the indexer raises an error and the file will not be processed.

PerformanceLevel

5

Central Administration\Operations\Services on Server\Office SharePoint Server Search Service Settings

This value governs the priority given to the search processes. For index and query servers, this value should be 5, which corresponds to "Maximum" in the user interface. For servers that are not dedicated to search functions, use lower values.

PlugInPingFrequency

12

Not available

This values indicates the number of index service heartbeats between pings to the plug-ins. Plug-ins include IFilters and Protocol Handlers. If you have an unreliable plug-in you should consider reducing this value.

ProxyName

Blank

Search Server\Search Administration\Farm-Level Search Settings

The proxy server name that you enter in the user interface is stored in this registry value. If you enter a port number, the ProxyName value is http://servername:portnumber.

RobotsTxtRefreshFrequency

86400

Not available

Many Web sites use a robots.txt file to list directories and files that should not be indexed. Search Server 2008 respects these preferences, but caches the robots.txt file for the time specified in this value in seconds. The default value of 86400 seconds is 24 hours. If you index sites that regularly change the robots.txt file, you should consider reducing this value.

RobotThreadsNumber

0

Not available

This value limits the number of robot threads that the indexer creates during a crawl. The value 0 is the default and means that the indexer automatically chooses the number of threads. If you find that crawling is using too many resources, such as CPU time or network time, you should consider specifying a value. The maximum value is 64.

UseProxy

0

Search Server\Search Administration\Farm-Level Search Settings

If the network uses a proxy server for access to the Internet, you can configure the name of that server in the Central Administration site. When you specify a proxy server in the user interface, this value is set automatically to 1. If you use Registry Editor to specify a proxy server, make sure that you manually set this value to 1.

You can find the following value in this registry location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Global\Gathering Manager

Name | Default Value | User Interface Location | Description
MaxDocId | 4294967295 | Not available | You can use this value to place an upper limit on the total number of documents that the indexer will crawl. The value -1 means that there is no limit. If the index file is becoming too large, this is one way to limit its size. Note, however, that some documents in the content may never be indexed if you use this value.


Book Excerpts (Search Server 2008)
DropDown image

Updated: 2009-07-23

The following table contains links to book excerpts that are intended for IT Professionals.

Publisher | Book Title | Chapter | Description
Wiley | Professional Microsoft Search: SharePoint 2007 and Search Server 2008 | Chapter 5: Searching LOB Systems with the BDC | This chapter will step you through the architecture of the BDC, how to connect it to your systems, how to use the systems in SharePoint Server, and how to write programs that use the BDC object model.
Wiley | Professional Microsoft Search: SharePoint 2007 and Search Server 2008 | Wiley: Professional Microsoft Search: SharePoint 2007 and Search Server 2008 | This chapter covers the federation features in detail, including what the federation framework looks like, how to configure and customize a Federated Location, what the new Federation web parts do, and how you can configure them.
Wrox Press | Real World SharePoint 2007 | Chapter 12: Secure SharePoint Communication | This chapter provides full coverage of the various options for securing SharePoint. Readers of this chapter will learn to implement Secure Sockets Layer (SSL), Kerberos security, and other configurations. This chapter also includes coverage of how to use the Microsoft Internet Security and Acceleration (ISA) Server.