Migrating from Windows PowerShell 5.1 to PowerShell 7

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 works side-by-side with Windows PowerShell letting you easily test and compare between editions before deployment. Migration is simple, quick, and safe.

PowerShell 7 is supported on the following Windows operating systems:

• Windows 10, and 11
• Windows Server 2016, 2019, and 2022

PowerShell 7 also runs on macOS and several Linux distributions. For a list of supported operating systems and information about the support lifecycle, see the PowerShell Support Lifecycle.

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

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.

You may also install PowerShell 7 via the Windows Store or winget. For more information about both of these methods, see the detailed instructions in Installing PowerShell on Windows.

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

Differences in .NET versions

PowerShell 7.4 is built on .NET 8.0. Windows PowerShell 5.1 is built on .NET Framework 4.x. The differences between the .NET versions might affect the behavior of your scripts, especially if you are calling .NET method directly. For more information, Differences between Windows PowerShell 5.1 and PowerShell 7.x.

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

For more information, see about_PSModulePath.

For more information about Modules, see about_Modules.

Separate profiles

A PowerShell profile is a script that executes when PowerShell starts. This script customizes your environment by adding commands, aliases, functions, variables, modules, and PowerShell drives. The profile script makes these customizations available in every session without having to manually recreate them.

The path to the location of the profile has changed in PowerShell 7.

• In Windows PowerShell 5.1, the location of the profile is $HOME\Documents\WindowsPowerShell.
• In PowerShell 7, the location of the profile is $HOME\Documents\PowerShell.

The profile filenames have also changed:

$PROFILE | Select-Object *Host* | Format-List

 AllUsersAllHosts       : C:\Program Files\PowerShell\7\profile.ps1
 AllUsersCurrentHost    : C:\Program Files\PowerShell\7\Microsoft.PowerShell_profile.ps1
 CurrentUserAllHosts    : C:\Users\<user>\Documents\PowerShell\profile.ps1
 CurrentUserCurrentHost : C:\Users\<user>\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

For more information about_Profiles.

PowerShell 7 compatibility with Windows PowerShell 5.1 modules

Most of the modules you use in Windows PowerShell 5.1 already work with PowerShell 7, including Azure PowerShell and Active Directory. We're continuing to work with other teams to add native PowerShell 7 support for more modules including Microsoft Graph, Office 365, and others. For the current list of supported modules, see PowerShell 7 module compatibility.

PowerShell Remoting

PowerShell remoting lets you run any PowerShell command on one or more remote computers. You can establish persistent connections, start interactive sessions, and run scripts on remote computers.

WS-Management remoting

Windows PowerShell 5.1 and below use the WS-Management (WSMAN) protocol for connection negotiation and data transport. Windows Remote Management (WinRM) uses the WSMAN protocol. If WinRM has been enabled, PowerShell 7 uses the existing Windows PowerShell 5.1 endpoint named Microsoft.PowerShell for remoting connections. To update PowerShell 7 to include its own endpoint, run the Enable-PSRemoting cmdlet. For information about connecting to specific endpoints, see WS-Management Remoting in PowerShell

To use Windows PowerShell remoting, the remote computer must be configured for remote management. For more information, including instructions, see About Remote Requirements.

For more information about working with remoting, see About Remote

SSH-based remoting

SSH-based remoting was added in PowerShell 6.x to support other operating systems that can't use Windows native components like WinRM. SSH remoting creates a PowerShell host process on the target computer as an SSH subsystem. For details and examples on setting up SSH-based remoting on Windows or Linux, see: PowerShell remoting over SSH.

The New-PSSession, Enter-PSSession, and Invoke-Command cmdlets have new parameter sets to support SSH connections.

[-HostName <string>]  [-UserName <string>]  [-KeyFilePath <string>]

To create a remote session, specify the target computer with the HostName parameter and provide the user name with UserName. When running the cmdlets interactively, you're prompted for a password.

Enter-PSSession -HostName <Computer> -UserName <Username>

Alternatively, when using the HostName parameter, provide the username information followed by the at sign (@), followed by the computer name.

Enter-PSSession -HostName <Username>@<Computer>

You may set up SSH key authentication using a private key file with the KeyFilePath parameter. For more information, see OpenSSH Key Management.

Group Policy supported

PowerShell includes Group Policy settings to help you define consistent option values for servers in an enterprise environment. These settings include:

• Console session configuration: Sets a configuration endpoint in which PowerShell is run.
• Turn on Module Logging: Sets the LogPipelineExecutionDetails property of modules.
• Turn on PowerShell Script Block Logging: Enables detailed logging of all PowerShell scripts.
• Turn on Script Execution: Sets the PowerShell execution policy.
• Turn on PowerShell Transcription: enables capturing of input and output of PowerShell commands into text-based transcripts.
• Set the default source path for Update-Help: Sets the source for Updatable Help to a directory, not the Internet.

For more information, see about_Group_Policy_Settings.

PowerShell 7 includes Group Policy templates and an installation script in $PSHOME.

Group Policy tools use administrative template files (.admx, .adml) to populate policy settings in the user interface. This allows administrators to manage registry-based policy settings. The InstallPSCorePolicyDefinitions.ps1 script installs PowerShell Administrative Templates on the local machine.

Get-ChildItem -Path $PSHOME -Filter *Core*Policy*

    Directory: C:\Program Files\PowerShell\7

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2/27/2020 12:38 AM          15861 InstallPSCorePolicyDefinitions.ps1
-a---           2/27/2020 12:28 AM           9675 PowerShellCoreExecutionPolicy.adml
-a---           2/27/2020 12:28 AM           6201 PowerShellCoreExecutionPolicy.admx

Separate Event Logs

Windows PowerShell and PowerShell 7 log events to separate event logs. Use the following command to get a list of the PowerShell logs.

Get-WinEvent -ListLog *PowerShell*

For more information, see about_Logging_Windows.

Improved editing experience with Visual Studio Code

Visual Studio Code (VSCode) with the PowerShell Extension is the supported scripting environment for PowerShell 7. The Windows PowerShell Integrated Scripting Environment (ISE) only supports Windows PowerShell.

The updated PowerShell extension includes:

• New ISE compatibility mode
• PSReadLine in the Integrated Console, including syntax highlighting, multi-line editing, and back search
• Stability and performance improvements
• New CodeLens integration
• Improved path autocompletion

To make the transition to Visual Studio Code easier, use the Enable ISE Mode function available in the Command Palette. This function switches VSCode into an ISE-style layout. The ISE-style layout gives you all the new features and capabilities of PowerShell in a familiar user experience.

To switch to the new ISE layout, press Ctrl+Shift+P to open the Command Palette, type PowerShell and select PowerShell: Enable ISE Mode.

To set the layout to the original layout, open the Command Palette, select PowerShell: Disable ISE Mode (restore to defaults).

For details about customizing the VSCode layout to ISE, see How to Replicate the ISE Experience in Visual Studio Code

Next Steps

Armed with the knowledge to effectively migrate, install PowerShell 7 now!