Export (0) Print
Expand All

Problems with Full-Text Indexing

 

Topic Last Modified: 2005-07-17

This section discusses how to resolve problems that you may encounter with full-text indexing. It contains information about the following error messages and situations:

  • Safe event viewer messages

  • Population process is slow

  • Population process is found in a paused state

  • Deleted message is still visible in search results

  • Wrong location is displayed after moving the index

  • Using gather log entries to identify problems

  • Language settings problems

  • Queries fail during server startup

  • Restoring missing performance counters

  • Avoiding disk bottlenecks

  • High paging

If you encounter problems with full-text indexing, Event Viewer and Performance Logs and Alerts are useful troubleshooting tools.

Although Event Viewer is useful for troubleshooting full-text indexing problems, there are certain events (as described in the following sections) that do not necessarily indicate problems.

After you use Exchange System Manager to stop an index population, the Microsoft Search service (MSSearch) may incorrectly log several copies of the following event message in the Event Viewer application event log:

Event Type: Information

Event Source: Microsoft Search

Event Category: Indexer

Event ID: 7000

Date: date

Time: time

User: N/A

Computer: server_name

Description:

The Indexer started successfully for project

<ExchangeServer_SERVERNAME priv78F2DC76>

This message does not indicate a problem, and you can ignore it.

When you shut down the Microsoft Search service in a clustered environment, you may see the following error message:

Event Type: Error

Event Source: Microsoft Search

Event Category: Gatherer

Event ID: 10006

Date: 2/11/2000

Time: 9:44:25 AM

User: N/A

Computer: <servername>

Description:

An error occurred during the online operation for instance <your instance>: 8000ffff - Catastrophic failure

This error is not a catastrophic failure. Wait for all services to shut down successfully, and then restart services, if necessary. To prevent this error, use Cluster Administrator to stop clustered resources instead of the Services application in Control Panel. When you stop the service using Services in Control Panel, the cluster resource manager assumes that the resource failed, and it either attempts to restart the service or fails over the group.

When the Microsoft Search service is running, you may receive error messages similar to the following in the gather logs:

2b3b1b8 1bed2fc

file:\\.\BackOfficeStorage\server.microsoft.com\MBX\SMTP

(SERVER-{E2E63C70-4129-43F6-9363-6B501433C952}) 8000000c 0 80080005

2cdeb96 1bed2fc

file:\\.\BackOfficeStorage\server.extest.microsoft.com\MBX\System Attendant 8000000c 0 80080005

You can ignore these error messages. For more information about the gather logs, see "Using Gather Log Entries to Identify Problems" later in this topic.

If the population process is slow, Internet news feeds may be the cause. Internet news feeds may contain uuencoded binaries, which are indexed at a much slower rate than normal messages. When you run a population on a public folder that contains Internet news feeds, population time lengthens significantly.

Messages with large attachments may also cause performance problems if you have not optimized the maximum download size. The recommended setting is 4,000 megabytes (MB). Changing this setting requires editing the registry.

CautionCaution:
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

For detailed steps about how to change the maximum download size of attachments, see How to Change the Maximum Download Size of Attachments.

For more information about setting the download size, see "Optimizing Full-Text Indexing" in Using Exchange Server 2003 Full-Text Indexing.

The Microsoft Search service pauses a population process if it cannot continue. To verify whether the Microsoft Search service, instead of an administrator, paused the population, check the event log. The Microsoft Search service logs an event when it must pause or stop the population. For example, the Microsoft Search service pauses a population if the disks are too full to add new information to the indexes or the log files. Generally, you can fix the problem (for example, by freeing space on a full drive), and resume the population. New documents added during the pause are not added to the index until the next population.

noteNote:
Lack of space on the disk is often the problem, even when it appears that there is ample free disk space. The Microsoft Search service uses disk space liberally to temporarily unpack large sections of the index to merge new results before recompressing.

You can delete a message from a search results folder. The message is deleted, but the message remains visible in the search results window until you refresh the search.

If you use the Catutil tool (Catutil.exe) to move the index, the index location that Exchange System Manager displays is not updated. For details about using the Catutil tool to move the index, see Using Exchange Server 2003 Full-Text Indexing. The index is moved successfully and functions correctly, but Exchange System Manager displays the original location of the index incorrectly. This is a display error and does not affect the normal operation of full-text indexing. You cannot correct the display, but you can check the current location of the index at any time by checking the registry.

For detailed steps about how to check the current location of the index after using Catutil, see How to Check the Current Location of the Index.

Gather log files are generated during a population. These files contain log information for the Microsoft Search service. The files are located in the Program Files\Exchsrvr\ExchangeServer_<servername>\GatherLogs directory. The files have a .gthr extension.

If a particular document fails to be indexed for any reason, an entry is logged in the gather log file. Each entry lists the file name and the error number. To decode this error number, use the Gthrlog tool found in the Program Files\Common Files\System\MSSearch\Bin directory.

For detailed steps about how to use the Gthrlog tool to decode an error number from the gather log file, see How to Use the Gthrlog Tool to Decode an Error Number from the Gather Log File.

The guidelines that govern full-text indexing in mixed-language scenarios are complex. The language settings of individual messages, attachments, the server, and the client computer affect indexing behaviors. The following table explains how various language settings affect indexing behaviors. You can use this information to help determine the cause of user-reported search problems.

Effects of language settings on indexing behavior

Language setting Indexing behavior

Individual messages

  • If a message is a MAPI message, it has a Locale ID property, and full-text indexing uses this value to determine which word-breaker (identifies where individual words begin and end in a given text) to use. This property value comes from the Language setting in Microsoft Office System on the client computer. If full-text indexing cannot find a word-breaker to match the Locale ID property, it uses the Neutral <0> property. For more information about how full-text indexing uses word-breakers, see Using Exchange Server 2003 Full-Text Indexing.

  • If a message is created with Distributed Authoring and Versioning (DAV), it uses the Accept-Language header to determine the correct locale.

  • If a message has no locale identified, (which is often the case with messages from the Internet), the System Locale setting of the computer running Microsoft Exchange Server 2003 where full-text indexing is performed is used to determine the word-breaker.

Attachments to messages

If an attachment is a Microsoft Office document, full-text indexing uses the language setting that was used to generate the document.

Server running Microsoft Windows 2000 Server

If the message is non-MAPI (from the Internet), its Locale ID property is not set, and full-text indexing uses the System Locale setting of the server to determine which word-breaker to use.

Client computer

When a query is sent from Microsoft Office Outlook 2003, the Locale ID of the client computer is also sent. If the Locale ID of the message does not match the Locale ID of the query, the search results are unpredictable.

noteNote:
The language of the computer running Exchange Server2003 is irrelevant in this scenario. The client computer setting takes priority.

The following scenarios describe query behavior of content indexing with various language settings.

If you use U.S. language settings in Outlook, running on a client computer with U.S. language settings, to compose and submit a message to Exchange Server 2003 on a server running Windows 2000 Server with U.S. language settings, the following process occurs:

  1. Full-text indexing indexes the message using the U.S. language setting word-breaker.

  2. Queries from the client computer with U.S. language settings are processed as expected.

In this example, the client computer is configured as follows:

  • The client computer has Hebrew language settings.

  • Office has U.S. language settings.

  • Outlook has Hebrew language settings.

If you compose a message on the client computer described in this example and submit the message to Exchange Server 2003 with the System Locale setting set to U.S., the following process occurs:

  1. Full-text indexing uses the U.S. word-breaker to index the message. The Locale ID property of the message defaults to U.S. because of the Office settings.

  2. Queries from the Hebrew client computer fail because the Hebrew document does not have the proper word-breaker applied.

In this example, the client computer is configured as follows:

  • The client computer has Japanese language settings.

  • Office has Japanese language settings.

  • Outlook has Japanese language settings.

If you compose a message on the client computer described in this example and submit the message to Exchange Server 2003 with the System Locale setting set to U.S., the following process occurs:

  1. Full-text indexing uses the Japanese word-breaker to index the message.

  2. Queries from the Japanese client computer succeed because the message was indexed and queried with the same Locale ID property.

During initialization, in the first few minutes after starting a computer running Exchange Server 2003 with full-text indexing, users might receive their mail but not receive results from queries. This failure to receive query results occurs because the Microsoft Search service is loading the index, and Exchange Server 2003 is loading the property store. Queries do not return results until these processes are complete.

Event messages similar to the following indicate that the counters used by the Performance Logs and Alerts service and the Performance application (also called System Monitor) are missing. If you receive one of these messages, restore the counters by restarting the Microsoft Search service. For more information about these monitoring applications, see the Windows Resource Kit.

Performance monitoring for the Gatherer service cannot be initialized because the counters are not loaded or the shared memory object cannot be opened. This only affects availability of the performance counters. Rebooting the system may fix the problem.

Performance monitoring cannot be initialized for the Gatherer object because the counters are not loaded or the shared memory object cannot be opened. This only affects availability of the performance counters. Rebooting the system may fix the problem.

Performance monitoring for the Indexer object cannot be initialized because the counters are not loaded or the shared memory object cannot be opened. Stop and restart the Search service. If this error continues, reinstall the application.

To avoid disk read and write bottlenecks, use the following guidelines:

  • Disk queue length should be monitored.

  • The queue length is expected to average less than the number of spindles in the redundant array of independent disks (RAID) array. If a storage area network (SAN) is being used, it is recommended that you monitor latency using the following performance counters: PhysicalDisk: Average Disk sec/Read and PhysicalDisk: Average Disk sec/Write.

  • The length should drop to zero occasionally.

  • The queue should be empty occasionally. Having something always in the queue indicates a problem.

  • The average time per disk write and per disk read should be close to the expected latency. The system should take roughly 10 milliseconds for a disk write or read. If the configuration has a hardware cache or a RAID controller, the time could be less.

High memory-to-disk paging can indicate a memory bottleneck. Check your performance counters and monitor them for warning signs. In particular, check the Memory: Page writes/sec and Memory: Page reads/sec counters.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft