Exchange 2003, Checkpoint Files and SBS 2003

This post is compiled from an email thread on the MSSmallBiz Yahoo! Group from around April, 2008.

The original question was regarding an Exchange Store that wouldn't mount and I brought up the issue that SBS 2003 has with Exchange Checkpoint files. Basically, if you install the Exchange Server component of SBS 2003 to a location other than drive C: and leave the Exchange databases in that same location (or at least that same partition), then you won't have any issues. However if you install the Exchange Server components to the C:\ partition and use a different partition for the databases (ie, closer to the Exchange best practices) then you will have an issue with the Checkpoint files unless you know to move them.

Here's the information I gave on how to ensure this is taken care of:

First, a bit of info on the checkpoint files for Exchange.

Microsoft Exchange uses a checkpoint file per storage group (and as there's only one Storage Group available with SBS, there's only going to be a single checkpoint file, E00.chk, in an SBS environment, unless you've blown it out to Exchange Enterprise for some reason). The checkpoint file keeps information on the last transaction that was committed from the log files into the Exchange store database. As you can imagine, keeping this checkpoint file in synch with the log files is rather important.

Ideally, MS Exchange should be run with the OS and Exchange binaries on a RAID-1 array, the pagefile should be on a separate RAID-1 array, there should be a RAID-1 or RAID-0+1 array for the transaction logs and a separate RAID-1, RAID-0+1 or RAID-5 array for each storage group database. If you really wanted to build for performance, you'd then, in addition to this, split the .edb files andf the .stm files onto separate, optimized arrays. In an SBS environment, you can easily see that this absolutely stands no chance of being deployed, so we need to look at a less-than-optimal Exchange Server installation.

So, in an SBS world, with a single server with as few disks as we can manage to install, we recommend that you use at least 2 RAID arrays, the first (for the OS and applications) being RAID-1 and the second (being for data) being RAID-1, RAID-0+1, RAID-5 or RAID-6 depending on the needs of the client. Remember, however, that in both a RAID-1 and RAID-5 array, the loss of a single drive leaves the array in a non-redundant status, which needs to be addressed as a matter of urgency. In this case, we recommend that you install SBS + Exchange program files onto the C: drive (RAID-1 array) and the database, log files and checkpoint file onto the second array in a dedicated, aligned partition.

Now, although some Exchange tuning guides recommend storing the databases on the C: drive, that is something that we'd never recommend as we don't feel that the C: partition is the place to store any data. Especially not Exchange databases.

Now, because the log files and the E00.chk file are extremely interdependent, we strongly suggest storing the E##.chk files with their respective transaction logs - if not in the same directory, at least on the same partition.

This all becomes *critical* when image backups instead of file backups are being used. When using file backups, if you take a backup of the Exchange Stores, the transaction logs and the checkpoint files, they can all reside anywhere on the system and they will be backed up together. However there's the *slight* chance that the checkpoint file and transaction logs will be out of sync if the backup takes some time. There's no way to be 100% sure unless Exchange is stopped before backing these all up, which is what we're ultimately trying to avoid.

When using image backups, if the .chk file is left on C:\Program Files\ExchSrvr\MDBDATA as happens with a regular, unHiltonized SBS installation, and the C: partition is imaged at a different time to the E: partition (containing the Exchange databases and log files), then if the C: partition is restored due to a system failure, say 2 weeks later or even one hour later, the E00.chk file will think that one particular transaction has been rolled in, say 12345 and the Exchange transaction logs will be well past this point, say at 13456. This will cause Exchange to crack the sh+s. The checkpoint file and the transaction logs will be out of sync and Exchange will simply run around waving its arms madly in the air.

If you HAVE done this, before you mount the Exchange stores, the best thing to do is to delete the incorrectly versioned E00.chk file and cause Exchange to process every transaction in every log file, on the disk, starting from the oldest, to find the last transaction that was written to the database, and then it will recreate the E00.chk file and continue to roll transaction log entries into the store databases. Not fun, but not a reason to look at hanging yourself from a USB extension cable, either.

So, if you have a Hiltonized SBS install whereby the .chk files are now living peacefully with your transaction logs and the C: partition needs to be restored from an image, you'll have no issues with regards Exchange transaction logs and checkpoint file(s) being out of synch. Of course, if you've added or removed users, then AD and the Exchange Stores will be out of synch, which you'll need to fix, however that's not the point of this thread.

Now, to directly answer your question, if you go to ESM\ [Exchange]\Servers\\First Storage Group\\System path location and change this value, Exchange will magically move the current E00.chk file to the new location and keep running.

Regards,

The Outspoken Wookie