Weekend Scripter: Why Upgrade to PowerShell 4.0?


Summary: Microsoft Scripting Guy Ed Wilson talks about why to upgrade to Windows PowerShell 4.0

Microsoft Scripting Guy, Ed Wilson, is here. I am kicking off a week of posts that are written by Windows PowerShell MVPs, a member of the product group, and myself, in which we are going to talk about upgrading to Windows PowerShell 4.0. For each of us, the reasons vary a bit.

Why is this important? The short answer is that Windows PowerShell is a crucial technology from Microsoft, and it is central to our management strategy. With the shift to the cloud, Windows PowerShell takes on an even greater role in management.

Background: Windows PowerShell 1.0

If you are a regular reader of this blog, I imagine you are familiar with the previous paragraph. But for me, the central answer is that I do not want to fall behind. I do not want my skills to get out of date. Think about this: If you began using Windows PowerShell when it first came out, you only had 129 cmdlets to learn. It was basically on par with VBScript.

This was cool because that is where I came from. If I wanted to do anything really cool with Windows PowerShell, I had to use COM, WMI, or ADSI. Like I said, no biggie because that was the VBScript world. It wasn’t simple, but it was a straightforward migration, if you will.

I had to learn about new Windows PowerShell concepts, get my head around the idea that everything is an object, and learn a few new ways of doing things—but that was about it. After using it for a year or so, I had a real good handle on Windows PowerShell…and then came the beta of Windows PowerShell 2.0.

A new ball game: Windows PowerShell 2.0

Windows PowerShell 2.0 nearly doubled the number of cmdlets—up to around 229. It added new features, such as Windows PowerShell Remoting, and powerful and complicated cmdlets like Get-WinEvent.

It introduced things like Advanced Functions, comment-based Help, modules, the Windows PowerShell ISE (with its own object model), and graphical cmdlets such as Out-Gridview. I could go on and on and on. It is absolutely amazing how much the Windows PowerShell team added in such a short time.

But you know what? I did not panic. Why? Because I already knew Windows PowerShell 1.0 very well. I had studied, learned, and pushed the boundaries for Windows PowerShell 1.0 (in addition to when it was in beta). So when Windows PowerShell 2.0 shipped, I was ready for the next great Windows PowerShell. In fact, I was happy to see it because I was running up against real limitations of Windows PowerShell 1.0.

On the other hand, if I had been confronted with Windows PowerShell 2.0 from the outset, with no exposure to Windows PowerShell 1.0, dude, I would have been crying. As an example, my book about Windows PowerShell 1.0 was around 300 pages—and I covered, in detail, all of the major features of Windows PowerShell 1.0 and how to implement them in a Windows world. My book about Windows PowerShell 2.0 was over twice that size—and I had to leave stuff out.

The big Windows PowerShell 3.0

If Windows PowerShell 2.0 was a huge release, then Windows PowerShell 3.0 was a mega release. I feel like I am running out of superlatives. There were so many new features introduced in Windows PowerShell 3.0, that I have not even finished writing about them all—either on the Hey, Scripting Guy! Blog or in book form.

I have written two books about Windows PowerShell 3.0, and I have not covered everything. For example, one way cool feature (sort of a stealth feature) is the Windows PowerShell Web Access. This is something I keep meaning to write about. It is a way cool feature that lets me set up a web server and run Windows PowerShell commands against my servers. Slick.

We added new features to the Windows PowerShell ISE, such as code snippets and improved Tab expansion. We added support for disconnected Windows PowerShell sessions. One of the big features was the CIM cmdlets and subsystem. This feature added literally thousands of cmdlets beginning with Windows PowerShell 3.0 (in Windows 8 and Windows Server 2012).

Note  This feature relies on a subsystem that is not available in Windows 7.0 or earlier.

We also added support for updatable Help, scheduled jobs, auto loading of modules. Oh, yeah, if that was not enough, we also added Windows PowerShell Workflows.

Any one of these features could take a year to work through and to get really good at. Taken in total, all I can say is, “DUDE!” I would really hate to begin my learning of Windows PowerShell at the 3.0 level.

Out of the park with Windows PowerShell 4.0

Before I got through working with all the new features in Windows PowerShell 3.0, boom! Out comes Windows PowerShell 4.0. It added Desired State Configuration (DSC). But there were also a lot of other features added.

We vastly improved working with constrained run spaces, and we added the ability to save Help, which is great for updating the Help in sandboxed environments. We added new features to cmdlets, such as Invoke-RestMethod and Invoke-WebRequest. We simplified the syntax of the Where operator, and added new cmdlets, such as Get-FileHash.

The big feature is, of course, DSC. But the numerous features added to the existing cmdlets make discovery an ongoing new process.

And now: Windows PowerShell 5.0

Windows PowerShell 5.0 is currently in community preview. This is your chance to try to get ahead of the curve…or maybe a chance to catch your breath.

Being an IT pro is hard work. We all know this. There are long hours, endless learning, and the constant demand to do more with less. Staffs are cut and jobs are outsourced. Yet the number of unmanaged devices and complexity of networks continue to grow, literally unchecked. Add to this the pressures of regulations and security constraints, and it seems to be an impossible situation. But it is the job we love, and the rewards are great.

Windows PowerShell is one tool that can make a huge difference. The ability to quickly manage hundreds (even thousands) of devices from a single Windows PowerShell script or even a one-line command is not only cool, but it is necessary.

From my perspective the time spent learning Windows PowerShell is one of the quickest ROIs available. Get ahead of the curve and stay ahead of the curve by learning how to leverage the newest features of Windows PowerShell to gain the maximum advantage from this powerful technology.

Stay tuned for this week’s posts as we talk about how to move to Windows PowerShell 4.0. Tomorrow, Windows PowerShell MVP, Richard Siddaway, leads us off with a discussion of the concerns and cautions when planning an upgrade.

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 

Comments (6)

  1. Loads of info, thanks Ed!

  2. Mike Shepard says:

    Wasn’t the where-object syntax simplified in 3.0?

  3. Matt M. says:

    Mike Shepard: You’re correct, the where-object syntax was simplified with new parameters in v3.0. I believe Ed is referring to the where operator of array objects:

    $Object.Where()

    It behaves like a method and can filter similar to Where-Object.

    http://technet.microsoft.com/en-us/hh857339.aspx#BKMK_wps4

  4. jmurphy says:

    "not available in Windows PowerShell 7.0 or earlier."
    Do you mean Windows 7 or earlier?

    Will PS 5 break Exchange, SCCM, etc, again?

  5. Ed Wilson says:

    @jmurphy yes, it is Windows 7 … For some compatability information, refer to the PowerShell 4 release notes (on the download page) and to Richards article:

    http://blogs.technet.com/b/heyscriptingguy/archive/2014/10/20/should-i-upgrade-to-latest-windows-powershell-version.aspx

Skip to main content