How to Check Exchange Database Health
The feeling of bliss when everything is working in top shape in your Exchange Server setup and anyone would be taking a coffee and enjoying the day. This of course is because the Exchange Admins are working hard in keep this up and monitoring the Exchange Server. Checking the database of your setup is essential to keep your databases healthy and no connectivity issues from your users.
In Exchange the worst nightmare for any Exchange Admin is to have a corrupted or unhealthy database. Before heading to horrible conclusions, we need to check other factors on why the users cannot access their mailboxes.
As a starter we would want to check that all services of Exchange Server are running. If the users have not complained yet it doesn’t mean that the setup is working fine. It could be that after a restart or updates, a service might not have started automatically. To test this, we need to use the Test-ServiceHealth cmdlet after opening the Exchange Management Shell. The result of a healthy Exchange Server would be that all services are ‘True’, but if one of them would result in a ‘False’ result you might need to open the ‘services.msc’ to make sure you start the service or investigate why this was not running.
This will ensure that all services are running. To ensure that your users can access their mailboxes, we must ensure that MAPI connectivity is not obscured and all is well. For this we need to use the Test-MAPIConnectivity cmdlet.
Here we can see that connectivity is good. The next thing is to test the mail flow coming in and out of our Exchange Server. This can be done by running the Test-MailFlow cmdlet which will give us a summary of the mail flow.
If all is well here we go on and test our Exchange Databases. Why did I leave this for last? Well usually we go immediately to the conclusion that a database is corrupt or we look for the big problems where the issues could be due a service not running or an issue with mail flow due to network connectivity. The first thing to check in your database if the database is mounted or not. This can be checked from the Exchange Management Console, clicking on Servers and Databases. Here you would confirm if the database is mounted or not. You can try to mount the database if it’s not mounted and usually the Exchange Server would give an explanation of the fault.
The usual culprits for a database not being able to mount are lack of disk space, inconsistent or missing log files, database corruption, time mismatch, Jet error of file access or locked, permission problems, anti-virus problems, licensing issues or Active Directory issues.
Before exploring a few of these the first thing is to check the health of the database that it’s consistent and no damage is done. This can be tested by using the native utility called EseUtil and using the /MH along with the name of the EDB file next to the command.
We need to make sure to notice the State of the database and if it’s not Clean Shutdown we might need to dig deeper into the issue. Some issues will let you know immediately in the EseUtil result like the below.
Let’s start by going briefly through some of the culprits. If there is no disk space usually it’s because either the backup is not being taken or the backup software is not application aware and doesn’t purge the logs. This will end with the logs consuming all your hard disk space. Some backup software are not application aware and this will cause this along with the possibility of no backup or corruption of the database.
Third party software installed along with Exchange Server can cause havoc and the Anti-Virus software is another. The antivirus software must also be Exchange Server aware as it may lock the EDB file for scanning and possibly cause damage to the database. This could the issue where if you run the EseUtil you would get a Jet error saying file Access Denied due to file being locked or in use. Inconsistent or missing log files could cause a database not to mount this could be by a corrupted log file or a deleted log file. This will prevent the database to mount. Licensing could be also an issue as in Exchange 2013 for example you cannot have more than 5 mailbox database. If you try to add the sixth mailbox database it will not give any issues, but you can only mount 5 database at a point in time.
Exchange Server is highly dependent on Active Directory and having an unhealthy Active Directory or DNS would result in an issue with your Exchange Server. The database could be healthy but due to the schema or replication issues in Active Director could hinder access or operation of your database where in some cases end up with corruption or damage.
If the Antivirus, storage, missing logs, and Active Directory are not the issue, then we would need to run a soft recovery of the database using the EseUtil /R and if this fails to mount the database you would need to execute a hard recovery process using the /P parameter which could take a considerate amount of time. After this process you would need to run a database defragmentation which will take a long time depending on the size and damage on the database. This process cannot be stopped. All this must be done with the database unmounted and people not being able to send, receive or check their email.