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:
Place 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.
Perform the following steps on the Hyper-V host machine:
Logon as a Domain Administrator
Install the Group Policy Management feature from the Server Manager console
After installation, open the GPMC MMC snap-in and browse to the policy that manages User Rights
Edit the policy to include NT Virtual Machine\Virtual Machines in the entries for Log on as a Service
Close the policy editor and initiate a gpupdate /force on the Hyper-V host computer to refresh policy. (You may need to wait several minutes for Active Directory replication to occur).
Perform the following steps on a client computer running Windows 8 that supports the Client Hyper-V feature:
Logon as a Domain Administrator
Install the Client Hyper-V feature
Install the Windows 8 Remote Server Administration Tools (RSAT)
Open the Group Policy Management console and browse to the policy that manages User Rights
Edit the policy to include NT Virtual Machine\Virtual Machines on the entries for Log on as a Service user right
Close the policy editor on the client
Initiate gpupdate /force on the Hyper-V host to refresh policy. (You may need to wait several minutes for Active Directory replication to occur).
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.