MIM LAB6: The AD MA and Run profiles

This post is part of a series. The chapter index is located here.

In this lab we will configure the firs AD management agent and set up run profiles.

Continue reading “MIM LAB6: The AD MA and Run profiles”

MIM LAB5: The MIM Service / Portal Management Agent

This post is part of a series. The chapter index is located here.

In this post we will install and configure the MIM Portal / Service management agent.

Continue reading “MIM LAB5: The MIM Service / Portal Management Agent”

MIM LAB 4: Installing the MIM Portal / MIM Service

This post is part of a series. The chapter index is located here.

In this post we install and configure the MIM Portal / Service.

Be aware that I had to make some changes to things I did in previous labs to make this work. I hope I have included all the details, but I have yet to re-run a complete install to test it. Continue reading “MIM LAB 4: Installing the MIM Portal / MIM Service”

MIM LAB 2: Preparing the first MIM server

This post is part of a series. The chapter index is located here.

In this post we:

  • Create the first MIM VM and join it to AD
  • Install prerequisites
  • Set Local security policies
  • Change IIS authentication mode
  • Install SQL Server
  • Install and configure Sharepoint Foundation Services 2013

Continue reading “MIM LAB 2: Preparing the first MIM server”

MIM LAB 1: Prepare a domain controller

This post is a part of a series. The chapter index is located here.

We will look at:

  • Installing ADDS
  • Creating a domain
  • Configuring DNS
  • Creating a basic OU structure
  • Creating users and groups required for the MIM installation

Continue reading “MIM LAB 1: Prepare a domain controller”

Event 20501 Hyper-V-VMMS

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.

image

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.