Introduction:
One of the things that were missing less in Hyper-V is the capacity we had in Virtual Server to remotely manage and by VMRC to boot the virtual machine console in our team.
Hyper-V until now was not that capability and we had to connect to the server via remote desktop, start the virtual machines, which should in turn be configured for remote desktop, and now from the customer access via remote desktop virtual machines.
This scenario has changed since Microsoft has released a utility to remotely manage Hyper-V servers.
For 64 bits:
For 32 bits:
http://www.microsoft.com/downloads/details.aspx?familyid=BF909242-2125-4D06-A968-C8A3D75FF2AA&displaylang=en
connectivity problems, begin at this time.
connectivity problems :
· If your machine belongs to a domain and the domain server
have installed Hyper-V (or on another server belonging to the estate) and have an administrator account, then we have no problem.
· Problems arise in these scenarios:
1 - Workstation is not connected to the domain from which we manage
Hyper-V which is in the domain.
2 - Hyper-V on a standalone server and want to access from a workstation.
3 - Hyper-V installed on a Core Server and we manage it from remote.
In either case, it will be impossible, we will see a screen that indicates
not have permission, we contact the administrator to select policies
. But what policies? ... no such policy or
domain or as local settings when the server is standalone.
look at each case:
1. Workstation is not connected to the domain from which we manage Hyper-V which is in the domain.
Run steps 1) 2) 3) and 4) of section SERVER bottom.
Run steps 1) 2) 3) and 4) of section CUSTOMER lower.
If at any time requested credentials, use User / Pass the Dominion.
2. Hyper-V on a standalone server and want to access from a workstation .
Run steps 1) 2) 3) and 4) of section SERVER bottom.
Run steps 1) 2) and 3) of section CUSTOMER bottom.
3. Hyper-V installed on a Core Server and we manage it from remote
SERVER:
Run step 1)
Step 2) is not possible to be on a Core Server, but it contains a group "builtin"
called "Distributed COM Users". Therefore, we add the user who will access this group
:
net localgroup "Distributed COM Users" / add server \\ user
Step 3) we run it from remote. Therefore, in the remote machine (client)
open the Computer Management and right click on Computer com Management,
select "Connect to another computer ..."
In this way we can change Root \\ CIMV2 and Root \\ virtualization as
described in Section 3)
Step 4) should also do this from remote. To do this, from the remote machine:
net use * file: / / server / c $
azman.msc and then manage the XML with the remote server as described in this step
.. We have only one problem: azmna.msc not work correctly in remote
not find user (assuming you want to register
one in particular).
As workaround: Now we are editing (on backup) the
initialstore.xml and need to incorporate the user's SID. To understand it, this script can serve
:
strComputer = "." September
objWMIService = _
GetObject ("winmgmts: \\ \\ server \\ root \\ cimv2")
September
objAccount = _
objWMIService.Get
(Win32_UserAccount.Name = 'username', Domain = ' server '") Wscript.Echo
objAccount.SID
Notepad is not an XML editor and in this case, it would be convenient to use a freeware XML editor
of many that exist in the network.
IN THE SERVER
1. firewall on the server Set .
In a console run:
advfirewall netsh firewall set rule group = "Windows M anagement Instrumentation (WMI)" new enable = yes
is necessary to ensure that the command is successful and your answer must be that it has updated
4 rules.
NOTE: Quoted string must match the name of the group defined in the
own firewall. Therefore, if you are running a Windows in a language other than English
must first check in your firewall rules
name. (Administrative Tools, Firewall with Advanced Security.)
2. Configure DCOM on the Server . To configure the DCOM
we run the command "dcomcnfg" (without the quotes
). This sets the permissions and must be consistent with the rest of
actions on the following points in security. We can give permissions to a user
, a group of users, or to any authenticated user.
Right click "My Computer", Properties, and select the tab "COM
Security."
Select "Edit Limits" at the bottom. "Launch and Activation Permissions". Not to be confused with the top button of "Edit Limits". We'll see a screen with the groups / users and their permissions. Click the button "Add" (Add):
the user or group to which we give permission. In this ejmplo, we
add to the group "Authenticated Users" and on the next screen, mark
"Remote Launch" and "Remote Activation"
3. Assign permissions to WMI on Server .
Right click on Computer (Computer) and Manage. Locate the "WMI Control",
right click on it, properties and Security tab.
Notice the upper structure, we must update two keys in the same way: " CIMV2"
and "virtualization "
select the key, and click on the button "Security" below.
select the user or group, or add it (Add).
Once selected click the button "Advanced" and assign "Remote Enable".
We make three points here :
1. In "Apply to:" we should select "This namespace and subnamespaces"
2. Column Permission, select "Enable Remote."
3. Mark the checkbox below. "These Apply permissions to objects and / or containers Within this container only"
Repeat the above for other key Root \\ virtualization.
4. Set "Authorization Manager" in the server .
execute: "azman.msc" (without the quotes).
Right click on Authorization Manager and Open Authorization Store. Select "XML File
" and add:
% ProgramData% \\ Microsoft \\ Windows \\ Hyper-V \\ initialstore.xml
When opened, but to assign specific roles In this case we will give
all permissions to the group "Authenticated Users" is with which we are working
. To do this, navigate to "Role Assignments" and the right side,
right button to "Administrator" -> "Assign Users and Gropus" -> For Windows ans
Active Directory "and add the group" Authenticated Users ". It should be:
ON THE CUSTOMER
1. Configure firewall on the client .
In a console run:
advfirewall netsh firewall set rule group = "Windows Management Instrumentation (WMI)"
new enable = yes
comment Review of 1) in the Server with regard to language and content of the string
superior.
2. Allow Console (MMC) on the client firewall :
Create an exception in the firewall to the console:
Netsh firewall add allowedprogram program =% windir% \\ system32 \\ mmc.exe name = "Microsoft Management Console"
3. Give permissions to WMI on the client . WMI
server performs a callback to the client. It is normal and is not specific to Hyper-V
. If the server was in a working group from the server the DCOM
customer is "in limited liability."
therefore execute "dcomcnfg" locate "My Computer", Properties, tab "COM
Security" and in this case go to "Edit limits" in the upper
"Access Permissions".
add "ANONYMOUS LOGON" to the user list and mark the permissions in the area of \u200b\u200b
"Remote Access / Allow"
4. Set the credentials on the client.
console booted in normal mode ( do not high
mode: this is important!) Run:
cmdkey / add remoteserver / user: remoteserver \\ username / pass
The last option in the / user must be remoteserver \\ username to be username
the user on the remote machine.
Juan Barrios and Carlos Rovira.
