You may experience similar problems in version from Exchange 2010, here I have showcased an issue I faced in Exchange Server 2016 infrastructure.

You will see one or more of the following events/status on the server,

Event IDs 4026, 1009 etc.
Log Name:      Application
Source:        MSExchangeRepl
Event ID:      4026
Level:         Error
[Seed Manager] The seed request for database 'LAB-DB01' encountered an error during seeding. Error: An Exception was received during a FAST operation.


Log Name:      Application
Source:        MSExchangeFastSearch
Event ID:      1009
Task Category: (1)
Level:         Warning
The following information was included with the event:
Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed. ---> Microsoft.Exchange.Search.Engine.FeedingSkippedException: "Feeding was skipped for '45fc6bd2-7221-4c3d-8314-4e6e75473703 (LAB-DB03)' due to the state 'Unknown', error code: 'Unknown'."


This issue can cause due to many factors, and most cases it can be mitigated by Solutions mentioned in the next section.

The reasons for this issues could be one or more of the following, but not limited to

  1. Issues with “Microsoft Exchange Search” (MSExchangeFastSearch) Service
  2. Issues with “Microsoft Exchange Search Host Controller” (HostControllerService) service.
  3. Corrupt Content Index
  4. Hard disk errors (read/write)

How to mitigate this issue, follow as suggested below!

Solution 1

Generally, this issue can be mitigated in one of the two list options below,

Option 1:

Consider you do not have any database copies with healthy Index State or the only server that host the database.

Stop the following services,

Microsoft Exchange Search Host Controller
Microsoft Exchange Search

Delete the folder similar to the following from database path/location.

Delete Folder

Start the Services in order,

Microsoft Exchange Search
Microsoft Exchange Search Host Controller

The Exchange Server will initiate the process to rebuild the whole index. Depends on the data/size the process may take extended period of time. Wait for the process to finish, and in 90% of the case it will fix the issue.

Option 2:

If you have one “healthy” Content Index state database copy, reseed the database copy that has the unhealthy copy of content Index. In some cases when you add database copy in the DAG, the content index can go into unhealthy status (such as failed, unknown, failedandsuspended etc). To recover the content Index back to healthy, you can reseed the content index by running the “Update-MailboxDatabaseCopy” command with switch “-CatalogOnly”.

Update-MailboxDatabaseCopy LAB-DB03\EX16-01 –CatalogOnly

If you already tried this command, you may get the warning “Seeding cannot be requested for the same database copy until the failed request has been cleaned up by the server …”. Please say “y” to proceed with the reseed operations.

Verify the ContentIndexState after sometime, you will see a “healthy” state.

Solution 2

If the above steps did not go through fine, and if you receive errors similar to below even if all these services are healthy then it will be not an easy task to bring back your ContentIndexstate to healthy.

WARNING: Seeding of content index catalog for database 'LAB-DB03' failed. Please verify that the Microsoft Search (Exchange) and the Host Controller service for Exchange services are running and try the operation again. Error: An error occurred while processing a request on server 'EX16-03'. Error: An Exception was received during a FAST operation..

In some cases, there are disk errors but in my case the server was recovered from a unexpected failure which lead to run recovery steps on the database. Post the recovery the ContentIndexState was in healthy status in some database copies, but did not work quite fine in others.

Please note that the Content Index State only impact the end user experience, you are still allowed to mount the database on server where the Content Index State is not healthy. Hence the recommended approach is to create additional database and move the mailboxes gradually to get rid of the problematic database.

In my case, I also had the following event (Event ID 40025) logged on the server where this database was active.

Source:        MSExchangeIS
Event ID:      40025
Task Category: High Availability
Level:         Error
       Database LAB-DB03 (45fc6bd2-7221-4c3d-8314-4e6e75473703) has been offline-repaired (by eseutil.exe) one or more times in the past. However, although this ensures database-level logical consistency and may permit the database to be successfully mounted, Exchange-level logical consistency can no longer be guaranteed. Therefore, all mailboxes should be evacuated from the database and the database should be retired as soon as possible in order to eliminate the potential for unexpected behaviour caused by Exchange-level logical inconsistency.      
This event will continue to be emitted once per hour while the database is mounted as an urgent reminder to evacuate and retire the database as soon as possible.      
Database last repaired: 3/15/2017 7:04:00 AM      
Repair count since the database was last offline-defragmented: 2      
Repair count before the database was last offline-defragmented: 0      
Recovery database?: False    
Please note that the above events and actions are based on Exchange Server 2016 infrastructure, however the operations are almost stays the same in other versions from 2010 onward.

Please share you comments or issues.



Published in Solutions

MS has recently released the Service Pack 2 for the Exchange Management Pack, and the same has been now temporarily removed from the Download Center due to the issue of mailbox quarantining when the free space availability on the Transaction Log Drive is low.

You may see the following entries on your event log, if you are affected with this issue.

Log Name: Application
Source: MSExchangeIS
Event ID: 10018
Task Category: General
Level: Error
The mailbox for user <guid>: /o=Contoso /ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserMailbox has been quarantined. Access to this mailbox will be restricted to administrative logons for the next 6 hours.


Log Name: Microsoft-Exchange-Troubleshooters/Operational
Source: Database Space
Event ID: 5410
Level: Warning
Keywords: Classic
The database space troubleshooter quarantined mailbox <guid> in database <DBName>.

To know more about this issue, read the below blog from Exchange Team.

Mailboxes on a database are Quarantined in an environment with System Center Operations Manager


Published in Solutions
theme by reviewshub