Random Thunks

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

This was an odd one and much akin to a previous recent incident I’d had with the configuration manager (albeit this time on a totally different server); this last weekend we had one of our regular ‘let’s all work through the night’ maintenance windows. Such events are never fun to do but made even worse when the strangest of things happen.

This weekend it was the turn of the Sql Configuration Manager and it’s stubborn refusal to validate a new account password. No matter how many times I tried it would not take the new password, regardless if I pasted it in or typed it in. Each time I’d see an entry in the Security log telling me the attempt to logon with the credentials had failed.

Given that it was now getting close to 3AM I decided another approach based off the prior experience; I fired up the Services applet and pasted the password directly in there.

Well, would you Adam and Eve it – it only bloody worked.

Don’t have a good reason or explanation for this one other than – WTF?

Still, whatever it takes.

Sql Server 2005 SP2 No CR’s.