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

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

Part 5. Domain client to Workgroup Server: 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 5. Domain client to Workgroup Server: 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 73
  • Likes

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

So far, I’ve covered the following Hyper-V Remote Management scenarios:

  • Workgroup: Vista client to remote server, server configuration, full install (Part one)
  • Workgroup:  Vista client to remote server, client configuration (Part two)
  • Workgroup:  Vista client to remote server, server configuration, core install (Part three)
  • Domain: Vista client to remote server (Part four)

But the questions keep coming. Part number five covers the case of a domain joined Vista client connecting to a remote server in a workgroup.

And the reason for all these posts? To configure both machines to overcome the error: “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’” message when you start Hyper-V Manager remotely.

IMPORTANT: Before anything else, I am going to assume you already have DNS setup correctly. If you can’t resolve the remote server machine using nslookup on the Vista machine, fix that now. Nothing will work unless that is right.

One shortcut I do take in the walkthrough is to make the server with the Hyper-V role enabled a full install. See part three for how that affects you if your server is a core installation. I’m not going to provide great detail about exactly what to click in each step – it’s all been covered in the previous posts, so please refer back.

Let’s make this walkthrough a little more interesting, by making it more representative of a real-world deployment by locking down the access permissions to a specific user/group (rather than 'administrator'). I’m going to have a domain user, “domain1\john” with password “johnhoward” connecting to a workgroup remote server with the Hyper-V role enabled where a local user “john” with password “john” exists. (And no, these are no reflection on my real passwords. It’s purely for demonstration only and to show you that password matching isn’t needed to make this work).

Step 1. Create the user accounts (Domain Controller & Hyper-V enabled Server)

On my domain controller, I’ve created an account "domain1\john" using Active Directory Users and Computers. Note that I am not making this account an administrator anywhere. Just a regular Joe User.

d2wg20

On the Hyper-V enabled server, I’ve created the account workgroup\john using the net user command. I’ve also created a group called “Remote Hyper-V Admins”, and added the local workgroup “john” account to that group.

d2wg21 

Step 2. Enable Firewall WMI Rules (on Hyper-V enabled server)

Run the following command as an administrative user on the server: 'netsh advfirewall firewall set rule group=”Windows Management Instrumentation (WMI)” new enable=yes'

d2wg22 

Step 3. Allow authenticated remote DCOM access (on Hyper-V enabled server)

Here I’ve added the “john” account to the “Distributed COM Users” group. Unfortunately, in a workgroup environment, you can’t nest groups, but the “Remote Hyper-V Admins” group will come in useful later.

d2wg23 

Step 4. Allow authenticate users to remote WMI namespaces (on server)

See step 4 in part one for more information. Here is where I’m using the “Remote Hyper-V Admins” group I created previously. As before, make sure you do this TWICE, once for Root/CIMv2 and again for Root/Virtualization.

d2wg24 
d2wg25 


Step 5. Configure AZMan (on server)

Here I’ve granted “Remote Hyper-V Admins” authorization rights to be Hyper-V administrators. See step 5 in part one for full details.

d2wg26

REBOOT SERVER.

Step 6. Create a firewall exception for MMC (on client)

To save repeating myself, this is identical to Part two, step 6.

Step 7. Allow anonymous callbacks (on client)

To save repeating myself, this is identical to Part two, step 7.

Step 8. Set credentials for the remote server (on client)

This is the gem of information you need. I’m logging onto the client machine as “john”, a standard domain user. The client has LUA enabled, as it should. From a non-elevated command prompt (that’s important), use cmdkey to store credentials for accessing the remote machine using the following syntax: “cmdkey /add remoteserver /user:remoteserver\username /pass”

Of utmost importance, is the option passed to the /user parameter: - you must specify it as remoteserver\username, not just username. So in my walkthrough, I entered “cmdkey /add jhoward-hp2 /user:jhoward-hp2\john /pass” as the remote machine is called jhoward-hp2.

d2wg27 

Step 9. Run Hyper-V Manager (on client)

Start Hyper-V Manager from Control Panel/Administrative Tools (or \program files\Hyper-V\virtmgmt.msc). If you are using a pre-release version of Hyper-V and have not previously accepted the EULA, accept it now.

d2wg28

You will notice that once you create a virtual machine and open Virtual Machine Connection, you will be prompted for credentials. At this point, use the credentials on the remote machine (john, password john in my example).


d2wg29 

And “Voila”

d2wg30 

So I’m very nearly there. I just need to write up the scenario of the Client being in a workgroup and the Server being domain joined. Part six to follow soon….

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
  • ... and the client being in a workgroup and the server being in a different one.  :)

    I'll run through all of this stuff tomorrow or the day after, when I get time to get back to this and see how it all goes.  But there's nothing here that's much different from the previous info that's leaving Ryan and myself in the situation where WMI Control shows "Root" and no namespaces under it.

    Anyway, I'll see what happens when I try this all again!

    Thanks for your efforts.  I just wonder if Microsoft really intended such a convoluted procedure to manage a Core box...

  • John this is great. Actually this is a real scenario environment.

    You're great!

  • @HiltonT - I'll get there ;) I'm still looking into the no namespaces not showing up but can't repro it in-house. If you can email me directly, that would help me investigate.

    Thanks,

    John.

  • Hi

    Have to begin with saying. Great blog ! :D

    I have the same issue here. Followed you instruction down to the line, but the same happens. I can't see anything else than --Root. So i'm looking forward to the solution :)

    //Michael A

  • Hi again :)

    Now i got connected to Hyper-v finaly, but i don't have permission to add new virtual machine or edit anything in Virtual Network Manager. I'm running a Win Core

    Got some ideas ?

    //Michael A

  • Michael A - This is AZMan configuration by the sound of it (step 5 above).  Did you add your user account to the Administrator under role assignments? As you're running server core, you'll need to jump through the hoops for AZMan configuration I described in part 3 (sorry!).

    Thanks,

    John.

  • John,

    Thanks for the this great guide!  I'm still amazed how people figure this stuff out.

    I think I may have found a mistake in Step 4.  In step 4 you say "See step 5 in part one for more information" but when I went to look at it, none of the screen shots matched up.  I did some looking and found the similar screenshots in Step 4 of Part 1.  

    Is this correct?

    Thanks Again,

    -Howard

  • Thanks Howard - yes, my mistake - I've corrected it above. I did indeed mean step 4 of part 1.

    Cheers,

    John.

  • John,

    Makes for really good reading

    But I am stuck at Step 4

    Step 4. Allow authenticate users to remote WMI namespaces (on server)

    See step 4 in part one for more information. Here is where I’m using the “Remote Hyper-V Admins” group I created previously. As before, make sure you do this TWICE, once for Root/CIMv2 and again for Root/Virtualization.

    the WMI just keeps tellimg me access denied

    any ideas

  • Maritn (Martin?)

    What's the domain/workgroup combination you're hitting when you get this error? Is it domain client to workgroup server as described in this walkthrough? Just want to double-check.

    I'm assuming you're doing this step on the server, not remotely on the client? If so, are you running as a local administrator? I suspect that is the most likely cause.

    Thanks,

    John.

  • John,

    It is Martin yes (I still type looking at my fingers not the screen)

    the client is a Domain Vista Box and the Core server in a workgroup so I am trying to run the mmc from the snap in on the client this is when I connect the computer management snap in then browse to WMI, then when I right click it comes up access denied.

    as I am not very big on command line stuff (but trying to learn) it is very frustrating I have copied all 5 of the walkthrough's onto paper to get all the steps in the right order.

    Thanks in Advance

    Martin

  • Don't forget, you can also use RemoteApp on the 2008 server where hyper-v is installed. You can pubish both the vmconnect and the virtmgmt. My laptop is not part of the domain, and i have no problems connecting.

  • Hey Bev,

    Neat trick using RemoteApp, except for one problem:  Hyper-V Connect to Virtual Machine doesn't work with Terminal Services.  How did you resolve that?

  • Hi John,

    Thanks for the great series of articles on configuring machines to remotely manage Hyper-V!

    Using your articles as a guide, I figured out how to do the 6th scenario:  workgroup client talking to domain bound server.  Notes are here:  http://dannythorpe.com/2008/06/21/hyper-v-remote-management-workgroup-vista-client-to-domain-bound-server/

    -Danny

  • I'm trying to setup Hyper-V manager in a domain environment but I'm getting a slightly different error message to those you have covered here. When I open Hyper-V Manager on the client, I get the message:

    "Access denied. Unable to establish communication between 'CLIENT' and 'SERVER'."

    This appears in the Virtual Machines panel. The client and server are connect to the same unmanaged switch with no firewalls other than the window firewall in default configuration on both machines. My user is a local machine administrator on both machines (with UAC running). Other services such as remote desktop between the machines works without problems.

    I followed the steps in Part 4 of your guide, except for the WMI Control section, as when I inspected the settings the

    user already had the necessary access due to being a server local machine administrator.

    The two operations I can perform successfully in Hyper-V manager from the client are using the Hyper-V Settings and the Virtual Network Manager features, but everything else fails with the above message, usually at the end of a wizard.

    Thanks for any help you can offer.

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