Windows Server 2019 – Your networking toolbox

How to run your first application on Kubernetes

Whether you are a server administrator, a network administrator, or a combination of the two, there are a number of tools that are useful for testing and monitoring network connections within the Windows Server world. Some of these tools are baked right into the operating system and can be used from the Command Prompt or PowerShell, and others are more expansive graphical interfaces that require installation before running. The following are the network tools that we are going to look at:

  • ping
  • tracert
  • pathping
  • Test-Connection
  • telnet
  • Test-NetConnection

All the these tools are free, though, so you have no excuse to delay getting acquainted with these helpful utilities.


Even the newest of IT pros are usually familiar with this one. ping is a command that you can utilize from a Command Prompt or PowerShell, and it is simply used to query a DNS name and/or IP address to find out whether it responds. Ping is and has always been our go-to tool for testing network connectivity between two devices on a network. From my Windows 10 client on the LAN, I can open a prompt and ping <IP_ADDRESS>. Alternatively, because I am using DNS in my environment, which will resolve names to IP addresses, I can also use ping <SERVERNAME>, as shown in the following example. You can see that my server replies to my ping, letting me know that it is online and responding:

Ping traffic is technically called ICMP traffic. This is important because ICMP is blocked by default more and more often these days, with firewalls being turned on by default on so many of our systems and devices. Historically, ping was always a tool that we could count on to tell us fairly surely whether connectivity was flowing between two devices, but that is not the case anymore. If you build a brand new Windows box and plug it into your network, that computer may be communicating with the internet and all of the servers on your network just fine, but if you try to ping that new computer from another machine on your network, the ping will probably fail. Why would that happen? Because Windows has some security measures built into it by default, including the blocking of ICMP traffic in the Windows Firewall. In that case, you would need to either turn off the firewall, or provide it with an access rule that allows ICMP traffic. Once such a rule is enabled, pings will start replying from this new computer. Keep in mind whenever building new systems or servers in your network that ping is not always the most trustworthy tool to depend upon in today’s networking world.

It’s easy to allow ICMP responses by plugging a rule into the Windows Defender Firewall with Advanced Security, though you still wouldn’t want to have to remember to do this manually on every new system you introduce into a network. Thankfully, you already know how to utilize Group Policy in order to build a GPO and push it out to all machines on your network, and yes you can absolutely place firewall rules inside that GPO. This is a common way to allow or block ICMP throughout an entire organization, by issuing a firewall rule via Group Policy.


tracert, which is pronounced Trace Route, is a tool used to trace a network packet as it traverses your network. What it really does is watch all of the places the packet bumps into before hitting its destination. These bumps in the road that a network packet needs to get through are called hops. Trace route shows you all of the hops that your traffic is taking as it moves toward the destination server or whatever it is trying to contact. My test lab network is very flat and boring, so doing a tracert there wouldn’t show us much of anything. However, if I open up a PowerShell prompt from an internet-connected machine and tracert to a web service, such as Bing, we get some interesting results:

If you utilize tracert but are not interested in seeing all of the DNS information provided in the output, use tracert -d to focus only on the IP addresses.

This information can be extremely useful when trying to diagnose a connection that is not working. If your traffic is moving through multiple hops, such as routers and firewalls, before it gets to the destination, tracert can be essential in figuring out where in the connection stream things are going wrong. Given that the preceding screenshot shows a successful trace route to Bing, now let’s see what that it looks like when things are broken. I will unplug my internet router and run the same tracert again, and now we can see that I am still able to communicate with my local router, but not beyond:


tracert is useful and seems to be the de facto standard for tracing packets around your network, but this next command is even more powerful in my opinion. pathping essentially does exactly the same thing as tracert, except that it provides one additional piece of crucial information. Most of the time, with either of these commands, you are only interested in figuring out where in the chain of hops something is broken, but often when I’m setting up servers for networking purposes, I am working with servers and hardware that have many different network cards. When dealing with multiple NICs in a system, the local routing table is just as important as the external routers and switches, and I often want to check out the path of a network packet in order to see which local NIC it is flowing out of. This is where pathping becomes more powerful than tracert. The first piece of information that tracert shows you is the first hop away from the local server that you are traversing. But pathping also shows you which local network interface your packets are flowing out of.

Let me give you an example: I often set up remote access servers with multiple NICs, and during this process we create many routes on the local server so that it knows what traffic needs to be sent in which direction, such as what traffic needs to go out the Internal NIC, and what traffic needs to go out the External NIC. After completing all of our routing statements for the Internal NIC, we test them out by pinging a server inside the network. Perhaps that ping fails, and we aren’t sure why. I can try a tracert command, but it’s not going to provide me with anything helpful because it simply cannot see the first hop, it just times out. However, if I try a pathping instead, the first hop will still time out, but I can now see that my traffic is attempting to flow out of my EXTERNAL NIC. Whoops! We must have set something up incorrectly with our static route on this server. So then I know that I need to delete that route and recreate it in order to make this traffic flow through the internal NIC instead.

The following is the same PowerShell prompt from the same computer that I used in my tracert screenshot. You can see that a pathping shows me the local IP address on my laptop where the traffic is attempting to leave the system, whereas the tracert command did not show this information:


The commands we have discussed so far can be run from either the Command Prompt or PowerShell, but now it’s time to dive into a newer one that can only be run from the PowerShell prompt: a cmdlet called Test-Connection; it is sort of like ping on steroids. If we open up a PowerShell prompt in the lab and run Test-Connection WEB1, we get very an output that is very similar to what we’d get with a regular ping, but the information is laid out in a way that I think is a little easier on the eyes. There is also an unexpected column of data here called Source:

That is interesting. I was logged into my DC1 server when I ran this command so my source computer for this command was DC1. But does this mean that I have the ability to manipulate the source computer for the Test-Connection cmdlet? Yes, this is exactly what it means. As with everything in Windows Server 2019 management, the need to be logged into a local server is decoupled. Specific to the Test-Connection cmdlet, this means you have the ability to open a PowerShell prompt anywhere on your network, and to test connections between two different endpoints, even if you are not logged into either of them. Let’s test that out.

I am still logged into my DC1 server, but I am going to use a Test-Connection cmdlet in order to test connections between a number of my servers in the network. You see, not only can you specify a different source computer than the one you are currently logged into, you can take it a step further and specify multiple sources and destinations with this powerful cmdlet. So if I want to test connections from a couple of different source machines to a couple of different destinations, that is easily done with the following command:

Test-Connection -Source DC1, DC2 -ComputerName WEB1, BACK1 

You can see in the following screenshot that I have ping statistics from both DC1 and DC2, to each of the WEB1 and BACK1 servers in my network. Test-Connection has the potential to be a very powerful monitoring tool:

One more useful function to point out is that you can clean up the output of the command pretty easily by using the -Quiet switch. By adding -Quiet to a Test-Connection command, it sanitizes the output and only shows you a simple True or False for whether the connection was successful, instead of showing you each individual ICMP packet that was sent. Unfortunately, you cannot combine both the -Source switch and the -Quiet switch, but if you are using Test-Connection from the original source computer that you are logged intolike most of us will be doing anyway-Quiet works great. Most of the time, all we really care about is Yes or No as to whether these connections are working, and don’t necessarily want to see all four attempts. By using -Quiet we get exactly that:

Test-Connection -Quiet -ComputerName WEB1, BACK1, DC2, CA1

If I were to use Test-Connection in the standard way to try to contact all of the servers in my network, that would turn into a whole lot of output. But by using the -Quiet switch, I get back a simple True or False on whether each individual server could be contacted:


telnet provides quite a bit of remote management capability; it essentially offers the ability to make a connection between two computers in order to manipulate the remote machine through a virtual terminal connection. Surprisingly, we are not here to discuss any of the actual functionality that telnet provides, because with regard to networking I find it is quite useful as a simple connection-testing tool, without knowing anything about what functionality the telnet command itself actually provides.

When we discussed ping , we talked about the downside to ICMP: it is easily blocked, and it is becoming more common in today’s networks not to allow pings to be successful. This is unfortunate since ping has always been the most common form of network-connection testing, but the reality is that, if ping makes our lives easier, it also makes the lives of hackers easier. If we cannot rely on ping to tell us with certainty whether we can contact a remote system, what do we use instead? Another case that I see often is where a server itself might be responding correctly, but a particular service running on that server has a problem and is not responding. A simple ping may show the server to be online, but it can’t tell us anything about the service specifically. By using the Telnet Client commands, we can easily query a server remotely. Even more importantly, we can opt to query an individual service on that server, to make sure it is listening as it is designed to do. Let me give you an example that I use all the time. I often set up new internet-facing web servers.

After installing a new web server, it makes sense that I would want to test access to it from the internet to make sure it’s responding, right? But maybe the website itself isn’t online and functional yet, so I can’t browse to it with Internet Explorer. It is quite likely that we disabled pings on this server or at the firewall level, because blocking ICMP over the internet is very common to lower the security vulnerability footprint on the web. So my new server is running, and we think we have the networking all squared away, but I cannot test pinging my new server because, by design, it fails to reply. What can I use to test this? telnet. By issuing a simple telnet command, I can tell my computer to query a specific port on my new web server, and find out whether it connects to that port. Doing this establishes a socket connection to the port on that server, which is much more akin to real user traffic than a ping would be. If a telnet command connects successfully, you know your traffic is making its way to the server, and the server service running on the port we queried seems to be responding properly.

The ability to use Telnet is not installed by default in Windows Server 2019, or any Windows operating system, so we first need to head into Server Manager and Add Roles and Features in order to install the feature called Telnet Client:

You only need to install Telnet Client on the machine from which you want to do command-line testing. You do not have to do anything on the remote server that you are connecting to.

Now that the Telnet Client feature has been installed, we can utilize it from a Command Prompt or PowerShell in order to do work for us, by attempting to make socket connections from our computer to the remote service. All we need to do is tell it what server and port to query. Then telnet will simply connect or time out, and based on that result, we can see whether that particular service on the server is responding. Let’s try it with our own web server. For our example I have turned off the website inside IIS, so we are now in the position where the server is online but the website is dead. If I ping WEB1, I can still see it happily responding. You can see where server-monitoring tools that rely on ICMP would be showing false positives, indicating that the server was online and running, even though our website is inaccessible. Just below the successful ping in the following screenshot, you can see that I also tried querying port 80 on the WEB1 server. The command that I used for that is telnet web1 80. That timed out. This shows us that the website, which is running on port 80, is not responding:

If I turn the website back on, we can try telnet web1 80 again, and this time I do not get a timeout message. This time, my PowerShell prompt wipes itself clean and sits waiting on a flashing cursor at the top. While it doesn’t tell me yay, I’m connected!, this flashing - cursor indicates that a successful socket connection has been made to port 80 on my web server, indicating the website is online and responding:

After creating a successful Telnet socket connection, you may be wondering how to get back to the regular PowerShell interface. Press the Ctrl+ ] keys together (that second one is a closed bracket key, usually next to the backslash key on your keyboard), type the word quit, and then press Enter. This should return you to a regular prompt.


If ping has an equivalent and improved PowerShell cmdlet called Test-Connection, does PowerShell also contain an improved tool that works similarly to telnet for testing socket connections to resources? It sure does. Test-NetConnection is another way to query particular ports or services on a remote system, and the displayed output is friendlier than that of Telnet.

Let’s walk through the same tests, once again querying port 80 on WEB1. You can see in the following screenshot that I have run the command twice. The first time the website on WEB1 was disabled, and my connection to port 80 failed. The second time, I re-enabled the website, and I now see a successful connection.

Test-NetConnection WEB1 -Port 80

Packet tracing with Wireshark or Message Analyzer

Eventually, you might need to look a little deeper into your network packets. Now we are entering territory where your network team may also be involved, but if you are familiar with these tools, you may be able to solve the problem before needing to call for assistance. Making use of command-line tools to check on the status of servers and services is very useful, but occasionally it may not be enough. For example, you have a client application that is not connecting to the application server, but you don’t know why. Utilities such as ping and even telnet might be able to connect successfully, indicating that network routing is set up properly, yet the application fails to connect when it opens. If the application’s own event logs don’t help you troubleshoot what is going on, you might want to take a deeper look inside the network packets that the application is trying to push toward the server.

This is where the Wireshark and Message Analyzer tools come in handy. Both are free and easily downloadable, and they perform basically the same functions. They are designed to capture network traffic as it leaves from or arrives at a system, and they capture the information that is inside the packets themselves so that you can take a deeper look into what is going on. In our example of an application that cannot connect, you could run one of these tools on the client computer to watch the outgoing traffic, and also on the application server to watch for the incoming traffic from the client.

Each tool has quite a bit of individual functionality and we don’t have the space to cover all of it here, so I will leave you with links from which to get these tools so that you can test them out for yourself:

  • Wireshark:
  • Microsoft Message Analyzer:


The tools that we have discussed so far are great and can be used on a daily basis for poking and prodding individual resources that you want to test, but sometimes there are situations where you need to step back and figure out what it is you are looking for in the first place. Maybe you are working with an application on a computer and are not sure what server it is talking to. Or perhaps you suspect a machine of having a virus and trying to phone home to somewhere on the internet, and you would like to identify the location that it is trying to talk to or the process that is making the call. In these situations, it would be helpful if there was a tool that you could launch on the local computer that shows you all of the network traffic streams that are active on this computer or server, in a clear and concise way. That is exactly what TCPView does. TCPView is a tool originally created by Sysinternals; you may have heard of some of their other tools, such as ProcMon and FileMon. Running TCPView on a machine displays all of the active TCP and UDP connections happening on that computer in real-time. Also important is the fact that you do not need to install anything to make TCPView work; it is a standalone executable, making it extremely easy to use and clear off a machine when you are finished with it.

You can download TCPView from

Simply copy the file onto a computer or server that you want to monitor, and double-click on it. The following is a screenshot of the TCPView interface running on my local computer, showing all of the connections that Windows and my applications are currently making. You can pause this output to take a closer look, and you can also set filters to pare down the data and find what you are really looking for. Filters get rid of the noise, so to speak, and enable you to look more closely at a particular destination or a specific process ID:

Comments are closed.