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

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

Part 4. Domain joined environment: 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 4. Domain joined environment: 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 78
  • Likes

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 

So after even more feedback and questions, part 4 of this series provides the walkthrough steps necessary to perform Hyper-V remote administration in a domain joined environment.

For reference:

  • Part one is the server configuration for a full server installation in a workgroup environment
  • Part two is the client configuration for parts one and three
  • Part three is the server configuration for a server core installation in a workgroup environment
  • Part four, this post, contains the relevant bits from parts two and three as applicable to deploying remote management of Hyper-V in a domain environment
  • Setting up and the pre-requisites for Hyper-V on server core are in this post.
  • More information on server core commands is here

Follow the same steps for setting up the server core box itself as before, but remember to join the machine to the domain by using netdom join <computername> /domain:<domainname> /userd:<domain user> /passwordd:*. Don't forget to enable remote administration.


dom1
Let’s first logon as domain administrator on the Vista machine and connect to the remote machine using Hyper-V Manager. As you can see, that works fine.

dom2

Obviously running as domain administrator isn’t a practical option in anything but a contrived lab environment. So I’ve created a standard user account in the domain called “domainuser” who is not an administrator either in the domain, the server core box with the Hyper-V role enabled, or on the Vista machine. Let’s see what happens when I start Hyper-V Manager on the Vista machine targeting the remote server core box. As you can in the screenshot below, it indicates that I am unauthorized. This is expected at this stage.

dom3 

Step 1 Authorization Manager configuration

I need to authorize the domain user account for operations on the Hyper-V server, the same as I did in the workgroup environment. This is easier if I use an administrative account on the remote server core machine. For simplicity, I’m going to log back on to the Vista machine as domain administrator and run configure the Hyper-V authorization policy. (Note in the real world, you don't need domain administrator - this is for simplicity in the walkthrough only).

Logon to the Vista machine as Domain Admin and click start/run AZMan.msc.

dom4 

dom5
Now open InitialStore.xml from the %systemdrive%\programdata\microsoft\windows\Hyper-V directory on the remote server machine. Right click on Open Authorization Manager and select Open Authorization Store…

dom6

Select XML and enter the path to InitialStore.xml (or browse to it, noting that the programdata directory is hidden).

dom7 

Expand the tree through Hyper-V services\Role Assignments\Administrator and select “Administrator”. Note that I’m making this walkthrough as simple as possible by making the domain user an administrator in the context of being able to perform all operations on the machine running the Hyper-V role. This does not however mean that the domain user becomes, or needs to be a local administrator on the Hyper-V machine (or on the Vista machine).

dom8 

In the right-hand side of the window, right click and select Assign Users and Groups then From Windows and Active Directory….

dom9

Select the domain user account and click OK.

dom10 

dom11 

You can now close Authorization Manager

Step 2 DCOM Configuration

Again, this is similar to the configuration steps necessary in the workgroup environment. You need to grant the appropriate users access rights to remote DCOM on the server. Use the same steps as in the workgroup configuration and add those users to the Distributed COM Users group.

On the Vista machine logged on with an account with administrative rights on the server core machine, click start/control panel/administrative tools/computer management.

dom12 

Remember in the server core configuration steps, I allowed remote management to enable this to work. If you get an error - go back to the server core configuration steps (links at top of this post). Right Click on the top of the tree on the “Computer Management (Local Computer)” node and click Connect to another computer…

dom13

Enter the name of the remote server (jhoward-hp2 in my walkthrough)

dom14 

Expand the tree down through Computer Management/System Tools/Local Users and Groups/Groups and select Distributed COM Users on the right hand side.

DOM15 

Double click on "Distributed COM Users", click Add… and select the appropriate users (domainuser in my walkthrough), and click OK.

dom16 

Step 3. Remote WMI

This step is the same as the configuration steps necessary in the workgroup environment. You need to allow the domain user account access to the Root\CIMV2 and Root\virtualization namespaces. While Computer Management is still open from Step 2, expand out Services and Applications and select WMI Control.

dom17

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

dom18 

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 2 above to add them.

dom19 


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

dom20 

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

DOM21 

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.

dom22 

Repeat for the Root\virtualization namespace

dom23

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

After completing this step, reboot your server for the changes you made in step 2 to take effect.

Step 4. Test it out

I logged back onto the Vista machine using the test domain user account. I started Hyper-V Manager and targeted jhoward-hp2, the remote server core machine. I then created a new virtual machine with all default settings, except selecting to add a virtual hard disk later. I started the virtual machine and connected to it. And as you can see in the screenshot below, the virtual machine is up and running (the boot failure message is expected as there’s no bootable media in the virtual machine).

Cool!

DOM24 

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
  • Again, I can't thank you enough for taking the time to find a solution for this problem. However, it is still not working for me. I got through steps one and two without any problems and then hit a snag at step three. When I go to the WMI Control Security Tab all I can see it the Root namespace, nothing below it, not even after I expand it. This shouldn't really matter because my domain user is part of the Local Administrators group on my Server Core install and that group is given full control over all of WMI by default. I am really at a complete loss here, it should be working just fine. I haven't been able to see if I can manage it from a full Server 08 install using its Hyper-V Manager so that is what I am going to have to try next.

    Thanks,

    Ryan Lenkersdorfer

  • Ryan - you have enabled remote management on the server core box? I suspect that is the most likely cause.

    Thanks,

    John.

  • I am able to remotely manage everything else but Hyper-V. I have enabled all the firewall rules that exist for WMI and remote administration in general on both the client and the server, still nothing. Is there some specific command that you had in mind?

    Thanks,

    Ryan

  • Ryan - yes, these two specifically:

    netsh advfirewall firewall set rule group=”Windows Management Instrumentation (WMI)” new enable=yes

    and

    netsh advfirewall firewall set rule group=”Remote Administration” new enable=yes

    It's also possible that you're getting domain policy being pushed down for the firewall. Of that though, I can't comment on what's present, but it is possible you are being blocked by it.

    Thanks,

    John.

  • I ran both commands, I am pretty sure I have ran them in the past as well, but it said it updated a few rules. I also went though our Group Policies and removed all policies regarding the firewall config on the server. I then ran a gpupdate on the server and restarted it. I then ran gpresult to make sure it wasn't applying anything else and tested it. Nothing. I am not sure what in the world could be wrong now. Clean install of Server 2008 Datacenter Server Core x64 with nothing else running on it. Clean install of Vista Business SP1 x64. Both on the same domain (Windows 2000 level domain if that matters), both have my domain user added to their Local Admin groups. I also get the same error if I point the Management Console at another server running Hyper-V Beta. Disabling the firewall on both client and server does nothing. It just doesn't make any sense.

    Thanks,

    Ryan

  • Ryan.  Hmmmm. This seems a little odd. So first off, I'd rule out pointing a Vista SP1 RC0 Hyper-V management box at a beta Hyper-V server. That is destined for failure as there are several WMI changes between Beta and RC0. The firewall disabling similarly I can probably rule out as this is WMI/DCOM permissions most likely. I could believe there could be discrepancy between Business and Enterprise Vista (I know of one issue, but that should have been resolved in RC0) - I was using Enterprise.

    There is one clear difference - my test domain is at 2K8 functional level, with only a single 2K8 DC in the picture.

    So you are saying that when you go into Start/COntrol Panel/Administrative Tools/Computer Management and target the remote Hyper-V RC0 box, you can, for example, add local users in System Tools\Local Users and Groups, or view the event log, or stop/start services under Services and Applications\services just cannot get to enumerate the WMI namespaces under Services and Applications\WMI Control?

    It makes no sense that _just_ WMI Control would not be working remotely (at least no sense that I can make of it). Can you confirm you have access remotely to the other examples?

    Thanks for your patience!

    Cheers,

    John.

  • I have just verified that I can remotely manage anything but WMI security using Computer Management on my Hyper-V RC0 box. When I open the security tab in WMI Control I see Root with a plus sign next to it. When I click on the plus sign to expand root it waits a second and then the plus sign disappears, nothing else happens. I have left it open like this for a good 5 min now and still nothing. I also know that there is a command line tool available in server core to manage WMI. It is a very complex tool and I have been unable to find good documentation on it so far. I am going to try to find out how to make the WMI security changes using that tool so I can bypass this remote WMI control problem since it is not my primary problem right now.

    Thanks,

    Ryan

  • I am sorry, I forgot to mention that the WMI command line tool is wmic.exe.

    Thanks,

    Ryan

  • HI John,

    Although I don't have a domain-joined Core+Hyper-V setup, I have the exact same issue - I can start and stop services via Computer Management on my Vista SP0 machine, yet I have no namespaces under Root in WMI Control.  (I also posted this, or similar, at the end of Part 3, but since Ryan's issue above is almost identical to my issue, I thought it only sensible to tag along in here instead.  :)

  • Ryan/Hilton - can you both please confirm the details of the account you are running step 3 in. If you have the opportunity, can you confirm if you can expand the namespaces when logged on as "the" domain admin. If that is not possible, please confirm you are running this as a _domain_ user account which has local administrative rights on both the vista and remote server core machines, and not a local account.

    One other interesting thing would be to run wbemtest on the Vista machine and attempt to connect to \\remoteserver\root\cimv2 and \\remoteserver\root\virtualization. Does that succeed, or do you get an access denied error?

    Thanks,

    John.

  • Hi John,

    OK.  To test this, since the Core+Hyper-V in my network is not and will never be domain-joined (no sense if one of the guests is the AD controller), I created a CoreAdmin account on a laptop running Vista SP1+RSAT+Hyper-V Management Tool which is a local admin, the same as on the Core box (CoreAdmin is a local admin).  This is the laptop I take with me to onsites and use for tech work.

    I can successfully connect via RDP to the Hyper-V machine and I can successfully connect to it using "net use \\qrk01hyperdev", so I know the username and password are identical on both machines.

    When I try to connect to Computer Management via the laptop, I get "Error 5: Access is denied" if I try to look at the Hyper-V server's services and in WMI Control it reports that it Failed to connect to \\qrk01hyperdev because "Win32: Access is denied."'

    So, this is getting curioser and curioser - why can I *almost* connect using my desktop with Vista SP1 + RSAT + Hyper-V Management Tool but I cannot even get that close using my laptop with Vista SP1 + RSAT + Hyper-V Management Tool?

    This maketh absolutely no sense to me!

  • ... and as to the wbemtest test, I can connect to both cimv2 and virtualization without errors, but past that, I'd not know what to do to know that these have actually connected properly.

    So, as for not getting errors saying access is denied, it seems that this works fine.

  • Okay, I have verified that I am running a true domain user and that the user has been added to the local administrators group on both the Vista machine and the remote server core machine. I do not have the ability to log in as 'the' domain admin but I have verified the above information.

    I also used wbemtest and was able to connect to both namespaces without issues.

    Thanks again for you help!

    -Ryan

  • Here are the results of "net localgroup Administrators" ran on both machines:

    Remote Server Core Machine:

    C:\Users\scs!admin>net localgroup Administrators

    Alias name     Administrators

    Comment        Administrators have complete and unrestricted access to the computer/domain

    Members

    -------------------------------------------------------------------------------

    AD\Domain Admins

    AD\rdlenk

    Administrator

    The command completed successfully.

    Vista Workstation:

    C:\Users\rdlenk>net localgroup Administrators

    Alias name     Administrators

    Comment        Administrators have complete and unrestricted access to the computer/domain

    Members

    -------------------------------------------------------------------------------

    AD\Domain Admins

    AD\rdlenk

    Administrator

    The command completed successfully.

  • Our domain here is "AD" and both computers are joined to it. My domain username is AD\rdlenk, so it is defiantly added to both admin groups and it is defiantly a domain account.

    Thanks,

    Ryan

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