I'm back, finally.
I was recently challenged with trying to not only enumerate all the network adapters on a system across dozens of different operating system versions and hardware platforms, but also to try to figure out where they are physically in the machine, remotely, without being able to see the actual hardware.
The short answer is you can't.
The long answer is you can't... do it scriptomatically without the assistance of vendor-specific software, such as the HP network configuration software and maybe an API or WBEM queries... but that's only going to cover one specific hardware platform. I need to consistently gather this data across not only Proliants, but Poweredges, VMs, desktop workstations, anything that runs Windows. Windows doesn't know where in space your network adapters are. By that I mean Windows doesn't know which physical port on your 4-port NIC is the third one from the left, etc. This would be why there is seemingly no rhyme or reason as to which network adapter Windows assigns "Local Area Network", "Local Area Network #2", "Local Area Network #3", etc. The installed NICs are enumerated randomly, as evidenced by the fact that you may get different results for which NIC port is assigned to which network connection every time you re-install Windows on a multi-NIC machine. I have heard that some particularly anal administrators even go so far as to install Windows, then delete all the Network Connections that are out of order, and continue removing and letting Windows reinstall them until they are all in the "correct" order. There is also a theory that NIC manufacturers of multi-port NICs should give each port on the card sequential MAC addresses, starting from the port closest to the PCI bus. So you might be able to infer something from that, but that's not something I would put money on for thousands of NICs with dozens of manufacturers.
Furthermore, "NIC teaming" throws yet another wrench into this, as now you can no longer rely on what Windows thinks the MAC address of a teamed adapter is, or what the cabinet switch thinks the MAC address is on a given switch port that has a teamed NIC plugged in to it.
I can get you all the information that Windows does have though, including (apparent) MAC addresses, IPs, and "Location Information" as read from the registry. This is that "Bus 0, Device 8, Function 25" stuff that you might have seen in Device Manager. It might be useful in drawing some correlations, but it's still not going to tell you much about physically where all these NICs are.
So without further ado, here are the scripts. The first one is Powershell. The second one is the exact same but ported to VB Script, for compatibility with older versions of Windows. Note the operating system version check in the VB Script.
Powershell:
$ErrorActionPreference = 'Stop'
$nics = Get-WmiObject Win32_NetworkAdapter
$cfgs = Get-WmiObject Win32_NetworkAdapterConfiguration
Write-Host "`nPhysical NICs In No Particular Order"
Write-Host "------------------------------------`n"
foreach ($_ in $nics)
{
Try
{
if($_.PNPDeviceID.StartsWith('PCI'))
{
$registryKey = Get-Item HKLM:\System\CurrentControlSet\Enum\$($_.PNPDeviceID)
$keyValues = Get-ItemProperty $registryKey.PSPath
$regSplit = $keyValues.LocationInformation.Split(";")
$location = $regSplit[2].Replace('(','').Replace(')','')
$locSplit = $location.Split(",")
Write-Host "Name : $($_.Name)"
Write-Host "MAC : $($_.MACAddress)"
Write-Host "Location: Bus $($locSplit[0]), Device $($locSplit[1])`, Function $($locSplit[2])"
$mac = $_.MACAddress
foreach ($cfg in $cfgs)
{
if($cfg.MACAddress -eq $mac -And $cfg.IPAddress)
{
Write-Host "IP : $($cfg.IPAddress)"
}
}
Write-Host " "
}
}
Catch { }
}
VB Script:
Option Explicit
const HKEY_LOCAL_MACHINE = &H80000002
Dim nic, objNICs, objCfgs, objWMIService, objReg, objOSVer
Dim strWMIQuery, strRegistryKey, strValue, strLocInfo, strBus, strDevice, strFunction, strOSMajor
Dim arrSplitKey, arrSplitLoc, arrOSBuild
Dim mac, cfg, ip, v
strWMIQuery = "SELECT * FROM Win32_NetworkAdapter"
Set objWMIService = GetObject("winmgmts:\\.\root\CIMv2")
Set objNICs = objWMIService.ExecQuery(strWMIQuery)
strWMIQuery = "SELECT MACAddress,IPAddress FROM Win32_NetworkAdapterConfiguration"
Set objCfgs = objWMIService.ExecQuery(strWMIQuery)
strWMIQuery = "SELECT Version FROM Win32_OperatingSystem"
Set objOSVer = objWMIService.ExecQuery(strWMIQuery)
For Each v in objOSVer
arrOSBuild = Split(v.Version,".")
Next
strOSMajor = arrOSBuild(0)
Wscript.Echo "Physical NICs In No Particular Order"
Wscript.Echo "------------------------------------"
For Each nic In objNICs
If StrComp(Left(nic.PNPDeviceID,3),"PCI",1) = 0 Then
Set objReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
strRegistryKey = "System\CurrentControlSet\Enum\" & nic.PNPDeviceID
objReg.GetStringValue HKEY_LOCAL_MACHINE,strRegistryKey,"LocationInformation",strValue
If CInt(strOSMajor) >= 6 Then
arrSplitKey = Split(strValue,";")
strLocInfo = arrSplitKey(2)
strLocInfo = Replace(strLocInfo,"(","")
strLocInfo = Replace(strLocInfo,")","")
arrSplitLoc = Split(strLocInfo,",")
End If
Wscript.Echo "Name : " & nic.Name
Wscript.Echo "MAC : " & nic.MACAddress
If CInt(strOSMajor) >= 6 Then
Wscript.Echo "Location: Bus " & arrSplitLoc(0) & ", Device " & arrSplitLoc(1) & ", Function " & arrSplitLoc(2)
Else
Wscript.Echo "Location: " & strValue
End If
mac = nic.MACAddress
For Each cfg In objCfgs
If StrComp(cfg.MACAddress,mac) = 0 And isNull(cfg.IPAddress) = False Then
For Each ip In cfg.IPAddress
Wscript.Echo "IP : " & ip
Next
End If
Next
Wscript.Echo " "
If isObject(objReg) Then Set objReg = Nothing
End If
Next
The output looks like this:
The IPs are not shown on the second adapter because it's switched off right now and thus doesn't have any IPs. My first idea for improvement of the Powershell version (I don't invest much time into improving VBS,) is making custom objects out of the output instead of just doing Write-Hosts. The power of Powershell is in its ability to deal with objects, and so you should try to keep everything as objects for as long as possible. Once you've spit it out on the screen in a Write-Host statement for example, you can no longer pass it along the pipeline, etc.
Thanks to Kelvin Wong and Server Fault for helping me research this.