When Creating a New Resource or Role in Windows Server 2012 R2 Failover Cluster, the Network Name Fails to Come Online or Failed to Create Associated Computer Object in Domain
There is an issue I have seen repeatedly in the field since Windows Server 2012 and Windows Server 2012 R2 released. It typically surfaces when attempting to add roles to Windows Failover Cluster. Since my customers are large SQL shops, this issue typically surfaces when the server team hands off the Windows Server 2012 R2 Cluster nodes to the SQL team and the SQL team attempts to install SQL Server Failover Cluster and gets this:
Microsoft SQL Server 2012 Service Pack 1 Setup
The cluster resource ‘SQL Server’ could not be brought online due to an error bringing the dependency resource ‘SQL Network Name (SQLSHARE3VS)’ online.
Refer to the Cluster Events in the Failover Cluster Manager for more information.
If you check out the event logs, you’ll see the following:
Event ID: 1194
Source: Microsoft-Windows-FailoverClustering
Cluster network name resource 'SQL Network Name (SQLSHARE3VS)' failed to create its associated computer object in domain 'charity.contoso.com' for the following reason: Resource online.
The associated error code is: -1073741790
Please work with your domain administrator to ensure that:
- The cluster identity '2012SQL3FailoverCluster$' can create computer objects. By default all computer objects are created in the 'Computers' container; consult the domain administrator if this location has been changed.
- The quota for computer objects has not been reached.
- If there is an existing computer object, verify the Cluster Identity '2012SQL3FailoverCluster$' has 'Full Control' permission to that computer object using the Active Directory Users and Computers tool.
At this point, the SQL team (or even before this point) punts it back to the server team. The server team scratches their head, mumbles something about this working in Windows Server 2008 R2, and typically opens a case with Microsoft.
So what changed?
In Windows Server 2012 R2, we added a new feature that was high in demand. We now have the ability to specify an OU during Create Cluster Wizard. That way the Cluster Name Object (CNO) can be created in some OU other than the default Computers container. Additionally, if you move the computer objects for the servers to a different OU, when you create the Cluster, even if you do not specify an OU during creation, the CNO will be created in the same OU where the server computer objects reside instead of the default Computers container.
Let’s take a step back for a minute
What is the Cluster Name Object (CNO)? When you create a failover cluster by using the Create Cluster Wizard, you must specify a name for the cluster. If you have sufficient permissions when you create the cluster, the cluster creation process automatically creates a computer object in AD that matches the cluster name. This object is called the cluster name object or CNO. It is also what we use to administer the Cluster as a single unit. These can also be prestaged.
Great. So what’s the Virtual Computer Object (VCO)? The VCO is also a computer object that is automatically created when you configure any Cluster roles that have an associated client access point. A client access point is nothing more than an IP address and network name. Again, the network name is associated with a computer object in AD. For example, if you setup a file server and call the role FileServer1, you will have a computer object in AD directory called FileServer1. The CNO is responsible for creating these. When the CNO is automatically created, we assign it the appropriate permissions in order to be able to do so. If we’re prestaging or manually creating these, then we rely on the AD admin to follow the TechNet documentation and assign the appropriate permissions.
Most roles require a client access point. So most roles are going to have a corresponding computer object in Active Directory.
Let’s take a look at what this looks like in AD. My two servers that will be my two Cluster nodes are named Node1 and Node1. I probably should have used more descriptive computer names for my Cluster nodes, but whatever. I use the KISS principle in my lab environments…but even I must admit, that’s a little too simplistic. :-) After building them, per typical policy, I moved them from the default Computers container to the SQL OU as their end function will be SQL servers.
After installing the Failover Cluster feature on both nodes and running validation, I create my Cluster. At this point in the Create Cluster Wizard, I can actually specify an OU if I wanted to, but I’m just going to do what I see in the field and specify the Cluster name.
When I click Next and Finish, at this point, we form the Cluster and the CNO is created in Active Directory. So if I pop back over to my SQL OU, I see that my CNO followed the computer accounts for my two nodes and also resides in the SQL OU.
Notice the CNO is the same name I specified for the Cluster. Any roles I setup for this Cluster will have VCO objects created in this same location.
To summarize:
We create a computer object in Active Directory whenever we setup the Cluster. This is the CNO.
We create a computer object in Active Directory whenever we create a role that requires a client access point (most roles). This is the VCO.
VCOs follow the CNO. Whichever OU the CNO is in is where the VCOs will be created.
Crystal clear right? I hope so. This has been a confusing point for many of the classes I have taught and many of my customers, especially those that do not touch AD.
So what’s the problem?
By default whichever OU you move the CNO to does not have the appropriate permissions for the CNO to create the VCO and you’ll see the errors described at the beginning of this blog or you’ll simply fail to see the resource come online. On closer investigation, you’ll see the network name failed as shown below:
If you go look in Active Directory, you’ll notice that the computer object or VCO was never created for my MSDTC resource pictured above. There should be a VCO by the name of SQL1MSDTC, but no such object exists in AD. It was never created because the CNO did not have the appropriate permissions to create it.
But wait, I thought you said the CNO was automatically granted the permissions to create the VCOs?
Correct, that is the case. On the CNO itself, we give it the right permissions automatically. However, we change nothing at the OU level. In order for the CNO to create the VCOs in a custom OU, we either need to prestage the VCOs (see: https://technet.microsoft.com/en-us/library/dn466519.aspx for instructions on how to do so) or we need to grant the CNO permissions to Create Computer objects at the OU level.
To do this, we do the following (these are straight from the TechNet document linked above):
In Active Directory Users and Computers, on the View menu, make sure that Advanced Features is selected.
Right-click the OU where you created the CNO in Step 1: Prestage the CNO in AD DS, and then click Properties.
On the Security tab, click Advanced.
In the Advanced Security Settings dialog box, click Add.
Next to Principal, click Select a principal.
In the Select User, Computer, Service Account, or Groups dialog box, click Object Types, select the Computers check box, and then click OK.
Under Enter the object names to select, enter the name of the CNO, click Check Names, and then click OK. In response to the warning message that says that you are about to add a disabled object, click OK.
In the Permission Entry dialog box, make sure that the Type list is set to Allow, and the Applies to list is set to This object and all descendant objects.
Under Permissions, select the Create Computer objects check box.
After I do this, the next time I start my SQL1MSDTC role, everything comes online as expected.
If we peak at AD again, you can see the SQL1MSDTC VCO computer object is now created:
Why?
You might be wondering why we’re having to do this on Windows Server 2012 R2 when we didn’t with Windows Server 2008 and 2008 R2. The CNOs have always needed this right. However, 2008 and 2008R2 clusters created its objects in the default Computers container, even if the CNO was moved to a different OU, when you formed the Cluster, etc., it still defaulted to the default Computers container where every object has rights to create computer objects by default.
2012 and 2012R2 clusters create the objects in the same OU as where the nodes. For example, the SQL OU depicted above. Since it is not the default Computers container, then we have to add the rights separately. Neither has changed in the fact that the rights had to be there, it’s just everyone normally has rights to create in the default Computers container as a default, but do not have those permissions in custom OUs.
Now, obviously you don’t want to add each and every individual CNO for all the Clusters you create to the OU one at a time. The easiest method to solve this is to create a security group that has the Create Computer Objects permission at the OU level. When building a new Cluster, add the Cluster name (CNO) to the group. For example, I created a FailoverCluster security group and went through the same process to grant it Create Computer Objects permission on my SQL OU:
Cheers!
~ Charity “2012 R2 Clusters still rock!” Shelbourne