How to Fix Resource CiAgeOfLastNotification is Unhealthy Error

When moving mailboxes from on-premises Exchange Server to another server or Exchange Online, you may face various issues and errors. One such error message that you may encounter while moving or offloading a mailbox or mailboxes is:

Resource ‎'CiAgeOfLastNotification‎(System)‎‎' is unhealthy and shouldn‎'t be accessed

This error can occur in one of the following scenarios:

• You have a hybrid model configured between your on-premises Exchange Server and Exchange Online for migration. The full hybrid model is configured with the certificates and all the connectors are in place. You are trying to move the mailbox to Exchange Online.
• You have another Exchange Server and you are moving a mailbox to a database on the same server or another server.

Solutions to Fix the Resource ‎’CiAgeOfLastNotification‎(System)‎‎’ is Unhealthy Error

Usually, this error message occurs when an index on the on-premises server or the source server is corrupt. Let’s see how to restore the index to a healthy state and fix the error.

• First, you need to determine if the issue you are facing is only with one specific mailbox or all the mailboxes in the database. To test this, you can move another existing mailbox or a new mailbox.
• Restart the Microsoft Exchange Server Search and the Microsoft Exchange Search Host Controller. You can do this via the Services Manager. Right-click the service and then click on the Restart.
• Alternatively, you can use the below PowerShell commands to restart the Microsoft Exchange Server Search and the Microsoft Exchange Search Host Controller services.

Restart-Service MSExchangeFastSearch

Restart-Service HostControllerService

• Now, try to re-initiate the mailbox move after the status of the services is showing as running.

If the problem persists, it means that the index of the source database is corrupt. In this case, you need to reseed the content index.

• If the database is part of a Database Availability Group (DAG), you can reseed the content index by following the given command.

Update-MailboxDatabaseCopy -Identity <database name>\<server name> -CatalogOnly

• This will reseed the Exchange database from any member of the availability group. For example, if there are three server nodes and there is a copy of the database on all the servers, the above command will reseed all the three copies.
• If you want to reseed a specific copy on a specific server, you can use the below command, specifying the source server. This command will only reseed the copy on the specified source server.

Update-MailboxDatabaseCopy -Identity <database name>\ <server name>-SourceServer <server name>-CatalogOnly

• If there is standalone Exchange Server setup, the process is different. First, you need to stop the services via the Services Manager or using the PowerShell command as given below.

Stop-Service MSExchangeFastSearch

Stop-Service HostControllerService

• Once the services are stopped, you need to delete the folder containing the Exchange content index catalog. You can delete it, rename it, or move it to another location for safekeeping. The folder path is as follows:

%ExchangeInstallPath%Mailbox\<name of mailbox database>_Catalog\<GUID>12.1.Single

• After the folder is removed or moved, you can go ahead and start the services using the below command.

Start-Service MSExchangeFastSearch

Start-Service HostControllerService

• Once this is done, you can check if the process has finished or not by running the below command.

Get-MailboxDatabaseCopyStatus | FL Name,Index

• Now, you need to check the Content Index state. During reseeding, it will be in a Crawling state. When it is complete, it will be shown as Healthy.

Once the status of the content index is Healthy, you can retry to move the mailbox. 

To Conclude

If you see the Content Index state as failed or suspended, it indicates severe corruption in Exchange database. If this is the case, you can use ESEUtil to perform smooth recovery. It can help in fixing minor corruption issues in the database. If this doesn’t work, you can try the hard recovery. However, it is highly not recommended as it will just purge any data which is deemed as corrupted, resulting in data loss. The other option is to restore from backup but it will also result in data loss.

Alternatively, you can take the help of an Exchange Server recovery application, such as Stellar Repair for Exchange. With this application, you can open the corrupt Exchange Server databases (EDB) with no size limit and from any version of Exchange Server. You can browse through the structure of the database. Then, you can export the recovered database directly to a live Exchange Server or Office 365 with ease and without any data loss.