Identifying network adapters

One of the great things about Windows Management Instrumentation (WMI) is the way that it can provide detailed information. The bad thing is that it requires a specialist level of knowledge and understanding to effectively use and to understand the information (either that or a good search engine, such as BING and an awesome repository of information such as the Script Center).

Using raw WMI to identify network adapters

One of the cool things about Windows PowerShell, since version 1.0, is that it provides easier access to WMI information. The bad thing, of course, is that it is still wrestling with WMI, which some IT Pro’s seem to hate (or at least dislike). The great thing about using raw WMI is compatibility with older versions of the operating system. For example, using raw WMI and Windows PowerShell would make it possible to talk to Windows XP, Windows 2003 Server, Windows 2008 Server, Vista, Windows Server 2008 R2 and Windows 7, in addition to the modern operating systems of Windows 8, 8.1 and Windows Server 2012 and Windows Server 2012 R2.

So how do I do it? I used to be able to find our real network card by finding the one that was bound to TCP/IP. I would query the Win32_NetworkAdapterConfiguration WMI class, and filter on the IPEnabled property. Using this approach, I would have done something like this:

  1.  Get-WmiObject-ClassWin32\_NetworkAdapterConfiguration -filter"IPEnabled = $true"

The problem with this methodology nowadays is that some of the pseudo adapters are also IPEnabled. The above command would eliminate many, but not necessarily all of the adapters.

A better approach is to look at the Win32_NetworkAdapter class and query the NetConnectionStatus property. Using this technique, I return only network adapter devices that are actually connected to a network. While it is possible that a pseudo adapter could sneak under the wire, the likelihood is more remote. In this command, I will use the Get-WmiObject PowerShell cmdlet to return all instances of Win32_NetworkAdapter class on the computer. I then create a table to display the data returned by the NetConnectionStatus property.

  1. Get-WmiObject-ClassWin32\_NetworkAdapter|
  2. Format-Table-PropertyName,NetConnectionStatus-AutoSize

The fruit of our labor is somewhat impressive. I have a nice table that details all of the fake and real network adapters on our laptop, as well as the connection status of each. Here is the list from my laptop.

  1. Name                       NetConnectionStatus
  3. ----                       -------------------
  5. WAN Miniport (L2TP)
  6. WAN Miniport (PPTP)
  7. WAN Miniport (PPPOE)
  8. WAN Miniport (IPv6)
  9. Intel(R) PRO/1000 PL Network Connection     2
  10. Intel(R) PRO/Wireless 3945ABG Network Connection 0
  11. WAN Miniport (IP)
  12. Microsoft 6to4 Adapter
  13. Bluetooth Personal Area Network
  14. RAS Async Adapter
  15. isatap.{51AAF9FF-857A-4460-9F17-92F7626DC420}
  16. Virtual Machine Network Services Driver
  17. Microsoft ISATAP Adapter
  18. Bluetooth Device (Personal Area Network)     7
  19. 6TO4 Adapter
  20. Microsoft 6to4 Adapter
  21. Microsoft Windows Mobile Remote Adapter
  22. isatap.launchmodem.com
  23. isatap.{647A0048-DF48-4E4D-B07B-2AE0995B269F}
  24. Microsoft Windows Mobile Remote Adapter
  25. WAN Miniport (SSTP)
  26. WAN Miniport (Network Monitor)
  27. 6TO4 Adapter
  28. 6TO4 Adapter
  29. Microsoft 6to4 Adapter
  30. Microsoft Windows Mobile Remote Adapter
  31. isatap.{C210F3A1-6EAC-4308-9311-69EADBA00A04}
  32. isatap.launchmodem.com
  33. Virtual Machine Network Services Driver
  34. Virtual Machine Network Services Driver
  35. Teredo Tunneling Pseudo-Interface
  36. isatap.{647A0048-DF48-4E4D-B07B-2AE0995B269F}

There are two things you will no doubt notice. The first is that most of the network adapters report no status what-so-ever. The second thing you will notice is that the ones that do report a status do so in some kind of code. The previous table is therefore pretty much useless! But it does look nice.

A little work in the Windows SDK looking up the Win32_NetworkAdapter WMI class and I run across the following information:

  1. Value Meaning
  3. 0     Disconnected
  5. 1     Connecting
  7. 2     Connected
  9. 3     Disconnecting
  11. 4     Hardware not present
  13. 5     Hardware disabled
  15. 6     Hardware malfunction
  17. 7     Media disconnected
  19. 8     Authenticating
  21. 9     Authentication succeeded
  23. 10    Authentication failed
  25. 11    Invalid address
  27. 12    Credentials required

The value of 2 means the network adapter is connected. Here is the code I wrote to exploit the results of our research.

  1. Get-WmiObject -classwin32\_networkadapter -filter "NetConnectionStatus = 2"|
  2. Format-List -Property [a-z]\*

Such ecstasy is short lived; however, when I realize that while I have indeed returned information about a network adapter that is connected, I do not have any of the configuration information from the card.

What I need is to be able to use the NetConnectionStatus property from Win32_Networkadapter and to be able to obtain the Tcp/Ip configuration information from the Win32_NetworkAdapterConfiguration WMI class. This sounds like a job for an association class. In VBScript querying an Association class involved performing confusing AssociatorsOf queries (Refer to the MSPress book, “ Window Scripting with WMI: Self Paced Learning Guide“ for more information about this technique.)

Using the association class with Windows PowerShell, I come up with the FilterAssociatedNetworkAdapters.ps1 script shown here.

FilterAssociatedNetworkAdapters.ps1

  1. Param($computer="localhost")
  3. functionfunline ($strIN)
  4. {
  5. $num=$strIN.length
  6. for($i=1 ; $i-le$num ; $i++)
  7.  { $funline=$funline+"=" }
  8.   Write-Host-ForegroundColoryellow$strIN
  9.   Write-Host-ForegroundColordarkYellow$funline
  10. } #end funline
  12. Write-Host-ForegroundColorcyan"Network adapter settings on $computer"
  14. Get-WmiObject -Class win32\_NetworkAdapterSetting `
  15. -computername $computer|
  16. Foreach-object `
  17. {
  18.  If( ([wmi]$\_.element).netconnectionstatus -eq 2)
  19.   {
  20.   funline("Adapter: $($\_.setting)")
  21.   [wmi]$\_.setting
  22.   [wmi]$\_.element
  23.   } #end if
  24. } #end foreach

I begin the script by using a command line parameter to allow us to run the script remotely if needed. I use the Param statement to do this. I also create a function named funline that is used to underline the results of the query. It makes the output nicer if there is a large amount of data returned.

  1. Param($computer="localhost")
  3. functionfunline ($strIN)
  4. {
  5. $num=$strIN.length
  6. for($i=1 ; $i-le$num ; $i++)
  7.  { $funline=$funline+"=" }
  8.   Write-Host-ForegroundColoryellow$strIN
  9.   Write-Host-ForegroundColordarkYellow$funline
  10. } #end funline

I print out the name of the computer by using the Write-Host cmdlet as seen here. I use the color cyan so the text will show up real nice on the screen (unless of course your background is also cyan, then the output will be written in invisible ink. That might be cool as well.)

  1. Write-Host -Foreground Colorcyan "Network adapter settings on $computer"

Then I get down to actual WMI query. To do this, I use the Get-WmiObject cmdlet. I use the -computername parameter to allow the script to run against other computers, and I pipeline the results to the ForEach-Object cmdlet.

  1. Get-WmiObject -Class win32\_NetworkAdapterSetting `
  2. -computername $computer|
  3. Foreach-object `

The hard part of the query is seen here. I need a way to look at the netConnectionStatus property of the Win32_NetworkAdapter class. This class is referred to by the reference returned from the association query. It is called element. To gain access to this class, I use the reference that was returned and feed it to the [WMI] type accelerator (it likes to receive a path, and this is what the reference is). Since the reference refers to a specific instance of a WMI class, and since the [WMI] type accelerator can query a specific instance of a class, I are now able to obtain the value of the netConenctionStatus property. So I say in our script, if it is equal to 2, then I will print out the name of the network adapter, and the configuration that is held in the setting property and the adapter information that held in the element property. This section of the code is seen here.

  1. {
  2.  If( ([wmi]$\_.element).netconnectionstatus -eq2)
  3.   {
  4.   funline("Adapter: $($\_.setting)")
  5.   [wmi]$\_.setting
  6.   [wmi]$\_.element
  7.   } #end if

The result of running the script is that it displays information from both the Win32_NetworkAdapter WMI class and the Win32_NetworkAdapterConfiguration class. It also shows us I only have one connected network adapter.

Using NetSh

Microsoft created NetSh back in 2000, and it has been a staple of networking ever since then. When I open it up, now days, it displays a message saying that it might be removed in future versions of Windows, and therefore I should begin using Windows PowerShell. Here is the message:

image013.png

Now, because NetSh is an old style menu type application, it is possible to enter NetSh, and walk my way down through the menus until you arrive at the proper location. Along the way, if I get lost, I can use the ? to obtain help. The problem, is that the help is quite often not very helpful, and therefore it takes me at times nearly a dozen times before the command is correct. The great thing is that, for the most part, Once I figure out a command, I can actually keep track of my location in the program, and back all the way out and enter the command as a one linner. Here is the NetSh command to display network interface information that is bound to Ipv4:

  1. netsh interface ipv4 show interfaces

The output appears here:

image015.png

Using PowerShell on Windows 8 or above

If I have the advantage of Windows 8 or 8.1 or Windows Server 2012 or Windows Server 2012 R2, then I have the built in NetAdapter module. Due to the way that modules autoload on Windows Powell I do not need to remember that I am using functions that exist in the NetAdapter module. I can use either Windows PowerShell 3 or Windows PowerShell 4 and the behavior will be the same (Windows 8.1 and Windows Server 2012 R2 come with Windows PowerShell 4 and Windows 8 and Windows Server 2012 come with Windows PowerShell 3).

The Get-NetAdapter cmdlet returns the name, interface description, index number, and status of all network adapters present on the system. This is the default display of information and appears in the figure that follows.

image017.png

To focus in on a particular network adapter, I use the _name _parameter and supply the name of the network adapter. The good thing, is that in Windows 8 (and on Windows Server 2012) the network connections receive new names. No more of the “local area connection” and “local area connection(2) to attempt to demystify. The wired network adapter is simply _Ethernet _and the wireless network adapter is _Wi-Fi. _The following command retrieves only then _Ethernet _network adapter.

  1. Get-NetAdapter -Name Ethernet

To dive into the details of the _Ethernet _network adapter, I pipeline the returned object to the Format-List cmdlet and I choose all of the properties. The command appearing here uses the _fl _alias for the Format-List cmdlet.

  1. Get-NetAdapter -Name ethernet|Format-List *

The command and output associated with the command appear in the figure that follows.

image019.png

There are a number of excellent properties that might bear further investigation, for example there are the _adminstatus _and the _mediaconnectionstatus _properties. The following command returns those two properties.

  1. Get-NetAdapter -Name ethernet |select adminstatus, MediaConnectionState

Of course, there are other properties that might be interesting as well. These properties appear here, along with the associated output (the following is a single logical command broken on two lines).

  1. Get-NetAdapter -Name ethernet |
  2. select ifname, adminstatus, MediaConnectionState, LinkSpeed, PhysicalMediaType

The output from the above command appears here:

  1. ifName        : Ethernet\_7
  2. AdminStatus     : Down
  3. MediaConnectionState : Unknown
  4. LinkSpeed      : 0 bps
  5. PhysicalMediaType  : 802.3

I decide to look only for network adapters that are in the admin status of _up. _I use the command appearing here.

  1. PS C:\> Get-NetAdapter|whereadminstatus-eq"up"
  3. Name           InterfaceDescription          ifIndex Status
  4. ----           --------------------          ------- ------
  5. vEthernet (InternalSwi... Hyper-V Virtual Ethernet Adapter #3     22 Up
  6. vEthernet (ExternalSwi... Hyper-V Virtual Ethernet Adapter #2     19 Up
  7. Bluetooth Network Conn... Bluetooth Device (Personal Area Netw...   15 Disconn...
  8. Wi-Fi           Intel(R) Centrino(R) Ultimate-N 6300...   12 Up

To find the disabled network adapters, I change the _adminstatus _from _up _to _down. _This command appears here.

  1. Get-NetAdapter|whereadminstatus-eq"down"

I go back to my previous command, and modify it to return WI-FI information. This command, and associated output appears here (this is a single logical command).

  1. PS C:\> Get-NetAdapter-Name wi-fi|
  2. select ifname,adminstatus,MediaConnectionState,LinkSpeed,PhysicalMediaType
  4. ifName        : WiFi\_0
  5. AdminStatus     : Up
  6. MediaConnectionState : Connected
  7. LinkSpeed      : 54 Mbps
  8. PhysicalMediaType  : Native 802.11

If I want to find any network adapters sniffing the network, I look for _promiscousmode. _This command appears here.

  1. Get-NetAdapter| ? PromiscuousMode -eq $true

When I combine the Get-NetAdapter function with the Get-NetAdapterBinding function I can easily find out which protocols are bound to which network adapter. I just send the results to the Where-Object and check to see if the enabled property is equal to true or not. Here is the command.

  1. Get-NetAdapter |Get-NetAdapterBinding | ? enabled -eq $true

Here is an example of both the command and the output from the command.

image021.png

If I want to find which network adapters have the Client for Microsoft Networks bound, I need to first see which protocols are enabled (using the syntax from the previous command) and I need to see which one of the enabled protocols have the display name of Client for Microsoft Networks. This requires a compound where-object statement and therefore I cannot use the simplified syntax. Also, because only one of the protocols begins with Client - I can use that to shorten my query just a bit. Here is the command I use (this is a one line command that I broke at the pipe character to make a better display).

  1. Get-NetAdapter |
  2. Get-NetAdapterBinding |
  3. where {$\_.enabled -AND$\_.displayname -match 'client'}

The command and associated output appear in the figure here.

image023.png