PowerShell 5.0 is Back

At long last, Microsoft has republished Windows Management Framework 5.0, which for most of us means PowerShell 5.0. The initial RTM bits were quickly pulled after a bug was discovered that caused problems with the %PSMODULEPATH% environmental variable. While that would seem like a simple fix, the publication process is apparently lengthy, but now the wait is over. So what does this mean to you?

If you are running Windows 10 or testing out Windows Server 2016, you don’t need to do anything. You already have PowerShell 5.0. There is no need to install the RTM package, which I doubt you could anyway.
Instead, these bits are intended for Windows 7 and Windows 8.1 admin desktops, as there’s no reason to worry about clients having PowerShell 5.0, unless you have some process or tooling in place that requires PowerShell access for end-users or their computers. If you were waiting to install v5, but didn’t get a chance, now’s your chance.
If you are running any previous versions of PowerShell 5.0, you should remove them first. Go to Programs in the Control Panel and select Uninstall program. Next, click the link to “View Installed Updates.” Find your Windows Management Framework 5 updates and uninstall. This will most likely require a reboot. Next, install the new RTM package.
If you installed the original RTM bits, and if you didn’t run into problems, you have a choice. From what I have been told, the only change in the package was for the module path problem. So if you didn’t have that problem, theoretically you could be fine. This was my situation on my main desktop. But not knowing what else might have changed, however minor, and to ensure I had the most current shipping bits, I decided to uninstall the v5 RTM package (I’m running Windows 8.1) and re-install the new one. It only took a little time, but at least I know I am up to date.

As for your servers, updating them to PowerShell 5.0 now depends on how you use PowerShell, including technologies like Desired State Configuration. There are several DSC enhancements that will require PowerShell 5.0. But if you are still ramping up to DSC, you could be just fine with PowerShell 4.0. My recommendation is that any server you intend to manage with PowerShell should be at least at PowerShell 4.0, although 3.0 will do in an exception. I know there are some server products that might force you to maintain a PowerShell 2.0 server, but I’d treat those as exceptions and manage them separately.
If you are going to maintain a mixed environment, you should test your scripts and techniques out in a lab setting. There are some compatibility issues. For example, from a Windows 5 client, I run into problems trying to run a workflow on a v4 server.

Another potential gotcha is PowerShell help. If you have a process to save help files locally, and update, I think you will want to maintain separate locations for the different PowerShell versions. One final note on documentation, there are still bugs in the help system both in content and how it is displayed. But you can always use the –Online parameter. Or if you have questions, find me on Twitter.

Are you planning up upgrading to v5? What’s holding you back? What are you most excited or scared about? What “gotchas” did you run into it? I hope you’ll share your thoughts in the comments.