Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I'm having an issue with remote debugging. I have a non-domain server and a non-domain client PC. The client PC can successfully connect to the server and the instance, and it even runs SSMS as the context of the local administrator account of the server. But even with all this set up, when I try to debug in SSMS I get the following error:

Unable to start T-SQL Debugging. Could not attach to SQL Server process

I have followed all of these steps and checks from this Resource:

Test 1: When you locally connect to the same instance the issue is not reproduced

Test 2: Check if TCP 139, TCP 445, UDP 137 and UDP 138 are open from both side (server and client) (e.g.: Configuring the Transact-SQL Debugger )

Test 3: Check if SQL management Studio is lauched with "Run an administrator..."

Test 4: Check if SQL service account can connect to the client machine. When you are using T-SQL debugging, SQL service account will communicate with the machine host Management Studio.It's an additional reason to set up SQL service with domain account

Test 5: Check if SSMS and SQL server service are in the same domain. if not, set up the same account and password that SQL server is using.

Test 6: Check if your domain account is sysadmin.

Test 7: Check if Kerberos is enable correctly and SPN are ok for your instance. - The SQL Network Interface library was unable to register SPN - SQL Server 2008 connectivity issue : cannot generate SSPI context

Test 8: Check from server side that the service below are started - TCP/IP NetBIOS Helper - Remote Registry - RPC Service


Test 5 is the only one I haven't done, because I'm not working within a domain. These are all local accounts. My question is, what else could be causing this issue? Does remote debugging require a domain???

share|improve this question
add comment

1 Answer 1

I don't know anything about Remote Debugging, but you can use Windows Authentication between two computers on different domains or with no domain, if they have an identical user account with the same password.

  1. On the client machine, create a Windows account UserSQL, with password test123
  2. On the server, create a windows account UserSQL, with password test123
  3. On the server in SSMS, add UserSQL to the sysadmin role
  4. On the client, run SSMS as UserSQL and connect to the server using Windows Authentication.

One other question. When you connect to the SQL Server instance from the client computer, are you using an IP address or the name of the Instance? I'm not sure if this is true or not, but whenever I have used Windows Authentification to connect to SQL Server, I use the instance name. If that is not possible because they are on two different networks, then you would have to setup an alias on the client machine in SQL Server configuration manager to associate the IP address with the distant sql server.

--edit

I just had some additional thoughts after reading a similar article in Microsoft's forums

http://social.msdn.microsoft.com/forums/en-US/sqlnetfx/thread/840841cc-ae4a-45fc-b1ab-0708dc4403c0/

Is there an external firewall between the two computers? From the client, can you do a telnet to each one of the ports from the command line

I.E. from the dos cmd prompt you type

telnet serveripaddress 139

telnet serveripaddress 445

Is the user that you're using to connect to the server instance in the sysadmin role? Can you debug locally?

share|improve this answer
    
thanks for the reply, I am actually using the same Windows Auth login on both machines, I got that working. And they are on the same network, so I do use the named server\instance. –  Thomas Stringer Nov 23 '11 at 13:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.