VMM agent deployment issues? Try these solutions

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.

Firewall ports

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

Brien Posey

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at: www.brienposey.com.

Published by
Brien Posey
Tags hyper-v

Recent Posts

Contactless payments are hot, but are they secure?

The trend to contactless payments has accelerated as retailers and consumers adjust to COVID-19 realities.…

8 hours ago

Season’s fleecings: CISA warns on holiday shopping scams

The U.S. Department of Homeland Security is warning that online holiday shopping scams may be…

11 hours ago

Azure DNS: Using Azure DevOps to protect public DNS zones

This in-depth tutorial shows you how to use features available in Azure DevOps to boost…

14 hours ago

Report: Baidu Android apps had potential to expose data

Two apps from Chinese tech giant Baidu that had been available in the Google Play…

1 day ago

Shining a light on the dark shadow cast by shadow IT

Employees who don’t have the tools to get their jobs done sometimes turn to the…

2 days ago

Microsoft 365 troubleshooting: Diagnostic tools at your fingertips

Many Exchange Server troubleshooting tools don’t work with Microsoft 365. Fortunately, Microsoft has a bunch…

4 days ago