Controlling the Information Store

The Exchange information store contains storage groups and databases. You can create and manage storage groups in a variety of ways.

Creating Storage Groups

You can create a storage group by completing the following steps:

1. In Exchange Management Console, expand the Server Configuration node, and then select the related Mailbox node.

2. In the details pane, right-click the mailbox server you want to manage, and then select New Storage Group from the shortcut menu. You should now see the New Storage Group wizard, as shown in Figure 11-1.

3. The Server Name text box is set based on the server you selected. In the Storage Group Name text box, type a descriptive name for the storage group. If you want to follow the default naming convention, name each storage group in sequence, as in Second Storage Group, Third Storage Group, and so on.

4. Click Browse to the right of the Log Files Path text box. Use the Browse For Folder dialog box to select a location for the transaction logs, and then click OK. If you need to create a new folder, navigate to the location where you'd like to place the folder, click Make New Folder, type the name of the new folder, press Enter, and then click OK. You can't store files for additional storage groups in the same directory in which you have an existing storage group.

   Tip Each storage group has its own set of transaction logs. These logs are used to perform transactional processing within Exchange Server. To improve performance, you could place each set of transaction logs on a physically separate drive. The number of transaction log drives should equal the number of storage groups you're using. For example, if a server uses two storage groups, the server should have two transaction log drives. To protect transaction log drives against failure, you should mirror them as well. RAID 1 (disk mirroring) is recommended over RAID 5 (disk striping with parity) because you'll have better write performance with RAID 1 in most instances-and the transaction log drives are frequently written to on busy servers.

5. Click Browse to the right of the System Files Path text box, select a location for the system files that the storage group will use, and then click OK.

6. If you want to enable LCR for the storage group, select the Enable Local Continuous Replication For This Storage Group check box, and then set the backup locations for transaction logs and system files using the Browse buttons provided. Click each Browse button in turn, select a backup location, and then click OK.

   Note 

   When you add a database to a storage group for which LCR has been enabled, you can enable LCR for the database. The default database backup location is the backup system files folder. You can set a different backup location if desired.

7. Click New to create the storage group, and then click Finish. You can now add databases to the storage group as appropriate.

   In Exchange Management Shell, you can create storage groups using the new-StorageGroup cmdlet. Sample 11-1 provides the syntax and usage.

Figure 11-1: Set the storage group name and file locations.

Sample 11-1: new-StorageGroup cmdlet syntax and usage

 Syntax new-StorageGroup -Server 'CORPSVR127' -Name 'Third Storage Group'  -LogFolderPath 'FolderPath'  -SystemFolderPath 'FolderPath'  -HasLocalCopy Switch  [ -CopyLogFolderPath 'FolderPath']  [ -CopySystemFolderPath 'FolderPath'] Usage new-StorageGroup -Server 'CORPSVR127' -Name 'Third Storage Group'  -LogFolderPath 'E:\Exchange Logs\Third Storage Group'  -SystemFolderPath 'F:\Exchange System Files\Third Storage Group'  -HasLocalCopy $true  -CopyLogFolderPath 'H:\Backup System Files\Third Storage Group'  -CopySystemFolderPath 'G:\Backup Logs\Third Storage Group' 

Enabling Local Continuous Replication for an Existing Storage Group

When a storage group contains a single database, you can enable LCR to improve availability. LCR is used to replicate transaction logs and system files, which enables log replay and faster recovery in case of failure. For optimal performance, you'll want to configure LCR to use separate backup locations for transaction logs and system files.

Note 

If your Exchange 2007 organization has more than one public folder database, you cannot enable LCR for your public folder databases. When there are multiple public folder databases, public folder replication occurs automatically, even if there are no public folders to replicate.

You can enable LCR for a storage group by completing the following steps:

1. In Exchange Management Console, expand the Server Configuration node, and then select the related Mailbox node.

2. In the details pane, select the mailbox server you want to manage. You should see a list of storage groups that are available on the server.

3. Right-click the storage group you want to change, and then select Enable Local Continuous Replication from the shortcut menu. You should now see the Enable Storage Group Local Continuous Replication.

4. Click Next. On the Set Paths page, shown in Figure 11-2, click Browse to the right of the Local Continuous Backup System Files Path text box, select a location for the backup system files, and then click OK.

5. Click Browse to the right of the Local Continuous Backup Log Files Path text box, select a location for the backup log files, and then click OK. Click Next.

6. If the storage group has a database associated with it, you'll see the Mailbox Database or Public Folder Database page next. Click Browse, select the backup location for the related database file, and then click OK. The default location is the backup system files folder. Click Next.

7. Click Enable, and then click Finish.

Figure 11-2: Set the backup location for the storage group.

In Exchange Management Shell, you can enable LCR for a storage group using the enable-StorageGroupCopy cmdlet. If the storage group has a database for which LCR should be enabled as well, you can use the enable-DatabaseCopy cmdlet to do this. Always run enable-DatabaseCopy prior to running enable-StorageGroupCopy. Samples 11-2 and 11-3 provide the syntax and usage for these cmdlets.

Sample 11-2: enable-DatabaseCopy cmdlet syntax and usage

 Syntax enable-DatabaseCopy -Identity 'DatabaseIdentity'  -CopyEdbFilePath 'FilePath' Usage enable-DatabaseCopy -Identity 'CORPSVR127\Third Storage Group\MarketingMail'  -CopyEdbFilePath 'J:\DBCopies\Third Storage Group\MarketingMail.edb' 

Sample 11-3: enable-StorageGroupCopy cmdlet syntax and usage

 Syntax enable-StorageGroupCopy -Identity 'StorageGroupIdentity'  -CopyLogFolderPath 'FolderPath'  -CopySystemFolderPath 'FolderPath' Usage enable-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group'  -CopyLogFolderPath 'H:\Backup System Files\Third Storage Group'  -CopySystemFolderPath 'G:\Backup Logs\Third Storage Group' 

Initiating or Resynchronizing Local Continuous Replication

The update-StorageGroupCopy cmdlet allows an administrator to manually initiate or resynchronize LCR. Manually initiating or resynchronizing LCR creates or re-establishes a baseline copy of logs, system files, and the related database, allowing you to overwrite a corrupted LCR copy or invalid baseline. An example of when you might want to resynchronize the LCR copy is when you've recovered a database or server.

The update-StorageGroupCopy cmdlet requires that no Exchange files exist in the target location when you run it and that you have suspended the LCR. After you've resynchronized the LCR copy, you can resume LCR copying. Sample 11-4 provides the syntax and usage for a resynchronization script.

Sample 11-4: Resynchronizing Local Continuous Replication syntax and usage

 Syntax suspend-StorageGroupCopy -Identity 'StorageGroupIdentity'  -SuspendComment 'Comment' update-StorageGroupCopy -Identity 'StorageGroupIdentity' resume-StorageGroupCopy -Identity 'StorageGroupIdentity' Usase suspend-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group'  -SuspendComment 'Suspending LCR for resync'  update-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group'  resume-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group' 

Disabling, Suspending, or Resuming Local Continuous Replication

After you've configured LCR, you can manage it in two key ways. If you no longer want to create backups, you can disable this feature. If you want to temporarily disable backups, as may be necessary when you are performing maintenance, you can suspend backups temporarily and then resume them.

To disable LCR for a storage group, follow these steps:

1. In Exchange Management Console, expand the Server Configuration node, and then select the related Mailbox node.

2. In the details pane, select the mailbox server you want to manage. You should see a list of storage groups that are available on the server.

3. Right-click the storage group, and then select Disable Local Continuous Replication.

4. When prompted to confirm the action, click Yes.

5. As necessary, manually delete the backup copies from the backup locations.

To temporarily suspend and then resume LCR for a storage group, follow these steps:

1. In Exchange Management Console, expand the Server Configuration node, and then select the related Mailbox node.

2. In the details pane, select the mailbox server you want to manage. You should see a list of storage groups that are available on the server.

3. Right-click the storage group, and then select Suspend Local Continuous Replication.

4. When prompted to confirm the action, type a comment to record in the application event log, and then click Yes.

5. As necessary, perform maintenance or recovery operations. When you are finished, right-click the storage group, and then select Resume Local Continuous Replication.

6. When prompted to confirm the action, click Yes.

In Exchange Management Shell, you can disable, suspend, and resume Local Continuous Replication for a storage group using the disable-StorageGroupCopy, suspend-StorageGroupCopy, and resume-StorageGroupCopy cmdlets, respectively. Samples 11-5 through 11-7 provide the syntax and usage for these cmdlets.

Sample 11-5: disable-StorageGroupCopy cmdlet syntax and usage

 Syntax disable-StorageGroupCopy -Identity: StorageGroupIdentity' Usage disable-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group' 

Sample 11-6: suspend-StorageGroupCopy cmdlet syntax and usage

 Syntax suspend-StorageGroupCopy -Identity 'StorageGroupIdentity'  -SuspendComment 'Comment' Usage suspend-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group'  -SuspendComment 'Suspending LCR for maintenance' 

Sample 11-7: resume-StorageGroupCopy cmdlet syntax and usage

 Syntax resume-StorageGroupCopy -Identity 'StorageGroupIdentity' Usage Resume-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group' 

Moving Storage Groups

As discussed earlier, the transaction log location and system path have an important role in managing Exchange Server performance. The transaction log location determines where primary, secondary, and reserved log files are stored. The system path determines where check files are stored and where temporary transactions are processed. If you enable LCR, you can have separate backup locations for transaction logs and system files as well.

You can change the locations for transaction logs, system files, and backups for an existing storage group by completing the following steps:

1. In Exchange Management Console, expand the Server Configuration node, and then select the related Mailbox node.

2. In the details pane, select the Mailbox server you want to manage. You should see a list of storage groups that are available on the server.

3. If you have enabled LCR for the storage group, right-click the storage group, and then select Suspend Local Continuous Replication. When prompted to confirm the action, type a comment to record in the application event log, and then click Yes.

4. Right-click the storage group you want to change, and then select Move Storage Group Path from the shortcut menu. You should now see the Move Storage Group Path wizard, as shown in Figure 11-3.

5. Click Browse to the right of the Log Files Path text box, select a new location for the storage group's transaction logs, and then click OK. The folder location must already exist. If the folder location doesn't exist, you'll need to either create it in Windows Explorer or click New Folder in the Browse window.

6. Click Browse to the right of the System Files Path text box, select a new location for the storage group's system files, and then click OK. The folder location must already exist. If the folder location doesn't exist, you'll need to either create it in Windows Explorer or click New Folder in the Browse window. If you don't place the system files on a separate drive, you should place them on the same drive as the transaction logs.

7. If you have enabled LCR for the storage group, set the backup locations for transaction logs and system files using the Browse buttons provided. Click each Browse button in turn, select a backup location, and then click OK.

8. Click Move. Exchange will validate the paths you've provided and then move the files. Click Finish when this process completes.

   Note 

   If you've enabled LCR but replication has not yet begun, you may see an error stating that the backup paths are invalid. This occurs because there are no backup files to copy at this time, and you can ignore the error.

9. If LCR is enabled for the storage group, right-click the storage group, and then select Resume Local Continuous Replication. When prompted to confirm the action, click Yes.

Figure 11-3: Move the storage group's files to new locations.

In Exchange Management Shell, you can move storage groups using the move-Storage-GroupPath cmdlet. Sample 11-8 provides the syntax and usage. With LCR, you must suspend copying before moving the storage group and then resume copying after moving the storage group.

Sample 11-8: move-StorageGroupPath cmdlet syntax and usage

 Syntax move-StorageGroupPath -Identity 'StorageGroupIdentity'  -LogFolderPath 'NewFolderPath'  -SystemFolderPath 'NewFolderPath'  [ -CopyLogFolderPath 'NewFolderPath']  [ -CopySystemFolderPath 'NewFolderPath'] Usage move-StorageGroupPath -Identity 'CORPSVR127\Third Storage Group'  -LogFolderPath 'E:\Exchange Logs\Third Storage Group'  -SystemFolderPath 'F:\Exchange System Files\Third Storage Group'  -CopyLogFolderPath 'H:\Backup System Files\Third Storage Group'  -CopySystemFolderPath 'G:\Backup Logs\Third Storage Group' 

Tracking Local Continuous Replication Status

You can track the status of LCR on a per-storage group basis. The status details provided allow you to quickly determine the overall health of an LCR copy as:

• Disabled LCR is disabled for the storage group and its related database.

• Broken Verification failed, as the database or logs were incompatible with each other or the storage group is improperly configured for LCR.

• Seeding Database seeding is in progress.

• Stopped Transaction log copying is stopped.

• Copying Transaction log replay is suspended but copying is enabled.

• Healthy LCR is currently healthy and operating normally.

Queuing details can help you determine whether Exchange is able to keep the LCR copy current. If the copy queue length is more than five, or if the replay queue length is more than 20, Exchange is not able to keep up with the demands required by LCR copying. To resolve this, you'll need to determine the cause of the performance bottleneck. Typically, the bottleneck will be the drive to which you are writing the LCR copy. You may be able to resolve this problem by moving the LCR copies to new disks.

Although the usual suspect is the drive to which you are writing the LCR copy, the problem could also be with the server's CPUs and RAM. If the computer's CPUs are consistently at 80 percent utilization or higher, you'll need to correct this problem by adding CPUs or installing faster CPUs. If the computer's available physical memory is consistently low, you'll need to correct this problem by adding virtual memory, RAM, or both.

To use the Exchange Management Console to view LCR statistics, follow these steps:

1. In Exchange Management Console, expand the Server Configuration node, and then select the related Mailbox node.

2. In the details pane, select the mailbox server you want to manage. You should see a list of storage groups that are available on the server.

3. Right-click the storage group you want to work with, and then select Properties.

4. In the Properties dialog box, select the Local Continuous Replication tab and review the displayed statistics.

In Exchange Management Shell, you view LCR statistics using the get-StorageGroup-CopyStatus cmdlet. Sample 11-9 provides the syntax and usage for this cmdlet.

Sample 11-9: get-StorageGroupCopyStatus cmdlet syntax and usage

 Syntax get-StorageGroupCopyStatus -Identity 'StorageGroupIdentity' Usage get-StorageGroupCopyStatus -Identity 'CORPSVR127\Third Storage Group' Example Output Identity: CORPSVR127\Third Storage Group StorageGroupName: Third Storage Group SummaryCopyStatus: Broken Broken: True BrokenMessage: InvalidFilePath: StorageGroup CORPSVR127\Third Storage Group, path Third Storage Group. Seeding: False ReplaySuspend: False ReplaySuspendComment: CopySuspend: False CopySuspendComment: CopyQueueLength: 0 ReplayQueueLength: 0 LatestAvailableLogTime: 2/17/2007 3:17:55 AM LastCopyNotificationedLogTime: 2/17/2007 3:17:55 AM LastCopiedLogTime: 2/17/2007 3:17:55 AM LastInspectedLogTime: 2/17/2007 3:17:55 AM LastReplayedLogTime: 2/17/2007 3:17:55 AM LastLogGenerated: 3 LastLogCopied: 3 LastLogInspected: 3 LastLogReplayed: 3 LatestFullBackupTime: LatestIncrementalBackupTime: SnapshotBackup: IsValid: True ObjectState: Unchanged 

As you can see from the example output, the get-StorageGroupCopyStatus cmdlet provides detailed tracking information. Table 11-3 provides a summary of these statistics.

Table 11-3: Table 11-3 Summary of LCR Statistics
Open table as spreadsheet

LCR Statistic	Statistic Description
Broken	When set to True, indicates that verification of the database or logs identified an inconsistency that prevents replication, or that there is a configuration or access problem with the active or passive copy.
BrokenMessage	When Broken is True, this statistic identifies the condition that caused replication to become broken, such as an invalid file path.
CopyQueueLength	Shows the number of transaction log files waiting to be copied to the backup log folder. A copy is not considered completed until it has been checked for corruption.
CopySuspend	When True, indicates that log copying has been halted for the passive copy. This prevents the backup log folder from changing.
CopySuspendComment Shows the optional administrator comment, providing a reason why log copy activity was suspended.	Identity
Shows the server and name of the queried storage group. LastCopiedLogTime	Shows the time of the last successful copy of a transaction log file.
LastCopyNotificationedLogTime	Shows the time the last copy notification occurred.
LastInspectedLogTime	Shows the time of the last successful inspection of a transaction log file.
LastLogCopied	Shows the last log generation number that was successfully copied to the backup log folder.
LastLogGenerated	Shows the last log generation number that was known to be generated on the active copy of the database.
LastLogInspected	Shows the last log generation number that was inspected.
LastLogReplayed	Shows the last log generation number that was successfully replayed into the passive copy of the database.
LastReplayedLogTime	Shows the time of the last successful replay of a transaction log file.
LatestAvailableLogTime	Shows the time of the most recently detected new transaction log file.
LatestFullBackupTime	Shows the time of the last full backup.
LatestIncrementalBackupTime	Shows the time of the last incremental backup.
ReplayQueueLength	Shows the number of transaction log files waiting to be replayed into the passive copy.
ReplaySuspend	When True, indicates that replay has been suspended for the passive copy. This prevents log replay.
ReplaySuspendComment	Shows the optional administrator comment, providing a reason why replay activity was halted.
Seeding	When True, indicates that seeding is in progress.
SnapshotBackup	Shows the time of the last snapshot backup.
StorageGroupName	Shows the name of the queried storage group.
SummaryCopyStatus	Shows the current overall status of LCR.

Verifying Your Local Continuous Replication Copies

When you use LCR, you should regularly verify the LCR copies to ensure that they are valid and usable. You can do this using the /K parameter of the Extensible Storage Engine Utility (Eseutil.exe). Before you run Eseutil, however, you should suspend LCR. After verification, you should resume LCR.

If you configure these tasks as a script that runs as a scheduled task, you'll be able to easily schedule verification to run during off-peak usage hours. Be sure to redirect the output of Eseutil to a log file so that you can determine if errors were generated. Sample 11-10 provides the syntax and usage for a verification script.

Note 

By default, Eseutil.exe is located in %SystemDrive%∖Program Files ∖Microsoft∖Exchange Server∖bin. This folder path must be part of the file path for the user under which the scheduled task runs. Eseutil.exe has other parameters that you can use for maintenance and repair. Related topics are covered in Chapter 12 and Chapter 18, "Backing Up and Restoring Microsoft Exchange."

Sample 11-10: Verifying LCR syntax and usage

 Syntax suspend-StorageGroupCopy -Identity 'StorageGroupIdentity'  -SuspendComment 'Comment' eseutil /k 'LogFilePrefix' >> TransLogFilePath eseutil /k 'DatabaseFilePath' >> DBLogFilePath resume-StorageGroupCopy -Identity 'StorageGroupIdentity' Usage suspend-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group'  -SuspendComment 'Suspending LCR for maintenance' eseutil /k 'E00' >> C:\tlogs.log eseutil /k 'J:\DBCopies\Third Storage Group\MarketingMail.edb' >> C:\db.log resume-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group' 

Enabling and Disabling Circular Logging

Circular logging allows Exchange Server to overwrite transaction log files after it has committed the data they contain to the database. Overwriting old transactions reduces the disk space requirements for Exchange Server, yet makes it impossible to recover Exchange Server up to the last transaction. If you enable circular logging, you can recover Exchange Server only up to the last full backup.

You control circular logging at the storage group level, which allows each storage group to have a different policy for logging. You cannot enable circular logging if LCR is enabled.

To enable or disable circular logging, complete the following steps:

1. In Exchange Management Console, expand the Server Configuration node, and then select the related Mailbox node.

2. In the details pane, select the mailbox server you want to manage. You should see a list of storage groups that are available on the server.

3. Right-click the storage group you want to change, and then select Properties from the shortcut menu.

4. Select or clear the Enable Circular Logging check box, as appropriate, and then click OK.

Caution 

Caution If you enable circular logging, you are limiting your recovery options for Exchange Server. As mentioned previously, you will be able to recover Exchange Server only up to the last full backup. Thus, you won't be able to successfully apply changes contained in differential or incremental backups that were created after the last full backup.

In Exchange Management Shell, you can enable or disable circular logging using the –CircularLoggingEnabled parameter of the set-StorageGroupCopy cmdlet. Sample 11-11 provides the syntax and usage for this parameter and cmdlet.

Sample 11-11: Enabling or Disabling circular logging syntax and usage

 Syntax set-StorageGroupCopy -Identity 'StorageGroupIdentity'  -CircularLoggingEnabled Switch Usage set-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group'  -CircularLoggingEnabled true$ 

Renaming Storage Groups

Renaming storage groups is simple. Right-click the storage group, and select Properties from the shortcut menu. In the Properties dialog box, delete the current name, type a new one, and then click OK. What you don't see are the repercussions of renaming, and this is what you need to be aware of.

All objects in Active Directory are located by a unique identifier that uses the directory namespace and works through each element in the directory hierarchy to a particular object. When you change the name of a storage group, you change the namespace for all the objects in that storage group, which includes databases, mailboxes, and more. Thus, the simple act of renaming a storage group has a definite impact on Exchange Server.

In Exchange Management Shell, you can rename a storage group using the –Name parameter of the set-StorageGroupCopy cmdlet. Sample 11-12 provides the syntax and usage for this parameter and cmdlet.

Sample 11-12: Renaming a storage group syntax and usage

 Syntax set-StorageGroupCopy -Identity 'StorageGroupIdentity'  -Name 'Name' Usage set-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group'  -Name 'Storage Group 3' 

Deleting Storage Groups

Before attempting to delete a storage group, you must delete or move the databases it contains. Exchange Server allows you to delete storage groups only when they are empty (that is, only when they contain no databases).

When the storage group is empty, right-click the storage group, and then select Remove from the shortcut menu to remove it. When prompted, confirm the action by clicking Yes.

In Exchange Management Shell, you can remove a storage group using the remove-StorageGroupCopy cmdlet. Sample 11-13 provides the syntax and usage for this cmdlet.

Sample 11-13: remove-StorageGroup cmdlet syntax and usage

 Syntax remove-StorageGroupCopy -Identity 'StorageGroupIdentity' Usage remove-StorageGroupCopy -Identity 'CORPSVR127\Third Storage Group'