Sdílet prostřednictvím

Standby Continuous Replication: Database Portability

  • Článek

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Applies to: Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

This topic details a scenario in which an organization, Woodgrove Bank, is using standby continuous replication (SCR) and database portability to recover from a failure of a single database. In this scenario, an SCR source database is found to contain physical corruption, and the administrator makes the decision to activate the SCR target database. During activation, SCR is disabled, the SCR target database is mounted as the production database, and user mailboxes are re-homed. After data access has been restored to clients, SCR is again enabled for the storage group to restore redundancy and protection for the SCR target.

SCR and Database Portability

Woodgrove Bank has deployed Microsoft Exchange Server 2007 Service Pack 1 (SP1) and has decided to use SCR to provide a redundant copy of a storage group on a remote Mailbox server. Both Mailbox servers are in the same Active Directory directory service site and are configured to use Active Directory-integrated DNS servers. The Active Directory replication interval for the Active Directory site is configured for 15 minutes.

SCR is configured so that transaction log files are being replicated for a single storage group, SG1, which contains a single database, MBX1. EXMBX1 is the SCR source computer and EXMBX2 is the SCR target computer. The paths for the storage group files (which include the transaction log files) and database file are E:\SG1 and D:\SG1\MBX1.EDB, respectively. These paths are used on both the source and target computers.

These assignments were configured using the following command:

Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

The health and status of SCR for SG1 was verified using the Test-ReplicationHealth and Get-StorageGroupCopyStatus cmdlets in the Exchange Management Shell. For example:

Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2 | fl

To save time during the SCR target activation process, EXMBX2 is preconfigured with a storage group and database that will be used as part of the database portability operations. The storage group and database are named SG1PORT and MBX1PORT, respectively.

Important

SG1PORT and MBX1PORT are separate from the SCR target's storage group and database files. Therefore, the paths for SG1PORT and MBX1PORT should be configured with a temporary path that does not conflict with the SCR target paths.

Note

After MBX1PORT has been created, we recommend that it be mounted and then dismounted, and that all storage group files and the database file be deleted.

SCR Target Activation

A messaging administrator notices an application event log entry that indicates the SCR source database is physically corrupt. Because SCR was enabled for SG1, the decision is quickly made to perform a manual activation of the SCR target database for SG1, and restore data availability. Activation of the SCR target copy begins with dismounting the database in SG1. Then, the SCR target database is made viable for mounting, and then re-homing the mailboxes on the affected mailbox database. This is accomplished by performing the following steps, in order:

  1. The SCR source database is dismounted using the following command:

    Dismount-Database EXMBX1\SG1\MBX1

  2. The process for disabling SCR and making the SCR target database viable for mounting involves running the Restore-StorageGroupCopy cmdlet. This task marks the storage group's database as mountable, and provides a report about the data loss, if any, that will result from mounting the database in the storage group. It also verifies that all of the log files generated by the active copy of the storage group are present in the passive copy's storage group file location. If any log files are missing, the operation will try to copy the missing log files. SCR is disabled and the target database is made viable for mounting using the following command:

    Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

Important

If the SCR source is not available, the Force parameter must be added to the Restore-StorageGroupCopy command.

  1. After the Restore-StorageGroupCopy command has completed, an administrator should verify whether the database is in a Clean Shutdown state. If the database is in a Dirty Shutdown state, the administrator can bring the database to a Clean Shutdown state by running Exchange Server Database Utilities (Eseutil) recovery mode (Eseutil /r) against the database. For detailed steps about how to run Eseutil recovery mode, see How to Run Eseutil /R (Recovery).

    Note

    If the storage group prefix (for example, E00 or E01) is the same for the SCR source (EXMBX1\SG1) and the SCR target storage group that will be used for database portability (EXMBX2\SG1PORT), running Eseutil in recovery mode will not need to be performed. The final database mount operation will bring the database into a Clean Shutdown state after replaying all of the replicated log files.

  2. After the database is in a Clean Shutdown state, the administrator runs two commands that update Active Directory with the new locations for the storage group files and database file. Use the following commands to change the paths for SG1PORT and MBX1PORT from the temporary paths to the paths for the SCR target's storage group and database files:

    Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath E:\SG1 -LogFolderPath E:\SG1 -ConfigurationOnly
Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath D:\SG1\MBX1.EDB -ConfigurationOnly

  3. Next, the database must allow itself to be overwritten during a restore operation. This can be done by selecting the check box for This database can be overwritten by a restore on the database object properties in the Exchange Management Console. This task can also be performed using the following command in the Exchange Management Shell:

    Set-Mailboxdatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true

  4. After the database has been configured to allow itself to be overwritten during a restore, the administrator can mount the database using the following command:

    Mount-Database EXMBX2\SG1PORT\MBX1PORT

  5. After the database is mounted, the mailboxes homed on the SCR source database must be re-homed to point to MBX1PORT on EXMBX2. This can be done by running the Get-Mailbox cmdlet and pipelining the output to the Move-Mailbox cmdlet. During this process, it is important that the Microsoft Exchange System Attendant and system mailboxes not be included in the output from the Get-Mailbox cmdlet that is pipelined to the Move-Mailbox cmdlet. This is done by running the following command:

    Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT

At this point, client access to MBX1PORT is now possible. However, whether users can actually access their mailboxes after they have been moved from EXMBX1\SG1\MBX1 to EXMBX2\SG1PORT\MBX1PORT depends on several factors:

  • Active Directory replication latency   Depending on the number of directory servers, it may take time for the update to propagate throughout the environment.

  • Client access method   Messaging clients running Microsoft Office Outlook 2007 and non-Outlook clients will have access to the user's mailbox after the directory servers used by the user's Client Access server have been updated with the new paths. Messaging clients running Outlook 2003 and earlier versions will require the user's desktop messaging profile to be updated with the new server name if the original server is down or otherwise unavailable. If the original server is online and available to respond to client requests, then messaging clients running Outlook 2003 and earlier versions will have their desktop messaging profile automatically updated by the original server with the new server name, and the desktop messaging profile will not need to be manually modified.

Restoring Redundancy After SCR Target Activation

After clients have access to their mailboxes and mailbox data, the final step is to establish redundancy again by re-enabling SCR. This is done by removing any remaining storage group and database files from EXMBX1. After the files have been removed, the paths for EXMBX1\SG1\MBX1 can be moved to a temporary location, and EXMBX1 can become an SCR target of EXMBX2. After this is done, redundancy will have been restored to the environment.