28 March 2008

Part 2 - Hyper-V Remote Management: You do not have the requested permission to complete this task. Contact the administrator of the authorization policy for the computer ‘COMPUTERNAME’

The second part of the extra-long blog post contains the steps necessary on the client machine. Part one concentrated on the server side configuration.

Step 5 (On the client)

Step 5 mirrors step 2 in the first part of this blog post, but on the client. Note also (again for convenience more than anything else), my Vista SP1 machine is actually itself a virtual machine running on the same physical machine as the server. You’ve got to love it when you can have a somewhat recursive technology ;)
 
Enable the firewall rules on the client for WMI (Windows Management Instrumentation). From an elevated command prompt, enter the following:

netsh advfirewall firewall set rule group=”Windows Management Instrumentation (WMI)” new enable=yes

Make sure the command it successful and responds: Updated 8 rules(s). Ok.



If you now open “Windows Firewall with Advanced Security” from Control Panel/Administrative Tools on the start menu, you will notice eight rules, six inbound and two outbound have been enabled. (It helps to sort by Group)





Step 6 (On the client)

This step creates a firewall exception for the Microsoft Management Console application (mmc.exe). From an elevated command prompt, enter the following:

Netsh firewall add allowedprogram program=%windir%\system32\mmc.exe name=”Microsoft Management Console”

Make sure the command is successful and responds “Ok.”



You can verify that you succeeded in the above step by looking in the “other” Windows Firewall application. (No, I have no idea why there are two either….). Open "Network and Sharing Center" on the control panel, and click Windows firewall in the bottom left corner, then click "Allow a program through Windows Firewall" where you’ll see a new entry with the name “Microsoft Management Console”







Step 7 (On the client)

WMI makes calls back from the server to the client. This is entirely expected (and is not Hyper-V specific). When a server is in a workgroup, the DCOM connection from the server back to the client is "anonymous". This step therefore grants the appropriate permission.

On the start menu box (yes, well spotted, I need to apply updates), type dcomcnfg and hit enter to open Component Services. If UAC is enabled, click allow when prompted or enter appropriate administrative credentials.



Expand the tree down through Component Services\Computers\My Computer, select My Computer, right-click, choose properties and select the COM Security tab.



Click Edit Limits in the Access Permissions area (do not confuse with Edit Limits in the Launch and Activation Permissions area). Select “ANONYMOUS LOGON” from the list of users, and make sure Remote Access/Allow is checked in the permissions area. Your screen should look like below.



Click OK and OK again, and close Component Services.

Step 8 (Away from the keyboard)

Take a deep breath and pat yourself on the back. Now do that again. A third time if you like. Then double-check to make sure you followed the above steps and those in part one  to the letter.  You did remember the step about restarting the server, didn't you?

Step 9 (On the client)

Logon as the account you have granted permissions to (“john” in my walkthrough) on the client.

Start Hyper-V Manager from Administrative Tools on the Control Panel. Enter appropriate administrative credentials if UAC is enabled and the account is not an administrator on the client.

Click Connect to Server and enter the name of the remote machine.

Watch in awe as you get a screen like below. You can also see, it took me 2 hours, 24 minutes and 19 seconds to do this walk-through documenting it step-by-step. It should take you much less time!



Cheers,
John.

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# John Howard : Part 1 - Hyper-V Remote Management: You do not have the requested permission to complete this task. Contact the administrator of the authorization policy for the computer ???COMPUTERNAME??? said:

PingBack from http://blogs.technet.com/jhoward/archive/2008/03/28/part-1-hyper-v-remote-management-you-do-not-have-the-requested-permission-to-complete-this-task-contact-the-administrator-of-the-authorization-policy-for-the-computer-computername.aspx

28 March 08 at 11:13 PM
# Virtual PC Guy's WebLog said:

I am feeling lazy today - but thankfully my colleagues have been working hard :-) Mike Kolitz has done

29 March 08 at 3:01 AM
# John Howard said:

More for my own reference, as I keep having to search the Internet for this document and never bookmark

29 March 08 at 6:08 PM
# Mike P said:

I use Windows One Care on my Vista PC. The settings above do not work as the Windows FW is turned off.

Can you post the specific programs, ports etc... to accomplish the same thing as listed above.

If I turn off the firewall on the Vista PC all works as advertised.

Thanks is advance

30 March 08 at 12:29 PM
# John Howard said:

Although I thought I’d finished at part two, after even more emails and comments on part one and two

30 March 08 at 8:58 PM
# John Howard said:

So far, I’ve covered the following Hyper-V Remote Management scenarios: Workgroup: Vista client to remote

04 April 08 at 10:49 PM
# Ivan Versluis said:

Hi John, thank you. I took me around 15 minutes to configure this remote management Hyper-V MMC console in a workgroup scenario. It works fine for me, but I had couple of problems with copy and paste of the netsh scripts in your post and enabled the rules manually using control panel. Kind regards, Ivan Versluis

07 April 08 at 7:08 AM
# Tore said:

I have a wierd problem.

I got 2 computers (main and laptop) both running vista ultimate in workgroup mode.

I have the same user\password on both but only the main one can access the hyper-v server.

The only difference i've found is that the main one uses x64 while the laptop uses Vista x86.

Any idea why one should fail when the other works perfectly?

10 April 08 at 2:41 PM
# jhoward said:

Tore -  I got your email and have just replied.

Thanks,

John.

11 April 08 at 12:50 PM
# Andrew Somervell said:

Brand new Vista x64 install, i'm getting a "Group cannot be specified along with other identification conditions" error when I enter the "netsh advfirewall firewall set rule group=”Windows Management Instrumentation (WMI)” new enable=yes" command. Any clues?

Regards,

andrew (at) somervell dot com

17 April 08 at 6:58 AM
# jhoward said:

Andrew - were you copying and pasting by any chance from above? I had exactly this error when copying and pasting when setting up another box. Have you tried typing it manually? (And no, I really can't explain why)!

Thanks,

John.

17 April 08 at 3:47 PM
# robr said:

I was pointed here after trying to connect and getting the error "Cannot connect to the RPC service, make sure your RPC service is running".

I followed all the instructions, with the exception of the firewalls steps as Windows Firewall is disabled on both computers.

My client PC is here at the office behind a firewall.  I log into a domain here at work from the PC, so it's not a workgroup config on the client side.

The server is located remotely at a data center, no firewall in front of it, windows firewall disabled, and is a standalone server.  Because of this setup, I need to get this working so I can have mouse control of the remote VMs.

Could my error be a firewall issue here at work related to RPC?  Thanks for all the work and well documented instructions.

17 April 08 at 3:48 PM
# jhoward said:

Rob - there's a couple of things here. Make sure you cover the steps in part 5 which covers a domain joined client to a workgroup server. Similar to this, but a couple of nuances.

However, what's most likely blocking this working is the external firewall you are describing. WMI/DCOM are not particularly "external firewall friendly" due to the number of ports you need to open, so I would not recommend the scenario you are trying to achieve. I'm not sure the exact list of ports you need for this - haven't tried it myself, but as I understand it the default ports are

135

49152-65535  

2179

There's a couple of articles about this you may want to read: http://msdn2.microsoft.com/en-us/library/ms809327.aspx

http://support.microsoft.com/kb/217351

If you're also behind a NAT router, I don't believe remote DCOM calls would work.

I'm not sure of your exact topology, but I would look towards a TSGateway which you can remote Hyper-V manager through and use mouse (once the integration services are installed - I have an entry a short while ago describing how to use the keyboard to drive the installation of that without mouse), or use TS directly to the server and run Hyper-V Mnaager on the server (unless it is Server Core).

Hope that helps.

Thanks,

John.

17 April 08 at 8:11 PM
# robr said:

Thanks very much John, I'll take a look at some of your other suggestions.  I'm running some Linux VMs, so I'm not certain integration services (in the case of SLES 10 which does have integration services installed, but I also have a Fedora VM) will solve all my mouse related issues.  I've installed them remotely without a mouse and just ssh in, but it would be nice to have access to the GNOME desktop.  

So far, Hyper-V has been absolutely brilliant, but this ONE issue just makes everything they've done so right seem tarnished.  I have to imagine a great majority of people will be running production Hyper-V servers remotely.

18 April 08 at 8:24 AM
# jhoward said:

Robr - I was thinking about this some more. With the caveat that I have never tried this, it may be possible to tunnel DCOM over HTTP using the RPC over HTTP proxy mechanism. When I get a chance, I'll build up a lab environment to see whether it's possible. There's some interesting information here: http://msdn2.microsoft.com/en-us/library/ms809302.aspx

You will still need port 2179 for the VMConnect video RDP connection though.

Thanks,

John.

18 April 08 at 4:02 PM
# robr said:

I'd absolutely love to see if you can get this working in your copious free time :).   I have previously played around with RPC over HTTP trying to get Outlook clients on the outside of our network to connect to the Exchange server behind our NATted firewall and failed miserably :).

18 April 08 at 4:18 PM
# Michael Sainz said:

John- I'm experiencing the same problem as Robr, but my topology is different. Instead of going through firewalls, mine is being routed by firewalls. I use ISA 2004 at two points to create a site to site VPN tunnel. Other MMC consoles seem to work, but this Hyper-V one does not. Again, it's not going through NAT, but in a routed environment.

I would like to be kept up to date also if you could.

-Michael

michaelsainz@(takemeout)sunsetpres.org

18 April 08 at 8:18 PM
# Andrew Somervell said:

Hahaha, you wouldnt believe how much I danced around when it worked John, you were right i had to type it in. Thank you.

So when's this all become less of a pain in the.... ? :P

A

22 April 08 at 4:10 AM
# Rhynier said:

Thank you very much! I would never have thought it would be so difficult to get Hyper-V Manager running with a remote connection. Two comments below.

1) I installed the RC0 for Hyper-V and found both on the server and my Vista SP1 client that some new firewall rules had been added which looked very much like the WMI rules (same ports, etc.), but starting with "Hyper-V". I disabled the WMI firewall rules from your steps and everything still worked.

2) The reason you can't copy and paste the firewall rules from the blog post is that the open and closing quotes are not the same ASCII character as the one on the keyboard :). I've seen this many times using Word as it replaces the quote character with fancy open and close quotes that the command prompt does not recognize.

24 April 08 at 8:08 PM
# mmcaulay said:

I couldn't get this to work until I explicitly added my user name to the appropriate steps in the server portion of this guide.  Even though that user was a member of the Administrators group on the server.  This was not enough to allow the connection. The user had to be added separately. At least on my setup. Running Server 2008 Full x64 with a client running Vista Business x86 SP1.

26 April 08 at 3:12 PM
# Greg said:

The reason the shell commands don't work if you cut and paste them is because the inverted commas - ie " " don't come across right - they must be some kind of unicode character I imagine - if you paste the command into a command prompt box, then just go back and re-type the " over the existing ones, they'll work.

02 May 08 at 10:23 PM
# Darin said:

What about if Hyper-V server and Client Vista are in different domains? Do I need to create the two indentical users in both domains?

16 May 08 at 4:51 AM
# jhoward said:

Darin - untrusted domains or part of the same forest? If the latter, then part 4 should work. Untrusted domains has seperate challenges which I'm still working through for a future part.

Cheers,

John.

16 May 08 at 1:14 PM

Leave a Comment

Comment Policy: No HTML allowed. URIs and line breaks are converted automatically. Your e–mail address will not show up on any public page.

(required) 
(optional)
(required) 
Page view tracker