Niro77
asked on
MS SQL 2000, 2005 multiple instances not broadcasted to other subnets
We currently have multiple instances of MS Sql 2000 and MS SQL 2005 installed on servers. When at other locations that uses different subnets only the default instance is available, published, broadcasted, selectable.
We have TCPIP and name pipes enabled for all instances. This seems to be a common problem for all locations.
We have TCPIP and name pipes enabled for all instances. This seems to be a common problem for all locations.
The function that gathers the available servers is SQLBrowseConnect. This function requests from the network all SQL Servers that are on the network. Each instance of SQL Server is broadcasting itself on the network. SQLBrowseConnect then lists the servers that respond to its request. There are network considerations that get in the way of this process, such as firewalls, routers, etc. If any of these block the response or slow it down then the SQL Server will not be able to respond in the required amount of time.
You can tell your SQL servers to publish themselves to the AD; this should ensure that they all get recognized regardless of the network (provided that your SQL clients are members of the AD domain as well).
Setting them in AD is a good idea but it probably will not resolve the issue. The problem is with the way
SQLBrowseConnect works and how long it takes for the SQL Servers to respond to the request, which is dependent on the network.
SQLBrowseConnect works and how long it takes for the SQL Servers to respond to the request, which is dependent on the network.
If the SQL server is configured to publish to the AD, won't itdo this as soon as it starts up? If so, then list isn't compiled "on the fly"; it will be available as soon as the client connects to the AD. Of course, the list might be out of date if the SQL server went down.
Yes it is publishes as soon as it starts up. It is not a matter of the list being available. The SQLBROWSECONNECT function actually polls the network and the SQL Server itself responds. It does not look at AD. It is looking for an actual response from the SQL Server. If that response does not come in the required time frame the SQL Server does not get listed.
ASKER
I believe this is the problem and explanation of what is occuring. This seems to be the default behavior in our situation and not a whole lot we can do about it.
http://forums.microsoft.com/forums/ShowPost.aspx?PostID=1434832&SiteID=17
http://forums.microsoft.com/forums/ShowPost.aspx?PostID=1434832&SiteID=17
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Rboyd56 es you are correct, did not notice that.