9

I need to collect baseline performance data on a SQL Server running on Windows Server 2008 R2. When I open perfmon on my computer running Windows 7 and try to add counters from the remote server, I receive an error stating "Unable to connect to the machine."

I can ping the server, and I can connect using Remote Desktop.

In addition to the perfmon issue, I cannot browse shares (e.g. \uncpath\c$), connect to the remote registry, or connect to port 445 over telnet.

I'm on the same subnet as the server, and the Windows Firewall is turned off on both the server and my computer.

Rob D.
  • 233
  • 1
  • 3
  • 10
  • 2
    It may seem obvious, but have you verified there's actually something *listening* on the target machine? (do connections work from `localhost`? Does `netstat` show listeners where you expect them?) -- Assuming everything else you're reporting is accurate the only reason I can think of that you can't connect to this host is that it's not listening... – voretaq7 Dec 22 '11 at 20:29
  • Doesn't perfmon use RPC or ADMIN$ shares to poll it's data? Is RPC blocked somehow? – Tim Dec 22 '11 at 21:41
  • 2
    @voretaq7 `netstat -ao` shows the Service process is listening on TCP 445. When logged into the server, I can establish a connection by typing `telnet localhost 445`. – Rob D. Dec 22 '11 at 21:48
  • Any `ipsec` setting? – Remus Rusanu Dec 22 '11 at 22:24
  • @RemusRusanu There are no dynamic or static ipsec policies configured on the server (checked using `netsh ipsec dynamic show all` and `netsh ipsec static show all`). – Rob D. Dec 22 '11 at 22:33
  • I just had an opportunity to restart the server and that has corrected the problem for now. – Rob D. Dec 22 '11 at 23:17
  • Restarting the server resolved the error, and the problem hasn't recurred since. I guess it will remain a mystery. – Rob D. Feb 09 '12 at 03:09

2 Answers2

4

I know this is old but might as well add some answer to this question for future use...

Make sure you can connect

telnet thehostname 445

Or on linux

 nc -v -w3 thehostname 445
 Connection to test-ws1 445 port [tcp/microsoft-ds] succeeded!

Make sure something is listening

C:\Users\Administrator>netstat -ao | find "445"
  TCP    0.0.0.0:445            thehostname:0             LISTENING       4
  TCP    [::]:445               thehostname:0             LISTENING       4

Make sure file and printer sharing is enabled on that interface

enter image description here

The last one got me

KCD
  • 878
  • 3
  • 11
  • 23
  • but if you can't `telnet` then the 'last one' is irrelevant right? – Simon Mar 25 '17 at 04:32
  • If you cannot connect you should resolve that first. There could be a number of things not working but not being able to reach the desired port is a reliable test – KCD Mar 26 '17 at 08:59
  • Every time I tried to turn this option on it just turned itself off and I don't want to risk losing connectivity so I gave up. This is on a godaddy server that's being retired. At home I have uverse which apparently blocks it anyway. – Simon Mar 26 '17 at 09:01
0

tl;dr

If all the things in the answer by @KCD don't help you, including netsh winsock reset and netcfg -d, try removing the virtual NIC and adding a new one (hopefully you're on a VM).

Longer story:

If you cannot connect on port 445 (or really any port, this fix works for many different symptoms where the underlying cause is the same) and it's really* not the firewall, not endpoint protection, not a permissions or DNS issue, or malware, or any of the usual stuff, and the server is listening on the port OK, then it could be a binding issue where the process or 'port' can't bind to the actual NIC itself. I'm a little hazy on the technical details but roughly that's what's going on.

Removing the NIC and adding a new one fixes this, or at least it has for me a couple of times now after spending literally days ruling everything else out.

*Knowing whether it's really not something else on the server, or something in the networking or firewalling on the client or local network, comes down to experience. After you've spent enough hours and days troubleshooting issues, you start to get a feel for when something's a networking or configuration issue, and when you've reached what I call the 'twilight zone' where you need to start trying things that in theory, ought never to be required, but in practice sometimes are

Gostega
  • 161
  • 3