Sql Server secretly replicating registry keys on startup
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!
