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 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 down time.
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. This 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.
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).
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 what cumulative update we were running. We also need to know the operating system and directory path for the Exchange install. 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.
To find the cumulative update (or build) that the failed server was running we can also use 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, Exchange version 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.
Once the operating system is installed be sure to give it a static IP (preferably the same as before), 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.
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.
Have you ever had to recover an Exchange Server? How did it go? Come join the conversation on Twitter @SuperTekBoy.