How to manage PowerShell versions

Do you know which version of PowerShell is running when you open a terminal window - and does it matter?

It matters more than most people think. Windows ships with PowerShell 5.1 preinstalled, and that is the version that runs by default when you open Windows Terminal, launch a script through Microsoft Intune, or execute a scheduled task. PowerShell 7 is a separate installation that runs side-by-side. It does not replace PowerShell 5.1, and it does not automatically become your default shell.

This distinction is critical when you write scripts for endpoint management. A script that runs perfectly in PowerShell 7 on your development machine can fail silently on a managed device where only PowerShell 5.1 is available - or during a Windows Autopilot provisioning flow, where PowerShell 7 is not yet installed on the device. Based on my experience with multiple deployments, this version mismatch is one of the most common sources of scripting issues in Microsoft Intune environments. I will walk through how to install PowerShell 7, configure Windows Terminal and Visual Studio Code to use both versions, and share practical guidance on when to use which version.

PowerShell 5.1 vs. PowerShell 7

PowerShell 5.1 and PowerShell 7 are not just different version numbers - they are built on fundamentally different foundations. Understanding this distinction is essential before deciding which version to use for a given task.

PowerShell 5.1, referred to as Windows PowerShell, is built on the .NET Framework and ships with every supported version of Windows. It is the version that runs when you type powershell.exe in a command prompt or when Microsoft Intune executes a PowerShell script on a managed device. Microsoft has moved Windows PowerShell into maintenance mode - it still receives security fixes, but no new features are being added.

PowerShell 7, simply referred to as PowerShell, is built on modern .NET and runs cross-platform. It brings significant improvements: better performance, improved error handling, ternary operators, pipeline parallelism with ForEach-Object -Parallel, null-coalescing operators, and native SSH remoting. It installs side-by-side with Windows PowerShell and uses a completely separate executable (pwsh.exe), separate module paths, and a separate configuration profile.

However, side-by-side also means that having PowerShell 7 installed does not change what happens when a system or service invokes powershell.exe. That executable still points to PowerShell 5.1 - always.

When to use PowerShell 5.1

PowerShell 5.1 remains the right choice in several important scenarios. The most significant one for endpoint management is that Microsoft Intune executes PowerShell scripts using powershell.exe, which means PowerShell 5.1. If you are writing scripts that will be deployed through Microsoft Intune, you should develop and test against PowerShell 5.1 to ensure compatibility.

Other scenarios where PowerShell 5.1 is the appropriate choice:

• Modules that depend on the .NET Framework - Some older modules and snap-ins are not compatible with PowerShell 7
• Group Policy logon/startup scripts - These execute through powershell.exe by default
• Environments where PowerShell 7 is not installed - On devices you do not control, PowerShell 5.1 is the only version you can count on being present

When to use PowerShell 7

PowerShell 7 is the better choice when you control the execution environment and want to take advantage of modern language features. Scenarios where PowerShell 7 shines:

• Cross-platform scripting - When your scripts need to run on Windows, Linux, and macOS
• Performance-sensitive automation - ForEach-Object -Parallel can significantly speed up bulk operations
• Modern language features - Ternary operators ($condition ? $true : $false), null-coalescing ($value ?? 'default'), and pipeline chain operators (&&, ||)
• Azure automation and DevOps pipelines - Many CI/CD environments default to PowerShell 7
• Local development and tooling - When building tools for your own use where you control the runtime
• Microsoft Graph and REST API work - PowerShell 7 handles JSON and REST operations more cleanly

The key question to ask yourself is: will this script run on a device where I cannot guarantee PowerShell 7 is installed? If the answer is yes, stick with PowerShell 5.1. If you control the environment, PowerShell 7 is almost always the better experience.

Installing PowerShell 7

Installing PowerShell 7 is straightforward using Windows Package Manager. Starting with PowerShell 7.6.0, winget installs the MSIX package by default. Open Windows Terminal and run:

# Description: Installs PowerShell 7 using Windows Package Manager (MSIX)
# Elevation is not required - winget handles elevation prompts automatically

winget install --id Microsoft.PowerShell --source winget --accept-source-agreements --accept-package-agreements

Install PowerShell 7 using winget (MSIX package)

If you prefer the MSI package - which is the better choice for enterprise deployment, Windows Server, or when you need full control over installation options - use the --installer-type wix flag:

# Description: Installs PowerShell 7 MSI package using Windows Package Manager
# Elevation is not required - winget handles elevation prompts automatically

winget install --id Microsoft.PowerShell --source winget --installer-type wix --accept-source-agreements --accept-package-agreements

Install PowerShell 7 using winget (MSI package)

PowerShell 7 is also available as a Microsoft Store app , which means users can install it themselves or you can deploy it through Microsoft Intune as a Store app. In my experience, there is very little practical difference between the Store app and the winget-installed MSIX package for day-to-day scripting and development work. That said, the MSIX/Store installation does come with some limitations. It runs in a sandboxed context, which means PowerShell remoting over WSMan is not supported and system-level configuration changes under $PSHOME are blocked. Whether those limitations matter depends on your workflow, so it is worth testing in your own environment before committing to one approach.

After installation completes, verify the installation by launching the new shell:

# Description: Launches PowerShell 7 and displays version information
# Elevation is not required - version query does not require elevated privileges

pwsh -Command '$PSVersionTable'

Verify the PowerShell 7 installation

You should see output similar to this:

Name                           Value
----                           -----
PSVersion                      7.6.2
PSEdition                      Core
GitCommitId                    7.6.2
OS                             Microsoft Windows 10.0.26100
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Expected output from $PSVersionTable in PowerShell 7

If you run the same command in Windows PowerShell (powershell.exe), you will see PSVersion 5.1.x and PSEdition Desktop instead - that is how you confirm which version you are running at any given time.

Executable paths

PowerShell 5.1 ships in both 64-bit and 32-bit variants, while PowerShell 7 is available in 64-bit (x64) and ARM64 only - there is no 32-bit (x86) build of PowerShell 7. The executables are installed in different paths:

In most cases, the 64-bit version is what you want - it is what Windows Terminal, Visual Studio Code, and Microsoft Intune use by default. The 32-bit variant of PowerShell 5.1 is only relevant if you need to interact with 32-bit COM objects, 32-bit ODBC drivers, or other components that require a 32-bit process.

Configuring Windows Terminal

Windows Terminal typically auto-detects PowerShell 7 after installation and adds it as an available profile. Open Windows Terminal, click the dropdown arrow next to the tab bar, and check whether PowerShell 7 appears in the list.

Renaming profiles for clarity

By default, Windows Terminal labels the profiles Windows PowerShell and PowerShell. That distinction is subtle enough to cause confusion, especially when you have both open in separate tabs. I have found that renaming them makes the version difference immediately obvious:

• Rename Windows PowerShell to PowerShell 5
• Rename PowerShell to PowerShell 7

You can do this through the Windows Terminal settings UI:

1. Open Windows Terminal and go to Settings
2. Under Profiles, select the profile you want to rename
3. Change the Name field
4. Repeat for the other profile
5. Save your changes

Alternatively, you can edit the settings.json file directly. Open it from Settings > Open JSON file and locate the profiles:

{
  "profiles": {
    "list": [
      {
        "name": "PowerShell 5",
        "commandline": "powershell.exe",
        "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}"
      },
      {
        "name": "PowerShell 7",
        "commandline": "C:\\Program Files\\PowerShell\\7\\pwsh.exe",
        "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}"
      }
    ]
  }
}

Windows Terminal settings.json - renamed profiles

With both profiles clearly labeled, you can always tell at a glance which version of PowerShell is running in each tab.

Setting a default profile

To control which shell opens when you launch Windows Terminal or press Ctrl+Shift+T for a new tab:

1. Open Windows Terminal Settings
2. Under Startup, find Default profile
3. Select your preferred profile
4. Save your changes

Alternatively, set the defaultProfile in settings.json:

"defaultProfile": "{574e775e-4f2a-5b96-ac1e-a2962a402336}"

Windows Terminal settings.json - default profile

Which version you set as default depends on your workflow. If you primarily write scripts for Microsoft Intune, keeping PowerShell 5 as the default ensures you are always testing in the same environment your scripts will run in. If most of your work targets PowerShell 7, set that as the default instead.

Manually adding a PowerShell 7 profile

In some cases - custom installations, enterprise images, or locked-down environments - Windows Terminal may not automatically detect PowerShell 7. You can add the profile manually by opening settings.json and adding an entry to the profiles.list array:

{
  "name": "PowerShell 7",
  "commandline": "C:\\Program Files\\PowerShell\\7\\pwsh.exe",
  "icon": "ms-appx:///ProfileIcons/pwsh.png",
  "startingDirectory": "%USERPROFILE%"
}

Manually adding a PowerShell 7 profile to Windows Terminal

Save the file and Windows Terminal will reload the configuration automatically.

Configuring Visual Studio Code

Visual Studio Code is where I do most of my scripting and development work, and controlling which PowerShell version runs in the integrated terminal matters just as much as it does in Windows Terminal. Visual Studio Code typically auto-detects both PowerShell versions after installation.

Setting the default terminal profile

Visual Studio Code defaults to PowerShell 7 when it is installed on the system. If you write scripts for Microsoft Intune, this is worth being aware of - you may be developing and testing in PowerShell 7 without realizing it, while your scripts will run in PowerShell 5.1 on managed devices.

To explicitly control which version opens by default, you can use the Command Palette:

1. Press Ctrl+Shift+P to open the Command Palette
2. Type Terminal: Select Default Profile
3. Select Windows PowerShell for PowerShell 5.1 or PowerShell for PowerShell 7

Alternatively, set it directly in your user or workspace settings (settings.json). To keep PowerShell 7 as the default:

"terminal.integrated.defaultProfile.windows": "PowerShell"

Visual Studio Code settings.json - default terminal profile

To switch the default to PowerShell 5.1:

"terminal.integrated.defaultProfile.windows": "Windows PowerShell"

Visual Studio Code settings.json - PowerShell 5.1 as default

Switching between versions in the terminal

You do not need to change your default to use both versions. Visual Studio Code lets you open multiple terminal instances with different profiles:

1. Click the dropdown arrow next to the + button in the terminal panel
2. Select either PowerShell (7) or Windows PowerShell (5.1)
3. Each terminal instance runs independently with its own version

This makes it easy to test a script in both versions without leaving Visual Studio Code.

The PowerShell extension

If you use the PowerShell extension for Visual Studio Code , it runs its own PowerShell session for IntelliSense, debugging, and script analysis. By default, it uses the newest PowerShell version it finds. You can control this by clicking the version indicator in the status bar and selecting a different PowerShell version, or by setting it explicitly in settings.json:

"powershell.powerShellDefaultVersion": "Windows PowerShell (x64)"

Visual Studio Code settings.json - PowerShell extension session version

Adding version checks to your scripts

When you write scripts that require PowerShell 7 as a minimum version, you can add a #Requires statement at the top of the script file. This is a built-in PowerShell mechanism that prevents the script from running in an incompatible version:

# Description: Ensures the script runs only in PowerShell 7.0 or later
# Elevation is not required - #Requires is evaluated before execution

#Requires -Version 7.6

Using #Requires to enforce a minimum PowerShell version

When a user tries to run this script in PowerShell 5.1, they will receive a clear error message stating that the script requires a newer version - the script will not execute at all. This is far better than having the script fail partway through due to unsupported syntax.

You can also check the version programmatically within your script if you need to branch logic rather than block execution entirely:

# Description: Checks the PowerShell version and adjusts behavior accordingly
# Elevation is not required - version check does not require elevated privileges

if ($PSVersionTable.PSVersion.Major -ge 7) {
    # PowerShell 7+ specific logic
    $results = 1..100 | ForEach-Object -Parallel {
        # Parallel processing - only available in PowerShell 7
        Get-Process -Id $_ -ErrorAction SilentlyContinue
    }
} else {
    # PowerShell 5.1 fallback
    $results = 1..100 | ForEach-Object {
        Get-Process -Id $_ -ErrorAction SilentlyContinue
    }
}

Runtime version check with conditional logic

For scripts deployed through Microsoft Intune, the opposite approach is more practical - verify that the script is compatible with PowerShell 5.1 and avoid PowerShell 7-specific features entirely:

# Description: Checks that the script is running in a compatible PowerShell version
# Elevation is not required - version check does not require elevated privileges

if ($PSVersionTable.PSEdition -ne 'Desktop') {
    Write-Warning "This script is designed for Windows PowerShell 5.1 (Desktop edition)."
    Write-Warning "Current edition: $($PSVersionTable.PSEdition)"
    exit 1
}

Validating PowerShell 5.1 compatibility for Intune scripts

Verifying which version is running

Regardless of how you configure your terminals, you can always check the active PowerShell version by running $PSVersionTable - as demonstrated earlier during installation. The two key fields to look at:

The PSEdition field is particularly useful in scripts - Desktop always means PowerShell 5.1, and Core always means PowerShell 6 or later.

Final thoughts

The distinction between PowerShell 5.1 and PowerShell 7 is not about one being better than the other - it is about using the right version for the right context. PowerShell 7 brings genuinely useful improvements for local development, cross-platform work, and performance-sensitive automation. However, PowerShell 5.1 remains the version that matters most when your scripts are executed by systems you do not control - Microsoft Intune, Group Policy, scheduled tasks on devices without PowerShell 7 installed.

If you have not started evaluating PowerShell 7 for your environment yet, now is the right time. The improvements to performance, syntax, and cross-platform support are real. The side-by-side installation model means there is no risk to existing scripts. When you do write scripts that require PowerShell 7, use #Requires -Version 7.0 so the failure is clear and immediate rather than subtle and delayed. That said, scenarios like Windows Autopilot provisioning and Microsoft Intune script execution still run through powershell.exe, which means PowerShell 5.1 is not going away anytime soon. The practical answer is not choosing one over the other - it is knowing how to use both deliberately and testing in the version that matches where your script will actually run.

–Jesper

Header image attribution: Image created with help from Microsoft Copilot