Being able to recover an Exchange Server is key to business continuity. This is magnified in environments where there is only a single Exchange server. Rebuilding an Exchange environment from scratch would be an arduous and monumental task. Luckily Exchange saves much of its configuration settings in Active Directory. As long as Active Directory is healthy you can recover an Exchange Server to its former configuration. This process saves a massive amount of time.
That said there are some items that are not stored in Active Directory. This includes the databases where the user and public folder data is stored, third-party certificates and, customizations made outside of the Exchange management tools.
Certificates are easy. If you don’t have a backup you can have your certificate re-keyed by your provider. This may take some time so it is much better to export your Exchange server certificate and save it to a safe location. Then it can be quickly imported in the event of a failure. This will reduce downtime.
Databases are a little more difficult. Depending on the nature of the failure they may need to be restored from backup. The time required for restore largely depends on the size of the database. With the Exchange standard license you get five databases. So, rather than one large database, go with five smaller ones. These greatly aides your recovery time objective (RTO). Exchange enterprise allows up to a hundred databases giving you even greater capacity.
I always recommend that you architect a database availability group (DAG) where possible. Even if your budget can only cover two Exchange servers–creating a two-member DAG with two copies of each database–will put you miles ahead when it comes to disaster recovery. The instructions to recover a DAG member differ and we will cover that in a later article.
Configuration outside of the Exchange tools is going to be a little tougher. You will either need documentation so the changes can be repeated, or, a backup of the changes. Customizations outside of Exchange can include the registry, IIS, or, text-based configuration files.
Note: It can help to keep a copy of the Exchange install files in a safe location. Microsoft generally only makes the last two cumulative updates publically available. You can recover from the latest cumulative update. However, note that the build number within Exchange admin tools will reflect the version prior to failure. This will update as soon as you run the next cumulative update.
Total loss of an Exchange Server
For this article I have a virtual machine running Exchange Server 2016 CU5, named EX16, running on Windows Server 2016. This virtual machine is going to be deleted from its virtual storage. This could mimic failed storage, a virtual machine becoming corrupt, or, the operating system refusing to boot. This Exchange Server is not part of a Database Availability Group (DAG).
Note: You can also use this process with older versions of Exchange.
So, let’s “accidentally” delete our virtual machine. The screenshot to the right shows our virtual machine has been deleted.
Gathering information for the recovery process
For the recovery, we will need to know the operating system and directory path our Exchange server used. Without this information, the recovery procedure will fail. For our lab, we knew all this information. But what if we didn’t have this information?

To find the operating system we can use Active Directory Users and Computers.
Open Active Directory Users and Computers and locate the computer account for the failed Exchange Server. Right-click on the account and select Properties from the context menu. Select the Operating System tab. In our case, we can see we were running Windows Server 2016 Datacenter.
To find the install directory for Exchange you will need to use ADSI Edit.
Open ADSI Edit. Right-click on the ADSI Edit node and select Connect to from the context menu. Under Select a well known naming context pick Configuration from the drop-down menu. Click Ok.
Expand Configuration, CN=Configuration,DC=<your-domain>,DC=<your-domain>, CN=Services, CN=Microsoft Exchange, CN=<your-Exchange-org-name>, CN=Administrative Groups, CN=Exchange Administrative Group, CN=Servers and right-click on the name of the failed server and select Properties.
Double click on the attribute named msExchInstallPath to see the Exchange install path on the failed server. In our case Exchange was installed under the default path of C:\Program Files\Microsoft\Exchange Server\V15. If your value is different than the default install path you will need to specify this during recovery.

If you want to restore using the exact same cumulative update you can find that with ADSI Edit.
Using the instructions above right-click on the name of the failed server and select Properties. Select the attribute named serialNumber. The number 15.1 designates Exchange 2016. In parenthesis, we can see the build is 30845.34. If we remove the first two digits (30) we have the build number of 845.34. If we look up this build number we can see we are on Cumulative Update 5.

Recover Exchange Server
Now that we know the operating system and install path let’s recover our server.
The first decision is whether you are recovering to the same or different hardware. If the same hardware then you should not have to worry about sizing. If new hardware you need to make sure it meets both the system requirements to run Exchange and that you have also sized the new hardware in accordance with the Exchange Server Role Requirements Calculator.
For our scenario, we have a single server environment and will be recovering to a new virtual machine on the existing virtual infrastructure. We will use the same sizing as our old virtual machine.
Once the hardware is ready we need to reinstall our operating system. It is imperative we use the same operating system and service pack level as before. The recovery procedure will not allow an in-place upgrade of the operating system. For our scenario, we will be reinstalling Windows Server 2016.
While we are waiting for the operating system to reinstall let’s reset the Active Directory computer account for the failed Exchange Server. Resetting the computer account permits us to do two things. First, it allows us to rejoin the new server to Active Directory under the old computer name. Second–this is the most important part–it allows the recovery process to retrieve all configuration data from Active Directory for the failed Exchange server. It is critical we do not delete the computer account during the recovery process.
To reset the computer account open Active Directory Users and Computers and locate the computer account for the failed Exchange Server. Right-click on the account and select Reset Account from the context menu. Click Yes to confirm. You will receive a notification that the account was successfully reset. Click Ok.

Note: That it may take some time for this reset to replicate throughout Active Directory.
Once the operating system is installed be sure to give it a static IP (I recommend using the same one), the same computer name and, join it to the domain. If the domain join fails you may need more time for replication. In our case, we have set a static IP, named the new server back to EX16 and rejoined our domain SKARO.LOCAL.
Next, let’s get the Exchange 2016 prerequisites installed. To do this open a PowerShell console as the administrator.

Then issue the following command.
C:\> Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS
Next, verify you have the necessary version of the .NET Framework installed. This will vary based on the version of Exchange and operating system you need to recover.
Next download and install the Unified Communications Managed API (UCMA) 4.0.
Note: Your prerequisites will vary depending on the version of Exchange and operating system you are installing. For example, we are installing Exchange 2016 on Windows Server 2016 which requires we install this patch.
Now is a good time to reboot the server. Once rebooted open a Command Prompt, change to the location of your Exchange setup files and, issue the following command. The recovery process can not be completed via the GUI setup.
If you installed Exchange at a different install path you will need to specify this with the /TargetDir switch.
D:\> Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms Welcome to Microsoft Exchange Server 2016 Cumulative Update 5 Unattended Setup Copying Files... File copy complete. Setup will now collect additional information needed for installation. Languages Mailbox role: Transport service Mailbox role: Client Access service Mailbox role: Unified Messaging service Mailbox role: Mailbox service Management tools Mailbox role: Client Access Front End service Mailbox role: Front End Transport service Performing Microsoft Exchange Server Prerequisite Check Configuring Prerequisites COMPLETED Prerequisite Analysis COMPLETED Configuring Microsoft Exchange Server Preparing Setup COMPLETED Stopping Services COMPLETED Copying Exchange Files COMPLETED Language Files COMPLETED Restoring Services COMPLETED Language Configuration COMPLETED Mailbox role: Transport service COMPLETED Mailbox role: Client Access service COMPLETED Mailbox role: Unified Messaging service COMPLETED Mailbox role: Mailbox service COMPLETED Exchange Management Tools COMPLETED Mailbox role: Client Access Front End service COMPLETED Mailbox role: Front End Transport service COMPLETED Finalizing Setup COMPLETED The Exchange Server setup operation completed successfully. Setup has made changes to operating system settings that require a reboot to take effect. Please reboot this server prior to placing it into production.
When setup completes you will need to reboot. Once rebooted you will be able to log back into the Exchange Admin Center and confirm all settings were restored from Active Directory.
Wrapping it all up
Once you have successfully restored your Exchange server you will need to reapply your Exchange certificate. If you have backed this up you can easily import it. If not, you will need to get your certificate re-keyed with your certificate provider, which will mean generating a new certificate. This can take some time. As mentioned previously it is a good idea to export your certificate and store it in a safe place.
If you made any customizations to the Exchange Server these will need to be reconfigured. Customizations are changes you have made outside of Exchange Admin Center or Exchange Management Shell that Exchange has no knowledge of. For example, making custom registry changes, IIS modifications, or, manual edits to web.config files will all need to be redeployed. Any setting you configured inside of the Exchange tools such as configuring custom connectors, virtual directories, email address policies, or, transport rules will all be present.
Lastly, depending on the nature of your failure you may also need to recover a database from backup. For example, if this was just a matter of an operating system that would not boot and your databases and logs were on a separate drive you probably will not have to restore but instead, be dealing with a dirty shutdown. If the database and logs were lost you will need to recover this from a backup. As mentioned earlier if your budget can cover two Exchange servers then I would recommend creating a DAG. This will greatly improve your business continuity from a single server failure.
Further Reading
Here are some articles I thought you might like:
- Install Exchange 2016 in your lab (7-part series)
- Renew a Certificate in Exchange 2016
- Extend, Prepare and Verify Active Directory for Exchange 2016
- Configure Kemp Load Balancer for Exchange 2016

Have you ever had to recover an Exchange Server? How did it go? Join the conversation on Twitter @SuperTekBoy.
This is all great, but you selected to blow away a server NOT in a dag, and you even suggest that a dag should have been setup. I suspect there was a reason for this.
How can you recover a server that is in a dag and no other servers remain? I.E. the first to recover. The installer recovery won’t continue if it detects the server was in a dag. The MS articles assume a server exists to gracefully remove the server to recover from the dag.
Has anyone tried this scenario? I’m in this nightmare right now and hacking with ADSIEdit for this situation gets you past the installer, but now Transport services wont start along with no IIS management even after getting some services to start. MS Support has been little help.
I can’t say I have run into this scenario before.
As you mentioned, if you lose a server that was part of a DAG, you eject the failed server from the DAG from another working Exchange Server. Then recover the server (with the steps above), add it back into the DAG, and reseed any database copies.
However, it sounds like all DAG members are a total loss at this point? If not, and you do have one server that is able to at least boot into an OS (but Exchange is broken) you could look into ejecting directly with Windows Clustering.
I’d be curious what led to that situation so you can avoid it in the future.
Hi
I’ve attempted this on our domain, as our mail server went completely offline.
I was able to access the datastores, so I created a new server on hyper-v, gave it all the same specs as the original, installed exchange as above and copied the datastores back to the new server (just everything in Exchange Server\V15\Mailbox)
Unfortunately I’m getting 500 errors whenever I try to access ECP or OWA.
Does anyone know if there’s anything else I should be copying to the new server, or something I may have missed?
Any help hugely appreciated
Hey Mike,
Apologies, I just now saw this comment. Were you able to resolve the 500 error?
For others, this error often occurs from the incorrect application of security updates in Exchange (if the MSPs were run without elevated privileges). If that is the issue, you can often resolve it by rerunning the MSP as an admin.
I also have some articles on this blog about other reasons someone may run into ISE 500.
Hi there, i tried this scenario but it fails with the message that the ex 16 setup needs access to the old non recoverable database of previous dead ex 16 server.
Since there is no data on my failed machine i do not need to recover anything. I just want to be able to resurect the exchange 2016 to continue the migration process
Thx BR0KK
Hi BROKK,
It sounds like you don’t need this database as there was no data in it. If this is the case, and there are no other functional Exchange 2016 servers from where you could delete this, then you could look at using ADSI Edit to remove the database.
However, ADSI Edit is a raw Active Directory editor. You can do considerable damage to your environment using this tool, so be very careful and make sure you have a good backup of Active Directory before proceeding with ADSI Edit.
The steps you would be looking for would be to launch ADSI Edit from a domain controller, right-click on the top node and select “Connect to” from the context menu. From the dialog, under “Select a well known Naming Context” pick “Configuration” from the drop-down menu and select Ok.
Then from the tree in the left pane expand “Configuration, CN=Configuration, CN=Services, CN=Exchange, CN=your unique org name, CN=Administrative Groups, CN=Exchange Administrative Group” and select “CN=Databases”. This shows ALL your databases. Be very careful which database you delete from here. Doing the wrong thing here could result in data loss and outages for your users. I would recommend testing these steps in a lab first.
I would recommend contracting a Microsoft Partner or Microsoft support for assistance with this. As mentioned earlier, a wrong move in ADSI Edit, can be catastrophic to your environment.
Hi Gareth, thanks for your excellent articles. If I want to go one step further and remove one of my Exchange servers (that is no longer available) do you have steps for that process?
Hey Steve,
There are a couple of trains of thought on this one.
If the computer account is still available you could recover that server with the article above and then immediately turn around and perform a graceful uninstall against that recovered server. That would clean up AD probably the best and in a supported manner with Microsoft.
The second method would be to remove the server object and associated objects using ADSI Edit. This ADSI Edit route is incredibly risky, and I highly recommend having a known working backup (with a tested restore) before you make any changes in ADSI Edit. Any change you make in ADSI Edit could negatively impact working Exchange servers.
I doubt I would ever do an article for server cleanup with ADSI Edit because each environment is unique. Therefore, any recommendation I make in one environment could be very detrimental to another.
Probably not the answer you wanted to hear, but I hope it helps. If you do feel you need to go down the ADSI Edit route I would recommend either contracting a Microsoft Partner or opening a case with Microsoft Support directly.
Hi Sam, will a CU on a DAG breaks the External SSL cert?
Awesome info.
How about this one: we have a customer who lost their FSMO PDC/GC computer (didn’t have a backup nor another machine to take the role, so TOAST).
Any ideas on how we might get the Exchange 2016 server to migrate over to the new domain? I understand I will probably have to rebuild all the Ex infrastructure bits, but can I at least save the databases (which are still whole)?
Thanks,
~Sam
Hey Sam,
Can’t say I have run into this scenario since my Exchange 2003 days and the database architecture had changed significantly since then.
It sounds like the domain itself is a complete loss and you have to build a brand new domain? No other DCs/GCs you can seize the FSMO roles onto? If not, I think you are looking at a brand new Exchange server, new users, new mailboxes, and looking to recover the data through a Recovery Database.
Third party recovery solutions might be another option. Exchange-aware backup software will let you restore mailbox data into a new and different mailbox. In the interim, you can at least give them empty mailboxes to get mail flowing again as you try to recover data.
I’d recommend opening a Microsoft ticket on this one and having them walk you through the recovery.