I co-maintain the Chocolatey package for PowerShell. With the recent release of PowerShell 5.1, the Chocolate packaging is able to handle one more challenging, but potentially common, deployment scenario.
Microsoft is moving fast to retire version 5.0 by June of 2017 - including removing the downloads for 5.0 - a distinct encouragement to evaluate and adopt 5.1 quickly.
Lets talk about this challenge as well as a brief summary of some other challenging deployment scenarios that were already handled by the Chocolatey Package.
Thanks to the Microsoft PowerShell teams forthcoming publishing of the 5.1 release limitations - none of this information had to be discovered the hard way by all those attempting to deploy 5.1 - these are known issues highlighed in release notes and downloads and Microsoft has provided a PowerShell helper script to apply 5.1 in the trickiest scenarios.
Using Windows Update
Microsoft recently published PowerShell 5.1 for Server 2012 R2 and Windows 8.1 to the Windows Update Catalog - if your company actively manages Windows updates this is likely the smoothest way to 5.1.
PowerShell 5.1 Deployment Challenge #1
The first challenge is that PowerShell 5.1 requires .NET 4.5.2 - but it does not install it nor refuse to install if it is not present. I am an advocate of this conservative approach to upgrading .NET runtimes. I have come across many applications that are quite sensitive to the version of .NET used and I really don’t want to be the admin that sent an entire fleet of production cloud servers to their early demise because I “innocently” deployed PowerShell. And yes, while it’s true that all changes should be tested before deploying - many times the faults show up in areas that aren’t currently part of even the most thorough test plans or test automation.
Unlike directly deploying the .MSU, the Chocolatey package will refuse to install if the .NET version is not sufficent for installation - this alerts you to the challenge immediately.
PowerShell 4 and 5.0 upgrades both had similar behavior - the Chocolatey package will ensure you are aware that your .NET version is insufficient for full PowerShell functionality or for the upgrade to even succeed. In some cases the upgrade goes fine, but the version of PowerShell does not change after reboot due to lacking the correct .NET version.
PowerShell 5.1 Deployment Challenge #2
The second challenge is more specific. It is a good news, bad news story. The good news is you can now install PowerShell 5.1 without first installing PowerShell 4.0 (WMF 4 is a requirement for installing WMF 5.0) on Windows 7 / Server 2008 R2 (Windows Version 6.1) machines- awesome and hats off to the PowerShell team for helping with this backlevel problem so far down the road - they are really listening to their users.
The bad news is that if you happen to have installed PowerShell / WMF 3 on those machines (and many, many of us did), then your PSModulePath can be lost during the upgrade. What’s the big deal you ask? Well if your PSModulePath was never changed by installing custom modules or administrative tools that have their PowerShell modules in a custom folder - then you would have no problems simply making sure the default paths are in PSModulePath. However, PowerShell has such broad usage across all Windows machines that it is most likely going to break something by wiping out any customizations to PSModulePath as many optional software installs will add to the path.
The new PowerShell package does not seem to be able to handle this challenge - my guess is because the removal happens as part of the code in the WMF 3 package’s self-removal code. I have tested and determined that the action happens AFTER the required reboot - making it difficult to get one’s hands on a fixup.
The Powershell Chocolatey Package for 5.1 detects when you are putting 5.1 over top of 3.0 and saves the path customizations aside and queues them up for re-addition after the reboot. The method for scheduling this reboot task on a headless system was the topic of [this Mission Impossible Code post].(https://missionimpossiblecode.com/post/continue-your-automation-to-run-once-after-restarting-a-headless-windows-system/)
PowerShell 5.1 Deployment Challenge #3
Another automation challenge lurks as well - this is the fact that it is very easy to mess up path environment variables if you aren’t careful. Most notably it is very bad practice to read the current processes “PSModulePath”, update it and write it back to the Machine level environment variable. The path updating code in the PowerShell 5.1 package was covered in this Mission Impossible Code post - along with actual working code. Among other things, this code ensures that you do not accidentally expand environment variables contained in your path to their static values.
All aspects of this challenge are handled by the Chocolatey Package for PowerShell 5.1 - at the time of this writing the package has been downloaded 142,000 times.
If you’ve been hearing the excitement about Chocolatey and want to get started, you might want to watch my PluralSight coures titled [Chocolatey NuGet Essentials for Automation Pros].(https://app.pluralsight.com/player?course=chocolatey-nuget-automation-pros&author=darwin-sanoy&name=chocolatey-nuget-automation-pros-m0&clip=0)
You can find this package at https://chocolatey.org/packages/powershell.
Steal My PowerShell Code / This Code In Production
If you currently can’t leverage PowerShell or prefer to roll this challenging update yourself, you can steal the code from the Chocolatey Package - here are the relevant lines: https://gitlab.com/DarwinJS/ChocoPackages/-/blob/master/PowerShell/v5.1/tools/ChocolateyInstall.ps1#L106-174
