Theinstallation commands in this article are for the latest stable release of PowerShell. Toinstall a different version of PowerShell, adjust the command to match the version you need. Thefollowing links direct you to the release page for each version in the PowerShell repository onGitHub.
Winget, the Windows Package Manager, is a command-line tool enables users to discover, install,upgrade, remove, and configure applications on Windows client computers. This tool is the clientinterface to the Windows Package Manager service. The winget command-line tool is bundled withWindows 11 and modern versions of Windows 10 by default as the App Installer.
Windows Server 2025 Preview Build 26085 and later includes winget for Windows Server withDesktop Experience only. For more information, seeAnnouncing Windows Server Preview Build 26085.
On Windows systems using X86 or X64 processor, winget installs the MSI package. On systems usingthe Arm64 processor, winget installs the Microsoft Store (MSIX) package. For more information,see Installing from the Microsoft Store.
PowerShell 7.4 installs to a new directory and runs side-by-side with Windows PowerShell 5.1.PowerShell 7.4 is an in-place upgrade that removes previous versions of PowerShell 7. Previewversions of PowerShell can be installed side-by-side with other versions of PowerShell.
PowerShell 7.2 and newer has support for Microsoft Update. When you enable this feature, you'll getthe latest PowerShell 7 updates in your traditional Microsoft Update (MU) management flow, whetherthat's with Windows Update for Business, WSUS, Microsoft Endpoint Configuration Manager, or theinteractive MU dialog in Settings.
Enabling updates may have been set in a previous installation or manual configuration. UsingENABLE_MU=0 doesn't remove the existing settings. Also, this setting can be overruled by GroupPolicy settings controlled by your administrator.
MSI packages can be installed from the command line allowing administrators to deploy packageswithout user interaction. The MSI package includes the following properties to control theinstallation options:
Depending on how you download the file you may need to unblock the file using the Unblock-Filecmdlet. Unzip the contents to the location of your choice and run pwsh.exe from there. Unlikeinstalling the MSI packages, installing the ZIP archive doesn't check for prerequisites. Forremoting over WSMan to work properly, ensure that you've met the prerequisites.
The dotnet tool installer adds $HOME\.dotnet\tools to your $env:PATH environment variable.However, the currently running shell doesn't have the updated $env:PATH. You can start PowerShellfrom a new shell by typing pwsh.
By default, Windows Store packages run in an application sandbox that virtualizes access to somefilesystem and registry locations. Changes to virtualized file and registry locations don't persistoutside of the application sandbox.
This sandbox blocks all changes to the application's root folder. Any system-level configurationsettings stored in $PSHOME can't be modified. This includes the WSMAN configuration. This preventsremote sessions from connecting to Store-based installs of PowerShell. User-level configurations andSSH remoting are supported.
Beginning in PowerShell 7.2, the PowerShell package is now exempt from file and registryvirtualization. Changes to virtualized file and registry locations now persist outside of theapplication sandbox. However, changes to the application's root folder are still blocked.
For best results when upgrading, you should use the same install method you used when you firstinstalled PowerShell. If you aren't sure how PowerShell was installed, you can check the value ofthe $PSHOME variable, which always points to the directory containing PowerShell that the currentsession is running.
When upgrading, PowerShell won't upgrade from an LTS version to a non-LTS version. It onlyupgrades to the latest version of LTS, for example, from 7.2.3 to 7.2.22. To upgrade from anLTS release to a newer stable version or the next LTS, you need to install the new version withthe MSI for that release.
Windows 10 IoT Core adds Windows PowerShell when you include IOT_POWERSHELL feature, which we canuse to deploy PowerShell 7. The steps defined above for Windows 10 IoT Enterprise can be followedfor IoT Core as well.
Microsoft supports the installation methods in this document. There may be other third-party methodsof installation available from other sources. While those tools and methods may work, Microsoftcan't support those methods.
For flexibility and to support the needs of IT, DevOps engineers, and developers, there are severaloptions available to install PowerShell 7. In most cases, the installation options can be reduced tothe following methods:
Deploying the MSI package requires Administrator permission. The ZIP package can be deployed by anyuser. The ZIP package is the easiest way to install PowerShell 7 for testing, before committing to afull installation.
PowerShell 7.2 is built on .NET 6.0. Windows PowerShell 5.1 is built on .NET Framework 4.x. Thedifferences between the .NET versions might affect the behavior of your scripts, especially if youare calling .NET method directly. For more information,Differences between Windows PowerShell 5.1 and PowerShell 7.x.
The new location is added to your PATH allowing you to run both Windows PowerShell 5.1 andPowerShell 7. If you're migrating from PowerShell 6.x to PowerShell 7, PowerShell 6 is removed andthe 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 ofboth versions.
By default, Windows PowerShell and PowerShell 7 store modules in different locations. PowerShell 7combines those locations in the $Env:PSModulePath environment variable. When importing a module byname, PowerShell checks the location specified by $Env:PSModulePath. This allows PowerShell 7 toload both Core and Desktop modules.
A PowerShell profile is a script that executes when PowerShell starts. This script customizes yourenvironment by adding commands, aliases, functions, variables, modules, and PowerShell drives. Theprofile script makes these customizations available in every session without having to manuallyrecreate them.
Most of the modules you use in Windows PowerShell 5.1 already work with PowerShell 7, includingAzure PowerShell and Active Directory. We're continuing to work with other teams to add nativePowerShell 7 support for more modules including Microsoft Graph, Office 365, and others. For thecurrent list of supported modules, see PowerShell 7 module compatibility.
On Windows, we've also added a UseWindowsPowerShell switch to Import-Module to ease thetransition to PowerShell 7 for those using incompatible modules. For more information on thisfunctionality, see about_Windows_PowerShell_Compatibility.
Windows PowerShell 5.1 and below use the WS-Management (WSMAN) protocol for connection negotiationand data transport. Windows Remote Management (WinRM) uses the WSMAN protocol. If WinRM has beenenabled, PowerShell 7 uses the existing Windows PowerShell 5.1 endpoint named Microsoft.PowerShellfor remoting connections. To update PowerShell 7 to include its own endpoint, run theEnable-PSRemoting cmdlet. For information about connecting to specific endpoints, seeWS-Management Remoting in PowerShell
SSH-based remoting was added in PowerShell 6.x to support other operating systems that can't useWindows native components like WinRM. SSH remoting creates a PowerShell host process on thetarget computer as an SSH subsystem. For details and examples on setting up SSH-based remoting onWindows or Linux, see: PowerShell remoting over SSH.
The PowerShell Gallery (PSGallery) contains a module and cmdlet that automatically configuresSSH-based remoting. Install the Microsoft.PowerShell.RemotingTools module from thePSGallery and run the Enable-SSH cmdlet.
To create a remote session, specify the target computer with the HostName parameter and providethe user name with UserName. When running the cmdlets interactively, you're prompted for apassword.
Group Policy tools use administrative template files (.admx, .adml) to populate policy settingsin the user interface. This allows administrators to manage registry-based policy settings. TheInstallPSCorePolicyDefinitions.ps1 script installs PowerShell Administrative Templates on thelocal machine.
Visual Studio Code (VSCode) with the PowerShell Extension is the supported scriptingenvironment for PowerShell 7. The Windows PowerShell Integrated Scripting Environment (ISE) onlysupports Windows PowerShell.
To make the transition to Visual Studio Code easier, use the Enable ISE Mode function availablein the Command Palette. This function switches VSCode into an ISE-style layout. The ISE-stylelayout gives you all the new features and capabilities of PowerShell in a familiar user experience.
There are no plans to update the ISE with new features. In the latest versions of Windows 10 orWindows Server 2019 and higher, the ISE is now a user-uninstallable feature. There are no plans topermanently remove the ISE. The PowerShell Team and its partners are focused on improving thescripting experience in the PowerShell extension for Visual Studio Code.
Is there a built in self upgrade command, or I just go to the release page, download the latest release and run the installer? (this latter case will it correctly upgrade, or just overwrites, or something else, resulting side effects?)
You can tell it to include powershell when running Windows Update. There is a checkbox for this in the MSI while installing PS 7, but there doesn't seem to be a way to view it after install other than the registry. Like this:
If you want to look at it first without setting it just use Get instead of Set and leave off "-Value 1". Setting the value to 0 will turn the feature off. You can use RegEdit too, this just seems faster.
3a8082e126