I need to know the default port settings for the following services
SQL Server
SQL Browser
SQL Reporting services
SQL Analysis services
I need to know the port settings for these services for different versions of SQL Server (2000,2005,2008)
Also let me know whether the default port setting will change based on sql server versions.
The default SQL Server port is 1433 but only if it's a default install. Named instances get a random port number.
The browser service runs on port UDP 1434.
Reporting services is a web service - so it's port 80, or 443 if it's SSL enabled.
Analysis services is 2382 but only if it's a default install. Named instances get a random port number.
If you have access to the server then you can use
select local_tcp_port from sys.dm_exec_connections where local_tcp_port is not null
For full details see port number of SQL Server
The default, unnamed instance always gets port 1433 for TCP. UDP port 1434 is used by the SQL Browser service to allow named instances to be located. In SQL Server 2000 the first instance to be started took this role.
Non-default instances get their own dynamically-allocated port, by default. If necessary, for example to configure a firewall, you can set them explicitly. If you don't want to enable or allow access to SQL Browser, you have to either include the instance's port number in the connection string, or set it up with the Alias tab in cliconfg (SQL Server Client Network Utility) on each client machine.
For more information see SQL Server Browser Service on MSDN.
1433
the default port hasn't changed yet
SQL Server default port is 1434.
To allow remote access I had to release those ports on my firewall:
Protocol | Port
---------------------
UDP | 1050
TCP | 1050
TCP | 1433
UDP | 1434
You can use SQL Configuration Manager to set individual IP addresses to use dynamic ports or not (value of 0 = yes, use dynamic port), and to set the TCP port used for each IP.
But be careful: I recommend first mapping out your instances, IPs, and ports, and planning such that no instances or IPs step on each other before starting to make changes willy-nilly.
We can take a look at three different ways you can identify the port used by an instance of SQL Server.
Reading SQL Server Error Logs
Using SQL Server Configuration Manager
Using Windows Application Event Viewer
USE master
GO
xp_readerrorlog 0, 1, N'Server is listening on', 'any', NULL, NULL, N'asc'
GO
Identify Port used by SQL Server Database Engine Using SQL Server
Configuration Manager
Click Start -> Programs -> Microsoft SQL Server 2008 -> Configuration Tools -> SQL Server Configuration Manager
In SQL Server Configuration Manager, expand SQL Server Network Configuration and then select Protocols for on the
left panel. To identify the TCP/IP Port used by the SQL Server
Instance, right click onTCP/IP and select Properties from the drop
down as shown below.
For More Help
http://sqlnetcode.blogspot.com/2011/11/sql-server-identify-tcp-ip-port-being.html
Related
I would like to test a website in development hosted in a remote location against a sql server instance on my local machine. I was thinking I could run ngrok locally and update the connection string on the remote website appropriately, but I'm not sure what parameters I need to specify.
I've tried ngrok tcp 12345 and ngrok http 12345
In SQL Server Configuration Manager I've enabled TCP/IP for the SQL Express instance I want to use and set the port to listen on to 12345 (actually, a different number, but we'll say 12345 for the sake of this post). And I then restarted SQL Server.
I don't believe it's necessary for me to make holes in the firewall, but just in case I've temporarily disabled it entirely while I test this.
To test locally, I am taking the url ngrok provides and putting it in the connection dialog in SQL Management Studio, but I can't get it to connect.
What am I missing?
Set up Ngrok
Run ngrok on tcp on the SQL port (by default is 1433)
ngrok tcp 1433
You will get an url like tcp://3.tcp.ngrok.io:12345
In the "Connect to Server Dialog" type:
Server name: 3.tcp.ngrok.io,12345 Notice the comma between the port and the url. Type the url without tcp://
Login: your regular user, in my case sa and your password
Connect
The "URL" that ngrok generates for a TCP tunnel probably shouldn't be used unmodified. The tcp:// scheme part isn't a URI scheme in common use I don't think. Only the hostname and port part of the generated ngrok "URL" would be useful in a SQL Server connection configuration.
Not being intimately familiar with the referenced connection dialog in SQL Management Studio, it's hard to say exactly what input is expected, but maybe stripping out the tcp:// scheme will do the trick?
I'm trying to develop an ASP SQL connection to a MSSQL 2005 server. The SQL server is a sub server behind our main domain server, so a port forward has been setup from the WAN > LAN on port 1433 to allow the traffic to access the second server.
I've done a telnet test on my end to see if the port forward is working correctly and it tells me the connection is refused. When I run the script I get the following result:
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or
access denied.
The code is as follows:
<%
Dim cn
Dim rs
Dim SQL
SQL = "SELECT count(*) FROM master"
'create an instance of the ADO cn and rs objects
Set cn = Server.CreateObject("adodb.connection")
Set rs = Server.CreateObject("adodb.recordset")
'open the cn to the database
cn.Open "Provider=SQLOLEDB;Data Source=###.###.###.###,1433;Network Library=DBMSSOCN;Initial Catalog=blah;User ID=blah;Password=blah"
'Open the rs object executing the SQL statement and return records
rs.Open SQL,cn,adOpenKeyset,adLockOptimistic
'first of all determine whether there are any records
If rs.EOF Then
Response.Write("No records returned.")
Else
'if there are records then loop through the fields
Do While NOT rs.Eof
Response.write rs("count")
Response.write "<br>"
rs.MoveNext
Loop
End If
'close the cn and rs objects to free up resources
rs.Close
Set rs=nothing
cn.Close
Set cn=nothing
%>
Thanks
Also, check Surface Area Configuration in Start menu under 'Microsoft SQL Server 2005' / 'Configuration Tools' to make sure that TCP is enabled. I think by default only Named Pipes are enabled.
Firewalls
The first thing that can block a connection to SQL Server is a firewall. If you have any firewalls, make sure they are configured to allow connections to SQL Server. The default TCP port that SQL Server uses is 1433. Firewalls include McAfee, Norton, Windows Firewall which ships with Windows XP SP2, and Internet Connection Firewall (ICF) which ships with Windows 2000.
Service verification
Before you can connect to SQL Server 2005, you need to verify that SQL Server is running. By default, the SQL Server Express edition is installed as a named instance (SQLEXPRESS). This means that you need to access it by using (local)\SQLEXPRESS from the local machine. SQLEXPRESS without the prefix will not work. You can also use the 127.0.0.1 IP address on a local machine to avoided DNS related problems.
To verify that the service is running, type sqlcmd –S(local)\SQLEXPRESS at the command prompt. If you see "1>" that means that you managed to connect. Type exit to exit the sqlcmd program.
Connection protocols
SQL Server 2005 supports a number of protocols for connecting client applications with the database server. These protocols are TCP, Named Pipes (NP), Shared Memory (SM), VIA, and HTTP. Only TCP, NP, and SM are supported in SQL Server Express.
By default, only SM is accessible for SQL Server Express on the local machine. This means that connections from a remote machine to SQL Server Express will fail unless TCP and/or NP is enabled. If you want to use TCP and NP, you must explicitly turn them on. Use SQL Server Configuration Manager to explicitly enable TCP and NP for server and client. After enabling TCP and NP, you need to start the SQL Browser service (See SQL Browser below).
If you are connecting remotely, you need to substitute "(local)" with the IP address of the server. You can also use the server name instead of the IP address if DNS can resolve the name.
If you are connecting via a specific IP address, make sure you enable the connection for it. In SQL Configuration Manager, expand the SQL Server 2005 Network Configuration node then select TCP/IP Properties from the pane on the right. Select the IP Addresses tab and change Enabled to Yes for the specific IP address.
SQL Server Configuration Manager
The SQL Server Configuration Manager in SQL Server 2005 and SQL Server Express replaces both Client Network Utility and the Server Network Utility. It allows you to configure the protocols that SQL Server listens to as well as the protocols that ADO.NET 2.0 application can use. However, to configure client protocol for applications that use ADO instead of ADO.NET 2.0, you still need to use the Client Network Utility. The Client Network Utility ships with ADO and is part of Windows 2000, Windows XP, and Windows 2003.
To connect to SQL Server Express remotely, make sure that the server can listen to TCP connections. From the SQL Server Configuration Manager, expand "SQL Server 2005 Network Configuration" and navigate to "Protocols for SQL Server Express" then enable TCP. You need to restart the server for the change to take effect.
If you are using Teratrax Database Manager, you can configure client protocols by clicking on the "Client Network Utility" button in the connection dialog. Make sure that you meet the operating system requirement for Teratrax Database Manager (Windows 2000, Windows XP, or Windows 2003).
SQL Server Browser
SQL Browser is a new service in SQL Server 2005 that is used to identify the ports that named instances listen on. The SM protocol does not use this service. This service is turned off in SQL Server Express by default. This means that the user will have to start this service so that remote access can work. You can start the SQL Browser service from the Service Manager or by typing "NET START SQLBROWSER" from the command line.
SQL Browser listens on UDP port 1434. However, pre-SP3 versions of SQL Server 2000 holding port UDP 1434 may result in failure of SQL Browser name resolution, since they may refuse to give up the port. The workaround is to upgrade all SQL Server 2000/MSDE instances on the machine to SP3 or higher.
This happens when the SQL Server service is not running at the remote machine
You may also want to ensure that the sql server instance allows remote connections
I've done a telnet test on my end to
see if the port forward is working
correctly and it tells me the
connection is refused.
Then one of the following is true:
port forwarding does not work
the SQL host firewall is blocking the port (1433)
there is no process listening on 1433 on target:
SQL server stopped or
SQL not configured to use TCP or
SQL host has multiple-IPs and SQL TCP is not listening on the inbound IP from the forwarder or
SQL server listens on non-default port
I have problems connecting to my database server. The database server is not local, I am connected via its IP address.
It works fine in my development machine. After publishing the website to my server, it can not connect to my database server.
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
Why can't my publish server connect to the database server, whereas it works fine through the development machine?
I often had that problem. Mostly it's because of two problems.
Open the SQL Server Configuration Manager.
Check if the SQL Server Network Configuration supports TCP/IP, if it's disabled, enable it.
e.g. SqlServer 2005 Network Configuration, Protocols for SQLEXPRESS
Open the SQL Server Management Studio
Click on the Sql Server Properties (right click on the server name and
select properties).
After that, select the page "Security" and switch the check to "SQL Server and Windows Authentication mode".
That's all.
I'll attempt to go two for two on the psychic debugging for today...
I will assume that you are not using integrated security? If so it might explain things as the account on your local machine probably has permissions, but the SYSTEM account that is running on the server does not. Just a shot in the dark though.
It sounds like your server can't make the network connection, rather than a security issue.
Ensure that any firewalls on both the DB and app servers allow traffic on the port (1433).
Ensure you're able to ping or tracert from both machines.
Is it your first time you publish your website on the web server ? if it is , Are you sure you have set your connection string properly ?
You need to create a login ( of curse a password for that too ) and the IP Address of that SQL on the web server .
So you need IP Address of the sql server host , Database Name , UId , Pwd .
I will agree that this sounds like a network issue and not a security issue.
Remote into the web server and ping the DB server by IP address. If this does not work, your server cannot see the DB server via that address (different subnet, incorrect firewall/proxy setup, etc). There may be a proxy address you must use to get to the DB server from the web server, or your web server may also be the gateway and IIS doesn't know to look for the DB server on the LAN. If it does work, the computers may not be talking on the same port, or the firewall may be blocking that port exiting the web server.
I have spent hours trying to connect to SQL server using sqlcmd. I disabled my firewall, checked all ip listed in "Protocols for SQLEXPRESS", edited my hosts file. I tried using different ips and machinename to connect to the server. But none of work worked. After hours of investigation, I found out that I made absolutely stupid blunder making me unable to connect.
I want to remind people that the connection string is not case sensitive. But the option is!!
what i did is I put
sqlcmd -s .\sqlserver
But the correct string is
sqlcmd -S .\sqlserver
so watch out, people
I have a login page that works in my local development environment. When I push the site onto the web server, i am getting this error when trying to login from the asp.net login control.
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
I cannot figure out why it does not work on the server. Do I need to add anything or change something in the web.config?
This support article may help. It may also be a firewall issue or an authentication issue on the new setup (but the error message makes that less likely).
For resolving error 26 in sql server you need to do the following steps.
At Server System
1. Under surface area configuration manager-Open up remote connections.
2. Add into firewall 1433 and 1434 port no as n exception.
3. Open port 1433 on router for WAN access.
4. Add client machine ip address as an exception to your antivirus or allow LAN settings in antivirus.
5. Now try to check if both client and server are connected to each other.
for this type "ping IP address of remote system" at run and if reply is obtained then do same for server machine.
If reply is obtained from both machines.
Open Sql server and try to connect to remote machine which allow remote connections using its ip address. U will surely get connected to server machine
See this video
Check to make sure TCP/IP is enabled on the SQL Server. For whatever reason, named pipes and TCP/IP is off by default. Also make sure you are trying to connect to the correct instance (maybe you are using ./SQLEXPRESS locally and on the server SQL is installed on the default instance). Lastly, make sure the database you are trying to connect to exists on the server.
My company is currently migrating some of their really old db's to sql server 2005. Some legacy apps have problems connecting to the new server. The connection string works in Asp.NET 2.0, probably because it assumes tcp:1433 automatically.
I have to construct the connection string like this in ASP.NET 1.1 for it to work:
"Server=tcp:my.server.com,1433;..."
Without the protocol and the port, the connection fails ("Invalid Connection exception")
TCP 1433 and UDP 1434 are open on our firewall. On SQL Server 2005 Remote Access is enabled, so is TCPIP, the SQL Browser service is running, I use the proper login credentials.
Any ideas why I can't just specify the server name without protocol and port number?
IIRC SQL Server 2005 defaults to find any-old-port that is available. On my laptop this means port 1212.
To force it to a specific port you must go to Start->Programs->SQL Server 2005->Configuration Tools->SQL Server Configuration Manager
From here you must go to SQL Server 2005 Network Configuration->Protocols for (name of service)->Right click on TCP/IP->Properties->Choose tab "IP Address" and set TCP Dynamic Ports to .
For some reason "0" means "Yes, use dynamic ports" and (i.e. no entry in field) menas "No, I will specify it myself"
Then fill in the field TCP Port with 1433.
Do so on all adapters that are listed, and restart the SQL Service.
You can now check if the service is indeed on the right port by doing the following
Start->Run->cmd.exe
C:>netstat -ano
look for an entry like this
local address <stuff> PID
0.0.0.0:1433 <some number>
Now do
C:>tasklist
and look for the task with the number from above. This task should be called something like sqlsrvr.exe.
Perhaps your SQL Server is configured for multi-protocol, and it's trying to use the other protocol first and failing, perhaps for some security reason (the account that the app is running as in IIS). Just a guess.
Check the "SQL Native Client Configuration" settings in "SQL Configuration Manager" on the ASP.NET machine. The default connection settings are set there. Also try messing with the MDAC configuration:
http://msdn.microsoft.com/en-us/library/ms131035.aspx