Creating a second Client Access Point on a cluster makes it inpredictable on what name SQL Server will respond - by Axel8s

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 695664 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 10/19/2011 1:07:15 AM
Access Restriction Public


I'm working on a migration/upgrade scenario for a customer and for several reasons I need the new Cluster environment to be reachable with it's new and it's old (current) name.
The cluster will host the SQL server environment as well as some file shares for importing or exporting data.
First attempt was creating a host record in DNS with the alias, after registering the SPN's for SQL Service this was working for SQL server but the files shares were not reachable using the server aliasname. Apparantly this behaviour is new in 2K8 clusters and for the file shares we needed to create a second Client Access Point(CAP) in the cluster. So we removed the DNS alias, created a second CAP in the cluster registered the SPN's again. Now the file shares are reachable by both names but SQL Server was only available with 1 name (we made the SQL Server dependant on both CAP's). During tests it became more awkward when we sawthat SQL Server was responding by the name of the CAP that first came online. So now it's unpredictable on what name SQL Server will respond after coming online. Making the second CAP depending on the first can solve the predicatbility issue but still our SQL Server isn't reachable with 2 names. Is there something we miss, is this intentional our can this be fixed? Thanks in Advance
Sign in to post a comment.
Posted by Microsoft on 11/29/2011 at 3:32 PM

Thanks for your feedback. Having 2 Client Access Points in SQL Server Failover Cluster resource group is not supported by the current design in SQL Server 2005, 2008, and 2008 R2. In the upcoming release SQL 2012 the behavior will remain the same.

I’m resolving this item as by design.

Min He, Program Manager, SQL Engine