We have a Windows VPS server using SQL Server 2005 for our e-commerce site.
A while back we were suffering from attempts to access the database remotely so someone made changes so that only the IP of the server itself could access data. That was about 18 months ago and everything has been fine since.
However, we now have a second site (hosted on another VPS) that needs to access the same database and I can't get in contact with the person who made the original changes.
I know he was working in the SQL Server Management tool when he made the changes, can anyone point me in the correct direction.
Thanks.
SQL Server 2005 came locked down by default. Rather than SSMS, it also installs the SQL Server 2005 Surface Area Configuration tool, which has a Remote Connections setting where you can limit it to Local connections only.
You may also like to check any firewall on the server, which will have to allow Port 1433 (or different if changed from the default) TCP access from whichever machines you want to access it.
He might have turned the TCP/IP protocol off. In this case only the localhost can access the database. This link describes the procedure for sql server express, but the idea is the same
Related
I have two computers connected to the same switch on the same network with the same subnet, and when I go to either 32 or 64-bit ODBC to create a System DSN and attempt to add a new DSN using the SQL Server Native Client 11.0, the Server list is empty on one but fully populated on the other. I have a local SQL Server on both computers.
The last two entries above are from the computer that is not working. So the SQL Server on the non-working machine has an available instance.
For the computer that is NOT showing any SQL Servers I have tried the following with no success:
Upgraded the OS from Windows 10 to Windows 11
Followed the directions from Microsoft to open ports TCP 1433 and UDP 1434
Made sure the option to hide my SQL server instance is not enabled
Reinstalled ODBC drivers
Checked permissions
Nothing is working. Even my other computer can see my SQL Server instance, but I can't. I can type the server instance manually and that works. But I am dying to figure this out! This makes no sense to me. Also, the computer that works takes almost no time to build the list. On the computer that it's not working, it sits there for a long time before coming back empty.
I thought this could be a permission issue with my account, but it works fine on my other computer using the same account. The only other thing I can think of is it might be a policy issue, but I'm not sure where to go or look for a policy that might affect it. These are both work computers on a domain and even support here can't figure it out.
Any help/direction is appreciated. Thanks!
We've been experiencing a strange issue with SQL 2008 R2 (10.50.1600) installed as a named instance. In order for any external clients to connect, we have a certain procedure we have to follow, but should not have to. Now I did in fact open the TCP/IP and Named Pipes protocols on the SQL server and restarted it, this isn't the problem. We're on an Active Directory Domain (running from Server 2003). The problem exists no matter what OS the server or client is (XP, 2003, 2008, Vista, 7, 64bit, 32bit, etc.). The problem also persists from anything which can connect, for example, SQL Management Studio, ADO (from our applications), etc.
The problem is that before any client can connect to this server, each client machine must first connect to this server through ODBC (and we don't use ODBC). Any attempt to connect to a 10.5 SQL server before doing this results in "Server does not exist or access denied". But once we can connect in the ODBC (through Named Pipes), then everything else starts to work. The same issue occurs both when using the Computer Name and IP Address. In fact, if we want to connect with computer name \ instance name, then we have to do so first in the ODBC, and then if we want to connect via the IP address \ instance name, then we have to do the same also for that.
We've been having to do this on every single client computer. Again, once the ODBC is able to connect to this SQL server through Named Pipes, then all future attempts from that client work.
What could be causing this to occur? How to avoid it? I should not have to do this "ODBC Trick" as we've been calling it. I've never had this issue on any other version of SQL.
The issue might be related to the SQL Browser service. Each sql instance will have a different port number - try connecting from the client as IP Address,Port (e.g. 123.123.123.1,1433) - this will exclude DNS and Browser from the equation
Edit: now knowing that it is browser related, try see why clients can't access SQL Browser (usually Port 1434). Service not started? Possibly firewall blocking?
Microsoft have tied down everything security wise now by default, so any new configuration now generally requires quite a bit of detailed security planning, policy configuration, permissions etc. Welcome to the age of non-trust ;)
You could easily test your connection by creating a simple file. Follow the steps here at "How to test an SQL Server connection": http://teusje.wordpress.com/2012/02/21/how-to-test-an-sql-server-connection/
I don't know how to do this. I opened my SQL Server and connected using Windows Authentication at 10am. Until now, it does not go to the "Explorer".
I checked the services. The SQL Server Browser is running as well as the SQL Server Service. I restarted the service, but this did not solve the problem.
What should I do?
Below is the screen shot of the error.
(note the Server name has bee removed intentionally, I am actually using a server name)
Here's regarding the services I mentioned earlier
Do you mean that you can't see any databases listed in the Object Explorer? If so, click 'Connect' and choose to connect to a Database Engine. This should then list the server in that list.
Or if it is there, maybe it just needs to be expanded?
I assume that connection was working earlier? Maybe you could try to access server using dedicated administrator connection? Here is a brief description:
http://msdn.microsoft.com/en-us/library/ms178068.aspx
Another thing worth checking are protocols used for communication with server (shared mem, named pipes, tcp/ip, via) - check whether they haven't been disabled.
Maybe there is something also with your domain? If you use domain credentials, then maybe SQL Server has problems communicating with it.
If connection was not working before, then check whether you have approved windows authentication access.
In the SQL server configuration manager, there is an item called SQL server network configuration, under protocols, I selected the properties of the TCP/IP protocol. There is a tab "IP Addresses" there, and at the bottom of the list is an entry called IPAll. In my case the TCP port was empty. I entered the SQL standard port 1433 in there and I was able to connect.
This should work!!!
Regards
Mohammed
The server name should be PCNAME\SQLEXPRESS or PCNAME\MSSQLSERVER
How do I connect to SQL Server 2005/2008 using Management Studio or other desktop application over the internet?
Check out WCF Data Services:
http://msdn.microsoft.com/en-us/data/bb931106.aspx
That way, you don't have to totally expose your database server out to the internet, but you get fine grained control over what gets exposed and who (which type of user) can see or modify what.
Marc
I finally solved this by:
Changing default SQL Port to 8080 from 1433 (our ISP was blocking)
Turning off Windows Firewall on the server. I know this is not a long term solution, but at least I was able to pinpoint the problem. I had set two inbound firewall rules to allow port 8080 and SSMS program, on the server. I created an outbound firewall rule on the client for SSMS (but don't think this mad a difference).
I had to change all apps to use the new port instead of the default port. I had to configure our router to handle the new port 8080 and forward to the database server.
I will modify the Windows Firewall settings to see what was blocking SSMS.
DB Server: Windows 7 Pro 64bit 24 GB RAM
If you put 'your' SQL server (any brand, I'm not bashing) on the internet ... it won't be yours for long, unless you add some rather effective security measures ...
I suggest you look into VPN.
To be able to access your database over the internet, you will need to make sure that the server that hosts the database is accessible over the internet and the port that the database instance uses is open on that machine. You will also need to allow remote connections using the SQL Server Configuration Tool.
For Management Studio access I would recommend rather than opening the server to the outside to use a VPN solution that allows you to create a secure connection to the server and from there you can use the server name or IP to connect as if your machine is part of that network.
For the desktop application I would recommend looking into having the data be consumed through a web service or WCF rather than needing to have a direct connection to the database over the internet.
Hope this helps.
Firstly, if we put security consideration on the side, you have to configure SQL server (sql surface area configuration) to accept traffic, then you have to open proper ports on you server and allow inbound traffic thru to your router to the SQL server.
When you open sql server management studio in connect to server window and at the server name type the IP of your server and enter your username and password.
correct format : IP\InstanceName
you should have a user on target database.
I just setup a new Windows Server 2008 machine with an instance of SQL Server 2008 Express. The SQL Browser service does not appear to be working correctly. In Management Studio, browsing for servers shows the hostname of the new server, but not the instance name. When you choose the hostname form the list it doesn't connect. But I can connect manually by typing the hostname\instancename combination.
update 1:
The browser service is running, and I have tried it with several different accounts, including domain administrator which is a bad practice, but I tried anyway for troubleshooting purposes.
I have tried punching the appropriate holes in the firewall, and also completely turning the firewall off.
This is running on a Hyper-V, Windows Server 2008 32 bit guest, which is on a Windows Server 2008 64-bit host. I have done this before (without issues) on this same host, but with SQL 2008 Standard instead of Express.
When I browse for the server in SSMS(Express) on the SQL Server machine, it works fine and shows the whole instance name. When I browse for it on a remote machine (on the same intranet) with SSMS (standard) it just shows the host name.
update 2:
Followed the packets as suggested and found the following
The client sent the broadcast as expected and received correct responses from other SQL Servers on the same network.
The server received the broadcast but did not send a response.
Considering these results, I wonder why the host name ever appears in the client list in the first place. It shouldn't show up at all, right?
update 3:
Spent an hour and a half on the phone with Microsoft support. I learned a few things, but the problem is not yet solved. It was suggested that I try installing an instance of SQL Standard on the same machine. I did that and the new instance exhibits all the same symptoms. The hostname shows up in the browse list only once, not once for each instance.
update 4:
Stackoverflow chose an answer for me thanks to the bounty system, but this question is not answered. Today I tried moving the whole VM to a different host server - everything is exactly the same. The hostname still appears in the browse list, without the instance name.
update 5:
Confirmed that Hyper-V Integration Services are installed on the guest (SQL) server.
check that the browser service is running, it's not turned on by default.
UPDATE1: See if you can install Network Monitor/Wireshark to do a network trace on the SQL Server to see if it's receiving the broadcasts and sending responses. I think this is your best option in troubleshooting this issue. According to MSDN the service uses UDP port 1434, so this is the traffic to watch.
UPDATE2: Does the server have multiple IP's? according to this MSDN article the Windows Server 2008 firewall has issues responding to SQL Browser service broadcasts, even with rules allowing packets through.
I tend not to rely on browsing. You'll get inconsistent results because browsing sends out a broadcast udp/1434 packet and waits for responses back. However, since you are able to connect remotely via SERVERNAME\INSTANCENAME, that aspect of the SQL Browser service is working. If it wasn't, you wouldn't have been able to connect. With that said, to troubleshoot the browsing portion:
Have you tried stopping and restarting the SQL Browser Service?
Have you tried stopping and restarting the instance if that didn't work?
To completely troubleshoot this, unfortunately, you'd have to do packet traces.
Sounds like the browsing service is messed up somehow...
I don't know if you can temporarily take this SQL Server down temporarily. But if so, you may want to try this:
Uninstall all SQL\instances completely.
Run the install of SQL Express 2008
Create a default instance during install (Not a named instance)
Run the installer again and create the default named instance (SQLExpress)
Try connecting to the named instance again. If it works, you can remove the default instance.
I had the same issue in a VM. After shutting down the Firewall it worked.
I just had this same issue. I was not able to see Instance Names in the SSMS Network Servers tab. It turned out that I had set up Hyper-V and created an Internal Network on my local machine. That network was identified as a Public/Guest Network and the Windows Firewall was ENABLED for it, even though my Domain setting has the Firewall DISABLED. Once I disabled that guest network on my computer I could see all the instances.
Machines:
Physical SQL Server 2014 Ent
Windows 8.1 laptop running Hyper-V