Summary: Exchange log files are critical not just because they record all events that take place on the server, but also since they help restore the server in case of an unexpected crash. However sometimes, the log files themselves become the source of Exchange troubles. In this post, we’re demonstrating a typical situation wherein some crucial log files go missing from the server thereby giving rise to Exchange error 528.
Each day, there are a ton of things that can go wrong while working with the Exchange server and cause a ripple effect of warning messages, error pop-ups, or other mishaps. In the case of any such catastrophe, the DBA must take remedial action as soon as possible to mitigate the damage and bring the server back online quickly.
Maintaining proper transaction log files is one of the most basic steps an Exchange administrator can take in order to ensure Continuity and proper functioning for Exchange in case of a mishap. In the event of sudden Exchange shut down, critical log files can go missing giving rise to the error “operation terminated with error 528 current log file missing”. Through this post, let us understand exactly why transaction log files are important, how they can go missing, and what should be done to resolve the error that arises as a result.
The criticality of log files & introduction to Exchange error 528
Exchange transaction log files are an important component of the Exchange server. All changes that occur on the server are written to log files and committed to the database when the system allows. This write-ahead method of logging allows users to send and receive messages without touching the database. Until a transaction is committed to the database, the only existence of the data involved in that transaction is in the system memory and in the transaction logs. In the event of a server crash, the contents of the memory are lost and all that is left is the record in the transaction log. That is why, these transaction logs are crucial to the recovery of a failed Exchange server.
Now imagine a scenario wherein a sudden power failure or surge occurs when the Exchange server is running and it causes many transactions to not be committed to the database. There may be other similar situations too where the transaction logs don’t get committed before the server crashes like:
- Virus or malware attack to the server
- Improper configuration of some application causing a sudden restart of the server
In all of the above cases, the log files that are currently running will automatically be lost. This will result in the Exchange database being marked in “dirty shutdown” state and occurrence of the “operation terminated with error 528 current log file missing” error. To overcome this disaster, quick action is needed.
Resolving Exchange error 528 Manually
Note: The techniques discussed below are free of cost and can be performed with moderate technical knowledge. However, some of them involve the risk of data loss and can take up a significant amount of time to complete.
- Check if anti-virus has quarantined the missing log files
If you haven’t added an exception for Exchange in your anti-virus application, it can regard all transaction log files as virus infected files. Thus, check the configuration settings of your anti-virus first and enable the quarantine module. Follow below mentioned steps:
- Go to anti-virus settings and enable the quarantine module
- Next, stop all services of the Exchange server and move the log files from <drive>:\Program Files\exchsrvr\MDBDATA\E0000000.log to some other location
- Now delete all files that have .log extension. Finally, you should be left with three files, viz. res1.log, res2.log, & e00.chk
- Restart all Exchange services. This should fix things
If this doesn’t work, proceed to the next solution.
- Use ESEUTIL command-line utility for repairing the EDB files
The inbuilt ESEUTIL utility comes handy in situations precisely like this one. It can detect and fix errors with EDB files and bring the database to a consistent state. To fix the problem in this case, use ESEUTIL as follows:
- Make a note of the log files require to bring the database to a “clean shutdown”. Use the command eseutil /mh for this.
- Now initiate a soft recovery procedure on the database using the command
Eseutil /r <logFileSequenceName> /l <logFileLocation> /d <DatabaseLocation> /a /i
If this doesn’t work, try the following:
- Backup all your databases and logs
- Rename the Checkpoint file to something else
- Create a new folder and copy all the healthy log files into it
- From the result of the eseutil /mh command you executed to find the starting point of the missing logs, locate the last complete log. Make a copy of it, rename it, and place it in the same location
- Now run the soft recovery command again and “deleted the renamed last log” that you created while soft recovery is running
Once the recovery completes, the database will be in clean shutdown state. Before mounting the database again, clear all logs in the database location so that you can start with a new set of log files and backup right away.
Note: This is a tricky process and the slightest mistake could make matter worse. So kindly proceed with caution and do not attempt these steps unless you have good experience with ESEUTIL.
- Use NewmailboxRepairRequest command for repairing the database
Another preferred approach for resolving the “operation terminated with error 528 current log file missing” error is using the NewmailboxRepairRequest command. The best aspect of this command is that it can repair the EDB files without the need to dismount it. Simply execute the command New-MailboxRepairRequest -Database[-StoreMailbox] to fix and restore EDB data files.
If however, this technique also doesn’t work or you have limited or no experience in using it, the best way of overcoming the error is by placing your trust in reliable Exchange recovery software Stellar Repair for Exchange.
The best approach to resolving Exchange error 528
Regardless of how complex an Exchange error is, if manual techniques are unable to provide an accurate solution, the best strategy to bring Exchange online is to use Stellar Repair for Exchange. Backed by sophisticated scanning and EDB repair mechanisms, this product is recommended as the number one Exchange recovery product by MVPs. The software repairs corrupt Exchange Database (EDB) files and restores mailbox contents which can be directly exported to live Exchange. Giving users the option to repair large and multiple EDB files without any data loss, this application can successfully repair and recover dismounted & offline EDB files too.
We hope that one of the above mentioned solutions will help you get rid of Exchange error 528. While you can add an exception in your anti-virus program for your Exchange log files, a majority of problem causing factors that trigger error 528 cannot be prevented. Thus, if a situation arises in the future wherein critical log files go missing from the server, remember to backup database files and initiate soft recovery procedure. If that doesn’t work, you know you can rely on Stellar Repair for Exchange to save the day.