Hyper-V: Why does Hyper-V Manager not always work over VPN connection? Access Denied or RPC server unavailable errors.
This post examines a problem several people have reported when running Hyper-V Remote Management tools over a VPN connection - specifically hitting an error “Access denied. Unable to establish communication between ‘SERVER’ and ‘CLIENT’”. In some variations, I’ve seen RPC errors such as “RPC server unavailable. Unable to establish communication between ‘SERVER’ and ‘CLIENT’.”
And an example of an RPC error case:
To be explicit up front, I am talking about this only occurring over a VPN/RAS connection – when connected using a wired or wireless connection without VPN, everything works normally. If things are not working on wired/wireless, follow my series of remote management posts to configure everything first.
Diagnosing the issue took a bit of sleuthing. So let’s dive in. A big clue is in the first message – it implies there is some form of communication between the Hyper-V enabled server and the Remote Management client. Indeed, that is correct – there is a DCOM callback. So let’s start by looking at the IP configuration on the laptop machine I’m using for this walkthrough after the VPN connection has been established.
Note that the DHCP assigned address for the VPN connection is 192.168.200.6, and the DHCP assigned address for the Internet connection is 192.168.1.119.
Let’s run a network trace network trace on the Hyper-V enabled server to see what’s going on. I’m running the network trace while starting Hyper-V Manager on the laptop:
The two highlighted lines show that the Hyper-V enabled server is making an attempt to connect to my local wireless IP address on my broadband connection, 192.168.1.119, rather than the DHCP assigned IP address for my machine on the internal network, 192.168.200.6.
What’s also interesting in the trace are ARP packets from the Hyper-V enabled server at 192.168.200.218 to “HPCRAPTOP”:
Notice that the server is asking where 192.168.200.14 is, and netmon is resolving 192.168.200.14 to the IP address of the laptop. So that indicates all is not well with DNS since we know above that the DHCP assigned address on the VPN connection is 192.168.200.6. Let’s do an nslookup to examine the DNS entry for the laptop.
Indeed, the laptop from a DNS perspective is incorrect and explains why netmon is resolving 192.168.200.14 to my laptop. (Although I didn’t mention it, I happen to know that this DNS entry, 192.168.200.14, was the IP address assigned to the laptop when it was last connected directly to the internal network.)
So as an experiment and first workaround, let’s edit \windows\system32\drivers\etc on the Hyper-V enabled server to add an entry for my laptop as 192.168.200.6, the current IPv4 address for VPN and see what happens.
Yes, that works. But it’s hardly what I could describe as a desirable or every-day-workable solution. If you’re walking through with me, remember to remove that entry hosts to see if there are any other workarounds.
Well there is one interesting workaround which I mentioned in my remote management configuration series. However, I absolutely do NOT recommend this one unless you really need to as you are lowering the security of your machine. Changing this setting is NOT necessary for remote management in a domain environment, but it is in a workgroup environment (my home environment I’m using for this is domain based). Here are the settings to change in dcomcnfg on the management client:
Why this works is related to WMI/DCOM fallback, but I’m far from claiming to be an expert here and will walk swiftly away from any further explanation. However, I re-iterate, I absolutely do not recommend you change this setting unless you need to.
So let’s step back a bit now and try and understand a bit more about the DNS issue. The obvious thing to think may be to run “ipconfig /registerdns” from an elevated command prompt on the remote management machine to correct the DNS registration. Let’s see what happens, while at the same time running a network trace on the ISA server with a filter for just the DNS protocol.
If you’re ahead of the game, you may notice this is a very interesting capture! Maybe not if you’re aware of my home setup, so let me explain why. 192.168.15.2 is the external internet address of my ISA server (in turn connected to a VOIP router). The destination being resolved to a host with name starting ‘ns’ is my ISP’s DNS server. Looking at the frame details, you can see the packet is a DNS update request for the laptop. Unsurprisingly, if you look at the response from the ISP in packet 3949, the response is “NotAuth”. Afterall, they’re not authoritative for DNS of my domain. I am!
This routing to the external network through ISA is normal expected behaviour. So I’m still yet to find a good solution. But all is not lost (of course). Let’s take a different tactic and look a little closer at the Vista SP1 inbox VPN client configuration (as in one which hasn’t been created by what-ever the equivalent of CMAK, or Connection Manager Administration Kit, for Vista – and no, I’ve no idea what the replacement technology is. But it does remind me to do some research for another day....).
I’m assuming you’re already familiar with configuring a PPTP or L2TP VPN connection in Vista – that’s a little outside of the scope of this post. But here’s the IPv4/Properties/Advanced/DNS dialog tab of the VPN connection I’ve created to connect back to my home network. Look at the bottom three items relating to DNS registration:
Hmmmm. These look extremely promising . Logically, it sounds like I want all three: I want to specify a DNS suffix for this connection which is that of my internal domain; Yes, I want to register the connection’s address in DNS; and I’d like to use the DNS suffix in the DNS registration. So I changed it to look like this:
After saving the changes, let’s run that DNS-filtered network trace on the ISA server again while re-establishing the VPN connection:
Looks good as a DNS update was sent to the internal DNS servers, not to the external ISP. It shows the update for the IPv4 address of the remote management client as 192.168.200.4 with a success response in the following packet. And ipconfig on the client?
This confirms the trace above – the remote management client has IP address 192.168.200.4. What about an nslookup of the laptop?
Excellent. Everything is looking rosey – the DHCP assigned IP address of the laptop acquired from the VPN connection is in DNS on the internal servers. Therefore, the Hyper-V enabled server should be able to locate the laptop when making it’s DCOM callback, so let’s fire up Hyper-V manager and see what happens:
Voila! Hope you found that useful.
Cheers,
John.
Comments
Anonymous
January 01, 2003
Tristan - curious, I've not heard of this having been reported before. I'd be interested to see the results of use wbemtest on the client to connect to \serverrootvirtualization and run a query "select * from msvm_computersystem". You should get multiple entries back - one for the server itself, and one for each VM configured on the system. Can you confirm also if you are using SCVMM in your environment? Thanks, John.Anonymous
January 01, 2003
PingBack from http://makemoneyonline.ezineaerticles.com/2008/08/08/hyper-v-why-does-hyper-v-manager-not-always-work-over-vpn-connection-access-denied-or-rpc-server-unavailable-errors/Anonymous
January 01, 2003
Tristan - I confess to now knowing whether disabling that service has that effect. I'd still be sure though that it is a case of the server not being able to accurately resolve the IP address of the client. The wbemtest queries above only test client to server. Can you try pinging server to client -4 byname to verify it hits the right address? Maybe worth also running a netmon trace on the server while connecting to verify that the server is attempting to callback to the right IP address of the client. To confirm also - are you saying that wbemtest on VPN returns instances for each of the VMs, but Hyper-V Manager shows no virtual machines, and no error? However, on non-VPN, using the same account, you get a list of VMs back in both Hyper-V manager and wbemtest? VMM puts VMs into scopes which are not generally accessible unless you are authenticating as the delegated user in VMM, or the local administrator on the Hyper-V machine itself. I'm wondering if it's actually working and not returning any virtual machines simply due to the use of VMM. If you can confirm there is a inconsistency using the same account in the VPN/non-VPN case. Thanks, John.Anonymous
January 01, 2003
Paul - can you clarify that without VPN that remote management works correctly. What do you mean by access any of the created machines - that they do not appear in the list; they do appear but you cannot access them using VMConnect, or something else. Thanks, John.Anonymous
January 01, 2003
Chuck - which of the two errors are you getting? If access denied, have you followed the appropriate parts for configuring remote management? Can you also confirm you have updated to Hyper-V RTM? Thanks, John.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Steve - no, this is still relevant.Anonymous
January 01, 2003
Curiosity got the better of me. When I was analyzing why Hyper-V Remote Management didn't always workAnonymous
January 01, 2003
David A Does this work without the SSL VPN - with the info you've provided about it, it's not clear if that could be the cause. Do you have a way to connect on the same LAN directly to rule it out? For other troubleshooting Hvremote /show reveals all. If you can post that from both server and client side; PLUS: ipconfig /all on both machines; PLUS: results of attempt to ping by name the client from server and visa-versa, it will give me the info I need to determine if it's an external factor. cmdkey should only have been necessary in an all workgroup config if the usernames and passwords didn't match. To be clear though on your current scenario - you're now attempting to connect to a domain joined server from a workgroup vista client. It would be helpful if you could confirm if cmdkey is set correctly to authenticate with domain credentials to the server and that domain account has been granted remote access on the server. Thanks, John.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Tristan - another option which may help diagnosis is to turn on tracing for Hyper-V Manager. If you email me using the link at the top, I can forward on instructions. Thanks, John.Anonymous
January 01, 2003
The comment has been removedAnonymous
September 08, 2008
Unfortunately, the above steps didn't quite work for us in fixing our Hyper-V over VPN. Any further ideas?Anonymous
September 15, 2008
John - Excellent post, and much appreciated! You saved me a zillion hours of frustration! I made an additional discovery. After going through your steps, I was still having problems (note: there is an ISA 2006 server between my client and the Hyper-V server), but instead of timing out, I was immediately getting a "Could not connect to 'Server Name'" error. I added an access rule to allow all traffic FROM "Internal" TO "VPN Clients", and then, in the "Filtering" dialog on the "Ports" tab, I unchecked the "Strict RPC Compliance" checkbox. That did the trick, and now, I can manage my network from home. Thanks again! J.JaAnonymous
September 21, 2008
Thanks a lot, help me make my configuration working But in the case of Network to Network VPN With the management client in a workgroup, I don't find any other solution than editing the hosts file on both side. JLOAnonymous
September 22, 2008
The comment has been removedAnonymous
October 02, 2008
I'm getting the same error but not in a VPN solution... both machines on the same internal LAN, same subnet and both in the same domain where the logged in user is in the domain admins group. Is there anything special you need to do in order to connect?Anonymous
October 08, 2008
The comment has been removedAnonymous
October 14, 2008
The comment has been removedAnonymous
October 16, 2008
The comment has been removedAnonymous
October 25, 2008
Justin James: Thank you very much for the hint regarding ISA rpc filtering. This is absolutely necessary and did the trick for me! AlexAnonymous
November 10, 2008
The comment has been removedAnonymous
January 05, 2009
The comment has been removedAnonymous
January 05, 2009
The comment has been removedAnonymous
February 02, 2009
Thanks a lot. After following the instructions I still got access denied (connecting workgroup Vista to domain HyperV) until I used the "cmdkey /add:ServerComputerName /user:ServerComputerNameUserName /pass" command. Instead of servernameusername in the /user: section I use domainusername - and then it all worked. Thanks MarkAnonymous
March 21, 2009
A comment - this problem might also occur if the client machine is assigned a new IP address and the Hyper-V server still uses the old IP address. In that case you might want to run ipconfig /flushdns on the Hyper-V host. CheersAnonymous
April 12, 2009
Hello everyone! Very nice and helpfull post. My config is a windows 7 domain client and a hyper-v domain server. When I'm inside of our company netwok everthing is fine with the remote management of the hyper-v server. Now I am at home and connected with vpn over an ISA 2006. With the help of your articel it is possible to connect with the remote mmc to the hyper-v server. After I take the neccessary changes for ISA Server 2006 (disable RPC filter), I get the hyper-v server in the mmc, can create new guest systems, check virtual harddrives and so on. But I don't see any virtual guest system in the middel console window. There is only a message "RPC Server unavaible. Unable to establish RPC connection between Server and Client." I think it is the same problem like Paul descibes above. Perhaps somebody can help me.Anonymous
June 19, 2009
Thanks a lot! I am also having the excact same problem as TPickhan. I can edit the settings in Hyper-V, but i cannot view any of hte machines and am getting the RPC error.Anonymous
July 01, 2009
The comment has been removedAnonymous
July 14, 2009
The comment has been removedAnonymous
July 20, 2009
Hi John, Sorry about the delayed reply and thanks very much for your help. Yes, we are using SC VMM 2008 in our environment and I believe this server is VMM-managed, but I am not presently a user of VMM on this network so I can't confirm. I should be able to arrange tests if needed though. I tried the WBEMTEST query and I'm getting the seven results for the parent and the six children as you describe. The parent returns the server name and the children have GUIDs for names. Is this what you would expect? Can you suggest anything else? Cheers, TristanAnonymous
July 20, 2009
The comment has been removedAnonymous
July 21, 2009
The comment has been removedAnonymous
August 07, 2009
Hi John, Have you received my troublehooting information or have you had any other thoughts about this? We’re continuing to have problems and since the server is Hyper-V Server our only option is to connect via Hyper-V Manager remotely – we can’t log in over RDP and then launch the tool as a work-around (unless I'm missing how that's done). As I mentioned in the e-mails, the Client Trace config didn't produce any files and we can't connect from the VMM administrator console since this server is just managed by VMM - it's not a VMM server. We also can't use HVRemote since it is VMM managed. Since a few other people seem to have had this problem above and since WBEMTEST seems to indicate that this should work, is it safe to assume this is a bug in Hyper-V Manager or the MMC? If so, can we expect a patch? Thanks, TristanAnonymous
August 13, 2009
The comment has been removedAnonymous
August 27, 2009
Yes, I am getting the same problem as Tristan. I initially had an RPC error in the Hyper-V console to my remote network Hyper-V Hosts, but partially solved this via creating a new ISA Server rule to my Hyper-V hosts that disabled "Enforce Strict RPC Compliance". As with Tristan, the Hyper-V console now appears to connect correctly, however no VMs are displayed. Curiously though, Tore Lervik's excellent Hyper-V Monitor Vista/7 gadget shows all the remote hosts including their VMs!! However when trying to initiate a connection to the remote VM through the Hyper-V gadget, the following error msg is displayed: "An error occured when trying to register for IME events for 'VWSAPPXXXXX'. The operation on computer 'WSVIRT0009' failed."Anonymous
August 31, 2009
The comment has been removedAnonymous
September 23, 2009
The comment has been removedAnonymous
October 29, 2009
Excellent job - worked like a charm!Anonymous
November 05, 2009
The comment has been removedAnonymous
November 06, 2009
The comment has been removedAnonymous
March 10, 2010
The comment has been removedAnonymous
September 28, 2011
With ISA 2006 you should create 2 rules (1st from VPN clients to HVS and 2nd HVS to VPN clients) and then right click on each rule and deselect 'enforce strict RPC compliance'.Anonymous
December 14, 2011
The comment has been removedAnonymous
March 03, 2013
Check your firewall specifically for port 135 TCP streams coming from you Hyper-v Server.Anonymous
June 04, 2013
Unfortunately these posts are extremely old (2011) so I suspect that a lot of this is irrelevant or has been fixed in the current release. (I hope). We have had a few similar issues here with a single user, however the configuration appears to be setup correctly on the client. At this point, we are monitoring to see if it continues to be an issue. Btw, I love the machine name of his test machine used in the examples above. hpcraptop! Steve <a href="http://bestpocketknifecompanion.com>MCSE</a>