Problem
The following event is logged non-stop in the Hyper-V High Availability log:
Log Name: Microsoft-Windows-Hyper-V-High-Availability-Admin
Source: Microsoft-Windows-Hyper-V-VMMS
Date: 27.07.2017 12.59.35
Event ID: 20501
Task Category: None
Level: Warning
Description:
Failed to register cluster name in the local user groups: A new member could not be added to a local group because the member has the wrong account type. (0x8007056C). Hyper-V will retry the operation.
Analysis
I got this in as an error report on a new Windows Server 2016 Hyper-V cluster that I had not built myself. I ran a full cluster validation report, and it returned this warning:
Validating network name resource Name: [Cluster resource] for Active Directory issues.
Validating create computer object permissions was not run because the Cluster network name is part of the local Administrators group. Ensure that the Cluster Network name has “Create Computer Object” permissions.
I then checked AD, and found that the cluster object did in fact have the Create Computer Object permissions mentioned in the message.
The event log error refers to the cluster computer object being a member of the local admins group. I checked, and found that it was the case. The nodes themselves were also added as local admins on all cluster nodes. That is, the computer objects for node 1, 2 and so on was a member of the local admins group on all nodes. My records show that this practice was necessary when using SOFS storage in 2012. It is not necessary for Hyper-V clusters using FC-based shared storage.
The permissions needed to create a cluster in AD
- Local admin on all the cluster nodes
- Create computer objects on the Computers container, the default container for new computers in AD. This could be changes, in which case you need permissions in the new container.
- Read all properties permissions in the Computers container.
- If you specify a specific OU for the cluster object, you need permissions in this OU in addition to the new objects container.
- If your nodes are located in a specific OU, and not the Computers OU, you will also need permissions in the specific OU as the cluster object will be created in the OU where the nodes reside.
See Grant create computer object permissions to the cluster for more details.
Solution
As usual, a warning: If you do not understand these tasks and their possible ramifications, seek help from someone that does before you continue.
Solution 1, low impact
If it is difficult to destroy the cluster as it requires the VMs to be removed from the cluster temporarily, you can try this method. We do not know if there are other detrimental effects caused by not having the proper permissions when creating the cluster.
- Remove the cluster object from the local admin on all cluster nodes.
- Remove the cluster nodes from the local admin group on all nodes.
- Make sure that the cluster object has create computer objects permissions on the OU in which the cluster object and nodes are located
- Make sure that the cluster object and the cluster node computer objects are all located in the same OU.
- Validate the cluster and make sure that it is all green.
Solution 2, high impact
Shotgun approach, removes any collateral damage from failed attempts at fixing the problem.
- Migrate any VMs away from the cluster
- Remove the cluster from VMM if it is a member.
- Remove the “Create computer objects” permissions for the cluster object
- Destroy the cluster.
- Delete the cluster object from AD
- Re-create the cluster with the same name and IP, using a domain admin account.
- Add create computer objects and read all properties permissions to the new cluster object in the current OU.
- Validate the cluster and make sure it is all green.
- Add the server to VMM if necessary.
- Migrate the VMs back.
