How To Troubleshoot Issues With Exchange 2010 Search

How To Troubleshoot Issues With Exchange 2010 Search

  • Comments 1
  • Likes


Written by Rhoderick Milne, Microsoft Premier Field Engineer.
Since Exchange servers are now storing an ever increasing amount of data, it is imperative that people can quickly search and retrieve the content from their mailbox.  This may have been possible without search capabilities in the past with a 20MB mailbox quota (remember those days ?!?), but as quotas move to double gigabyte figures effective search is a hard requirement.

Exchange Search is a different animal compared to the full-text indexing that was available in Exchange 2003 and it has numerous performance, feature and scalability changes.  The search methodology is one of always up to date rather than Exchange 2003’s crawl model.  And unlike in Exchange 2003, content indexing is enabled by default on all mailbox servers so there is minimal configuration or setup apart from installation of the Office Filter Pack.  Throttling also ensures that Exchange 2007/2010 search does not impact server performance.

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 that is considered when Active Manager is deciding which copy of a mailbox database to failover to and activate in a Database Availability Group.

So what are some of the issues that can arise, and what can be done about them?  Issues can include the following:

  • Slow search performance
  • Unable to index certain documents
  • Unable to active database copies in a DAG

Slow Search Performance

Exchange 2010 SP1 RU4 addressed some important Exchange Search issues.  For example:  It takes a long time to return results when you perform an Advanced Find search on a mailbox by using Outlook in online mode in an Exchange Server 2010 SP1 environment.

 

Exchange Unable To Index Certain Documents

iFilters are 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 assists here as Exchange setup will automatically register the IFilters from the Office Filter Pack with Exchange Search, with Exchange 2007 and Exchange 2010 RTM:  http://technet.microsoft.com/en-us/library/dd351258.aspx

If you want other file formats to be indexed, e.g. PDF then an IFilter for that type needs to be installed and registered.

Unable to activate database copies

You will not be able to use the Exchange Management Console to activate a mailbox database copy when its Content Index is failed - you can use EMS to do that with the SkipClientExperienceChecks switch.

Note that the various database copy states can be found here in the Get-MailboxDatabaseCopyStatus cmdlet section.

 

Further Troubleshooting Steps

What else can we do to troubleshoot the Content Index for issues where searches are stalling or it is deadlocked?  Exchange provides a range of scripts that are present in the \Scripts directory.  By Default this is C:\Program Files\Microsoft\Exchange Server\V14\Scripts for Exchange 2010.  Exchange 2010 SP1 introduced the Content Index Troubleshooter Script – Troubleshoot-CI.ps1.  This script can monitor and perform troubleshooting on a server’s CI catalogs and can detect and resolve symptoms such as

  • Deadlock: Exchange Search deadlocks waiting on threads from MSSearch
  • Corruption: One or more search indices are corrupted
  • Stall: Similar to deadlock in that the indices are not getting updated
  • Backlog: The Search catalog is backlogged resulting in missing index searches

 

If the above troubleshooter is unable to correct the issue, it may be necessary to reset the CI catalog and let it rebuild.  This can be done by running the ResetSearchIndex.ps1 script.  This will stop the Exchange Search service, delete the catalog files for the given database and then start the Exchange Search service  after which the catalog is rebuilt.

Normally this process works well, but from time to time I encounter catalogs that have persistent issues where a little more invasive action is required.  In these situations the CI index is set to be disabled for the database, old copies of the catalog files are moved and then the generation process can start afresh.  This is shown is the following steps:

  • Disable the CI for the database.   
Set-MailboxDatabase -IndexEnabled $False
  • Stop Exchange Search search on passive copies
  • Rename the catalog folder on all copies
  • Re-enable CI for database
Set-MailboxDatabase -IndexEnabled $True
  • Wait, or restart the Search service on the active server to rebuild the CI on the active copy.  Look for the msg in the app log to confirm this.
  • Then start search service on passive. 
  • Then update the catalog on passive
Update-Mailboxdatabasecopy -CatalogOnly

 

Cheers,

Rhoderick

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hope you can help me - My one of the client Exchange 2010 SP2 / No Rollups

    Observations:

    MBX servers are monitored via SCOM2012 Exchange server management pack verison - 14.3.38.4

    SCOM Alert - KHI - Detected indexing backlog for multiple database on server

    MBX server event ID 5611 every two hours - Indexing backlog reached a critical limit of 48 hours or the number of items in the retry queue is greater than 10000 for one or more databases

    Action Taken:

    Did catalog reseed only - still the events are occuring

    Followed KB2633044 - Dword value wasn't present on server hence created, didnt worked (Didnt rebooted the server but waited for SCOM to auto execute the Troubleshoot-CI.ps1)

    Searched and came across - support.microsoft.com/.../2820817 - Should we really need to follow...?

    When I ran the Troubleshoot-CI.ps1 manually on server from script folder I do not find any error event ID 5611 logged on the server

    Whats your thought on this...?

    Finally what do you have to suggest/recommend SCOM exchange mgmt. pack version upgrade / exchange rollup or service pack?