It's a recommended best practice to periodically verify the integrity of the passive storage group copy to make sure neither the database copy nor any of the log files are corrupted. This is done by running a physical consistency check against both the database copy as well as the log files using Exchange Server Database Utilities (Eseutil.exe).
To verify the physical integrity of the log files that have been replicated to the passive copy of the storage group, you'll need to open either a Command Prompt window or the EMS. In either the Command Prompt window or the EMS you should run Eseutil with the /k switch followed by the log file prefix of the storage group.
The log file prefix for a storage group can be found under the General tab of the respective storage group, as shown in Figure 8.21.
As you can see, the log file prefix for the First Storage Group typically is E00. To see the path for the log files, refer back to Figure 8.8. For the purpose of this example, the path is E:\Mailbox\LocalCopies\First Storage Group, so we'll need to type Eseutil /k "E:\Mailbox\LocalCopies\First Storage Group\E00."
This will initiate checksum mode and start verifying each log file located under the specified path, as shown in Figure 8.22. If no corrupted log files are detected, the operation will complete successfully after a few seconds or minutes, depending on how many log files are contained in the respective folder.
When the log files have been verified, we can move on to checking the integrity of the database copy. This is also done by running Eseutil with the /k switch but instead followed by the full path the database copy. In this example, we need to run the following command: Eseutil /k "E:\Mailbox\LocalCopies\First Storage Group\Mailbox Database.edb".
Eseutil will once again initiate checksum mode and then create a temporary database so that the database copy can be checked for any errors (see Figure 8.23). Again, the time required for the integrity check depends on the size of the database.
When you have performed an integrity check of both the log files and the database copy (and hopefully Eseutil.exe hasn't found too many corrupted log files or issues with the database copy), you should make sure that LCR for the respective storage group is resumed again. Should you be so unlucky that Eseutil.exe finds one or more corrupted log files or corruption in the database copy, you need to disable LCR on the storage group, then remove the corrupted log files and/or database copy file. When the files have been removed, you can re-enable LCR, which will create a database copy and seed it as well as replicate any existing log files from the active copy of the storage group to the specified path.
We'll bet that most of you understand the importance of during periodically integrity checks of both the log files as well as the database copy -- right?
Managing Local Continuous Replication in Exchange 2007
Part 1: Exchange 2007 Local Continuous Replication overview
Part 2: Enabling Local Continuous Replication on a storage group
Part 3: Viewing the status for a Local Continuous Replication copy
Part 4: Switching to the LCR copy for database disaster recovery
Part 5: Suspending and resuming LCR for an Exchange 2007 storage group
Part 6: Manually adding an Exchange 2007 database to a storage group copy
Part 7: Use Eseutil for a passive storage group copy integrity check
Part 8: Disabling LCR on an Exchange 2007 storage group
Part 9: Adding Local Continuous Replication performance objects and counters
Part 10: Exchange 2007 LCR administration summarized
|This chapter excerpt from How to Cheat at Configuring Exchange Server 2007: Including Outlook Web, Mobile, and Voice Access, by Henrik Walther, is printed with permission from Syngress, a division of Elsevier, Copyright 2007.
Click here for the chapter download.