Deploy Hyper-V Replica

 

Applies To: Windows Server 2012 R2, Windows Server 2012

This article walks you through the deployment steps for Hyper-V Replica.

• Before you start

• Step 1: Set up the Hyper-V server

• Step 2: Set up replication

• Step 3: Test the deployment

• Step 4: Run a planned failover

• Step 5: Respond to an unplanned failover

• Step 6: Set up extended replica

Before you start

Check requirements:

1. Will both the primary and Replica servers be behind the same firewall? Because the Replica site is likely remote from the primary site, you should configure your firewall to allow replication data through. If the primary and Replica servers will be separated by a firewall, add Step 1.3 to your to-do list.

2. Will either the primary or Replica server be part of a failover cluster? If so, Replica needs a NetBIOS name and IP address to use as a connection point to the cluster. To enable this, install Hyper-V on each node of the cluster and configure a Hyper-V Replica Broker role for the cluster. If a failover cluster is involved in replication, add Step 1.4 to your to-do list.

3. Does the replication data sent between the primary and Replica servers need to be encrypted? To provide encrypted replication data transfer, Replica uses certificate-based authentication, so you must have or create an appropriate security certificate. For example, in any remote office or other cross-premises scenario, the data should probably be encrypted for security. However, if both the primary and Replica servers are physically co-located and are behind the same firewall, the built-in Kerberos authentication may be adequate.

   Note

   Kerberos authentication is only available when the primary and Replica servers are members of the same domain or in mutually trusted domains. Other scenarios require certificate-based authentication.

   If the transmitted replication data must be encrypted, add Step 1.5 to your to-do list.

4. Which VHDs need to be replicated? VHDs that contain data that is rapidly changing and not used by the Replica server after failover, such as page file disks, should be excluded from replication to conserve network bandwidth. Make a note of which VHDs can be excluded from replication.

5. How many recovery points do you need? You can configure Replica to store only the latest received replication data; the data on the Replica server is updated according to the replication frequency you configure. You can also configure Replica to maintain an additional one or more recovery points, which are created once approximately every hour. Having additional recovery points also allows you to recover virtual machine operations to an earlier point in time when you perform a failover. A maximum of 15 (24 in Windows Server 2012 R2) such recovery points is possible. Make a note of the number of recovery points you need.

6. Do you need applications to remain consistent? The standard replication configuration maintains consistency in the state of the operating system of the replicated virtual machines after a failover, but not the state of applications that may be running in the virtual machine. To preserve the state of applications, you can choose to have Replica create additional application-consistent recovery points that use VSS on a set schedule. Make a note whether you need application-consistent recovery points.

7. Decide on the initial replication method. To start replicating data, Replica needs to transfer the current state of the virtual machines. This initial state can be transmitted directly over the existing network, either immediately or at a later time that you configure. You can also use a pre-existing restored virtual machine on the Replica server (for example, if you have restored an earlier backup of the virtual machine on the Replica server) as the initial copy. Or, you can save network bandwidth by copying the initial copy to external media and then physically delivering the media to the Replica site. Make a note of the initial replication method you plan to use.

   Note

   If you plan to use a pre-existing virtual machine restored from backup as the source for the initial replication, delete all previous snapshots associated with the virtual machine before you enable replication and start the initial replication.

8. (For Windows Server 2012 R2) Will you use extended replication? In extended replication, your Replica server forwards changes that occur on the primary virtual machines to a third server (the extended Replica server). After a planned or unplanned failover from the primary server to the Replica server, the extended Replica server provides further business continuity protection. Once you have completed Steps 1 through 5 to enable, configure, and test replication between the primary and Replica servers, see Step 6 for information about configuring and working with extended replication.

9. Do you want to plan for capacity? If so download the Capacity Planner for Hyper-V Replica from https://www.microsoft.com/download/details.aspx?id=39057.

Step 1: Set up the Hyper-V server

Hyper-V Replica is a feature of Hyper-V, so you must enable the Hyper-V server role if you aren’t already using it. Replica also requires virtual machines, so if you haven’t already done so, you need to create one or more. To enable the Hyper-V server role and create virtual machines, see Install Hyper-V and create a virtual machine.

Set up the firewall

Hyper-V Replica already includes firewall rules that will allow the replication data to pass through, but you do have to enable the appropriate exceptions. Follow the steps below depending on whether you plan to use Kerberos or certificate-based authentication on standalone (non-clustered) servers. If your servers are part of a failover cluster, run the Windows PowerShell cmdlets that follow the procedures on any node in the cluster to enable the firewall rules on all nodes in the cluster. These instructions only apply to Windows Firewall. If you are using a non-Microsoft firewall, different steps may be required.

1. Open Windows Firewall with Advance Security and click Inbound Rules.

2. To enable Kerberos authentication right-click Hyper-V Replica HTTP Listener (TCP-In) >Enable Rule.

3. To enable certificate-based authentication right-click Hyper-V Replica HTTPS Listener (TCP-In) > Enable Rule.

4. For servers that are part of a failover cluster, run this Windows PowerShell cmdlet with admin privileges on any node in the cluster for Kerberos authentication The cmdlet must be run by a user with administrative privileges.

   get-clusternode | ForEach-Object  {Invoke-command -computername $_.name -scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTP Listener (TCP-In)"}}
   

5. For servers that are part of a failover cluster, run this Windows PowerShell cmdlet with admin privileges on any node in the cluster for certificate authentication The cmdlet must be run by a user with administrative privileges.

   get-clusternode | ForEach-Object  {Invoke-command -computername $_.name -scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTPS Listener (TCP-In)"}}
   

Set up a cluster

If you plan to use a failover cluster with Hyper-V Replica and haven’t already set up the cluster, see https://go.microsoft.com/fwlink/?LinkId=253006

Each node of the failover cluster that is involved in Replica must have the Hyper-V server role installed. If you haven’t already done so, refer to Step 1.2 in this topic and install the Hyper-V role on each cluster node.

Finally, configure the Hyper-V Replica Broker for the cluster with the following steps.

1. In Server Manager, open Failover Cluster Manager.

2. In the left pane, connect to the cluster, and while the cluster name is highlighted, click Configure Role in the Actions pane. The High Availability wizard opens

3. In the Select Role screen, select Hyper-V Replica Broker.

4. Complete the wizard, providing a NetBIOS name and IP address to be used as the connection point to the cluster (called a “client access point”). The Hyper-V Replica Broker is configured, resulting in a client access point name. Make a note of the client access point name for configuring Replica later on.

5. Verify that the Hyper-V Replica Broker role comes online successfully and can fail over between all nodes of the cluster. To do this, right-click the role, point to Move, and then click Select Node. Then, select a node, and then click OK.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

This example sequence of cmdlets will create a Hyper-V Replica Broker names “HVR-Broker” that uses the static IP address 192.168.1.5. All steps must be completed by a user with administrative privileges.

$BrokerName = “HVR-Broker”

Add-ClusterServerRole -Name $BrokerName –StaticAddress 192.168.1.5

Add-ClusterResource -Name “Virtual Machine Replication Broker” -Type "Virtual Machine Replication Broker" -Group $BrokerName

Add-ClusterResourceDependency “Virtual Machine Replication Broker” $BrokerName

Start-ClusterGroup $BrokerName

Set up a certificate

If you configure Replica to use Kerberos authentication, the data transmitted from the primary to the Replica server is not encrypted. For the data to be encrypted, you should use certificate-based authentication. You can either provide an existing X.509v3 certificate or create a self-signed certificate.

If you are already using a certificate server or public key infrastructure (PKI) system, you can use an existing certificate, provided that it meets the following criteria:

• The certificate must not be expired or revoked.

• The certificate must include both client and server authentication extensions for enhanced key usage (EKU) and an associated private key.

• The certificate must terminate at a valid root certificate in the Trusted Root Certification Authorities store on the Replica server.

• If the virtual machine is hosted by a standalone server, the subject common name (CN) must be equal to (or the subject alternative name—DNS name) should contain the FQDN of the host. If the virtual machine is hosted by a failover cluster, the subject common name (CN) must be equal to (or the subject alternative name—DNS name) should contain the FQDN of the Hyper-V Replica Broker.

Learn more about using certificates with Hyper-V Replica.

Step 2: Set up replication

Set up the replica server

Although Hyper-V Replica will work if you configure only the Replica server (to receive replication from primary servers), it is a good practice to also configure the primary servers to receive replication. This allows you to reverse the replication direction after a failover, which provides replication protection for the newly active Replica server.

You configure a server to receive replication with Hyper-V Manager, which is available locally on any server that has Hyper-V installed or installable separately as part of the Remote Server Administration Tools (RSAT). Servers that are part of failover clusters use Failover Cluster Manager to also configure Hyper-V replication. With any of these tools, you can connect to the Replica server remotely to enable replication for it.

1. In Hyper-V Manager, click Hyper-V Settings in the Actions pane.

2. In the Hyper-V Settings dialog, click Replication Configuration.

3. In the Details pane, select Enable this computer as a Replica server.

4. In the Authentication and ports section, select the appropriate authentication method. For either authentication method, specify the port to be used (the default ports are 80 for Kerberos over HTTP and 443 for certificate-based authentication over HTTPS).

5. If you are using certificate-based authentication, click Select Certificate and provide the request certificate information.

6. In the Authorization and storage section, use the radio buttons to specify whether to allow any authenticated (primary) server to send replication data to this Replica server or to limit acceptance to data from specific primary servers. You can use wildcard characters to limit acceptance to servers from a particular domain without having to specify them all individually (for example, *.contoso.com). If you specify individual primary servers, you can designate a separate storage location for Replica data for each one, as well grouping them with the Trust Group tag.

7. Click OK or Apply when you are finished.

Set-VMReplicationServer -ReplicationEnabled $true -AllowedAuthenticationType Certificate -ReplicationAllowedFromAnyServer $true -CertificateThumbprint "<CertThumbprint>” -DefaultStorageLocation “<Storage Location>” -CertificateAuthenticationPort <Listenerport>

Verify that the https listener is running with netsh http show servicestate.

Ensure that Windows Firewall is allowing traffic through the port with the following cmdlet:

Enable-Netfirewallrule -displayname "Hyper-V Replica HTTPS Listener (TCP-In)"

If the Replica server is part of a failover cluster, ensure that Windows Firewall is allowing traffic with this cmdlet instead:

Get-ClusterNode | ForEach-Object  {Invoke-command -computername $_.name -scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTPS Listener (TCP-In)"}}

Set up a Replica server in a cluster

Having configured the Hyper-V Replica Broker you enable replication directly from Failover Cluster Manager. If you haven’t configured the Hyper-V Replica Broker, follow the directions in Step 1.4. When you complete these steps, Replica is configured for all nodes of the cluster.

Note

If you use certificate-based authentication, ensure that each cluster node and the Hyper-V Replica Broker’s client access point all have appropriate machine certificates.

Note

If you use network address translation (NAT), ensure that the inbound and outbound ports are configured to use the same port number. Replica only listens on one port.

1. In Server Manager, open Failover Cluster Manager.

2. In the left pane, connect to the cluster, and while the cluster name is highlighted, click Roles in the Navigate category of the Details pane

3. Right-click the role and choose Replication Settings.

4. In the Details pane, select Enable this cluster as a Replica server.

5. In the Authentication and ports section, select the authentication method. For either authentication method, specify the port to be used (the default ports are 80 for Kerberos over HTTP and 443 for certificate-based authentication over HTTPS).

6. If you are using certificate-based authentication, click Select Certificate and provide the request certificate information.

7. In the Authorization and storage section, use the radio buttons to specify whether to allow any authenticated (primary) server to send replication data to this Replica server or to limit acceptance to data from specific primary servers. You can use wildcard characters to limit acceptance to servers from a particular domain without having to specify them all individually (for example, *.contoso.com). If you specify individual primary servers, you can designate a separate storage location for Replica data for each one, as well grouping them with the Trust Group tag.

Enable virtual machine replication

Once the hosting server is configured for Replica, you can enable replication for each virtual machine that you want to be replicated. The details of replication are configured on a per-virtual-machine basis, so each one can have slightly different settings.

1. In the Details pane of Hyper-V Manager, select a virtual machine by clicking it.

2. Right-click the selected virtual machine and point to Enable Replication. The Enable Replication wizard opens.

3. On the Specify Replica Server page, in the Replica Server box, enter either the NetBIOS or fully qualified international domain name (FQIDN) of the Replica server that you configured in Step 2.1. If the Replica server is part of a failover cluster, enter the name of the Hyper-V Replica Broker that you configured in Step 1.4. Click Next.

4. On the Specify Connection Parameters page, the authentication and port settings you configured for the Replica server in Step 2.1 will automatically be populated, provided that Remote WMI is enabled. If it is not enabled, you will have to provide the values. Click Next.

5. On the Choose Replication VHDs page, clear the checkboxes for any VHDs that you want to exclude from replication, per your decision from 1.1. Make basic planning decisions, and then click Next.

6. On the Configure Recovery History page, select the number and types of recovery points to be created on the Replica server, per your decisions from 1.1. Make basic planning decisions, and then click Next.

   Note

   In Windows Server 2012 R2, this page of the wizard has been replaced by two pages: Configure Replication Frequency and Configure Additional Recovery Points.

7. On the Choose Initial Replication page, select the initial replication method to use per your decisions from 1.1. Make basic planning decisions. If you choose to have initial replication over the network occur at a later time, configure that here as well, and then click Next.

8. On the Completing the Enable Replication Relationship Wizard page, review the information in the Summary and then click Finish.

9. A dialog box appears indicating that replication was successfully enabled. In this dialog, click the Settings button and provide settings to configure the network that the virtual machine will connect to on the Replica server. The Replica virtual machine does not automatically connect to any network on the Replica server (after a failover) by default, so these settings are important. You can configure the network settings so that the virtual machine will connect to a different network after a failover to the Replica server than it used when it was on the primary server.

   Note

   The configuration data for a virtual machine is replicated only once, at the time of initial replication. After that point, you manage the primary and Replica virtual machines independently.

10. A Replica virtual machine is created on the Replica server. If you elected to send the initial copy over the network, the transmission begins either immediately or at the time you configured. If you elected to use external media for the initial copy, the necessary files are copied to a local location. Copy the files to the media you will use to transfer the initial copy and then send the media to the Replica site.

11. Using Hyper-V Manager or Windows PowerShell on the Replica server, perform initial replication for each virtual machine, using the files you sent to the Replica site.

This example sequence of cmdlets will enable and start replication for a virtual machine (“CRMVM”) that is hosted by a Replica server named “Recovery1.contoso.com”. In this example, Kerberos authentication is configured. All steps must be completed by a user with administrative privileges.

Import-Module Hyper-V

$ReplicaServer = “Recovery1.contoso.com”
$RecoveryPort = 8080
$PrimaryVM1 = “CRMVM”
$PrimaryServer = “Primary1.contoso.com”

Enable-VMReplication -VMName $PrimaryVM1 -ReplicaServerName $ReplicaServer -ReplicaServerPort $RecoveryPort -AuthenticationType Integrated -CompressionEnabled $true -RecoveryHistory 0

Start-VMInitialReplication –VMName $PrimaryVM1

Set up the primary server to receive replication

Hyper-V Replica normally sends changes that occur on the primary virtual machines to the Replica virtual machines, but after a failover, it can send the data the other direction. By doing this, when you fail over operations from the current primary server to the Replica server, the replication direction can be reversed back to the primary server from the Replica server once the primary has come back online. In this way, you provide replication protection for the Replica server which is now servicing the virtual machine load.

To do this, simply repeat the instructions to configure the Replica server on one or more of the primary servers, using the same settings you used for the Replica server.

Step 3: Test the deployment

To ensure that the replicated virtual machines (and applications running within them) will function properly on the Replica server just as they do on the primary server, you can conduct a test failover at any time. When you conduct a test failover, a temporary virtual machine is created on the Replica server. You can test any applications in that test virtual machine without interrupting the ongoing replication. When you conclude the test, the temporary virtual machine is deleted. Note that:

• After failover the test virtual machine won’t be connected to any network. If you need to conduct tests that require a network, you can modify the settings of this test virtual machine in the same way you would modify settings of any ordinary virtual machine.

• For a test failover to succeed, you must have enabled replication for at least one virtual machine and have completed the initial replication by any of the available methods. To verify failover with a recovery point other than the most recent one, replication must have been running long enough for at least one additional recovery point to have been created.

1. Access the Replica server, and in Hyper-V Manager, right-click the virtual machine you want to test failover for, point to Replication…, and then point to Test Failover….

2. Choose a recovery point to use. This creates and starts a virtual machine with the name “<virtual machine name>-Test” (for example, “CRMVM-Test”).

3. Conduct your tests on the test virtual machine. For example, you might verify that the virtual machine starts, pauses, and stops, and that any applications in the virtual machine run properly.

   After you have concluded your testing, discard the test virtual machine by choosing Stop Test Failover under the Replication option.

   Important

   Operations that move the test virtual machine, such as quick migration, are not supported and could result in the test virtual machine becoming orphaned.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

This example sequence of cmdlets will conduct a test failover of a virtual machine named “CRMVM”.

$ReplicaVM1 = “CRMVM”

$TestReplicaVM1 = Start-VMFailover -AsTest -VMName $ReplicaVM1

Start-VM $TestReplicaVM1

To stop the test failover operation and discard the test virtual machine:

Stop-VMFailover –VMName $ReplicaVM1

Step 4: Run a planned failover

A planned failover is an operation in which you move operations on any primary virtual machine to its corresponding Replica virtual machine. For example, you might perform a planned failover in order to perform maintenance or upgrades on a primary virtual machine or when you have advance notice of an impending event that might require taking the primary server offline. You might also perform a planned failover to demonstrate and confirm readiness for a disaster recovery scenario.

In a planned failover, any un-replicated changes are first copied over to the Replica virtual machine, so no loss of data occurs. After the planned failover, the Replica virtual machine takes over the workload; to provide similar protection for the virtual machine that is now servicing the workload, you configure “reverse replication” to send changes back to the primary virtual machine (once that comes back online).

1. Start Hyper-V Manager on the primary server and choose a virtual machine to fail over. Turn off the virtual machine that you want to fail over.

2. Right-click the virtual machine, point to Replication, and then point to Planned Failover.

3. Click Fail Over to actually transfer operations to the virtual machine on the Replica server. Failover will not occur if the prerequisites have not been met.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

This sequence of cmdlets will conduct a planned failover of the virtual machine “CRMVM,” provided you have already configured the primary server (in addition to the Replica server) to accept replication traffic using the procedure in Step 2. Run these cmdlets on the primary server:

$PrimaryVM1 = “CRMVM”
Stop-VM $PrimaryVM1
Start-VMFailover -VMName $PrimaryVM1 –prepare

Then run these cmdlets on the Replica server:

$ReplicaVM1 = “CRMVM”
Start-VMFailover -VMName $ReplicaVM1

Once the primary virtual machine has come online, you can optionally run these commands to reverse the replication direction:

Start-VM $ReplicaVM1
Set-VMReplication -reverse -VMName $ReplicaVM1

Step 5: Respond to an unplanned failover

After an unplanned failover you need to get your virtual machines back online. There is the possibility of data loss, since there was no opportunity to transmit changes on the primary virtual machines that might not have been replicated yet. Note that unlike failover clustering, Hyper-V Replica doesn’t automatically transfer to the virtual machines on the Replica server if the primary server goes offline.

Start the replica virtual machines

1. Open Hyper-V Manager and connect to the Replica server.

2. Right-click the name of the virtual machine you want to use, point to Replication, and then point to Failover….

3. In the dialog that opens, choose the recovery snapshot you want the virtual machine to recover to, and then click Failover….. The Replication Status will change to Failed over – Waiting completion and the virtual machine will start using the network parameters you previously configured for it. If you have not previously configured the network parameters or if you want to use different parameters at this point, you can use the Windows PowerShell cmdlet below to do this.

4. Use the Complete-VMFailover Windows PowerShell cmdlet below to complete failover.

5. Repeat these steps for each virtual machine you want to bring back online.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

This sample script will complete an unplanned failover:

$Primary = "host1"
$Replica = "host2"
$VMName = "vm01"

Start-VMFailover -VMName $VMName -ComputerName $Replica

Complete-VMFailover -VMName $VMName -ComputerName $Replica

Start-VM -VMName $VMName -ComputerName $Replica

# Assuming that Primary server is recovered.

Set-VMReplication -VMName $VMName -AsReplica -ComputerName $Primary

Set-VMReplication -VMName $VMName -Reverse -ReplicaServerName $Primary -ComputerName $Replica

Start-VMInitialReplication -VMName $VMName -ComputerName $Replica

To provide new or different network parameters for the Replica virtual machine to use when it comes online, use the following example cmdlet, substituting appropriate values:

$NetworkAdapter = Get-VMNetworkAdapter -VMName $Replica -Name $VMNetworkAdapterName
$NetworkAdapter | Set-VMNetworkAdapterFailoverConfiguration -IPV4Address 172.20.31.100 -IPV4SubnetMask 255.255.255.0 -IPV4DefaultGateway 172.20.31.1 -IPV4PreferredDNSServer 172.20.31.101 -IPV4AlternateDNSServer 172.20.31.102

Start reverse replication

Once the Replica virtual machine(s) are back online running on the Replica server, they are unprotected against further failure. You can provide this protection by enabling reverse replication back to the primary server once the server comes back online.

Note

The Replica virtual machines must be replicated back to their original primary server. Do not attempt to configure replication from the Replica server to a third server.

1. Open Hyper-V Manager and connect to the Replica server.

2. Right-click the name of the virtual machine you want to reverse replicate, point to Replication, and then point to Reverse replication…. The Reverse Replication wizard opens.

3. Complete the Reverse Replication wizard. You will find the requested information to be very similar if not identical to the information you provided in the Enable Replication wizard (see 2.3 Enable replication for virtual machines.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

To reverse replication of the virtual machine, use the following example cmdlet:

Set-VMReplication -reverse -VMName $ReplicaVM2

Step 6: Set up extended replica

In extended replication (available in Windows Server 2012 R2), your Replica server forwards changes that occur on the primary virtual machines to a third server (the extended Replica server). After a planned or unplanned failover from the primary server to the Replica server, the extended Replica server provides further business continuity protection. As with ordinary replication, you configure extended replication by using Hyper-V Manager, Windows PowerShell (using the –Extended option), or WMI.

Having the third server allows for new options for planned, unplanned, and test failovers, as well as different ways of moving the virtualized workload among the three servers. Once extended replication is established, you can do essentially all of the same things with the Replica and extended Replica servers just as you would with the primary server and the Replica server.

Because the roles of primary, Replica, and extended Replica can be exchanged among the various servers, to keep the explanations as clear as possible, in this topic we will assume a starting configuration of three servers: Server A, Server B, and Server C. This topic assumes that you have already configured standard replication along the lines of Steps 1-5 of this topic collection, where Server A is the primary server and Server B is the Replica server. The extended Replica server created in these steps will initially be Server C.

Enable extended replication

1. In Hyper-V Manager, connect to the Replica server (in the initial state of this example, Server B).

2. Right-click the virtual machine and point to Extend Replication. The Extend Replication wizard opens.

3. On the Specify Replica Server page, enter the name of the server you intend to use as the extended Replica (in this example, Server C; not the current Replica server, Server B).

4. Complete the wizard, providing values as you did when you originally configure replication between the primary and the Replica server. You can use different values for replication frequency, authentication method, and initial replication method than those you used for the basic replication configuration.

   Note

   There are certain differences in the Replica-extended Replica relationship as compared to the primary-Replica relationship: You must use a longer replication frequency for extended replication than was configured for the primary-Replica relationship. Only frequencies of 5 or 15 minutes are supported for extended replication. If you have configured application-consistent snapshots in the primary-Replica relationship, these snapshots are forwarded to the extended Replica. However, you cannot set a different frequency for the snapshots or enable application-consistent snapshots for extended replication independent of the primary-Replica relationship. The collection of VHDs used in the primary-Replica relationship cannot be different in extended replication.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

You extend replication with the same cmdlet used to enable ordinary replication. However, you run it from the current Replica server and use –ReplicaServerName to define the extended Replica server.

Enable-VMReplication –VMName <vmname> -ReplicaServerName <extended_server_name> -ReplicaServerPort <Auth_port> -AuthenticationType <Certificate/Kerberos> -ReplicationFrequencySec <300/900> [--other optional parameters if needed--]

To monitor the status and statistics of extended replication, start Hyper-V Manager, right-click the Replica virtual machine, and then point to View Replication Health. To see the data for the extended replica, you must view the health report from the Replica server. From the primary server, you can only access the report for the primary replication relationship.

With Windows PowerShell, you can use the Measure-VMReplication cmdlet with the extra parameter –ReplicationRelationshipType. If you use the parameter without specifying a value, statistics for both the primary and extended replication are returned. To specify the extended replication relationship, use the parameter with the value Extended; for the primary relationship, use the value Simple.

Examples:

To view the statistics of the extended replication relationship from the Replica server:

Measure-VMReplication –VMName <name> -ReplicationRelationshipType Extended | select *

To view the statistics of the primary replication relationship from the Replica server:

Measure-VMReplication –VMName <name> -ReplicationRelationshipType Simple | select *

To view replication relationship statistics for both the primary and extended replication relationships:

Measure-VMReplication –VMName <name> | select *

Pause and resume extended replication

Pausing and resuming extended replication works the same way as for primary replication. You can control primary and extended replication separately. If you access the Replica virtual machine with Hyper-V Manager, you will find separate options for pausing or resuming either the primary replication or the extended replication. If you access the extended Replica virtual machine, you will find pause and resume options for only the extended replication.

With Windows PowerShell, you can use the Suspend-VMReplication and Resume-VMReplication cmdlets with the extra parameter –ReplicationRelationshipType. To specify pausing or resuming the extended replication relationship, use the parameter with the value Extended; for the primary relationship, use the value Simple (which is the default if you don’t specify the replication relationship type.

Examples:

To pause or resume extended replication from the Replica server:

Suspend-VMReplication/ Resume-VMReplication –VMName <name> -ReplicationRelationshipType Extended

To pause or resume primary replication from the Replica server:

Suspend-VMReplication/ Resume-VMReplication –VMName <name> -ReplicationRelationshipType Simple

To pause or resume primary replication (if performed on the primary server) or extended replication (if performed on the extended Replica server):

Suspend-VMReplication/ Resume-VMReplication –VMName <name>

Resynchronize

To recover from certain errors, it might be necessary to resynchronize replication. If an error has occurred, you can resynchronize either primary or extended Replication with the following commands.

Examples:

To resynchronize replication from the primary server in the event of an error:

Suspend-VMReplication –VMName <name>//puts the virtual machine state to suspended
Resume-VMReplication –VMName <name> -ReplicationRelationshipType Extended -Resync

To resynchronize extended replication from the Replica server:

Suspend-VMReplication –VMName <name> -ReplicationRelationshipType Extended //puts the extended virtual machine state to suspended
Resume-VMReplication –VMName <name> -ReplicationRelationshipType Extended -Resync

In some circumstances, it is possible that replication could be in the “Resynchronization Required” state. If this occurs, you can use Hyper-V Manager to perform resynchronization immediately or schedule it for a later time. If the primary replication relationship is resynchronizing, extended replication will move into the Resynchronization Required state. When primary resynchronization is complete, extended resynchronization commences automatically.

You can also start resynchronization with Windows PowerShell.

Examples:

To resynchronize replication from the primary server when in Resynchronization Required state:

Resume-VMReplication –VMName <name> -Resync

To resynchronize extended replication from the Replica server when in Resynchronization Required state:

Resume-VMReplication –VMName <name> -ReplicationRelationshipType Extended -Resync

Test failover

Test failovers from the Replica server to the extended Replica server work just as they do in a basic replication relationship. During the test failover, the relationship between the Replica server and the extended Replica server remains intact. During the test, you can also pause or resume operations between Replica and extended Replica.

Planned failover

Having an extended Replica server affords more options when you perform a planned failover. In a basic replication configuration (without an extended Replica server), once you perform a planned failover from Server A to Server B, you typically reverse replication from B to A to provide replication protection for B, which is now hosting the active virtualized workload.

With an extended Replica server, once you have completed a planned failover from A to B, B acts as the primary server, but you can either use C as its Replica server or reverse replication back to A.

Fail over to Server B and use Server C as the new Replica

1. Use Hyper-V Manager or Windows PowerShell to shut down the virtual machine on the primary server (in this example, Server A).

2. Start a planned failover from Server A to Server B, as described in Step 4: Perform a Planned Failover.

3. In the Planned Failover dialog box, clear Reverse the replication direction after failover checkbox and select the Start the Replica virtual machine after failover checkbox.

4. Click Fail Over.

5. After failover is complete, in Hyper-V Manager, right-click the virtual machine that is now on the Replica server (Server B) and point to Resume Extended Replication. This removes the replication relationship between Servers B and A; as result, B is now the primary server, and C is its Replica server.

To do this with Windows PowerShell, run Start-VMFailover –VMName <name> -Prepare on the primary server (Server A), then run Start-VMFailover –VMName <name> on Server B. The virtual machine is now failed over to Server B, which is the new primary server.

To use Server C as the new Replica server to protect Server B, run the following cmdlets on Server B:

Complete-VMFailover –VMName <name> // to commit the failover
Start-VMFailover -Prepare
Resume-VMReplication –VMName <name> -Continue // to resume extended replication

Fail over to Server B and use Server A as the new Replica

1. Use Hyper-V Manager or Windows PowerShell to shut down the virtual machine on the primary server (in this example, Server A).

2. Start a planned failover from Server A to Server B, as described in Step 4: Perform a Planned Failover.

3. In the Planned Failover dialog box, select the Reverse the replication direction after failover checkbox and select the Start the Replica virtual machine after failover checkbox.

4. After failover is complete, in Hyper-V Manager, right-click the virtual machine that is now on the Replica server (Server B) and point to Reverse Replication. This removes the extended replication relationship between Servers B and C; as result, B is now the primary server, and A is its Replica server.

To do this with Windows PowerShell, run Start-VMFailover –VMName <name> -Prepare on the primary server (Server A), then run Start-VMFailover –VMName <name> on Server B. The virtual machine is now failed over to Server B, which is the new primary server.

To use Server A as the new Replica server to protect Server B, run the following cmdlets on Server B:

Remove-VMReplication –VMName <name> -ReplicationRelationshipType Extended
Set-VMReplication –VMName <name> -Reverse

In some circumstances, you might want to take both the primary and Replica servers (Servers A and B) offline, and have the extended Replica (Server C) maintain the virtualized workload.

Fail over completely to the extended Replica (Server C)

1. Shut down the virtual machine on the primary server (Server A), and then complete a planned failover to the Replica server (Server B) (see Step 4: Perform a Planned Failover).

2. Once failover to the Replica server is complete, complete a planned failover to the extended Replica server (Server C).

To do this with Windows PowerShell, run Start-VMFailover –VMName <name> -Prepare on the primary server (Server A), then run Start-VMFailover –VMName <name> and Complete-VMFailover –VMName <name>on Server B. The virtual machine is now failed over to Server B, which is the new primary server.

Fail over from Server B to Server C by running Start-VMFailover –VMName <name> -Prepare on Server B.

Finally, complete the failover to Server C by running the following on Server C:

Start-VMFailover –VMName <name>
Complete-VMFailover –VMName <name>

Unplanned failover

Unplanned failover from primary to Replica

If the primary server (Server A) goes down, you can complete an unplanned failover to the Replica server (Server B) with Hyper-V Manager by right-clicking the virtual machine on Server B and pointing to Failover. In the dialog that opens, select a recovery point and click Fail Over.

To do this with Windows PowerShell, run Start-VMFailover –VMName <name> -VMRecoverySnapshot <VMSnapshot>.

Once failover to Server B is complete, you can choose to continue replication to Server C (to provide protection to Server B), or if Server A comes back online, reverse replication from Server B to Server A.

To continue replication to Server C, on Server B, right-click the virtual machine in Hyper-V Manager and point to Resume Extended Replication.

Note

This action removes replication between Servers A and B. Server B becomes the primary server and Server C becomes the Replica server. Replication from Server B to Server C goes into the resynchronization state and replication continues automatically once resynchronization is complete. The virtual machine on Server A becomes orphaned.

To do this with Windows PowerShell, run the following cmdlets on Server B:

Complete-VMFailover –VMName <name> // to commit the failover
Resume-VMReplication –VMName <name> -Continue // to resume extended replication

At a later point, when all three servers are back online, you can restore each server to its original function by following these steps:

1. Remove replication from all three servers with Hyper-V Manager or Windows PowerShell.

2. Run the Enable Replication wizard on Server B, choosing Use an existing virtual machine on the Replica server as the initial copy.

3. Perform a planned failover from Server B to Server A.

4. Extend replication from Server B to Server C.

To reverse replication to Server A after the unplanned failover, on Server B, right-click the virtual machine in Hyper-V Manager and point to Reverse Replication. The extended replication relationship is removed; Server B becomes the primary server and Server A becomes the Replica server. The virtual machine on Server C is orphaned.

To do this with Windows PowerShell, on either Server A or Server B, run Set-VMReplication –VMName <name> -AsReplica. Then on Server B, run:

Set-VMReplication –VMName <name> -Reverse -ReplicaServerName <new_recovery_server_name> -ReplicaServerPort <Auth_port> -AuthenticationType <Certificate/Kerberos> -ReplicationFrequencySec <30/300/900> [--other optional parameters if needed--]

At a later point, when all three servers are back online, you can restore each server to its original function by following these steps:

1. Remove replication from Server C with Hyper-V Manager or Windows PowerShell.

2. Perform a planned failover from Server B to Server A; choose the Reverse Replication option in the wizard. At this point, Server A is the primary server and Server B is the Replica server.

3. On Server B, run the Extend Replication wizard, choosing to Use an existing virtual machine on the Replica server as the initial copy.

Unplanned failover when both primary and Replica servers go offline

If a failover has shifted the virtualized workload to the extended Replica server (Server C in these examples), it is now functioning as the primary server. If both Server A and Server B go down, complete the unplanned failover to Server C with Hyper-V Manager by right-clicking the virtual machine on Server C and pointing to Failover. In the dialog that opens, select a recovery point and click Fail Over.

Once failover is complete, you have three options for putting the other servers back into service:

Repurpose the Replica server (Server B, which previously replicated Server A) to be a Replica server replicating Server C:

In Hyper-V Manager, access Server C, right-click the virtual machine, and then point to Reverse Replication.

If a primary replication relationship is detected on Server B, you will receive an error. If this occurs, remove the replication relationship on B, and then repeat the reverse replication step from Server C.

When reverse replication from Server C is complete, Server C will be the primary server, Server B is the Replica server, and the virtual machine on Server A is orphaned.

To restore the servers to their original roles

1. Perform a planned failover of the virtual machine from Server C to Server B.

2. Remove replication on all three servers.

3. Enable replication from Server B to Server A, choosing to Use an existing virtual machine on the Replica server as the initial copy

4. Perform a planned failover from Server B to Server A, selecting the check box for enabling reverse replication.

5. On Server B, run the Extend Replication wizard, to extend replication to Server C.

Repurpose the original primary server (Server A) to be a Replica server replicating Server C:

With Hyper-V Monitor, access Server A, right-click the virtual machine, and point to Remove Replication.

On Server B, run the Enable Replication wizard to set up replication to Server A, choosing to Use an existing virtual machine on the Replica server as the initial copy. If an orphaned virtual machine is still present on Server A, the wizard can use it as a data source to complete the initial replication.

To restore the servers to their original roles

1. Perform a planned failover of the virtual machine from Server C to Server A.

2. Remove replication on all three servers.

3. Enable replication from Server A to Server B, choosing to Use an existing virtual machine on the Replica server as the initial copy

4. Perform a planned failover from Server A to Server B, selecting the check box for enabling reverse replication.

5. On Server B, run the Extend Replication wizard, to extend replication to Server C.

Use a new server (Server D) as the Replica server

Prepare a new server for Hyper-V and replication as described in Step 2: Enable Replication.

Access Server C and remove replication for the virtual machine.

Enable replication to Server D for the virtual machine.

Move primary or Replica virtual machines to different servers or clusters

You can move either primary or Replica virtual machines around to different servers either with quick migration or export/import, but in many cases resynchronization will be required.

Remove replication or extended replication

You can remove extended replication with Hyper-V Manager by right-clicking the Replica virtual machine and then pointing to Replication. Point to Remove Replication and then select either Remove extended replication or Remove all replication. If you remove the replication relationship between the Replica and the extended Replica, changes in the virtual machine are no longer forwarded to the extended Replica, but the virtual machine on the extended Replica is not deleted.

Note

If you want to remove replication between the primary and the Replica, remove replication between the Replica and the extended Replica first.

With Windows PowerShell, use the Remove-VMReplication cmdlet with the parameter -ReplicationRelationshipType. Use the value Extended to remove extended replication or Simple to remove primary replication.

Examples:

To remove extended replication from the Replica server:

Remove-VMReplication –VMName <name> -ReplicationRelationshipType Extended

To remove primary replication from the Replica server:

Remove-VMReplication –VMName <name> -ReplicationRelationshipType Simple

To remove all replication (run from primary or extended Replica server):

Remove-VMReplication –VMName <name>