Moving to PowerShell 5.0
Because I do so much training and work in PowerShell 4.0, primarily because I think many people are still running 4.0, I’m always behind in upgrading to newer versions of PowerShell. With that said, I think I’ve finally reached a point where it makes sense to move to PowerShell 5.0 on my daily system. In this article, I’ll walk through some essential steps to take after moving to PowerShell 5.0.
My system is still running Windows 8.1 Enterprise, and while I could have upgraded it to Windows 10 to get PowerShell 5.0, I wasn’t ready to make that change due to some potential application issues. I have another system running Windows 10, so I’m not totally out of step.
Technically, PowerShell 5.0 is part of the Windows Management Framework 5.0. Note that the the Windows Management Framework 5.0 RTM release was released on December 23, 2015, but the update was taken offline due to customer issues. In the meantime, you can still download the production preview to get started. You will need to be running at least Windows 7 SP1 and the .NET Framework 4.5. If you’re installing on a server, be sure to read the install notes.
To upgrade, close all PowerShell and PowerShell ISE windows. As with any major installation, make sure you have backups of critical files. The update shouldn’t cause any problems, but better safe than sorry. Navigate to the downloaded files and double-click the MSU file for your operating system. Follow the simple instructions and reboot when prompted. The entire upgrade goes pretty quickly.
Upon reboot, I opened up a PowerShell window and confirmed the new version.
Although I’m running PowerShell 5.0, I’m still running Windows 8.1, so I don’t get new things like the improved console window that we get in Windows 10. As far as I can tell, the PowerShell ISE is unchanged except for new version numbers.
The first step is to update help, primarily because there are a number of new cmdlets.
As in PowerShell 4.0, all you need to do is run Update-Help. You might see an error or two for modules like OneGet. That’s normal. Unfortunately, even with updating, some cmdlets are lacking help documentation both in help and online. At some point, I hope that documentation catches up. Still, it doesn’t hurt to run Update-Help.
When you downloaded the 5.0 files, you should also have pulled down a Word document with extensive release notes. I hope you take a lunch break to skim through it. You should also read the help topic about_Windows_PowerShell_5.0.
What do you get for all this effort? A new package management system with PowerShellGet, improvements to Desired State Configuration (DSC), new debugging tools, new cmdlets, and additional parameters.
I have a pretty extensive PowerShell profile and when I started up PowerShell, everything ran without error, so that’s a positive. Over the next few weeks, I’ll be testing a number of my scripts and tools for any bugs or incompatibilities with PowerShell 5.0. But so far, so good.
The first thing I’m going to do in this new world is try out the package manager tools, which is probably one of the more intriguing features. By default, you have access to a Microsoft repository of modules.
I want to see what’s available.
Because I’ve never used the cmdlet before, I need to download an additional file. Now I can rerun the Find-Module command.
I found almost 400 modules, many of them are DSC resources. It’s easy enough to pipe $m to Out-Gridview to see the results.
In scrolling through the list, I see a number of things I’d like to have, so I’ll get one.
At some point, I’ll modify the trust settings for the PowerShell Gallery, but for now, I can say yes.
This also shows up now as an installed module:
Eventually I can use Update-Module to get the latest version.
This is just a taste of what awaits you. I’m looking forward to getting to know PowerShell 5.0 on a more intimate level.
What’s your story? Have you moved to PowerShell 5.0? If not, what’s holding you back? I’d love to hear about it.