Having an Exchange Server setup is great but having the ability of failover and replication is even better. Exchange Server can be configured using Database Availability Groups where two Exchange Servers can be joined together to form one Exchange access server with database copies on each side.
Thou this setup is quite solid, it’s not infallible and issues might arise. One issue in particular is when having the primary server working fine with all the databases mounted and the secondary showing all databases stuck in disconnected and resynchronizing.
This may happen due to storage space, blocked TDP or UDP ports, problem with AD or database corruption. Below we have discussed a few solutions that you may apply to fix the issue. You may also want to check and repair database if this has occurred due to database corruption. You can use a reliable Exchange recovery tool, such as Stellar Repair for Exchange to repair the database, extract mailboxes and then save them to PST or restore them to a database on live Exchange server.
Check Storage on the secondary server
First thing to check in such cases is the storage on the secondary server and see if the drive where the Exchange data and logs are residing is not running out of disk space. Size does matter and enough free space is necessary to operate a DAG or else it will not be a healthy one.
After trying to dismount and remount the database and not being successful, another thing to test thou obvious and maybe a bit silly is to restart the secondary server since it would not affect any users.
Check 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 and DNS on both the primary and secondary site. An Unhealthy DNS or non-replicating DNS will not do you good. Checking the Active Directory can be done by running the following commands.
This will shows a summary of the current replication health. Here you can check if there are fails and errors on the two main sections being Source and Destination DSA. Both Active Directory are listed both in the Source and Destination DA. This means that both servers can read and write data to between the two servers.
This will show is there are any requests stuck. By default on a healthy AD schema the queue total will be zero.
The above will show the GUID of each object that was replicated and its result making this useful as you might find an object which is not synchronizing.
Now if this fails then we must assume there is something wrong with the actual database. As there might be some kind of corruption in it. 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 eliminate one can identify if something has triggered this issue. Usually it could be that either someone has modified something or it could be an update which has caused this.
Check Firewall changes
Firewall changes should be also checked just in case the network team was doing some lock down procedure and by mistake they have closed a specific port for the DAG to operate. You need to make sure that no traffic is blocked between the two servers but 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
One last option is to reseed the database copy by following the below steps:
On the replica server i.e.where you would be having the issue, you need to dismount the database by opening the Exchange Admin Center, click on Databases, right-click on the database effected and select Dismount, you will be prompted to confirm this.
Now, remove the passive copy or move it to another location just in case. This way all the files will be cleared. Clear all files from the location in the secondary node.
Once this is done, on the primary site move the transaction logs and the system file which is the CHK file to a different folder. Mount the database. Once the database is mounted try adding the database copy on it. This should start the seeding and the status can be checked in by running the PowerShell command Get-mailboxDatabaseCopyStatus.
If all goes well and everything is working fine, after some time the database should show Mounted and healthy. Thou if anything fails, check the databases with ESEUTIL / MH if it is in clean shutdown, and you can delete the logs and restart the databases. If it fails then you would need to explore and extract any information from a corrupted EDB.
Stellar Repair for Exchange can easily open a corrupted EDB, offer a comfortable GUI where you can explore the EDB object and items, search for specific items and export to PST and other formats. The application can also export directly from an Exchange EDB file to a live Exchange database or Office 365 tenant.