I have a Windows Server 2003 Enterprise Edition sp2 - 2 node cluster.
Installed is SQL Server 2005 sp2 across both nodes.

I am logged into the node (node 1) that owns the resources.
I am using the command line [C:\WINDOWS\system32\mmc.exe /32
"C:\WINDOWS\system32\SQLServerManager.msc" /computer:SQL2005] [SQL2005 is
the virtual server] to change the passwords.

When I try to change the SQL Server service account password through SQL
Server configuration manager, it looks like only one nodes 1's services are
changed.
When I move the group to the second node (node 2), both FullText and
SQLServer fail (Agent doesn't have a chance to start because of the
dependencies.)

I thought that the above for SSCM would change all the services across all
cluster nodes.
To actually change the password I have had to go to the plain old
services.msc, change the passwords there,
then move the sql group to that node (this allows the services to start on
that node) then using the SSCM on node 2 with the same command line start as
above, I change the passwords there. This seems to right the wrong I did
when I had to use services.msc.

Any ideas of what is wrong or what I may be doing wrong?
Thnaks in advance.
frankm

Hi Frank,
Welcome to Microsoft TechNet Managed Newsgroup Services.

To let me better understand this scenario and perform effective research, I
appreciate it if you could first answer me some questions and help collect
the requested information as following:
1. Did you verify if the failover function worked fine before you tried to
change the password?
2. Can your SQL Server cluster work fine if you change the password back to
the original?
3. Are the passwords of SQL Server service account and Microsoft Cluster
Service (MSCS) account same?
If they are same, I recommend that you change them to different. Use a
domain administrator account to your MSCS, and a different domain user
account for your SQL Server service.
4. What is the result if you do not use command line to run the SQL Server
Configuration Manager?
5. SQL Error Logs
By default the error logs are located in the folder
%ProgramFiles%\Microsoft SQL Server\MSSQL(.N)\MSSQL\LOG. For SQL Server
cluster, the error logs are located in your cluster share folder.
6. Windows Event Logs on both your active node and passive node
Please gather Windows Event Logs on the problematic node:
Start -> Administrative Tools -> Event Viewer -> Export application/system
event logs with both EVT & TXT format and send them to me.

Since the files may be larger than 2MB, I recommend that you first send me
(changliw_at_microsoft_dot_com) an email response. Then I will send an
email response to you and let you know how to upload the files to me.

Thank you!

Best regards,
Charles Wang

Microsoft Online Community Support
Get Secure! - www.microsoft.com/security
================================================== ==
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ==
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ==

1) Yes
2) Yes
3) No
4) I get connected to (local) not (SQL2005), I've tried both
5 & 6) sent

Thank you for your help!



""Charles Wang [MSFT]"" <changliw (AT) online (DOT) microsoft.com> wrote

Ok, new saga...........................
Tried changing SQL Server 2005 service passwords on a second unrelated
cluster (Only difference was W2K3 R2).
Same problem.
Even with the [/computer:SQLSVR] as a parameter, the SSCM will only update
one node (the node that SSCM was running on), not both. The SSCM did show
that it was connected to the virtual SQL Server not "local".

As the passwords were set to expire (no hope of an extension) , I tested
this in VMWARE numerous times.
Having done this kind of hack on SQL Server 2000 (when passwords expired) I
hoped it would be the same in 2005.

The process I used to change the SQL Server 2005 service account passwords
is:
This appears to have worked every time, no errorr or complaints from any
service or log.

1) On Node 1, change the passwords in SSCM. (This node owns the SQL Server
resource group)
2) On Node 1, in SSCM, restart the SQL Browser service.
3) On Node 2, change the SQL Server services password in Services Manager
(services.msc). (This is done so that the services will start on Node 2,
otherwise they will fail due to password mismatch.)
4) On Node 2, restart the SQL Browser service (in SSCM or services.msc).
5) Move the SQL Server resource group to Node 2 (So that the services will
start on Node 2 and you can connect with SSCM)
6) On Node 2, start the SSCM and change the services account passwords. (in
case there are any registry items that needed updating because I went
through services.msc instead of SSCM)
7) Then I move the SQL Server resource groups a couple of times from node to
node to verify all is well.


BTW - the command line cluster service password change
(http://support.microsoft.com/default.aspx/kb/305813)
worked like a dream. Thanks MS. All without a restart. And a nice output
telling you all the nodes that it was successful on.





"frankm" <frankm (AT) nospam (DOT) postalias> wrote

Dear Frank,
Good morning!

I looked through the uploaded logs, however unfortunately the recorded
error messages were general and I did not find helpful clues. I would like
to further check with you on the following conditions:
1. Is the service account of your Microsoft Cluster Service a domain
administrator account?
You can go to services panel, find the service, double click it, and
switch to the Log On tab to check it. Please make sure that it is a domain
administrator account.
2. What is the result if you change the SQL Server service account to
another domain user account?

Thank you!

Best regards,
Charles Wang
Microsoft Online Community Support
================================================== =======
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg (AT) microsoft (DOT) com.
================================================== =======
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== =======

Hello Charles,

I didn't see any problems in the logs either, that's why I'm baffled.
1) No it is not. There is absolutely no possibility that we can or would use
a domain admin account for a service account.
2) The change to a new domain user worked. I dropped the new login into the
local admin group. That would be the only difference between the old login
and the new.
We have a second cluster that has the same problem only it is W2k3 R2. It
has the service account in the local admin group.





""Charles Wang [MSFT]"" <changliw (AT) online (DOT) microsoft.com> wrote