One of our partners recently reported that our software could not contact a remote instance of SQL Express until they started the RPC Locator and SQL Server Browser services. Where would I find a list of services that must be running, on both server and client, to enable remote access to SQL Express and/or SQL Server?
Sadly, the SQL Express documentation does not appear to include this detail.
SQL Express always installs as a named instance (servername\sqlexpress) and hence has a dynamic port assigned to it. The SQL Browser service is required for clients to locate the instance. Without the SQL browser, a client won't know what port the service is listening on.
Looking at my current installation of SQL Server, I have remote connections enabled and working and both RPC Locator and SQL Server Browser services are disabled on the machine.
The key is that you have to enable remote connections properly in the Surface Area Configuration Wizard.
I've experienced problems in the past running linked server queries if the MS DTC (Distributed Transaction Co-ordinator) service was not running
I don't know of any services that need to running on the client (unless they're application dependencies), but for the server, this KB article explains how to enable remote connections to SQL Server: http://support.microsoft.com/kb/914277.
By default, SQL Express is configured to only allow local connections. The gist of the article is: use the Surface Area Configuration tool to tell the SQL service to listen on tcp/ip and/or named pipes; then enable the SQL Browser service (or don't, and use a specific port in your client connection); and finally, poke a hole in your firewall. Anecdotally, I think most people have the most trouble with the firewall exceptions.
I think the RPC Locator service is more of a general windows service for handling COM calls, so I'm not sure it's fair to characterize it as a SQL-specific requirement; your app may require it to connect, but I don't know that every app would (e.g. Mitchel says that his installation works fine w/out it).
Related
I’m having a very specific issue with Azure and I couldn’t find any solution on the web.
So, we are little by little migrating our client’s infrastructure to Azure and we are starting with our Workers (webjobs).
These webjobs need to consume data present on a AWS SQL Server instance.
We already have checked that the App Service Plan’s Outbound IPs are whitelisted and that the SQL server is listening on TCP port 1433.
An evidence of that is the fact that we are able to communicate with the SQL Server instance through the Azure Debug Console:
But when we run the WebApp, the worker cannot find and connect to the same DB:
Does anyone have a clue of how I can solve this issue? It would be very appreciated!
Well, as you demonstrated by the first image, the SQL Server instance is configured correctly.
The worker Outbound IP address is definetely the same as the App Service Plan's machine.
Based on that, can you then please check if the Connection string you are setting have 'tcp:' before the IP Address?
Sometimes you need to force it, otherwise IIS can choose other ways to connect to your SQL server (like UDP for instance).
I am new to workflow stake and don't have good knowledge in networking.
Can someone please tell me if I have an application server in DMZ which connects to SQL server instance which is not in DMZ, Is there any difference if i connect to SQL server or SQL Server instance. I am able to make connection to the SQL Server but once i try to try the instance it won't find the instance.
I.e. Can connect to sqlservername but not to sqlservername\instanename the error i am getting is the SQL Server instance can't be found. the instance is setup to allow remote connection. Hope my question make sense.
Regards
You can't connect to named instance? - as minimum you need to enable remote connections to this server from SSMS->Server->Properties->Connections or you can read, for example, this article for more information how to do that. And... be sure that Sql Server Browser service is started and feels good, because it's responsible for managing connections to named instances.
The main issue with DMZ in my experience is dealing with authentication. Domain users usually can't access DMZ so, services such as Analysis Services (known as Cubes) for example, which allow only windows authentication, will be not accessible from the application server without extra efforts, establishing for example, kerberos auth.
I want to access SQL server via an application (it is a desktop application) which is installed on remote location, where as SQL server installed in Main Office, where other applications are also accessing same SQL server on LAN.
Is it possible to do it?
Yes, technically this is not problem. Once installed, SQL Server will react both on the internal IP and external - if the Firewall is configured to forward SQL-Server Traffic (TCP 1433).
BUT - from security point it's not a good idea to expose your SQL Server directly to the internet. In the past there have been several security problems that would have exposed more than you wanted to expose. I would suggest external users, not inside your LAN use a VPN Connection to get inside your internal Network. I work every day over VPN with SQL Server and it's stable and secure.
I need to transfer data daily from SQL Server (2008) to SQL Server (2005). One of the servers is located at our web host so the data will be transferred over the Internet. On the same network I would use SSIS to transfer the data, but over the Internet this is not a secure option. Is there a secure way of achieving this?
You can use SSL with SQL Server (2000/2005 Instructions / 2008 Instructions) and then force protocol encryption on the connection between both machines. You don't have to use a purchased SSL certificate either, you can use Windows Server Certificate Services to generate one - however if you do so then the CRL must be on a machine that both servers can connect to. An easy way to do this is install Certificate Services on a stand alone machine, perhaps just a VM and the configure it to embed a public DNS name for it's CRL. This doesn't have to be a machine running Certificate Services, just something you own and can upload to. Then you can generate the certificates and publish the CRL and tada, all done.
You will need to ensure the service account SQL is running as has access to the private key of the certificate it is using.
Generally it isn't recommended to have your SQL Servers exposed to the Internet, although that may be out of your control in this case. In your position I would investigate developing some separate Web Services that would perform the transfer of the data. These can then be secured using a variety of methods, such as SSL and WS-Security and other custom user permissions. If that isn't possible then blowdart's answer seems like the way to go.
You can use Service Broker:
Built into SLQ Server engine itself, no need for external process to drive communication.
Compatible protocol SQL 2005 and SQL 2008 communicate over Service Broker out-of-the box.
No need to expose either server to the internet. Through Message Forwarding you can expose
just a SQL Express, with no data on it, to the internet to act as a gateway that lets messages into the back end target.
Communication is encrypted.
Speed, the sample in the link shows how you can exchange over 5000 1k payload messages per second between commodity machines.
Unlike SSIS or replication Service Broker is a general communication framework so it won't provide support to extract the changes and to apply the changes, with conflict resolution and the like. You would have to code that part yourself.
How do I connect to an SQL Server remotely and administer my database objects? I need to connect to my database located on the web hosting company's server. I have the server name, IP address, my database username & password. I have an installation of SQL Server 2000 in my machine.
Can I use SQL Server Enterprise Manager for this? A step by step guide would be very helpful.
Yes, you can use Enterprise Manager (or SQL Server Management Studio, even if it's an Express version) to connect to any SQL Server (of the same or lower version as the tool you're using) you have TCP/IP connectivity to. Just launch it, enter the DNS host name or IP address in the 'Server Name' box and hit Connect.
Two things may prevent this from working:
Your SQL Server isn't set up for TCP/IP connectivity. This is the default setting from version 2005 onwards, and can be changed using the SQL Server Configuration Manager.
There is a firewall between you and your SQL Server blocking TCP/IP traffic. This is an entirely sensible construction: you do NOT want your database server to be available from the general Internet, as this is a huge security risk. In fact, if your hosting company allows this kind of access by default, I'd be looking for a different provider...
Anyway, what seems to be needed in your scenario is: a) the hosting company enabling TCP/IP on your SQL Server instance, b) them providing you with secure access to the IP address that instance is running on.
This will involve some kind of VPN or SSH port-forwarding soluition, or at least an IP filter, where only 'trusted' IP addresses can access the SQL Server (which is not a great solution, but can be used if nothing else can be implemented). You'll have to discuss these requirements with your hosting company.
Yes you can do this but how you do this will be dependent on your hosting setup.
As Brannon suggests you will need to open port 1433 on the firewall. This would be a dangerous thing to do on its own so you would combine it with a VPN. It can be quite tricky to set this up through and you could end up blocking yourself from access to the server and needing the hosting companies help to reset it.
Another option would be some of the web management tools such as:
http://www.microsoft.com/downloads/details.aspx?familyid=C039A798-C57A-419E-ACBC-2A332CB7F959&displaylang=en
http://www.mylittleadmin.com/en/welcome.aspx
It is possible, but a lot of things need to align for you to be able to connect.
Enterprise Manager and SQL Management Studio just use a standard client connection to SQL. The default TCP/IP port is 1433, but the host needs to allow that port through the firewall. If you are using a named instance, then I believe you also need to be able to connect to port 1434.
Most administrators do not allow direct access to the SQL Server from outside the firewall. In that case, if you can connect to the host over VPN then you should be able to connect directly to the server with Enterprise Manager or SQL Management Studio.