That's written for SQL Server 2000, but I don't imagine this aspect has changed much, if at all. This article says you can go further and try connecting to the IPC$ share:
home directory/.ssh/) and with name authorizedkeys. It should be copied to the home directory of the intended user in the destination server. Step 2: Now, we need to copy idrsa.pub key on the destination machine. If SQL Server is using Named Pipes, then I believe if you're able to access shares on the machine, you have adequate network connectivity. If they match then the connection will be established without asking a password. Otherwise, dig through the Windows event log or the SQL Server error log for a message indicating which port is in use by the instance. If it's using dynamic ports, then as long as you don't have multiple instances on the server, netstat -abn is probably the simplest way to find what it's using. Check SQL Server configuration manager to see if it's a specific port, or dynamic ports.
If it's using a different port, or dynamic ports (common with a named instance), then you'll need to determine which port it's currently listening on. That will probably be appropriate in most cases. By default, that's port 1433, so this should work: telnet servername 1433
If the server is using TCP/IP, then the simple way is to just telnet to the SQL Server port and see if it connects.
0 kommentar(er)
