Hyper-V Virtual Machine Connection and Direct Access

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.


Comments (3)

  1. Pat Telford says:

    A less drastic fix, if you happen to have the DirectAccess Connectivity Assistant installed and configured is to right-click the DCA icon in the WIndows taskbar and select "Prefer Local DNS Names". This too clears the NRPT cache from the local computer and gets you around this problem. Re-enabling DirectAccess can be accomplished by right-clicking DCA again and selecting "Prefer Corporation DNS Names"

  2. Takanari Sato says:


    In my environment, I coped with this subject by writing the entry of IPv6 to a hosts file.

    ::1 <Hyper-V server's FQDN>

  3. J.F. LeSaux says:

    Thanks for this great post. I had the same problem and the fix worked magic.

Skip to main content