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
  • Paul - this error generally indicates you have not configured the DCOM settings on the client machine. See Part 2, step 7. That should resolve the issue.

    Thanks,

    John.

  • Thanks John, that was indeed the problem. Looks like that step is necessary in the domain scenario as well as the workgroup scenario.

  • John,

    Thanks for this.  Any help on what I believe to be an issue with connecting from a 32bit Vista client to the 64bit Hyper-V instance?  Connection works fine from x64 W2008 but get the usual 'Cannot connect to RPC service' error when trying to connect from 32bit Vista.

    Thanks,

    David

  • David - I'm not aware of an architecture specific issue and have certainly run through both in my lab environments. There are differences between Vista configuration and 2K8 configuration though. Are you sure you followed the client configuration which is absolutely needed for Vista - part two has most of that information. I think that will solve your problems.

    Thanks,

    John.

  • This is simple superb/.. Good Work

  • This is simple superb/.. Good Work

  • Thank's John for your research effort and for posting this information.

    I haven't tried all actions, but it would appear that the Hyper-V Manager is working from my Vista client.

    In Part 2 (Client configuration) step 7, you say that if the 2008 Hyper-V server is in a workgroup, it will use Anonymous access from the server to the client.

    I couldn't find anywhere what the situation is if both the Hyper-V server and the Client are both domain members in the same domain.  I enabled the anonymous access per your directions, but I'm wondering if this is necessary in an all domain situation.   Could you please clarify this for me?

  • Bruce - you are correct. If both machines are domain members in the same domain, anonymous callback does not need to be configured. You should be able to add the user account to the Distributed COM Users group for the callback.

    Thanks,

    John.

  • John,

    I've walked through your notes and they are absolutely wonderful - one thing that I ran into, and I can't find on anyone's blog is a good way of setting up the networking.  I'm running into the following situation:

    Server1 - Win2008, x64; 2 NICs (192.168.1.3 and 192.168.1.203)

    Computer1 - Vista SP1, x64

    Server1 has HyperV configured like your blog.

    Computer1 is configured like your blog.

    From Computer1, I can create a VM with no issue.

    However, the VM sees an unknown device (I'm certain it's the NIC, because there are no NICs installed).  I would have expected the VM to autodetect and install the NIC.  But it doesn't.  No errors.

    From the Hyper-V console on the Computer1, I selected the 192.168.1.3 to be the External NIC; and it's that NIC i use for the VM.

    Thoughts?  anyone?

  • Chris - the unknown device is probably VMBus. You need to install the Integration Services inside the VM for the synthetic devices to run. Once you are connected to the VM in VMConnect, select Actions/Insert Integration Services Setup Disk and let autoplay run inside the VM (or navigate to setup.exe on the virtual CD ROM inside the VM). Reboot the VM and everything should be good.

    Thanks,

    John.

  • Hi. Thank you in advance for reply :-). This is our situation: 1 new server 2008 core in the same lan of a domain (but not part of it). My NB (vista sp1) is in the domain. I'm able to connect to server with terminal server. After a lot of work (included the translation for the Italian localized version :-( ) I reach the end and it seems all ok. But finally when I connect with Hyper-v mmc to the server and try to create a VM I receive an error "unable to load the wizard page" (translation from italian) and even If I try to go away I'm not able to create any VM. Server is empty and has only 2008 core with hyper-v role installed. Any suggests ?

  • Matteo - you usually see this if you are running pre-release versions of the either the server or client. Please make sure you have KB950050 on the server and 952627 on the client - these are the RTM releases.  If the server is core, you should be able to use wmic qfe list to list the installed updates.

    Thanks,

    John.

  • Thank you again, it was the missing of KB950050 on the server. Now, finally, I'am creating the first VM. And now I can go home to take my deserved beer :-) bye

  • Howard, Thanks to your blogs I got Hyper-V Management with Management client (Vista SP1) and Hyper-V Server (W2K8 with KB950050) in same domain working. I installed my first VM, was able to connect to it and to take a snapshot.

    Suddenly after two days - out of nowhere - I'm not able to connect to the VM (though it shows up in Hyper-V Manager and also works as a DNS Server as expected). The snapshot loading takes place but doesn't complete und I'm not able to create new VMs or new VHDs. There is just a create bar that stays indefinetly.

    Any idea what went wrong in my case? Your help is highly appreciated because I don't know where to go from here. I did setup a second client for management (Vista SP1 as well) with exactly same result.

    Thanks,

    Werner

  • John, Thanks to your blogs I was able to set-up remote management of Hyper-V: Hyper-V Manager on Vista (x86) Business SP1 – W28K Enterprise Core with KB950050. I created, configured and snapshot a VM and was able to connect to that VM for about 2 days.

    Now, suddenly – out of nowhere – I cannot connect to that VM anymore. But the VM shows up in Hyper-V-Management and it is also working as expected (W2K8 Enterprise as DNS Server and File Server). At the same time it is impossible to create new VMs or VHDs (the process starts, but the progress bar stays indefinitely). The snapshot starts loading into the Manager, but loading doesn’t complete.

    I did set-up a Hyper-V-Manager on a second Vista SP1 client, yielding the same result.

    Do you have any idea how that problem can be solved? Any comment or suggestion is highly appreciated!!

    Werner

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