A couple of years ago, I wrote an article where I talked about some of the hurdles that I encountered when troubleshooting a problem deploying a System Center Virtual Machine Manager (VMM) agent onto a Hyper-V host. Recently though, someone got in touch with me because they were having some agent deployment issues of their own. My first thought was to send them a link to the article mentioned above. After reviewing the article, though, I realized that there are several additional troubleshooting techniques that I didn’t have the space to cover in my original article. As such, I wanted to revisit the topic and talk about some more things to check out if you have trouble adding a Hyper-V host to VMM.
Out of time
If you are having trouble deploying a Virtual Machine Manager agent to a Hyper-V host, the first thing you should do is make sure that the Virtual Machine Manager server’s clock is in sync with the Hyper-V host. I think that I mentioned this technique in my original article, but I wanted to underscore the point because it is so important. Clock skew issues can cause the agent deployment process to fail, even if everything else is configured correctly.
VMM agent installation failure
Often when a Virtual Machine Manager agent fails to install properly, it’s because the VMM server is physically unable to copy the agent to the Hyper-V host. When this happens, you will usually see an error 415 listed in the job history. The full text of this error message is:
- Error (415) Agent installation failed copying C:\Program Files:\Microsoft System Center\Virtual Machine Manager\agents\I386\3.1.6011.0\msiInstaller.exe to \\servername\ADMIN$\msiInstaller.exe.
Like so many of the other errors produced by System Center Virtual Machine Manager, this error’s descriptive text can be a little bit misleading. Occasionally, a 415 error is accompanied by additional details indicating that a process cannot access a file because it is in use by another process. The details might also indicate that the target account name is incorrect. My own experience has been that these two factors rarely, if ever, point to the true underlying cause of the problem. As such, I wanted to talk about some of the things that you should be checking.
Assuming that the Hyper-V server’s clock matches that of the Virtual Machine Manager server and that both servers exist in the same domain, you should continue your troubleshooting efforts by ensuring that no firewall rules prevent the agent from being deployed. Five firewall ports need to be open on your Hyper-V server. These include:
- Port 80 (WinRM)
- Port 135 (RPC)
- Port 139 (NetBIOS)
- Port 445 (SMB over TCP)
- Port 443 (HTTPS used by BITS transfer)
- 5985 (WinRM)
- 5986 (WinRM)
There are two important things to keep in mind about these firewall port requirements. First, although these ports will need to be open on the Hyper-V host on which the agent is being installed, any firewalls between the Virtual Machine Manager server and the Hyper-V host must also allow traffic to pass on these ports.
The second important thing to note about the firewall ports is that these are not the only firewall ports that Virtual Machine Manager uses. The ports listed above are used for agent communications, but additional ports are used for other functions. For example, Port 1433 is used when communicating with a remote SQL database. Another example is that Port 22 is used when communicating with a VMware server. Microsoft offers a full list of the ports that Virtual Machine Manager uses here.
Check the Hyper-V server’s roles
Another thing that you should do if you are having trouble installing a VMM agent onto a Hyper-V host is to check the Hyper-V server’s roles. Microsoft best practices have long stated that Hyper-V hosts should not run any additional roles or services. The exception is ancillary services needed to support the Hyper-V role. A couple of common examples include backup agents and antivirus software.
As strange as it sounds, though, there is an additional server role that you will need to enable before you can deploy a VMM agent. It’s the file server role. The file server role is usually enabled by default on Windows servers, but some administrators disable it in the interest of security. However, the Virtual Machine Manager server will be unable to deploy an agent to a Hyper-V server unless the File Server role is enabled on that server.
Check the Hyper-V server’s shares
Windows Servers generally include a hand full of hidden shares. These shares are just like any other file path share, except that they are created by default, and the share name ends in a dollar sign (which tells Windows to hide the share). For example, a hidden share exists for each of the server’s local storage volumes.
For Virtual Machine Manager to be able to deploy an agent to a Hyper-V server, the Hyper-V machine must include a hidden share called Admin$. This share is created by default, so it should exist unless someone has removed it.
The easiest way to confirm that the Admin$ share exists is to open an elevated command prompt window on your Hyper-V server and enter the following command:
Net view \\<hyper-v server name> /all
If, for example, your Hyper-V server is named Hyper-v-1, then the command would be:
Net view \\Hyper-v-1 /all
When all else fails
If you have tried everything suggested in this article, but are still unable to deploy the Virtual Machine Manager agent, then there is one last thing that you can try. System Center Virtual Machine Manager makes use of a Run As account that it uses to perform various tasks on Hyper-V hosts. Assuming that the Run As account is a domain account (which it should be), try manually adding the Run As account to the Hyper-V server’s local Administrators group. This will ensure that the Run As account (and Virtual Machine Manager) have permission to do whatever they need to do on the Hyper-V host.
Featured image: Shutterstock