Summary: Use PowerShell to identify and disable network adapters in Windows Server 2012 R2.
Hey, Scripting Guy!
I would love to know if there is an easy way to work with my physical adapters in a Windows Server 2012 R2 environment. Specifically, can you show me which adapters are live?
—TM
Hello TM,
Honorary Scripting Guy, Sean Kearney, is here today, unlocking more of the Power of the network cmdlets. This is the third part in a series called Windows PowerShell Network Week. You also might enjoy reading:
Yesterday, we discovered that working with the Windows Firewall with Windows PowerShell was incredibly easy. Today we’re going to touch on something that I used to want to do. I wanted to walk up to a server like a PowerEdge 720 with 10 network adapters in it, and easily be able to identify which ones were live. I especially wanted to do this in a scenario where I was deploying a new server and was working with multiple VLANs.
In the old days, I might have done something like plug in the cable, look at the GUI, see which one lit up, and scribble in my documentation where that name aligned with the physical position on the server.
That’s still very much in play in a newer environment. But at least with Windows PowerShell in Windows Server 2012 R2, I can run a script in the background to keep looping and displaying the live network adapters —or at least catch the live ones and export their names to a CSV.
To do any of this, we need to use the Network Adapter cmdlets.
In the past, to get a list of network adapters with NETSH.EXE, I would run a command like this:
Netsh.exe interface ipv4 show connections
Which might give an output like this:
The big problem was to get that date out and parse it was…errr…irritating. I could pipe it to a text file I guess—but well, then I’d have to do something funky with a for statement in DOS. Then maybe cross my fingers, and yell a bit when it didn’t work the first time…or the fifteenth. You get the idea.
Now we can leverage the Get-NetAdapter cmdlet for this, which will return an object that is far easier to parse. Simply use this line to get output:
Get-NetAdapter
Not only is this easier to read and use, but because it’s an object, I can now do something as simple as filter on only adapters that are live:
Get-NetAdapter | Where { $_.Status –eq ‘Up’ }
Or I can even do something like this to show only physical adapters in the computer:
Get-NetAdapter –Physical
Or I can pipe that entire list to a CSV file for documentation:
Get-NetAdapter –Physical | Export-CSV C:\Foo\ServerNicList.csv
One of the things that used to drive me bananas was having a bunch of adapters left live at the back of a computer while I was setting things up. I might go back to my desk, and a coworker might pop in and plug in a LAN cable to the wrong server—and suddenly I’ve got a second IP address messing up my work.
Not any more with Windows PowerShell. I can use the Disable-NetAdapter cmdlet to disable all those adapters that are not live:
Get-NetAdapter –Physical | Where { $Status –ne ‘Up’ } | Disable-NetAdapter
Now remember that scenario where I would plug in a cable to find the live port and document it after finding it in the GUI? One of my previous tasks was also to give it a description to match the network it was on. This also gets easier with Windows PowerShell and the Set-NetAdapter cmdlet.
I can find only the live physical adapters (there should only be one as I work), and use Set-NetAdapter to provide the description:
Get-NetAdapter –Physical | Where { $Status –eq ‘Up’ } | Set-NetAdapter –interfacedescription ‘Production Vlan’
With a script running this, I could easily configure a series of computers running Hyper-V or a cluster, and be consistent in my cabling and in naming the descriptions.
But why stop there? You can even easily rename the network adapter with Rename-NetAdapter or dive into the advanced properties of the physical adapter.
I can even fight my old nemesis: Power management. What if a vendor didn’t quite implement the power management right, and this was causing network adapters to prematurely go to sleep? Well, I can dive into that advanced property with Windows PowerShell right now!
Get-NetAdapter | Disable-NetAdapterPowerManagement
There! No more sleeping on MY network now! All thanks to Windows Powershell!
Pop in tomorrow, TM, and we’ll play with configuring IP addresses and DNS settings! Va-va-va-voooooom!
I invite you to follow The Scripting Guys on Twitter and Facebook. If you have any questions, send an email to The Scripting Guys at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then remember eat your cmdlets each and every day with a taste dash of creativity.
Sean Kearney, Windows PowerShell MVP, Honorary Scripting Guy