Exchange Server 2019 database fails to mount after reboot (PowerShell commands return Active Manager error)

Imran Qureshi 220 Reputation points
2025-10-31T07:14:55.4166667+00:00

After a recent reboot of my Exchange Server 2019, one of the mailbox databases failed to mount. When I try to mount it using PowerShell with

Mount-Database -Identity "DB01"

I receive the following error:

An Active Manager operation failed. Error: Database copy is in a failed and suspended state.

Running

Get-MailboxDatabaseCopyStatus "DB01"

shows the status as FailedAndSuspended. The disk hosting the database is online and accessible, permissions look fine, and eseutil /mh reports the database as being in a clean shutdown state.

Exchange | Exchange Server | Development
0 comments No comments
{count} votes

Answer accepted by question author
  1. Jack-Bu 5,490 Reputation points Microsoft External Staff Moderator
    2025-10-31T08:22:48.2566667+00:00

    Hello Imran Qureshi

    Thank you for reaching out to Microsoft Q&A forum regarding the issue with your Exchange Server 2019 mailbox database failed to mount after reboot. From what you've described, the database is in a clean shutdown state, the disk is up and running with no permission issues, but it's stuck in FailedAndSuspended status. This happens sometime after a reboot, probably tied to replication or the content index in your DAG. Here something you can try to troubleshoot this (Note: Back up your database before proceeding, and ensure your server is on the latest Cumulative Update).

    First, we need to Gather Detailed Status. Run the following command to collect more information:

    Get-MailboxDatabaseCopyStatus DB01 | Format-List Name, Status, ContentIndexState, CopyQueueLength, ReplayQueueLength, ErrorMessage, ActivationSuspended, LastInspectedLogTime
    

    Also, review the Event Viewer on the affected server:

    • Go to Applications and Services Logs > Microsoft > Exchange > HighAvailability and MailboxDatabaseFailureItems.
    • Around the time of the reboot, look for errors event IDs like 4113 (index issues) or 4114 (replication failures).

    If the issue seems transient, meaning no obvious hardware/log errors from the status or events, start by resuming replication. This often resolves post-reboot suspensions without a full reseed.

    Resume-MailboxDatabaseCopy -Identity "DB01\ServerName"
    

    Wait a few minutes, then check status with Get-MailboxDatabaseCopyStatus. If it becomes Healthy, mount the database with Mount-Database -Identity "DB01"

    If ContentIndexState is Failed or similar, reseed only the catalog with:

    Update-MailboxDatabaseCopy -Identity "DB01\ServerName" -CatalogOnly
    

    It's faster and avoids copying the entire database.

    If all failed, do a full reseed. First suspend, even if already suspended, this ensures a clean start:

    Suspend-MailboxDatabaseCopy -Identity "DB01\ServerName" -Confirm:$false
    #then Reseed:
    Update-MailboxDatabaseCopy -Identity "DB01\ServerName" -DeleteExistingFiles
    

    This may take time depending on your database size.

    I hope this helps resolve your concern. If you have any additional questions, feel free to comment below. I’ll be more than happy to assist.  


    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".      

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.