Exchange DAG in witness failed state – How to fix?

Read time 4 minutes

Microsoft Exchange Server offers a robust and dependable infrastructure designed to ensure high availability and resilience, capable of handling a wide array of challenges while delivering uninterrupted user access. Within this infrastructure, the Database Availability Group (DAG) plays a pivotal role, comprising multiple mailbox servers, which can scale up to 16 servers, dedicated to hosting databases. The DAG operates with an automatic database-level recovery system, equipped with a failover mechanism that ensures continuous data accessibility.

Witness server in database availability group

When the DAG comprises an even number of members, a witness server plays a pivotal role. It operates externally to the DAG and serves to establish and maintain quorum. In contrast, DAGs with an odd number of members do not necessitate the use of a witness server. However, it’s important to note that all DAGs featuring an even number of members must have a witness server in place. Fortunately, this requirement is versatile, as any PC running Windows Server can fulfill the role of the witness server. Moreover, the operating system of the witness server need not be of the same Windows Server version as that of the DAG members.

Following the successful update of your Windows Server and subsequent restart of the Exchange Server, it’s possible that you might encounter a warning or error when verifying the status of the database availability group (DAG).

This is the cmdlet:

Following the execution of the command, a warning message will be displayed in the following manner:

WARNING: Database availability group <Database-Availability-Group-Name> witness is in a failed state. The database availability group requires the witness server to maintain quorum. Please use the Set-DatabaseAvailabilityGroup cmdlet to re-create the witness server and the directory.

The warning message explains the correct method to recreate the witness server using the Exchange Management Shell cmdlets.

Note: The cmdlet will work only in on-premises Exchange Server.

Now, run the first cmdlet, and it will run without any warning or error.

You can change the Witness server in the Exchange Admin Center too.

1. Select “Servers” > “Database Availability Groups” in EAC.
2. After choosing the DAG, click the edit icon.
3. Click Save after entering the new witness server’s FQDN and new witness directory path.

Check the server’s name under servers > database availability groups to confirm the DAG witness server. Additionally, make sure the witness server’s witness directory is correctly built.

There are some great practices to put the witness server in the data center when the single or multiple Database Availability Groups.

Conclusion

The DAG’s witness server plays a pivotal role in maintaining quorum integrity. However, the failover clustering can become compromised if the witness server experiences downtime or failure following a reboot, resulting in a “failed witness server” state. In such critical situations, you have two options: either attempt to restore the witness server to an operational state or transition to an alternate witness server and directory. To mitigate potential issues arising from a member server malfunction during this process or database dismount due to discrepancies, you can leverage your Exchange Server backup for database and mailbox restoration.

If you haven’t yet backed up the most recent server changes, your optimal course of action is to initiate a database repair and mailbox recovery. Exchange EDB Recovery offers a dependable solution for maintaining database integrity through thorough corruption scanning and live-saving capabilities within Exchange Server. With a range of data storage options at your disposal, you can also review the preview of recovered items post-scan for added confidence.