Over the years I have used a number of tools to check if a remote machine had certain ports open. My two favourites are nmap and PortQry (documentation). nmap is useful because of the power it has, but requires installing a considerable amount of data which can be tricky in some customer systems. One of the reasons I like PortQry is because it is lightweight, consisting solely of an EXE file.
Sometimes even getting a single EXE file onto a system is a difficult goal. One thing about every modern server that will be used for running SharePoint or SQL Server is that it has PowerShell, so I asked myself — How can I check the status of ports on remote machines with PowerShell?
The answer is Test-NetConnection. This cmdlet comes standard out of the box with Windows Server 2012 R2, Windows Server 2016, Windows 8.1, and Windows 10. If you’re building SharePoint 2013 or SharePoint 2016 farms you likely are using one of these Windows Server versions so this cmdlet is available to you today.
The cmdlet is simple and to the point. Want to see if SQL Server is accepting connections on port 1433?
Test-NetConnection -Computername sql.example.com -Port 1433
The best part is the Test-NetConnection cmdlet returns an object so you can use this in scripts and handle situations where an expected network resource is not available.
$testconnection = Test-NetConnection -Computername sql.example.com -Port 1433
As an example, here is a test I did on my local machine. I’m not running SQL Server so I expect the first request to fail, and port 135 is the Windows Messenger service which is normally open on a Windows machine. Finally I capture the results of my test into an object and evaluate the TcpTestSucceeded property.
For a SharePoint farm, here are some ports you may need to check:
- SharePoint sites – TCP 80/443
- SharePoint Web Services – TCP 32843, 32844
- SQL Server Database Engine – TCP 1433
- Search services – TCP 808
- Search index – TCP 16500-16519
- Distributed Cache – TCP 22233-22236