Advanced Troubleshooting of Hyper-V Replica – Part 1

The above command tests the connection between the local server (which is acting as Primary Server) and Replica Server (HV-2012R2-B.Hyperv.Local) over network port 80 using the Kerberos authentication protocol (which is Active Directory-based authentication mechanism for Hyper-V Replica).

If you are using Certificate-based authentication, you can change the above command by including the “–AuthenticationType” parameter and then specify “Certificate” as the authentication type for cmdlet to test the connection with Hyper-V Replica Server using certificates.

As you can see in the above screenshot, the error returned is “The operation timed out” for the Replica Server.

Test-VMReplicationConnection cmdlet does not provide specific error messages rather it provides generic error message which is “The operation timed out” in this case. The same error is reported in the Event Viewer also. If you look at the Event Viewer (expand Application and Services Logs | Microsoft | Windows | Hyper-V-VMMS, and click on Admin), you will see the event message similar to message reported by the Test-VMReplicationConnection cmdlet as shown in the below screenshot:

Your first task is to fix the connection issue between Primary and Replica Server, if any! To fix the connection issues, you can think of the following possibilities and then move ahead to troubleshoot the issue further:

1. Replica Server or Primary Server cannot communicate with Active Directory or the trust relationship for these two computer accounts has been broken. To verify the computer trust with Active Directory, you can use NLTEST with /SC_VERIFY switch. You need to run this command on both Primary and Replica Servers individually and make sure the output reported is similar to as shown in the below command window:

2. Replica Server or Primary Server is not authorized to access each other over the network. Please note both Primary and Replica Servers communicate over the network. They might fail to communicate if a Group Policy setting has been applied which prevents the network communication. You must check for “Access this computer from the network” Group Policy setting as shown in below screenshot which is taken from a Group Policy Object:

The Group Policy Setting should contain the computer accounts of Primary and Replica Servers or at least make sure to add Authenticated Users security group which contains both computer accounts.

3. Misconfigured TCP/IP settings on Primary or Replica Server. Primary Server communicates with the Replica Server using the FQDN. The FQDN is resolved by querying the DNS Server. In case of misconfigured DNS Server in the TCP/IP settings of Primary Server, the Primary Server might not be able to resolve the FQDN to an IP Address. In case of the name resolution issues, an event will be generated in the Event Viewer as shown in the below screenshot:

For Event ID 32022, it shows the Hyper-V Replica server could not be resolved. You can actually use Ping and NSLookup commands to test the connectivity and name resolution.

It is imperative to understand that it is Primary Server which needs to resolve the name of the Replica Server to an IP Address if replication is one way (e.g. From Primary to Replica Server). So for any name resolution issues in Hyper-V Replica environment, please make sure, especially, Primary Server is configured with the correct DNS Servers. Replica Server might hit with the name resolution issue only if reverse replication action is used.

4. Replica Server is not listening on the required network ports. Replica Server must listen on the required network ports. The required network ports are determined based on the authentication mechanism you have selected for the Hyper-V Replication. For Active Directory-based authentication, the Replica Server must listen on “HTTP 80” and network port “HTTPS 443” if Replica and Primary Servers communicate using a certificate.

To make sure, Replica Server is listening on the required port, you can run the “Netstat –ano” command. This command should list the Replica Server IP address with the port it should listen on as shown in the below screenshot:

As you can see in the above screenshot, Replica Server (0.0.0.0:80) is “LISTENING” over network port 80 which is ok. This indicates that the Replica Server is listening for replication traffic from Primary Server.

Once you fix the connection issue between Primary and Replica Server, run the “Test-VMReplicationConnection” cmdlet again to test the connection. If it does not report any error, the cmdlet output should report the message; “The connection to the specified Replica Server with the specified parameters was successful.” as shown the below PowerShell window:

5. Time difference. If there is a too great time difference between Replica and Primary Server, the replication will fail. Please ensure to configure Primary and Replica Servers to sync time from a reliable time source. The reliable time source could be a domain controller running in your production environment or an external NTP Server.

Conclusion

This article focused on how to troubleshoot issues with the Hyper-V Replica if a specific condition occurs with regards to the authentication and connectivity. We learned that Hyper-V replication could be broken because of Primary Server not able to communicate with the Replica Server due to several reasons.

There are several other reasons the communication may fail between the Primary and Replica Servers. In the next part, we are going to learn how Primary Server establishes a successful connection with the Replica Server to rule out any issues with the network ports and firewall.