Exchange Server Recovery: Best Practices for Production Environment

When it comes to recovering a failed Exchange Server, you should look into the best solutions to minimize the impact on the data and services as well as to reduce the recovery time to a minimum with minimal effort. In this article, we will be discussing some strategies and best practices on Exchange Server recovery.

Preparation and Documentation

Preparation work before disaster strikes is important as it will reduce the impact on the business and the severity of damage as well as reduce the time of recovery. Let’s explore some best practices when it comes to be prepared for such situations.

Have the server’s documentation up-to-date with details such as computer name, network settings, infrastructure, and all the steps needed to install the server. Having a change management request system is also important.

Adding to this, you should have a library of all the software needed to reinstall the server - be it the operating system and the Exchange Server build that is currently installed.

Apart from this, you would have a list of all the responsible people and defined their responsibilities so that when the disaster strikes, there is a smooth flow of information and work.

You must have a solid backup solution which is checked on a daily basis and a test recovery is performed on a monthly basis to ensure if something happens, the backup is recoverable.

This process must be thoroughly tested on a yearly basis to ensure that in case of a disaster, the plan of action is tried and tested. This will ensure that during a crisis situation, everything will be in place to recover the system.

Recovering Data using the Native Exchange Tools

Exchange native tools, such as ESEUtil, can be used for various reasons. But one of the functions is to repair databases. ESEUtil has two options for database recovery – soft recovery and hard recovery. Let’s explore these options.

Soft recovery offers a non-destructive process of trying to replace the transaction logs to try to get the database to consistent state. This is the safest way to try to recover and repair a database. The only constraint is that the Exchange Server must be running, and the transaction logs are not damaged/missing. If this is not the case, the ESEUtil will not work and the smooth recovery will fail.

Hard recovery is strongly not recommended. You should take a backup of the data before running this option. This is a destructive procedure where data loss is guaranteed as it will simply purge any data which might be deemed corrupted. It takes a considerable amount of time to process and  requires a lot of free disk space to process the database. If you run the command, the database will have a hard coded note. If you request support from Microsoft (News - Alert), you will be denied if the database is marked with the note that the hard recovery was executed.

Recovering Data using Alternative Tools

As you have seen, there is constraint with the native tools and the challenges that you would face. With Exchange recovery tools, such as Stellar Repair for Exchange, you can eliminate these challenges and focus on data recovery.

With this tool, you can open multiple databases from any version of Exchange Server, of any size, in any state, and without the need of transaction logs. This tool is not dependent on the Exchange Server. After a quick or deep scan, you can see the entire structure of database where you can filter and do inline search, and granularly export the data to PST and other formats. You can directly export user mailboxes, user archives, shared mailboxes, and public folders to a live Exchange Server database or Exchange Online with automatic mailbox matching. This tool has the following benefits:

• Much less recovery time
• Reduced recovery effort
• Garaunteed recovery
• Less complexity with a very intuitive UI

Recovering the Server

With the disaster recovery document, you will have a playbook on how to rebuild Exchange server. The first thing to know is that all the configuration information of server is stored in the Active Directory Schema (News - Alert). This means that if the Exchange Server is not operational, you can rebuild the Exchange Server from scratch and it will take all the configuration from the schema. This procedure involved using the setup.exe with the recover mode parameter.

However, when recreating the server - be it a virtual machine or physical machine, you need to keep in mind the following:

• The same operating system must be installed.
• This includes the drive configuration with the same drive letter.
• Same specifications when it comes to CPU and RAM (News - Alert).
• The same number of network cards and their respective settings including the IP Address.
• Same computer name.

Once the Exchange Server is installed and the configuration has been restored, the server will be operational again, but with no data. You would need to move back the databases and use ESEUtil to see if the databases have not been damaged. If the databases or transaction logs have been damaged, you can utilize specialized Exchange recovery tools, such as Stellar Repair for Exchange (as mentioned above) to quickly recover the data from damaged database/s to a fresh clean database in the recovered setup with minimal effort and resources.

Conclusion

Above, we have seen the importance of having a recovery document for restoring the server and data in a disaster scenario. Apart from having a mitigation plan, you must have all the tools to make the recovery as fast as possible with minimal complexity and with minimal effort. One such Exchange recovery tool that you can consider when it comes to recovery from damaged or corrupted database is Stellar Repair for Exchange.