Exchange Server disaster recovery: rebuild a lost server with Setup /Mode:RecoverServer

When an Exchange server's operating system or disks are gone for good, you don't build a brand-new server and migrate everything onto it. Exchange keeps almost all of a server's configuration in Active Directory, so Setup can rebuild the server from that record with /Mode:RecoverServer. In this post I'll walk through the prerequisites, the different paths for a standalone server and a DAG member, getting the data back, and the local customizations that Setup can't restore for you, for Exchange Server SE and Exchange Server 2019.

How RecoverServer works#

The Exchange server object in the configuration partition of Active Directory still describes the lost server: its roles, databases, virtual directories, connectors and install path. When you run Setup in recovery mode on a new machine with the same name, Setup reads that object, installs the Exchange binaries and services, and applies the stored settings. What it can't bring back is anything that lived only on the old machine: certificates and their private keys, database and log files, IIS and registry tweaks, and edited config files.

RecoverServer is the right tool when the server is unrecoverable. If only a database is damaged, use the dirty shutdown and eseutil guide or the recovery database restore guide instead. If a whole site or the Active Directory forest is down, start with recovering Exchange after a site or forest-wide outage.

Prerequisites#

• Same name, same domain. Recovery fails if the new Windows server doesn't have exactly the name of the lost Exchange server.
• Same Windows Server version. The target must run the same Windows Server release as the lost server; you can't move to a newer operating system during recovery.
• Same build of Exchange. Use the setup media for the CU (or the SE release) the server was running. If you don't have it, Microsoft allows the latest available CU; the server's version attributes then show the older build until you run the next upgrade, which is cosmetic.
• Same drive letters and install path. Database and log drive letters must exist on the new server. If Exchange wasn't installed in the default %ProgramFiles%\Microsoft\Exchange Server\V15, you need /TargetDir.
• Permissions. Domain Admins and Organization Management membership for a standalone server.
• Certificate backup. A PFX export of the third-party certificate with its private key, or the ability to reissue it from your CA.
• Healthy Active Directory. Domain controllers and global catalogs in the server's site must be up and replicating, because everything Setup needs comes from them.

Find the original install path from the msExchInstallPath attribute of the server object. You can open the server object in ADSI Edit, or query it with the ActiveDirectory module:

$config = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -SearchBase $config -LDAPFilter "(&(objectClass=msExchExchangeServer)(cn=MBX1))" -Properties msExchInstallPath |
    Select-Object Name, msExchInstallPath

Step-by-step#

1. DAG members only: take the server out of the DAG#

If the lost server was a DAG member, clean up its DAG configuration from a surviving member first. Record any lag settings, because you'll need them when you add the copies back:

# Note replay and truncation lag for copies that lived on MBX1
Get-MailboxDatabase DB1 | Format-List Name, ReplayLagTimes, TruncationLagTimes

# Remove every database copy that was hosted on the lost server
Remove-MailboxDatabaseCopy -Identity DB1\MBX1

# Remove the server from the DAG; it's offline, so update configuration only
Remove-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1 -ConfigurationOnly

# -ConfigurationOnly doesn't touch the cluster, so evict the node yourself
Remove-ClusterNode -Name MBX1 -Cluster DAG1

Run Remove-MailboxDatabaseCopy for each database that had a copy on the server. A database whose only copy lived on the lost server had nowhere to fail over to, so plan to restore it from backup after the rebuild.

2. Reset the computer account (don't delete it)#

In Active Directory Users and Computers › Computers (or the OU that holds your Exchange servers), right-click the lost server's computer object and select Reset Account. Resetting keeps the object's SID and its memberships in groups such as Exchange Servers and Exchange Trusted Subsystem. Deleting and recreating it gives you a new SID and breaks those permissions, so leave the object in place.

3. Build the replacement server#

Install the same Windows Server version, give it the original name, and join it to the same domain. Recreate the same drive letters and volume layout, then install the Exchange prerequisites for your version (Visual C++ runtimes, URL Rewrite, UCMA where required, and the Windows features). If a prerequisite is missing, the setup prerequisite guide covers the usual errors.

4. Run Setup in recovery mode#

Mount the ISO and run Setup from an elevated command prompt. Choose the diagnostic data switch that matches your policy:

E:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /Mode:RecoverServer

rem Non-default install path recorded in msExchInstallPath
E:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /Mode:RecoverServer /TargetDir:"D:\Program Files\Microsoft\Exchange Server\V15"

Optional switches include /DomainController to pin Setup to one DC and /DoNotStartTransport to keep transport stopped until you've re-applied your settings. If your organization uses the Scripting Agent, Setup can stop with this error:

Scripting Agent initialization failed: "File is not found: 'C:\Program Files\Microsoft\Exchange Server\V15\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml'."

Run Disable-CmdletExtensionAgent -Identity "Scripting Agent" on another Exchange server, rerun Setup, and turn it back on with Enable-CmdletExtensionAgent afterwards. If this is your only Exchange server, rename ScriptingAgentConfig.xml.sample in that folder to ScriptingAgentConfig.xml and rerun Setup.

5. Get the data back#

DAG member: add the server back and reseed its copies from the healthy ones, reapplying any lag you recorded:

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1 -ReplayLagTime 7.00:00:00

Standalone server: the database objects still exist in Active Directory and point at the original paths. Restore the database and log files with your backup application (Windows Server Backup or a third-party product) to those paths and let the restore replay the logs. If the files are restored to disk outside the backup application, check the state with eseutil /mh before mounting. Allow the restore to replace the database if needed, then mount it:

Set-MailboxDatabase DB1 -AllowFileRestore $true
Mount-Database DB1

If there's no usable backup, or the restore will take hours, mount an empty dial tone database so users can send and receive, and merge the old data later. Backup problems are covered in the VSS writer guide.

6. Re-apply local customizations#

Do this before the server takes production traffic, then restart it:

• Certificates. Setup binds a new self-signed certificate to every service that needs TLS. Import your PFX and assign services, otherwise Outlook users get certificate prompts:
  PowerShell

  Import-ExchangeCertificate -Server MBX1 -FileData ([System.IO.File]::ReadAllBytes('D:\Certs\mail.pfx')) -Password (Get-Credential).Password
  Enable-ExchangeCertificate -Server MBX1 -Thumbprint <thumbprint> -Services IIS,SMTP

  The organization-wide Auth certificate isn't server-specific, but confirm it's present with Get-AuthConfig; see the certificate renewal guide.
• Virtual directory URLs. Microsoft calls out that virtual directories need reconfiguring. Compare internal and external URLs with a healthy server (the virtual directories guide lists the commands), and check the Autodiscover service connection point.
• Receive connectors. These are stored in Active Directory, so they normally come back. Still compare Get-ReceiveConnector -Server MBX1 with your documentation, especially remote IP ranges on relay connectors and their permissions.
• IIS and registry settings. TLS hardening keys, Extended Protection, custom IIS redirects or bindings, edited EdgeTransport.exe.config settings, page file size, and antivirus exclusions all lived on the old disk.
• Kerberos and AD FS. If you use an alternate service account, redeploy the ASA credential to this server; if OWA uses AD FS, import the AD FS token-signing certificate.
• Updates. Install the latest Security Update for your build before go-live.

Verify#

Test-ServiceHealth -Server MBX1
Get-ServerComponentState -Identity MBX1 | Where-Object State -ne 'Active'
Get-ExchangeCertificate -Server MBX1 | Format-Table Thumbprint, Services, NotAfter, Subject

# DAG members
Test-ReplicationHealth -Identity MBX1
Get-MailboxDatabaseCopyStatus -Server MBX1

Good looks like this: every required service reports as running, no component is Inactive, your public certificate holds the IIS and SMTP services, all replication tests pass, and each copy shows Healthy with a Healthy content index. Then open a mailbox in Outlook and Outlook on the web and send mail in and out. Finally, run the Exchange Health Checker against the server and compare its report with a healthy peer; the Health Checker findings guide explains what each finding means.

Tips & gotchas#

• Document before you need it. Keep a per-server record of URLs, certificates, registry changes and lag settings. RecoverServer restores the AD record, not your notes.
• Don't run cleanup tools on the server object. Removing the lost server from Active Directory turns a short rebuild into a fresh install and a mailbox migration.
• Components stuck inactive? If the old server was in maintenance mode when it died, its component states can carry over; see components stuck Inactive and the DAG maintenance mode guide.
• Bigger outage? If Active Directory itself is gone, follow the Active Directory forest recovery guide first. The same "rebuild from the database the product already has" idea applies to the Configuration Manager site recovery guide.

References#

• Recover Exchange servers (Microsoft Learn)
• Recover a database availability group member server (Microsoft Learn)
• Export-ExchangeCertificate (Microsoft Learn)