PowerShell Editions and Hosts: Choose Your Fighter (Wisely)

Previously on “What Is PowerShell”: we met the engine that turns your tired admin commands into automation symphonies. Today, we’re not re-explaining the engine — we’re picking the right car and the right road. Translation: editions and hosts.

---

The Two Big Ideas (Keep These on a Sticky Note)

• Edition = the runtime flavor. Think Windows-only vintage vs. modern cross-platform. Same language DNA, different under-the-hood frameworks.
• Host = the stage where PowerShell performs. Console? VS Code? ISE (grandpa)? Remote session? All are hosts.

If PowerShell is the orchestra, the edition is the instrument, and the host is the concert hall. You can play the same music, but the vibe (and sound) changes.

---

Editions: Windows PowerShell vs. PowerShell 7+

1) Windows PowerShell 5.1 (aka “Windows PowerShell”)

• Built on .NET Framework
• Windows-only, ships with Windows
• PSEdition: Desktop
• Feature development: frozen in amber (security and fixes only)
• Your go-to when you need old-school, Windows-only modules (e.g., some legacy server products)

2) PowerShell 7+ (aka “PowerShell”)

• Built on modern .NET (Core/5/6/7/8)
• Cross-platform: Windows, Linux, macOS
• PSEdition: Core
• Fast, actively developed, new features like predictive IntelliSense, SSH remoting, and nicer errors
• Installs side-by-side with Windows PowerShell (they don’t fight; they ignore each other like exes at brunch)
• Comes in LTS and Current channels; on servers, LTS is usually your chill friend.

Quick Compatibility Reality Check

• Many Windows modules work in PowerShell 7.
• Some older, Windows-only modules need the Windows PowerShell compatibility shim:

# On Windows, in PowerShell 7+
Import-Module ActiveDirectory -UseWindowsPowerShell

• Module manifests can declare CompatiblePSEditions to signal support.

How to Tell What You’ve Got

$PSVersionTable
# Look at PSEdition (Desktop vs Core) and PSVersion

$PSVersionTable.PSEdition  # 'Desktop' or 'Core'
$PSVersionTable.PSVersion  # e.g., 7.4.1 or 5.1.22621.2506

Rule of thumb: use PowerShell 7 for new scripts and cross-platform work; keep Windows PowerShell around for legacy modules that didn’t RSVP to the modern party.

---

Fast Comparison: Editions

Feature	Windows PowerShell 5.1	PowerShell 7+
Framework	.NET Framework	.NET (Core/5/6/7/8)
Platform	Windows only	Windows, macOS, Linux
PSEdition	Desktop	Core
Development	Maintenance only	Active development
Remoting	WinRM (HTTP/HTTPS)	WinRM + SSH
Module Compat	Highest for legacy Windows modules	High, with -UseWindowsPowerShell for stubborn cases (Windows only)

---

Hosts: Where PowerShell Actually Lives

You’ve got the engine, you’ve chosen your edition — now pick a stage.

What Is a Host?

A host is any application that loads the PowerShell engine and lets you run commands. The host controls the UI/UX (input, output, colors, debugging). The language is the same; the vibes differ.

Inspect your current host:

$Host.Name         # 'ConsoleHost', 'Visual Studio Code Host', 'Windows PowerShell ISE Host'
Get-Host | Format-List *  # If you like way too much info

Common Hosts You’ll Meet

1. Console (powershell.exe / pwsh.exe)

• Raw, fast, everywhere. Great for servers, quick tasks, remote sessions.
• powershell.exe = Windows PowerShell 5.1
• pwsh.exe = PowerShell 7+

2. Windows Terminal

• The cool multiplexing UI that hosts multiple shells in tabs and panes.
• You still run powershell.exe or pwsh.exe; Terminal is the fancy house; the shell is the tenant.

3. Visual Studio Code + PowerShell Extension

• The scriptwriter’s paradise: editing, linting, debugging, breakpoints, IntelliSense, tests.
• Runs a language server + an integrated PowerShell host session.
• Ideal for building modules, debugging complex scripts, and pretending you’re in a hacking montage.

4. Windows PowerShell ISE (legacy)

• The iconic blue tool. No longer developed. Only works with Windows PowerShell 5.1.
• Do not wait for a PowerShell 7 ISE — it’s not coming. Use VS Code.

5. Remoting Hosts

• PowerShell can be hosted over WinRM (classic Windows remoting) or SSH (cross-platform love).
• Also: constrained endpoints via Just Enough Administration (JEA), job schedulers, services, and embedded hosts inside apps.

The “host” changes how you interact. The “edition” changes what’s possible under the hood.

---

Host Feature Snapshot

Host	Best For	Debugging	Cross-Platform	Notes
Console (powershell.exe/pwsh.exe)	Admin tasks, servers, quick scripts	Basic (Set-PSBreakpoint, Write-Debug)	Yes (pwsh)	Default, lightest footprint
Windows Terminal	Power users juggling tabs/panes	Same as console	Yes	UI layer over shells
VS Code + Ext	Script dev, modules, debugging	A++ (breakpoints, watches, variables, testing)	Yes	Modern workflow; recommended
ISE	Legacy 5.1 scripts	A (for 5.1)	No	Deprecated; do not use for new work
Remoting (WinRM/SSH)	Managing remote boxes	Script-level	Yes (SSH)	JEA for least privilege

---

Profiles, Paths, and the "Why Is This Different Here?!" Panic

Different hosts and editions can use different profiles and module paths. That’s not a prank; it’s a design choice.

# See which profile files are in play for this host+edition
$PROFILE | Format-List *

# Compare module search paths
echo $env:PSModulePath -split [IO.Path]::PathSeparator

• Profiles are scoped by edition and host (e.g., VS Code host profile vs. ConsoleHost profile).
• If your prompt/theme only shows up in one place, you probably edited the profile for that specific host.

---

Real-World Scenarios (Choose Your Loadout)

1. You need the Exchange 2016 module that sulks in modern environments.

• Fire up Windows PowerShell 5.1 or use PowerShell 7 on Windows and try:

pwsh
Import-Module ExchangeOnlineManagement -UseWindowsPowerShell

2. You’re writing a cross-platform file watcher.

• Use PowerShell 7 in VS Code. Test on Windows and macOS/Linux with SSH remoting.
• Profit from .NET’s cross-platform FS APIs.

3. You manage 300 servers, you like tabs, and you sip coffee aggressively.

• Use Windows Terminal with profiles for pwsh and powershell, color-coded.
• Keep 5.1 for legacy, 7+ for speed and new tooling.

4. You’re building a module and want debugging that doesn’t hurt.

• VS Code + PowerShell extension. Set breakpoints, step through parameters, watch variables grow up.

---

Rapid Decision Guide

Pick an Edition

1. Do you need a Windows-only, legacy module? → Start with Windows PowerShell 5.1 or 7 with -UseWindowsPowerShell (Windows only).
2. Do you want speed, cross-platform, and modern features? → PowerShell 7+.
3. Is this for a production server? → Prefer the latest LTS of PowerShell 7.

Pick a Host

1. Writing scripts/modules? → VS Code.
2. Doing quick admin tasks on a server? → Console (pwsh) or Windows Terminal tab.
3. Remote management? → WinRM for Windows estates; SSH for cross-platform.
4. Legacy script maintenance in ISE land? → Only if you must — and plan your migration.

---

Gotchas People Trip On (So You Don’t)

• “It works in ISE but not in VS Code!”

  • Different host, different profile, sometimes different runspace behavior. Test in the host you’ll actually use in production (console/VS Code), not just ISE.

• “My module disappeared when I switched editions.”

  • Check $env:PSModulePath. Paths differ between 5.1 and 7+. Install modules per edition or to a shared user scope.

• “Remoting to Linux with 5.1?”

  • 5.1 speaks WinRM, not SSH. Use PowerShell 7 for SSH-based remoting.

• “Which exe am I actually running?”

  • On Windows, 5.1 = powershell.exe, 7+ = pwsh.exe. Path confusion causes existential dread.

---

Pocket Commands to Feel Powerful Immediately

# Who am I (edition/version)?
$PSVersionTable | Format-Table -AutoSize

# Which host am I in?
$Host.Name

# Where do my modules load from?
$env:PSModulePath -split [IO.Path]::PathSeparator

# Show all profiles for this host/edition
$PROFILE | Format-List *

# Start a PowerShell 7 session (Windows) if installed
pwsh

# Start Windows PowerShell 5.1 explicitly (Windows)
powershell.exe

Pro move: add both shells as profiles in Windows Terminal, and give PowerShell 7 a heroic color scheme so you always know which universe you’re in.

---

Wrap-Up: The Elegant Two-Step

• Edition = capability. Windows PowerShell 5.1 is the reliable classic; PowerShell 7+ is the fast, modern, cross-platform standard.
• Host = experience. Choose console/Terminal for admin speed, VS Code for development zen, remoting for scale, and only use ISE for archaeology.

Key Takeaways

1. Use PowerShell 7 for new work; keep 5.1 for legacy modules.
2. Know your host — profiles and paths differ.
3. Prefer SSH remoting for cross-platform; WinRM for Windows estates.
4. Side-by-side installs are normal. You’re not cheating; you’re being strategic.

Final thought: The best automation isn’t just powerful — it’s well-placed. Pick the right edition and host, and your scripts stop fighting you and start high-fiving you.