Designed for cloud, on-premises, and hybrid environments, PowerShell 7 is packed with enhancements and new features.

Installs and runs side-by-side with Windows PowerShell
Improved compatibility with existing Windows PowerShell modules
New language features, like ternary operators and ForEach-Object -Parallel
Improved performance
SSH-based remoting
Cross-platform interoperability
Support for Docker containers

PowerShell 7 is supported on the following Windows operating systems:

PowerShell 7 currently supports the following operating systems on x64, including:

Windows 8.1, and 10
Windows Server 2012, 2012 R2, 2016, and 2019
macOS 10.13+
Red Hat Enterprise Linux (RHEL) / CentOS 7
Fedora 30+
Debian 9
Ubuntu LTS 16.04+
Alpine Linux 3.8+

Additionally, PowerShell 7.0 supports ARM32 and ARM64 flavors of Debian, Ubuntu, and ARM64 Alpine Linux.

Check the installation instructions for your preferred operating system Windows, macOS, or Linux.

While not officially supported, the community has also provided packages for Arch and Kali Linux.

Installing PowerShell 7

For flexibility and to support the needs of IT, DevOps engineers, and developers, there are several options available to install PowerShell 7. In most cases, the installation options can be reduced to the following methods:

Deploy PowerShell using the MSI package
Deploy PowerShell using the ZIP package

Note: The MSI package can be deployed and updated with management products such as System Center Configuration Manager (SCCM). Download the packages from GitHub Release page.

Deploying the MSI package requires Administrator permission. The ZIP package can be deployed by any user. The ZIP package is the easiest way to install PowerShell 7 for testing, before committing to a full installation.

Download the installer package

Go to the GitHub releases page → https://github.com/PowerShell/PowerShell/releases and scroll down to the Assets section.

press Next

press Install

Finish

Once the installation is finished, you should see this new PowerShell 87 (x64) icon in your start menu

PowerShell 7 (x64)

$PSVersionTable

Alternatively, you can install it using PowerShell using the command line below:

msiexec.exe /package PowerShell-7.0.2-win-x64.msi /quiet ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL=1 ENABLE_PSREMOTING=1 REGISTER_MANIFEST=1

The MSI package includes the following properties to control the installation options:

ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL — This property controls the option for adding the Open PowerShell item to the context menu in Windows Explorer.
ENABLE_PSREMOTING — This property controls the option for enabling PowerShell remoting during installation.
REGISTER_MANIFEST — This property controls the option for registering the Windows Event Logging manifest.

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.

Using PowerShell 7 side-by-side with Windows PowerShell 5.1

PowerShell 7 is designed to coexist with Windows PowerShell 5.1. The following features ensure that your investment in PowerShell is protected and your migration to PowerShell 7 is simple.

Separate installation path and executable name
Separate PSModulePath
Separate profiles for each version
Improved module compatibility
New remoting endpoints
Group policy support
Separate Event logs

Separate installation path and executable name

PowerShell 7 installs to a new directory, enabling side-by-side execution with Windows PowerShell 5.1.

Install locations by version:

Windows PowerShell 5.1: $env:WINDIR\System32\WindowsPowerShell\v1.0
PowerShell Core 6.x: $env:ProgramFiles\PowerShell\6
PowerShell 7: $env:ProgramFiles\PowerShell\7

The new location is added to your PATH allowing you to run both Windows PowerShell 5.1 and PowerShell 7. If you’re migrating from PowerShell Core 6.x to PowerShell 7, PowerShell 6 is removed and the PATH replaced.

In Windows PowerShell, the PowerShell executable is named powershell.exe. In version 6 and above, the executable is named pwsh.exe. The new name makes it easy to support side-by-side execution of both versions.

Separate PSModulePath

By default, Windows PowerShell and PowerShell 7 store modules in different locations. PowerShell 7 combines those locations in the $Env:PSModulePath environment variable. When importing a module by name, PowerShell checks the location specified by $Env:PSModulePath. This allows PowerShell 7 to load both Core and Desktop modules.

The following examples show the default values of $Env:PSModulePath for each version.

For Windows PowerShell 5.1:

$Env:PSModulePath -split (';')C:\Users\<user>\Documents\WindowsPowerShell\Modules C:\Program Files\WindowsPowerShell\Modules C:\WINDOWS\System32\WindowsPowerShell\v1.0\Modules

For PowerShell 7:

$Env:PSModulePath -split (';')C:\Users\<user>\Documents\PowerShell\Modules C:\Program Files\PowerShell\Modules C:\Program Files\PowerShell\7\Modules C:\Program Files\WindowsPowerShell\Modules C:\WINDOWS\System32\WindowsPowerShell\v1.0\Modules

Notice that PowerShell 7 includes the Windows PowerShell paths and the PowerShell 7 paths to provide autoloading of modules.

Note: Additional paths may exist if you have changed the PSModulePath environment variable or installed custom modules or applications.

For more information, see PSModulePath in about_Environment_Variables.

For more information about Modules, see about_Modules.

https://learn.microsoft.com/en-ca/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.4

Migrating from Windows PowerShell 5.1 to PowerShell 7