When moving a SQL 2005 instance to new disks on a two-node Windows 2003 cluster, I changed startup params on the active node to reflect the new paths for the master DB files and error logs.

I discovered after attempting a move to the alternate node that the startup params were not synchronized with the passive node and I had to reapply them there. Is that by design or should all nodes in a cluster have SQL Server Configuration Manager settings synchronized automatically?

  • 2
    So are you saying that after the move and after the service on the other node started up, the options weren't set and you verified through the error log that those parameters were ignored? Or when you were investigating the move, but before you actually moved, the configuration manager on the target node didn't yet match what you expected? What is the actual @@VERSION? Jul 18, 2013 at 15:16
  • It's currently SQL2K5 SP3. I was coordinating the file relocation from one node and I paused the second node during the transition. Once I finished and confirmed a successful start on the first node, I unpaused and failed over to the second node, but failed to start services there. That's where I checked the startup params and saw that they didn't synch.
    – MattyZDBA
    Jul 18, 2013 at 17:05
  • By "failed to start services there" do you mean you started the services and that failed, or you didn't bother? As Thomas explained, the services need to attempt to start before they will go get the updated parameters. Jul 18, 2013 at 18:00
  • I initiated a failover, observed the physical disks going online first, then observed the SQL service attempting to start (going to Pending Online) but ended up in Failed state. I then attempted to manually bring the service online and got the same result. At that point I checked the event log and then the startup parameters and found the discrepancy.
    – MattyZDBA
    Jul 18, 2013 at 21:24

1 Answer 1


The registry should have been updated automatically. Take a look at the BOL reference on configuring server startup parameters:

On a cluster, changes must be made on the active server while SQL Server is online, and will take effect when the Database Engine is restarted. The registry update of the startup options on the other node will occur upon the next failover.

In order to further troubleshoot why that didn't happen, we would need to know more surrounding information (errors, procedures for changing and failover, etc.). When you say "after attempting a move to the alternate node that the startup params were not synchronized..." what do you mean by "move to the alternate node"? Did you failover the instance?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.