Part 1 - 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 

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

After the many emails I’ve had about this, it seemed only appropriate to write up a detailed post (or two actually) about how to resolve this.

You will hit this problem when using the Hyper-V Vista management tools connecting to a remote Windows Server 2008 machine with the Hyper-V role enabled, and where both machines are in a workgroup (or in a domain environment where you genuinely don’t have access - but that's another blog entry).

wg1
There are several additional configuration steps you need to complete to make remote management work in a workgroup environment.

Step 1 (On Client and Server)

Make sure you are using a username and password which matches between the client and the server. For this walkthrough, I created an account with the username “john” with the same password on both machines. The “john” account is not an administrator on the server machine, but is an administrator on the client machine (for convenience).

wg1a

Step 2A (On Server core installations)

See part 3 of this series

Step 2B (On Server full installations)
Enable the firewall rules on the server 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 is successful and responds Updated 4 rules(s). Ok.

wg2 

Note: The string in quotes must match the group name defined in the Windows firewall itself. So if you are running a non-English language server, you will need to verify what group name this is.

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

wg3

wg4 

Step 3 (On Server)

This step grants appropriate DCOM (Distributed COM) permissions to the user(s) who are remotely connecting. Depending on your circumstances, you can add the individual users (they must obviously have an account already on the server), a group, or you can allow all users by select the “Authenticated Users” group.

Open Component Services by typing “dcomcnfg” in the box on the start menu, and expand the menu so that “My Computer” is selected under Component Services\Computers.

wg5 Thumbnail

wg6

Right-Click on My Computer, select Properties and select the “COM Security” tab.

wg7
In the above dialog, click Edit Limits in the “Launch and Activation Permissions” area (not to be confused with the Edit Limits in the “Access Permissions” area).

wg8

Click “Add…” and enter the users (or groups including “Authenticated Users” as appropriate)

wg9

Click OK, then select the added user or group

wg11
In the Allow column, select Remote Launch and Remote Activation, then click OK.

wg12

Close Component Services

Step 4 (On Server)

This step grants appropriate WMI permissions to the user(s) who are remotely connecting. You need grant access to two namespaces, and, as in step 3, you can add individual users, group(s) or the “Authenticated Users” group.

Open Computer Management under Start/Administrative Tools, expanding the tree down through Services and Applications\WMI Control. Select WMI Control

wg13

Right-click on WMI Control and select properties. Then switch to the Security tab. Select the Root\CIMV2 namespace node.

wg14

IMPORTANT: You need to set the security twice. Once for the Root\CIMV2 namespace, and then again for the Root\virtualization namespace.

Click the Security button. If the appropriate user or group does not already appear, use “Add…” as you did in Step 3 above to add them.

wg15

Now select the user and click the Advanced button below the “Permissions for <user>” area.

wg16

Again, make sure the user/group is selected and click Edit

wg17

You need to make three changes here:

  • In the “Apply to:” drop-down, select “This namespace and subnamespaces”
  • In the Allow column, select Remote Enable
  • Check “Apply these permissions to objects and/or containers within this container only”

The screen should look like below. If so, click OK through the open dialogs.

wg18

Repeat for the Root\virtualization namespace

wg19

Click OK as appropriate to confirm all open dialogs and close Computer Management.

Step 5 (On Server)
This step configures the Authorization Manager (AZMan) policy for the server running the Hyper-V role. I am assuming in this walkthrough, you are using the in-box default policy and have not re-configured anything at this stage.

Open Authorization Manager by typing “azman.msc” in the box on the start menu.

wg20

wg21

Right-click on the Authorization Manager and choose Open Authorization Store from the context menu.

wg22

Make sure the “XML file” radio button is selected, and browse to the \ProgramData\Microsoft\Windows\Hyper-V directory on the system drive and select InitialStore.xml, then click OK.

wg23

I’m going to keep this walkthrough as simple (!) as possible, and making my “john” account an Administrator in the context of Hyper-V authorization policy. Expand the tree down through InitialStore.xml\Hyper-V services\Role Assignments\Administrator, and select Administrator.

wg24
In the area on the right, right-click and select “Assign Users and Groups” then “From Windows and Active Directory…”.

wg25

Add the appropriate users or groups (here you can see the “john” account)

wg26
Close the Authorization Manager MMC.

IMPORTANT. You must now reboot your server for the above changes to take effect.

In part 2, I'll walk through the client configuration steps.

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

Cheers,
John.