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

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


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.


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)



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


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

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


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


Click OK, then select the added user or group

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


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


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


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.


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


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


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.


Repeat for the Root\virtualization namespace


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.



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


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.


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.

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


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

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