There is no doubt that Microsoft Exchange Server is a superb application and works like a charm. However, disaster may happen anytime. In such a case, the right decision to resolve the problem could save you from a disaster. The most feared issue with the Exchange Server is when all the users are not able to access their mailboxes and you would notice that the databases are dismounted. When you try to mount the databases, you would get a bunch of errors. There may be other faults that would make the server unusable like software or hardware issues. But, in my opinion, the issues with databases are the critical ones.
Why does this happen?
The databases may suffer from 'not being able to mount' problem due to a planned restart or a power failure. After reboot or powering the server ON, you would be presented with all the databases that are unable to mount. A planned restart could install the periodic Windows Updates. But it may also happen if the people managing the server might reboot the server due to some issues. Let's face it! Sometimes, rebooting a machine could solve a teething problem. Unfortunately, with Exchange Server, it could be a result of an issue and when it restarted, the databases won't mount.
What are the causes?
As said, the causes can be many. To name a few, we could mention:
- Sudden power failure
- Forced restart, without leaving the server enough time to properly shutdown the Exchange databases
- Hardware failure
- An update which went wrong
- A third-party application which is not application-aware or not Exchange friendly
- Malware
- No space in the database drive
- Aggressive anti-virus application
- Human errors
Is it easy to recover an Exchange Server?
There are different types of corruption or other damages. It would not be easy to make a general assumption that how long it will take to recover an Exchange server from a disaster. One thing for sure is that it is not an easy task. Exchange server has a database and log files. The log files are not there just to keep a lot but act as a buffer between the users and the database where temporary data is stored until the Exchange Server commits the data in the database. One must also factor in that the Exchange Server is dependent on the Active Directory and vice versa.
Portability of a simple setup of SQL includes setting up a new SQL server, attach the databases from the failed server and point the users to the new server. However, with Exchange Server, it doesn't work that way.
How to deal with the recovery process?
In case of any problem with the Exchange server, you must not panic. You must have the technical know-how or the right tools in hand to have a quick recovery with minimal downtime, for the Exchange Admins and the frustrated users.
The first thing to do before starting a recovery is to copy the database in its current state on a temporary storage, if you have enough resources. Why is this? During a recovery process, you might cause further damage to the database. So, if your database ends up in a non-recovery state, then that copy will save you. If it is not corrupted, you will be able to restore it by using the native tools of the Exchange server.
What recovery solutions can be used?
Let's start from the beginning. We need to check the database state by running the 'EseUtil' with the '/mh' parameter. If the database is in Dirty Shutdown state, corruption or missing files are sure to be there. To try recovering a database from minimal corruption, you can use the 'EseUtil' with the '/r' parameter to do a soft recovery of the database.
I must make a note here that using 'EseUtil' does not mean a 100% recovery of the database. You might end up with an even more damaged database.
If this doesn't work, the only option, with 'EseUtil', is to use the hard recovery. Using the hard recovery means that it will slice off the corrupted data from the database. Now, this means that you will need to accept the data loss. I have to also stress on the fact that recovery is not 100% guaranteed as after this process you could end up with an unusable database. When recovering a database using the hard recovery, a parameter is hard coded in the database. On the other hand, if you would request Microsoft's support to assist in recovering the database, they will not help you if the database has been hard recovered.
Case Study
Reviving PNG DataCo Ltd After an Exchange Server Crash - Uncover the Full Recovery Journey!See how PNG DataCo Ltd used Stellar Repair for Exchange
By performing both soft and hard recovery, if the database's state changes to Healthy Shutdown, you can mount the database and all will be fine.
The other option is to restore the server from the last healthy backup. But this would end up in data loss, from the last backup till the time that the server stopped working. I would leave this as a last resort.
Alternatively, you can use a specialized Exchange recovery tool such as Stellar Repair for Exchange. When a disaster strikes, you would like to have the service up and running with minimal downtime and hopefully with no data loss. With Stellar Repair for Exchange, you can open a corrupted database and export anything from the database with no complex setups. Just a quick 3-minute installation of the application, you will be able to export EDB files granularly to PST and other formats such as PDF, EML and HTML. You can also export EDB files directly to a live Exchange Server database of any version or an Office 365 tenant.
4 min read
