snyderkv
asked on
SQL Server not listening on 1433?
EE,
It may be a corrupt server OS but for some reason I can't get these two SQL servers from the same image to respond to 1433 requests via portqry. I turned off the local and domain firewall policy but they still say "not listening" My other SQL servers respond. Besides that, I have gone into SQL Configuration and put 1433 for IPAll (along with the rest) and enabled secure pipes. SQL Server Browser and agent are running.
Any other ideas?
It may be a corrupt server OS but for some reason I can't get these two SQL servers from the same image to respond to 1433 requests via portqry. I turned off the local and domain firewall policy but they still say "not listening" My other SQL servers respond. Besides that, I have gone into SQL Configuration and put 1433 for IPAll (along with the rest) and enabled secure pipes. SQL Server Browser and agent are running.
Any other ideas?
Brian Crowe
Can you ping/telnet to the SQL instances from your target server? It may not be SQL related at all. You could have DNS or IP issues.
Port 1433 is for TCP/IP connections, has nothing to do with pipes or the other methods.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Will check when I'm back in the office but yeah sql is def running. Will also check Anti-Virus exclusions and any vDS settings if anyone has any more input let me know.
Will also try cliconfg.exe to see if that resets thigns
Will also try cliconfg.exe to see if that resets thigns
ASKER
Recreated the issue in my lab. I have a named instance and had to remove the default as per STIG. Named instances don't use 1433 default and I'm sure not all applications remoting to this port require it but still trying to enable it for troubleshooting purposes
Named instances connect thru the 'sqlbrowser.exe' service on port 1434.
ASKER
1434 was still not listening either. Are you saying that's normal? I changed to 1433 for IPAll under SQL Server Configuration and it listens now. Is this a supported config for Named instances? It just doesn't seem normal for named instances to not listen on on either 1433/1434.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Dave, not following. Most applicatons on the client that connect to a remote sql server default to or ask for the named instance (or default name) NOT the IP address. Sounds like your talking about when connecting remotely via SQL Management Studio? I'm talking about how applications connect to the back end remotely. If they use 1433 or 1433 for named instances via the browser, then that port should respond from the client i.e SolarWinds connecting to the backend storage via named instance (default during insall). Not sure if it's required to be open in this case but I think it connects via an ODBC connection set to SQL Server Native Client 11.0 (which has 1433 enabled) in SQL configuration manager.
I have both PHP and ASP programs that connect to my 4 different installs of SQLExpress and I have told you how they are working. I can switch them between 'named instance' and IP address and they still work. I even have PHP on Linux connecting to them.
SSMS can connect thru any available protocol. I normally leave it at 'default' but I don't actually know what that is. And you can set the SQL Native Client to use any port you want. The Default for TCP/IP on this computer is 1433.
Info on SQL Browser: https://technet.microsoft.com/en-us/library/ms181087%28v=sql.105%29.aspx
SSMS can connect thru any available protocol. I normally leave it at 'default' but I don't actually know what that is. And you can set the SQL Native Client to use any port you want. The Default for TCP/IP on this computer is 1433.
Info on SQL Browser: https://technet.microsoft.com/en-us/library/ms181087%28v=sql.105%29.aspx