Manage Network Adapters with PowerShell: Troubleshooting

Over the last few articles I’ve been exploring and demonstrating PowerShell tools for managing network adapters and configuring network adapters in Windows Server 2012. If you missed either of those articles, you should read them first. In this article we’ll look at some cmdlets that might come in handy when troubleshooting a networking issue, and all of these commands can be run remotely. Everything I’m going to show you requires PowerShell 3 and Windows Server 2012. These commands will also work with Windows 8, but that’s a bonus.

Get Protocols

The first item you might want to check is protocol configuration. There are IP version specific cmdlets that will return useful information.

To query a remote computer you can use a computer name, IP address, or an existing CIMSession. Although if you need to specify alternate credentials you will need to create a CIMSession.

A useful feature of this cmdlet is that you can filter in place by a number of protocol settings. This is very helpful when you want to query multiple computers. For example, I need to see which of my servers are still configured for the protocol stack to pay attention to DHCP.

Unfortunately, as you can see below in Figure 1, the cmdlet throws an exception for computers that do not have the specified setting.

Managing Network Adapters with PowerShell

I could run the command suppressing errors, but that might mask other problems. Or I can simply filter all the results with Where-Object.

As you can see in Figure 2, this is a bit nicer.

Managing Network Adapters with PowerShell

I can get similar results for the IPv6 stack.

If you want to see several properties across multiple computers, I recommend using Out-Gridview.

Managing Network Adapters with PowerShell

As you can see above in Figure 3, I haven’t done much with IPv6, but you could use a similar technique with the IPv4 cmdlet.


In the “old days,” IT pros used command line tools like NETSTAT.EXE to examine what ports were in use and what connections a server might have. But it was a command line tool, and you had to run it on the server. Today we can get the same information through PowerShell using Get-NetTCPConnection.

Managing Network Adapters with PowerShell Get-NetTCPConnection

More than likely, you will want to limit the display to make it more “netstat-like.”

I formatted the output to make it a little easier to read in Figure 5 (as shown below).

Managing Network Adapters with PowerShell

The LocalAddress is the IP address of the remote server. We can also query the remote address as well.

Figure 6 shows all the connections from CHI-APP01 to any address that starts with 172.

Managing Network Adapters with PowerShell

Or if I just want the remote IP address, I can get a unique list.

And because we have objects, there are some interesting ways we can use this.

Managing Network Adapters with PowerShell

Figure 7 (above) shows all the remote computers that have a remote connection to I can do the same thing with ports.

Now I’ve searched all my Windows Server 2012 computers for those that have a remote PowerShell session open on the default port, 5985.

Managing Network Adapters with PowerShell


The last cmdlet that might come in handy is Get-NetRoute. This is PowerShell equivalent to the legacy Route.exe utility. But this works remotely!

You can see my result below in Figure 9.

Managing Network Adapters with PowerShell Get-NetRoute

The ifIndex property is the Interface Index number which we looked at in earlier article. In fact, we can get a net adapter and then discover its associated routes.

Even though the output in Figure 10 (shown below) doesn’t explicitly show it, this is the route table for CHI-FP02, which only has a single adapter.

Manage Network Adapter PowerShell

Or perhaps I want to verify that all my servers have the correct default gateway. Here’s a one line command:

Based on what I see in Figure 11, everything looks good.

Manage Network Adapter PowerShell

If you have a more complex environment with multi-homed servers, this cmdlet could be a lifesaver in tracking down a network configuration problem.

As I’ve been reminding you in each article, please take the time to read complete help and examples for all the cmdlets I’ve been demonstrating. Now that we’ve seen all the information we can gather, we need to explore what it takes to set and configure. We’ll start that discovery next time.

Related Topics:

  • Networking

    Don't have a login but want to join the conversation? Sign up for a Petri Account