Summary: “The content index state is failed and suspended” is an error that appears in the Exchange Server DAG setup that can prevent the DAG from switchover or failover to another server if a disaster strikes or the primary server stops working. This can impact the users as they won't be able to connect or access their mailboxes. In this blog, we have shared some solutions that you may follow to try to fix the error and restore client-server connectivity.
You might encounter an unusual error on the Exchange Server database index saying, “The content index state is failed and suspended.” The error does not impact the accessibility to the databases as the users will still be able to access, read, send, and receive the emails. However, this will impact any user who is trying to connect via Outlook Web Access (OWA) and trying to search in the mailbox.
The functionality impact of the error on the Exchange Server infrastructure is that if you have a Database Availability Group (DAG) setup, it can cause issues when doing a switchover or failover to another server. Although it is not critical to the users, you will not want any issues with your server. If something occurs on the server and it fails to do a failover, it will leave your users without access to their mailboxes.
This issue might occur during a migration from an older version of Exchange Server or due to a problem of storage space.
If the issue has been reported by the users that they cannot search on their mailboxes, the only way to identify the issue is by checking the mailbox database copy status. For this, you can use the PowerShell cmdlet Get-MailboxDatabaseCopyStatus in the Exchange Management Shell (EMS).
Get-MailboxDatabaseCopyStatus * | sort name | Select name,status,contentindexstate
This will show the status of the databases and the content index state. If the state shows FailedAndSuspended, then you need to intervene to resolve the problem.
Contents
When your Exchange Server is a standalone server and is not part of a Database Availability Group (DAG), you can rebuild the content index by following the below procedure.
Note: Although this is a simple procedure, you might end up with performance degradation on the server as it is very resource-hungry on the CPU utilization. It is strongly suggested to run this process during a maintenance window or at night or on a weekend.
The first step is to stop the Microsoft Exchange Search and the Microsoft Exchange Search Host Controller services.
This can be done from the services.msc. For this, right-click on the service and then click on stop. Alternatively, this can be done from PowerShell by using the Stop-Service cmdlet (as given below).
Stop-Service MSExchangeFastSearch Stop-Service HostControllerService
The next step is to delete the content index from the path of the database. This can be done by using File Explorer. For this, browse to the folder where the EDB file is stored which corresponds to the database with the problem, and delete the folder with the GUID.
Make sure that the services mentioned above are stopped, otherwise you will not be allowed to delete the folder. If you are unsure of the file path, you can use the PowerShell cmdlet Get-MailboxDatabase to get the file path of the database.
Get-MailboxDatabase <database name> | select EdbFilePath
After you have deleted the folder of the content index, start the services as given below.
You can also use the below PowerShell cmdlet to start the services.
Start-Service MSExchangeFastSearch Start-Service HostControllerService
Now, the services will start crawling and indexing all the content of the database. The indexing may take some time to complete, depending on the size and number of items of the database. Once this is done, re-run the Get-MailboxDatabaseCopyStatus PowerShell cmdlet. You will see the database state as healthy.
When your database is in a Database Availability Group (DAG), you need to run the re-seeding of the database from a healthy database copy. This can be done by using the Update-MailboxDatabaseCopy PowerShell cmdlet (as given below).
Update-MailboxDatabaseCopy <database name>\<source server name> -CatalogOnly -BeginSeed
This operation may take time, depending on the connection between the servers and the size of the database. Once the operation is complete, re-run the Get-MailboxDatabaseCopyStatus PowerShell cmdlet. You will see the ContentIndexState as healthy.
While the above-given procedure resolves the issue, this does not mean that it will work every time. If the issue occurs on a regular basis, it indicates corruption in the database. If this is the case, you can use the Exchange server native tools, such as ESEUtil, to run a database recovery process. However, to do so, the database must be offline.
Alternatively, you can use Stellar Repair for Exchange to repair and export all mailboxes to PST and other formats, while being able to browse the whole database, mailboxes, contacts, calendar, tasks, and journal of each mailbox. By using the Exchange recovery software, you can also export all mailboxes directly to a live Exchange database or an Office 365 tenant, matching the mailboxes and other features.
Ravi Singh is a Senior Writer at Stellar®. He is an expert Tech Explainer, IoT enthusiast, and a passionate nerd with over 6 years of experience in technical writing. He writes about Data Recovery, File Repair, Email Migration, Linux, Windows, Mac, and DIY Tech. Ravi spends most of his weekends working with IoT devices and playing games on the Xbox. He is also a solo traveler who loves hiking and exploring new trails.
