Can't change TCP Port using configuration manager for x64 SQL 2005 SP1 virtual instance

Hi, I hope someone can help me! I changed the TCP port that the default instance of SQL 2005 x64 SP1 is listening on and now SQL server won't start as the port is being used - no problem I say to myself, I'll just change it again, however I can't!

My problem is that I can not change the TCP Port back again using Configuration Manager - no matter what values I put in, after a restart of the instance it comes up with this in the IP Addresses tab for TCP/IP Properties and SQL Server won't start:

IP1
Active Yes
Enabled No
IP Address aaa.bbb.ccc.111
TCP Dynamic Ports
TCP Port 0

IP2
Active Yes
Enabled No
IP Address aaa.bbb.ccc.222
TCP Dynamic Ports
TCP Port 0

IP3
Active Yes
Enabled No
IP Address aaa.bbb.ccc.333
TCP Dynamic Ports
TCP Port 0

IP4
Active Yes
Enabled No
IP Address 10.1.1.1
TCP Dynamic Ports
TCP Port 0

IP5
Active Yes
Enabled No
IP Address 127.0.0.1
TCP Dynamic Ports
TCP Port 0

IPALL
TCP Dynamic Ports 2020
TCP Port 2020

Interestingly, the ip address that the server is listening on aaa.bbb.ccc.444 is not reported in the list of IP addresses in the configuration manager for this instance, yet it is when I view the available IP addresses for the other two instances - is this significant?

I have tried failing to the other node, changing it there, changing it at the console and also while logged onto the the virtual machine remote desktop, rebooting both nodes, etc, etc. There are two other instances on this cluster that are still working fine but I hvae not attempted to change the TCP ports they listen on.

I used the same method to change this default instance as I did for a named instance on a similarly configured cluster and it worked fine. How to fix this?

Regards, Mike

2007-02-27 12:03:17.69 Server Server is listening on [ aaa.bbb.ccc.444<ipv4> 2020].
2007-02-27 12:03:17.71 spid9s Starting up database 'tempdb'.
2007-02-27 12:03:17.72 Server Error: 26023, Severity: 16, State: 1.
2007-02-27 12:03:17.72 Server Server TCP provider failed to listen on [ aaa.bbb.ccc.444<ipv4> 2020]. Tcp port is already in use.
2007-02-27 12:03:17.75 Server Error: 17182, Severity: 16, State: 1.
2007-02-27 12:03:17.75 Server TDSSNIClient initialization failed with error 0x2740, status code 0xa.
2007-02-27 12:03:17.75 Server Error: 17182, Severity: 16, State: 1.
2007-02-27 12:03:17.75 Server TDSSNIClient initialization failed with error 0x2740, status code 0x1.
2007-02-27 12:03:17.75 Server Error: 17826, Severity: 18, State: 3.
2007-02-27 12:03:17.75 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.
2007-02-27 12:03:17.77 Server Error: 17120, Severity: 16, State: 1.
2007-02-27 12:03:17.77 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.

BWAHAHAHAHAHAHA!!!!! The same thing happened to me today! What a nightmare! I came about 10min away from nuking my virtual server instance and restoring 50+ databases. It was supposed to be such a simple change... I even tested it on a non-clustered box first. Oh well.

I had *exactly* the same setup as you, except 32bit. I think the problem was that I made the change on my passive node. My cluster has multiple instances spread over all nodes, but the virtual instance I was changing wasn't changed on the active node. I think that's what did me in.

In my situation, the IP settings I ented in caused the SQL Server instance to not start (too lazy to check the actual error at the moment). What happens is that the cluster service is configured to replicate the registry settings that govern the TCP/IP paramenters. If you edit the parameters incorrectly (or at least the way I did) then the cluster service continues to replicate those parameters to all nodes. Mind you, I used the SSCM too! The registry replication occurs when the cluster group changes nodes. If the SQL Server service does not start, then the cluster quorum logs never get cleared. In other words, the cluster doesn't think the registry params got applied correctly. No matter what you do to the registry on each node, the cluster quorum logs will continue to apply the replicated settings until SQL starts successfully (which never happens).

To fix it, I had to stop MSCS from replicating the bad registry params so that I could manually rebuild them. Here's how I did it, YMMV:

0. (I forgot a step) Set your broken SQL instance cluster resource to not restart automatically in MSCS

1. Stop cluster service on all nodes

2. Locate the SQL Server instance cluster resource you're having issues with here: HKLM\Cluster\Resources

Change the following parameter from this:

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER

to this:

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\CurrentVersion

on all nodes

3. Fix the following registry branch on all nodes to what they were before (use your other instances as a guide if necessary):

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\supersocketnetlib\TCP

4. Start the cluster service on all nodes.

5. SQL Server will not start because you've messed with the registry replication params. (but it'll be a different error than before)

6. Move this cluster group to all nodes and let it fail on all nodes.

6b. Verify that the TCP/IP parameters are still good on all nodes.

7. Take your group completely offline.

8. Revert the registry replication changes you made in step 2 back to what they should be.

9. Clean up Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\CurrentVersion. (It'll be messed up from the forced registry replication. Do this on all nodes.

10. cycle the SQL browser service on all nodes for good measure.

11. Bring your broken SQL instance back to life. I had to cycle SQL Browser one more time while I was doing this.

12. Verify that the SQL instance comes back on all nodes.

This worked for me. Good luck. Oh, and for my gratification, how about you try changing the IP address parameters from the Active node using SSCM while SQL is up? Let me know it if works :) and I'll attempt it on my cluster again.

-EDF

This sucks Beavis.

|||Thanks EDF. This looks very promising. I actually made my changes while RDP'd to the virtual instance name so it must have been the active node but maybe making the change through Remote Desktop stuffed it. I'll give it a go tomorrow and try my IP config changes again from the active node at the console and let everyone know how it goes. Thanks again.|||I tried the above changes but it did not help. I am going to raise a call with MS Support and I'll post the resolution.|||

Gengleman, did either of you successfully change the IP address of the cluster? We are currently attempting this and although I did it once before I think I got lucky. I'd love to see the steps followed.

UJ

|||Yeah, I did. It turns out that "Listen on All IP Addresses" *really* means "Listen on All IP Addresses in the cluster group". Move all your SQL instances to one node. Log into that node and start the IP binding configuration tool, SSCM. Leave the entry for "listen all"=Yes (totally against all that is good & right in me...). I wanted all my SQL instances to listen on the same port (2048), but diff IP addresses. On the IP Addresses tab, I set all my IP addresses entries to Enabled=No. At the bottom, I set IPAll entry so that TCP Dynamic Ports was NULL (not 0) and TCP Port=2048. On start up, each SQL instance then only attempts to bind port 2048 to it's own IP address. Certainly NOT what I would have expected, but I suppose it makes sense.|||

Hi, I was trying to change the port, not the IP address, when somehow it got screwed up - I guess I mis-typed something. I ended up calling in PSS and they fixed it for me as I couldn't reproduce the fix that fischere suggested. It is very easy to screw up your TCP/IP config with the SSCM - the MS tech used it to corrupt his installation to reproduce my problem so it would be a good idea to play around with it on an environment that isn't important first and then make sure you follow the process exactly on your other instances.

If you end up screwing up the instance (by changing IP addresses, ports, etc) so that it won't start, you can reset it back to what it was using the Cluster Server Recovery Utility (ClusterRecovery.exe) which is available for download from the MS website. It's main purpose seems to be to recover from failed drives, but it has the ability to override the registry entries that cluster services wants to apply to a node using the "checkpoint" option. This allows you to overcome the problem of not being able to reset the values that the SSCM tries to write to the registry on each node because when you try and bring an instance on line or fail to another node the settings get restored from cluster services as fischere points out. To fix a failed instance using this tool, follow these steps:

1. move the failed instance to a node

2. change the registry settings to what they should be on that node, eg HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\SuperSocketNetLib\Tcp\IPAll

3. checkpoint the cluster using the tool on that node

4. bring the instance on line

5. repeat this process on each node.

I hope this helps someone else!

|||Thanks for posting this solution. It worked like a charm for me.sql

Can't change TCP Port using configuration manager for x64 SQL 2005 SP1 virtual instance

Hi, I hope someone can help me! I changed the TCP port that the default instance of SQL 2005 x64 SP1 is listening on and now SQL server won't start as the port is being used - no problem I say to myself, I'll just change it again, however I can't!

My problem is that I can not change the TCP Port back again using Configuration Manager - no matter what values I put in, after a restart of the instance it comes up with this in the IP Addresses tab for TCP/IP Properties and SQL Server won't start:

IP1
Active Yes
Enabled No
IP Address aaa.bbb.ccc.111
TCP Dynamic Ports
TCP Port 0

IP2
Active Yes
Enabled No
IP Address aaa.bbb.ccc.222
TCP Dynamic Ports
TCP Port 0

IP3
Active Yes
Enabled No
IP Address aaa.bbb.ccc.333
TCP Dynamic Ports
TCP Port 0

IP4
Active Yes
Enabled No
IP Address 10.1.1.1
TCP Dynamic Ports
TCP Port 0

IP5
Active Yes
Enabled No
IP Address 127.0.0.1
TCP Dynamic Ports
TCP Port 0

IPALL
TCP Dynamic Ports 2020
TCP Port 2020

Interestingly, the ip address that the server is listening on aaa.bbb.ccc.444 is not reported in the list of IP addresses in the configuration manager for this instance, yet it is when I view the available IP addresses for the other two instances - is this significant?

I have tried failing to the other node, changing it there, changing it at the console and also while logged onto the the virtual machine remote desktop, rebooting both nodes, etc, etc. There are two other instances on this cluster that are still working fine but I hvae not attempted to change the TCP ports they listen on.

I used the same method to change this default instance as I did for a named instance on a similarly configured cluster and it worked fine. How to fix this?

Regards, Mike

2007-02-27 12:03:17.69 Server Server is listening on [ aaa.bbb.ccc.444<ipv4> 2020].
2007-02-27 12:03:17.71 spid9s Starting up database 'tempdb'.
2007-02-27 12:03:17.72 Server Error: 26023, Severity: 16, State: 1.
2007-02-27 12:03:17.72 Server Server TCP provider failed to listen on [ aaa.bbb.ccc.444<ipv4> 2020]. Tcp port is already in use.
2007-02-27 12:03:17.75 Server Error: 17182, Severity: 16, State: 1.
2007-02-27 12:03:17.75 Server TDSSNIClient initialization failed with error 0x2740, status code 0xa.
2007-02-27 12:03:17.75 Server Error: 17182, Severity: 16, State: 1.
2007-02-27 12:03:17.75 Server TDSSNIClient initialization failed with error 0x2740, status code 0x1.
2007-02-27 12:03:17.75 Server Error: 17826, Severity: 18, State: 3.
2007-02-27 12:03:17.75 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.
2007-02-27 12:03:17.77 Server Error: 17120, Severity: 16, State: 1.
2007-02-27 12:03:17.77 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.

BWAHAHAHAHAHAHA!!!!! The same thing happened to me today! What a nightmare! I came about 10min away from nuking my virtual server instance and restoring 50+ databases. It was supposed to be such a simple change... I even tested it on a non-clustered box first. Oh well.

I had *exactly* the same setup as you, except 32bit. I think the problem was that I made the change on my passive node. My cluster has multiple instances spread over all nodes, but the virtual instance I was changing wasn't changed on the active node. I think that's what did me in.

In my situation, the IP settings I ented in caused the SQL Server instance to not start (too lazy to check the actual error at the moment). What happens is that the cluster service is configured to replicate the registry settings that govern the TCP/IP paramenters. If you edit the parameters incorrectly (or at least the way I did) then the cluster service continues to replicate those parameters to all nodes. Mind you, I used the SSCM too! The registry replication occurs when the cluster group changes nodes. If the SQL Server service does not start, then the cluster quorum logs never get cleared. In other words, the cluster doesn't think the registry params got applied correctly. No matter what you do to the registry on each node, the cluster quorum logs will continue to apply the replicated settings until SQL starts successfully (which never happens).

To fix it, I had to stop MSCS from replicating the bad registry params so that I could manually rebuild them. Here's how I did it, YMMV:

0. (I forgot a step) Set your broken SQL instance cluster resource to not restart automatically in MSCS

1. Stop cluster service on all nodes

2. Locate the SQL Server instance cluster resource you're having issues with here: HKLM\Cluster\Resources

Change the following parameter from this:

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER

to this:

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\CurrentVersion

on all nodes

3. Fix the following registry branch on all nodes to what they were before (use your other instances as a guide if necessary):

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\supersocketnetlib\TCP

4. Start the cluster service on all nodes.

5. SQL Server will not start because you've messed with the registry replication params. (but it'll be a different error than before)

6. Move this cluster group to all nodes and let it fail on all nodes.

6b. Verify that the TCP/IP parameters are still good on all nodes.

7. Take your group completely offline.

8. Revert the registry replication changes you made in step 2 back to what they should be.

9. Clean up Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\CurrentVersion. (It'll be messed up from the forced registry replication. Do this on all nodes.

10. cycle the SQL browser service on all nodes for good measure.

11. Bring your broken SQL instance back to life. I had to cycle SQL Browser one more time while I was doing this.

12. Verify that the SQL instance comes back on all nodes.

This worked for me. Good luck. Oh, and for my gratification, how about you try changing the IP address parameters from the Active node using SSCM while SQL is up? Let me know it if works :) and I'll attempt it on my cluster again.

-EDF

This sucks Beavis.

|||Thanks EDF. This looks very promising. I actually made my changes while RDP'd to the virtual instance name so it must have been the active node but maybe making the change through Remote Desktop stuffed it. I'll give it a go tomorrow and try my IP config changes again from the active node at the console and let everyone know how it goes. Thanks again.|||I tried the above changes but it did not help. I am going to raise a call with MS Support and I'll post the resolution.|||

Gengleman, did either of you successfully change the IP address of the cluster? We are currently attempting this and although I did it once before I think I got lucky. I'd love to see the steps followed.

UJ

|||Yeah, I did. It turns out that "Listen on All IP Addresses" *really* means "Listen on All IP Addresses in the cluster group". Move all your SQL instances to one node. Log into that node and start the IP binding configuration tool, SSCM. Leave the entry for "listen all"=Yes (totally against all that is good & right in me...). I wanted all my SQL instances to listen on the same port (2048), but diff IP addresses. On the IP Addresses tab, I set all my IP addresses entries to Enabled=No. At the bottom, I set IPAll entry so that TCP Dynamic Ports was NULL (not 0) and TCP Port=2048. On start up, each SQL instance then only attempts to bind port 2048 to it's own IP address. Certainly NOT what I would have expected, but I suppose it makes sense.|||

Hi, I was trying to change the port, not the IP address, when somehow it got screwed up - I guess I mis-typed something. I ended up calling in PSS and they fixed it for me as I couldn't reproduce the fix that fischere suggested. It is very easy to screw up your TCP/IP config with the SSCM - the MS tech used it to corrupt his installation to reproduce my problem so it would be a good idea to play around with it on an environment that isn't important first and then make sure you follow the process exactly on your other instances.

If you end up screwing up the instance (by changing IP addresses, ports, etc) so that it won't start, you can reset it back to what it was using the Cluster Server Recovery Utility (ClusterRecovery.exe) which is available for download from the MS website. It's main purpose seems to be to recover from failed drives, but it has the ability to override the registry entries that cluster services wants to apply to a node using the "checkpoint" option. This allows you to overcome the problem of not being able to reset the values that the SSCM tries to write to the registry on each node because when you try and bring an instance on line or fail to another node the settings get restored from cluster services as fischere points out. To fix a failed instance using this tool, follow these steps:

1. move the failed instance to a node

2. change the registry settings to what they should be on that node, eg HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\SuperSocketNetLib\Tcp\IPAll

3. checkpoint the cluster using the tool on that node

4. bring the instance on line

5. repeat this process on each node.

I hope this helps someone else!

|||Thanks for posting this solution. It worked like a charm for me.

Can't change TCP Port using configuration manager for x64 SQL 2005 SP1 virtual instance

Hi, I hope someone can help me! I changed the TCP port that the default instance of SQL 2005 x64 SP1 is listening on and now SQL server won't start as the port is being used - no problem I say to myself, I'll just change it again, however I can't!

My problem is that I can not change the TCP Port back again using Configuration Manager - no matter what values I put in, after a restart of the instance it comes up with this in the IP Addresses tab for TCP/IP Properties and SQL Server won't start:

IP1
Active Yes
Enabled No
IP Address aaa.bbb.ccc.111
TCP Dynamic Ports
TCP Port 0

IP2
Active Yes
Enabled No
IP Address aaa.bbb.ccc.222
TCP Dynamic Ports
TCP Port 0

IP3
Active Yes
Enabled No
IP Address aaa.bbb.ccc.333
TCP Dynamic Ports
TCP Port 0

IP4
Active Yes
Enabled No
IP Address 10.1.1.1
TCP Dynamic Ports
TCP Port 0

IP5
Active Yes
Enabled No
IP Address 127.0.0.1
TCP Dynamic Ports
TCP Port 0

IPALL
TCP Dynamic Ports 2020
TCP Port 2020

Interestingly, the ip address that the server is listening on aaa.bbb.ccc.444 is not reported in the list of IP addresses in the configuration manager for this instance, yet it is when I view the available IP addresses for the other two instances - is this significant?

I have tried failing to the other node, changing it there, changing it at the console and also while logged onto the the virtual machine remote desktop, rebooting both nodes, etc, etc. There are two other instances on this cluster that are still working fine but I hvae not attempted to change the TCP ports they listen on.

I used the same method to change this default instance as I did for a named instance on a similarly configured cluster and it worked fine. How to fix this?

Regards, Mike

2007-02-27 12:03:17.69 Server Server is listening on [ aaa.bbb.ccc.444<ipv4> 2020].
2007-02-27 12:03:17.71 spid9s Starting up database 'tempdb'.
2007-02-27 12:03:17.72 Server Error: 26023, Severity: 16, State: 1.
2007-02-27 12:03:17.72 Server Server TCP provider failed to listen on [ aaa.bbb.ccc.444<ipv4> 2020]. Tcp port is already in use.
2007-02-27 12:03:17.75 Server Error: 17182, Severity: 16, State: 1.
2007-02-27 12:03:17.75 Server TDSSNIClient initialization failed with error 0x2740, status code 0xa.
2007-02-27 12:03:17.75 Server Error: 17182, Severity: 16, State: 1.
2007-02-27 12:03:17.75 Server TDSSNIClient initialization failed with error 0x2740, status code 0x1.
2007-02-27 12:03:17.75 Server Error: 17826, Severity: 18, State: 3.
2007-02-27 12:03:17.75 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.
2007-02-27 12:03:17.77 Server Error: 17120, Severity: 16, State: 1.
2007-02-27 12:03:17.77 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.

BWAHAHAHAHAHAHA!!!!! The same thing happened to me today! What a nightmare! I came about 10min away from nuking my virtual server instance and restoring 50+ databases. It was supposed to be such a simple change... I even tested it on a non-clustered box first. Oh well.

I had *exactly* the same setup as you, except 32bit. I think the problem was that I made the change on my passive node. My cluster has multiple instances spread over all nodes, but the virtual instance I was changing wasn't changed on the active node. I think that's what did me in.

In my situation, the IP settings I ented in caused the SQL Server instance to not start (too lazy to check the actual error at the moment). What happens is that the cluster service is configured to replicate the registry settings that govern the TCP/IP paramenters. If you edit the parameters incorrectly (or at least the way I did) then the cluster service continues to replicate those parameters to all nodes. Mind you, I used the SSCM too! The registry replication occurs when the cluster group changes nodes. If the SQL Server service does not start, then the cluster quorum logs never get cleared. In other words, the cluster doesn't think the registry params got applied correctly. No matter what you do to the registry on each node, the cluster quorum logs will continue to apply the replicated settings until SQL starts successfully (which never happens).

To fix it, I had to stop MSCS from replicating the bad registry params so that I could manually rebuild them. Here's how I did it, YMMV:

0. (I forgot a step) Set your broken SQL instance cluster resource to not restart automatically in MSCS

1. Stop cluster service on all nodes

2. Locate the SQL Server instance cluster resource you're having issues with here: HKLM\Cluster\Resources

Change the following parameter from this:

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER

to this:

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\CurrentVersion

on all nodes

3. Fix the following registry branch on all nodes to what they were before (use your other instances as a guide if necessary):

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\supersocketnetlib\TCP

4. Start the cluster service on all nodes.

5. SQL Server will not start because you've messed with the registry replication params. (but it'll be a different error than before)

6. Move this cluster group to all nodes and let it fail on all nodes.

6b. Verify that the TCP/IP parameters are still good on all nodes.

7. Take your group completely offline.

8. Revert the registry replication changes you made in step 2 back to what they should be.

9. Clean up Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\CurrentVersion. (It'll be messed up from the forced registry replication. Do this on all nodes.

10. cycle the SQL browser service on all nodes for good measure.

11. Bring your broken SQL instance back to life. I had to cycle SQL Browser one more time while I was doing this.

12. Verify that the SQL instance comes back on all nodes.

This worked for me. Good luck. Oh, and for my gratification, how about you try changing the IP address parameters from the Active node using SSCM while SQL is up? Let me know it if works :) and I'll attempt it on my cluster again.

-EDF

This sucks Beavis.

|||Thanks EDF. This looks very promising. I actually made my changes while RDP'd to the virtual instance name so it must have been the active node but maybe making the change through Remote Desktop stuffed it. I'll give it a go tomorrow and try my IP config changes again from the active node at the console and let everyone know how it goes. Thanks again.|||I tried the above changes but it did not help. I am going to raise a call with MS Support and I'll post the resolution.|||

Gengleman, did either of you successfully change the IP address of the cluster? We are currently attempting this and although I did it once before I think I got lucky. I'd love to see the steps followed.

UJ

|||Yeah, I did. It turns out that "Listen on All IP Addresses" *really* means "Listen on All IP Addresses in the cluster group". Move all your SQL instances to one node. Log into that node and start the IP binding configuration tool, SSCM. Leave the entry for "listen all"=Yes (totally against all that is good & right in me...). I wanted all my SQL instances to listen on the same port (2048), but diff IP addresses. On the IP Addresses tab, I set all my IP addresses entries to Enabled=No. At the bottom, I set IPAll entry so that TCP Dynamic Ports was NULL (not 0) and TCP Port=2048. On start up, each SQL instance then only attempts to bind port 2048 to it's own IP address. Certainly NOT what I would have expected, but I suppose it makes sense.|||

Hi, I was trying to change the port, not the IP address, when somehow it got screwed up - I guess I mis-typed something. I ended up calling in PSS and they fixed it for me as I couldn't reproduce the fix that fischere suggested. It is very easy to screw up your TCP/IP config with the SSCM - the MS tech used it to corrupt his installation to reproduce my problem so it would be a good idea to play around with it on an environment that isn't important first and then make sure you follow the process exactly on your other instances.

If you end up screwing up the instance (by changing IP addresses, ports, etc) so that it won't start, you can reset it back to what it was using the Cluster Server Recovery Utility (ClusterRecovery.exe) which is available for download from the MS website. It's main purpose seems to be to recover from failed drives, but it has the ability to override the registry entries that cluster services wants to apply to a node using the "checkpoint" option. This allows you to overcome the problem of not being able to reset the values that the SSCM tries to write to the registry on each node because when you try and bring an instance on line or fail to another node the settings get restored from cluster services as fischere points out. To fix a failed instance using this tool, follow these steps:

1. move the failed instance to a node

2. change the registry settings to what they should be on that node, eg HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\SuperSocketNetLib\Tcp\IPAll

3. checkpoint the cluster using the tool on that node

4. bring the instance on line

5. repeat this process on each node.

I hope this helps someone else!

|||Thanks for posting this solution. It worked like a charm for me.

Can't change TCP Port using configuration manager for x64 SQL 2005 SP1 virtual instance

Hi, I hope someone can help me! I changed the TCP port that the default instance of SQL 2005 x64 SP1 is listening on and now SQL server won't start as the port is being used - no problem I say to myself, I'll just change it again, however I can't!

My problem is that I can not change the TCP Port back again using Configuration Manager - no matter what values I put in, after a restart of the instance it comes up with this in the IP Addresses tab for TCP/IP Properties and SQL Server won't start:

IP1
Active Yes
Enabled No
IP Address aaa.bbb.ccc.111
TCP Dynamic Ports
TCP Port 0

IP2
Active Yes
Enabled No
IP Address aaa.bbb.ccc.222
TCP Dynamic Ports
TCP Port 0

IP3
Active Yes
Enabled No
IP Address aaa.bbb.ccc.333
TCP Dynamic Ports
TCP Port 0

IP4
Active Yes
Enabled No
IP Address 10.1.1.1
TCP Dynamic Ports
TCP Port 0

IP5
Active Yes
Enabled No
IP Address 127.0.0.1
TCP Dynamic Ports
TCP Port 0

IPALL
TCP Dynamic Ports 2020
TCP Port 2020

Interestingly, the ip address that the server is listening on aaa.bbb.ccc.444 is not reported in the list of IP addresses in the configuration manager for this instance, yet it is when I view the available IP addresses for the other two instances - is this significant?

I have tried failing to the other node, changing it there, changing it at the console and also while logged onto the the virtual machine remote desktop, rebooting both nodes, etc, etc. There are two other instances on this cluster that are still working fine but I hvae not attempted to change the TCP ports they listen on.

I used the same method to change this default instance as I did for a named instance on a similarly configured cluster and it worked fine. How to fix this?

Regards, Mike

2007-02-27 12:03:17.69 Server Server is listening on [ aaa.bbb.ccc.444<ipv4> 2020].
2007-02-27 12:03:17.71 spid9s Starting up database 'tempdb'.
2007-02-27 12:03:17.72 Server Error: 26023, Severity: 16, State: 1.
2007-02-27 12:03:17.72 Server Server TCP provider failed to listen on [ aaa.bbb.ccc.444<ipv4> 2020]. Tcp port is already in use.
2007-02-27 12:03:17.75 Server Error: 17182, Severity: 16, State: 1.
2007-02-27 12:03:17.75 Server TDSSNIClient initialization failed with error 0x2740, status code 0xa.
2007-02-27 12:03:17.75 Server Error: 17182, Severity: 16, State: 1.
2007-02-27 12:03:17.75 Server TDSSNIClient initialization failed with error 0x2740, status code 0x1.
2007-02-27 12:03:17.75 Server Error: 17826, Severity: 18, State: 3.
2007-02-27 12:03:17.75 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.
2007-02-27 12:03:17.77 Server Error: 17120, Severity: 16, State: 1.
2007-02-27 12:03:17.77 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.

BWAHAHAHAHAHAHA!!!!! The same thing happened to me today! What a nightmare! I came about 10min away from nuking my virtual server instance and restoring 50+ databases. It was supposed to be such a simple change... I even tested it on a non-clustered box first. Oh well.

I had *exactly* the same setup as you, except 32bit. I think the problem was that I made the change on my passive node. My cluster has multiple instances spread over all nodes, but the virtual instance I was changing wasn't changed on the active node. I think that's what did me in.

In my situation, the IP settings I ented in caused the SQL Server instance to not start (too lazy to check the actual error at the moment). What happens is that the cluster service is configured to replicate the registry settings that govern the TCP/IP paramenters. If you edit the parameters incorrectly (or at least the way I did) then the cluster service continues to replicate those parameters to all nodes. Mind you, I used the SSCM too! The registry replication occurs when the cluster group changes nodes. If the SQL Server service does not start, then the cluster quorum logs never get cleared. In other words, the cluster doesn't think the registry params got applied correctly. No matter what you do to the registry on each node, the cluster quorum logs will continue to apply the replicated settings until SQL starts successfully (which never happens).

To fix it, I had to stop MSCS from replicating the bad registry params so that I could manually rebuild them. Here's how I did it, YMMV:

0. (I forgot a step) Set your broken SQL instance cluster resource to not restart automatically in MSCS

1. Stop cluster service on all nodes

2. Locate the SQL Server instance cluster resource you're having issues with here: HKLM\Cluster\Resources

Change the following parameter from this:

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER

to this:

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\CurrentVersion

on all nodes

3. Fix the following registry branch on all nodes to what they were before (use your other instances as a guide if necessary):

Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\supersocketnetlib\TCP

4. Start the cluster service on all nodes.

5. SQL Server will not start because you've messed with the registry replication params. (but it'll be a different error than before)

6. Move this cluster group to all nodes and let it fail on all nodes.

6b. Verify that the TCP/IP parameters are still good on all nodes.

7. Take your group completely offline.

8. Revert the registry replication changes you made in step 2 back to what they should be.

9. Clean up Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER\CurrentVersion. (It'll be messed up from the forced registry replication. Do this on all nodes.

10. cycle the SQL browser service on all nodes for good measure.

11. Bring your broken SQL instance back to life. I had to cycle SQL Browser one more time while I was doing this.

12. Verify that the SQL instance comes back on all nodes.

This worked for me. Good luck. Oh, and for my gratification, how about you try changing the IP address parameters from the Active node using SSCM while SQL is up? Let me know it if works :) and I'll attempt it on my cluster again.

-EDF

This sucks Beavis.

|||Thanks EDF. This looks very promising. I actually made my changes while RDP'd to the virtual instance name so it must have been the active node but maybe making the change through Remote Desktop stuffed it. I'll give it a go tomorrow and try my IP config changes again from the active node at the console and let everyone know how it goes. Thanks again.|||I tried the above changes but it did not help. I am going to raise a call with MS Support and I'll post the resolution.|||

Gengleman, did either of you successfully change the IP address of the cluster? We are currently attempting this and although I did it once before I think I got lucky. I'd love to see the steps followed.

UJ

|||Yeah, I did. It turns out that "Listen on All IP Addresses" *really* means "Listen on All IP Addresses in the cluster group". Move all your SQL instances to one node. Log into that node and start the IP binding configuration tool, SSCM. Leave the entry for "listen all"=Yes (totally against all that is good & right in me...). I wanted all my SQL instances to listen on the same port (2048), but diff IP addresses. On the IP Addresses tab, I set all my IP addresses entries to Enabled=No. At the bottom, I set IPAll entry so that TCP Dynamic Ports was NULL (not 0) and TCP Port=2048. On start up, each SQL instance then only attempts to bind port 2048 to it's own IP address. Certainly NOT what I would have expected, but I suppose it makes sense.|||

Hi, I was trying to change the port, not the IP address, when somehow it got screwed up - I guess I mis-typed something. I ended up calling in PSS and they fixed it for me as I couldn't reproduce the fix that fischere suggested. It is very easy to screw up your TCP/IP config with the SSCM - the MS tech used it to corrupt his installation to reproduce my problem so it would be a good idea to play around with it on an environment that isn't important first and then make sure you follow the process exactly on your other instances.

If you end up screwing up the instance (by changing IP addresses, ports, etc) so that it won't start, you can reset it back to what it was using the Cluster Server Recovery Utility (ClusterRecovery.exe) which is available for download from the MS website. It's main purpose seems to be to recover from failed drives, but it has the ability to override the registry entries that cluster services wants to apply to a node using the "checkpoint" option. This allows you to overcome the problem of not being able to reset the values that the SSCM tries to write to the registry on each node because when you try and bring an instance on line or fail to another node the settings get restored from cluster services as fischere points out. To fix a failed instance using this tool, follow these steps:

1. move the failed instance to a node

2. change the registry settings to what they should be on that node, eg HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\SuperSocketNetLib\Tcp\IPAll

3. checkpoint the cluster using the tool on that node

4. bring the instance on line

5. repeat this process on each node.

I hope this helps someone else!

|||Thanks for posting this solution. It worked like a charm for me.

Cant Access SQL Server (on Vista) from other Network PC (XP)

I have just installed Vista on one of my home network pcs. I also installed Outlook 2005 with Business Contact Manager. It installs an instance of SQL Server Express.

I have created another database on this engine that I need to access from other PCs on my network.

The server address is PCNAME\MSSMLBIZ and I can access the data the database using this name from the the Vista PC (PCNAME).

When I try to acess the database using the same credentials (server, database, username (sa) and password) from an XP PC on the network - it times out and returns an error . My guess is that it is not seeing the database service at all.

I have SQL Server Management Studio installed on the Vista PC and have full access to the instance.

Server authentication is set for SQL Server and Windows Authentication mode.

Can anyone help me?. I need to access the SQL Server from the XP PC.

Ian

Make sure that SQL Server Browser is running, you firewall is configured properly to allow the SQL Server traffic and that Remote connections are enabled for SQL Server. (See the screencats on my site for more information).

Firewall configuration: http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b914277

Jens K. Suessmeyer.

http://www.sqlserver2005.de

|||

Yes - that worked - as soon as I set remote access on Surface Area Configuration for Services and Connections page.

Regards Ian

|||I have just installed SQL Server 2005 Developer Edition on Windows Vista Ultimate, but i cant access and see "sql server managment studio" The only things i have are these >>>

Cant Access SQL Server (on Vista)

I have just installed Vista on one of my home network pcs. I also installed Outlook 2005 with Business Contact Manager. It installs an instance of SQL Server Express.

I have created another database on this engine that I need to access from other PCs on my network.

The server address is PCNAME\MSSMLBIZ and I can access the data the database using this name from the the Vista PC (PCNAME).

When I try to acess the database using the same credentials (server, database, username (sa) and password) from an XP PC on the network - it times out and returns an error . My guess is that it is not seeing the database service at all.

I have SQL Server Management Studio installed on the Vista PC and have full access to the instance.

Server authentication is set for SQL Server and Windows Authentication mode.

Can anyone help me?. I need to access the SQL Server from the XP PC.

Ian

Make sure that SQL Server Browser is running, you firewall is configured properly to allow the SQL Server traffic and that Remote connections are enabled for SQL Server. (See the screencats on my site for more information).

Firewall configuration: http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b914277

Jens K. Suessmeyer.

http://www.sqlserver2005.de

|||

Yes - that worked - as soon as I set remote access on Surface Area Configuration for Services and Connections page.

Regards Ian

|||I have just installed SQL Server 2005 Developer Edition on Windows Vista Ultimate, but i cant access and see "sql server managment studio" The only things i have are these >>>

Can't access SQL Express from SQL Server

I installed SQL Express on an instance of Microsoft Virtual Server. I
haven't been able to connect to it from SQL Server which is running on the
same network, but on our real server. Now I have been able to successfully
able to connect to the real SQL Server from the Express but it doesn't work
the other way around. I am using the same hostname that I see in the
Express managment studio... \\PARENTVM\SQLEXPRESS using the login I created
in Express.
I allowed access through Windows Firewall, and I enabled the allow access
from remote users in the Express configuration.
What am I missing?
Hi there,
Have you enabled remote connections on the SQLExpress instance?
By default the remote connections are disabled. Open "SQL Server
Surface Area Configuration" under Configuration tools. You then need to
select the "Surface Area Configuration for Services and Connections"
option. The Remote connections option will allow you to change the
connection types. Once you've done that restart the service to make
sure the change takes effect.
Hope this help...
sql

Can't access properties on Stored Procedures

Hi. I have set up an instance of SQL 2005 on my local computer. I use MS SQL Server Management Studio to login into my 2005 instance via Windows login. When I expand "Stored Procedures" under "Programmability" of the Database I want and go to a stored procedure and right click, I don't see the "properities" selection.

I know it's there because I can get to it on other instances but I can't get to it on my local instance. I added my windows user to my Logins and then to my database users but it didn't help.

Can anyone please tell me what I need to do so I can access the properties of the stored procedures?

Thanks

Your procedure was created with encryption option. Because this you can′t see the contents.

|||Its either an encryption problem (like already mentioned by the other poster) or you don′t have the appropiate permissions viewing the properties. Which access level does the account you are using have ? Is there a pas lock on the stored procedure symbol ?

Jens K. Suessmeyer.

http://www.sqlserver2005.de

Can't Access Named Instanced With Network Protocol Disabled

Hi there,
I have a little question here.
I've installed a named instance of MSDE SP4 called mydb, with network
protocols disabled.
Then I noticed that I can't connect to it using OSQL
I tried
'osl -S (local)\mydb -E'
'osl -S localhost\mydb -E'
and both of them can't connect to the database, however.
'osql -S mypcname\mydb -E'
works perfectly... I don't want to manually fill in the machine name for
each connection string can someone tell me why (local) doesn't seem to
connect to the local machine? Does it have anything to do with network
protocols disabled?
Thanks.
Hi
(local) and localhost rely on the network stack to resolve. If you network
is disabled, there is nothing there to resolve the name. localhost resolves
to 127.0.0.1 by TCP/IP.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Marauderz" <marauderz@.nospam.com> wrote in message
news:u1dlfrAqFHA.3720@.TK2MSFTNGP14.phx.gbl...
> Hi there,
> I have a little question here.
> I've installed a named instance of MSDE SP4 called mydb, with network
> protocols disabled.
> Then I noticed that I can't connect to it using OSQL
> I tried
> 'osl -S (local)\mydb -E'
> 'osl -S localhost\mydb -E'
> and both of them can't connect to the database, however.
> 'osql -S mypcname\mydb -E'
> works perfectly... I don't want to manually fill in the machine name for
> each connection string can someone tell me why (local) doesn't seem to
> connect to the local machine? Does it have anything to do with network
> protocols disabled?
> Thanks.
>

can't access named instance by it's name

Hi,

I have sql2005 sp1 active-active installation.

I've fixed the named instance port.

I can't reach it from clients with i'ts name (servername\instancename) .

I manage to rech it only by using servername, ip-port.

The sql browser has the following error:

"The configuration of the AdminConnection\TCP protocol in the SQL instance GILBOACL is not valid."

your help is appreciated!

Shahar

1. Is UPD port 1434 open?
2. Does the browser service account have access to the registry key? See the following article for more info.
http://support.microsoft.com/kb/905618

Can't access an instance installed on same server

About 2 months ago I loaded a new instance on my SQL Server 200 box. I have
been working with the database in that instance. However, now I try to
access the other instance on the server and I get connection failed check
server registration properties. When I check them I get "login failed." I
switch the registration back to SQL and windows - same issue. All services
are running on server and users are able to get to database.
I checked whitepapers and KB but can't find what to do. Any assistance is
greatly appreciated.
Hi
If you login is failing how can your "users are able to get to database"?
If you can access the server using the given login though query analyser
(from the failing client), then check the connection string and check the
network libraries/protocols.
John
"Multitasker" wrote:

> About 2 months ago I loaded a new instance on my SQL Server 200 box. I have
> been working with the database in that instance. However, now I try to
> access the other instance on the server and I get connection failed check
> server registration properties. When I check them I get "login failed." I
> switch the registration back to SQL and windows - same issue. All services
> are running on server and users are able to get to database.
> I checked whitepapers and KB but can't find what to do. Any assistance is
> greatly appreciated.
sql

Can't access an instance installed on same server

About 2 months ago I loaded a new instance on my SQL Server 200 box. I have
been working with the database in that instance. However, now I try to
access the other instance on the server and I get connection failed check
server registration properties. When I check them I get "login failed." I
switch the registration back to SQL and windows - same issue. All services
are running on server and users are able to get to database.
I checked whitepapers and KB but can't find what to do. Any assistance is
greatly appreciated.Hi
If you login is failing how can your "users are able to get to database"?
If you can access the server using the given login though query analyser
(from the failing client), then check the connection string and check the
network libraries/protocols.
John
"Multitasker" wrote:

> About 2 months ago I loaded a new instance on my SQL Server 200 box. I hav
e
> been working with the database in that instance. However, now I try to
> access the other instance on the server and I get connection failed check
> server registration properties. When I check them I get "login failed." I
> switch the registration back to SQL and windows - same issue. All services
> are running on server and users are able to get to database.
> I checked whitepapers and KB but can't find what to do. Any assistance is
> greatly appreciated.

Can't access an instance installed on same server

About 2 months ago I loaded a new instance on my SQL Server 200 box. I have
been working with the database in that instance. However, now I try to
access the other instance on the server and I get connection failed check
server registration properties. When I check them I get "login failed." I
switch the registration back to SQL and windows - same issue. All services
are running on server and users are able to get to database.
I checked whitepapers and KB but can't find what to do. Any assistance is
greatly appreciated.Hi
If you login is failing how can your "users are able to get to database"?
If you can access the server using the given login though query analyser
(from the failing client), then check the connection string and check the
network libraries/protocols.
John
"Multitasker" wrote:
> About 2 months ago I loaded a new instance on my SQL Server 200 box. I have
> been working with the database in that instance. However, now I try to
> access the other instance on the server and I get connection failed check
> server registration properties. When I check them I get "login failed." I
> switch the registration back to SQL and windows - same issue. All services
> are running on server and users are able to get to database.
> I checked whitepapers and KB but can't find what to do. Any assistance is
> greatly appreciated.

Cant access (local) server

I folks. I have something going on with my local SQL instance. It's SQL 2000 Standard with SP3a on a W2k3 Server with SP1. It's been running fine for several months. I got brave over the weekend and broke something.

I installed the .Net Enterprise Architect and SQL Reporting Services. My SQL instance is still running, but I can't get to it through EM and SQLServerAgent won't start. When I try to start SQLServerAgent manually, it gets about halfway through the process, then shuts itself down again. I also have an MSDE instance that is not complaining at all.

I can get to the server from my applications. I can also register it in EM with the IP and get to it that way.

Here's what's in sqlagent.out:

2007-01-02 16:34:41 - ! [298] SQLServer Error: 6, Specified SQL server not found. [SQLSTATE 08001]
2007-01-02 16:34:41 - ! [298] SQLServer Error: 11004, ConnectionOpen (Connect()). [SQLSTATE 01000]
2007-01-02 16:34:41 - ! [000] Unable to connect to server '(local)'; SQLServerAgent cannot start
2007-01-02 16:34:42 - ? [098] SQLServerAgent terminated (normally)

I did confirm in the registry that the port is set to 1433. It's not blank or incorrect. I am also working with a local account that is in the administrators group. There is no AD structure at work.

Many thanks for any ideas. This one feels like a little needle in a big haystack.

EaglesYouc an't have a 2k and an msde instance both named local... one of them HAS to be a named instance. Which one is named?|||The MSDE instance is named. The SQL Server 2000 instance is local.|||what server name do you use to connect to msde?|||One question (which will lead to others..) Were the two instances (Both MSDE and SQL Server existing before all the other installs? And happily co-existing?|||Yes, the 2 instances have been happily co-existing for over a year and things have been very stable. Since it's all the SQL instances are test environment, there's quite of bit of database creation and deletion in both the SS2K and MSDE instance. I also freqently register my clients SQL servers when I'm on-site also. There is actually a third instance which is another MSDE instance. Here's a snippet of them:

(local) - SS2k WITH sp3a. Currently houses a database for Project server and several small company databases for an accounting app. This instance starts automatically. It has been in place for ever a year.

acsob- MSDE instance with several company databases for an accounting application. This instance and it's accompanying sqlserver agent start automatically. It has been in place for over year.

quickalerts - MSDE instance with an interface application to the SS2K accounting application. This instance and accompanying sqlserveragent are set to start manually and are rarely running. This instance was installed 2 weeks ago. It was running constantly during initial configuration and testing.

All these servers are test environments with very low usage. I use them to do software demos, training, and testing. There's rarely more than one user logged in to any of the servers.

Last night after I opened this thread I registered the local sql server instance using the machine IP (assigned by the DHCP server). I was able to get it using the IP address but not as (local). That brought to light another piece of possible useful info. About a month ago, I enabled the mail role on this machine so I could send mail when I'm on the road. That all worked fine with one exception. I can not send email to my own domain account. I can send email to any other domains. I can also receive email to myself that I send from my providers webmail. Not sure if this is relevant, but it's starting to feel like a dns issue somewhere.

Thanks.

Eagles|||I can now get to the the sql instance through EM. The hosts file contained the following entry:

127.0.0.1 localhost

I added this entry:

127.0.0.1 local

A network admin at a client site suggested this.

The sqlserveragent still starts and immediately shuts down.

Cann't uninstall an instance

I once tried to uninstall a single default instance of sql2000, using
the installation CD. Unfortunately, it was taking forever and I killed
the process. After I rebooted the server and tried to uninstall again, I
got the error, saying uninstall file could not be found, or something
was missing...
I tried to re-install the default instance to correct it. However, I
could not get the default instance back. As a result, I could not
re-install it and I could not uninstall it.
How can I manually uninstall the instance?
Thank you.
I found myself an article and will go from there...
How to manually remove SQL Server 2000 default, named, or virtual instance
http://support.microsoft.com/default...290991&sd=tech
Jluo wrote:
> I once tried to uninstall a single default instance of sql2000, using
> the installation CD. Unfortunately, it was taking forever and I killed
> the process. After I rebooted the server and tried to uninstall again, I
> got the error, saying uninstall file could not be found, or something
> was missing...
> I tried to re-install the default instance to correct it. However, I
> could not get the default instance back. As a result, I could not
> re-install it and I could not uninstall it.
> How can I manually uninstall the instance?
> Thank you.
>

Cann't uninstall an instance

I once tried to uninstall a single default instance of sql2000, using
the installation CD. Unfortunately, it was taking forever and I killed
the process. After I rebooted the server and tried to uninstall again, I
got the error, saying uninstall file could not be found, or something
was missing...
I tried to re-install the default instance to correct it. However, I
could not get the default instance back. As a result, I could not
re-install it and I could not uninstall it.
How can I manually uninstall the instance?
Thank you.I found myself an article and will go from there...
How to manually remove SQL Server 2000 default, named, or virtual instance
http://support.microsoft.com/defaul...;290991&sd=tech
Jluo wrote:
> I once tried to uninstall a single default instance of sql2000, using
> the installation CD. Unfortunately, it was taking forever and I killed
> the process. After I rebooted the server and tried to uninstall again, I
> got the error, saying uninstall file could not be found, or something
> was missing...
> I tried to re-install the default instance to correct it. However, I
> could not get the default instance back. As a result, I could not
> re-install it and I could not uninstall it.
> How can I manually uninstall the instance?
> Thank you.
>

Cann't uninstall an instance

I once tried to uninstall a single default instance of sql2000, using
the installation CD. Unfortunately, it was taking forever and I killed
the process. After I rebooted the server and tried to uninstall again, I
got the error, saying uninstall file could not be found, or something
was missing...
I tried to re-install the default instance to correct it. However, I
could not get the default instance back. As a result, I could not
re-install it and I could not uninstall it.
How can I manually uninstall the instance?
Thank you.I found myself an article and will go from there...
How to manually remove SQL Server 2000 default, named, or virtual instance
http://support.microsoft.com/default.aspx?scid=kb;en-us;290991&sd=tech
Jluo wrote:
> I once tried to uninstall a single default instance of sql2000, using
> the installation CD. Unfortunately, it was taking forever and I killed
> the process. After I rebooted the server and tried to uninstall again, I
> got the error, saying uninstall file could not be found, or something
> was missing...
> I tried to re-install the default instance to correct it. However, I
> could not get the default instance back. As a result, I could not
> re-install it and I could not uninstall it.
> How can I manually uninstall the instance?
> Thank you.
>

Cannot use file for clustered server

I have a clustered server with a clustered instance of SQL Server 2000
running on it. I'm attempting to restore several databases to the clustered
server from our production, non-clustered database server. I also want to do
a move of log files at the same time. On the production server, the database
and log files are on the same raid array. On the clustered server, I've
created two raid arrays, drive H: for the databases which is in cluster group
0 and drive g: for the logs which is in cluster group 1. The database server
on the cluster is in group 0, by the way. I'm doing a restore using an sql
file that works restoring databases and logs to a backup server on different
drives so I'm reasonably sure that the restore syntax is correct. When I
attempt to do a restore of the log files on the cluster server, I receive the
following error.
Msg 5184, Level 16, State 2, Line 1
Cannot use file g:\logs\ims.ldf for clustered server. Only formatted files
on which the cluster resource of the server has a dependency can be used.
What does that mean? Does that mean that I have to put the log array in the
same group as the clustered instance of sql server? If that's the case, how
do I do that?
TIA
Ernie
Move the G: Drive into the SQL Group (group 0 from you post).
Stop the SQL clustered group.
Double click SQL Server resource and add G: Drive as a dependency.
Bring the SQL Group back online.
Restore away
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://www.msmvps.com/clustering - Blog
"ebferro" <ebferro@.discussions.microsoft.com> wrote in message
news:24628F06-9C5C-4B4F-B7C6-50E82D24CF8F@.microsoft.com...
>I have a clustered server with a clustered instance of SQL Server 2000
> running on it. I'm attempting to restore several databases to the
> clustered
> server from our production, non-clustered database server. I also want to
> do
> a move of log files at the same time. On the production server, the
> database
> and log files are on the same raid array. On the clustered server, I've
> created two raid arrays, drive H: for the databases which is in cluster
> group
> 0 and drive g: for the logs which is in cluster group 1. The database
> server
> on the cluster is in group 0, by the way. I'm doing a restore using an
> sql
> file that works restoring databases and logs to a backup server on
> different
> drives so I'm reasonably sure that the restore syntax is correct. When I
> attempt to do a restore of the log files on the cluster server, I receive
> the
> following error.
> Msg 5184, Level 16, State 2, Line 1
> Cannot use file g:\logs\ims.ldf for clustered server. Only formatted
> files
> on which the cluster resource of the server has a dependency can be used.
> What does that mean? Does that mean that I have to put the log array in
> the
> same group as the clustered instance of sql server? If that's the case,
> how
> do I do that?
> TIA
> Ernie
|||Rod:
Many thanks for the help. My restore appears to be running nicely right now
so I think that fixed the problem.
"Rodney R. Fournier [MVP]" wrote:

> Move the G: Drive into the SQL Group (group 0 from you post).
> Stop the SQL clustered group.
> Double click SQL Server resource and add G: Drive as a dependency.
> Bring the SQL Group back online.
> Restore away
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://www.msmvps.com/clustering - Blog
>
> "ebferro" <ebferro@.discussions.microsoft.com> wrote in message
> news:24628F06-9C5C-4B4F-B7C6-50E82D24CF8F@.microsoft.com...
>
>

Cannot Subscribe Using Windows Synchronization Manager

Hi,
I'm using two instances of SQL Server 2005 Developer Edition (SP2) on the
same machine. One instance is Publisher and Distributor and the other is
Subscriber. When I try to use Windows Synchronization Manager to subscribe
to the publication, I get this error:
The SQL Server publication uses features that the current version of the
Subscriber does not support. The subscriber should be upgraded to 'Unknown
version of Microsoft SQL Server'.
Any help would be greatly appreciated,
Leila
Can you check the compatibility level of the subscription database?
Also see if you can do a simple pull subscription to see if that works.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Leila" <Leilas@.hotpop.com> wrote in message
news:%23ESWMUCTHHA.1200@.TK2MSFTNGP02.phx.gbl...
> Hi,
> I'm using two instances of SQL Server 2005 Developer Edition (SP2) on the
> same machine. One instance is Publisher and Distributor and the other is
> Subscriber. When I try to use Windows Synchronization Manager to subscribe
> to the publication, I get this error:
> The SQL Server publication uses features that the current version of the
> Subscriber does not support. The subscriber should be upgraded to 'Unknown
> version of Microsoft SQL Server'.
> Any help would be greatly appreciated,
> Leila
>
|||compatibility level is 9, pull subscription without Synchronization Manager
works!
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%234mNP4DTHHA.4404@.TK2MSFTNGP03.phx.gbl...
> Can you check the compatibility level of the subscription database?
> Also see if you can do a simple pull subscription to see if that works.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Leila" <Leilas@.hotpop.com> wrote in message
> news:%23ESWMUCTHHA.1200@.TK2MSFTNGP02.phx.gbl...
>
|||Sounds like something is wrong with Windows Synchronization Manager. Can you
try from another machine?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Leila" <Leilas@.hotpop.com> wrote in message
news:OJC3wRFTHHA.4956@.TK2MSFTNGP04.phx.gbl...
> compatibility level is 9, pull subscription without Synchronization
> Manager works!
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%234mNP4DTHHA.4404@.TK2MSFTNGP03.phx.gbl...
>
|||I'll try that!
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23OP$xzFTHHA.5108@.TK2MSFTNGP06.phx.gbl...
> Sounds like something is wrong with Windows Synchronization Manager. Can
> you try from another machine?
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Leila" <Leilas@.hotpop.com> wrote in message
> news:OJC3wRFTHHA.4956@.TK2MSFTNGP04.phx.gbl...
>
|||I'll try that!
One more thing: BOL says that interactive conflict resolution is not
available when you synchronize via SSMS. Then why is there such an option
when you create the subscription in SSMS?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23OP$xzFTHHA.5108@.TK2MSFTNGP06.phx.gbl...
> Sounds like something is wrong with Windows Synchronization Manager. Can
> you try from another machine?
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Leila" <Leilas@.hotpop.com> wrote in message
> news:OJC3wRFTHHA.4956@.TK2MSFTNGP04.phx.gbl...
>
|||It is for subscriptions that you will pull through WSM. Note you have to
also enable interactive conflict resolution in WSM as well
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Leila" <Leilas@.hotpop.com> wrote in message
news:%23w5nP4HTHHA.2124@.TK2MSFTNGP06.phx.gbl...
> I'll try that!
> One more thing: BOL says that interactive conflict resolution is not
> available when you synchronize via SSMS. Then why is there such an option
> when you create the subscription in SSMS?
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23OP$xzFTHHA.5108@.TK2MSFTNGP06.phx.gbl...
>
>

Cannot start SQL Server 2005 service

I have a SQL Server 2005 instance installed. I have created databases and
schema on the SQL Server. I cannot start the service for the SQL Server. I
ahve tried using every account possible. It always errors out with the
following message:
initerrlog: Could not open error log file 'C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\LOG\ERRORLOG'. Operating system error = 5(Access is
denied.).
The event ID in the application log is 17058.
Also the following error message appears in the system log
The SQL Server (MSSQLSERVER) service terminated with service-specific error
17058 (0x42A2).
Please help, there is not a lot of information out there on this issue
Thanks
The error message is pretty straight forward. Does the SQL Server service account have permissions
on that folder? Did you change the service account after installation. Changing service account
should only be done using the "SQL Server Configuration Manager" applet.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"batgirl" <batgirl@.discussions.microsoft.com> wrote in message
news:BAEDC4F7-3F13-44BB-8394-63B2BDC5A638@.microsoft.com...
>I have a SQL Server 2005 instance installed. I have created databases and
> schema on the SQL Server. I cannot start the service for the SQL Server. I
> ahve tried using every account possible. It always errors out with the
> following message:
> initerrlog: Could not open error log file 'C:\Program Files\Microsoft SQL
> Server\MSSQL.1\MSSQL\LOG\ERRORLOG'. Operating system error = 5(Access is
> denied.).
> The event ID in the application log is 17058.
> Also the following error message appears in the system log
> The SQL Server (MSSQLSERVER) service terminated with service-specific error
> 17058 (0x42A2).
> Please help, there is not a lot of information out there on this issue
> Thanks
>
>
|||The SQL Service acoount does have permissions on that folder. The service
account was not changed. The SQL Server was working fine. It was down for a
couple of days and then the service started giving this errors.
batgirl
"Tibor Karaszi" wrote:

> The error message is pretty straight forward. Does the SQL Server service account have permissions
> on that folder? Did you change the service account after installation. Changing service account
> should only be done using the "SQL Server Configuration Manager" applet.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "batgirl" <batgirl@.discussions.microsoft.com> wrote in message
> news:BAEDC4F7-3F13-44BB-8394-63B2BDC5A638@.microsoft.com...
>
|||Though, this means the error doesn't reflect reality. How about if you log on to the machine
interactively and try to access that folder? And add, read etc to a file in the directory...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"batgirl" <batgirl@.discussions.microsoft.com> wrote in message
news:4EEB5F4B-E834-4681-A9A8-917402FE4149@.microsoft.com...[vbcol=seagreen]
> The SQL Service acoount does have permissions on that folder. The service
> account was not changed. The SQL Server was working fine. It was down for a
> couple of days and then the service started giving this errors.
> --
> batgirl
>
> "Tibor Karaszi" wrote:
|||I have already tried that, it did not help. The only thing that has changed
on the machine is it's IP address. It is a test machine, I was going to
uninstall and reinstall SQL 2005 but it will not even let me uninstall. I
have no idea what to do next
Thanks
batgirl
"Tibor Karaszi" wrote:

> Though, this means the error doesn't reflect reality. How about if you log on to the machine
> interactively and try to access that folder? And add, read etc to a file in the directory...
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "batgirl" <batgirl@.discussions.microsoft.com> wrote in message
> news:4EEB5F4B-E834-4681-A9A8-917402FE4149@.microsoft.com...
>
|||Hmm, if the directory exists with the exact same name as in the error message and the service
account indeed has permissions, then you seem to have some serious problem with the installation. I
know you can get some strange errors with compressed drives...
In what way doesn't the uninstall work? Error messages? I know that there is a KB article on how to
manually uninstall 2000, perhaps there is one for 2005 as well?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"batgirl" <batgirl@.discussions.microsoft.com> wrote in message
news:6CACF67A-FC57-4722-A6E8-B12B81D36DB9@.microsoft.com...[vbcol=seagreen]
>I have already tried that, it did not help. The only thing that has changed
> on the machine is it's IP address. It is a test machine, I was going to
> uninstall and reinstall SQL 2005 but it will not even let me uninstall. I
> have no idea what to do next
> Thanks
> --
> batgirl
>
> "Tibor Karaszi" wrote: