Summary: Ed Wilson, Microsoft Scripting Guy, talks about the reduced need to use Windows PowerShell scripting.

Microsoft Scripting Guy, Ed Wilson, is here. If you follow me on Twitter or Facebook, you already know that my new book, Windows PowerShell Step by Step, third edition, is on its way to the printers. I am not going to talk about that today—but it dawned on me as I was completing the final tasks for this book, that I did not talk about as much scripting in the book as I did, for example, in the Windows PowerShell 1.0 Step by Step book.

This is not because I don’t like to script. In fact, I love to write Windows PowerShell scripts. I am one of the few real scripting nerds in the world. I like to write scripts, and I do it for fun. But you see, I simply don’t have to write nearly as many scripts as I used to.

Quick! Without thinking, name five things you can do with Windows PowerShell 5.0 on Windows 10, with a single cmdlet—things that you had to write scripts to do in the past. Or you had to write a complicated command—or at the very minimum, you needed to remember an obscure WMI command.

I say Windows PowerShell 5.0 on Windows 10 because that is what I happen to be running. If I test something in my Windows PowerShell console, I can be assured that it will work in Windows PowerShell 5.0 on Windows 10. I am not assured that it will work in Windows PowerShell 3.0 installed on Windows 7. In fact, the odds are pretty well in my favor that it will NOT work in Windows PowerShell 3.0 on Windows 7. Or for that matter, in Windows PowerShell 5.0 installed on Windows 7.

Note  For more information, see Backwards Compatibility in PowerShell.

The big watershed event for Windows PowerShell and for operating system automation came in Windows 8 on Windows Server 2012, where hundreds and hundreds of cmdlets (functions) were introduced into the operating system. These simply are not present in Windows 7, and they cannot be backported either.

So all of the way cool things that save me so very much time are not so much part of Windows PowerShell 5.0 or PowerShell 4.0, but they are actually part of the operating system. I am thinking of things like Get-NetAdapter:

PS C:\> Get-NetAdapter

Name                      InterfaceDescription               ifIndex      Status

—-                             ——————–                    ——-       ——

Ethernet                  Intel(R) 82579LM Gigabit Network Con…       2 Up

Wi-Fi                     Intel(R) Centrino(R) Ultimate-N 6300…       6 Not Pre…

In the past (and in Windows 7), I had to query the Win32_NetworkAdapter WMI class to find this information. I then cycled through all of those “bogus” network adapters that appeared, selected the appropriate properties from the dozens that do not return any information, and then interpreted some of the coded values. This actually can turn into a pretty complicated 20-line Windows PowerShell script. I know—I have written it.

There is another one of my favorite commands, the Get-Volume command (function), which displays information about NTFS volumes. With a short command, I can get volume information, and display it into a sortable graphical user interface window pane.

Speaking of sortable graphical user interface window panes…

One of my favorite cmdlets is the Out-GridView cmdlet. It makes filtering through information a breeze, and it is a great add-on for a script. In the past, creating something like this would have been a major difficulty—and again, I know because I wrote stuff to present GUIs.

The command to display volume information is shown here (ogv is an alias for Out-GridView):

Get-Volume | ogv

The newly created grid view is shown here:

New cmdlets (functions) are not limited to only hardware. (However, we are in Windows 10 and the previous stuff was introduced three versions ago, so that is hardly new.)

Another really powerful feature was added to the Get-Content cmdlet a while ago (maybe in PowerShell 4.0). That is the –Tail parameter. By using the –Tail parameter, I can retrieve only the last however many lines from a text file. Again, this used to require some scripting, but now it is part of the cmdlet. Here is an example:

PS C:\> Get-Content .\fso\AMoreComplete.txt -Tail 1

and even more kinds of "stuff" like quotes.

The entire contents of the file are shown in the following image:

I am not even going to talk about Desired State Configuration (DSC). I mean, using DSC is so easy, and while it is powerful most of the time, it is not doing stuff that I could not write a script to do. But it really makes stuff simple. I can write a very short DSC script, and it replaces some pretty hairy coding.

It is almost like the Windows PowerShell team is deliberately looking at situations where I used to have to write some pretty complicated code, and they are actually making it simple. In some cases, it is really, really simple. I can see a day (maybe not too far away) where I never have to write Windows PowerShell scripts again. Really, that is fine. It will give me more time to spend programing my drone—that is until they create a Windows PowerShell parrot module.

Join me tomorrow when I will talk about more cool PowerShell stuff.

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