Why Knowing Your PowerShell Version Matters

Before diving into the methods for checking your PowerShell version, it’s important to understand why this information is valuable. The PowerShell ecosystem has undergone substantial changes over the years, with each major release introducing new capabilities, deprecating outdated features, and modifying existing functionality. When you know your exact PowerShell version, you can make informed decisions about script compatibility, module installations, and system requirements.

Compatibility is perhaps the most critical reason to know your PowerShell version. Organizations often maintain extensive libraries of automation scripts that have been developed and tested on specific PowerShell versions. When you attempt to run a script on an incompatible version, you may encounter unexpected errors, failed commands, or even system instability. By checking your PowerShell version first, you can verify compatibility before executing any scripts, saving time and preventing potential issues.

Security considerations also play a significant role in version awareness. Microsoft regularly releases security patches and updates for PowerShell, with newer versions containing important security enhancements that protect against known vulnerabilities. If you’re running an outdated version, your system may be exposed to security risks that have been addressed in later releases. Enterprise environments, in particular, must maintain awareness of PowerShell versions across their infrastructure to ensure compliance with security policies and industry regulations.

Feature availability represents another compelling reason to track your PowerShell version. PowerShell 7 introduced groundbreaking features like ForEach-Object with the Parallel parameter, enabling parallel processing of pipeline operations that dramatically improve performance for large-scale tasks. The ternary operator, null-coalescing operators, and pipeline chain operators added in PowerShell 7 provide more concise and readable code structures. If you’re using Windows PowerShell 5.1, these features simply won’t be available, and attempting to use them will result in syntax errors.

Understanding PowerShell Editions and Version Numbers

PowerShell version numbers follow a standard format that provides detailed information about the specific release you’re using. The version number typically appears as four components separated by periods, such as 5.1.19041.1023 or 7.4.0. The first number represents the major version, which indicates substantial changes and new features. The second number is the minor version, denoting smaller feature additions and improvements. The third and fourth numbers represent the build and revision, indicating specific patches and bug fixes.

The PSEdition property distinguishes between the two main PowerShell editions currently in use. Windows PowerShell shows “Desktop” as its edition, while PowerShell Core and PowerShell 7 display “Core” as their edition. This distinction is crucial because it affects module compatibility, available cmdlets, and the underlying .NET runtime being used. Desktop edition PowerShell runs on the full .NET Framework and is limited to Windows systems, while Core edition runs on .NET Core or .NET 5+ and supports multiple operating systems.

Pre-Installed PowerShell Versions by Windows Operating System

Different Windows operating systems come with different pre-installed PowerShell versions, and understanding this relationship helps set expectations for what you’ll find on any given system. Windows 7 and Windows Server 2008 R2 originally shipped with PowerShell 2.0, which lacked many features we now consider standard. Windows 8 and Windows Server 2012 brought PowerShell 3.0, introducing workflows and significantly improved cmdlet functionality. Windows 8.1 and Windows Server 2012 R2 upgraded to PowerShell 4.0, adding Desired State Configuration and enhanced debugging capabilities.

Windows 10 marked a significant shift, with most editions shipping with PowerShell 5.0 or 5.1 after updates. Windows 10 version 1607 (Anniversary Update) and later releases included PowerShell 5.1 as the default installation. Windows 11 continues to include PowerShell 5.1 as the built-in Windows PowerShell version. However, it’s important to note that PowerShell 7 is not pre-installed on any Windows version and must be manually downloaded and installed from Microsoft’s GitHub repository, the Microsoft Store, or using package managers like Winget.

Windows Server editions follow a similar pattern, with Windows Server 2016 including PowerShell 5.1, and Windows Server 2019 and 2022 also shipping with PowerShell 5.1 as the default Windows PowerShell installation. PowerShell 5.1 represents the final major release of Windows PowerShell, as Microsoft’s development focus has shifted entirely to the cross-platform PowerShell 7 line.

Method 1: Using the $PSVersionTable Command (Most Reliable)

The $PSVersionTable command represents the most reliable and comprehensive method for checking your PowerShell version. This automatic variable is a read-only hash table that contains detailed information about your PowerShell environment, including version numbers, edition type, platform details, and compatibility information. When you run this command, PowerShell returns a complete table of key-value pairs that provide everything you need to know about your installation.

To use this method, first open PowerShell by pressing the Windows key and typing “PowerShell” in the search bar, then clicking on “Windows PowerShell” in the search results. Alternatively, you can press Windows key + R to open the Run dialog, type “powershell” and press Enter. Once the PowerShell window opens, displaying its characteristic blue background with white text, you’re ready to execute the command.

Type the following command exactly as shown and press Enter:

$PSVersionTable

The output will display several lines of information organized in a table format. The most important entry is labeled “PSVersion” which shows your PowerShell version number. For example, if you see “5.1.19041.1023” next to PSVersion, you’re running Windows PowerShell 5.1 with specific build and revision numbers. If you see “7.4.0” or similar, you’re running PowerShell 7.

Understanding the $PSVersionTable Output

The $PSVersionTable output contains several valuable properties beyond just the version number. The PSEdition property indicates whether you’re running Desktop edition (Windows PowerShell) or Core edition (PowerShell 6+). This distinction is critical for understanding module compatibility and available features. The CLRVersion property (present in Windows PowerShell) shows the Common Language Runtime version of the .NET Framework being used, while PowerShell Core shows .NET Core or .NET 5+ information.

Additional properties include PSCompatibleVersions, which lists all PowerShell versions your current installation can support, ensuring backward compatibility for scripts written for older versions. The GitCommitId property (available in PowerShell 6 and later) shows the specific Git commit from which your installation was built, useful for developers tracking exact source code versions. The OS and Platform properties display your operating system details, particularly relevant for cross-platform PowerShell Core installations.

If you only want to see the version number without all the additional information, you can use a more specific command:

$PSVersionTable.PSVersion

This command returns just the version object, displaying Major, Minor, Build, and Revision numbers in a cleaner format. This approach is particularly useful when you’re writing scripts that need to check the PowerShell version programmatically and make decisions based on version compatibility.

Method 2: Using the Get-Host Command

The Get-Host cmdlet provides another straightforward method for checking your PowerShell version, though it technically returns information about the host program running PowerShell rather than the PowerShell engine itself. Despite this distinction, Get-Host remains a popular choice because it’s easy to remember and provides quick access to version information along with other host details.

To use this method, open PowerShell using any of the previously mentioned techniques, then type the following command and press Enter:

Get-Host

The output displays multiple properties including Name (showing which host program you’re using, such as “ConsoleHost” or “Windows PowerShell ISE Host”), Version (the host version number), InstanceId (a unique identifier for this PowerShell session), and CurrentCulture settings. The Version property shows the PowerShell version, though it’s important to note that this reflects the host version, which typically matches the PowerShell engine version but may differ in some scenarios.

Alternative Get-Host Syntax

You can also access just the version property directly using PowerShell’s dot notation:

$Host.Version

This command returns the version in a slightly different format, breaking out the Major, Minor, Build, and Revision numbers on separate lines or in a structured object format. This approach provides the same version information as Get-Host but in a more compact presentation that’s easier to parse programmatically.

It’s crucial to understand that when using Get-Host on a remote computer via PowerShell remoting, the command returns the version of the host environment on your local machine, not the remote system. If you need to check the PowerShell version on a remote computer, you must use different techniques specifically designed for remote version checking, which we’ll cover later in this guide.

Method 3: Checking PowerShell Version Through Windows Registry

The Windows Registry stores PowerShell version information in specific registry keys, providing an alternative method for version checking that doesn’t require running PowerShell itself. This approach proves particularly valuable when PowerShell won’t launch properly, when you’re automating version checks from other applications, or when you need to verify PowerShell versions before running any PowerShell commands.

There are two ways to access registry information for PowerShell versions: using a PowerShell command to query the registry, or manually navigating through the Registry Editor application. Both methods access the same underlying data but serve different use cases.

Using PowerShell to Query the Registry

To check the PowerShell version using a PowerShell command that queries the registry, open PowerShell and enter this command:

(Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine -Name 'PowerShellVersion').PowerShellVersion

This command uses the Get-ItemProperty cmdlet to retrieve the PowerShellVersion value from the registry key where PowerShell stores its engine information. The HKLM abbreviation stands for HKEY_LOCAL_MACHINE, one of the main registry hives. The path points to the PowerShell 3 folder (which also contains information for later versions of Windows PowerShell) and specifically targets the PowerShellEngine key.

Manual Registry Editor Method

For situations where you can’t use PowerShell commands, the Registry Editor provides direct access to version information. To open Registry Editor, press Windows key + R to open the Run dialog, type “regedit” and press Enter. You may see a User Account Control prompt asking for permission to make changes to your device. Click “Yes” to proceed, but exercise caution as incorrect registry modifications can cause system problems.

Once Registry Editor opens, navigate through the folder structure in the left panel. Start by expanding “HKEY_LOCAL_MACHINE” (often abbreviated as HKLM), then locate and expand the “SOFTWARE” folder. Scroll down through the alphabetically organized list until you find “Microsoft” and expand it. Look for “PowerShell” in the list and expand it to reveal numbered folders.

You’ll typically see folders labeled “1” and “3” under the PowerShell key. Click on the “3” folder to expand it, then click on “PowerShellEngine” inside. The right panel of Registry Editor will display several values, including “PowerShellVersion” which shows your installed Windows PowerShell version number. This registry location specifically stores information about Windows PowerShell (version 5.1 and earlier). PowerShell 7 installations store their information in different registry locations under a separate PowerShell Core key.

Method 4: Checking PowerShell Version on Remote Computers

System administrators frequently need to check PowerShell versions across multiple remote computers to ensure consistency, plan upgrades, or troubleshoot compatibility issues. PowerShell provides robust remoting capabilities that make remote version checking straightforward, though certain prerequisites must be met before remote commands will work.

Prerequisites for Remote PowerShell Version Checking

Before you can check PowerShell versions on remote computers, several requirements must be satisfied. Windows Management Framework (WMF) must be installed and enabled on both the local and remote machines, as it provides the underlying infrastructure for PowerShell remoting. Windows Remote Management (WinRM) service must be configured and running on both systems, facilitating the secure communication channel PowerShell uses for remote operations.

To configure WinRM on a machine that hasn’t been set up for remoting, open PowerShell as Administrator on that computer and run the following command:

winrm quickconfig

This command performs all necessary configuration steps automatically, including starting the WinRM service, setting it to start automatically, creating firewall exceptions, and configuring default settings. You’ll also need appropriate credentials with administrative privileges on the remote computer to execute commands remotely.

Using Invoke-Command for Remote Version Checking

The Invoke-Command cmdlet executes PowerShell commands on remote computers and returns the results to your local session. To check the PowerShell version on a remote computer, use this syntax:

Invoke-Command -ComputerName RemotePC01 -ScriptBlock { $PSVersionTable.PSVersion } -Credential $cred

In this command, replace “RemotePC01” with the actual name or IP address of the remote computer you want to check. The ScriptBlock parameter contains the command that will execute on the remote system, in this case, $PSVersionTable.PSVersion to retrieve version information. The Credential parameter requires a credential object containing valid username and password for the remote system.

To create the credential object before running Invoke-Command, use this command:

$cred = Get-Credential

PowerShell will prompt you to enter the username and password for the remote system, storing them securely in the $cred variable. You can then use this variable in your Invoke-Command statements.

Checking Multiple Remote Computers Simultaneously

One of PowerShell’s most powerful features is its ability to execute commands on multiple remote computers in a single operation. To check PowerShell versions across several machines at once, separate the computer names with commas:

Invoke-Command -ComputerName RemotePC01, RemotePC02, RemotePC03 -ScriptBlock { $PSVersionTable.PSVersion } -Credential $cred

This command connects to all three computers and retrieves their PowerShell versions simultaneously, returning results that include the computer name along with the version information. This approach dramatically reduces the time required to audit PowerShell versions across large networks, making it invaluable for enterprise environments with hundreds or thousands of systems to manage.

Method 5: Using PowerShell Command Line Parameter (pwsh –version)

PowerShell Core (PowerShell 6 and later) introduced a convenient command-line parameter that displays the version number immediately upon launching, without requiring you to enter a PowerShell session first. This method works particularly well for quick version checks and is especially useful on Linux and macOS systems where PowerShell Core runs in terminal environments.

To use this method, open your command-line interface (Command Prompt, Windows Terminal, or any terminal application on Linux/macOS) and type:

pwsh --version

The command immediately returns the PowerShell version in a simple format, such as “PowerShell 7.4.0” without launching a full PowerShell session. This makes it ideal for automated scripts, deployment verification, or quick checks when you don’t need to interact with PowerShell itself.

Note that this command specifically works with PowerShell Core (pwsh) and not Windows PowerShell (powershell). If you try to use “powershell –version” with Windows PowerShell 5.1, the command won’t work as expected because Windows PowerShell doesn’t support the –version parameter. This is one of many distinctions between the traditional Windows PowerShell and the modern PowerShell Core editions.

Method 6: Checking Through File Properties (Windows Explorer)

While less commonly used, you can also determine your PowerShell version by examining the properties of the PowerShell executable file itself. This method provides version information without executing PowerShell, making it useful for security audits or when PowerShell execution is restricted.

To check the PowerShell version through file properties, navigate to the PowerShell installation directory. For Windows PowerShell 5.1, the executable is typically located at:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

For PowerShell 7, the default installation path is:

C:\Program Files\PowerShell\7\pwsh.exe

Once you locate the appropriate executable file, right-click on it and select “Properties” from the context menu. Click on the “Details” tab in the Properties window. Look for the “File version” or “Product version” entries, which display the version number of the PowerShell installation. This information matches what you would see using the $PSVersionTable command, but obtained through the Windows file system rather than PowerShell itself.

Method 7: Using System Information Commands

Windows provides several system information commands that can reveal PowerShell version details as part of broader system configuration data. These commands prove useful when gathering comprehensive system information that includes PowerShell versions along with other relevant details.

Using Windows Management Instrumentation (WMI)

WMI provides extensive access to system information, though it doesn’t have a direct PowerShell version query. However, you can use WMI to determine the Windows version, which correlates to specific pre-installed PowerShell versions:

Get-WmiObject Win32_OperatingSystem | Select-Object Caption, Version

This command returns the Windows operating system version, which you can cross-reference with the table of pre-installed PowerShell versions by Windows OS that we covered earlier. While this doesn’t give you the exact PowerShell version directly, it provides strong context for what PowerShell version should be present by default.

Using systeminfo Command

The systeminfo command, available in Command Prompt, displays detailed configuration information about your computer and its operating system. While it doesn’t show PowerShell version directly, it provides operating system build numbers that correspond to specific PowerShell versions:

systeminfo | findstr /B /C:"OS Version"

This command filters the systeminfo output to show only the OS version line. Combined with knowledge of which PowerShell versions ship with specific Windows builds, you can determine the expected PowerShell version, though actual installed versions may differ if updates or manual installations have occurred.

Understanding Differences Between Windows PowerShell and PowerShell Core

The distinction between Windows PowerShell and PowerShell Core (now simply PowerShell 7) represents one of the most important concepts for users to understand when working with PowerShell environments. These two editions differ fundamentally in their architecture, capabilities, and intended use cases, and understanding these differences helps explain why version checking is so critical.

Windows PowerShell, with version 5.1 being the final major release, is built on the .NET Framework and remains tightly integrated with the Windows operating system. It ships pre-installed on all modern Windows versions and provides access to Windows-specific features, cmdlets, and modules. Microsoft has officially ended development of Windows PowerShell, with the company now focusing exclusively on security updates and bug fixes. No new features will be added to Windows PowerShell, making it a stable but ultimately legacy platform.

PowerShell Core began as a cross-platform reimagining of PowerShell, starting with version 6.0 released in 2018. Built on .NET Core (and later .NET 5 and .NET 6+), PowerShell Core runs on Windows, macOS, and Linux, enabling truly portable automation scripts and tools. PowerShell 7 unified the best features of Windows PowerShell and PowerShell Core, offering improved performance, modern language features, and active ongoing development. New capabilities like parallel processing with ForEach-Object -Parallel, ternary operators, null-coalescing operators, and pipeline chain operators exist only in PowerShell 7.

Compatibility between these editions presents one of the biggest challenges for users and organizations. Many modules and scripts written for Windows PowerShell work perfectly in PowerShell 7, but not all do. Windows-specific modules that depend on .NET Framework APIs may not function in PowerShell 7’s .NET Core environment without modifications. Conversely, scripts using PowerShell 7-specific features will fail in Windows PowerShell 5.1. This is why checking your PowerShell version before running scripts is crucial.

Running Multiple PowerShell Versions Side by Side

One of PowerShell’s most convenient features is the ability to run multiple versions simultaneously on the same computer. Windows PowerShell 5.1 and PowerShell 7 can coexist without conflicts, allowing you to maintain legacy script compatibility while also leveraging modern PowerShell features. This side-by-side installation capability makes transitioning from Windows PowerShell to PowerShell 7 much smoother for organizations.

When you install PowerShell 7 on a Windows system, it installs to a completely separate directory from Windows PowerShell. Windows PowerShell remains in its traditional location under C:\Windows\System32\WindowsPowerShell, while PowerShell 7 typically installs to C:\Program Files\PowerShell\7. Each version has its own executable file: powershell.exe for Windows PowerShell and pwsh.exe for PowerShell 7.

To determine which installation directory your current PowerShell session is running from, use the automatic variable $PSHOME:

$PSHOME

This command returns the full path to the directory containing the PowerShell installation currently executing your commands. If the path includes “WindowsPowerShell,” you’re running Windows PowerShell. If it shows “PowerShell\7” or similar, you’re running PowerShell 7.

When both versions are installed, you can explicitly launch either version by using its specific executable name. From Command Prompt or Run dialog, type “powershell” to launch Windows PowerShell, or “pwsh” to launch PowerShell 7. In Windows Terminal, each version appears as a separate profile option, allowing quick switching between editions from the dropdown menu.

How to Update or Install PowerShell

After checking your PowerShell version, you might discover you’re running an outdated version that lacks important features or security updates. Updating PowerShell or installing newer versions involves different processes depending on whether you’re updating Windows PowerShell or installing PowerShell 7.

Updating Windows PowerShell

Windows PowerShell 5.1 receives updates through Windows Update as part of the Windows Management Framework. These updates primarily include security patches and bug fixes rather than new features, since Microsoft has ended feature development for Windows PowerShell. To ensure you have the latest Windows PowerShell updates, simply keep your Windows system updated through Windows Update in Settings.

You cannot manually upgrade Windows PowerShell to a newer major version than what your Windows OS supports. For example, if you’re running Windows 10, Windows PowerShell 5.1 is the maximum version available. To use PowerShell features beyond version 5.1, you must install PowerShell 7, which runs alongside Windows PowerShell rather than replacing it.

Installing PowerShell 7 via Microsoft Store

The easiest method for installing PowerShell 7 on Windows is through the Microsoft Store. Open the Microsoft Store application, search for “PowerShell,” and look for the official Microsoft PowerShell listing. Click the “Get” or “Install” button to begin installation. The Microsoft Store version includes automatic updates, ensuring you always have the latest PowerShell 7 release without manual intervention.

Installing PowerShell 7 via Winget

Winget, Microsoft’s official command-line package manager, provides the fastest installation method for PowerShell 7. Winget comes pre-installed on Windows 11 and recent Windows 10 versions. To install PowerShell 7 using Winget, open PowerShell or Command Prompt and run:

winget install --id Microsoft.Powershell --source winget

This command downloads and installs the latest stable release of PowerShell 7 automatically. To update an existing PowerShell 7 installation via Winget, use:

winget upgrade --id Microsoft.Powershell

Installing PowerShell 7 via MSI Package

For enterprise deployments or manual installations, Microsoft provides MSI installer packages on the PowerShell GitHub releases page. Download the appropriate MSI file for your system architecture (x64, x86, or ARM64), then run the installer. The MSI package offers customization options including installation directory, whether to add PowerShell to the PATH environment variable, and whether to register PowerShell as the default handler for .ps1 files.

The MSI installation method works particularly well for automated deployments across multiple computers using enterprise software deployment tools. System administrators can script MSI installations with specific parameters to ensure consistent configuration across all systems.

PowerShell Version History and Evolution

Understanding PowerShell’s version history provides valuable context for why certain features exist in specific versions and helps you make informed decisions about which version to use for different scenarios. PowerShell’s journey from a Windows-only automation tool to a cross-platform development platform spans nearly two decades of continuous improvement and innovation.

PowerShell 1.0, released in November 2006, introduced the foundational concepts of cmdlets, objects in the pipeline, and the .NET integration that differentiated PowerShell from traditional scripting shells. It was initially available for Windows XP SP2, Windows Server 2003 SP1, and Windows Vista. PowerShell 2.0, arriving in October 2009 with Windows 7 and Windows Server 2008 R2, added remoting capabilities, background jobs, advanced functions, and debugger support, transforming PowerShell from a simple scripting tool into a comprehensive automation platform.

PowerShell 3.0 shipped with Windows 8 and Windows Server 2012 in September 2012, bringing workflow support, improved session connectivity, and scheduled jobs. PowerShell 4.0, released with Windows 8.1 and Windows Server 2012 R2 in October 2013, introduced Desired State Configuration (DSC), a revolutionary approach to infrastructure as code, along with enhanced debugging and network diagnostics capabilities.

PowerShell 5.0, launching in February 2016, added package management through PackageManagement (formerly OneGet), PowerShellGet for module discovery and installation, class definitions, and improved debugging features. PowerShell 5.1, released in January 2017 with Windows 10 Anniversary Update and Windows Server 2016, became the final major release of Windows PowerShell, adding catalog cmdlets and performance improvements.

PowerShell Core 6.0 marked a pivotal shift in January 2018, representing the first cross-platform version built on .NET Core. This version ran on Windows, macOS, and Linux, though it initially lacked some Windows-specific features from PowerShell 5.1. PowerShell Core 6.1 and 6.2 improved compatibility and added features gradually.

PowerShell 7.0, released in March 2020, unified the Windows PowerShell and PowerShell Core branches, bringing most Windows PowerShell features back while maintaining cross-platform capability. It introduced ForEach-Object -Parallel for parallel processing, ternary operators, null-coalescing operators, and pipeline chain operators. PowerShell 7.1, arriving in November 2020, became the first Long Term Support (LTS) release, guaranteeing three years of support.

PowerShell 7.2, released in November 2021, included native support for Apple Silicon (M1) processors, predictive IntelliSense, and PSReadLine improvements. It became the second LTS release. PowerShell 7.3, launching in November 2022, added further performance optimizations and quality-of-life improvements. PowerShell 7.4, released in November 2023, continues the evolution with enhanced scripting capabilities and improved error handling.

Pro Tips for PowerShell Version Management

Managing PowerShell versions effectively requires understanding not just how to check versions, but also how to leverage this information for optimal system administration and development workflows. These professional tips help you work more efficiently with PowerShell across different versions and scenarios.

Always verify PowerShell version before running scripts in production environments. Include version checking at the beginning of critical scripts using simple conditional logic. For example, use if ($PSVersionTable.PSVersion.Major -lt 7) { Write-Error “This script requires PowerShell 7 or later” } to ensure scripts only run on compatible versions. This prevents unexpected failures and makes troubleshooting much easier.
Document PowerShell version requirements in script headers and README files. When sharing scripts or modules with team members or the broader community, clearly specify which PowerShell versions you’ve tested with and what the minimum required version is. This saves others countless hours of troubleshooting compatibility issues.
Use the PSEdition property to write version-agnostic scripts. Instead of checking for specific version numbers, check whether you’re running on Desktop or Core edition using $PSVersionTable.PSEdition. This approach makes your scripts more resilient to future version changes while still handling the fundamental differences between Windows PowerShell and PowerShell Core.
Leverage the $PSVersionTable.PSCompatibleVersions property for backward compatibility testing. This property lists all PowerShell versions your current installation claims compatibility with. When developing modules or scripts, test against these compatible versions to ensure broad usability across different environments.
Create PowerShell profile scripts that display version information at startup. Add Write-Host “PowerShell $($PSVersionTable.PSVersion) – Edition: $($PSVersionTable.PSEdition)” -ForegroundColor Cyan to your PowerShell profile. This provides an immediate visual reminder of which version you’re working in, particularly helpful when you frequently switch between versions.
Use version-specific module paths when installing modules for different PowerShell editions. PowerShell maintains separate module directories for Windows PowerShell and PowerShell Core. Understanding these paths helps you troubleshoot module availability issues and manage installations across multiple versions.
Maintain both Windows PowerShell 5.1 and PowerShell 7 installations on development machines. This allows you to test scripts for compatibility with both editions, ensuring your work functions across diverse environments. Many organizations still rely heavily on Windows PowerShell, making this dual-version approach essential for professional development.
Use the $PSHOME variable to identify the installation directory quickly. This automatic variable always points to the directory containing the currently running PowerShell installation, making it invaluable for troubleshooting path issues and determining which version you’re actually running when multiple versions are installed.

Frequently Asked Questions

What is the difference between $PSVersionTable.PSVersion and Get-Host version?

The $PSVersionTable.PSVersion command returns the version of the PowerShell engine itself, providing the most accurate and reliable version information. This represents the actual PowerShell runtime version and is universally consistent across all PowerShell hosts. The Get-Host command, on the other hand, returns information about the host application running PowerShell, which may be Windows PowerShell Console, PowerShell ISE, Visual Studio Code’s integrated terminal, or other applications that host PowerShell.

The host version typically matches the PowerShell version but can differ in some scenarios, particularly with third-party hosting applications. For script compatibility checking and accurate version determination, always use $PSVersionTable.PSVersion rather than Get-Host.

Can I upgrade Windows PowerShell 5.1 to PowerShell 7 as a replacement?

No, PowerShell 7 doesn’t upgrade or replace Windows PowerShell 5.1. Instead, PowerShell 7 installs alongside Windows PowerShell as a completely separate application in a different directory. Windows PowerShell 5.1 remains installed and available on your system after installing PowerShell 7, allowing you to use either version depending on your needs.

This side-by-side installation approach ensures backward compatibility with scripts and modules that specifically require Windows PowerShell while giving you access to modern PowerShell 7 features. To launch Windows PowerShell, use the “powershell” command, and to launch PowerShell 7, use the “pwsh” command. Both can be running simultaneously without conflicts.

Will scripts written for PowerShell 5.1 work in PowerShell 7?

Most scripts written for PowerShell 5.1 will work in PowerShell 7 without modifications, as Microsoft designed PowerShell 7 with backward compatibility in mind. However, compatibility isn’t guaranteed for all scripts, particularly those using Windows-specific features or modules that depend on the full .NET Framework.

Some Windows PowerShell modules aren’t available in PowerShell 7 by default, though PowerShell 7 includes a compatibility layer that can load many Windows PowerShell modules using implicit remoting. Scripts that use deprecated cmdlets, rely on PSSnapins (replaced by modules), or depend on Windows-only GUI elements may require modifications. The best practice is to test all production scripts in PowerShell 7 before migrating to ensure they function as expected. PowerShell 7’s -UseWindowsPowerShell switch for Import-Module can help bridge compatibility gaps for problematic modules.

How do I know if I should use Windows PowerShell or PowerShell 7?

Choose Windows PowerShell 5.1 when you need to use Windows-specific features or modules that haven’t been ported to PowerShell 7, when you’re maintaining legacy scripts that you know work with Windows PowerShell, or when organizational policies require using only the built-in Windows components. Choose PowerShell 7 when you need cross-platform compatibility, want access to modern language features like parallel processing and ternary operators, require better performance for large-scale operations, or are starting new automation projects. For most users beginning new projects, PowerShell 7 represents the better choice as it’s actively developed with new features, security updates, and performance improvements. Many organizations maintain both versions during a transition period, using Windows PowerShell for legacy systems while gradually migrating to PowerShell 7 for new development.

Why does my PowerShell version check show different results on different commands?

If you’re seeing different version numbers from different commands, you’re likely running different PowerShell editions or instances without realizing it. Windows systems with both Windows PowerShell and PowerShell 7 installed have multiple PowerShell executables. If you run a version check in a Windows PowerShell window, you’ll see version 5.1, while the same check in a PowerShell 7 window will show version 7.x. This commonly happens when users don’t realize they’ve opened a different PowerShell version. Check the window title bar, which usually indicates which version you’re running. You can also verify by looking at $PSHOME, which shows the installation directory. Additionally, some version checking methods like Get-Host can show host-specific version information that differs slightly from the engine version. Always use $PSVersionTable.PSVersion for the most accurate engine version.

How often should I update my PowerShell version?

For Windows PowerShell 5.1, updates arrive automatically through Windows Update, and you should keep your system updated with the latest security patches Microsoft releases. These updates focus on security and stability rather than new features. For PowerShell 7, update frequency depends on your installation method. Microsoft Store installations update automatically, while manual installations require you to download and install new versions. Microsoft typically releases new PowerShell 7 versions every few months, with major versions annually and minor versions or patches more frequently. For production environments, many organizations adopt Long Term Support (LTS) releases like PowerShell 7.2, which receive support for three years, providing stability while still getting security updates. Development machines might update more frequently to test new features. Security-critical updates should be applied promptly regardless of your update schedule, while feature updates can follow your organization’s change management procedures.

Can I check PowerShell version on a computer without administrator rights?

Yes, checking your PowerShell version doesn’t require administrator privileges. All the standard version checking commands like $PSVersionTable, Get-Host, and registry queries work perfectly with regular user permissions. You can open PowerShell as a standard user and run any of the version checking methods described in this guide. The only scenario where you might need elevated privileges is when attempting to check PowerShell versions on remote computers, as PowerShell remoting typically requires administrative credentials on the target systems. For local version checking on your own account, standard user permissions are sufficient. This makes version checking accessible to all users regardless of their privilege level on the system.

Conclusion

Checking your PowerShell version is a fundamental skill that every PowerShell user should master, whether you’re a system administrator managing enterprise infrastructure, a developer creating automation scripts, or a power user optimizing your Windows environment. The methods we’ve covered in this comprehensive guide provide multiple approaches to version identification, each suited to different scenarios and requirements. The $PSVersionTable command remains the most reliable and informative method for most users, offering detailed version information along with edition details, compatibility data, and platform information in a single, easy-to-use command.

Understanding the distinction between Windows PowerShell and PowerShell Core editions is equally important, as this knowledge helps you make informed decisions about which version to use for specific tasks and how to handle compatibility challenges. With Windows PowerShell 5.1 representing the end of the legacy line and PowerShell 7 continuing active development with new features and improvements, the PowerShell ecosystem is clearly moving toward the cross-platform future while maintaining support for existing Windows-based infrastructure.

By regularly checking your PowerShell version, keeping installations updated, and understanding version-specific features and limitations, you ensure your PowerShell workflows remain secure, compatible, and efficient. Whether you’re running simple administrative tasks or complex automation workflows, knowing your PowerShell version empowers you to leverage the right tools for the job and troubleshoot issues more effectively when they arise.

How to Check Your PowerShell Version in Windows 10/11: 7 Proven Methods with Step-by-Step Commands