I'm kinda stuck, i'm trying to setup multiple instances on a sql server (seperate vm) as my development database, according to internet documentation it should be correct.
I can perfectly remote connect to my database when the firewall is turned off, but I cannot connect when the firewall is turned on.
So I know it is a firewall issue but i don't see the problem.
Every instance uses a different port.
I have enabled incoming requests to that port from tcp protocol,
I also have enabled ssrp.
I think the last one is not relevant or I should delete that one tough.
Any idea what i'm missing?
Related
I recently installed SQL Server Express 2014 on a series of machines running Windows Server 2012. Seven machines in total.
All but 1 of them live in the same local domain company.local.
A single rogue machine lives in a different public domain public.company.org.
The installation process on this machine on a separate domain was carried out by someone who was not paying much attention to the process and pretty much selected all defaults (a.k.a. a click-click-click installation.) As such, certain features such as SQL Server authentication and remote connectivity were not enabled by default.
We want to connect remotely, via SQL Server Authentication, using SSMS, from development machines in the same local domain company.local. This we were able to easily turn on.
As for allowing remote connections, we found ourselves in more difficulties.
We ensured that firewall rules have are defined to allow inbound connection on ports 1433 for TCP and 1434 for UDP. We verified that that is the case.
We have set this rule to apply to all profiles: Domain, Public, Private.
We ensured that all protocols for SQLEXPRESS are allowed in the SQL Server Configuration Manager, specifically TCP/IP.
We have enabled SQL Server Browser.
We have restarted all services multiple times after our configuration changes.
We have even restarted the machine.
We have also kicked the box.
We are still not able to the SQLEXPRESS instance using either:
machine-name.public.company.com\SQLEXPRESS
machine-name.public.company.com\SQLEXPRESS,1434
<ip-address>\SQLEXPRESS
<ip-address>\SQLEXPRESS,1434
Using SSMS or SQLCMD
Using SQL Server Authentication, with regular logins or sa.
Using windows authentication, with credentials on the remote machine.
Pinging the server shows it is responsive. And we have verified that the ports are indeed open.
As far as we are aware of, we've revised, compared and match all configuration/environment settings from the 6 local machines to the one on the different domain.
When disabling firewall all together at all levels, we are able to connect.
Of course we don't want to leave the door open, so we added a inbound rule to the firewall to allow all sorts of connections to the SQL Server (SQLEXPRESS) service.
QUESTION
So the QUESTION is if what we did is the correct approach?
How come adding this firewall exception for the SQL Server process itself is not required in the other local machines???
I've checked your post twice, but I can't find anything about whether you've allowed remote connections to that SQL Express instance. You've allowed all protocols, sure, but that's not enough.
By default, all remote connections to Express instances are disabled (that includes DAC, too). To check this setting, restart the machine (or SQL instance) and look into SQL Server logs. Specifically, you will be interested in entries started with "SQL Server is listening on ..." - there, you'll find all protocols, ports and addresses the instance is listening on.
If the only IP you're see there is 127.0.0.1, then instance rejects all remote connections, regardless of firewall or anything else.
I don't have 2014 Express to check it, but in 2012 this setting is configured via Configuration Manager, in the "SQL Server Network Configuration" section.
I have read a number of articles on how to configure mirroring on SQL Server 2012. I went through the steps and everything worked until hitting the final step, which didn't work.
When I run this on the Principal:
ALTER DATABASE MyDBName SET PARTNER = 'TCP://1.2.3.4:5022';
I get this error:
The server network address "TCP://1.2.3.4:5022" can not be
reached or does not exist.
When I run the counterpart ALTER statement shown above, but on the Mirror, it works fine.
I have tried all the steps in this troubleshooting article.
Important points:
The Primary and Mirror servers are in different datacenters, not on the same network at all. Not connected by VPN. Completely untrusted by each other.
I can connect to the Mirror via SSMS on the Primary and run queries. And vice versa.
I configured certificates on each server to establish the trust relationship. Everything worked during the setup and config, no errors.
I configured the endpoints on both servers and verified they're active/enabled.
I opened port 5022 on both servers by configuring incoming and outgoing windows firewall rules. I can telnet to the Mirror from the Principal and vice versa - ports appear open, no problems.
In the troubleshooting guide mentioned above, I tried steps 1-6. I didn't try 7, deleting the endpoints and re-creating, because they look perfectly valid and active to me.
Looking for some ideas on this one.
If you can telnet that port from the principal machine everything is fine with TCP/IP and firewall settings.
I can remember that I had a similar issue in the past. Unfortunatly I dont remember the exact solution but it was related to security/authentication of the endpoints and the SQL Server service account not having enough permission on the mirror machine. Unfortunatly the error message is pretty misleading in this case. Script the endpoints and verify their settings, SSMS has no UI for that.
Another thing that you could check is that you have the possibility to also connect to port 5022 from the mirror to the principal machine. You will get the same error message if the connection is not possible from both instances.
Sorry that I cant provide you a proper solution, but maybe that points you to the right direction.
Unfortunately there are quite non-informative error messages in MS SQL. The problem might be an authorization issue and the server still will be saying "network address can not be reached".
Considering "servers are in different datacenters", how the authentication is performed? A MSSQL service (on server1) itself must be runned as a valid db user (on server2, and vice versa) in order to make the mirroring work.
There can be multiple reasons for this to happen.
In your SQL Server Management Studio, if you see a White bubble next to the server instance name, instead of the Green bubble, then you can try the following:
"Allow an app through firewall" and add "Windows Management Instrumentation (WMI)" for Windows Server 2012. If it is Windows Server 2008, you can allow "Remote Administration" through firewall.
Is it meant to be a semi colon?
ALTER DATABASE MyDBName SET PARTNER = 'TCP://1.2.3.4;5022'
The semi colon is used when connecting to IP / Port when using management studio.
I have a Sql Server instance installed on my Azure Virtual Machine. I've changed the port for Sql Server to...let's say 4849. I opened this port in Windows Firewall and established the endpoint for both TCP and UDP. I check to see if the port is open via http://www.yougetsignal.com/tools/open-ports/ and it's still closed. What am I missing here?
I'm utilizing SQL Server 2012 SP1 on Windows Server 2012.
Thanks in advance!
Not sure how this service checks for opened ports, but if it doing so by sending "ping" command then it may not work. You would need to do additional stuff for that to work. Please check this blog post for more details: http://blogs.biztalk360.com/windows-azure-virtual-machines-virtual-network-may-not-ping-automatically/.
Does this need to be accessible to the outside world? If so, you will need to open it on your firewall and have the firewall forward traffic on that port to your VM.
Also, you might need to check the config of your VM network adapter, if it's using NAT to share the hosts IP address, you might encounter problems, depending on what host you're using, I find that bridged mode works best so that the VM can use it's own IP address on the network.
I think you can also try this one to enable PING command for Azure virtual machine: http://blogs.biztalk360.com/windows-azure-virtual-machines-virtual-network-may-not-ping-automatically/
In my development shop, we deploy code on virtual servers that sit on a remote network.
We access the machines on that network by first opening an SSH connection to a gateway server, and then SSH-tunneling RDP over a local port.
I would very much like to be able to locally access SQL Server instances running on these servers in the same way.
I've set up a local port (3398) to redirect to the SQL Server port on the remote instance (L3398 -> remote.machine.com:1433).
I can then actually test the connection by telnetting to localhost 3398, and I get a connection: the screen clears and I can type characters to some listening process.
But when I try to connect SSMS to localhost:3398, it times out and then claims that there is no SQL Server listening on that port:
Cannot connect to localhost:3398
Additional information:
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. (...)
I am sure that the server accepts remote connections, because I have connected to it remotely while logged in via RDP to a different machine within the remote network.
I have Googled around to know that this is possible; does anyone have some idea why this isn't working, or what I might do to diagnose and hopefully fix the problem?
Thanks!
Instead of connecting to localhost:3398
Use 127.0.0.1,3398
For Authentication type Azure Active Directory - Universal with MFA (Mutli-Factor Authentication), in addition to specifying the port correctly (127.0.0.1,3398), I also had to point the host to localhost.
On Windows, I had to edit my hosts file to include the server host:
127.0.0.1 server.example.com
Then, in SSMS, I could connect to server.example.com,3398, which would perform the MFA correctly.
I could have performed this redirection at a higher DNS level as well.
The issue is probably that SSMS is trying to access the SQL Server Browser Service, which is UDP port 1434. Take a look at http://technet.microsoft.com/en-us/library/cc646023.aspx for an overview of the additional ports you may need to forward to get this to work.
I'm pretty sure I figured out the answer to this, actually.
On the remote network (which we don't control), for security purposes, it appears that the database servers are set up to ignore database requests coming from the gateway machine. So I guess there's just no good solution short of convincing them to give us full VPN access. Thanks everyone for your help.
My company had a machine running SQL Server hosted by a company specializing in such. We have an .NET application that connects to it.
Recently the decision was made to bring the machine in house.
If we use the internal IP of the machine to connect, it works. When we go to an outside network and use the machine's external IP, it fails. The machine answers pings, and all of the ports in the following article have been opened.
http://support.microsoft.com/kb/287932
Any ideas?
are you sure that the server is configured to accept tcp connections? open teh "SQL Server Configuration Manager". "Protocols for MSSQLSERVER" (in the tree) be sure that TCP/IP i set to enabled.
You might need to go to 'SQL Surface Area Configuration', click on 'Remote Connections' in the treeview, then check the 'Local and Remote Connections' radiobutton.
Firewalls
I assume you have enabled TCP/IP, and also the SQL Browser Service.
Also I assume if behind a router/NAT, you have done the required Port triggering/Port forwarding.
The final thing would be make sure all firewalls allow SQL Server through.