John Howard - Senior Program Manager in the Hyper-V team at Microsoft

Senior Program Manager, Hyper-V team, Windows Core Operating System Division.

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

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

  • Comments 103
  • Likes

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote 

Quick links to the all parts in the series: 1, 2, 3, 4 and 5 

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.

wg27

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)

wg28

wg29 

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

wg30

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”

wg31

wg32

wg33


Step 7 (On the client)

IMPORTANT!!!! You need to do this step in the following scenarios:

  • Client and server are both in a workgroup
  • Client is a workgroup and server is in a domain
  • Client is in a domain and server is in a workgroup
  • Both client and server are in domains, but there is NO TRUST between them.  

You DO NOT NEED TO DO THIS STEP if the client and server are in either the same or trusted domains. Go to step 8.

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.

wg34 

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

wg36

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.

wg37
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!

wg39

Cheers,
John.

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Comments
  • 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

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

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

  • 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

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

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

  • 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

  • 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?

  • Tore -  I got your email and have just replied.

    Thanks,

    John.

  • 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

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

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

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

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

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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment