Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix Event ID 2059

Event ID 2059: log shipping stops when the DAG replication network breaks

9 min read Updated October 4, 2026 Exchange Server

Fix it now

Log shipping needs a working network path between members and a working cluster underneath. Check the cluster before you blame replication: if quorum has gone, nothing can decide which copy is active and replication stops as a consequence rather than as a cause.

Run these on a member of the group, in the Exchange Management Shell

Get-ClusterNode
Get-ClusterQuorum
Get-MailboxDatabaseCopyStatus * | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength
Get-DatabaseAvailabilityGroup DAG1 | Format-List ReplicationPort
Get-DatabaseAvailabilityGroupNetwork -Identity DAG1
  1. Test the path between two members on the replication port. Microsoft documents the default as TCP 64327 where ReplicationPort has not been set.
  2. Confirm each DAG network shows its subnets and interfaces as up, and that name resolution returns the address you expect on each network.
  3. If the cluster or the witness is the problem, fix that first. Replication rides on top of both and will not recover until they do.
  4. Once the path is back, resume any suspended copies and let the queues drain before you consider reseeding anything.
  5. Run Test-ReplicationHealth on each member afterwards and work through anything it flags.

Microsoft publishes no description for the replication event in this article’s title. Read the entry on your own server for the member and network it names, and use it to decide which path to test.

If the queues drain and the cluster is stable, you are done. If members keep dropping, the next section covers the cluster events that mean the fault is underneath Exchange.

Why it happens

A passive copy pulls closed log generations from the server hosting the active copy, over TCP on the group’s replication port, and replays them into its own database. That transfer needs a working network path in both directions, working name resolution, and a running replication service at each end. It also needs the cluster, because membership and the decision about which copy is active come from there rather than from Exchange.

Microsoft documents the replication port precisely: if ReplicationPort is not specified, the default port for replication – log shipping and seeding – is TCP 64327. That is the port to test between members, and it is worth confirming the value on your own DAG rather than assuming, because someone may have set it.

When the cluster goes, the picture changes completely. Event ID 1177 from Microsoft-Windows-FailoverClustering has a published description and it is unambiguous: the Cluster service is shutting down because quorum was lost, which could be due to the loss of network connectivity between some or all nodes, or a failover of the witness disk. Microsoft’s own resolution starts with running the Validate a Configuration wizard against the network tests. That is a cluster problem, and reseeding databases while it is unresolved achieves nothing.

The replication network path is down or filtered

You have this one if One member cannot be reached on the replication port while the client network to the same server works normally.

  1. Test the port in both directions between the affected members, not just one way.
  2. Check the interfaces and subnets the group has discovered, and confirm nothing has changed on the switch, the virtual switch or the host firewall.
  3. Confirm name resolution returns the address you expect for each member on each network.
  4. Once the path is restored, watch the copy queue drain rather than reseeding straight away. A copy that can still catch up should be allowed to.

A dedicated replication network is optional. A single well-provisioned network that somebody monitors is a more reliable design than two networks nobody watches.

The cluster heartbeat is failing intermittently

You have this one if Members drop out and rejoin, and the failover clustering log shows connectivity lost and restored repeatedly.

  1. Read the sequence in Applications and Services Logs, then Microsoft, then Windows, then FailoverClustering, around each drop.
  2. Check for a maximum transmission unit mismatch, which is common where jumbo frames are enabled on some hops and not others and produces exactly this pattern.
  3. Review adapter teaming, offload settings and any power saving on the adapters. Microsoft’s guidance for nodes leaving cluster membership starts with the network configuration and adapter hardware.
  4. Where members sit in different sites, review the cluster’s cross-subnet delay and threshold settings against the real latency between them.

The witness is unavailable or lacks its rights

You have this one if A group with an even number of members that will not hold quorum, and witness arbitration failures in the cluster log.

  1. Confirm the witness server is running and reachable by name from every member, and that the share exists.
  2. If the witness server is not itself an Exchange server, Microsoft requires the Exchange Trusted Subsystem universal security group to be in the local Administrators group on it, so that Exchange can create the directory and share.
  3. Enable the Windows Firewall exception for File and Printer Sharing on the witness. Microsoft documents that the witness uses SMB port 445.
  4. Reconfigure it with Set-DatabaseAvailabilityGroup -Identity DAG1 -WitnessServer <server> -WitnessDirectory <path>. The witness cannot be a DAG member, must be in the same forest, and each DAG needs its own witness directory.

The replication service is stopped on a member

You have this one if A copy reports its service down while the server is otherwise healthy.

  1. Check the Microsoft Exchange Replication service on that member and start it if it is stopped.
  2. Confirm the member is not still in maintenance mode from a patch window. A member left in maintenance looks exactly like a fault.
  3. Run Test-ReplicationHealth on the member afterwards and work through anything it flags.

Full reference

What is published and what is not

Entry Source Published description
Replication network event Exchange None. Read the member and network your own entry names
Event ID 1177 Microsoft-Windows-FailoverClustering The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk
Witness arbitration event Microsoft-Windows-FailoverClustering None found. Work from the documented witness requirements instead

Microsoft’s symbolic name for 1177 is MM_EVENT_ARBITRATION_FAILED, and the documented causes are loss of network connectivity between nodes, a failover of the witness disk, and configuration changes such as adding nodes when too few are online to achieve quorum in the new configuration. That last one catches people out after a DAG grows.

Witness requirements, in full

  • The witness server cannot be a member of the DAG.
  • It must be in the same Active Directory forest as the DAG.
  • A single server can act as witness for several DAGs, but each DAG needs its own witness directory.
  • If it is not an Exchange server, the Exchange Trusted Subsystem universal security group must be added to its local Administrators group before the DAG is created.
  • If Windows Firewall is enabled on it, the File and Printer Sharing exception must be enabled; the witness uses SMB port 445.
  • Set-DatabaseAvailabilityGroup can be used to reconfigure the witness server and directory if the witness lost its storage or someone changed the share permissions.

Reading the pattern before you touch anything

What you observe Where the fault is
Queues grow against one member only That member’s network path, or its replication service
Every copy stops at the same instant A shared network segment, or the cluster
Quorum lost logged by the cluster Quorum, not replication. Fix the cluster first
Witness arbitration failing The witness share, its rights, or the firewall on the witness server
Replication continues but slowly The path is saturated, or replication has moved onto the client network

Where to look afterwards

The HighAvailability crimson channel records startup and shutdown of the Microsoft Exchange Replication service and its components, Active Manager role monitoring, database action events such as mounts and log truncation, and events about the DAG’s underlying cluster. MailboxDatabaseFailureItems records events associated with failures affecting a replicated database. Between them they tell you what the group did while the network was down, which is usually the question that matters once it is back.

Every code this article covers

Code What it points at Source
Event ID 2059 No description is published by Microsoft. Read the member and network your own entry names, then test that path on the replication port and check the cluster not published by the vendor
Event ID 1177 The Cluster service is shutting down because quorum was lost, which could be due to loss of network connectivity between nodes or a failover of the witness disk. Source Microsoft-Windows-FailoverClustering, symbolic name MM_EVENT_ARBITRATION_FAILED Microsoft Learn
Event ID 1564 No description is published by Microsoft. Treat a witness arbitration failure as a witness problem and work through the documented witness requirements: rights, share, firewall exception and SMB port 445 not published by the vendor

Confirm the fix worked

  1. Get-ClusterNode shows every member up and Get-ClusterQuorum reports the configuration you intended.
  2. Copy and replay queues have drained to near zero on every copy.
  3. Test-ReplicationHealth passes on each member.
  4. No further quorum or replication entries appear over the following day.

Questions people ask about this

Does fixing this cost anything?

No. This is network and cluster configuration, and every tool involved ships with Windows Server and Exchange. The only thing that costs money here is the network itself.

Which port should I be testing?

The DAG’s replication port. Microsoft documents TCP 64327 as the default where ReplicationPort has not been set, but read the value on your own DAG rather than assuming.

Do I need a separate replication network?

No. A single well-provisioned network is supported, and a second network nobody monitors adds failure modes rather than removing them. If you run one, monitor it as carefully as the client network.

Should I reseed once the network comes back?

Not immediately. A copy that is behind but intact will catch up on its own, and reseeding throws away a working copy to rebuild it across the network you have just repaired.

Why did the databases dismount when only the network broke?

Because the cluster lost quorum. Microsoft’s own description of that event says the Cluster service shuts down deliberately when quorum is lost, which stops two halves of a partitioned group both deciding they are in charge.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error Event ID 9646: a client blew past the Exchange session or object limit Free Fix MapiExceptionLogonFailed: the store rejects a MAPI logon for this mailbox License Error 550 5.7.64 TenantAttribution: Exchange Online refuses relay from your server License Error Error 1638: another Exchange version blocks this cumulative update install
← Back to Knowledge Base