Understanding the foundations of PowerShell: the difference between powershell.exe and pwsh.exe, choosing the right host between the console, ISE, VS Code, and Windows Terminal, dissecting cmdlet structure with the Verb-Noun convention, using Get-Help and Update-Help, exploring the system with Get-Command, Get-Member, and Get-Module, and configuring the execution policy.

In episode 1 we understood why PowerShell exists — born from Monad to solve the chaos of Windows administration. Now it's time to touch the real thing: the console and command fundamentals. This episode is the "basic etiquette" — what you see on screen, how commands are structured, how to ask the system questions, and the security rules that govern script execution.
If episode 0 prepared the environment and episode 1 prepared the mindset, episode 2 prepares the language. Master this section, and all the following episodes — variables, operators, conditionals, and functions — will feel like adding vocabulary to a language you already understand.
There are two PowerShell engines you'll encounter on a Windows machine, and telling them apart is the first skill you must have:
| Engine | Executable | Version | Characteristics |
|---|---|---|---|
| Windows PowerShell | powershell.exe | 5.1 | Built into Windows; maximum compatibility |
| PowerShell (Core) | pwsh.exe | 7.x | Modern, cross-platform, faster |
Both can coexist on the same machine. The quickest way to confirm which engine is running:
$PSVersionTable.PSEditionThe value Core means PowerShell 7, while Desktop means Windows PowerShell 5.1. Throughout this series we use pwsh, unless there's a special note about 5.1 compatibility.
You need a place to write and run PowerShell. Each host has its own strengths:
| Host | Best For | Notes |
|---|---|---|
Console (pwsh) | Running commands directly | Fast, minimal, default host |
| Windows Terminal | Modern console with tabs | Best host for the console |
| PowerShell ISE | Legacy, 5.1 scripting | No longer developed |
| VS Code + PowerShell extension | Serious script development | IntelliSense, debugger, git |
Rule of thumb: use the console to explore, VS Code to build. You'll switch often — testing commands in the console, then pouring them into scripts in VS Code. Windows Terminal is recommended for both because it provides tabs for many sessions.
Every time pwsh starts, it reads the profile file — a script that executes automatically. This is where you store aliases, functions, and your favorite colors so every session feels like home. See your profile's location:
$PROFILEIf the file doesn't exist yet, create it first. A simple example profile:
if (-not (Test-Path $PROFILE)) {
New-Item -Path $PROFILE -ItemType File -Force
}
Set-Location C:\Users\arman\Documents
Set-Alias g git
function kls {
Get-ChildItem | Format-Wide -Column 4
}
Write-Host "Profile loaded - welcome, $env:USERNAME" -ForegroundColor Green$PROFILE is the same file for powershell.exe and pwsh.exe — if you use both, create a separate profile for each so your settings don't get mixed up.
Every PowerShell command is called a cmdlet (command-let), and its name always follows the Verb-Noun pattern. The most basic example:
Get-Process -Name pwshGet is the verb: taking something.Process is the noun: what is being taken.-Name pwsh is the parameter: filters the results.The genius of this convention: because names are consistent, you can guess. Want to create a service? New-Service. Remove a file? Remove-Item. Run something? Invoke-Command. The system becomes predictable.
| Verb | Meaning | Example |
|---|---|---|
Get | Retrieve/read | Get-Process |
Set | Change an existing value | Set-Content |
New | Create something new | New-Item |
Remove | Delete | Remove-Item |
Add | Add to a collection | Add-Content |
Start | Start | Start-Service |
Stop | Stop | Stop-Process |
Invoke | Perform an action | Invoke-WebRequest |
Microsoft maintains a list of approved verbs — official verbs you're allowed to use. Its purpose is to make the entire ecosystem (Microsoft and the community) speak the same vocabulary. Using a verb outside the list will trigger a warning when you create your own functions in later episodes.
Nobody can memorize every parameter. That's exactly why PowerShell provides a rich built-in help system:
Get-Help Get-Process| Option | Function |
|---|---|
-Full | Full documentation including parameters and advanced examples |
-Detailed | Medium detail, without the most technical parts |
-Examples | Usage examples only |
-Online | Opens the latest documentation in the browser |
-? | Quick Get-Help shortcut from the console |
PowerShell 7 has updatable help — documents that can be downloaded to stay fresh:
Update-Help -ForceBesides per-cmdlet help, there are conceptual about_* topics explaining general rules — like execution policies and automatic variables. Try Get-Help about_* to see the list, or go straight to Get-Help about_Execution_Policies.
Help alone isn't enough — you need to explore what's available on the system.
Get-Command finds commands. Search all cmdlets containing a certain word using wildcards:
Get-Command -Name *Process*Get-Member unpacks the contents of objects — what properties and methods a value has. This is the window to understand what you can do with the data you're holding:
Get-Process pwsh | Get-MemberGet-Module lists available and loaded modules — units that bring collections of cmdlets, for example the Active Directory or Azure module. Show-Command displays a small GUI to compose commands with a parameter form.
Tip
The combination of Get-Command, Get-Help, and Get-Member is the exploration trio: find the command, read its documentation, then dissect the object it returns. This habit replaces feeling stuck with curiosity.
Execution policy is not antivirus protection — it's a reminder: Windows won't run PowerShell scripts silently. There are five main modes:
| Policy | Behavior |
|---|---|
Restricted | No scripts may run (old default) |
AllSigned | All scripts must be signed |
RemoteSigned | Local scripts are free; scripts from the internet must be signed |
Unrestricted | All scripts may run, with a warning |
Bypass | All scripts run without blocking |
On modern Windows 10/11, the default value is generally RemoteSigned — a wise compromise: scripts you write yourself run normally, while scripts downloaded from the internet (the riskiest ones) require a signature.
View your current policy, then change it if needed:
Get-ExecutionPolicy
Set-ExecutionPolicy RemoteSigned -Scope CurrentUserScope determines how broadly a rule applies: Process (this session only), CurrentUser (this user), or LocalMachine (all users, requires administrator). Start with CurrentUser — the safest for learning.
Important
Never blindly copy a script from the internet and run it with -ExecutionPolicy Bypass. This policy is a seat belt — changing it to Bypass permanently is like removing your seat belt so it doesn't bother you. Understand what you run first.
Episode 2 closes out the language fundamentals: you now know how to tell powershell.exe and pwsh.exe apart, choose the right host, read the Verb-Noun cmdlet structure, ask the system questions with Get-Help and Get-Command, dissect objects with Get-Member, and understand the execution policy and its scopes.
Key takeaways:
pwsh.exe (7+) is the series' main engine; powershell.exe (5.1) for compatibility.Verb-Noun pattern — understand the pattern, and the system becomes easy to predict.Get-Command to find, Get-Help to read, Get-Member to dissect.RemoteSigned and only change it in the scope that needs it.In the next episode, episode 3, we get into the "raw materials" of scripting: variables & data types — how to store values in $variable, getting to know types like string, number, boolean, array, and hashtable, plus the string manipulation techniques you'll use in almost every script. Make sure your pwsh is warm, because the material ahead gets more concrete!