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!

Not my find this but such a useful post I thought I’d repost it.

In my situation I had added a certificate’s thumbprint to the SuperSocketNetLib key on a new cluster which, for some reason Sql took a total and utter dislike to.

I thought (in my apparent naïveté) that I could simple remove the thumbprint from the registry, restart Sql and I’d be off and running.

Not so fast though. Every time I’d restart Sql Server it would repopulate the thumbprint back into the Certificate value then fail to start as a result. No matter how many times I rebooted, took the value out of the registry and twisted on my left foot whilst swinging a chicken in the air, Sql Server stubbornly and abjectly refused to stop repopulating the value with the bad certificates thumbprint.

User baby_cheeses on SqlServerCentral.com was able to find the magic formula for stopping Sql Server from magically repopulating the registry.

I amended baby_cheeses answer slightly to fit my situation, and it is…

  1. Remove the Certificate’s thumbprint from the registry.

  2. Start Sql Server using a Net Start MSSqlServer.

  3. Check the registry again and ensure thumbprint hasn’t returned.

  4. Start up Sql Server from within Cluster Administrator

  5. Check registry a third time and remove the thumbprint from the Certificate value.

  6. Move the cluster to another node and watch it start normally.

Like I say, I can’t take credit for this discovery.

Original post is here.

UPDATE

Apparently what is happening here is known as Checkpointing, where a copy of the registry is stored on the Quorum. MS gives an official method of avoiding the problem here, although I still think baby_cheeses solution is simpler and involves far less hacking around!