Exchange DAG: Setup, Failover & Troubleshooting

Our Exchange Server support team works on DAG cases daily: failed database copies, lost quorum, and stalled failovers. This page documents how a Database Availability Group works, what a correct setup requires, how failover behaves, and the repair sequence for the common failure states.

What a DAG is

A Database Availability Group is a set of up to 16 Mailbox servers that hosts copies of the same mailbox databases and provides automatic database-level recovery from database, server, or network failures. Per the official documentation, a DAG uses continuous replication: the server holding the active copy of a database ships transaction log files to the servers holding passive copies, and each passive server replays those logs into its own copy of the database file. Each database can have one active copy and up to 15 passive copies at any time.

The DAG is built on Windows failover clustering, but the cluster is managed by Exchange, not by the administrator. Cluster membership, quorum configuration, and failover decisions are handled by a component called Active Manager, which runs inside the Microsoft Exchange Replication service on every DAG member. On Windows Server 2012 R2 and later, DAGs are created without a cluster administrative access point by default, which means no cluster name object and no cluster IP address to manage.

Components

Setup requirements and steps

Requirements before creating a DAG:

• All members run the same Exchange Server version and the same operating system version.
• The DAG name is a valid computer name of 15 characters or fewer, unique in the forest.
• A witness server is designated that is not, and will not become, a DAG member.
• Each member has the same number of networks and consistent storage paths, since database and log paths must be identical on every server holding a copy.
• Members should have no more than one MAPI network and, optionally, dedicated replication networks.

The sequence, per the DAG management documentation:

1. Create the DAG object: New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer FS1 -WitnessDirectory C:DAG1. Omitting IP parameters on Windows Server 2012 R2 or later creates the DAG without an administrative access point, which is the recommended configuration.
2. Add members: Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1, repeated per server. The first add installs the failover clustering feature and creates the cluster; subsequent adds join it and adjust the quorum model automatically.
3. Add database copies: Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer EX2 -ActivationPreference 2. Per the Add-MailboxDatabaseCopy reference, this triggers an automatic seed of the new passive copy from the active copy.
4. Verify: Get-MailboxDatabaseCopyStatus DB1 should show the new copy as Healthy with a content index state of Healthy and a copy queue length near zero.

Failover behavior

Two distinct operations move an active database:

• Switchover — an administrator-initiated move, run with Move-ActiveMailboxDatabase DB1 -ActivateOnServer EX2 for one database or with the server-level form for all databases on a member. Used for maintenance. No data loss is expected because the source is healthy and logs are fully shipped before the move completes.
• Failover — an automatic reaction to a failure. When the active copy or its server fails, the Primary Active Manager selects a passive copy and mounts it.

The selection process is called best copy selection (BCS). Per the Active Manager documentation, Exchange 2013 and later actually perform best copy and server selection (BCSS): candidates are sorted by copy queue length, replay queue length, and database copy status, checked against protocol health, and activation preference is used as the tie-breaker. Copies blocked by activation policy (Suspend-MailboxDatabaseCopy -ActivationOnly or server-level activation blocks) are skipped. The attempt-copy-last-logs process then tries to copy any missing log files from the failed server; the AutoDatabaseMountDial setting on the target server determines how many logs may be missing before the database is allowed to mount, which is the data-loss boundary in a failover.

Health monitoring

Two cmdlets cover routine DAG monitoring, per the monitoring documentation:

• Get-MailboxDatabaseCopyStatus -Local — per-copy status (Healthy, Failed, FailedAndSuspended, Resynchronizing, and so on), copy queue length, replay queue length, and content index state. Copy queue length is the number of log files not yet shipped to the passive copy; a sustained climb means replication is behind or broken.
• Test-ReplicationHealth — checks the replication pipeline end to end: cluster service, replication service, Active Manager role, RPC and TCP log-copy listeners, quorum, and DAG networks. Run it against each member; every test should return Passed.

A copy queue of a few log files that drains is normal. A copy that alternates between Failed and Healthy indicates an intermittent network or storage problem on the passive side and should be treated as an incident, not noise.

Troubleshooting failed and suspended copies

Copy status Failed

A Failed copy is one that cannot copy or replay logs but was not suspended. Exchange rechecks it periodically and returns it to Healthy automatically once the cause clears. Check the Application log on the passive server for the underlying error (disk full, path missing, network unreachable), fix that, then run Resume-MailboxDatabaseCopy DB1EX2 if the copy does not recover on its own.

FailedAndSuspended: reseed the copy

FailedAndSuspended means the system detected a failure that requires administrator intervention — typically unrecoverable divergence between the active database and the copy. The fix is a reseed, per the seeding documentation:

Suspend-MailboxDatabaseCopy DB1EX2 -Confirm:$false
Update-MailboxDatabaseCopy DB1EX2 -DeleteExistingFiles
Get-MailboxDatabaseCopyStatus DB1EX2

The reseed copies the full database file over the replication network, so plan for the transfer time on large databases. The SourceServer parameter can point the seed at a different healthy copy to keep load off the active server.

ContentIndexState Failed

When the database copy is Healthy but only the content index is Failed, reseed the index alone: Update-MailboxDatabaseCopy DB1EX2 -CatalogOnly. On Exchange 2019 and Subscription Edition, the search index (Big Funnel) lives inside the database itself, so a separate catalog reseed does not apply; a failed index there follows the database copy.

Quorum lost

When a majority of voters is unreachable, the cluster stops and every database in the DAG dismounts. The sequence: identify which members and the witness are down; restore reachability to enough voters to regain majority; if a member count changed recently, confirm the quorum model adjusted (Exchange manages this when members are added and removed through the cmdlets). If the witness share is the missing voter, verify the share exists and the Exchange Trusted Subsystem group still has access, or move the witness with Set-DatabaseAvailabilityGroup -Identity DAG1 -WitnessServer FS2 once quorum is back. Forcing quorum with cluster tools is a datacenter-switchover action (Restore-DatabaseAvailabilityGroup) and belongs in a documented DR runbook, not in ad-hoc troubleshooting.

Maintenance mode for CU installs

Cumulative updates on a DAG member require placing the server in maintenance mode first: suspend activation, drain transport queues, move active databases off the server, and pause the cluster node. Exchange ships StartDagServerMaintenance.ps1 and StopDagServerMaintenance.ps1 in the Scripts directory for this. The full step order, including the manual cmdlet equivalents and the checks to run before resuming the node, is documented in Exchange cumulative update. Installing a CU on a member that still holds active databases forces an unplanned failover mid-install.

When DAG problems become a support case

A reseed on a multi-terabyte database, a quorum loss across sites, or a divergence that keeps recurring after reseeds are cases where the fix depends on state that is easy to misread — and a dismounted DAG is a full mail outage while it is read wrong. If the failure has taken the last healthy copy with it, database repair is a different procedure; see Exchange database recovery. Our Exchange Server support team handles DAG failures as a standard case type: copy-status triage, reseeds, quorum and witness repair, and CU maintenance-mode work. An Exchange engineer is available on live chat 24/7.