{"id":48080,"date":"2019-12-30T10:45:00","date_gmt":"2019-12-30T10:45:00","guid":{"rendered":"https:\/\/www.stellarinfo.com\/blog\/?p=48080"},"modified":"2022-08-08T07:26:10","modified_gmt":"2022-08-08T07:26:10","slug":"solve-database-redundancy-two-copy-health-check-failed-in-exchange-2013","status":"publish","type":"post","link":"https:\/\/www.stellarinfo.com\/blog\/solve-database-redundancy-two-copy-health-check-failed-in-exchange-2013\/","title":{"rendered":"How to Solve “database redundancy two-copy health check failed” error in Exchange 2013"},"content":{"rendered":"

Database Availability Group (DAG)<\/a> helps Exchange Server administrators achieve high availability (HA) and site resilience. It provides automatic failover protection and safeguards the Exchange infrastructure from downtime caused by database, server, or mailbox failure. However, it’s important to continuously monitor the DAG to ensure it provides HA when required.<\/p>

Test-ReplicationHealth<\/a> is one of the most used PowerShell to check and monitor all aspects of the database replication, replay, availability of Active Manager, and the health of cluster service, network components, and quorum. It also provides the status of mailbox servers in a DAG environment.<\/p>

When the health check fails with an error, such as ‘database redundancy two-copy health check failed’, it could be a sign of a damaged Exchange database. In such cases, you can check the database status and repair it using an Exchange recovery tool, such as Eseutil or Stellar Repair for Exchange.<\/p>

Below we have explained the issue behind the health check failure and solutions to fix the Exchange database redundancy two-copy health check failed error.<\/p>

Reason for Database Redundancy Health Check Failure<\/strong><\/h4>

It is observed that the error occurs in an Exchange Server DAG setup with two servers running Mailbox, CAS, and Hub roles, which are geo-located with different subnets connected over a site-to-site VPN, Windows Server 2012 R2 and Exchange Server 2013 Standard configured. However, the error may also occur in other Exchange Server versions with similar setups.<\/p>

If you notice the event logs, you will find a number of error messages in the Application log on MSExchangeRepl<\/strong> with event IDs 2059, 2153, and 4113. These are a result of some intermitted issues but will show quite often in the event logs.<\/p>

Database redundancy health check failed.
Database copy: TempDB
Redundancy count: 1
Error: The number of configured copies for database ‘TempDB’ (1) is less than the required redundancy count (2).
Name Status RealCopyQueu InspectorQue ReplayQueue CIState
—- —— ———— ———— ———– ——-
DAG01 MBX Sto FailedAndSusp 111 0 0 Failed
re 1\\EXC02 ended
DAG01 MBX Sto Mounted 0 0 0 Healthy re 1\\EXC01<\/p>

IMPORTANT NOTE:<\/strong><\/p>

In the output of the Test-ReplicationHealth cmdlet, you may see the error code ‘1018 – Database redundancy two-copy health check failed.’ It is important to note that the health check will always fail with two Exchange Server nodes and two copies. Therefore, if you have only two nodes in your DAG setup, you may ignore the 1018 JET_errReadVerifyFailure error<\/a>.  <\/p>

Solutions to Resolve Database Redundancy Two-Copy Health Check Failed Error<\/strong><\/strong><\/h4>

Below we have discussed the workarounds and solutions to troubleshoot and fix the Database redundancy two-copy health check failed error in Exchange DAG.<\/p>

  1. The first thing to do is check the logs. It will help you find what happened from when the Exchange Server was healthy until the issue occurred. Then, any changes made could be identified as the cause of the error.<\/li>
  2. However, if no changes were made that could harm the replication health, check for connectivity issues. For example, you need to check the connection’s speed and if there are any disconnections or lost packets during transit. Also, verify any changes on the network firewall or configuration changes.<\/li>
  3. Also, check that the Active Directory Servers on both sides are functioning properly with the repadmin \/replsummary<\/a><\/strong> to see that replication between sites is fine.<\/li><\/ol>
    \"check<\/figure>


    Then use the \/queue<\/strong> to see if there are any blocked or unprocessed items. Further, run the command with the \/showrepl<\/strong> parameter to see an overview of the Active Directory Partition<\/strong>.<\/p>

    \"check<\/figure>
    \"repadmin<\/figure>