Share via


Exchange 2016: Content Index and search

In this article, we will have a look at content index in Exchange 2016 and its improvements.

How indexing works in the background:

Indexes will contain all the search data for a database and its copies. This will create search data for all the mailboxes in that database. This data will be stored in a GUID on corresponding databases in the same location in a folder and has sub-folders in it. This will help all end users search query from their mailbox.

So basically this will be like an index for a book where we usually look for the subject page location and navigate to the right page. This index functionality is also similar where it looks for the specific email based on the executed search query from users and returns the appropriate results.

Exchange 2016 uses the same Fast Search Index which was introduced from Exchange 2013.

We can see that corresponding file FastSearchIndex as well in the below location on the indexing folder in Exchange 2016 as well.

https://exchangequery.files.wordpress.com/2016/04/ciii2.png?w=680

So how does the indexing functionality work with Fast Search Index?

This Fast Search Index has two core components.

1. CTS - Content Transformation Service:

This service is responsible for performing the actual background work. When the search query reaches here it actually filters the request and performs the search content analysis with dictionary matches, keyword matches and parsing data with regular expressions. All of them are preloaded registered filters on the Exchange 2016 Mailbox Server. From Exchange 2016 the parsing retry logic and search result cap have increased from 30 to 250 search refiners which gives better search results.

As soon as the search process with this CTS reaches the corresponding database store where the mailbox resides that's when the below Event ID gets created.

https://exchangequery.files.wordpress.com/2016/04/ccc.png

2. IMS - Interaction Management Service:

This component receives the prepared search results from CMS service processes and sends the search results back to the user.

The corresponding service which is responsible for these components is Microsoft Exchange Search.

https://exchangequery.files.wordpress.com/2016/04/actual.png

Rest of the content index operators statistics remain the same as Exchange 2013.

https://exchangequery.files.wordpress.com/2016/04/c1.png

What happens when you rebuild an index?

Usually, we aren't required to rebuild the index until the database and copies go into an inconsistent state which is very rare in a well-planned deployment. But when an index is rebuilt Exchange will create a clone copy of the existing database and will use this copy to rebuild the index from the scratch. This will take a lot of time to rebuild the index and will consume CPU, memory and disk.

Search Enhancements and improvements from Exchange 2016:

In earlier versions of Exchange, these passive database copy indexes will be updated from the active copies. This will consume more resources including CPU time, memory and also disk space of 10 to 20 percent.

From Exchange 2016 the indexing of passive copies is done on the passive itself rather than getting it from active copies. This will definitely reduce the utilization of the system resources and network which is very good.

Calendar search is available only from Outlook Web App at the moment.

https://exchangequery.files.wordpress.com/2016/04/actual2.png

Enhanced server power search and hand-off to the end user is available for all Outlook 2016 clients.

This means from Exchange 2016 with Outlook 2016 client, end users will not get the below screen with option "Find more on the server"  anymore

https://exchangequery.files.wordpress.com/2016/04/actual21.png?w=680

By having this as a default search index from Outlook 2016 client, this will seamlessly search on the local cache (ost), Exchange 2016 computer and provide better results in the first search itself. An important point to note is that the client computer needs an internet connection to have the server side search.

The good thing is that after configuring the Outlook profile for a user having a huge mailbox size on a new laptop, the help desk team no longer needs to wait for the local OST file to be cached and indexed since the server side search is attempted on the first try.

When offline, still the search will be performed against the Windows Search Index on the computer.

Based on experience with the enhanced search from Exchange 2016, it is really faster and returns the appropriate results with Outlook 2016 client.