Random Thunks

This one had me stumped for days. Fortunately MS support came to my rescue with a simple answer.

The problem I was having was getting Sql Server to load an SSL certificate to encrypt communications between client and server on a clustered instance. No matter how many times I tried, Sql refused to run issuing a 0x8009030d error code when attempting to load the certificate. I was always getting the following logged in my ErrorLog:

Server The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030d. Check certificates to make sure they are valid.

Server Error: 26014, Severity: 16, State: 1.

Server Unable to load user-specified certificate. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.

Server Error: 17182, Severity: 16, State: 1.

Server TDSSNIClient initialization failed with error 0×80092004, status code 0×80.

Server Error: 17182, Severity: 16, State: 1. 2011-10-26 07:26:42.75 Server TDSSNIClient initialization failed with error 0×80092004, status code 0×1.

Server Error: 17826, Severity: 18, State: 3.

Server Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.

Server Error: 17120, Severity: 16, State: 1.

Server SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.

I’d come across a few posts that mentioned this error and that Sql was having issues with the Private Key but they suggested using commands from the Resource Kit to fix the issue – something I could not do. To make matters worse (as my previous post described) Checkpointing kept on getting in my way of removing the certificate, just to get Sql to start. I’d even tried things like adding the Service Account in the Administrators group in the vain hope that it was a permissions issue.

So after spending several days of tearing my hair out (and running out of time to get this fixed) I came to the conclusion I needed to bring in outside help – MS Support to the rescue!

And the answer? It was as simple as deleting the previously imported certificate then re-importing it using the domain account that runs Sql. Yup, it was that simple…

Thanks Gary!

Whilst Quest declare that ChangeDirector 2.1 supports Clustering I’m not convinced it goes the whole hog. However your intrepid Random-Thunker has gone through the small number of extra steps required to make it so.

First off if you’ve not already done so, install ChangeDirector onto both nodes using the normal methods and validate that it works just fine by moving the Sql Cluster service through each node. Validate with ChangeDirector that the agent is running correctly.

Now shut the Service down and modify the configuration file ON EACH NODE. For me the configuration file was on C:\Program Files\Quest Software\Quest Change Director for SQL Server\[SqlClusterName]\QuestChangeTrackerAgent.exe.config. Update this to point the Trace and Log folders on one of the shared drives used by the cluster. I used the drive dedicated to normally storing dumps and backups onto which kept it away from affecting the other drives in the SAN whilst still making it always available to the cluster.

Fire up the service again on the active node to verify all is well still then shut it down again and this time change it’s startup type from Automatic to Manual.

Create a new Generic Service Cluster Resource in the Cluster Administrator. The Service name to use is Quest Change Tracker Agent. I added a couple of dependencies for both the drive I was using to store the logs and traces on and also Sql Server itself. In addition I elected to change the settings to not affect the group; this way if it should so something daft it wasn’t going to take the whole cluster with it. For me the continuous availability of the cluster trumps ChangeDirector – your individual mileage may, as they oft say, vary. And oh, there are no registry keys to replicate so you don’t need to worry on that front.

Now you should be able to fire up the resource in the Cluster Administrator and off you go. For a final test move the Sql Cluster through each node verifying that it’s seen by ChangeDirector at all times.

Windows 2003, ChangeDirector 2.1.0.87