SQL Availability Group Listener creation fails

Question

I'm having trouble creating an availability group listener for my newly created SQL 2012 Enterprise AG.

My AG resides on two virtual machines on top of Server 2012 Datacentre with the Hyper-V role. The VM's are part of my domain, and in a WSFC. Each VM has 4 subnets :

• (a) 172.33.0.x for management
• (b) 172.33.1.x for iSCSI communication
• (c) 172.33.2.x for iSCSI communication
• (d) 172.33.5.x for inter-VM communication

Only (a) and (d) are set in my cluster to allow cluster communication, and allow client connections.

Whenever I try to create a listener with this query

USE [master]
GO
ALTER AVAILABILITY GROUP [Sharepoint-System-DB-AvailabilityGroup]
ADD LISTENER N'SQL-SHP-AG01-L1' (
WITH IP
((N'172.33.5.203', N'255.255.255.0'),(N'172.33.0.203', N'255.255.255.0'))
, PORT=1433);
GO

I get this error :

Msg 19471, Level 16, State 0, Line 1
The WSFC cluster could not bring the Network Name resource with DNS name 'SQL-SHP-AG01-L1' online. The DNS name may have been taken or have a conflict with existing name services, or the WSFC cluster service may not be running or may be inaccessible. Use a different DNS name to resolve name conflicts, or check the WSFC cluster log for more information.
Msg 19476, Level 16, State 4, Line 1
The attempt to create the network name and IP address for the listener failed. The WSFC service may not be running or may be inaccessible in its current state, or the values provided for the network name and IP address may be incorrect. Check the state of the WSFC cluster and validate the network name and IP address with the network administrator.

I've tried :

• Some online posts suggest I try and pre-stage the creation of the computer object in AD, which I did, same error
• Set security settings on the Computer OU to allow the computers running the AG to create computer objects, same error
• I have another cluster setup (for another AG), that also generates the same error

Something that might be related is, I regularly get one of the following errors on the owner node of the cluster :

Cluster network name resource 'Cluster Name' failed registration of one or more associated DNS name(s) for the following reason:
DNS server failure.

For this, I've tried :

• Creating the A record manually, setting the "Allow all authenticated users to change this record"
• Allowing "Everyone" full access to the DNS A record
• Allowing non-secure updates to my domain's DNS records

Also to no avail, which makes me think there's something deeper wrong. Any suggestions?

Dysphoria

Answer 1

We had the same problem. Resolution was to grant the computer object associated with the cluster group 'create computer' rights in Active Directory as per this link - http://technet.microsoft.com/en-us/library/cc731002%28WS.10%29.aspx#BKMK_steps_precreating

It's the cluster group computer object thats needs these permissions.

Extol

Might be pertinent to mention that the Listener computer object is created in the same OU as the Cluster computer object. – Dysphoria

Answer 2

Open Active Directory Users and Computers, grant permission to the Cluster Name Object (CNO) in which the Availability Group will be created. Two permissions that need to be granted are: "Read all properties" and "Create computer objects" to the CNO via the container. More details can be found in the following blog http://blogs.msdn.com/b/psssql/archive/2013/09/30/error-during-installation-of-an-sql-server-failover-cluster-instance.aspx

Mackenziemackerel

On top of grimstoner's comment, and as you subtly indicated, Toan ("...via the container..."), it's the OU that receives the custom Security settings: both the domain user account creating the cluster/listener (Full control) and the cluster computer account (Read all properties and Create Computer objects). – Excogitate

Answer 3

An additional issue we had was having - versus _ in the name of the AOAG and listener. Once we recreated the AOAG using the underscore we were able to create the listener using an underscore also.

Bramante

Answer 4

In our case, all the AD permissions were already in place - and yet it was failing to create the Listener with the same error message. In the end, we found that stopping and starting the Cluster Service on both of the Nodes (using cluadmin.msc) somehow rectified the problem and the Listener got created successfully.

Meyer