Configuring LCR is pretty simple to do and it can be done via the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). We will take you through a configuration of LCR using the EMC and then cover the necessary EMS steps to accomplish the same tasks.
To enable a storage group to use LCR via the EMC, you can use a wizard. In the EMC, locate the storage group in the Server Configuration work center and under the Mailbox subcontainer. Highlight the server name in the Results pane and then locate the storage group in the Work pane. Select the Enable Local Continuous Replication task in the Actions pane; this runs the Enable Storage Group Local Continuous Replication Wizard. The Introduction page of this wizard is shown in Figure 6.15.
Figure 6.15 Starting the Enable Storage Group Local Continuous Replication Wizard
All you have to do on the Introduction page of the wizard is confirm the storage group name and confirm that there is only a single database in the storage group. The database list is labeled ‘‘Database Names,’’ but the wizard will stop you later if the storage group has more than one database.
Just like creating a storage group, you must define the location of the transaction log files and the system files. On the Set Paths page (shown in Figure 6.16), you must specify the LCR paths
for the transaction logs and system files. Ideally, these paths should be on a separate physical disk from the original transaction logs, the original database, and the LCR database.
Figure 6.16 Specifying LCR paths for transaction logs and system paths
The screen capture shown in Figure 6.17 shows the Engineering Mailboxes page of the Enable Storage Group Local Continuous Replication Wizard. This page is unique to the database con- tained in the storage group you have selected and thus will usually be different depending on the database that appears in the Database Names field.
On the Engineering Mailboxes page, the only thing you can specify is the location of the LCR database. Ideally, like the LCR path for the system and transaction log files, this should path should be on a separate physical disk from the original database and transaction log files as well as the LCR transaction log and system files.
The Enable page of the wizard simply shows the configuration summary of what tasks are about to be performed.
Once the Enable button is clicked on the Enable page, theEnable-DatabaseCopyandEnable- StorageGroupcopy cmdlets are used to enable LCR for this storage group and database. The following are the commands that are actually executed by the wizard:
Enable-DatabaseCopy -Identity ’HNLEX03\Engineering Mailboxes SG\Engineering Mailboxes’
-CopyEdbFilePath ’D:\Engineers-Mailboxes-LCR\Engineering Mailboxes.edb’
Enable-StorageGroupCopy -Identity ’CN=Engineering Mailboxes SG,CN=InformationStore, CN=HNLEX03,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),
CN=Administrative Groups,CN=Volcano Surfboards,CN=Microsoft Exchange,CN=Services, CN=Configuration,DC=volcanosurfboards,DC=com’
-CopyLogFolderPath ’D:\EngineersSG-LCR’ -CopySystemFolderPath ’D:\EngineersSG-LCR’
Figure 6.17
Specifying a path for the LCR database
Notice that the fully qualified distinguished name was used in theEnable-StorageGroupCopy command to identify the storage group name. To help you disseminate and decode what was done, here is a summary of the configuration parameters used to enable LCR for the storage group and database:
Storage group name Engineering Mailboxes SG
Database name Engineering Mailboxes
LCR transaction logs path D:\EngineersSG-LCR LCR system files path D:\EngineersSG-LCR
LCR database path D:\Engineers-Mailboxes-LCR
Managing Local Continuous Replication
Once LCR is enabled for a storage group, there are a few management tasks that you may need to perform. Management tasks for LCR include checking the health of a storage group’s replication, suspending replication, resuming replication, and resynchronizing (aka reseeding) the entire database.
Health Checks
Now that storage group replication is enabled, you can confirm that it is working in a number of different ways. The first is just to look at the listing of storage groups and databases names in the Work pane. Notice for the Engineering Mailboxes SG that the value in the Copy Status column is Healthy.
Here are the possible status values you may see in the Copy Status column (or in the SummaryCopyStatusproperty when you use the EMS cmdlet):
◆ Healthy means that LCR is working normally and data is replicating and being committed to the LCR copy of the database.
◆ Disabled means that LCR is not configured.
◆ Suspended means that an operator has temporarily stopped replication. ◆ Seeding means that the production database is being copied to the LCR location. ◆ Failed means that something has failed during the replication process and there may be
problems with the configuration, logs, or database. Consult the event logs.
◆ Not Supported means that the current configuration does not support or allow LCR. Using the EMS cmdletGet-StorageGroupCopyStatus, you can retrieve more useful and detailed information about the LCR status of a particular storage group. Here is an example:
Get-StorageGroupCopyStatus ”Engineering Mailboxes SG” | Format-List Identity : HNLEX03\Engineering Mailboxes SG StorageGroupName : Engineering Mailboxes SG
SummaryCopyStatus : Healthy CCRTargetNode : Failed : False FailedMessage : Seeding : False Suspend : False SuspendComment : CopyQueueLength : 2 ReplayQueueLength : 9 LatestAvailableLogTime : 12/10/2006 11:39:27 PM LastCopyNotificationedLogTime : 12/10/2006 11:39:27 PM LastCopiedLogTime : 12/10/2006 11:39:26 PM LastInspectedLogTime : 12/10/2006 11:38:45 PM LastReplayedLogTime : 12/10/2006 11:33:18 PM LastLogGenerated : 1768 LastLogCopyNotified : 1768 LastLogCopied : 1767 LastLogInspected : 1766 LastLogReplayed : 1757 LatestFullBackupTime : 11/25/2006 12:05:57 PM LatestIncrementalBackupTime : 12/4/2006 8:46:09 PM SnapshotBackup : False IsValid : True ObjectState : Unchanged
Suspending and Resuming Replication
There is really not much that you need to do to an LCR database once it is replicating. If you have to do maintenance on the disk on which LCR is running or if you want to stop all replication,
you can highlight the storage group that is running LCR and click Suspend Local Continuous Replication in the Actions pane. When you choose to suspend LCR, you are prompted for a reason. Simply type a reason and click Yes.
To resume LCR on the storage group, select the storage group and then click Resume Local Continuous Replication in the Actions pane. You will be prompted to confirm that this is what you want to do and you will see the reason that LCR was suspended previously.
You can accomplish the same thing using theSuspend-StorageGroupCopyandResume- StorageGroupCopycmdlets:
Suspend-StorageGroupCopy ”Engineering Mailboxes SG” -SuspendComment ”LC R disk maintenance on December 12” -Confirm:$False
Once LCR is suspended, you can confirm it also using theGet-StorageGroupCopyStatus cmdlet, as you can see in this example:
get-storagegroupcopystatus ”Engineering Mailboxes SG” | FL Identity,StorageGroupName,SummaryCopyStatus,SuspendComment Identity : HNLEX03\Engineering Mailboxes SG
StorageGroupName : Engineering Mailboxes SG SummaryCopyStatus : Suspended
SuspendComment : LCR disk maintenance on December 12
The Application event log will contain event ID 2083 from the MSExchangeRepl service indi- cating that replication for the storage group has been suspended:
Event Type: Information Event Source: MSExchangeRepl
Event Category: Action Event ID: 2083 Date: 12/10/2006 Time: 11:50:58 PM Computer: HNLEX03 Description:
Replication for storage group HNLEX03\Engineering Mailboxes SG has been suspended.
Tip
If you suspend LCR during busy times for your server, expect to have a lot of logs that need to be replayed when you resume LCR.
When you are ready to resume LCR for that storage group, you can use theResume- StorageGroupCopycmdlet:
Resume-StorageGroupCopy ”Engineering Mailboxes SG”
TheResume-StorageGroupCopycmdlet starts the log files copying and replaying once again and it clears theSuspendCommentproperty. When LCR is restarted, you will see the following event information in the Application event log:
Event Type: Information Event Source: MSExchangeRepl Event Category: Action Event ID: 2084
Date: 12/11/2006 Time: 8:04:24 AM Computer: HNLEX03 Description:
Replication for storage group HNLEX03\Engineering Mailboxes SG has been resumed. You will also see events in the event log indicating that the log files have started copying (event ID 2114) and log files have started replying (event ID 2115). These are normal and
expected:
Event Type: Information Event Source: MSExchangeRepl Event Category: Service Event ID: 2115
Date: 12/11/2006 Time: 8:05:08 AM Computer: HNLEX03 Description:
The replication instance for storage group Engineering Mailboxes SG has started replaying logfiles. Logfiles up to generation 1788 have been replayed.
Resynchronizing Local Continuous Replication
Under some circumstances, it may be come necessary to resynchronize the database or to manually resume replication. This operation is also called reseeding. This may be necessary if you created an LCR database before the original database was created, if you have performed an offline defragmentation of the original database, if the LCR database gets deleted, or if the LCR database becomes corrupted.
The only way to resynchronize the database is to use the EMS cmdlet Update-
StorageGroupCopy. Prior to running this cmdlet, you should suspend LCR for the storage group that you are working on and then delete the LCR files (database and transaction log files) unless you are planning to use the-DeleteExistingFilesparameter. Here is an example:
Update-StorageGroupCopy ”Engineering Mailboxes SG” -DeleteExistingFiles Confirm
Continuous replication seeding found an obsolete checkpoint
’D:\EngineersSG-LCR\E02.chk’ file for storage group copy ’Engineering Mailboxes SG’. The checkpoint file will be deleted, and then the database will be seeded if you confirm now.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is ”Y”):y
Confirm
Continuous replication seeding found an existing target database ’D:\Engineers-Mailboxes-LCR\Engineering Mailboxes.edb’ for storage
group copy ’Engineering Mailboxes SG’. This target database will be deleted, before seeding starts, if you confirm.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is ”Y”):y
This operation can take a fairly significant amount of time if the production database is large. Remember that it is making a copy of the production database. If you do this during a period when the load on the Exchange server is typical, you may affect your end users’ response times when they are using the server. We recommend you perform this operation during off-hours or periods of low usage.