How to Deal with Exchange Server Crash?
26 November 2024
4 Mins Read
toc impalement
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 a ‘not being able to mount’ problem due to a planned restart or a power failure. After rebooting or powering the server ON, you will 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 that went wrong
- A third-party application that is not application-aware or not ExExchange-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 about 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.
The 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, attaching the databases from the failed server, and pointing 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 A 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 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 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.
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 software 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.
With 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.
Read More:
Related Articles
