A couple of years ago, I wrote an article on this site outlining some things that you can do to fix the problem when you are unable to add a Hyper-V host to System Center Virtual Machine Manager. Most of the Hyper-V troubleshooting techniques discussed in that particular article centered around the Virtual Machine Manager agent deployment process. While agent-related problems are quite common, that isn’t the only thing that can cause problems when bringing Hyper-V hosts under management. In fact, problems can arise long before Virtual Machine Manager even tries to deploy an agent. In this article, I want to show you what to do when this happens.
Hyper-V troubleshooting: Bringing a host under management
Normally, when you bring a Hyper-V host under management using VMM, you begin the process by opening the Virtual Machine Manager administrator console and selecting the VMs and Services workspace. From there, right-click on the host group that you want to use and choose the Add Hyper-V Hosts and Clusters command from the shortcut menu, as shown below.
At this point, Virtual Machine Manager will launch the Add a Resource Wizard. This is the wizard used for adding a Hyper-V virtual machine. For this article, I am going to assume that the Hyper-V server is domain-joined. Therefore, when the wizard’s initial screen asks where the server is located, you would want to choose the Windows Server Computer in a Trusted Active Directory domain option, as shown in the next image.
Click Next, and you will be prompted to enter the credentials to be used by the discovery process. You would typically specify your RunAs account and click Next. Keep in mind that a RunAs account might not necessarily have Active Directory permissions. If you are having trouble adding a Hyper-V host to VMM, try using a domain admin account instead of your usual RunAs account.
The next screen asks you to enter the name of the Windows Server computer that you want to add. Enter the computer name and click Next. When troubleshooting Hyper-V, this is often where the troubles begin. If you look at the image below, you can see that the discovery process has failed. This is not an agent-deployment issue. Virtual Machine Manager can’t even find the specified Hyper-V server.
The troubleshooting process
When the discovery process fails, as was the case in the image above, there are a number of things that you can do to diagnose and fix the problem. Personally, I recommend taking a moment to make sure that you have spelled the hostname correctly. As embarrassed as I am to admit it, I once spent hours troubleshooting a problem only to realize later that a simple typo caused my problems.
Assuming that the hostname is spelled correctly, try using a few variations. You might try using the host’s fully qualified domain name rather than its NetBIOS name (for example, Hyper-V.poseylab.com instead of Hyper-V). You might also try entering the host’s IP address.
If those things fail to fix the problem, you will need to look elsewhere for a solution. As a next step, I recommend verifying that the VMM server and the Hyper-V host are both joined to a common (or at least trusted) Active Directory domain. The easiest way to do this is to right-click on the Start button and choose the System option. When the resulting window opens, scroll down to the bottom and then click the System Info link. The resulting screen will show the computer name, the full computer name (the fully qualified domain name), and the domain name. Again, you will need to make sure that both machines are joined to the correct domain.
Since the Active Directory has a direct dependency on DNS, it’s a good idea to make sure that DNS name resolution is working properly. In fact, when I have encountered these types of problems in real life, the problems have often been DNS-related.
Open an elevated Command Prompt window on both the Virtual Machine Manager server and on the Hyper-V server. On both machines, enter this command:
When the results are returned, make note of the server’s IP address and the IP addresses of the DNS servers that it is using. Make sure that both servers are using the same DNS servers. Otherwise, the name resolution process may fail. While you are at it, it doesn’t hurt to try pinging the DNS server to make sure that there is a communications path between the two machines, although a ping failure doesn’t necessarily indicate a communications failure since some firewalls are configured to block network pings. You can see what this process looks like in the image below (be sure to do this from both servers).
Once you verify the DNS addresses, open the DNS Manager and make sure that the correct IP address is listed for both servers. While you are at it, take a look to make sure that you don’t have multiple entries for either of the hosts. Double entries can sometimes occur if a server is manually assigned a new IP address. Cleaning up double entries by deleting incorrect DNS records can often fix name resolution problems.
Hyper-V troubleshooting: When all else fails
If you have tried everything that I have recommended but are still having host discovery problems, there are two more things that I recommend trying. First, make sure that the Hyper-V Host, VMM, and your domain controller have their clocks synchronized to the correct time.
You should also make sure that the WinRM service is running on the Hyper-V host and that no firewall rules are blocking WinRM communications (Ports 5985 and 5986). Keep in mind that additional ports will need to be open to allow agent communications later on. You can find a full list of the port requirements from Microsoft.
Featured image: Designed by Vectorjuice / Freepik