Update PowerShell on Windows without confusing editions
Sample output — your paths and versions will differ.
Documentation: Microsoft Learn
Inspect a sample
Example reader
Inspect this page's example
Run supported commands against the practice data, or inspect the example without executing it.
Ready to inspect.
Show reference output
Inspect this example’s structure
Read the command and its supplied arguments. This example requires real PowerShell or its module; this diagram does not execute it.
Get-Command pwsh, powershell -ErrorAction SilentlyContinue | Select-Object Name, Source- Stage 1Get-Command
-ErrorAction - Stage 2Select-Object
Positional values or no named parameters
Choose the installation channel
Use the channel through which PowerShell 7 is managed: an organization package, MSI, Microsoft Store or WinGet. Follow Microsoft’s Windows installation guidance for that channel. Windows PowerShell 5.1 is a Windows component and is serviced differently.
Inspect before changing
Record the current engine and critical module versions. Keep a repeatable validation script for imports, remoting and the tasks your users run. Test an update in a representative environment before changing unattended administration jobs.
Update the intended package
With a WinGet-managed installation, inspect winget list --id Microsoft.PowerShell --exact, then use the matching upgrade operation when approved. Do not select a preview package accidentally. Package-manager availability and elevation requirements vary by machine.
Keep module updates separate
Update-Module operates on compatible PowerShellGet-managed modules; Update-PSResource belongs to PSResourceGet. Neither upgrades the PowerShell engine. Review module release notes, dependencies and authentication changes before accepting a newer module in production.
Verify after opening a new session
Close the old session, start the intended executable and check PSVersion. Import the required modules and run a read-only smoke test. Update task executable paths deliberately rather than assuming that installing pwsh.exe changes powershell.exe jobs.
Command-line reference
Show reference output
The code above is a reference for your own authorized environment. The output shown is a stored fictional example — run the command in your own terminal to inspect your installation.
Read the original documentation
Check your understanding
There is no runnable lab on this page — these run in your own terminal, so predict the answer first, then verify.
Q1. winget list --id Microsoft.PowerShell --exact prints a table with one row. What do the columns tell you?
Answer: The Name, Id, Version and Source columns confirm PowerShell is registered with winget and show which version winget currently knows about — that is the version winget upgrade would move you to.
Q2. The same command prints no rows at all. What does that tell you?
Answer: Winget has no record of PowerShell under that exact id — most likely PowerShell 7 was installed from the MSI, the Store, or is not installed at all. Use pwsh --version to check what is actually on the machine.
Q3. After upgrading, you open a terminal and $PSVersionTable.PSVersion still shows the old version. What is the most likely cause?
Answer: The terminal was already open and loaded the old pwsh.exe. Close it and open a fresh terminal so the new executable starts.