In dealing with a hardened SQL Server, connecting may be problematic.
The general idea in hardening any piece of software is basically to decrease its outside surface as much as possible while still allowing the minimum required surface. And if you are trying to interface with a SQL Server that the vendor didn’t intend for you to connect to directly, they may not have documented everything they did during setup for your convenience.
The first couple of things are obvious things to check:
- The SQL Server instance properties are set to allow remote connections
- Your user account is allowed to connect
- The SQL Network Configuration is set up correctly to allow tcp/ip connections via the expected ports
- The SQL Server Browser service is running
- There is no Firewall getting in the way
Seemingly, everything is ok and yet you cannot connect. In that case, it may be that the instance you are trying to connect to has literally been ‘hidden’. There is a registry value called ‘HideInstance’ which signals that the instance should not show up in SQL Server Browser, nor will SQL Server Browser allow you to connect to the instance directly.
This registry value is located in HKLM\Software\Microsoft\Microsoft SQL Server\<INSTANCENAME>\MSSQLServer\SuperSocketNetLib
You could set the HideInstance value to 0 and restart the instance, but it’s always preferable to leave things as they are. In that case, the easiest workaround is to connect directly via tcp.
The thing is: if someone has disabled SQL Server Browsing but still enabled tcp/ip connections, they will have set it up so that the instance uses a fixed port number, or they wouldn’t be able to connect to it themselves. In that case you can find the portnumber in SQL Server Network configuration, and simply connect with the connection string tcp:<IPADDRESS>,<portnr>
So for example for an ip address of 188.8.131.52 and a SQL instance listening on port 55555, the connection string would be tcp:184.108.40.206,55555