PowerShell 7: Automation Scripts, Modules, and Common Errors Fixed

You already ran $PSVersionTable.PSVersion, now let's understand what you're looking at. Microsoft currently maintains four actively documented versions of PowerShell: 7.6 (LTS), 7.5, 7.4 (LTS), and the older Windows PowerShell 5.1. Each has a separate cmdlet reference on Microsoft Learn, and cmdlet behavior genuinely differs between versions. One of the most common confusion points I see is someone reading documentation for 7.4 while running 7.5, and wondering why a parameter they're looking at doesn't match what their shell does.

To see the full version table including OS and .NET runtime info, run:

$PSVersionTable

This gives you:

• PSVersion, your PowerShell version
• PSEdition, should say Core for PowerShell 7, Desktop for 5.1
• OS, confirms the platform (Windows, Linux, macOS)
• Platform, Win32NT for Windows

If PSEdition shows Desktop, you're in Windows PowerShell 5.1, not PowerShell 7 Core. That alone explains most cross-version module errors.

For enterprise environments, I strongly recommend standardizing on PowerShell 7.4 LTS or 7.6 LTS. Non-LTS releases like 7.5 are great for testing new features, but they reach end-of-life when the next minor version ships, which can leave your automation on an unsupported runtime faster than you expect.

Once you've confirmed the version, make sure the documentation you're referencing on Microsoft Learn matches. Use the version selector in the Table of Contents on the Learn site to switch between 7.6, 7.5, 7.4, and 5.1. The conceptual articles (everything above the Reference node in the TOC) are version-neutral and apply broadly, but cmdlet reference articles are version-specific. Getting those mixed up wastes hours.

You should see: PSEdition showing Core and PSVersion showing 7.x when you've confirmed you're in the right shell.

If pwsh.exe doesn't exist on your machine, here's how to get it properly. Don't just download a random installer from a search result, use the official channel.

The cleanest way on Windows 10/11 is via winget:

winget install --id Microsoft.PowerShell --source winget

For a specific version (recommended for production stability), pin to an LTS release:

winget install --id Microsoft.PowerShell --version 7.4.7

After installation, do not close and reopen the same terminal window. The PATH update won't be picked up by existing sessions. Open a fresh terminal. Then verify:

pwsh --version

You should see something like PowerShell 7.4.7.

For updating an existing PowerShell 7 installation:

winget upgrade --id Microsoft.PowerShell

If you're on a domain-joined enterprise machine where winget is blocked by policy, download the MSI installer from the official Microsoft PowerShell GitHub releases page and deploy it via SCCM, Intune, or manual install. The MSI path for a machine-wide install puts pwsh.exe at C:\Program Files\PowerShell\7\pwsh.exe. That path is consistent across versions and safe to hardcode in scripts and Task Scheduler jobs.

One thing that trips people up: PowerShell 7 installs side-by-side with Windows PowerShell 5.1. It does not replace it. Both will exist on the machine. This is intentional, some Windows management features (like certain Exchange or Active Directory cmdlets) still require the 5.1 runtime and won't move to 7 anytime soon. You need both.

You should see: pwsh.exe resolving from the command line with a version 7.x output, and PowerShell 7 appearing as a separate entry in your Start menu.

This one is responsible for a surprising number of "why won't my script run" support tickets. The error you see looks like this:

File C:\Scripts\Deploy.ps1 cannot be loaded because running scripts is disabled on this system.
For more information, see about_Execution_Policies at https://go.microsoft.com/fwlink/?LinkID=135170.

Here's the thing: PowerShell 7 maintains its own execution policy, completely separate from Windows PowerShell 5.1. Even if you (or your IT department) already set the execution policy to RemoteSigned in 5.1, that setting does not carry over to PowerShell 7. They're different configuration stores.

To check your current execution policy in PowerShell 7:

Get-ExecutionPolicy -List

This shows you every scope, MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine. The effective policy is the most restrictive one that applies.

For most personal or dev machines, set it for the current user:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

RemoteSigned means locally created scripts run without signing, but scripts downloaded from the internet need a digital signature. That's a reasonable balance for most scenarios.

For enterprise machines managed via Group Policy, you may not be able to override the MachinePolicy or UserPolicy scopes, those are GPO-controlled and take precedence over everything. If that's the case, you'll need to work with your AD team to update the PowerShell execution policy GPO. The GPO setting lives at:

Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on Script Execution

Note that this GPO applies separately to Windows PowerShell and PowerShell 7 depending on how it's configured. For a one-off bypass when testing (not for production), you can launch a process-scoped override:

pwsh.exe -ExecutionPolicy Bypass -File "C:\Scripts\Deploy.ps1"

You should see: Your script running without the execution policy error. If you still get blocked, run Get-ExecutionPolicy -List again and look for a MachinePolicy or UserPolicy entry that's set to Restricted or AllSigned, those can only be changed via GPO.

This is the deepest source of pain when moving automation to PowerShell 7. You'll typically see one of these errors:

Import-Module : Could not load file or assembly 'System.Web, Version=4.0.0.0...'

or:

WARNING: Module 'ActiveDirectory' uses Windows PowerShell compatibility. Some cmdlets may not work correctly.

The first error means the module depends on a .NET Framework assembly that doesn't exist in the .NET Core/.NET 5+ runtime that PowerShell 7 uses. The module was built for Windows PowerShell only and hasn't been updated for PowerShell 7.

The second error is actually progress, PowerShell 7 includes a Windows PowerShell Compatibility feature that can import certain 5.1-only modules and run them in a hidden background 5.1 session. It's not perfect, but it works for many administrative modules. To enable it for a specific module:

Import-Module ActiveDirectory -UseWindowsPowerShell

To check whether a module is compatible with PowerShell 7 before importing:

Find-Module -Name ModuleName | Select-Object -Property Name, PSEdition, Compatibility

For modules where compatibility mode doesn't work, you have three options:

1. Check for a PowerShell 7 native version, many popular modules (Az, ExchangeOnlineManagement, PnP.PowerShell) now ship PS7-compatible versions. Run Update-Module ModuleName first.
2. Use the compatibility shim with -UseWindowsPowerShell as shown above.
3. Run that specific part of your script in Windows PowerShell 5.1 and pass results back, useful when you need both 5.1-only modules and 7-only features in the same workflow.

To see all modules currently loaded and their source:

Get-Module | Select-Object Name, Version, ModuleType, Path

You should see: The module importing without assembly errors. Compatibility mode modules will show a warning but should still function. Verify by running a simple cmdlet from the imported module.

One of PowerShell 7's biggest advantages, and one of its most common sources of confusion, is that it works with .NET objects natively, not just text strings. This is a fundamental shift from bash or cmd. When a command returns data, you're getting back a structured object with properties and methods, not a blob of text to parse. This is exactly what makes PowerShell automation so powerful. But it also means errors look different and require a different mental model to fix.

A common automation error happens when a script expects text output but receives an object:

# This breaks, $result is an object, not a string
$result = Get-Process | Where-Object { $_.CPU -gt 100 }
Write-Output "High CPU process: $result"

Fix it by accessing the specific property you want:

$result = Get-Process | Where-Object { $_.CPU -gt 100 } | Select-Object -First 1
Write-Output "High CPU process: $($result.Name) using $($result.CPU) CPU"

For CSV/JSON output in automation pipelines, a very common need, use the built-in format cmdlets:

# Export to CSV
Get-Process | Export-Csv -Path "C:\Logs\processes.csv" -NoTypeInformation

# Export to JSON
Get-Process | ConvertTo-Json -Depth 3 | Out-File "C:\Logs\processes.json"

# Import and work with CSV data
$data = Import-Csv "C:\Data\servers.csv"
$data | ForEach-Object { Write-Output "Server: $($_.Name), Status: $($_.Status)" }

PowerShell 7 also ships with improved error handling. The $Error automatic variable holds the error history, and the $? variable tells you whether the last command succeeded. For automation scripts, always check these:

try {
    Invoke-Command -ComputerName "Server01" -ScriptBlock { Get-Service }
} catch {
    Write-Error "Failed: $($_.Exception.Message)"
    Write-EventLog -LogName Application -Source "MyScript" -EventId 1001 -EntryType Error -Message $_.Exception.Message
}

Tab completion and command prediction (powered by PSReadLine) are built into PowerShell 7. If tab completion isn't working in your session, check that PSReadLine is loaded:

Get-Module PSReadLine

If it's missing:

Install-Module PSReadLine -Force -SkipPublisherCheck

You should see: Scripts producing clean, structured output, errors being caught and logged properly, and tab completion working in interactive sessions.