Event ID 4113 signals database copy failures in Exchange Database Availability Groups (DAG), meaning your passive database copies are not replicating properly. This guide shows you how to diagnose replication issues and restore database redundancy.
Our DAG Support Team specializes in complex replication issues and database availability.
Error Overview: Database Copy Failures
In a DAG environment, each mailbox database can have multiple copies across different servers. Event ID 4113 occurs when replication between the active copy and a passive copy fails.
# Event ID 4113 Example
Log Name: Application
Source: MSExchangeRepl
Event ID: 4113
Level: Error
Description:
The copy of database 'MailboxDB01' on this server is
failing. Error: The log file could not be copied to
the passive node. The Microsoft Exchange Replication
service will attempt to recover this copy.
Copy Status: Failed
Copy Queue Length: 15842
Replay Queue Length: 0Symptoms & Business Impact
What Admins See:
- Event ID 4113 in Application log
- Database copy status shows Failed or FailedAndSuspended
- High copy queue lengths in Get-MailboxDatabaseCopyStatus
- DAG health alerts from monitoring systems
- Reduced database redundancy
Business Impact:
- Loss of high availability - if active copy fails, no failover target
- Potential data loss during server failure
- Increased backup window due to log accumulation
- Disk space consumption from un-truncated logs
# Quick status check
Get-MailboxDatabaseCopyStatus * | Where-Object { $_.Status -ne "Mounted" -and $_.Status -ne "Healthy" } | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength, ContentIndexState -AutoSize
# Detailed status for specific database
Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01" | Format-ListCommon Causes
1. Network Connectivity Issues (35%)
DAG replication requires reliable network connectivity between members. Firewall changes, network congestion, or replication network failures cause copy failures.
2. Disk Space Exhaustion (25%)
Insufficient disk space on the passive copy prevents log files from being written, causing replication to fail.
3. Log File Issues (20%)
Missing, corrupt, or out-of-sequence log files prevent replication from continuing. May require database reseed.
4. Service Failures (15%)
Microsoft Exchange Replication service crashes or hangs on either the active or passive server.
5. Database Divergence (5%)
The passive copy has diverged from the active and cannot be reconciled without reseeding.
Quick Diagnosis
# Get status of all database copies
Get-MailboxDatabaseCopyStatus * | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength, LastInspectedLogTime, ContentIndexState -AutoSize
# Check for suspended copies
Get-MailboxDatabaseCopyStatus * | Where-Object { $_.Status -like "*Suspended*" }
# Get detailed error information
Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01\Server2" | Format-List *Error*# Test replication health
Test-ReplicationHealth | Format-Table Server, Check, Result, Error -AutoSize
# Check DAG network configuration
Get-DatabaseAvailabilityGroupNetwork | Format-List Name, Subnets, ReplicationEnabled
# Verify replication service
Get-Service MSExchangeRepl | Select-Object Name, Status, StartType# Check disk space on passive server
Get-WmiObject Win32_LogicalDisk | Where-Object { $_.DriveType -eq 3 } | Select-Object DeviceID, @{N='FreeGB';E={[math]::Round($_.FreeSpace/1GB,2)}}, @{N='TotalGB';E={[math]::Round($_.Size/1GB,2)}}
# Check log file status
$db = Get-MailboxDatabase -Identity "MailboxDB01"
$logPath = $db.LogFolderPath
Get-ChildItem $logPath -Filter "*.log" | Measure-Object | Select-Object Count
# Check for log generation gap
Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01" | Select-Object Name, LastLogGenerated, LastLogCopied, LastLogReplayedQuick Fix
# If copy is suspended, resume it
Resume-MailboxDatabaseCopy -Identity "MailboxDB01\Server2"
# Wait and check status
Start-Sleep -Seconds 30
Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01\Server2" | Format-List Status, CopyQueueLength, LastInspectedLogTime
# If status is still failed, restart replication service
Restart-Service MSExchangeRepl -Force
# Re-check status
Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01\Server2"Detailed Solutions
Solution 1: Fix Network Connectivity
# Test connectivity between DAG members
$dagMembers = (Get-DatabaseAvailabilityGroup).Servers
foreach ($member in $dagMembers) {
Write-Host "Testing connectivity to $member..."
Test-NetConnection -ComputerName $member -Port 64327 # Replication port
}
# Check replication network
Get-DatabaseAvailabilityGroupNetwork | Format-List
# If replication network is misconfigured, fix it
Set-DatabaseAvailabilityGroupNetwork -Identity "DAG01\ReplicationNetwork" -ReplicationEnabled $true -IgnoreNetwork $false
# Verify Windows Firewall rules
Get-NetFirewallRule -DisplayName "*Exchange*" | Where-Object { $_.Enabled -eq $true } | Select-Object DisplayName, Direction, ActionSolution 2: Clear Disk Space
# Check what's consuming space
Get-ChildItem -Path "D:\ExchangeDatabases" -Recurse | Group-Object Extension | Sort-Object { ($_.Group | Measure-Object Length -Sum).Sum } -Descending | Select-Object Name, Count, @{N='SizeGB';E={[math]::Round(($_.Group | Measure-Object Length -Sum).Sum/1GB,2)}}
# Truncate logs after successful backup
# (Backup software should do this automatically)
# If logs are accumulating, verify backup is completing
Get-MailboxDatabase | Select-Object Name, LastFullBackup, LastIncrementalBackup
# Move database to larger volume if needed
Move-DatabasePath -Identity "MailboxDB01" -EdbFilePath "E:\Databases\MailboxDB01.edb" -LogFolderPath "E:\Databases\MailboxDB01_Logs"Solution 3: Reseed Database Copy
# First, suspend the copy
Suspend-MailboxDatabaseCopy -Identity "MailboxDB01\Server2" -Confirm:$false
# Delete existing database and log files (be careful!)
$copyStatus = Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01\Server2"
Write-Host "Database path: $($copyStatus.DatabasePathFile)"
Write-Host "Log path: $($copyStatus.LogFolderPath)"
Write-Host ""
Write-Host "WARNING: About to delete database copy files. Press Enter to continue..."
Read-Host
# Remove old files
Remove-Item -Path $copyStatus.DatabasePathFile -Force
Remove-Item -Path "$($copyStatus.LogFolderPath)\*" -Force
# Reseed the database copy
Update-MailboxDatabaseCopy -Identity "MailboxDB01\Server2" -DeleteExistingFiles
# Monitor reseed progress
Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01\Server2" | Format-List Status, CopyQueueLength, ReplayQueueLength, SeedingPercentSolution 4: Fix Content Index
# Check content index state
Get-MailboxDatabaseCopyStatus * | Select-Object Name, ContentIndexState, ContentIndexErrorMessage
# If content index is failed, rebuild it
Update-MailboxDatabaseCopy -Identity "MailboxDB01\Server2" -CatalogOnly
# Monitor rebuild progress
Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01\Server2" | Select-Object Name, ContentIndexState
# Alternative: Reseed just the catalog from another healthy copy
Update-MailboxDatabaseCopy -Identity "MailboxDB01\Server2" -CatalogOnly -SourceServer Server1Verify the Fix
# Check all database copy status
Get-MailboxDatabaseCopyStatus * | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength, ContentIndexState -AutoSize
# Verify copy queue is draining
$start = (Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01\Server2").CopyQueueLength
Start-Sleep -Seconds 60
$end = (Get-MailboxDatabaseCopyStatus -Identity "MailboxDB01\Server2").CopyQueueLength
Write-Host "Copy queue changed from $start to $end"$end"
# Run replication health test
Test-ReplicationHealth | Where-Object { $_.Result -ne "Passed" }
# Verify no more 4113 events
Get-EventLog -LogName Application -Source MSExchangeRepl -EntryType Error -Newest 20 | Where-Object { $_.EventID -eq 4113 }Prevention Tips
Best Practices
- Monitor copy queue lengths proactively (alert at 100+ logs)
- Ensure dedicated replication network with adequate bandwidth
- Maintain minimum 20% free disk space on database volumes
- Verify backup completion to enable log truncation
- Keep Exchange servers patched to same CU level
- Test DAG failover quarterly
When to Escalate
Contact DAG specialists if:
- Database requires multiple reseeds
- Replication failures affect multiple databases
- Copy queue continues growing despite troubleshooting
- Cluster issues complicate DAG operation
- Need assistance with complex network topology
Need Expert Help?
Our DAG Support Team provides comprehensive database availability troubleshooting and optimization.
Frequently Asked Questions
Still Stuck? We Can Help
Our Exchange Server experts have resolved thousands of issues just like yours.
- Remote troubleshooting in 95 minutes average
- No upfront commitment or diagnosis fees
- Fix-it-right guarantee with documentation
Medha Cloud Exchange Server Team
Microsoft Exchange Specialists
Our Exchange Server specialists have 15+ years of combined experience managing enterprise email environments. We provide 24/7 support, emergency troubleshooting, and ongoing administration for businesses worldwide.