SALES: 1-800-867-1380

Step 7: Create and customize recovery plans: On-premises to on-premises

Updated: June 20, 2014

After you’ve enabled protection for virtual machines you can configure recovery plans. A recovery plan groups virtual machines together for the purposes of failover and recovery, and it specifies the order in which groups of virtual machines should fail over.

You create and customize recovery plans as follows:

  1. Create a recovery plan—Create a plan and add virtual machines to it.

  2. Customize a recovery plan—You can customize a recovery plan by adding additional virtual machines and groups to it, adding scripts that run automatically, or adding manual actions.

  3. Update an IP address in DNS—You’ll need to do this if you’re allocating IP addresses to replica virtual machines from a static IP address pool. After failover a replica virtual machine won’t have the same address as the primary virtual machine, regardless of whether it’s issued by DHCP or DNS. However, addresses issued by DHCP are updated automatically in DNS, and addresses issued from a static address pool aren’t. You can use the script in this procedure to automate the update of IP address issued by a static pool in DNS.

To create a recovery plan, do the following:

  1. On the Quick Start page, click Create Recovery Plan.

  2. Specify a name for the recovery plan, and the source and target Virtual Machine Manager (VMM) servers. Note that source servers must have virtual machines that are enabled for failover and recovery. If you’re deploying with a single VMM server, the source and target server will be the same.

    Recovery Plan
  3. In Select Virtual Machine, select virtual machines to add to the recovery plan. These virtual machines are added to the recovery plan default group—Group 1. A maximum of 100 virtual machines in a single recovery plan have been tested.

    All of the virtual machines that are displayed have been enabled for protection. The list includes both virtual machines that are enabled for protection and initial replication has completed, and those that are enabled for protection with initial replication pending. Only virtual machines with initial replication completed can fail over as part of a recovery plan. Therefore, verify the initial replication status of virtual machines in the plan before starting recovery plan failover.

    Recovery Plan

After a recovery plan has been created, it appears in the list on the Recovery Plans tab.

After you create a recovery plan, you can customize it as follows:

  • Add new groups—You can add additional groups to the plan. Groups that you add will be named in the order they are added. For example, the first additional group you add after default Group 1 will be Group 2. When a recovery plan runs, virtual machines will fail over according to group order. You can add up to seven groups.

  • Add virtual machines to a group—Only virtual machines that are not currently in the recovery plan can be added. A virtual machine can be added to multiple recovery plans, but it can appear only once in each plan.

  • Prepare scripts for recovery plans—You can optionally add scripts to run before or after a specific group in a recovery plan. When a script is added, a new set of actions for the group is created. For example, a set of pre-steps for Group 1 will be created with the name: Group 1: Pre-steps. All pre-steps will be listed inside this set. Use the Move Up and Move Down command buttons to move the position of the script up or down, and specify at which point in the recovery plan it will run.

  • Add a manual action to the recovery plan—You can optionally add manual actions to run before or after a selected group. Specify a name and a list of instructions for the action. You can specify whether the action should be included in a test failover, planned failover, unplanned failover, or a combination of these. Use the Manual Action command button to specify the point at which the manual action will run. When the recovery plan runs, it will stop at the point that the manual action should be run, and a dialog box will appear that allows you to specify that the manual action was completed. Use the Move Up and Move Down command buttons to move the position of the manual actions up and down, and specify at which point in the recovery plan it should occur.

  • Remove or move virtual machines—You can remove virtual machines from a recovery plan, or move them to a different group.

  • Delete groups from the recovery plan—When a group is deleted, the groups below it are moved up. For example, if you delete Group 2, Group 3 becomes Group 2. You cannot delete the default group—Group 1. Deleting a group also deletes the pre- and post-custom actions steps, if any.

Customize a plan as follows:

  1. On the Recovery Plans tab, click the Recovery Plan you want to customize to open the Customize tab.

    • To add another group to the Recovery Plan, select any item in the Step list and click the Group button.

    • To add more virtual machines to the recovery plan, in the Step list click the name of the group you want to add to and then click the Virtual Machine button.

    • You can add a script or manual action before or after any step in the plan. Click any item in the Step list and then click Script or Manual Action. Specify whether you want to run the script or wait for the manual action before or after the selected item.

Customize recovery plan

You can add automated scripts and manual actions to extend recovery plan orchestration, for example, to create the conditions required for a specific application to run after failover and recovery.

  1. Prepare the library share as follows:

    • Ensure you have at least one library server in your VMM deployment.

    • By default, the library share path for a VMM server is located locally on the VMM server with the folder name MSCVMMLibrary.If your library share path is remote, or if it is local but not shared with MSCVMMLibrary, configure the share as follows. This procedure uses \\libserver2.contoso.com\share\ as an example.

      1. Open the Registry Editor.

      2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\DRAdapter\Registration.

      3. Edit the value ScriptLibraryPath.

      4. Place the value as \\libserver2.contoso.com\share\. Specify the full fully qualified domain name (FQDN).

      5. Provide permissions to the share location.

  2. Write scripts using Windows PowerShell.

  3. Scripts in a recovery plan run in the context of the VMM Service account. Ensure that this account has Read permissions on the remote share on which the script is located, and test the script to run at the VMM service account privilege level.

  4. Ensure that you test the script with a user account that has the same permissions as the VMM Service account, to ensure that stand-alone tested scripts run in the same way that they will in recovery plans.

  5. If there is an exception in the script, the script stops running, and the task shows as failed. Ensure that you use try-catch blocks, so that the exceptions are handled gracefully. If an error does occur, any remaining part of the script will not run. If this occurs when you are running an unplanned failover, the recovery plan will continue. If this occurs when you are running a planned failover, the recovery plan will stop. If this occurs, fix the script, make sure it runs as expected, and then run the recovery plan again.

  6. On the VMM server, set the execution policy to bypass as follows:

    1. Open the 64-bit Windows PowerShell console using elevated privileges.

    2. Type: Set-executionpolicy bypass. For more information about this cmdlet, see Using the Set-ExecutionPolicy Cmdlet.

  7. The Write-Host command doesn’t work in a recovery plan script, and the script will fail. If you want to create output, create a proxy script that in turn runs your main script, and ensure that all output is piped out using the >> command.

  8. The script times out if it does not return within 600 seconds.

  9. If anything is written out to STDERR, the script will be classified as failed. This information will be displayed in the script execution details.

Prepare the script for inclusion in a recovery plan as follows:

  1. Create a new folder in the library share, for example \<VMMServerName>\MSSCVMMLibrary\RPScripts. Place it on the source and target VMM servers.

  2. Create the script—for example, RPScript—and verify it works as expected.

  3. Open the required recovery plan, and add a new custom script.

  4. In Script Location, type the relative path to the share. So, for our example where the share is located at \\<VMMServerName>\MSSCVMMLibrary\RPScripts, specify the path: \RPScripts\RPScript.PS1.

  5. Do a failover of the recovery plan to ensure that the script works as expected.

System Center 2012 - Virtual Machine Manager cmdlets are delivered in a Windows PowerShell module. The VMM Windows PowerShell module is installed when you install the VMM console. The VMM module can be loaded into your script using the following command in the script: Import-Module -Namevirtualmachinemanager. For more information about this command, see Getting Started with Windows PowerShell and VMM.

 

Variable name

Details

$context.RecoveryPlanName

Name of the recovery plan being run

$context.FailoverType

Type of failover. Possible values:

  • Test

  • Planned

  • Unplanned

$context.FailoverDirection

Direction of failover. Possible values:

  • PrimaryToSecondary (failover from the protecting clouds to the clouds being protected)

  • SecondaryToPrimary (failover from the clouds being protected to the protecting clouds)

  • Unplanned

$context.VmIdList

List of virtual machine IDs in the group currently running. These are the comma-separated values of the list of virtual machine VMM GUIDs. These variables aren’t available in the shutdown phase. The following example script lists the virtual machines in a group to which the script is added as a custom action. It iterates each virtual machine in the group when the recovery plan runs in an unplanned failover from the protected cloud to the protecting cloud.

If ($context.FailoverType -eq “Unplanned” )  -and ($context.FailoverDirection -eq “PrimaryToSecondary”))
{
            $VMsInThisGroup = $context.VmIdList –split “,”
            Foreach($vm in $VMsInThisGroup){
               $Get-SCVirtualMachine -VMMServer "VMMServer01.Contoso.com" –ID $vm
               }
}

After replication the replica virtual machine will have an IP address that isn’t the same as the IP address of the primary virtual machine, and DNS updates are required. This happens automatically for DHCP issued addresses. For DNS you can use a couple of scripts to update an IP address. The first sample script retrieves the IP address so that you can specify it in the second sample script which updates the DNS server.

Run this sample script to verify an IP address allocated from a static pool. Note that this script can be used when an IP address is allocated from a static pool, or for VM networks that are configured to use Windows Network Virtualization.

$vm = Get-SCVirtualMachine -Name <VM_NAME>
$na = $vm[0].VirtualNetworkAdapters
$ip = Get-SCIPAddress -GrantToObjectID $na[0].id
$ip.address

Update DNS using the following sample script, specifying the IP address you retrieved using the previous sample script.

Param(
[string]$Zone,
[string]$name,
[string]$IP
)
$Record = Get-DnsServerResourceRecord -ZoneName $zone -Name $name
$newrecord = $record.clone()
$newrecord.RecordData[0].IPv4Address  =  $IP
Set-DnsServerResourceRecord -zonename com -OldInputObject $record -NewInputObject $Newrecord

Go to the Administer and Monitor Azure Site Recovery for information about testing your protection environment, running recovery plans, and monitoring Azure Site Recovery.

See Also

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft