Exchange Server after a site or forest outage: recovery order and DAG datacenter switchover

When a whole datacenter goes dark, or the Active Directory forest itself has to be recovered, Exchange recovery is less about any single command and more about doing things in the right order. Exchange keeps its configuration in Active Directory, its high availability depends on a Windows failover cluster, and its clients depend on DNS and certificates. In this post I'll lay out the order of operations for Exchange Server SE and Exchange Server 2019, the DAG datacenter switchover commands, the fallback options for databases, and a checklist that proves the organization is healthy again.

How the dependencies stack up#

Every Exchange server reads its own settings, the organization configuration and every recipient from Active Directory. Without reachable domain controllers and global catalogs, Exchange services either won't start or will start and fail every request. That gives a fixed order:

1. Active Directory and DNS, healthy and replicating.
2. Exchange servers, started and able to find DCs in their site.
3. The DAG, with quorum and mounted databases.
4. Client access and mail flow: namespaces, certificates, load balancer, MX.
5. Hybrid: Microsoft Entra Connect, then the Hybrid Configuration Wizard.

If a single server is lost while the rest of the environment is fine, you don't need any of this: rebuild it with Setup /Mode:RecoverServer instead.

Prerequisites#

• A decision, made by the business, about whether to activate the second datacenter or wait for the primary one. Switchovers and switchbacks each cause an outage.
• The DAG's datacenter activation coordination (DAC) mode status. Microsoft recommends DAC mode for every DAG with two or more members; check it with Get-DatabaseAvailabilityGroup DAG1 | Format-List DatacenterActivationMode (DagOnly means enabled).
• An alternate witness server in the surviving site, ideally preconfigured with Set-DatabaseAvailabilityGroup -AlternateWitnessServer -AlternateWitnessDirectory.
• Your DNS mapping: which records (Outlook on the web, Autodiscover, MAPI, EWS, SMTP, MX) change to which IP addresses, and their TTLs.
• Exported certificates (PFX with private key) for every namespace, and Organization Management plus the rights to change DNS and the cluster.

Step-by-step#

1. Recover Active Directory first#

If the forest was compromised or corrupted, nothing Exchange-related should start until AD is back. Follow the Active Directory forest recovery guide, and only move on when DCs, global catalogs and DNS are healthy in every site that will host Exchange. Microsoft's own switchover guidance says the same thing: if network or AD reliability is in doubt, keep messaging services off until those dependencies are healthy.

Remember that a forest restored from backup goes back in time. Anything created in AD after that backup, such as new mailboxes, databases, connectors or servers, is missing. Mailboxes whose user objects are gone show up as disconnected; the disconnected mailbox guide shows how to reconnect them.

2. Start the Exchange servers and confirm AD access#

Power on Exchange servers only after AD is stable. Then check that each server sees domain controllers in its site:

Get-ExchangeServer -Status | Format-List Name, CurrentDomainControllers, CurrentGlobalCatalogs, CurrentConfigDomainController

Empty values, or Event ID 2080 and 2142 from MSExchange ADAccess, point to a topology problem; see the ADAccess topology guide. Run Test-ServiceHealth on each server before you touch the DAG.

3. Recover the DAG#

Both sites survive (forest-only outage): once all members and the witness are up and can talk to each other, the cluster regains quorum and Active Manager mounts databases. In DAC mode, a member that starts while isolated won't mount its databases; that's DAC preventing split brain, not a fault. If quorum doesn't come back, the quorum and witness guide helps.

The primary datacenter is lost: perform a datacenter switchover. In DAC mode the sequence is:

# 1. If anything in the failed site is still running and reachable, mark it stopped there
Stop-DatabaseAvailabilityGroup -Identity DAG1 -ActiveDirectorySite Site1

# 2. From the surviving site, record the failed site's members as stopped
#    (use -ConfigurationOnly when those servers are offline)
Stop-DatabaseAvailabilityGroup -Identity DAG1 -ActiveDirectorySite Site1 -ConfigurationOnly

# 3. Stop the Cluster service on every DAG member in the surviving site
Stop-Service ClusSvc

# 4. Shrink the DAG to the surviving site and switch to the alternate witness
Restore-DatabaseAvailabilityGroup -Identity DAG1 -ActiveDirectorySite Site2 -AlternateWitnessServer FS2 -AlternateWitnessDirectory C:\DAG1\FSW

Either power off the servers in the failed site or mark them stopped. If neither happens, both sites could mount the same database, which is split brain. Once Restore-DatabaseAvailabilityGroup succeeds, healthy copies in the surviving site activate on their own, unless you blocked activation on those servers. In that case, clear the block or move each database explicitly with Move-ActiveMailboxDatabase DB1 -ActivateOnServer MBX3. Save the output of every command and follow up on each warning.

If the DAG isn't in DAC mode, the switchover uses the Windows Failover Cluster tools instead: force-start the cluster in the surviving site with net start clussvc /forcequorum, evict the failed nodes, adjust the quorum or witness, then move and mount the databases.

4. When there's no healthy copy: dial tone and database portability#

• Dial tone recovery creates an empty database, rehomes the mailboxes to it with Set-Mailbox -Database, and mounts it so users can send and receive within minutes. You restore the old data into a recovery database and swap or merge it later with New-MailboxRestoreRequest.
• Database portability mounts a restored or surviving database file on another Mailbox server in the same organization and rehomes the mailboxes to it. Source and target must run the same Exchange version and the same Windows Server version.

Both rely on AD being correct, which is another reason AD comes first. For restoring individual items afterwards, see the recovery database guide.

5. Restore client access and mail flow#

• Namespaces. Point the internal and external DNS records for Outlook on the web, Autodiscover, MAPI, EWS and ActiveSync at the surviving site's load balancer or servers. Clients reconnect once TTLs and their DNS cache expire.
• Inbound mail. Update MX records, or the gateway or Edge Transport target, to the surviving site.
• Certificates. Get-ExchangeCertificate | Format-Table Thumbprint, Services, NotAfter, Subject on every active server; the public certificate must cover every name you just moved and hold the IIS and SMTP services. Check Get-AuthConfig for a valid Auth certificate.
• Queues. Check Get-Queue for messages stuck in retry. Use Retry-Queue -Identity <queue> -Resubmit $true once the destination is reachable again.

6. Bring hybrid back#

Start with directory sync. If the Microsoft Entra Connect server was restored or rebuilt, confirm it's the active (not staging) server and check that the AD restore hasn't produced a large wave of deletions before you let exports run. The Entra Connect staging mode guide covers promoting a standby server. Then rerun the Hybrid Configuration Wizard from a healthy Exchange server to rebuild the connectors, OAuth and organization relationship against the surviving endpoints; the HCW errors guide helps if it fails. Finally, test free/busy and a mail flow round trip with Exchange Online.

Verify#

Get-ExchangeServer | ForEach-Object { Test-ServiceHealth -Server $_.Name }
Get-MailboxDatabaseCopyStatus * | Sort-Object Name | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength, ContentIndexState
(Get-DatabaseAvailabilityGroup DAG1).Servers | ForEach-Object { Test-ReplicationHealth -Identity $_.Name }
Get-ExchangeServer | ForEach-Object { Get-ServerComponentState -Identity $_.Name } | Where-Object State -ne 'Active'
Get-Queue | Where-Object MessageCount -gt 0

Good looks like this: no missing services, every active copy Mounted and every passive copy Healthy with low queues, all replication tests passing (minus the stopped servers in a failed site), no inactive components, and queues draining. Then test sign-in from Outlook, Outlook on the web and a mobile device, and send mail in and out of the organization.

Tips & gotchas#

• Switchback is a planned outage. When the primary site returns, bring it in with Start-DatabaseAvailabilityGroup -ActiveDirectorySite Site1, run Set-DatabaseAvailabilityGroup DAG1 with no other parameters so the DAG uses the right quorum model, let copies resynchronize or reseed, move the DNS back, wait for TTLs, and only then move databases.
• Don't activate databases before the namespace moves. A mounted database with no client access in its site leaves users connected to nothing.
• Write the runbook now. Pre-stage the alternate witness, document DNS mappings and keep certificate exports offline. Use maintenance mode as covered in the DAG maintenance guide for planned site work.
• Cross-team recovery. Device management recovers in the same order; see the Configuration Manager site recovery guide.

References#

• Datacenter switchovers (Microsoft Learn)
• Datacenter Activation Coordination mode (Microsoft Learn)
• Perform a dial tone recovery (Microsoft Learn)