Hyper-V is puking

[RebateMonger]

Did you check out this article?

Hyper-V: Why does Hyper-V Manager not always work over a VPN connection? Access Denied or RPC server unavailable errors

http://blogs.technet.com/jhoward/ar...-denied-or-rpc-server-unavailable-errors.aspx

"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’.”

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."

 

[narzy]

Did you check out this article?

Hyper-V: Why does Hyper-V Manager not always work over a VPN connection? Access Denied or RPC server unavailable errors

http://blogs.technet.com/jhoward/ar...-denied-or-rpc-server-unavailable-errors.aspx

"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’.”



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."

yes we've walked step by step through that article and haven't been able to nail it down. also ran the HVremote tool that John wrote and this is the interesting part...

7: - Async notification query to root\virtualization WMI namespace
FAIL - Notification query failed The remote procedure call failed.

The most likely cause of this failure is that you have not restarted the
server after having added a user account for the first time. Either restart
the server, or restart the Windows Management Instrumentation service
and all dependent services on the server before retrying.

Alternately, there is a DNS issue and the server cannot locate this
machine. You should check this by performing a ping test from the
server to this machine verifying that the IP address the server
is trying to reach matches the IPv4 address shown in the output above.
Note that it does not matter if the ping succeeds or fails, just that
the IP address is correct.

Run on itvs2.tech.div: ping -4 ANNIE-WIN7

Note that if you do not have DNS in your infrastructure, you can edit
the \windows\system32\drivers\etc\hosts file on the server to add an
entry for ANNIE-WIN7

If you do have DNS in your infrastructure, you may want to try flushing
the DNS cache on the server, and re-registering against DNS on the client

Run on itvs2.tech.div: ipconfig /flushdns
Run on ANNIE-WIN7: ipconfig /registerdns

If you are connected over a VPN, see http://tinyurl.com/o4lsbw for
information about another likely cause.

I'm thinking that its purely a DNS issue at this point but the minions are going to have to figure that out. I'll suggest it to them tomorrow though. Any way that I can test and back up my theory? NSlookup gets everything right and I don't see any issues in ipconfig. I've flushed the dns cache and ipconfig /registerdns and that hasn't been fruitful.

 

[stlcardinals]

So on the Hyper-V server itself, it can successfully resolve the VPN client's name to it's VPN assigned IP address?

 

[narzy]

So on the Hyper-V server itself, it can successfully resolve the VPN client's name to it's VPN assigned IP address?

I don't think so, that report is from the client side. it looks like the client on the vpn can resolve the server but I don't think that it is working from the server to the clients. I don't have privileges on the server so I can't test it. I have to ask the student administration team to test it for me.

 

[stlcardinals]

I don't think so, that report is from the client side. it looks like the client on the vpn can resolve the server but I don't think that it is working from the server to the clients. I don't have privileges on the server so I can't test it. I have to ask the student administration team to test it for me.

Name resolution has to work both ways for it to work. DNS seems like the culprit.

 

[narzy]

Just got this back from the instructor

The issue is that none of the indicated problems is the problem. DNS is working. User accounts are up. We have rebooted the server. We have restarted WMI. We are stuck.

 

[theevilsharpie]

Name resolution has to work both ways for it to work. DNS seems like the culprit.

This is not true. Only the DNS name of the server matters.

OP, this seems like a routing issue. Making sure that ICMP Echo Requests are allowed through the client's firewall, try to run a tracert from the Hyper-V server to the VPN client and see what happens.

 

[narzy]

This is not true. Only the DNS name of the server matters.

OP, this seems like a routing issue. Making sure that ICMP Echo Requests are allowed through the client's firewall, try to run a tracert from the Hyper-V server to the VPN client and see what happens.

Fixed it!

The proxy server was not handling the requests properly and was stopping traffic from routing to the hyper-v server. Some traffic made it but some did not.

This took a hell of a lot of detective work! thanks everyone for the help, really appreciate it. If I can find out exactly what the fix was I'll let you know so if you're in a similar situation you don't have to go through this hell

 

[RebateMonger]

Congrats on finding a fix to a tough problem.

How did you find that the proxy server was messing up traffic sometimes?