Problems with Full-Text Indexing
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.
Safe Event Viewer Messages
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.
Event ID 7000: The Indexer Started Successfully
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.
Event ID 10006: Catastrophic Failure (Cluster Environment)
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.
SMTP and System Attendant Logged as Errors
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.
Population Process Is Slow
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.
Warning
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.
Population Process Is Found in a Paused State
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.
Note
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.
Deleted Message Is Still Visible in Search Results
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.
Wrong Location Is Displayed After Moving the Index
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.
Using Gather Log Entries to Identify Problems
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.
Language Settings Problems
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 |
|
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. Note The language of the computer running Exchange Server2003 is irrelevant in this scenario. The client computer setting takes priority. |
Full-Text Indexing Behavior in Mixed-Language Scenarios
The following scenarios describe query behavior of content indexing with various language settings.
All U.S. 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:
Full-text indexing indexes the message using the U.S. language setting word-breaker.
Queries from the client computer with U.S. language settings are processed as expected.
Client Computer with Hebrew Language Settings, U.S. Language Settings in Office, and Hebrew Language Settings in Windows 2000 Server
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:
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.
Queries from the Hebrew client computer fail because the Hebrew document does not have the proper word-breaker applied.
Client Computer with Japanese Language Settings, Japanese Language Settings in Office, and U.S. Language Settings in Windows 2000 Server
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:
Full-text indexing uses the Japanese word-breaker to index the message.
Queries from the Japanese client computer succeed because the message was indexed and queried with the same Locale ID property.
Queries Fail During Server Startup
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.
Restoring Missing Performance Counters
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.
Avoiding Disk Bottlenecks
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 Paging
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.