Exchange Database failed due to Exchange 2013 Logs Drive Full

As an Exchange or IT Admin, when handling the exchange environment you may often come across the challenge of an exchange database not mounting. This can be due to many reasons and I will list a few of them:

• Server Specifications inadequate for Exchange.
• Backups not truncating log files
• Space problem.
• Corruption
• Logging is big in Exchange 2013 and higher

Server Specifications inadequate for Exchange

If we look at the first option, this is a very common reason. Many admins are given limited resources, so when you have a management request for a new exchange server, you need to make it available within all of your limitations. Unfortunately, this is a key root area for all problems. For example, the server does not have enough memory or enough disk space and this often happens 9 out of 10 times. This leads to hitting a backpressure of problems.

Exchange servers need to be spec’d according to Microsoft guidance as they have tested it and advise what the best practice should be.

Backup is not truncating log files.

Another big problem that seems to be around is how Admins are backing up Exchange. If you have a large environment, snapshotting machines is not a viable solution as a backup. The reason being that Exchange and AD write data real-time and reverting a snapshot results in data loss.

The second problem is backups running for Exchange databases are not truncating the log files. If your backup is running but not clearing the logs, it simply means that the backups are not valid, so you cannot restore them.

Space problem.

Space requirements in Exchange are hitting big numbers now; you need to look at a 400GB+ drive for the log drive. In general, Exchange writes many log files and when you perform mailbox moves, these log files increase drastically so if you do not keep an eye on things, they will occupy the drive very quickly which will result in your Exchange database dismounting because you have hit a threshold limit within Exchange.

If you are limited with space and are performing mailbox moves, then it might be an option to turn on circular logging to ensure that logs are truncated constantly, just remember you cannot run backups if you have this turned on as you will cause inconsistency within Exchange and its log files. This, in turn, points back to backups not running to truncate these log files.

Corruption.

Another possibility where the Exchange database will not mount is due to inconsistency with log files due to a space problem or if the server reboots itself and because you are out of space and there are missing log files. You can repair a corrupt Exchange without log files by using Stellar Phoenix Mailbox Exchange Recovery.

Logging is big in Exchange 2013 and higher

This is a big topic and not many people know how much logging actually takes place on an Exchange 2013 or 2016 Server.

There are many log files that are generated on the server, from RPC logs to IIS logs to log files within the Exchange Database directory. As an example, a customer had built an Exchange 2013 server with a C:\ Drive of 300GB which filled up within 1 day, Here this is due to lack of proper planning, you have fixed the threshold point and there should be a second plan when such a scenario arises.

Why does Exchange Require big space??

ETL files, as well as Performance logs on Exchange, are constantly logged. You might think when we say Exchange performance logs, it happens whenever a transaction goes through and when we say 1GB or 5GB performance logs is not much space, but that space can be easily filled depending on the size of the exchange server and activity performed.

IIS logs can grow big and are one of the key reasons for filling up a drive on Exchange. What can we do as admins during such scenarios? To share with you there is a script written by MVP that you can run on a daily schedule to clear the log files in all these directories and claim GB’s of space back, this is not the log files that reside within the Exchange Database directory but within all the other directories.

Solutions:

• Move the database and log files to a bigger drive
• Change the location of the queue database
• Monitoring is crucial

You should consider moving your database and log files to a bigger drive. This might sound like a daunting task but it is actually very simple. To perform this you can run the following command:

• Move-Databasepath “MDB1” –EdbFilepath “M:\DB\MDB1\databases\mdb1.edb” –LogFolderpath “M:\DB\MDB1\logs\”

The command above is an example; As a Prerequisite change the drive letter and the name of your database to match what you have in your environment. The thing to take into consideration is that to adjust your backups to point to the new location or you will fill up the new drive and run into the same space issue.

Change the location of the queue database

The next option is to move the queue database off the default drive (C:\) to another directory, to do this, we have a few commands to run and some config files to update, here are the steps:

Use the Command Prompt to create a new queue database and transaction logs in a new location

Create the folder where you want to keep the queue database and transaction logs. Make sure that the correct permissions are applied to the folder.

In a Command prompt window, open the EdgeTransport.exe.config file in Notepad by running the following command:

• Notepad %ExchangeInstallPath%Bin\EdgeTransport.exe.config

Find and modify the following keys in the <appSettings> section.

• <add key="QueueDatabasePath" value="<LocalPath>" />
• <add key="QueueDatabaseLoggingPath" value="<LocalPath>" />

For example, to create a new queue database and transaction logs in D:\Queue\QueueDB, use the following values:

• <add key="QueueDatabasePath" value="D:\Queue\QueueDB" />
• <add key="QueueDatabaseLoggingPath" value="D:\Queue\QueueDB" />

When you're finished, save and close the EdgeTransport.exe.config file.

Restart the Exchange Transport service by running the following command:

• net stop MSExchangeTransport && net start MSExchangeTransport

Conclusion

After all the challenges and solutions we went through, it is understandable that monitoring Exchange Server database Log files is a crucial consideration to be aware of. The threshold you fixed for your log files and pre-planning on how you will overcome such scenarios if you end up with a failure or disaster.