04 April 2008
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’
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.
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.
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'
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.
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.
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.
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.
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.
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).
And “Voila”
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
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
Comment Policy: No HTML allowed. URIs and line breaks are converted automatically. Your e–mail address will not show up on any public page.
