Exchange 2013 and Exchange 2016 search is again a huge improvement and work area in the same vein as the search improvements in Exchange 2007 compared to Exchange 2003. Exchange Search is important for many reasons. Users running Outlook in online mode will leverage the Exchange search service, as will those on OWA. Administrators performing discovery searches will also be using Exchange Search. Thus it is clearly an important aspect of the Exchange environment, and it is also part of the Best Copy Selection process which is considered when Active Manager is deciding which copy of a mailbox database to activate in a Database Availability Group. In addition, newer Outlook builds also have the ability to cache a portion of the mailbox data to the local OST file. This means that even in cached mode, the Outlook client will still need to reach out and leverage Exchange Search.
For most standard use cases there is no hard requirement to install the Office 2010 filter pack onto an Exchange 2013 server. This was not the case in Exchange 2007/2010 where the opposite was true. In Exchange 2007/2010 iFilters were required so that Exchange Search can index content in various file formats. In Exchange 2007 and Exchange 2010 RTM you must manually register the IFilters by editing the registry or running the provided script. Exchange 2010 SP1 helps us out as Exchange setup will automatically register the IFilters from the Office Filter Pack with Exchange Search. In Exchange 2007/2010 if you wanted other file formats to be indexed, e.g. PDF then an IFilter for that type needs to be installed and registered. Note that additional work items are required, which are discussed in detail in this post.
What happens when a good Search index goes bad? Issues can include the following:
- Slow search performance for users
- Unable to index certain documents
- Administrators unable to perform e-discovery searches or may get incomplete results (both are very bad)
- Unable to easily active database copies in a DAG
The below is an example from an Exchange 2016 RTM server which has an issue with Search. We can use the Get-MailboxDatabaseCopyStatus cmdlet to review the status of the index.
Get-MailboxDatabaseCopyStatus | Select Name, Status, ContentIndexState
Drilling into the details we can see that this index is in a FailedAndSuspended state, and that it needs to be reseeded.
Since this is a database with only a single copy, there is no place to reseed the index from. If there was another server with a healthy index then we could used the Update-MailboxDatabaseCopy cmdlet with the CatalogOnly parameter.
Resetting Content Index – The Exchange 2010 Way
As mentioned in the Troubleshooting Exchange 2010 Search blog post there were built-in scripts to help troubleshoot index issues, and were located in the $EXScripts folder. Of note for this discussion they were ResetSearchIndex.ps1 and Troubleshoot-CI.ps1.
However running ResetSearchIndex.ps1 on an Exchange 2013 or 2016 server will likely show you the below result:
The troubleshooter failed with error:System.InvalidOperationException: Couldn't read registry key:SOFTWARE\Microsoft\Exc
hangeServer\v15\ContentIndex\CatalogHealth\{d389a615-ce8b-49e8-9179-8be6d3d740ee}At C:\Program Files\Microsoft\Exchange
Server\V15\scripts\CITSLibrary.ps1:1023 char:9
Tony released a blog post noting that the ResetSearchIndex.ps1 was depreciated on Exchange 2013. On the Exchange 2016 RTM server shown above there is no ResetSearchIndex.ps1 in the $EXScripts folder at all.
Resetting Content Index – The Exchange 2013 and 2016 Way
If we are unable to reseed the index from another server in the DAG, then we can manually rebuild it using the below steps. A similar proceess could also be done in Exchange 2007 and 2010. We need to stop the Exchange Search services, remove the index files and then restart the Search services. It is critical that the services are stopped, else the search service believes that it has indexed content, but you have removed the index. Shortly after the Search services are restarted, Search will realised that it needs to index the database, and will then start the crawling process. This may take a considerable amount of time, so if at all possible it is recommended to reseed the index from another copy of the database in the DAG (assuming that is possible).
Note – before going down the troubleshooting path in Exchange 2013, please check to ensure that you are not hitting this known issue. In some cases multiple content indexes will be reported as failed due to an AD DS group not being created. This is covered in KB 2807668 -Content Index status of all or most of the mailbox databases in the environment shows "Failed".
To resolve the issue, do the following:
- Create a new Active Directory group that is named "ContentSubmitters" and then grant Admistrators and NetworkService full access to the group. This is a dummy group and should be used as a placeholder only. You might want to add a description so that the group is not removed.
- Force or wait for Active Directory replication.
- Restart the following services:
- Microsoft Exchange Search
- Microsoft Exchange Search Host Controller
The two services below are from an Exchange 2016 server. We can stop the services using PowerShell or the services applet.
If you want to automate the process MSExchangeFastSearch and HostControllerService are the two service names.
We could run the below to stop the services:
Stop-Service MSExchangeFastSearch ; Stop-Service HostControllerService
Then we remove the search catalog folder. This is stored in the same folder as the database. Once we have removed the catalog FOLDER then the services need to be restarted.
Start-Service MSExchangeFastSearch ; Start-Service HostControllerService
Initially the index state is unknown, and after a short while the state transitions to crawling. Eventually it will be healthy when the crawl completes.
We can see the progress when looking at the application event log. The Search services have started up, and after a few minutes they realised that the database is not indexed and the crawl is launched.
Note that in the above screenshot the database is referenced by its GUID with two extra characters at the end.
Cheers,
Rhoderick
