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).
As mentioned earlier in this chapter, you need to suspend LCR on the storage group for
which you want to verify the integrity of the passive database and log files.
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.
Figure 8.21 Log file prefix. (Click on image for enlarged view.)
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.
Figure 8.22 Integrity check of the LCR log files. (Click on image for enlarged view.)
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.
Figure 8.23 Integrity check of the LCR database copy. (Click on image for enlarged view.)
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
Home: Introduction
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
