This article is intended to cover some of the best practices related to Exchange 2010 search. Whilst the search service has been continuously improved over the lifecycle of Exchange 2010 there are multiple items can need to be addressed. If these items are not addressed, then there is a very good chance that you will be riding the bus to incident town…
What items and issues do we need to address?
Update Office Filter Pack
Exchange requires the Office filter pack when installing the Mailbox or Hub Transport role. Exchange 2010 RTM supported the Office 2007 filter pack, Exchange 2010 SP1 and up require the Office 2010 filter pack. Since only Exchange 2010 SP3 is currently supported, we only need to address the Office 2010 filter pack.
In addition to the base Office 2010 filter pack, there are now Service Pack One and Service Pack 2 for the Office 2010 filter pack. At this time you should have SP2 deployed for the Office 2010 filter pack. That will address multiple issues right off the bat.
Register Search Service iFilters
Installing the Office filter pack installs iFilters onto the server. It is these iFilters that do the crawling and indexing of the supported documents. With Exchange 2010 RTM and Exchange 2007, just installing the filter pack was not enough. You then had to manually register the filter pack with the Exchange Search service. If this was not done, then Exchange would never use the iFilters….
This is discussed on TechNet for Exchange 2010 and also for Exchange 2007. Unfortunately these are some of the least read pages, so these steps were often skipped. Exchange 2010 SP1 onwards now automatically registers the iFilters with the Exchange Search service.
Great you say! Yes it is for the Office iFilters. We will come back to this later with respect to 3rd party iFilters.
Default File Types
Exchange 2010 search supports a specific list of file types when the Office 2010 filter pack is installed. The list of files can be reviewed in the TechNet documentation. Note that there are a set list of file types that WILL be indexed, and also a set list of file types that do not contain data that can be indexed and are exempt from search. These file types are indicated by a null filter entry in the registry.
In addition to reviewing the TechNet documentation referenced above, we can look at the registry to see what the current configuration is.
This obtains the list of the current file types that will be indexed:
Get-ChildItem HKLM:SOFTWARE\Microsoft\ExchangeServer\v14\MSSearch\Filters | Format-Table PSChildName
This obtains the list of the current file types that are exmpted:
Get-ChildItem HKLM:SOFTWARE\Microsoft\ExchangeServer\v14\MSSearch\NullFilters | Format-Table PSChildName
Adding Additional iFilters
After reading the above section, and then looking at the registry you might have noticed that one fairly popular file type is not present.
PDF was not in the list of indexed file types was it? Exchange 2010 does not have native support for PDF files.
If you want to be able to index PDF files then you will need to install a 3rd party iFilter for Exchange 2010. Ensure that the iFilter you purchase is from a reputable company and that it is correctly installed and registered into the Exchange Search service. For reasons unknown there have been documentation mistakes with some of the previous PDF iFilter installation documents that I have had to troubleshoot.
Filter Deployment Timing
If Exchange Search does not have an iFilter for a given file type, then that file type will not be indexed.
For existing items, this is true even if you then add an iFilter for that file type. Exchange will not re-index just because you added the iFilter. If you then want to be able to search for older instances of the file type then the index must be reset and Exchange will have to rebuild the entire index from scratch.
During the rebuild all instances of the file type that was added to Exchange Search will be indexed.
For this reason, it is strongly recommended to deploy all required iFilters, prior to moving mailboxes to Exchange 2010. This guidance will typically apply to PDF iFilters since they are not natively processed in Exchange 2010.
An alternative to resetting the search catalog is to move all of your mailboxes to new databases. When the mailbox is moved the content is re-indexed on the destination. If the issue applies to only a couple of mailboxes of a department this may be the way to go. However if it is organisation wide, then the choice is yours…..
You might observe that Test-ExchangeSearch fails when Exchange 2007 SP3 and Exchange 2010 are installed onto Windows Server 2008 R2.
The Test-ExchangeSearch cmdlet fails for some or all Exchange databases on a specific server.
Search repeatedly stops and then starts at random intervals. However, you receive no error message.
The size of the catalog index (*.ci) files are smaller than 125 kilobytes (KB).
The MSFTEFD.EXE service creates a new instance every few minutes.
These issues occur because of a design change in the Windows Server 2008 R2 certificate-verification method. The server no longer accesses crl.microsoft.com for the Authoritative and Untrusted root certificate revocation lists (CRLs). The instance now accesses ctldl.windowsupdate.com to update the Authoritative and Untrusted root CRLs on the server.
To resolve this, edit the MSFTEFD.EXE.CONFIG file as described in KB 2837276.
Event ID 9877
You may observe EventID 9877 with error code 0x80041606 on Exchange 2010. The event log entry will contain:
Content Indexing function 'CISearch::EcGetRowsetAndAccessor' received an unusual and unexpected error code from MSSearch.
Mailbox Database: Mailbox Database
Error Code: 0x80041606
NOTE: 0x80041606 = QUERY_E_TOOCOMPLEX
This issue occurs because Exchange Search has a hard-coded prefix search limit of 200,000 nodes for a single character search. When a prefix search exceeds this limit, the search returns QUERY_E_TOOCOMPLEX. Therefore, 0x80041606 is logged as part of event ID 9877. By default, all searches that use Outlook online mode in an Exchange 2010 environment are prefix searches. Using single digits or letters causes the system to search for all numbers or words that begins with the single digit or letter across the whole mailbox database. If the 200,000 nodes default limit is reached, the search returns the error.
This is discussed in KB 2616127.
Monitor Search Catalog Health
While we can fix the issues noted in this post, we need to be alerted that there is in fact an issue.
That means that you will need to have monitoring deployed and configured for Exchange 2010. This could be SCOM or a third party product. The health of the index is critical when considering the results that are returned. If the index is not healthy then you will not get all of the potential results.
This applies to end users searching their mailboxes, and also compliance officers performing discovery searches.
Install Exchange Updates
There are many reasons and requirements that Exchange should be patched and be maintained properly. Addressing issues with the Exchange Search service is just one of them.
There have ben numerous updates and fixes for Exchange Search, and they are obtained by installing the Exchange updates.
File System Anti-Virus Exclusions
If the file system AV exclusions are not correctly implemented, then AV has a habit of interfering with the search catalog on disk. The catalog is always located with the Exchange database file.
Once common reason is due to mount points not being correctly excluded by file system AV.
Please ensure that you have consulted with your AV vendor to ensure that their product had been correctly configured. Microsoft specifies WHAT is to be excluded. HOW that is then implemented is guidance you must obtain from the AV vendor.
Please see this post for additional issues with file system AV exclusions (or rather lack of) and Exchange.