April 28, 2010 at 2:53 pm
All
our remote developers cannot launch SQL Server management studio after they establish VPN connection.
we have developers who must connect to our sql servers in our network in order to do some work but for some reason after they establish VPN connect they are not able to launch Management Studio.
I tried myself and i have the same error message, so that only way for me to have access to the SQL servers is for me to RDP into my desktop at work and them launch it
i have look around the web and not seems to find any solutions to this
I have asked my network engineers to check the VPN profile and there is nothing blocking sql port
Any tips
April 29, 2010 at 6:15 am
How about posting that error message?
first thought is that this is probably network related. Can you telnet to the sqlserver over port 1433... i.e. if you execute the following from a command prompt:
telnet servernameyouuseexactlyasinmgmtstudio 1433
Do you get a "could not connect" (bad) or black screen (good)?
April 29, 2010 at 6:25 am
Are there global policy restrictions on launching applications from entry through a VPN tunnel?
Could the VPN tunnel be such a memory hog that the system doesn't have the resources to launch SSMS? (Start a PerfMon trace and then log into the VPN connection, then try to open SSMS).
Check the Event log to see what's going on also.
EDIT: Check the Surface Area Config to see if SQL *allows* remote activation
April 29, 2010 at 6:30 am
most likely a DNS issue. is your internal AD DNS zone totally separated from the outside world and not published?
i've had the same problems and i either RDP to an office computer or i have a virtual WIndows 7 instance on VMWare that I use when away from the office
May 5, 2010 at 2:31 pm
i have attached a screen shot of the error i got to my reply
Thx
May 5, 2010 at 2:50 pm
Try using fully qualified server name... error message shows "error connecting to server\instance".
Change connection to look for servername.domain.com\instance
(of course by domain.com, I mean whatever the fully qualified name of the server is)
Also- get down to basics. Set aside managment studio for now and go to the command line. Can you ping the server? can you ping it using fully qualified name? can you telnet to it over port 1433? It's a named instance, what port is it listening on if not default?
May 6, 2010 at 4:27 am
nana.asare (5/5/2010)
i have attached a screen shot of the error i got to my reply
Read the error carefully. See where it says "or Remote connections are not allowed?"
Brandie Tarvin (4/29/2010)
Check the Surface Area Config to see if SQL *allows* remote activation
In case you don't know what this means, log into the server itself (NOT through the VPN), and navigate to this path: Start -> Programs -> Microsoft SQL Server 2005 -> Configuration Tools -> SQL Server Surface Area Configuration.
A window will pop up. Choose Surface Area Configuration for Services and Connections. Another window will pop up. Open up Database Engine. Click on Remote Connections. The right hand pane will change. Make sure the "Local and remote connections" radio button is picked. Then verify which network protocols you want to use and click that.
If VPN is using Named Pipes and you've got "Using TCP/IP only" checked, you won't be able to use VPN to connect to the server. Reverse that and the same is true. So make sure whatever network protocols you're using for VPN is what's chosen here.
May 6, 2010 at 4:48 am
Are u able to open any website from ur local machine while RDP?
Are u using any cencrypted login or any other security device for RDP?
May 6, 2010 at 5:08 am
Try right mouse click on the short cut for SSMS and choose run as administrator. When you VPN, the network does not recognize you and being on that domain so windows authentication does not work. You remain on what ever domain you are remote connecting from.
May 7, 2010 at 1:06 pm
When we have this issue it's due to the firewall rules not allowing any netbois name queries to pass the connection. Try connecting with the local IP of the server.
Or make sure you have the local AD DNS and/or WINS server pointing correctly.
Sometimes you may need a route statement on the server to route traffic back to the VPN subnet as they are usually a seperate subnet from the internal.
May 21, 2010 at 9:34 am
All
Thanks for the input, i was able to get a workaround. Database was installed with a named instance (eg. ndbd-910\devsq) that is servername and instance name, and that is how developers were connecting which resulted in an error. so what i did was i asked them to drop the instance and and just connect without adding the instance and that seems to be working fine now.
Regards
NAK
May 21, 2010 at 11:04 am
Are you sure they're hitting the correct instance? Because if there's both a named and a default on that server, they're no longer hitting the proper instance.
They may also need to add a port # (myserver\myinstance, 1433) to connect to the proper instance.
May 21, 2010 at 12:27 pm
Good point, currently the environment has only one named instance so i am not sure how that will play out if there were more than one instance on the database server..I will try your suggestion on an environment that has 2 instances installed on the server.
Thx
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply