Revision #5

You are currently reviewing an older revision of this page.
Go to current version
This topic is a work in progress
This is community content being developed for the TechNet Wiki. Feel free to contribute.

If you use System Center Virtual Machine Manager (VMM) to manage Hyper-V hosts, you will need to use delegated administration in VMM to configure the permissions that you had assigned through your Hyper-V role definitions.

VMM uses its own role-based security to authorize operations performed on virtual machines. In addition to the Administrator user role, this includes Delegated Administrator user roles, which enable almost all management tasks within the host groups and library servers defined by the role’s scope. You also can create self-service user roles, which define a set of specific operations that users can perform on their own virtual machines within a restricted environment. For more information about VMM user roles, see Role-Based Security in VMM.

Hyper-V security is based on Authorization Manager API (known as AZMan). Similarly to VMM’s delegated administration model, an administrator can configure a set of role objects and assign Active Directory user and group accounts to those roles. Each role can be granted a set of permissions for virtual machine access and management, and securable objects can be assigned to scopes, which determine the objects against which access checks are performed. When a Hyper-V host is added to VMM, VMM applies its own authorization layer, defined by the VMM user roles, to determine the actions that VMM administrators and self-service users can perform on the Hyper-V virtual machines while working in VMM. To do this, VMM creates its own AZMan authorization store on the host computer. In VMM 2008 R2, the method for implementing user roles in AZMan was changed to preserve role definitions and role memberships in the root scope of the Hyper-V authorization store while VMM is managing a Hyper-V host. In VMM 2008, the Hyper-V roles are not used while a host is managed by VMM.

Authorization for Hyper-V Virtual Machines in VMM 2008 R2

VMM 2008 R2 preserves changes to role definitions and role memberships in the root scope of the Hyper-V authorization store. The VMM agent overwrites all changes to other scopes. As a result, while a Hyper-V host is managed by VMM 2008 R2, access is determined by the union of all roles in the root scope plus the VMM role assigned to each virtual machine’s scope.

VMM 2008 R2 makes the following changes to authorization stores during agent installation on a Hyper-V host:

  1. VMM creates its own AZman authorization store—HyperVAuthStore.xml, stored in the folder %ProgramData%\Microsoft\Virtual Machine Manager—which will store the roles and memberships that are used to authorize virtual machine access and management through VMM.
  2. VMM updates the registry entry HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization on the Hyper-V host to point Hyper-V to the VMM authorization store.
  3. VMM imports any user roles and role memberships in the root scope of Hyper-V’s initialstore.xml authorization store into the VMM authorization store.

After VMM agent installation, the VMM user role refresher overwrites any changes to scopes other than the root scope every half hour. However, VMM preserves any role definitions and memberships that subsequently are added to the root scope.

When a Hyper-V host is removed from VMM 2008 R2, instead of pointing Hyper-V back to initialstore.xml, VMM saves a copy of the VMM authorization store on the Hyper-V computer, removes all user roles and scopes that were defined in VMM from the copy, and then points Hyper-V to that store.

Authorization for Hyper-V Virtual Machines in VMM 2008

When a Hyper-V host is added to VMM 2008, VMM creates its own authorization store without importing any role and membership settings from initialstore.xml on the Hyper-V computer, and then updates the registry so that Hyper-V points to the VMM authorization store.

VMM 2008 does not modify the existing Hyper-V role definitions; it simply ignores them. When a Hyper-V host is removed from VMM 2008, the registry is updated to point Hyper-V back to the original Hyper-V authorization store.

Note   In a Hyper-V environment, the pre-release version of VMM 2008 R2 does not support the use of shared ISO image files when creating Hyper-V virtual machines. By default, when an ISO image file is added to a drive on a virtual machine, VMM attaches a copy of an ISO image file to the virtual machine instead of sharing the image file. In the pre-release version of VMM 2008 R2, if a user instead chooses the Share image file instead of copying it option on a Hyper-V virtual machine, the operation will fail.

See Also


Revert to this revision