Im bardziej skomplikowana i zabezpieczona jest infrastruktura sieciowa, tym trudniej jest diagnozować występujące problemy. Weźmy na przykład kwestię serwera, do którego nie można się połączyć przez RDP lub do serwera SQL. Jeśli serwer występuje w tej samej sieci, w tym samym segmencie, to jednym z podstawoych testów, jakie mogły by być wykonane jest ping sprawdzający czy serwer w ogóle odpowiada i jest włączony. Niestety jeśli między maszynami znajdują sie zapory sieciowe (firewall), to ping może nie działać (wyłączony ICMP), ale połączenie RDP (port TCP/3389. UDP/3389) lub SQL (tcp/1433) mogą być dostępne.
Do niedawna w takich przypadkach korzystałem z polecenia portqry.exe, np
portqry -n <server_name> -t <protocol> -e <port_number> portqry -n CANTOR10 -t tcp -e 3389
Nie wszyscy są świadomi, że właściwie na nowszych systemach wcale nie ma potrzeby korzystania z zewnętrznego programu. Można korzystać z cmdlet Test-NetConnection:
Test-NetConnection -computer CANTOR10 -protocol tcp -port 3389
Można zaryzykować stwierdzenie, że Test-NetConnection to taki „ping na port”. Niektórzy w celu sprawdzenia otwarcia portu korzystają również z polecenia telnet otwieranego na określony port. Wydaje się jednak, że Test-NetConnection robi to co należy i jak należy w stosunkowo prosty sposób.
