[System.Environment]::OSVersion.VersionString # Should show Windows 10/11/2022 $PSVersionTable.PSVersion # MUST be 7.x (e.g., 7.4.5) [System.Environment]::Is64BitProcess # Should be True Get-Command -CommandType Cmdlet | Measure-Object | Select-Object -ExpandProperty Count # Expected: > 1500 cmdlets (vs ~400 in PowerShell 5.1) PowerShell 7 does not look at %Windir%\System32\WindowsPowerShell\v1.0\Modules by default (where most 5.1 modules live). To fix this, add the legacy path to your PSModulePath environment variable:
The modern standard is (often called "PowerShell Core"). It is open-source, cross-platform (Windows, Linux, macOS), and significantly faster. If your automation scripts still begin with #requires -Version 5.1 , you are working with the past. upgrading powershell
[Environment]::SetEnvironmentVariable("PSModulePath", $env:PSModulePath + ";C:\Windows\System32\WindowsPowerShell\v1.0\Modules", "Machine") You must restart pwsh for this to take effect. If you are still using powershell.exe for anything other than maintaining legacy Exchange or AD scripts, you are losing performance (PowerShell 7 is up to 3x faster for loops and object pipelines) and security (PowerShell 7 supports the modern LogPipelineExecutionDetails and ConstrainedLanguageMode better). [System
Install pwsh , alias it to ps7 in your profile, and never look back. The blue console belongs in a museum, not your production automation. If your automation scripts still begin with #requires
For over a decade, the blue-backed Windows PowerShell console (versions 1.0 through 5.1) was the backbone of Windows automation. It was powerful, but it was also limited, slow, and proprietary . Today, sticking with Windows PowerShell 5.1 is a technical debt you cannot afford.
# Do NOT do this on a domain controller or Exchange server. # Instead, change your task scheduler actions to "pwsh.exe" Run this diagnostic block in your new pwsh session: