Home / server / Questions / 343580
In Process
Rob D.
Asked: 2011-12-23 11:43:34 +0800 CST

Why can't I connect on port 445?

  • 772

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.

sql-server networking perfmon server-message-block windows-server-2008-r2

2 Answers

  1. 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

    • 4

  2. 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

    • 0