Recover Exchange Server after total loss

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.

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.

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.

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.

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.