In a DAG, sometimes Exchange users encounter an error in which the secondary Exchange database is stuck in disconnected and resynchronizing state. It would cause the failure of the secondary database, and hence, only the primary database is in a healthy condition. The common error query by users looks like this:
Causes of the error
The reasons behind this issue of Exchange database stuck in the disconnected and resynchronizing state could be many. Some of the possible reasons could be:
- Storage space shortage in the secondary server
- Blocked TCP/UDP ports
- Active Directory issues
- Corruption in the database
Try these Manual Solutions
With the above possibilities, you can perform some hit and trial methods to resolve this error.
- Check the Storage: Users can start by checking if the storage quota is filled up. Reach the drive which contains the log files and Exchange database file and check for the available storage in the disk. Enough storage space is a prime requirement for the smooth running of DAG. If the storage space is filled, remove unnecessary data after dismounting the database and remount the database to see if the issue is resolved.
- Check Port Connections: Sometimes unknowingly, ports are blocked by the network team while performing some other operations. Go to the Exchange Server settings and check whether these ports are blocked – TCP port 135 (for RPC), TCP port 64327 (for log shipping), and UDP port 3343 (for node communication). If found blocked, unblock the port.
- Reseeding Failed Database Copy: Try this method if the database copy of the secondary Exchange Server has failed. In this method, the Exchange administrator creates a fresh copy of the failed database using the replication of the other Exchange database.
First, check the health status of the Exchange database copies in DAG by running this command in the Exchange Management Shell.
This command will display Healthy, Mounted, or Failed and Suspended for Exchange database copies.
Now, you got the information which Exchange database copy is not healthy; you can try reseeding that in two ways – Exchange Admin Center and Exchange Management Shell.
Reseeding Failed Database Copy via Exchange Admin Center
Perform these steps.
- Open Exchange Admin Center and go to servers ≫databases. Select the database to be reseeded. On the right panel, you can see the details like database name, state, copy queue length, content index state, and other options. Click Update option.
- On the next Update database copy page, you can click browse and add the source server name (if you want) and click Save.
- The reseed process will get started. Wait for its completion, and after that, check whether the database state is changed.
You can also use cmdlets in the Exchange Management Shell to reseed the failed database copy.
Run this command to update the suspended database (if you are defining a source server)
Update-MailboxDatabaseCopy ” < enter Mailbox Database name > ” -SourceServer < enter source server name >
Execute this command for the update of the database (if the server is not defined).
Update-MailboxDatabaseCopy ” < enter Mailbox Database name > ”
After executing these commands, if you encounter any error for log files that these are already existing.
Update-MailboxDatabaseCopy ” < enter Mailbox Database name > ” – DeleteExistingFiles
It would delete the existing log files before starting the reseeding process.
The above discussed manual solutions could help you fix the issue of Exchange database stuck in disconnected and resynchronizing state. But if the corruption of the database is the cause behind this error, then we would recommend you go for an Exchange database recovery solution.
Recoveryfix for Exchange Server Recovery tool is a professional Exchange recovery tool that recovers corrupt or damaged Exchange database files to PST, live Exchange Server, or Office 365. It supports all Exchange Server versions, from oldest to newest, and supports selective data recovery. To learn its working, you can download its trial version for free from the website.
Due to different reasons like blocked ports, database corruption, storage issues, etc., there could be disconnected state and resynchronizing issue with an Exchange database copy in a DAG. Different methods can be tried to fix this issue. However, if the problem is database corruption, we recommend a good Exchange database recovery solution.
Read Related Blog
- Fix the ‘mailbox export request stuck in queued’ issue in Exchange
- How to Resolve Exchange Error 1018?
- Fix the Low Disk Space Issue in Exchange Server Database