PowerShell Core 6.0: Generally Available (GA) and Supported!

PowerShell Core 6.0 is a new edition of PowerShell that is cross-platform (Windows, macOS, and Linux), open-source, and built for heterogeneous environments and the hybrid cloud.

First and foremost, thank you to all of our amazing community, especially our open-source contributors (the most recent of which you can find on our community dashboard at https://aka.ms/PSGitHubBI) for donating your time and energy to PowerShell Core. Whether you contributed code, tests, documentation, issues, or even just your feedback and opinions, we are extremely grateful for the sweat and tears that you’ve invested in PowerShell. (For those interested in contributing, hop and over to our Contribution Guide on GitHub. You don’t have to be a guru to help out!)

FAQ

Where do I get PowerShell Core 6.0?

To download PowerShell Core on Windows, see https://aka.ms/getps6-windows.
To download PowerShell Core on macOS and Linux, see https://aka.ms/getps6-linux.

I already had PowerShell Core on my Linux machine, and it’s not updating. How do I get the latest version?

We’re currently working through a known issue where powershell-6.0.0 is viewed by package managers as a lower version than powershell-6.0.0-rc2.

In the meantime, a clean install will get you the latest version:

sudo apt remove powershell && sudo apt-get install powershell

sudo yum remove powershell && sudo yum install powershell

What’s the difference between Windows PowerShell and PowerShell Core?

There are now two editions of PowerShell:

Windows PowerShell is the edition of PowerShell built on top of .NET Framework
(sometimes referred to as “FullCLR”):

• This is the PowerShell that has been in widespread use for the last ~10 years.
• Because of it’s dependency on the .NET Framework, Windows PowerShell is only available on Windows (hence the name).
• The released versions of Windows PowerShell include 1.0, 2.0, 3.0, 4.0, 5.0, and 5.1.
• Windows PowerShell is available as a built-in component in Windows client and Windows Server.
• Windows PowerShell is launched as powershell.exe.
• On Windows PowerShell 5.0/5.1, $PSVersionTable.PSEdition is set to Desktop.
• Any usage of .NET-based functionality (e.g. C# cmdlets, Add-Type, and the invocation of static .NET Methods), relies on the .NET Framework runtime. This means Windows PowerShell’s .NET usage is limited to the functionality exposed by the .NET Framework and .NET Standard.
• Continues to be supported via critical bug fixes in the newest releases of Windows and Windows Server

PowerShell Core is the edition of PowerShell built on top of .NET Core
(sometimes simplified to “CoreCLR”).

• PowerShell Core is cross-platform, available on Windows, macOS, and Linux, thanks to the cross-platform nature of .NET Core.
• PowerShell Core is launched as pwsh.exe on Windows and pwsh on macOS and Linux
• On PowerShell Core, $PSVersionTable.PSEdition is set to Core.
  Note: while PowerShell Core 6.0 is cross-platform, there is also a PowerShell Core 5.0/5.1 released exclusively as part of Microsoft Nano Server.
• Any usage of .NET-based functionality (e.g. C# cmdlets, Add-Type, and the invocation of static .NET Methods), relies on the .NET Core runtime. This means PowerShell Core is limited to the functionality exposed by .NET Core and .NET Standard.

What platforms are supported?

PowerShell Core is officially supported on the following platforms:

• Windows 7, 8.1, and 10
• Windows Server 2008 R2, 2012 R2, 2016
• Windows Server Semi-Annual Channel
• Ubuntu 14.04, 16.04, and 17.04
• Debian 8.7+, and 9
• CentOS 7
• Red Hat Enterprise Linux 7
• OpenSUSE 42.2
• Fedora 25, 26
• macOS 10.12+

Our community has also contributed packages for the following platforms,
but they are not officially supported:

• Arch Linux
• Kali Linux
• AppImage (works on multiple Linux platforms)

We also have experimental (unsupported) releases for the following platforms:

• Windows on ARM32/ARM64
• Raspbian (Stretch)

What’s new in PowerShell Core? Why should I use it?

Check out What’s New in PowerShell Core 6.0 for a complete list!

Does PowerShell Core affect my Windows PowerShell installation?

Nope! PowerShell Core is completely side-by-side with Windows PowerShell. In fact, an awesome feature of PowerShell Core is that you can test new versions without affecting existing workloads. Whether it’s installed via an MSI or installed portably from the ZIP package, your Windows PowerShell installation is not affected by PowerShell Core.

What modules work with PowerShell Core?

Today, we ship the following set of “built-in” modules as part of PowerShell Core:

• CimCmdlets
• Microsoft.PowerShell.Archive
• Microsoft.PowerShell.Diagnostics
• Microsoft.PowerShell.Host
• Microsoft.PowerShell.Management
• Microsoft.PowerShell.Security
• Microsoft.PowerShell.Utility
• Microsoft.WSMan.Management
• PackageManagement
• PowerShellGet
• PSDesiredStateConfiguration
• PSDiagnostics
• PSReadLine

You can browse the reference for these modules via the PowerShell Module Browser. To see the commands available in these modules you can run Get-Command:

Get-Command -Module Microsoft.PowerShell.Management

Some cmdlets that shipped as part of these modules in Windows PowerShell are not available today in PowerShell Core. For a complete list of these cmdlets, the most up-to-date list is currently maintained in this cmdlet discovery test.

What about other 1st-party Microsoft modules?

1st-party Microsoft modules are generally in one of three categories:

• Modules that ship as part of Windows client or Windows Server:
  these are the modules you see after installing Windows and running Get-Module -ListAvailable (less the modules that in the “built-in” list above).
• Modules that ship as a part of a Microsoft product. For example, System Center applications include PowerShell modules as part of their installation.
• Modules that ship on the PowerShell Gallery. For example, Azure PowerShell is delivered via the Gallery.

For all of these categories, unless a module is explicitly supported in PowerShell Core by Windows or by the product group, there is no guarantee that it will work with PowerShell Core.

However, because of the guarantees of .NET Standard and CDXML,
many modules designed for Windows PowerShell are highly compatible with PowerShell Core. For more information on how to add Windows PowerShell modules to your PSModulePath for usage in PowerShell Core,
see Backwards compatibility with Windows PowerShell.

How do I know which modules on the PowerShell Gallery work with PowerShell Core?

The PowerShell Gallery is the community repository for PowerShell modules.

You can find modules that have been tagged with PowerShell Core support by searching for the tag PSEdition_Core.

You can learn more about PSEditions on the Gallery with our doc on Items with compatible PowerShell Editions

How do I build modules and scripts that are compatible with PowerShell Core?

If you’re building a C#-based cmdlet, you should build your cmdlets against .NET Standard 2.0 and PowerShell Standard. For more info on how to do this, check out:

• Creating a cross-platform binary module with the .NET Core command-line interface tools
• Building a C# Cmdlet with Visual Studio

Note: PowerShell Standard is currently in preview with a 3.0 version for PowerShell versions 3 through 6. We will soon have a version 5.0 that supports a wider set of APIs included PowerShell versions 5 through 6.

If you’re building a PowerShell-based cmdlet or script, you should make sure you’re using .NET types/assemblies, and that you’re using cmdlets and modules available on the platform you’re targeting. We’ll be adding PSScriptAnalyzer rules soon that will help you target sets of operating systems and PowerShell editions/versions.

Can I host PowerShell Core in a .NET Core application?

Absolutely! For more information, check out this doc on Hosting PowerShell Core in .NET Core Applications.

Does PowerShell Core support remoting?

Yes! PowerShell Core supports remoting over the PowerShell Remoting Protocol (PSRP) via both WSMan and SSH, and is interoperable with Windows PowerShell over WSMan. However, some authentication types are not supported for WSMan-based remoting clients on non-Windows platforms. Also, hosting a WSMan-based server on non-Windows platforms is still currently an experimental scenario.

For more information on setting this up, see:

• SSH Remoting in PowerShell Core
• WSMan Remoting in PowerShell Core

How is PowerShell Core supported?

PowerShell Core is adopting the Microsoft Modern Lifecycle Policy, a new support lifecycle intended to keep customers up-to-date with the latest versions.

In general, Microsoft support agreements cover support for PowerShell Core. You can read more about the specifics of this policy and how it applies to PowerShell Core at https://aka.ms/pslifecycle.

What’s missing from PowerShell Core?

As part of the move to .NET Core and other operating systems,
we were forced to leave behind some technologies that were being used by Windows PowerShell.

In other cases, we took the opportunity of PowerShell being refactored to stop supporting lesser used technologies. Some of these technologies may eventually return to PowerShell Core, but many will not.

At a high-level, these include:

• 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

We’ve also made a longer tail of small changes to the PowerShell language, engine, and cmdlets that technically qualify as breaking changes.

For more information on why we made these changes/removals, see our document on Breaking Changes in PowerShell Core.

What’s happening to Windows PowerShell?

The short answer is that it’s still useful and supported!

Windows PowerShell 3.0, 4.0, and 5.1 will continue to be supported on supported versions of Windows and Windows Server.
(Note: While Windows PowerShell 2.0 is still in support, it has been deprecated, and it’s recommend that workloads be migrated to newer versions of PowerShell.)

However, 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.

Where can I provide feedback?

First, we’re having an “Ask Me Anything” (AMA) with Jeffrey Snover and the PowerShell Team at https://aka.ms/powershellama on Microsoft Tech Communities on Thursday, January 11th at 9:00 AM PST (GMT-8).

You can also file issues on GitHub where we track, prioritize, and discus all our work on PowerShell Core. We’re usually very good about responding to issues there, as are many of the contributors outside Microsoft that help out in our repository.

Thanks!

Thanks again to everyone for all the contributions and support. I hope you enjoy PowerShell Core 6.0 as much as we do.

Joey Aiello
Program Manager, PowerShell