Exchange 2010: Disaster Recovery

In many companies, the Exchange server forms the heart of communication. In most cases, not only e-mail traffic but also fax sending and receiving is handled via Exchange using additional software. Contacts, tasks and appointments are managed via Exchange. Users synchronize their appointments and mails with smartphones. The Exchange server is therefore often regarded as a critical system that should ideally not fail at all. Many companies therefore use backup software that makes it easy to restore individual emails or appointments if a user has accidentally deleted them. But what needs to be done if the server has a hardware defect or the operating system no longer starts? Administrators should master disaster recovery, because nothing is worse than googling for instructions in a stressful situation and then implementing them. It is often in this situation that mistakes are made and, in the worst-case scenario, this can lead to significant data loss and long downtimes. This article describes the disaster recovery of a single Exchange server. Only the basic steps will be explained. Every administrator should prepare a battle plan for an emergency and test and internalize it thoroughly. This will make it easier for you in an emergency and you can sleep more peacefully if you know what to do.

My test environment looks like this:

There is a domain controller (DC1) and an Exchange 2010 server (EX1). The Exchange server has all 3 Exchange roles (hub transport, client access and mailbox). Only the Exchange database was backed up with the Windows backup. A third server serves as a standby server for recovery. Only the Windows Server 2008 R2 operating system is installed on the standby server. There are 3 user mailboxes on the Exchange server: Maggie, Lisa and Bart.

After a backup of EX1 has been carried out, I switch EX1 off to simulate a total failure. Then I start up the standby server, or if there is no standby server, I install the same operating system on suitable hardware as was installed on the defective Exchange Server. In my case, this is Windows Server 2008 R2, please make sure that the service pack versions of the machines are the same. If EX1 already had SP1 installed, the recovery machine should also have it installed.

The worst case scenario has now occurred in the test environment. The server on which Exchange was running is no longer available. In productive environments, this could be a hardware defect, for example, so that it is no longer possible to start up the server. If this case occurs, the following must be carried out:

1. Reset the Active Directory computer account of the Exchange Server (ATTENTION: The account may only be reset, never deleted)

   

2. Start up the standby server or if no standby server is available, a server must now be installed
3. The new server is given the same name and preferably also the same IP address as the defective Exchange server. In my case, this is "EX1"
4. Now the new server is added to the Active Directory domain again
5. Now the Exchange 2010 prerequisites are installed, which are the following described here
6. Next, open a command line with administrator authorizations and enter the command "setup.com /m:RecoverServer" executed

   

7. After the setup has run through, the server must be restarted
8. Now we should have a working Exchange installation again, but many configuration settings have been lost, so before the new server is put into productive operation, the complete configuration should be checked. For example, the Exchange certificate is not restored.
9. In the Exchange administration console you can now see that the database information has been restored, but this database is offline because the database files are missing.
10. The Exchange databases must now be restored from the data backup; it is not important which backup software was used to back up the database. For testing purposes, I have selected the Windows Server backup and restored the corresponding files. Please make sure that the data is restored to the directory of the database in which Exchange expects it. If this is not possible, the database path can also be adjusted afterwards.
11. Finally, the database must be made available. If everything went correctly, no errors should occur.

These instructions are only intended to help you set up your own test environment and test the recovery functions of Exchange. As already mentioned, you should be familiar with this in order to be able to act correctly and quickly in an emergency.