New Features in PowerShell v5 Preview
Microsoft recently released a preview version of PowerShell 5.0. While no official release date has been mentioned, I’m betting it will be later this year. More on what that means a bit later, but for now let’s take a look at the new features in the PowerShell v5 preview.
PowerShell v5: OneGet and New Cmdlets
The two most compelling features in the release is OneGet, which is a package manager much like Chocolatey, and a set of cmdlets for managing network switches. Of the two, OneGet is drawing the most attention now. If you’ve used Chocolately, you will immediate understand OneGet. I expect there will be some changes to OneGet when v5 finally ships, so I’ll hold off on any detailed review or analysis for now.
Other than that, there are only three new cmdlets:
And of these, the only one that I think you will find of immediate value is Get-ItemPropertyValue, which has an alias of gpv. In previous versions if you wanted to get just the value of say a registry key or file item you had to resort to expanding a property or a pipeline shortcut.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
The new v5 cmdlet simplifies the process.
Oh, and you can expect the usual amount of bug fixes in the v5 preview, although I have yet to see a definitive list.
What PowerShell v5 Really Means
So, if there’s not a lot in the preview, why does it matter? Well, as I alluded to earlier, many of you are still struggling to get PowerShell v3 – yet alone v4 – and now comes v5. Whoa! For those of us who train and write, this is also a challenge. But what you are seeing is a new paradigm for the PowerShell team where development and release cycles are more Agile-like. I think the days of several years between major releases is a thing of the past.
We can no longer rely on a two- or three-year window to move to a newer version. I think product releases will be faster and more incremental than before. We are going to have to adjust our review, adoption and training process. We are going to have to have processes in place to easily deploy new releases that we wish to take advantage of. If you’ve never paid any attention to the world of DevOps, I think you are going to have to now.
Sure, you could stick with twentieth-century management strategy, but you will miss out on the opportunities to take advantage of new PowerShell innovations, like Desired State Configuration (DSC), which could make you even more efficient and drive management costs down. Yes, this will be difficult, but this is not the time for “We’ve always done it this way.”
What Should You Do?
From a PowerShell perspective, I would recommend getting all of your managed servers to at least PowerShell v3. The changes from v3 to v5 have been incremental. I look at v3 as the new minimal requirement. If you have legacy servers that won’t support v3, then at least install v2 and enable PowerShell remoting. I would recommend viewing these systems as unmanaged, and hopefully you have plans to retire or upgrade. Of course, if you intend on managing any server with DSC, you will need to make sure that server is upgraded to PowerShell v4, with all that might entail such as an operating system upgrade.
The next step is to download and evaluate PowerShell v5. The current preview is NOT intended for production use. But you should begin to review it to see what features, if any, will benefit your organization. This is also the time to begin developing a deployment strategy, if you don’t already have one, so that when v5 ships you can quickly deploy it where necessary. Right now, I would say that if you don’t have a compelling need, v3 or v4 should still suffice. And probably by the time you finish deploying v5 there will be a v6 preview and the process repeats.
Accept the fact that new PowerShell versions will be coming at you faster and plan accordingly. If Microsoft can be nimble and agile, you should be equally able.
As with all previews, everything I’ve shown you is subject to change, and I expect many things will change between now and final release. Once we have final bits, I will provide a more in-depth review and analysis. For now, whip up a test virtual machine that will run PowerShell v5 and kick it around. And start making plans to migrate the rest of your environment to at least PowerShell v3.