Is your Exchange 2007 log disk full? Exchange log files aren’t supposed to take up too much space, and when admins were building Exchange 2007 servers, disks were measured in Gigabytes, not Terabytes. Many admins just let the logs go to the default location, which is the same location as the databases, and the binaries, and the rest of the operating system. Others created separate volumes for log files since that’s what best practices suggest, but might not have allocated as much space as they find themselves needing. When your Exchange log disk is full, there’s a fairly easy way to address this. In this post, we’ll discuss the Exchange log files and what to do when your Exchange 2007 log disk is full.

Don’t panic

Before we go any further, let me offer you some words of wisdom most famously penned by Douglas Adams. Don’t panic. It’s going to be okay. Do not start deleting files in an effort to free up space. Take a deep, calming breath, and then, if you are already up against the wall, skip down to the last section “What to do when it happens to you”. You can read all the stuff in the middle after you have freed up space.

Exchange storage

Exchange log files are transaction logs for the database. Before anything is written to the database, it is written to the transaction log so that, if something happens during a write to the database, like a power loss or stop error, the event can be replayed from the log and the database will be correct.

These transaction log files are stored wherever you chose to save them (by default on the same drive that you selected for installing Exchange), are named based on the storage group and hexadecimal sequence number, and grow to 5MB before logging rolls over to the next file. If you have only one storage group, all your logs will begin with E00, and each successive storage group’s log files will begin with E01, E02, etc. Periodically, a checkpoint file is created which stores information that includes the last log file necessary for recovering the database in the event of a system failure. More on that later on in the article.

When you mount a database, it attaches to the log files, and when you gracefully dismount a database, it detaches. But when a server crashes, the database cannot detach itself from the logs, and finds itself in a “dirty state”. When the server comes back up, recovery runs, comparing what is in the logs to what is in the database, and when everything matches, the database is clean and mounts successfully.

Symptoms of impending or complete doom

If the Exchange log disk becomes full, bad things will happen. Hopefully, you have a monitoring solution that keeps an eye on free disk space on critical volumes. If you do, keep your eyes open (that is, create an alert) for event ID 2013 in the system log. That event indicates a volume is below 10% free space (by default, adjustable, see here) and is your chance to do something about the dwindling disk space before it is too late. You’ll want to set the equivalent of battle stations on event ID 429 from ESE, which indicates that the volume storing your logs is completely out of space.

If the drive storing your log files does run out of space, all the databases on the Exchange server will dismount, and you will not be able to mount them. The first sign of this will probably be several dozen users all calling in at once to say they cannot connect to their email, followed seconds later by your boss asking if Exchange just crashed. Remember, if Exchange cannot write anything to the log, it won’t be able to write it to the database, so even if the database volume has tons of free space, the log volume will take you down just as quickly and completely.

What to do when it happens to you

Odds are good that you skipped straight over the middle sections to this part. Remember, don’t panic. It’s probably instinctive to start deleting older log files in an effort to free up space; that works fine on most other servers, but it is not what you want to do here.

What to do if you are almost out of space:

If you Exchange log disk is almost, but not completely, out of space, there’s time to act in a cautious and methodical way. If you can perform a full backup of all the Exchange databases in the storage group, that will purge out the old logs automatically, and free up space. If you cannot perform a full backup of all the databases, and it looks like you are going to run out of space before you can, continue on with the next section.

What to do if you are completely out of space:

If you can perform a full backup of your database, Exchange will purge out all the old logs it no longer needs, which should free up significant space. Of course, you should have been doing that anyway, and if you were, you probably wouldn’t need this article. If you cannot do a full backup, here is what you can do:

1. Determine the path and name of your database log check file. It will be in the database log directory, and will be named E0x.chk.
2. Open an administrative command prompt, and run this command, filling in the appropriate path to your bin directory and your check file, and changing x to the correct number for your database.
   pathtobin\eseutil.exe /MK pathtologs\e0x.chk [enter]
3. That will return a value such as
   Checkpoint (0x35EA,1B33,A4)

That first value, 0x35EA, indicates the oldest log file you will need to recover your database. If your database is E0, then that file is E035EA.log. Take any files older than that one, and move them to another location. Don’t delete them until you are absolutely certain that you have a valid full backup and won’t ever need to restore an older backup. Here’s a tip: they compress really well. In the absolute worst case scenario, compress all the older files in place a few at a time to buy yourself some more time. Don’t try to do them all at once though, as your compression utility may take the last bit of available space while trying to compress all the files. Start with the very oldest, and work your way forward to the last file you need to save for database recovery.

How to move your logs to another volume

If you need to move your logs to a different volume, you can do so using the Exchange Management Shell. Remember that you will have to dismount the database before you do this, which means users will be disconnected temporarily.

Move-StorageGroupPath -Identity “MyStorageGroup” -LogFolderPath “D:\MyNewLogFolder” [enter]

Remount the database, and users will be back in business in no time.

When you find the Exchange log disk full, users won’t be able to connect to their mailboxes, and any inbound mail destined to them will begin to queue up or even be refused with an NDR, so you will obviously want to act quickly. Remember, you do not want to just start deleting log files. Identify which Exchange log files you need to leave in the logging directory, take all the rest and move them somewhere you can retrieve them if you ever need to restore from a backup, and then either expand the volume of relocate the logging directory to a different volume. When the Exchange 2007 log disk gets full you will have a service interruption, but you can quickly recover without any lasting impact if you don’t panic, and follow the steps above.

Article By: Eva Ciganova (90 Posts)