0

I'm wondering if there is a policy that can be pushed that defaults a client to always dynamically determine the port for connectivity. I'm dealing with a custom C# application that connects to a remote SQL server.
SQL Server Details SQL Server 2008 R2 STD instance Windows Server 2008 STD The SQL connection string of the C# application is hard coded to use the default 1433 for the data connection. However the server\instance name is a customizable parameter. The SQL Server is configured to bind the instance to a specific IP and port 1433 through the configuration manager. The instance is also configured to allow remote connections and there are not any firewall issues and I can verify this with portqury.exe. I can also verify that sqlserver.exe is listening on 1433 through a netstat –abn. There is only a single instance on the server and none of the interface IPs are configured to dynamic port configuration. I want to add that I am getting the same results with the sql browser enabled and disabled. But since there is only a single instance and I’m not using a dynamic port I should not have to use the SQL browser service. I guess I should also add that port 1434 was open and accessible while I was testing with the browser service enabled. The SQL configuration is not in question.

So testing with the C# application I’m unable to hit the database server and get a different error from multiple systems. However when I test connectivity to the SQL instance through ODBC I’m able to auth against the system (SQL Auth) and hit the required database. However I do have to make a configuration change on the client when adding the ODBC connection for testing. Selecting the option for SQL Auth and then going in to the client configuration options and disabling the check box for “Dynamically determine port” so that it will specify port 1433 for the connection. One this has been added the client software is able to connect without any further issues even after removing the ODBC connection I used for testing.

This is where my main question takes place. Is there a policy that can force all SQL connections from a Windows XP, Windows 7 system to always use a dynamic port for the data connection? Why would the application still connect to SQL on port 1433 after the ODBC connection was removed? I guess I could go a little further and do a process trace with process explorer and use TCPView to verify the connectivity from a fresh box to the SQL instance before removing the option from the ODBC connections for ““Dynamically determine port” on the client system.

Any insight or additional points to check and investigate further would be great. I posted this to super user as this appears to be a client side issue and not a server configuration issue.

RevelingSeven
  • 1

2 Answers2

0

Setting up an ODBC connection on the client computer (running as an admin) should allow you to set the port to * if I remember correctly.

I assume you checked out this from Microsoft: How to configure SQL Server to listen on a specific port http://support.microsoft.com/kb/823938

Or off the top of my head, Server Client Network Util on the server itself?

N8J
  • 1
0

The server side is configured and bound to port 1433 on a specific IP address. The issue is specifically on the client side attempting to negotiate a dynamic port when it is configured to a static port on the server. It ended up being a client setting in their AV product not allowing the connection to port 1434 for the specific application.

I was able to query the port dynamically through ODBC but unable to with the custom application. I did not have access to the AV management server or the client side password to view the blocked connections. Since I was working in an environment that I did not fully manage.

RevelingSeven
  • 1