Summary: Microsoft Scripting Guy, Ed Wilson, talks about ways to use Windows PowerShell to find connected network adapters.

Microsoft Scripting Guy, Ed Wilson, is here. This afternoon I am enjoying a nice pot of Oolong green tea. This tea has a great taste, especially when I add a bit of jasmine flowers. Oolong green tea steeps best if the water temperature is 185 degrees F—it really comes alive and is bursting with flavor.

PowerShell Saturday #007 will be held in Charlotte, North Carolina on February 8, 2014. This will be an awesome chance to meet and to learn from some of the best PowerShellers around. In fact, five of the speakers are also speakers at the PowerShell Summit this year. There are a limited number of tickets still available for this event, so you’ll want to sign up now. The Scripting Wife wrote a great post that provides a quick overview of the event: Psst…Charlotte PowerShell Saturday Details Leaked.

One of the most fundamental pieces of troubleshooting or security checks is to find out which of the many network adapters on a computer are actually connected to a network.

     Note  This is the fourth post in a series that examines working with network adapters. You may want to refer to the
     earlier posts to get a feel for the way the series progresses:

• Use PowerShell to Identify Network Adapter Characteristics
• Enabling and Disabling Network Adapters with PowerShell
• Renaming Network Adapters by Using PowerShell

Using Netsh

It is pretty easy to use Netsh to retrieve information about the connection status of network adapters. To do so, I use the following command:

netsh interface ipv4 show interfaces

One of the issues, from a management perspective, is that the command returns text. Therefore, if I need to parse the text to pull out specific information, such as the interface index number or the name of the adapter, I have to resort to writing a complicated regular expression pattern. If all I need to do is to obtain the information because I am writing to a log file as text, the command works great, and it is the lowest common denominator. I have used it all the way back to Windows 2000 days.

I can even run the Netsh commands from within the Windows PowerShell console, as shown in the following image:

Using WMI

It is possible to use WMI and the Win32_NetworkAdapter WMI class to retrieve information about the connection status. The NetConnectionStatus property reports a coded value that reports the status. These values are documented on MSDN: Win32_NetworkAdapter class.

By using the Get-WmiObject Windows PowerShell cmdlet, I can work with any operating system that installs Windows PowerShell. This includes systems all the way back to Windows XP and Windows Server 2003. The following command returns information similar to the Netsh command:

get-wmiobject win32_networkadapter | select netconnectionid, name, InterfaceIndex, netconnectionstatus

The command and the output from the command are shown in the image that follows:

The difference is that instead of plain text, the command returns objects that can be further manipulated. Therefore, while the previous command actually returns the network connection status of all network adapters, the Netsh command only returns the ones that are connected.

If I filter on a netconnectionstatus of 2, I can return only the connected network adapters. The command becomes this one (this is a single-line command that I broke at the pipeline character for readability):

get-wmiobject win32_networkadapter -filter "netconnectionstatus = 2" |

select netconnectionid, name, InterfaceIndex, netconnectionstatus

The command and its output are shown here:

If the desire is to obtain the connection status of more than just network adapters that are connected, the task will require writing a script to perform a lookup. The lookup values are:

Value	Meaning
0	Disconnected
1	Connecting
2	Connected
3	Disconnecting
4	Hardware not present
5	Hardware disabled
6	Hardware malfunction
7	Media disconnected
8	Authenticating
9	Authentication succeeded
10	Authentication failed
11	Invalid address
12	Credentials required

The Get-NetworkAdapterStatus.ps1 script requires at least Windows PowerShell 2.0, which means that it will run on Windows XP with SP3 and later.

Get-NetworkAdapterStatus.Ps1

<#

   .Synopsis

    Produces a listing of network adapters and status on a local or remote machine.

   .Description

    This script produces a listing of network adapters and status on a local or remote machine.

   .Example

    Get-NetworkAdapterStatus.ps1 -computer MunichServer

    Lists all the network adapters and status on a computer named MunichServer

   .Example

    Get-NetworkAdapterStatus.ps1

    Lists all the network adapters and status on local computer

   .Inputs

    [string]

   .OutPuts

    [string]

   .Notes

    NAME:  Get-NetworkAdapterStatus.ps1

    AUTHOR: Ed Wilson

    LASTEDIT: 1/10/2014

    KEYWORDS: Hardware, Network Adapter

   .Link

     Http://www.ScriptingGuys.com

#Requires -Version 2.0

#>

Param(

  [string]$computer= $env:COMPUTERNAME

) #end param

 

function Get-StatusFromValue

{

 Param($SV)

 switch($SV)

  {

   0 { " Disconnected" }

   1 { " Connecting" }

   2 { " Connected" }

   3 { " Disconnecting" }

   4 { " Hardware not present" }

   5 { " Hardware disabled" }

   6 { " Hardware malfunction" }

   7 { " Media disconnected" }

   8 { " Authenticating" }

   9 { " Authentication succeeded" }

   10 { " Authentication failed" }

   11 { " Invalid Address" }

   12 { " Credentials Required" }

   Default { "Not connected" }

  }

} #end Get-StatusFromValue function

 

# *** Entry point to script ***

 

Get-WmiObject -Class win32_networkadapter -computer $computer |

Select-Object Name, @{LABEL="Status";

 EXPRESSION={Get-StatusFromValue $_.NetConnectionStatus}}

If my environment is running Windows 7 or Windows Server 2008 R2, I can use Windows PowerShell 4.0 or Windows PowerShell 3.0. The advantage is that I gain access to the Get-CimInstance cmdlet which uses WinRM for remoting instead of DCOM, whicht the Get-WmiObject cmdlet uses. The only change to the Get-NetworkAdapterStatus.ps1 script that is required is to replace the Get-WmiObject line with Get-CimInstance. Here is the revision:

# *** Entry point to script ***

 

Get-CimInstance -Class win32_networkadapter -computer $computer |

Select-Object Name, @{LABEL="Status";

 EXPRESSION={Get-StatusFromValue $_.NetConnectionStatus}}

When I run the Get-StatusFromValue.ps1 script, in the Windows PowerShell ISE, I see the output achieved here:

Using the NetAdapter module

In Windows 8.1 and Windows 8, the NetAdapter module contains the Get-NetAdapter function. To see the status of all network adapters, use the Get-NetAdapter function with no parameters:

Get-NetAdapter

The output from this command is shown here:

I can reduce the output to only physical adapters by using the –physical parameter, as shown here:

Get-NetAdapter –Physical

If I only want to see the physical network adapters that are actually up and connected, I pipe the results to Where-Object:

Get-NetAdapter -physical | where status -eq 'up'

The output from the two previous commands is shown in the image that follows:

Network Adapter Week will continue tomorrow when I will talk about working with network adapter power settings.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy