Summary: In this article, we will discuss the “Failed to notify source server about the local truncation point. Hresult: 0xc8000713” error that occurs after adding a copy of a database in a Database Availability Group (DAG) setup. We will learn about the causes behind this error, along with the possible solutions to fix it. We will also mention an Exchange repair software that can help restore data from corrupted database to a new database on live Exchange Server.
In a Database Availability Group (DAG) setup in Exchange Server, you have the main database on the first server. Now, you want to add it to the DAG so that the database will replicate and failover to another server when something happens. However, when you try to add the database to the DAG, the process fails and displays the below message.
The seeding operation failed. Error: An error occurred while performing the seed operation. Error: Failed to notify source server <fqdn of the server> about the local truncation point. Hresult: 0xc8000713. Error: Unable to find the file.
The error message above doesn’t provide much information on how to fix the problem or at least where the problem is.
Why this Issue Appears?
The error may occur if there is a problem with the source server where all your primary databases are or the storage device is full where the mailbox databases are stored. The storage might get full due to large size of the databases or if the transaction logs are not purged after successful daily backup. The size of the database increases if there are empty spaces in it. This can be easily cleared with a PowerShell procedure.
Transaction logs are deleted automatically during a backup after the data is committed to the databases. However, if there is an issue with the backup, the transaction logs will never shrink and continue to accumulate. If this is the case, you should never manually delete the transaction logs as these hold temporary data before committing to the database. If these are deleted manually or by a third-party application, this may cause inconsistency of the data and the databases will fail to mount. It’s also not recommended to enable circular logging.
Possible Solutions to Fix “Failed to Notify Source Server about the Local Truncation Point” Error
Here are some solutions you can try to resolve the “Failed to notify source server about the local truncation point. Hresult: 0xc8000713. Error: Unable to find the file” in Exchange Server.
First, check if there is an issue with the database. For this, you can dismount the database and then mount it back. You can use the Exchange Admin Center (EAC) or the Exchange Management Shell (EMS).
To use EAC, follow these steps:
- Open the EAC. Click on Server and Databases.
- Highlight the database and click on the More Options (…) button.
- Click Dismount.
- To mount the database, follow the same steps but instead of Dismount, select the Mount option.
To dismount the database using the EMS, run the below PowerShell cmdlet:
Dismount-Database -Identity <database name>
To mount the database, run this PowerShell cmdlet:
Mount-Database -Identity <database name>
After this, check if the database is healthy or not. For this, run the following EseUtil command:
Eseutil /mh <path to the edb file name>
If the state of the database is Clean Shutdown, then it is suggested to create a new database in the Exchange Server and migrate all the mailboxes to the new database as there might be an issue with the database. This can only be done if the server has enough space or the server can be provisioned with a new temporary drive (in case of a virtual machine).
However, if the problem is lack of storage space, then you can expand the storage by adding a drive and then execute a backup of the database. This will purge the transaction logs. If, after the backup, the transaction logs are not purged, then this means that the backup solution is not application aware or the feature is not enabled. In this case, you can enable the Windows Server Backup from the Server Manager and run an application-aware backup using the Windows Server Backup.
Another option is to manually purge the transaction logs with DiskShadow. This should be used as a final solution (if you cannot add more storage or move data to free storage). To purge the transaction logs manually, open Command Prompt as Administrator and type the following:
DiskShadow
Add Volume <drive of the mailbox databases>
Begin Backup
Create
When the process is complete, run the below command.
End backup
This will clear the space.
To Conclude
Issues with storage can cause corruption in the database or hinder the operations of the server. Above, we have discussed some possible solutions to resolve the issue. However, if the database is corrupt or not able to mount for any reason, then you can move it to a temporary drive or server share, thus freeing the space on the server. After that, create a new database. Then, you can use Stellar Repair for Exchange to recover the data from corrupt database. This Exchange Server Recovery software can open multiple Exchange Server databases from any version of Exchange Server, with or without a working server. You can do a quick or deep scan of the databases and granularly export the data directly to the newly created database, with automatic mailbox matching, and parallel and priority exports. You can use this software to export user archives, shared mailboxes, disabled mailboxes, and public folders. You can also export the data to Office 365 and file formats, like PST, EML, HTML, and PDF.
