Summary: An Exchange database may display disconnected and resynchronizing errors in a Database Availability Group (DAG). In such a case, you may wait and check the database status again to verify if the error is resolved. However, if the database is stuck showing disconnected and resynchronizing, it indicates an inconsistent or damaged Exchange database. In this guide, we have shared some solutions to fix the error and ensure high availability (HA).
Setting up Exchange Servers in a DAG environment provides automatic failover protection and ensures high availability and site resilience. However, although the DAG setup is quite solid, it?s not infallible, and issues might arise.
One issue that administrators often encounter in a DAG environment is having the primary server working fine with all the databases mounted while the second server shows all databases stuck in a disconnected and resynchronizing state.
Reasons for Exchange Database Stuck in Disconnected and Resynchronizing State
You may encounter the Exchange database in a disconnected and resynchronizing state due to the following issues in the server or DAG:
- Lows storage space.
- Blocked TDP or UDP ports.
- Problem with Active Directory (AD).
- Database corruption.
Below we have discussed a few solutions you may apply to fix the issue.
Solution 1: Restart the Server
Restart the server and check if it resolves the issue. Otherwise, continue following the next solutions.
Solution 2: Check Storage on the secondary server
The first thing to check in such cases is the storage on the secondary server, where you encounter the disconnected and resynchronizing error.
Check if the drive where the Exchange mailbox database and logs are stored is not running out of disk space or has low storage.
In this case, the drive size does matter. Exchange Server always requires at least 25-30% free space on the drive where logs or databases are stored to operate in a standalone or DAG environment. Otherwise, you may encounter such issues, including database dismount and corruption.
Solution 3: Check the Infrastructure of the Setup
If this doesn?t work, one would need to look into the infrastructure of the setup. If the servers are geo-located, the first thing to check is the Active Directory (AD) and DNS on both the primary and secondary sites. An unhealthy or non-replicating DNS isn?t good or recommended.
You can check the Active Directory by running the following commands.
repadmin /replsummary
This will display a summary of the current replication health.
Here you can check if there are fails and errors in the two main sections: Source and Destination DSA.
Also, check if both Active Directories are listed in the Source and Destination DA. If listed, both servers can read and write data between the two servers.
Then run the below command to view if there are any requests stuck. By default, on a healthy AD schema, the queue total will be zero.
Repadmin /queue
Finally, check the GUID of each replicated object and its result. It makes this useful as you might find an object which is not synchronizing
repadmin /showrepl
Solution 4: Check Database
If the above solutions fail to fix the issue, there could be something wrong with the actual database, such as corruption or inconsistencies.
The first thing is to re-trace what happened on the replica server. Usually, a log is kept of any changes done on the server, which by eliminating, one can identify if something has triggered this issue. Also, it could be that either someone has modified something, or it could be an update that has caused this.
Solution 5: Check Firewall changes
Firewall changes should also be checked just in case the network team was doing some lockdown procedure, and by mistake, they have closed a specific port for the DAG to operate. You must ensure no traffic is blocked between the two servers. Most importantly, you must see that the below ports are not specifically blocked.
- TCP port 135 for RPC
- TCP port 64327 for Log Shipping
- UDP port 3343 for Node Communication
Solution 6: Re-Seed the Database Copy
On the replica server, i.e., where you are experiencing the error Exchange database is stuck in disconnected and resynchronizing, dismount the database by opening the Exchange Admin Center. The steps are as follows:
- Click on Servers > Databases.
- Right-click on the affected database and select Dismount.
- You will be prompted to confirm the dismount action.
Once dismounted, remove the passive copy or move it to another location just in case. This way, all the files will be cleared. Finally, clear all files from the location in the secondary node.
Once this is done, move the transaction logs and the system file to the primary site and the CheckPoint or .CHK file to a different folder.
Mount the database via EAC or using the Mount-Database cmdlet.
Once the database is mounted, try adding the database copy to it. This should start the seeding, and the status can be checked by running the PowerShell command Get-mailboxDatabaseCopyStatus.
If everything goes well and everything is working fine, the database should show Mounted and healthy after some time.
However, if anything fails, check the databases with the following command,
ESEUTIL /MH <pathToDatabase>.
You can delete the logs and restart the server if the database state is displayed as Clean Shutdown.
Conclusion
If the methods explained in this guide fail to fix the Exchange databases stuck in a disconnected and resynchronizing state, you would need to recover the mailboxes from the affected database using Exchange recovery software, such as Stellar Repair for Exchange.
The software can easily open a corrupted EDB, repair it and save the mailboxes as individual PST files or multiple formats. You can also export the mailboxes to another or new database on your Exchange Server or import them to Office 365 directly.
It can help restore mailboxes and email connectivity for the affected users in a few clicks.
