Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
Topic Last Modified: 2007-09-12

Use the Restore-StorageGroupCopy cmdlet in a cluster continuous replication (CCR), local continuous replication (LCR), or standby continuous replication (SCR) environment as part of the activation process for the storage group copy. An administrator must use the Restore-StorageGroupCopy cmdlet prior to performing a Mount-Database operation.

Syntax


`Restore-StorageGroupCopy -Identity <StorageGroupIdParameter> [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-Force <SwitchParameter>] [-ReplaceLocations <SwitchParameter>] [-StandbyMachine <String>] [-WhatIf [<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 use, 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, its default value is $true. When the Restore-StorageGroupCopy cmdlet is run to make an SCR target viable for mounting, the Force parameter must be included when the SCR source is not available.
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 environment.
StandbyMachine	Optional	System.String	The StandbyMachine parameter is used to specify the name of a server that hosts the SCR target being restored. This parameter must be used for restoring an SCR target. When this parameter is not included, the task will apply to the LCR or CCR passive copy.
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 a Microsoft Exchange Server 2007 administrator to mount a passive copy of a database or an SCR target database as part of the recovery from a failure or corruption of the active copy of the database. In an LCR configuration, it is expected that the administrator will relocate the data via a file system or volume operation, such as the use and changing of volume mount points. We recommend this method to maintain naming conventions between the paths used for the passive copy or SCR targets and the active copy of the databases.

The ReplaceLocations parameter is used in an LCR environment when the administrator wants to terminate replication and activate the passive copy of a database by changing the locations for these objects in the Active Directory directory service to point to the paths containing the passive copy of the storage group and database files. This is a quick operation, and after completion, you will be able to mount the database. If this option is not used, the data from the passive copy must be copied or moved to the paths for the active copy of the storage group. 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 database files.

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

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 terminates continuous replication for the storage group and makes the passive copy or SCR target database viable for the Mount-Database cmdlet. Specifically, use the Restore-StorageGroupCopy cmdlet in the following ways:

In a CCR environment, use the cmdlet when the automatic mount support does not mount the database and the administrator must explicitly intervene to mount the database.
In an LCR environment, use the cmdlet to disable LCR and make the passive copy viable for the Mount-Database cmdlet.
In an SCR environment use the cmdlet to disable SCR and make the SCR target copy viable for the Mount-Database cmdlet.

The Restore-StorageGroupCopy cmdlet can accomplish the following goals:

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

It 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 files location. If any log files are missing, the operation will try to copy the missing log files.

Note:
If all of the required log files are not available, and the Restore-StorageGroupCopy cmdlet fails to successfully copy them from the active storage group files location, the database will experience a data loss. For information about how CCR manages data loss, see Cluster Continuous Replication.

For LCR and SCR, it also disables continuous replication.
For LCR, if the database experiences any data loss, the content index will need to be re-created.
For LCR, this command must be run on the server hosting the storage group.

Note:

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

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

To run the following code, the account you use must be delegated the 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 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.`	The 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 cmdlet failed to get information about 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 because the storage group is 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 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 first code example shows how to disable LCR for a storage group named SG1 and activate the passive copy of the storage group to make it viable for a Mount-Database operation.

The second example shows how to activate an SCR target on Server2 for a storage group named SG1 and make it viable for mounting.

	Copy Code
Restore-StorageGroupCopy -Identity:SG1 Restore-StorageGroupCopy -Identity:SG1 -StandbyMachine:Server2