Windows PowerShell 5.1 versus PowerShell 7 on servers: which one a script actually runs under

What it is

Windows Server ships Windows PowerShell 5.1 (powershell.exe) as part of the OS; PowerShell 7.x (pwsh.exe) is a separate, MIT-licensed, cross-platform install that Microsoft's migration guide describes as running side by side with 5.1 rather than replacing it, with its own installation path, $PSModulePath, per-version profiles and event logs. Calling one from a script and expecting the other's behaviour is a common source of "it works interactively but not in the scheduled task" reports.

Why it matters

The two engines differ in more than version number:

• Executable and PATH: powershell.exe (in System32\WindowsPowerShell\v1.0) is always 5.1 on a stock server; pwsh.exe is only present if 7.x was installed separately. The MSI adds $Env:ProgramFiles\PowerShell\7 to PATH, but processes started before the install (long-running services) do not see the new PATH, and ZIP or Store installs may not be on the machine PATH at all.
• Module compatibility: most modules, including current Active Directory, work in 7.x, but some Windows PowerShell-only modules do not load natively. Import-Module -UseWindowsPowerShell addresses this by, in Microsoft's own words, "loading module using Windows PowerShell Compatibility functionality" — it runs the module inside a hidden 5.1 process and proxies commands, returning deserialized objects; this is slower and does not support every feature. PowerShell 7 applies this fallback implicitly only to modules in the 5.1 system module folder that are not marked Core-compatible (and not on its deny list).
• Remoting endpoints: over WinRM, Enter-PSSession/Invoke-Command without an explicit -ConfigurationName land on the Windows PowerShell 5.1 endpoint named Microsoft.PowerShell, even when the client runs pwsh; PowerShell 7 gets its own endpoints (PowerShell.7, PowerShell.7.x.y) only after running Enable-PSRemoting elevated under 7.x, which the migration guide lists among the "new remoting endpoints".
• Scheduled tasks: the ScheduledTasks module's -Execute action is a plain path to an executable; a task built with -Execute 'powershell.exe' always runs under 5.1 regardless of which shell created the task.

How to apply

• Have the script report $PSVersionTable.PSVersion and $PSVersionTable.PSEdition at the start of a run so logs show which engine actually executed it.
• In automation (scheduled tasks, CI runners, remoting scripts), hard-code the intended executable's full path rather than relying on PATH order.
• When a module only works under 5.1, use -UseWindowsPowerShell explicitly rather than relying on the implicit fallback, which does not cover modules outside the system module folder.
• For remoting, pass -ConfigurationName PowerShell.7 (or whatever name Enable-PSRemoting under pwsh registered) if the target must be PowerShell 7, and verify with Get-PSSessionConfiguration on the target.

Pitfalls

• Assuming installing PowerShell 7 upgrades or removes Windows PowerShell 5.1; both remain and powershell.exe keeps working unchanged.
• Testing a script interactively in a pwsh window and deploying it into a scheduled task that still calls powershell.exe.
• Forgetting that -UseWindowsPowerShell starts an additional background process per session, which changes performance and error surfaces compared with a native 7.x module.