Identify the passive node of the clustered mailbox server by running the following command:

	Copy Code
Get-ClusteredMailboxServerStatus -Identity:<Name>

Verify that the corruption is not the result of an offline log drive, offline database drive, or a volume configuration error.

Important:
If the log volume on the active node is not available at the time of the failover, more data may be lost than necessary.

Move the clustered mailbox server from the active node to the passive node using the Move-ClusteredMailboxServer cmdlet as follows:

	Copy Code
Move-ClusteredMailboxServer -Identity:<Name> -targetmachine:<TargetName> -movecomment:<Comment>

Note:
For more information about the Move-ClusteredMailboxServer cmdlet, see Move-ClusteredMailboxServer.

Important:
If you determine that the logs are not available, you should insert the -ignoredismounted argument as shown in the following sample code:

	Copy Code
Move-ClusteredMailboxServer -Identity:<Name> -targetmachine:<TargetName> -ignoredismounted -movecomment:<Comment>

Note:
If a failure occurs late in the move processing, the transition of ownership of the clustered mailbox server occurs, but any affected databases are left offline.

After the move operation is complete, make sure that all volumes have mounted. If one or more databases did not mount, you must determine the status of the local copy using the Get-StorageGroupCopyStatus cmdlet. You must determine if the source is exposing all available log files prior to running Restore-StorageGroupCopy or whether you are satisfied with the state of the copy.

If logs were not available to make the process lossless for all storage groups, the Restore-StorageGroupCopy cmdlet must be run as shown:

	Copy Code
Restore-StorageGroupCopy -Identity:"mbx01\SG1"

Note:
When the Restore-StorageGroupCopy cmdlet is run, it displays the state of the storage group copy and presents a prompt to complete the restore option. If you want to complete the restore operation, enter Yes.

Important:
If you choose not to complete the restore operation when prompted, you can run the command again at a later time.

Note:
For more information about the Restore-StorageGroupCopy cmdlet, see Restore-StorageGroupCopy.

The database can now be mounted. To mount the database, you can use either the Exchange Management Shell or the Exchange Management Console as detailed in How to Mount a Database in a CCR Environment.

If you selected Yes to complete the restore operation, after the restore is complete, you must manually mount the database in the storage group as described in the topic How to Mount a Database in a CCR Environment. In the absence of further failures, these steps will activate the copy on the passive node.

Important:
After the copy is activated, the corrupted copy must be restored to a condition where it can be a replication target. This task may involve repairing the hardware problem that caused the corruption or failure.