I am an employee of an organisation which uses Remote Desktop Computers. We log in from personal devices with Windows Remote Desktop to an IP/port combo, say 12.23.1.234:5431.
Once in I have servers accessible on the root path e.g. SVR1
Our main software uses a SQL Server instance on SVR1 e.g. Database_01. I can see this on the software loading screen and switch between SVR1\Database_01 and SVR1\Database_02 etc.
How can I identify the server name/address to connect MS Powerpivot to this server directly from my personal machine?
For this you have static ip address provided by your isp provider or your machine should have connected to your VPN and if you have one of them then you can access database by enabling tcp/ip in sql server in host machine
for this open SQL Server management configuration
in configuration tab go to
SQL Native Client *.0 Configuration =>Client Protocol
then Right Click on TCP/IP in right panel and make it enable
after that you can able to access sql server remotely by using ip address in server name
Follow the below mentioned steps to connect to SQL server remotely on a remote desktop:
Configure SQL Server machine
Windows Firewall ->Advanced Settings->Inbound Rules.
Run SSMS (SQL Server Management Studio) on SQL Server machine.
Server Properties - > Connections -> Allow Remote Connections ..”
Add a SQL login (if not already there)
Enable SQL Service to listen on TCP/IP.
Restart SQL Server Service.
Related
I have a SQL Server version 12.0 instance installed on a Windows Server 2012R2 (SERVER/SQL), and a SQL Server Express version 11.0 instance installed on a windows 10 workstation (WIN10/SQLEXPRESS). Both are on the same domain. I am logged in as the domain admin and have full rights on both SQL instances.
On my WIN10 machine I am able to create a linked server from (WIN10/SQLEXPRESS) to (SERVER/SQL).
On my SERVER when I attempt to create a linked server from (SERVER/SQL) to (WIN10/SQLEXPRESS) I am told to ensure that the instance will allow for remote connections. I have gone through about 40 hours of troubleshooting this, ensuring that all firewalls, ports, security and agents and browsers are open.
Is there any reason I cannot link a SQL Server Express to another SQL Server, but can the other way around?
I would like to be able to call stored procedures from my main SQL Server but am not able to.
Please note, the purpose for the SQLEXPRESS on the WIN10 machine is due to the vendor requirements for the software I am using. Otherwise I would have the instance on my SERVER.
Almost certianly a network issue.
Using SQL Server Configuration Manager configure SQLEXPRESS to enable TCP/IP and listen on a fixed port, preferably 1433 if no other instance is on the server. Restart the instance.
Create a Windows Firewall rule enable inbound TCP/IP connections to the port.
Test network connectivity to the target port from the other server with powershell, eg:
PS C:\> test-netconnection WIN10 -Port 1433
Test SQL connectivity with SQLCMD or SSMS on the server to the WIN10 box.
Create the linked server.
i moved my website on a server, it have installed web application and SQL server instance (this site is only for private network), if i try to access sql instance from SSMS it connect without problem, but when i try to access data from my website or SSMS installed on another pc connected to the same network it's says me that instance name is not correct or firewall block sql server ports. Sql connection string is correct, both SQL Server and SQL Browser services are active, named pipes and TCP are enabled, and i've added rules to firewall to allow connection from port 1433 and 1434(this one is for UDP) but i've the same problem, any help?
Using SQL Server 2008 R2
I have 2 SQL Server instances on my PC, SQL1 and SQL2.
I have Windows XP installed in a VirtualBox. In XP, I have an application which can connect to SQL Servers.
When I try to connect to SQL1, everything is fine, but when I try to do that with SQL2 it errors out with
Could not open a connection to SQL Server
So I started checking the settings. I can connect to SQL2 using SQL Server Management Studio (on a local PC), so I checked that 'Allow remote connections to this server' was enabled. Also, in SQL Server configuration tool I enabled all protocols for this instance, just as it is for the SQL1. SQL Server browser is working.
Configuration of both instances seem to be identical. There is only one difference between SQL1 and SQL2 that I have noticed.
SQL1 version is 10.50.4000
SQL2 version is 10.50.1600
What can cause one of the instances to be unreachable through the network while the other one can be, and both settings are the same?
It could be firewall settings or network settings. For an instance to be reachable, configure at least the following.
TCP protocol enabled (SQL Server Configuration Manager)
Fixed TCP port (SQL Server Configuration Manager)
Enable SQL Server Browser Service
Open firewall for SQL Browser service (UDP port 1434) if you have a named instance.
Open TCP ports for SQL Server Instances.
See Configure the Windows Firewall to Allow SQL Server Access
Initial Attempt
I have an Azure VM with Windows Server 2012, on which I just installed SQL Server 2012 Express Database Engine component. Then, I followed the instructions here to connect remotely with SQL Server Management Studio.
Create a TCP endpoint for the virtual machine
Open TCP ports in the Windows firewall
Configure SQL Server to listen on the TCP protocol
Configure SQL Server for mixed mode authentication
Create SQL Server authentication logins
Determine the DNS name of the virtual machine
Connect to the Database Engine from another computer
After step seven I received the following error:
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)
(Microsoft SQL Server, Error: 53)
What else do I need to configure before connecting remotely?
Troubleshooting
I have been following the troubleshooting instructions here. Each blockquote below is a step described that that link.
Confirm the instance of the SQL Server Database Engine is installed
and running.
Done. We installed SQL Server Express, and it is running as a named instance called SQLEXPRESS.
If you are attempting to connect to a named instance, make sure the
SQL Server Browser service is running.
Done. We followed the steps here to turn on the SQL Server Browser service.
Get the IP Address of the computer.
Done. We will use these later for testing connectivity and maybe for setting up a static port for SQLEXPRESS.
10.241.62.155
fe80::45c:8c29:e19f:f78b%15
Get the TCP port number used by SQL Server.
Done. The SQL Server Management Studio server logs showed that the server was listening on port 49169.
Enable Protocols
Done. We had already enabled TCP/IP in the configuration manager, but we restarted the SQL Server Service just in case.
Testing TCP/IP Connectivity
Done. We used tcping.exe to test connectivity (cmd ping doesn't work quickly with Azure.) We were able to connect to port 80.
tcping.exe buddha.cloudapp.net > successful
tcping.exe buddha.cloudapp.net 80 > successful
Testing a Local Connection
Done. We used sqlcmd.exe from the command prompt and were able to connect locally via TCP with a username and password.
sqlcmd -S Buddha\SQLEXPRESS (success via shared memory protocol)
sqlcmd -S tcp:Buddha\SQLEXPRESS (success via TCP)
sqlcmd -S tcp:Buddha\SQLEXPRESS -U sa -P (success via TCP with username)
sqlcmd -S tcp:10.241.62.155\SQLEXPRESS -U sa -P (success with internal IP)
Opening a Port in the Firewall
We opened the port on which we SQLEXPRESS listens. The server logs (above) showed that SQLEXPRESS was listening on port 49169, but this is just one of many dynamic ports, and we wanted to set up the static port 1435.
Use WF.msc to create an inbound TCP rule for port 1435.
Use Azure Management Portal to create a TCP endpoint for port 1435.
The troubleshooting instructions also say:
If you are connecting to a named instance or a port other than TCP
port 1433, you must also open the UDP port 1434 for the SQL Server
Browser service.
Since we are connecting SQLEXPRESS (a named instance), we needed to open port 1434 for UDP.
Use WF.msc to create an inbound UCP rule for port 1434.
Use Azure Management Portal to create a UDP endpoint for port 1434
Further research about connecting to named instances revealed dynamic port issues. The reason why we are using port 1435 (static) instead of port 49169 (one of many effective options.)
Instances of SQL Server Express, SQL Server Compact, and named
instances of the Database Engine use dynamic ports. To configure these
instances to use a specific port, see Configure a Server to Listen on
a Specific TCP Port (SQL Server Configuration Manager). and
here.
Done. We went to SQL Configuration Manager > SQL Server Network Configuration > Protocols for SQLEXPRESS > TCP/IP, we did the following.
Protocol Tab > Listen All > NO.
IP Addresses Tab > for each listed address
Enabled > Yes
TCP Dynamic Ports > Blank (delete the zero)
TCP Port > 1435 (or your choice)
After restarting the SQLEXPRESS service, we again looked in the SQL Server Management Studio logs, and found that the Server is Listening on port 1435!!! Hooray!
Testing the Connection
Done. We opened SQL Server Management Studio on our local (non-Azure) computer and connected.
buddha.cloudapp.net,1435 OR buddha.cloudapp.net\SQLEXPRESS
sa
password
Success.
Here are the three web pages on which we found the answer. The most difficult part was setting up static ports for SQLEXPRESS.
Provisioning a SQL Server Virtual Machine on Windows Azure. These initial instructions provided 25% of the answer.
How to Troubleshoot Connecting to the SQL Server Database Engine. Reading this carefully provided another 50% of the answer.
How to configure SQL server to listen on different ports on different IP addresses?. This enabled setting up static ports for named instances (eg SQLEXPRESS.) It took us the final 25% of the way to the answer.
The fact that you're getting an error from the Names Pipes Provider tells us that you're not using the TCP/IP protocol when you're trying to establish the connection. Try adding the "tcp" prefix and specifying the port number:
tcp:name.cloudapp.net,1433
I too struggled with something similar. My guess is your actual problem is connecting to a SQL Express instance running on a different machine. The steps to do this can be summarized as follows:
Ensure SQL Express is configured for SQL Authentication as well as Windows Authentication (the default). You do this via SQL Server Management Studio (SSMS) Server Properties/Security
In SSMS create a new login called "sqlUser", say, with a suitable password, "sql", say. Ensure this new login is set for SQL Authentication, not Windows Authentication. SSMS Server Security/Logins/Properties/General. Also ensure "Enforce password policy" is unchecked
Under Properties/Server Roles ensure this new user has the "sysadmin" role
In SQL Server Configuration Manager SSCM (search for SQLServerManagerxx.msc file in Windows\SysWOW64 if you can't find SSCM) under SQL Server Network Configuration/Protocols for SQLExpress make sure TCP/IP is enabled. You can disable Named Pipes if you want
Right-click protocol TCP/IP and on the IPAddresses tab, ensure every one of the IP addresses is set to Enabled Yes, and TCP Port 1433 (this is the default port for SQL Server)
In Windows Firewall (WF.msc) create two new Inbound Rules - one for SQL Server and another for SQL Browser Service. For SQL Server you need to open TCP Port 1433 (if you are using the default port for SQL Server) and very importantly for the SQL Browser Service you need to open UDP Port 1434. Name these two rules suitably in your firewall
Stop and restart the SQL Server Service using either SSCM or the Services.msc snap-in
In the Services.msc snap-in make sure SQL Browser Service Startup Type is Automatic and then start this service
At this point you should be able to connect remotely, using SQL Authentication, user "sqlUser" password "sql" to the SQL Express instance configured as above. A final tip and easy way to check this out is to create an empty text file with the .UDL extension, say "Test.UDL" on your desktop. Double-clicking to edit this file invokes the Microsoft Data Link Properties dialog with which you can quickly test your remote SQL connection
I have an SQL Server 2008 hosted on a different computer in a different domain. I am able to ping to this machine using the IP address, but not using the machine name. I have also checked the settings of the sql server instance and it is configured to provide access to remote connections.
(Allow remote connections, tcp/ip enabled)
When I try to find this server using Sql server management studio 2008 or VS 2008, I get the error saying that the server cannot be found.
what could be the reason for this?
Please check SQL Browser service is running.
Please make sure you are providing valid authentication details.
Also make sure that TCP/IP connections are allowed by the SQL Server instance by checking the SQL Server Configuration Manager. If you are using an express version of SQL Server then all remote connections are typically disabled by default.
You need to create a trust relationship between the domains I think, it's been a while since I've done things between domains.
Windows Firewall will block SQL Server connection requests from a client machine by default. These are the steps I normally do to allow SQL Server through Windows Firewall:
Windows Firewall-> Allow app or feature through Windows Firewall-> Change
Settings-> Allow another app-> Browse to SQL Server exe (eg: C:\Program
Files (x86)\Microsoft SQL
Server\MSSQL10.SQLEXPRESS\MSSQL\Binn\sqlservr.exe)-> Open-> Add.
Windows Firewall-> Allow app or feature through Windows Firewall-> Change
Settings-> Allow another app-> add SQL Brower service by going to
C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe.
SQL Server configuration Manager-> SQL Server Network Configuration->
Protocols for Your_SQL_Instance-> Right click TCP/IP on the right pane
and enable.
The SQL Server instance does not need to be configured to run on 1433 and therefore no need to open the 1433 port through the firewall. SQL Browser will find it for you whichever port it is running on.