{"id":74699,"date":"2021-02-16T05:19:35","date_gmt":"2021-02-16T05:19:35","guid":{"rendered":"https:\/\/www.stellarinfo.com\/blog\/?p=74699"},"modified":"2023-10-26T10:15:34","modified_gmt":"2023-10-26T10:15:34","slug":"database-availability-group-must-have-quorum-error","status":"publish","type":"post","link":"https:\/\/www.stellarinfo.com\/blog\/database-availability-group-must-have-quorum-error\/","title":{"rendered":"How to Fix \u201cDatabase Availability Group must have Quorum\u201d Error?"},"content":{"rendered":"

A Database Availability Group (DAG) works great for failover and high availability for your Exchange Server and services. Although this is the best solution around for Exchange Server business continuity and disaster recovery, you may encounter some unforeseen issues that might hinder the performance, quality, and data integrity of the Exchange Server infrastructure.<\/p>

One of the worst scenarios that an Exchange Administrator might encounter is when a mailbox database is dismounted. When you try to mount the database, you may encounter the following error:<\/p>

Failed to mount database “DB01<\/strong>“. Error: An Active Manager operation failed. Error: An Active Manager operation encountered an error. To perform this operation, the server must be a member of a database availability group, and the database availability group must have quorum. Error: Unable to read from the cluster database. <\/p>

This may occur if the server has recently been removed from the database availability group.<\/p>

[Server: EX2019.mail.lan<\/strong>]\n+ CategoryInfo<\/strong> : InvalidOperation: (DB01:ADObjectId) [Mount-Database], InvalidOperationException\n+ FullyQualifiedErrorId<\/strong> : [Server=EX2019,RequestId=c51a831c-33e3-4a75-867f-51433b925ee2,TimeStamp=1\/1\/2020\n4:13:12 AM] [FailureCategory=Cmdlet-InvalidOperationException] 7E29F70A,Microsoft.Exchange.Management.SystemConfigurationTasks.MountDatabase\n+ PSComputerName<\/strong> : EX2019.mail.lan<\/pre>
The above error could happen due to various reasons. Some of the reasons are:<\/p>
    \n
  • An update gone wrong<\/li>\n\n\n\n
  • Human error<\/li>\n\n\n\n
  • Hardware failure<\/li>\n\n\n\n
  • Power loss<\/li>\n\n\n\n
  • Malware and ransomware attack<\/li>\n\n\n\n
  • Corruption or storage issues<\/li>\n\n\n\n
  • Failure on the server’s storage unit<\/li>\n<\/ul>
    Fix “Database Availability Group must have Quorum” Error<\/strong><\/h2>
    The first thing to check is that you have the voting majority in your cluster. It means that you have half of your servers, plus one online and all participating servers are healthy and running. Also, you need to check that the storage of each node, along with the services of Exchange and the Cluster Service, are running and no errors occurred. If you have suffered a hardware issue that has powered down the server, this might be an issue as the DAG cannot function with one server, out of three. Like in other clusters (for example, SQL), if the voting majority is not reached, the cluster will shutdown as a safety precaution.<\/p>
    If all troubleshooting has been done and there is nothing you can do to restore the services back to normality, the only option is to remove the database copies so that the server would be in single database mode.<\/p>
    This can be done by running the Remove-DatabaseAvailabiltyGroupServer<\/strong> command from the Exchange Management Shell. This command will clear off any DAG entries from the Active Directory.<\/p>
    Note:<\/em><\/strong> There is no need to back up everything beforehand as this will remove just the configuration.<\/em><\/p>
    Remove-DatabaseAvailabilityGroupServer -ConfigurationOnly -MailboxServer SRV-MBX-01 -Identity DAG001<\/p>
    This process needs to be performed on every node. So, if your Database Availability Group (DAG) is made up of two servers, you need to perform the above on both servers.<\/p>
    \n
    \"Database<\/figure>\n<\/div>
    Once this operation is done, the Database Availability Group (DAG) configuration will be removed from the Active Directory.<\/p>
    The next step is to evict the nodes from the Windows Cluster. But you cannot use the Cluster Manager for this operation. It must be done by using the PowerShell. The operation is quite simple as you just need to use the Get-ClusterNode<\/strong> and the Remove-ClusterNode<\/strong> using the force parameter (as per the below example).<\/p>
    Get-ClusterNode <server name> | Remove-ClusterNode -Force<\/p>
    If the Exchange Server setup for the Database Availability Group (DAG) is made up of two or more server, you would need to perform this for each node in your cluster.<\/p>
    \n
    \"node<\/figure>\n<\/div>
    After this, any configuration of the Database Availability Group is removed from the Active Directory Schema and the setup should be converted as stand-alone server. This means that after a reboot of the servers, the database should mount as it is cleared from any Database Availability Group (DAG) membership.<\/p>
    What to do if the Databases still not Mount?<\/strong><\/h2>
    Now, if we’re saying that the databases should be mounted with no issues, it implies that no damage has occurred to the databases. If the databases still not mount, you might consider checking the databases by using the native tools that come with Exchange Server, such as the ESEUtil<\/strong>.<\/p>
    ESEUtil<\/a> is a native tool which identifies issues and tries to repair corrupted databases. It must be run from within a command line interface.<\/p>
    To identify if the database has any damage, you need to run the ESEUtil with the \/mh<\/a> parameter and check the state of database. A healthy database would have Clean Shutdown state,<\/strong> while a damaged database will show Dirty<\/strong> Shutdown<\/strong>.<\/p>
    EseUtil \/mh <exchange database file><\/p>
    \"Clean<\/figure>
    ESEUtil offers two database recovery options – Soft Recovery and Hard Recovery<\/a>. The Soft Recovery process, as the name implies, runs a soft\/quick recovery of the database. If the damage is light, the Soft Recovery will try to fix the issue.<\/p>
    If this fails and the database state remains in Dirty Shutdown<\/a>, this means that the corruption is severe. In such a case, the only solution is to restore the databases from backup. But this will result in data loss as you’re only able to restore data from the last backup. The other option is to perform the Hard Recovery. This also results in data loss as Hard Recovery process deletes any data which is deemed corrupted. On the other hand, Microsoft will not assist you if the database is found hard recovered. In addition, there is no guarantee that the database will mount afterwards.<\/p>
    As a healthy alternative, you can use a third-party application, like Stellar Repair for Exchange<\/strong> that can easily open any Exchange Server version database in any state and you will be able to read and browse the EDB file. You will be able to export the data to PST and other formats. The Exchange Server recovery software<\/a> also has a feature to export directly to a live Exchange Server database or Office 365 tenant.<\/p>