Exchange servers and databases are critical resources for your organization and this is why every reasonable effort should be taken to protect these resources as well as their contents.
Despite best efforts, there is always a possibility for the database files (.EDB files) to get corrupted. When this database becomes corrupted or damaged, user mailboxes become inaccessible and sometimes, this even leads to loss of data from database files.
Also, when these corrupted mailboxes are accessed, it throws a ton of errors, out of which the most common is “Operation terminated with error 528 current log file missing.” Another common one is “Exchange-level logical consistency can no longer be guaranteed. “
These two errors are related in many ways and let us know see how these errors can be fixed.
Operation terminated with error 528 current log file missing
When a database mailbox becomes inaccessible, the admin tends to perform a database restore operation on the Exchange backup files. During this time, if there is a sudden power failure, power fluctuations or corruption in the database exchange file, the current log files could go missing.
In general, there are two log files – main log and temp log files. The temp log files are where the current transactions are recorded and these transactions are written to the main log file in batches. In some scenarios, the temp file could be missing and this will cause inconsistency in the main log files because transactions have already happened, but they are not recorded.
Before going further into the solution, let us see briefly the possible causes for these files to go missing.
- Power failures and fluctuations – Since these are temp files, any power failure or fluctuation could erase them from the system.
- Antivirus programs – One of the most common cause is the wrong configuration of an antivirus program in your server. When the quarantine program of your antivirus is not enabled, the Exchange Server treats all log files as virus infected files and would automatically delete them.
- Corrupted Exchange database files – When Exchange database files are corrupted due to a dirty shutdown, then the log files get lost as well.
When the admin tries to restore the mailbox and if the current log file is missing, the system throws the error – “Operation terminated with error 528 current log file missing.”
Fixing this error
There are two ways to fix this error, but each comes with its own set of limitations.
One way to fix this error would be to use the built-in Eseutil tool. However, this tool comes with many drawbacks, all of which could impede the successful recovery of your database contents. Some of its drawbacks include,
- Takes a long time to recover.
- Wrong execution of commands
- At least 20 GB of free space is required to run Eseutil.
- It cannot repair damaged and corrupted database files.
These restrictions make Eseutil ideal only in certain situations.
Another possible way is to delete all log files and their checkpoints, so you can recover them from the last backup. This may not be easy because your backup files should have the latest content, otherwise you may end up losing some data.
Now, if these methods do not fix the error and you try to restore the contents of database files, you get another error – ” Exchange-level logical consistency can no longer be guaranteed. “
Exchange-level logical consistency can no longer be guaranteed
The good news about this error message is you will get a long and comprehensive message that explains the problem to you. Your error message will be
Database <databasename> has been offline-repaired (by eseutil.exe) one or more times in the past. However, although this ensures database-level logical consistency and may permit the database to be successfully mounted, Exchange-level logical consistency can no longer be guaranteed. Therefore, all mailboxes should be evacuated from the database and the database should be retired as soon as possible in order to eliminate the potential for unexpected behavior caused by Exchange-level logical inconsistency.
This event will continue to be emitted once per hour while the database is mounted as an urgent reminder to evacuate and retire the database as soon as possible.
So, how can you fix this error?
One way is to use the PowerShell cmdlet called “New-MoveRequest” to export the contents of your mailbox to a .PST file.
Unfortunately, this comes with restrictions as well. Generally speaking, .PST files have a file size limitation of 50 GB. If your contents are more than 50 GB, then they will be lost. Also, there is no way to check the size of your mailbox contents.
Another problem is this process can be a little complicated and may not be ideal for everyone to perform.
So, what’s the solution? Use third-party tools.
Stellar Repair for Exchange
Third-party Exchange Recovery tools like Stellar Repair for Exchange make it a breeze to handle all of the above problems.
First off, the size of the mailbox does not matter, as it will store data across many .pst files. For example, let’s say your edb has multiple mailboxes then, it will create john1.pst, john2.pst and john3.pst, where each mailbox will be stored in different PST files. This way, you don’t have to worry about partitioning your data and there will be no data loss.
Secondly, it comes with a simple and easy-to-use interface that hides all the complexity. All that you have to do is export the data, select the files and click on a button. The rest happens in the background and finally, you have .pst files with all your data. It’s really that simple.
Above everything, this tool can fix corrupted exchange database files as well, so there are no more concerns of data loss.
In fact, all this can be done within a short time, so users can access their mailbox at the earliest.
For these reasons, Stellar Repair for Exchange is your best bet to fix both these errors.
Do check our MVP review of Stellar Repair for Exchange.
