We’ve probably all been there! Installed Exchange, just to find out after a few days it is filling up the disk(s) with numerous logfiles, eventually resulting in a dismounted database. The first time this happened you have no clue at all. Why did the disk(s) fill up? After desparately going over the internet (with your boss breathing down your neck (“You’re the IT-Guy”)) you found the problem (LOGFILES), and probably also a way to remove those “old” logfiles.

Great, solved !

After a while you started to create (or copy/paste, whatever) scripts to not only truncate those pesty logfiles, but also other logfiles. You even found a script to move logfiles from the default C-drive to another drive. So now the system is running smooth, no more disk-problems.

But then, after a shutdown and restart, you notice that 1 or more of your databases won’t mount anymore. What the **?

There is plenty of space on disks, so why are they dismounted ?

Panic !!

Luckily there is this “EseUtil.exe /r“, so can can recover all of your emails (pheww!).

But after running this tool (and spending a lot of time on the internet trying to discover why it is telling you you are missing logfiles), you’ll end up in disaster, “EseUtil.exe /r” didn’t work. You have to fall back to the more disruptive “EseUtil.exe /p“. But after running that (and clearing the logfiles-folder, ’cause otherwise the database will not mount), you (or worse, your users) discover they are missing a number of newer mails/folders, whatever.

How come, what did I miss ?? And why did they get dismounted in the first place, or (because it turns out that that’s the base problem) why did the logfiles become corrupted/are missing??

Probably because, when the system was shutting down, not all logfiles were committed to the database, hence resulting in a dismounted database after the restart. And, because your fine script deleted older (but still not committed !!!!!!!!!) logfiles, those logfiles will be missing when trying to repair the database.

Ok, well, so how do you commit the logfiles to the database?

A: You can run a backup (Windows Backup), that will commit and clean up the logfiles, but that would take a lot of time (and maybe we don’t even have enough diskspace for it, because we use a different approach for backups with our VM’s).

B: You can dismount and mount the database(s), but that would disrupt your users while working with Exchange. And with an increasing amount of logfiles the dismounted time would increase.

C: Flush logfiles with DiskShadow. This is a program that makes snapshots on behalf of the VolumeShadowCopy-functionality (VSS). It creates snapshots, so 3rd-Party programs or backup-utilities can make backups without locking files. By using the DiskShadow-command in a certain way, we can tell Exchange we made a backup (without actually making a backup), thus resulting in Exchange flushing the logfiles (and effectively removing all old logfiles, so no more removal of old logfiles is needed).

Here are 3 files you can use to A: flush the logfiles, B: flush the logfiles and clear the (other) logfiles, and C: shutdown your Exchange-Server while flushing the logfiles.

The 2nd file relies on the 1st file, so be sure to download both of them. The 3rd file (batch-file) can be run standalone, but you can also (preferably) add it to a ShutDown-GPO for your Exchange-Server, thus assuring that with every shutdown/restart this batchfile will be executed.