Microsoft Releases PowerShell Core 6.0
Microsoft last week announced the general availability of PowerShell Core 6.0, which is notable for being a cross-platform DevOps tool for Windows, Linux and macOS.
This version of PowerShell is supported on Windows clients dating back to Windows 7, and Windows Server back to Windows Server 2008 R2. It also works with newer versions of CentOS, Debian, Fedora, OpenSUSE, Red Hat Enterprise Linux and Ubuntu operating systems.
The big change with PowerShell Core 6.0 is that it was developed on the open source .NET Core platform. It's not specifically tied to the Windows platform, like the current Windows PowerShell offering.
PowerShell Core will follow Microsoft's Modern Lifecycle Policy. That policy is open ended, but it seems to mean that Microsoft may give a one-year advance notice on discontinuing software if no alternative solution is available, and customers will be required to keep the software up to date by accepting all updates.
Microsoft describes how to install PowerShell Core on Windows systems in this document. Installation on Linux and macOS systems is described here. There's currently a glitch for Linux PowerShell Core 6.0 "release candidate" users. They have to perform a "clean install" to get the general availability release.
Some functionality in Windows PowerShell didn't make it to PowerShell Core 6.0. In general, these technologies are missing, per Microsoft's announcement:
- PowerShell Workflows
- PowerShell Snap-ins
- WMIv1 cmdlets (Get-WmiObject, Invoke-WmiMethod, etc.) We recommend using the CIM/WMIv2 cmdlets (Get-CimInstance, Invoke-CimMethod, etc.)
- Executing Desired State Configuration (DSC) resources using PowerShell Core
On the latter point, Microsoft had unveiled its plans in September to eventually replace Windows PowerShell DSC and DSC for Linux with "Desired State Configuration Core." Apparently, that capability is not ready. In an "Ask Microsoft Anything" on PowerShell Yammer forum held last Thursday, Microsoft employee Michael Greene indicated in a session response that more information about DSC plans will be coming.
PowerShell Core 6.0 lacks an integrated scripting environment, according to a blog post by Mark Wragg, a senior DevOps engineer. A session response by Steve Lee, an engineer manager on the PowerShell team, indicated that "Visual Studio, Visual Studio Code, and .Net CLI are three different ways to build the code" for PowerShell Core 6.0, but he recommended using Visual Studio Code for debugging.
Wragg noted that his favorite PowerShell Core 6.0 addition is PowerShell remoting over SSH, allowing anywhere access. Microsoft provides a list of what's new in PowerShell Core 6.0 in this document.
The Core Future
The Core version release is an important milestone to note because it's where Microsoft's future PowerShell development efforts are heading. In addition to the Core version, Windows PowerShell continues to exist. It's even possible to run PowerShell Core 6.0 and Windows PowerShell side by side without conflicts.
Microsoft is planning to provide continued support for most versions of Windows PowerShell, provided that the underlying Windows operating system is still a supported product. The notable exception is Windows PowerShell 2.0, which is considered to be a "deprecated" product (that is, not developed), and also a potential security risk to use.
Despite assurances of continued support for Windows PowerShell, Microsoft's development efforts likely won't be happening as much on that side. Here's how the announcement characterized Microsoft's plans:
There are currently no plans to introduce new functionality to Windows PowerShell. This means that the risk of regression will be very low for Windows PowerShell, so you can count on it as a stable platform for your existing workloads. There are also no plans to provide a new Windows Management Framework (WMF) package for downlevel operating systems.
Microsoft typically distributes its new Windows PowerShell products through its Windows Management Framework package releases. In a session comment, Microsoft confirmed that WMF 5.1 will be the last distribution of Windows PowerShell.
"Windows 5.1 and WMF 5.1 are the last official releases for Windows PowerShell," stated Michael Holste, a community manager for Office 365. "That said, we will continue addressing any critical blockers: E.g.: Security Fixes. Windows PowerShell 5.1 will continue be fully supported and service[d] via Windows Updates."
At best, Microsoft plans to just provide security fixes for Windows PowerShell, according to a session comment by Jeffrey Snover, a Technical Fellow at Microsoft and the chief architect for the Enterprise Cloud Group (and PowerShell's inventor).
Where's PowerShell Core 1.0?
Microsoft kind of explained its peculiar versioning for PowerShell Core 6.0 back in July when it described its roadmap plans. Windows PowerShell 6 never got out of beta, it seems. PowerShell Core 6.0 is considered to be a superset of Windows PowerShell 5.1 (the current and last Windows PowerShell version), though, so Microsoft just stuck the 6.0 numbering onto PowerShell Core product.
That seems to be the explanation. To add to the confusion, there are also PowerShell Core 5.0/5.1 versions in existence that were released specifically just for use with Nano Server. Nano Server is Microsoft's minimal footprint configuration option for Windows Server 2016.
PowerShell Core 6.0 and Existing Scripts
Given that PowerShell Core represent Microsoft's future development direction, will organizations now have to convert their Windows PowerShell scripts into PowerShell Core 6.0 scripts? Lee on the PowerShell team downplayed that idea in a PowerShell AMA session response:
Existing Windows PowerShell scripts will continue to work on Windows PowerShell as it's fully supported so there's no requirement to port existing scripts to PSCore6. Since PSCore6 works side-by-side with Windows PowerShell, you should be able to use both concurrently. If you want to leverage some of the new language or cmdlets enhancements with PSCore6, you may have to make some changes to existing scripts if they have dependencies on Windows PowerShell specific modules. Over time as we get more cmdlet coverage on PSCore6, this will be less of an issue. There is currently no plan to remove Windows PowerShell nor put PSCore6 inbox on Windows.
Joey Aiello, a program manager on the PowerShell team, added that PowerShell Core is gaining module support and that "over time, we'll be doing more to make modules more compatible via the WindowsPowerShellCompatibilityPack module." In addition, Microsoft plans to support Windows PowerShell "at least as long as Windows 10 and Windows Server 2016 are supported."
Other observers in the thread noted that there can be breaking changes between PowerShell versions when moving to PowerShell Core 6.0. Older scripts likely will have to be retested. In particular, there could be problems with Windows automation and third-party snap-ins.
Vendors will have to ensure that their PowerShell snap-ins work with .NET Standard, according to a session comment by Snover.
Kurt Mackie is senior news producer for the 1105 Enterprise Computing Group.