Share via

Hyper-V Virtual Machine Connection and Direct Access

  • Article

Some days ago I just wanted to create a new virtual machine on a Windows Server 2008 R2 Hyper-V laptop. After booting up that new machine from an .iso image and trying to connect using the “Virtual Machine Connection” (vmconnect.exe) application I got the error message:

“Cannot find the physical computer that runs the virtual machine. Try to flush your DNS cache (run ipconfig /flushdns). Then try to connect again. If the problem persists, contact the administrator of the physical computer or your network administrator”

This occurred when having no connection to a network in a pure offline scenario. The connection to an existing VM on that same machine using RDP worked just fine.

After some debugging we found the root cause of this (thanks Jeromy!). The issue was related to the fact that the laptop was used for Direct Access.

When a Hyper-V enabled machine is disconnected from the network, the Hyper-V virtual switch keeps the network adapter as connected to a network.  This means that the NIC will get auto-assigned addresses etc.  Direct Access is still active in this configuration. Most importantly the NRPT configuration is still active which prevents one of the requirements for Hyper-V server from functioning properly.

The real problem:
Hyper-V server requires the ability to connect back to the “remote” client via resolving the FQDN of the connecting client and establishing its own TCP connection back to the “remote” client.  Even while managing Hyper-V locally the local tools are seen as a “remote” client and as such the Hyper-V server will extract the FQDN of the connection and attempt to do name resolution to ensure that the client that is connecting actually owns the IP address it is connecting from. With NRPT active but unable to access a Direct Access server because the Direct Access client is offline the NRPT prevents the resolution of the FQDN (it would have allowed short-name resolution to fall through and use local LLMNR except that the connection is using IPv4 and not IPv6 and thus the IP addresses would not match and the connection is denied as a “spoof” attack).  Once NRPT is taken out of the picture the Hyper-V server is able to properly do name resolution leveraging the local resolver and everything connects up just fine.

The solution:
-go into the Registry and delete "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig"
-in an elevated command prompt, enter: sc control dnscache paramchange

After that the “Virtual Machine Connection” was working fine.

-thomas

Comments

  • Anonymous
    July 12, 2010
    The comment has been removed

  • Anonymous
    January 27, 2011
    Hello. In my environment, I coped with this subject by writing the entry of IPv6 to a hosts file. ::1 <Hyper-V server's FQDN>

  • Anonymous
    December 11, 2011
    Thanks for this great post. I had the same problem and the fix worked magic.