Applies to: Exchange Server 2007
Topic Last Modified: 2007-10-23

This topic explains how to use the Restore-StorageGroupCopy cmdlet in a Microsoft Exchange Server 2007 cluster continuous replication (CCR) or local continuous replication (LCR) solution to activate a passive storage group copy. In a CCR configuration, Restore-StorageGroupCopy is used when the automatic mount support does not mount the database and the administrator must explicitly intervene to mount the database. In this scenario, the administrator uses Restore-StorageGroupCopy prior to performing the Mount-Database operation. In an LCR configuration, Restore-StorageGroupCopy is used to disable LCR and make the passive copy viable for Mount-Database. In both configurations, Restore-StorageGroupCopy is terminating replication to the passive copy and making it viable for the Mount-Database cmdlet.

Syntax


`Restore-StorageGroupCopy -Identity <StorageGroupIdParameter> [-DomainController <Fqdn>] [-Force <SwitchParameter>] [-ReplaceLocations <SwitchParameter>]`

Parameters

Parameter	Required	Type	Description
Identity	Required	Microsoft.Exchange.Configuration.Tasks.StorageGroupIdParameter	The Identity parameter takes one of the following values: GUID Name of storage group
Confirm	Optional	Boolean	The Confirm parameter causes the command to pause processing and requires the administrator to acknowledge what the command will do before processing continues. The default value is $true.
DomainController	Optional	Microsoft.Exchange.Data.Fqdn	To specify the fully qualified domain name (FQDN) of the domain controller to locate the clustered mailbox server, include the DomainController parameter in the command.
Force	Optional	System.Management.Automation.SwitchParameter	The Force parameter can be used when the task is run programmatically and prompting for administrative input is inappropriate. If Force is not provided in the cmdlet administrative input is prompted. If Force is provided in the cmdlet, but the value is omitted, then its default value is $true.
ReplaceLocations	Optional	System.Management.Automation.SwitchParameter	The ReplaceLocations parameter is used in an LCR configuration when the administrator wants to terminate replication and push the copy's paths into the production storage group and database location attributes. The production database and storage group objects' paths are updated with the locations from the copy. The ReplaceLocations parameter is not valid in a CCR configuration.
WhatIf	Optional	Boolean	The WhatIf parameter instructs the cmdlet to simulate the actions that it would take on the object. By using the WhatIf parameter, the administrator can view what changes would occur without having to apply any of those changes. The default value is $true.

Detailed Description

The Restore-StorageGroupCopy cmdlet is required to enable an Exchange 2007 administrator to activate a CCR or LCR copy to recover from a failure of the active database or storage group. The command is used in both the CCR and LCR configurations. By default, the Restore-StorageGroupCopy cmdlet is used when an administrator terminates replication. This is used in both CCR and LCR configurations.

In an LCR configuration, it is expected that the administrator relocates the data via a file system or volume operations. We recommend this method to maintain conventions between the paths used for the copy and the production databases.

The ReplaceLocations parameter is used in an LCR configuration when the administrator wants to terminate replication and push the copy's paths into the production storage group and database location attributes. The production database and storage group objects' paths are updated with the locations from the copy. This will be a quick operation and allow an immediate mount of the database. If the option is not used, the data from the copy must be made available at the production locations. If this cannot be done via file system rename commands or volume operations, the outage duration will be proportional to the time required to copy the logs and databases.

In a CCR configuration, the copy being activated is on a different node and in the correct location. Thus, it is not necessary to change the location of the logs or database as part of the activation.

You can use the Restore-StorageGroupCopy cmdlet to override the loss restrictions of mounting the storage group on the newly active node. For example, the AutoDatabaseMountDial may be set to Lossless, which means that the database will not mount if even one log file from the last mounted node could not be copied and replayed on the copy. When in this state, you can restore the storage group copy and mount the database.

Note:
In certain circumstances, overriding the loss restrictions of mounting the storage group on the newly active node may require reseeding the previously active node storage group. Reseeding would be required if one or more of the logs in the loss region had been written to the database.

The Restore-StorageGroupCopy cmdlet can accomplish the following goals:

It marks the storage group's databases as mountable.
It provides a report on the data loss that will result from mounting the databases in the storage group.

It checks if all logs created on the source server for the storage group are present in the copy, and if not, it tries to copy them one more time.

Note:
If all the log files are not available, and the Restore-StorageGroupCopy cmdlet fails to successfully copy them from the source location, the resulting databases will experience a data loss. For information on how CCR manages data loss, see Cluster Continuous Replication.

For LCR, it also disables the storage group copy.
For LCR, if the resulting database experiences a loss, content indexing will re-index.

For LCR, this command must be run on the server hosting the storage group.

Note:
For CCR, for the specified copy to become the active copy, it must first be mounted. After being mounted and active, it will become the new source copy for subsequent replication activity.

To run the following code, the account you use must be delegated the following:

Exchange Server Administrator role and local Administrators group for the target server

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

Errors

Error	Description
`Use 'Msg 1: Cluster not available' and change task name.`	The task was unable to connect to the cluster due to a communication issue, or the cluster is not available.
`Use 'Msg 2: Wrong Version' and change task name.`	The server is not an Exchange 2007 server.
`Use 'Msg 3: No Permissions' and change the task name.`	User does not have Exchange Server administrator authority.
`<ServerName> or <StorageGroupName> does not exist.`	The specified server of the storage group does not exist.
`Restore-StorageGroupCopy: Must be run on <ServerName>'s host machine.`	The task must be run on the replication target's computer.
`Restore-StorageGroupCopy: ReplaceLocations can only be used with Local Continuous Replication configurations.`	The specified parameter does not exist, or the specified combination is not valid.
`CCR: No continuous replication copy of '<SGName>' to restore.` `LCR:No continuous replication copy of '<SGName>' to restore.`	This is an unsupported replication configuration. Replication has not been enabled.
`Use 'Msg 10: Comm' and change the task name.`	The ReplaceLocations parameter was specified and the production storage group locations could not be updated with the required paths.
`'<SGName>' is not in a healthy condition; storage group must be viable for a successful mount.`	The specified copy is not in a healthy condition.
`The database is not dismounted. Please dismount it before proceeding.`	The database of the specified storage group is not dismounted.
`Replication for '<SGName>' is not prepared to support a Restore-StorageGroupCopy. Retry your operation after a brief wait.`	Replication is not ready to make the storage group available.
`Replication for '<SGName>' is not prepared to support a Restore-StorageGroupCopy due to error (<ErrorCode>). Retry your operation after a brief wait.`	An internal error occurred. The Restore-StorageGroupCopy command failed to get information on all databases for LCR.
`Replication for '<SGName>' is not prepared to support a Restore-StorageGroupCopy due to a backup in progress. Terminate the backup and retry.`	An internal error occurred because a backup was in progress.
`Replication for '<SGName>' is not prepared to support a Restore-StorageGroupCopy due to error (<ErrorCode>). Retry your operation after a brief wait.`	An internal error occurred: not online.
`Restore-StorageGroupCopy: <SGName> has no database.`	There are no databases in the storage group.
`Restore of <StorageGroupName> was successful. All logs were successfully copied.` `Or` `Restore-StorageGroupCopy: Restore of <StorageGroupName> was successful and production paths were updated. All logs were successfully copied.` `Or` `Restore-StorageGroupCopy: Restore of <StorageGroupName> was successful. All logs were not successfully copied.` `Time of the failure was: <FailureTime>.` `Last log copied was <LogFileName> at <ItsChangeTime>.` `Or` `Restore-StorageGroupCopu: Restore of <StorageGroupName>was successful and production paths were updated. All logs were not successfully copied.` `Time of the failure was: <FailureTime>.` `Last log copied was <LogFileName> at <ItsChangeTime>.`	Success report that details what actions were taken and their results, including the amount of data loss as a result of the restore. The report also indicates whether the paths were updated. The report also states what to do next.
`<SGName> already marked as available for a mount; no action taken.`	The storage group has already been made available for mounting.

Example

The following code example shows how to terminate replication on the storage group named SG1.

	Copy Code
Restore-StorageGroupCopy -Identity:SG1