SQL Server Cluster Network Name Resource ‘SQL Network Name’ Failed Issue

Issue
Today will discuss about the issue that I’ve encountered during performing an installation of a SQL Server failover cluster is “The cluster resource ‘SQL Server (MSSQLSERVER)’ could not be brought online due to an error bringing the dependency resource ‘SQL Network Name (MSSQL2012)’ online.” Upon checking the cluster events in the Failover Cluster Manager, you will find the below error.

Cluster network name resource 'SQL Network Name (MSSQL2012)' 
failed to create its associated computer object in domain 'ENTERPRISE.ORG' for the following reason: 
Resource online.
The associated error code is: -1073741790
Please work with your domain administrator to ensure that:
- The cluster identity 'WIN2012$' 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 ' WIN2012$' has 'Full Control' permission to that computer object 
using the Active Directory Users and Computers tool.

Lets first understand, what is Cluster Name Object (CNO)?
In a Windows Server Failover Cluster, a cluster name object (CNO) is an Active Directory (AD) account for a failover cluster.

A CNO is automatically created during cluster Setup. When the administrator creates a failover cluster and configures clustered services or applications, the "Create Cluster Wizard" creates all the Active Directory computer accounts the failover cluster requires and gives each account specific permissions. The wizard also creates a computer account for the failover cluster itself; this account is called the cluster name object.

The CNO is important because other accounts are created through it. If the CNO is deleted or permissions for the account are changed, other computer accounts required by the cluster can't be created until the CNO and correct permissions are restored.

Beginning with Windows Server 2012, both the Create Cluster Wizard and the PowerShell cmdlet New-Cluster allow administrators to decide which organizational unit (OU) should contain the CNO.

There are basically two solution of this problem:

1. One resolution is a preventative action that can be done prior to beginning the installation of the SQL Server Failover Cluster, and
2. Second resolution is after the issue experienced during installation to be able to continue.
Both resolutions require access and permissions to AD.

Resolution
1. The resolution that will prevent this issue on future installations is to “pre-stage” the VCO.

- Log in as a user with permissions to create computer objects in the domain.
- Under Active Directory Users and Computers, create a “New Computer” object within the desired AD Container for the VCO (this will be your SQL Server Network Name).
- Once the object has been created, you can then add the CNO (this will be your WSFC Name) to the security of the VCO with “Full Control” over the VCO.

2. To achieve the resolution that will be reactive for your current errors, you need to grant the proper permissions to the CNO.

- Log in as a user with administrative permissions in the domain.
- Under Active Directory Users and Computers, grant the CNO (this will be your WSFC Name) “Create Computer Objects” permissions.

After doing this, you can retry your previously failed installation, and it should be successful. To verify if this issue was corrected, you can navigate within the SQL Server (MSSQLSERVER) Cluster group and attempt to bring the Server Name resource online.
If the resource is able to be brought online successfully and thats it!!

SQL Server Agent Missing Issue in Windows Failover Cluster

Issue
Today I'm going to share my experience which I've faced last week while installing SQL Server 2012 on a Windows Server 2008 R2 Failover Cluster. All SQL Server component got installed but it shows failed in the last. On further investigation, that happened due to CNO permission Issue. SQL Server cluster name was not created within AD, and Windows failover cluster name doesn’t possess the required permissions to create the object.

Here is the error:

The cluster resource ‘SQL Server (ClusterName)’ could not be brought online
 due to an error bringing the dependency resource ‘SQL Network Name(ClusterName)’ online.
 Refer to the Cluster Events in the Failover Cluster Manager for more information.

Once granted the proper permission then SQL Server cluster resource group was successfully brought online. Then noticed that the SQL Server Agent was not listed as a resource type under the Other Resources section of the cluster resource group.

Now here is the actual blog starts,
How do I manually add the SQL Server Agent to the cluster resource group?

You will also not be able to see the SQL Server Agent on the Other Resources section of the SQL Server cluster resource group means that it has not been created successfully. You can verify this by trying to add a new resource in the clustered resource group, that will not be listed in it.

Resolution:
Manually add the SQL Server Agent resource type to the SQL Server cluster resource group
Step 1 : Create the SQL Server Agent resource type

Using cmd prompt execute below command:

cluster.exe restype "SQL Server Agent" /create /DLL:SQAGTRES.DLL

Step 2 : Add the SQL Server Agent resource to the SQL Server Cluster Resource Group.

Using the Failover Cluster Manager, right-click on the SQL Server cluster resource group
select Add a resource -> More resources ... -> A - Add SQL Server Agent

Step 3 : Set the private properties of the SQL Server Agent resource.

We need to assign the VirtualServerName and InstanceName properties of the SQL Server Agent resource to match those of the SQL Server resource.

Using the Failover Cluster Manager, double-click the SQL Server Agent resource to open up the Properties window. Click on the Properties tab to display the VirtualServerName and InstanceName properties. Enter the appropriate values for the properties and click OK.

Step 4 : Add the SQL Server resource as a dependency for the SQL Server Agent resource you just created. Then add the SQL Server service as a dependency to the SQL Server Agent service as in a stand-alone instance.
Using the Failover Cluster Manager, click on the Dependencies tab of the SQL Server Agent Properties dialog box and select SQL Server under the Resource drop-down list. Click OK.

Step 5 : Modifying SQL Server registry keys

Having an incomplete or corrupted SQL Server installation also means that there are registry keys that have not been properly written or updated. It is important to backup your registry prior to performing these tasks.
5.1. Open the Registry Editor and navigate to the following registry hives.

For default instance:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\ConfigurationState

For a named Instance
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft Microsoft SQL Server\MSSQL10_50.INSTANCENAME\ConfigurationState

5.2. Check the values of all the registry keys. If the value is greater than 1, it means that there was a failure either during the installation or configuration phase while running the setup process. In my environment, all of the registry keys have a value of 2.

5.3. Change all of the registry key values to 1.

Step 6 : Run a Repair of the SQL Server 2008 R2 installation

After all of the ground work has been done, you can now perform a repair of the SQL Server instance. To do this, run the setup.exe from the SQL Server 2012 installation media and click the Maintenance link on the left-hand side. You can then click the Repair link to run the repair process.

Restart SQL Server Services and Thats it!!