Exchange content index Failed or Unknown: fixing search on Exchange 2016, 2019 and SE

Search problems on Exchange Server usually arrive as a user complaint ("Outlook can't find anything older than last week") or as a ContentIndexState of Failed or Unknown in your monitoring. The fix depends heavily on the version: Exchange 2016 keeps a separate search catalog that you can reseed or rebuild, while Exchange 2019 and Exchange Server SE keep search data inside the mailbox database. In this post I'll show how to separate client problems from server problems, then walk through the right fix for each version.

Symptoms#

• Searches in Outlook on the web, or in Outlook in Online Mode, return nothing, only recent items, or only part of the results.
• Outlook in Cached Exchange Mode shows Search results may be incomplete because items are still being indexed.
• The database copy status reports an unhealthy index (Exchange 2016):

Get-MailboxDatabaseCopyStatus * | Sort-Object Name |
  Format-List Name,Status,ContentIndexState

Name              : DB01\EX01
Status            : Mounted
ContentIndexState : Failed

Name              : DB01\EX02
Status            : Healthy
ContentIndexState : FailedAndSuspended

Name              : DB01\EX03
Status            : Healthy
ContentIndexState : Healthy

Name              : DB02\EX01
Status            : Mounted
ContentIndexState : Unknown

On Exchange 2016, a catalog reseed can also fail with:

WARNING: Seeding of content index catalog for database 'DB01' failed. Please verify that the Microsoft Search (Exchange) and the Host Controller service for Exchange services are running and try the operation again.

For the reason behind a failed state, add ContentIndexErrorMessage to the output: Get-MailboxDatabaseCopyStatus "DB01\EX02" | Format-List ContentIndexState,ContentIndexErrorMessage.

Why it happens#

Two different search architectures#

Exchange 2016 indexes each database copy into its own content index catalog: a folder named after the database GUID that sits next to the .edb file. Two services maintain it, Microsoft Exchange Search (MSExchangeFastSearch) and Microsoft Exchange Search Host Controller (HostControllerService). Because every DAG copy has its own catalog, a broken one can be reseeded from a healthy copy.

Exchange 2019 and Exchange Server SE use a rebuilt search architecture (often called Big Funnel) that stores index data inside the mailbox database, so it replicates with the database through normal log shipping. There's no catalog folder to delete or reseed, and Get-MailboxDatabaseCopyStatus reports ContentIndexState as NotApplicable by design; that value isn't a fault. Search problems there are investigated per mailbox.

What the Exchange 2016 states mean#

Common triggers are stopped or crashed search services, a full or failing database volume, antivirus scanning the catalog folders or search processes, and an interrupted cumulative or security update.

How to fix it#

1. Decide whether it's the client or the server#

Run the same search in Outlook on the web. OWA and Outlook in Online Mode always search on the server. Cached Exchange Mode searches the local cache through Windows Search and only goes to the server for items outside the cached window.

• OWA finds the item, Cached Mode Outlook doesn't: the problem is on the PC. Check the Windows Search service and rebuild the index from Control Panel › Indexing Options › Advanced › Rebuild.
• OWA can't find it either: the problem is on the server. Carry on below.

2. Check and restart the search services#

Get-Service MSExchangeFastSearch,HostControllerService |
  Format-Table Name,DisplayName,Status,StartType -AutoSize
Stop-Service MSExchangeFastSearch,HostControllerService
Start-Service HostControllerService,MSExchangeFastSearch

Both services exist on Exchange 2016, 2019 and SE. Wait a few minutes and check the state again: an Unknown caused by a hung service usually turns into Healthy or Crawling. Also confirm the database volume has free space and that the Exchange antivirus exclusions, including the search folders and processes, are in place.

3. Exchange 2016 in a DAG: reseed the catalog#

If at least one copy of the database has a Healthy catalog, reseed the broken one from it instead of rebuilding:

Update-MailboxDatabaseCopy -Identity "DB01\EX02" -CatalogOnly
# Or choose the source copy explicitly
Update-MailboxDatabaseCopy -Identity "DB01\EX02" -CatalogOnly -SourceServer EX03

Catalog seeding runs over the MAPI network. If you get the "Seeding of content index catalog ... failed" warning, confirm both search services are running on the source and the target, and that the source catalog really is Healthy. When the active copy's catalog is the broken one, switch the database to a copy with a healthy catalog (Move-ActiveMailboxDatabase DB01 -ActivateOnServer EX03), then reseed the catalog of the old active copy.

4. Exchange 2016 with one copy (or every copy broken): rebuild#

A rebuild makes Exchange crawl every mailbox in the database again. That costs CPU and disk I/O and leaves search incomplete until it finishes, so do it out of hours.

Get-MailboxDatabase DB01 | Format-List EdbFilePath,Guid
Stop-Service MSExchangeFastSearch,HostControllerService
# In the database folder, rename the catalog folder whose name starts with the database GUID.
# Don't touch the .edb, .chk or log files.
Start-Service HostControllerService,MSExchangeFastSearch

The services create a new catalog, and the state moves through Crawling to Healthy. Delete the renamed folder once search works. In a DAG where every copy failed, rebuild on the active copy first, then reseed the passive catalogs with -CatalogOnly.

5. Exchange 2019 and SE: work per mailbox#

Get-MailboxStatistics -Identity "user@contoso.com" | Format-List DisplayName,ItemCount,BigFunnel*

Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics |
  Where-Object { $_.BigFunnelNotIndexedCount -gt 0 } |
  Sort-Object BigFunnelNotIndexedCount -Descending |
  Format-Table DisplayName,ItemCount,BigFunnelNotIndexedCount -AutoSize

A high BigFunnelNotIndexedCount (and BigFunnelNotIndexedSize) means items that never made it into the index. Then:

• Restart the two search services on the server that hosts the active copy, and keep the server on the latest cumulative and security updates, because search fixes ship in them.
• For a single mailbox with a badly damaged index, a common fix reported by admins is moving it to another database with New-MoveRequest; the index is built again at the destination.
• Microsoft's CSS-Exchange project includes Troubleshoot-ModernSearch.ps1, which checks whether a specific item is indexed and, if not, why: .\Troubleshoot-ModernSearch.ps1 -MailboxIdentity user@contoso.com -ItemSubject "Test Message".

Verify the fix#

Get-MailboxDatabaseCopyStatus * | Format-Table Name,Status,ContentIndexState -AutoSize

On Exchange 2016, good looks like Healthy on every copy (expect Crawling for a while after a rebuild). On Exchange 2019 and SE, the affected mailboxes' BigFunnelNotIndexedCount drops to zero or close to it. In both cases, finish with a user-level test: search OWA for a message received today and one from last year, then repeat the search in Outlook.

Prevent it next time#

• Keep the Exchange antivirus exclusions complete, including the search folders and processes.
• On Exchange 2016, monitor ContentIndexState alongside copy status so a failed catalog is reseeded before users notice.
• Keep free space on database volumes; on Exchange 2016 the catalog lives there too.
• Exchange 2016 reached end of support on 14 October 2025, and moving to Exchange Server SE also ends catalog reseeds. See Exchange 2016 and 2019 are out of support and Exchange Server SE explained.
• If the whole database copy, not just its index, is failing, follow Database copy FailedAndSuspended in a DAG.

References#

• Update-MailboxDatabaseCopy (Microsoft Learn)
• Manage mailbox database copies (Microsoft Learn)
• Troubleshoot-ModernSearch (Microsoft CSS-Exchange)