Article ID: 2779204 - View products that this article applies to.
Virtual Machines running on Windows Server 2012 Hyper-V hosts may fail to start and you may receive an error message that is similar to the following:
Error 0x80070569 ('VM_NAME' failed to start worker process: Logon Failure: The user has not been granted the requested logon type at this computer.)
Additionally, when you perform a live migration of a Hyper-V virtual machine, the live migration may fail and you may receive an error message that is similar to the following:
Failed to create Planned Virtual Machine at migration destination: Logon failure: the user has not been granted the requested logon type at this computer. (0x80070569)
Note: The issue may stop temporarily if an Administrator logs into the Hyper-V host and runs the following command:
This issue occurs because the NT Virtual Machine\Virtual Machines special identity does not have the Log on as a Service right on the Hyper-V host computer. Usually, the Virtual Machine Management Service (VMMS) replaces this user permission at every Group Policy refresh to ensure it is always present. However, you may notice that Group Policy refresh does not function correctly in certain situations.
Microsoft is currently investigating this issue to determine a root cause.
To work around this problem, first, use the output of the gpresult command to identify the Group Policy Object(s), which modifies user rights settings. Then, use one of the following methods to correct the issue:
Method 1Place the computer account for the Hyper-V Host in an Organizational Unit (OU) that does not have any policies applied, that manage user rights, and then run gpupdate /force command or reboot the computer. This should remove the user rights applied by policy and allow user rights defined in the local security policy to take effect.
Method 2Perform the following steps on the Hyper-V host machine:
Method 3Perform the following steps on a client computer running Windows 8 that supports the Client Hyper-V
Best Practices regarding Hyper-V Hosts
A Microsoft recommended 'best practice' for Hyper-V servers is to not install any additional Roles or Features that do not specifically support virtualization. As an example, in a Hyper-V Cluster, the Hyper-V Role and the Failover Clustering feature are installed to support highly available virtualized workloads. Hyper-V hosts play a critical role in an organizations' virtualization strategy. Microsoft recommends that the Hyper-V servers be managed in a separate OU in Active Directory (if they are domain-joined). Only group policies that apply specifically to Hyper-V host machines should be applied to this OU. This minimizes the risk of a policy conflict affecting the proper functioning in a Hyper-V host.
Best Practices regarding management of user rights, file system permissions, and registry permissions via Group Policy
Although you can manage user rights assignments, file system permissions, and registry permissions via Group Policy objects, the management interface available in Group Policy will overwrite any user rights, file system permissions, or registry permissions defined locally on the computer. Thus, you should always leverage these capabilities with caution, and insure that the group policy objects that set these items apply only to the computers that actually need these items. Since these items are not cumulative, any group policy object that applies user rights, file system permissions, or registry permissions must contain all security principals or service accounts that may be operating on the computers where the group policy objects apply.
Best Practices regarding the Default Domain Policy
The Default Domain Policy is leveraged programmatically by the operating system and maintains critical, domain-wide policies that can only be set in this policy object. Because of this, the Default Domain Policy should only be modified when absolutely necessary. To manage group policy settings for the entire domain, administrators should create new policy objects linked at the domain level. Whenever possible, policies should be applied at the OU level rather than the domain level, in order to insure that settings are applied only to the users and computers that require them.
(http://go.microsoft.com/fwlink/?LinkId=151500)for other considerations.