Guys,
I have a “small” problem with SQLBrowser.
A setup is very simple: 3 nodes 2K3 R2 SP2 x64 cluster with 3 named SQL
instances (x64 too).

The service doesn’t want to start right after named pipes protocol was
disabled for all instances.
Upon restart I get the following error message:
The SQL Server Browser service on Local computer started and then stopped.
some services stop automatically if they have no work to do, for example the
performance Logs and Alerts service.

Funny… I always thought it suppose to tell a client what ports named SQL
instances listening on.
I have enabled named pipes protocol again, restarted/failed the cluster over
few times but it didn’t help.
Client machines cannot connect unless they have aliases specifying ports…

I was tried to start it from command line
C:\Program Files (x86)\Microsoft SQL Server\90\Shared>sqlbrowser.exe -c
SQLBrowser: starting up in console mode
SQLBrowser: starting up SSRP redirection service
SQLBrowser is successfully listening on 0.0.0.0[1434]
SQLBrowser: failed starting SSRP redirection services -- shutting down.
But got no hints there ether…

The only message is Error log is:
Source: SQL Browser
Type: Warning
Category: None
User: N/A
Description: The configuration of the AdminConnection\TCP protocol in the
SQL instance <name> is not valid.
And there is no clue how to fix it too.

I did some googling on it is and found a suggestion to disable “SsrpListener”
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90\SQL Browser]
"SsrpListener"
"0" - disabled

Indeed I can start SQL Server Browser service now, but it doesn’t listening
on 1434 anymore.
And (obviously!) PortQryV2 (a tool to query on UDP ports) doesn’t get any
response ether…


Somebody on forums suggest 100% working solution: “reinstall everything”!
Well, I’m pretty sure it’ll work, but I still want to know how I messed it
up so badly without doing anything. :-)


Finally a workaround was found (not a solution, but just a workaround)
3 named SQL instances was installed into
"C:\Program Files\Microsoft SQL Server\MSSQL.1\"
"C:\Program Files\Microsoft SQL Server\MSSQL.2\"
"C:\Program Files\Microsoft SQL Server\MSSQL.3\"

If I delete following keys on a node, I SQLBrowser can start and works
properly.
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ Microsoft SQL
Server\MSSQL.1]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ Microsoft SQL
Server\MSSQL.2]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ Microsoft SQL
Server\MSSQL.3]

But once instance is started on the node, the its key will be crated again
and we won’t be able to [re]start SQLBrowser anymore.
If I delete key while SQL instance is running, SQLBrowser can start, but
it’ll be nasty message in error log from ClusSvc service (every few seconds)
Cluster service could not write to a file (D:\TEMP\CLS4B07.tmp). The disk
may be low on disk space, or some other serious condition exists.


I you read so far, bear with me, please. I’m about to jump to conclusions! :-)

Above I was talking about our production system.
We do have exactly same setup for QA environment.
And those keys doesn’t exist on QA!
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ Microsoft SQL
Server\MSSQL.1]
[…\MSSQL.2]
[…\MSSQL.3]

I can restart/failover instance, but they never get created!

Apparently, they used by ClusSvc service. But ClusSvc supposed to be 64bit
application. Why would it go to Wow6432Node part of the registry?

Could anybody tell what application/service is responsible for creating
those keys and what are they for?
Why they do exists in some configuration but not presented in others?
Once we have the questions answered it should be easy to fix SQLBrowser
problem!

Thanks for reading and sorry for a long post…
OK