October 10, 2013 at 4:03 pm
Interesting dilemma... we were having an issue with the Passive node of one of our SQL 2012 Active/Passive clusters (running on Windows 2008), and in working with Microsoft a clean-up script was executed which basically destroyed the cluster. The end suggestion was to uninstall SQL and rebuild the cluster, but I was able to pull the Cluster registry key from the Instance and start MS SQL outside of the cluster. All is working great, but now we're finding Kerberos issues with double-hops like with Integrated Security with SSRS or deploying SSIS packages. It's not picking-up the authenticated credentials and is instead using an Anonymous account.
I've lisetd out the SPN info for both the server name and former Cluster name on the server, but I'm unsure of what to change or drop to fix this. Any suggestions?
Thanks.
October 11, 2013 at 12:37 pm
samalex (10/10/2013)
Interesting dilemma... we were having an issue with the Passive node of one of our SQL 2012 Active/Passive clusters (running on Windows 2008), and in working with Microsoft a clean-up script was executed which basically destroyed the cluster. The end suggestion was to uninstall SQL and rebuild the cluster, but I was able to pull the Cluster registry key from the Instance and start MS SQL outside of the cluster. All is working great, but now we're finding Kerberos issues with double-hops like with Integrated Security with SSRS or deploying SSIS packages. It's not picking-up the authenticated credentials and is instead using an Anonymous account.I've lisetd out the SPN info for both the server name and former Cluster name on the server, but I'm unsure of what to change or drop to fix this. Any suggestions?
Thanks.
I found the cause of the problem, so I'm working on the solution which hopefully will work. The SQL Server still identifies itself as the old Failover cluster name. For example if I run this:
Select ServerProperty('machinename'), ServerProperty('ServerName'), @@ServerName
it returns the Failover cluster name (which does not exist) instead of the server name in all three cases. Probably next week we'll move all the databases (system and user) to another server given the issues we've been having, and that will be a clean stand-alone version of Windows (non-clustered). Hopefully when we reattach the databases the naming issue will go away, but if not I'll drop/add the server to change the name.
Thanks.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply