The Windows command line is a powerful tool for file management, information gathering and troubleshooting. In this video, you’ll learn about file system commands, format, copy options, Group Policy commands, and much more.
When you’re troubleshooting network problems, you need to understand the configuration of the device that you’re using. So you need to know IP addresses, subnet mask, DNS settings, and other IP address configurations. In Windows, the command that can provide you with all of this information, and much more, is the ipconfig command. This will show you adapter information, IP information for both IPv4 and IPv6, and give you more details on just how this machine may be configured on the network.
This is also a good place to go if you need to know the DNS server this device is using or what DHCP server was used to retrieve the IP configuration. The ipconfig command shows you information about the hostname, IP address, subnet mask, and default gateway for both IPv4 and IPv6.
If you’d like to get more detail about the network configuration, you can use that same ipconfig command but use slash all at the end. You can see you get extensive details on the hostname, any proxy information, and then we include other details in the IP address configuration, including DHCP server and DNS server information.
If you want to know if another device on the network is able to communicate to your device, you may want to use the ping command. Ping is designed to tell you if another device can communicate with you and how long a round-trip time might be when you send information to that device and receive a response. Ping will probably be your most used troubleshooting tool, and you’ll use this when you sit down at a new machine and want to know just where on the network you’re able to communicate.
I’d like to see if a device that’s on the internet is responding to my pings, so I’m going to send a ping to the Quad9 server which is 9.9.9.9, and I will receive back responses from that server. In Windows, ping sends four requests, one every second, and looks for responses coming back from that IP address.
In our example, we received four separate replies from 9.9.9.9. We sent this device 32 bytes of data, and we received back 32 bytes of data. We also can see the round-trip times to this device. You can see one of them is 17 milliseconds, 21 milliseconds, 16, and 16. The last piece of information on these lines is the TTL, or time-to-live. This tells us the number of hops remaining for this packet when we receive this ping reply.
In this example, we don’t know what we started with, so it’s difficult to know how many hops away this device is. But if we see this number change in subsequent pings, we’ll know that something has changed with the path between us and that device. At the bottom, we have a summary of statistics for what we received. We sent four packets and received four packets, so there were zero packets lost, or 0% loss. This was a round-trip time that had a minimum of 16 milliseconds, a maximum of 21, so it averaged about 17 milliseconds to communicate to 9.9.9.9.
Netstat stands for network statistics, and it’s a utility that’s available in Windows, Linux, Mac OS, and other operating systems. There are a lot of different options within netstat, but we’ll look at some of the most popular ones in this video. We’ll start with netstat -a. This will give us a list of all of the devices that we are either connecting to or devices that are connecting to us.
If you’d like to see what application is being used to send or receive this data, you can show the binaries in Windows by using netstat -b. This particular option requires elevation, so you have to run this as an administrator at the command prompt. And lastly, if you would like to see just IP addresses in the netstat command, you could use netstat -n where no names will be resolved, and the results will all be IP addresses.
To be able to use netstat with the -b, or binary option, we need to run the command line as an administrator. So I’m going to choose the command-line option, I’m going to right mouse click, and choose run as administrator. This will ask me if I would like to allow this app to make changes to my device. I do, so we’ll click Yes, and now we have an elevated prompt. We know this because, in the title bar, it shows Administrator Command Prompt.
Now let’s run the netstat command. I’ll start with the first one, netstat -a, and you can see a lot of things go by. Let’s scroll back up to the top, and you can see protocols, local addresses, foreign addresses that would be remote devices, and what state that connection is in. We can see that our device is listening on certain ports, it has established connections to other devices, you can see the IP addresses we’re communicating to, and if we scroll down, we can get IPv6 information that’s very similar to that.
Let’s try the netstat -b. I’m going to try it with just the -b without opening up any other applications, and you can see a number of the applications in use are svchost.exe, SearchHost.exe, and msedgewebview2.exe. Let’s start up an Edge session– I’m just going to start the browser– then we’ll go back to our Command Prompt and run the netstat -b again.
Since we’ve already started new connections to other servers when we started that Edge we’ll scroll up, and you can see all of the different options that are being sent over the network between different IP addresses. And you can see that msedge.exe is the executable that initiated this conversation. We don’t commonly memorize the IP addresses of the web servers that we’re connecting to. Instead we put the fully qualified domain name into the browser bar, so we would type www.professormesser.com to be connected with the Professor Messer web server.
Behind the scenes of course, there is an IP address associated with that web server, and our browser needs to determine what that IP address is so it can make that connection. To be able to perform this resolution between fully-qualified domain name and IP address, we need to perform a query out to a DNS server. And if you’d like to see what that query looks like, you can run the nslookup command. There are many different options available within nslookup, but let’s look at just one single option that allows us to do a lookup of a web server.
Let’s perform an nslookup, and let’s simply add in a fully-qualified domain name such as www.professormesser.com. This will then go out to our DNS server and perform a resolution of that fully-qualified domain name. You can see that we’re using one of the Comcast DNS servers here, and it provides us with an answer of www.professormesser.com being associated with these three IP addresses.
You can see that there are three addresses here because I’ve configured some redundancy with my server, so that if one of these happens to have a problem, there are other IP addresses that you could connect to. Behind the scenes, this is how our browser finds an IP address that it can then use to communicate to the Professor Messer web server.
There are a number of commands within Windows that are very specific to the Windows operating system. Microsoft has summarized a number of these commands under the net command. You can see there’s a net command for accounts, computer, config, continue, and so on. These are Windows commands, so we can use these to connect, view, and share information to a Windows device.
Here are just some of the net commands you might use. Net view can tell you information about what shares might be available on a remote server by using net view, backslash, backslash, and the name of the server. If you wanted to map a drive to that share, you would use net use, you would specify a drive letter, and then specify the server name, and the name of the share. And if you’d like to be able to view the users that are configured on a particular device and make changes to the user account, you can use the user command.
Let’s see what shares might be available on a server that’s on our network. We’ll use the net view command, and we’ll specify a particular server. In this case, we’ll use the SGC server that is our Active Directory server. In this case, we have a number of different shares available. You can see there’s Classified, files, home, NETLOGON, SYSVOL, and Users.
Let’s say we’d like to connect to the Classified share, which we are not currently using on our system. To be able to do that, we would use net use, we would specify a drive letter, such as w colon, and then specify the name of the server. In this case, it’s the SGC ad server, and the name of the share we would like to connect to is called Classified. When we do that, it’ll say that the command is completed successfully, and if we move to our w colon and perform a directory, we can now see all of the classified information that is stored on that SGC server.
It’s useful to know if a device on the network is available and able to respond to our pings, but we might want more information about what routes a particular packet is taking to get to that device and then back again. To be able to view these routes, you can run a program called traceroute. In Windows, it’s abbreviated to “trace-r-t.”
Traceroute uses the ICMP protocol to compile this information, and it takes advantage of a Time To Live Exceeded message that is able to provide us with more information about what routers might be along the way. This uses a mechanism with an IP called TTL, or Time To Live, and although time is in the name, this is really referring to the number of hops, or routers, that we use to get to that device. It’s not referring to the time of day, such as seconds or minutes.
For example, a TTL of 1 would be referencing the first router, and a TTL of 2 would be the second router. Although many routers will respond with an ICMP Time To Live Exceeded message, there are some firewalls or devices that simply will not respond and provide this detail. If that’s the case, there will be lines within the traceroute where you will not be able to determine what the IP address might be. But subsequent routes will show on the screen if they support this Time To Live Exceeded error message.
Here’s how this traceroute works. I put together a network diagram that has three devices– we have Sam, Daniel, and Jack. Sam is going to perform a traceroute to Jack’s device, and there are a number of routers, or hops, along the way that will be identified during the traceroute. So from Sam’s device, we’re going to run a traceroute to 10.10.30.10, which is Jack’s device on the other side of the network.
The first thing that happens is the traceroute message is sent out with a TTL equal to 1. Each packet that hits a router will decrease the TTL by 1, and if the TTL reaches zero, then the message is sent back to the host saying that the TTL time was exceeded. This is exactly what happens in the very first hop of this traceroute, is that the router is going to change that TTL to zero, identify that the Time To Live has now been exceeded, and send that error message back to Sam.
This error message includes the IP address of the device that identified the TTL Exceeded, so that we can put a message up that says there was a 2-millisecond response time. And we receive this first TTL Exceeded from 10.10.10.1, which is router 1. Now the traceroute process sends another message out, but it changes the TTL to be 2.
This means it will get to router 1, router 1 will decrease the TTL by 1, continue sending that packet on its way, the next router will also decrease that number by 1. And at this point, we’ve now exceeded the TTL, and a message is sent back to Sam’s workstation, and traceroute can add another hop to the route of 172.16.1.2, which is router 3.
This process happens again with TTL equal to 3, which means it gets dropped to 2 at router 1. TTL is now 1 at router 3, and we make it to the next router along the way where the Time To Live is exceeded, and a message is sent back to Sam’s workstation where traceroute adds another IP address to the route. And as you’ve probably already expected, traceroute will add another number to the TTL, so it’s now equal to 4.
It gets decreased by 1 at router 1, decreased again at router 3, decreased again at router 4, and finally makes its way down to Jack’s workstation with TTL still equal to 1. Now that Jack has received that message, he can send back an ICMP reply completing the entire route from Sam’s computer to Jack’s computer.
Let’s perform a traceroute. I’m going to perform a tracert. I’m going to specify -d so that there’s no name resolution occurring. We’ll look at just IP addresses for this traceroute, and we’ll do a traceroute to Quad9– 9.9.9.9. This process will take place over a maximum of 30 hops, but I suspect that we’ll be communicating to Quad9 over a much smaller number of hops.
The traceroute is completed now, and we have eight total hops between our device and the device at 9.9.9.9. If all of this is within your own network, you can examine these routes to see if your routing tables are configured properly. If this is to an external device, then you can perform the traceroute now and then later on, perform the traceroute again to see if these routes may have changed.
For example, we could perform this traceroute again and only get to the fourth hop, which means that, for some reason, the fifth hop was no longer there. And since we performed this traceroute earlier, we know what IP address is associated with the fifth route, and that might identify where a problem may be occurring during this route.
Windows also includes utility that combines the functionality of ping with the details in traceroute. This is called pathping. Pathping is included with most modern versions of Windows, and it performs two different phases. The first phase runs a traceroute to build a map between one device and the other. In the second phase, a series of measurements are taken to determine what the round-trip time might be between each one of those hops along the way.
Let’s see what this pathping looks like. I’ll perform a pathping, I’m going to choose the -n option to not resolve these IP addresses to names so that we only see IP addresses in the final output, and we’ll specify that we would like to perform a pathping to Quad9. When we hit Enter, it performs a traceroute. You could see that happened very quickly, and now we start gathering metrics about the communication over the next 200 seconds.
Now that the calculations are complete, we can see full summary of the communication between our device and Quad9. You can see that all eight hops are listed on the left side, we can see round-trip times to each one of those hops, and then we can see exactly how much may have been lost versus what was sent to this device. In this case, we lost zero packets out of 100 for a 0% loss.
We can also see, for each individual node, what the differences are in what was lost versus what was sent and then the final IP addresses that were identified during the original traceroute process. Although this does take a little bit of extra time to perform, it can give you a lot of details about where a problem may be occurring between your device and another.