Summary: Microsoft Scripting Guy, Ed Wilson, talks about understanding Windows PowerShell 3.0 in Windows 8.

Microsoft Scripting Guy, Ed Wilson, is here. It is an exciting and great day! I have been working a bit to solidify the editorial calendar for the Hey, Scripting Guy! Blog. I can say that there are some absolutely awesome posts coming up in the next couple months. I am not just saying this because I am writing them. Nope. I have a great lineup of guest writers. The upcoming stuff will simply rock!

Windows 8 posh stuff…

One of the really great things about Windows 8 is the implementation of Windows PowerShell 3.0. But many of the really cool commands (cmdlets or functions) are not strictly Windows PowerShell 3.0. For example, one function I use on a regular basis when I am traveling is Get-NetAdapter. This command tells me if a network adapter is up. Because I toggle my wireless and my Ethernet adapter connections (on or off depending on the network), I often need to see if a particular adapter is up.

Another function I use a lot when I am traveling is the Get-NetConnectionProfile function. This tells me how a particular network adapter has been identified by the operating system. I can modify the profile by using Set-NetConnectionProfile. I need to use this a lot when I am traveling and I want to demonstrate Windows PowerShell.

Neither of the two previously mentioned functions are part of Windows PowerShell 3.0, per se. They are included in modules that ship with Windows 8. The associated modules are shown here:

PS C:\> Get-Command Get-NetConnectionProfile, Get-NetAdapter

CommandType     Name                                             ModuleName

———–     —-                                                                ———-

Function        Get-NetConnectionProfile                     NetConnection

Function        Get-NetAdapter                                     NetAdapter

Am I being pedantic? If so, it is not my intention. It is important to know where specific functionality arises, so that when I install Windows PowerShell 3.0 onto a computer running Windows 7, I will know what to expect. This concept will be important when Windows 8.1 ships with Windows PowerShell 4.0 because Windows PowerShell 4.0 in Windows 8.1 will expose certain cmdlets and functions that may not be available if I install Windows PowerShell 4.0 on a down-level system.

Emulating capability

With all the great commands in Windows 8, it is easy to forget that the capability comes from modules that ship with the operating system, and that they are not part of Windows PowerShell 3.0 core installation. But it is Windows PowerShell 3.0 that makes these cool modules shine. Most of the capability comes from the CIM infrastructure that is part of the Windows Management Framework 3.0 (where you obtain Windows PowerShell 3.0).

For example, the Get-NetAdapter function uses CIM to expose network adapter information. It is very convenient. The command and its associated output are shown here:

I can achieve the same output in Windows 7 by using Windows PowerShell 3.0. I use the Get-CimInstance cmdlet, query the Win32_NetworkAdapter WMI class, and choose the appropriate properties. The command is a bit longer than just typing Get-NetAdapter, but if I use it all the time, all I need to do is write my own function. Following is the command (gcim is the alias for Get-CimInstance, Select is the alias for Select-Object, and ft is the alias for Format-Table). This command is a single-line command that I broke at the pipe character for readability.

gcim win32_networkadapter |

select netconnectionid, description, interfaceindex, macaddress, speed |

ft * -auto

Here is the command and the output from the command:

Join me tomorrow as I begin a series of posts called Windows PowerShell Workflow for Mere Mortals. It is a great series, and you will not want to miss it.

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