0

In Windows 7, I used the following method to connect to a SQL server with a different domain/user:

runas /netonly /user:domain\username program.exe

Source: Connect different Windows User in SQL Server Management Studio (2005 or later)

However, this has stopped working since my Windows 10 update. I now get the following error:

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. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) (Microsoft SQL Server, Error: -1)

I'm using a VPN, that seems to be working (can use Remote Desktop and view intranet pages). I have used this setup on multiple locations, on multiple systems. All used Windows 7 or 8.1, hence why I think 10 is the problem.

Has anyone had any luck fixing this?

Thanks!

Update: I have rolled back to Windows 7 and it immediately works again. Tried pinging the server, gives me a 127.x.x.x address on Windows 10, and the correct IP on Windows 7. No entries in my hosts file. What gives?

Community
  • 1
  • 1
erwinvk
  • 1
  • 2
  • 1
    "stopped working" - in what way? Absolutely nothing happens? An error message? Management studio still launches but uses the wrong account? Also, we're not mind readers - you may have tried "lots of stuff" but how are we to know *what* you've tried unless you tell us? – Damien_The_Unbeliever Aug 03 '15 at 07:42
  • WIndows 10 didn't change how domain security works. Is your computer still part of the domain? Is the computer's name the same ? Have you logged in with a domain account? – Panagiotis Kanavos Aug 03 '15 at 07:48
  • @Damien_The_Unbeliever Thanks, have changed this. – erwinvk Aug 03 '15 at 07:49
  • The message isn't related to authentication. It's a connectivity problem. It means that the target computer wasn't found. Either your VPN connection doesn't work or you typed the wrong name. *Can* you ping the server? Or telnet to SQL Server's port? Did you try using the IP instead of the name? – Panagiotis Kanavos Aug 03 '15 at 07:50
  • @PanagiotisKanavos Hmm, I can't telnet to it. Pinging gives me a 127.0.53.53 address... That doesn't seem right. I think I'm going to roll back to 7 and see if that does still work. – erwinvk Aug 03 '15 at 08:10
  • @PanagiotisKanavos Rolled back, and it's working again. Ping gives me a different IP now. Very strange. Have no entries in hosts file. – erwinvk Aug 03 '15 at 08:34
  • This is a connectivity, not a Windows issue. Instead of rolling back you should check your VPN setup. If your connection depends on your machine having a specific IP, anything that changes it will cause problems, either at your end or at the remote network. The administrator may have set up restrictions on the IP ranges allowed. – Panagiotis Kanavos Aug 03 '15 at 08:44
  • I agree that it looks like a connectivity issue, but nothing has changed except for my version of Windows. Had reinstalled the VPN software as well - and that works fine for any other task (remote desktop, internal webpages). The computer hadn't been assigned an IP address. I have used this setup from multiple locations and on multiple computers (running win 7 and 8.1). – erwinvk Aug 03 '15 at 08:55
  • I suspect that the SQL Browser account has stopped since the Windows upgrade. – Steve Matthews Aug 03 '15 at 09:22

1 Answers1

0

I had the exact same problem. This workaround on TechNet worked for me. The short answer is to add an entry to your hosts file when running Windows 10. Then use the hostname instead of the IP address to connect to the database in SSMS (yes, this is counter-intuitive, but it worked for me).

It's fun to note that this only affected the DB running on 192.168.xx.xx. I have another DB running on 172.17.xx.xx and could connect to that one just fine without this workaround.

It was also devilish that this issue occurred only intermittently. Sometimes, I could connect to the DB in SSMS.exe without this workaround and sometimes I couldn't.