PowerShell is a command-line shell and scripting language built on .NET that Microsoft designed for automating and managing Windows systems. On the command line it replaces text-oriented tools with commands that pass structured objects to each other, which lets administrators query, filter and change configuration across one machine or thousands with the same short script.
Two editions exist side by side. Windows PowerShell 5.1 ships with Windows and runs on the .NET Framework, while PowerShell 7 is the current cross-platform edition, installed separately, built on modern .NET and also available on Linux and macOS. Both use the executable names powershell.exe and pwsh.exe respectively.
How the PowerShell object pipeline works
The defining feature of PowerShell is the object pipeline. In Command Prompt or Unix shells, commands exchange plain text that the next command must parse. In PowerShell, a command such as Get-Service emits .NET objects with properties and methods, and the next command reads those properties directly, for example Get-Service | Where-Object Status -eq 'Stopped'.
Commands are called cmdlets and follow a strict Verb-Noun naming convention with approved verbs such as Get, Set, New, Remove and Start. This consistency makes commands discoverable: Get-Command -Noun Service lists every cmdlet that works with services, and Get-Help explains each one with examples.
Text appears only at the end of the pipeline, when PowerShell formats the remaining objects for display. This is why output can be sorted, grouped, exported to CSV or converted to JSON with one additional cmdlet instead of fragile text parsing.
Core building blocks of the language
PowerShell combines an interactive shell with a full scripting language. The table below lists the building blocks that administrators use most often and what each contributes.
| Building block | Example | Purpose |
|---|---|---|
| Cmdlet | Get-Process | Compiled command that emits objects |
| Function | function Test-Port { } | Reusable code written in PowerShell |
| Script | Backup-Logs.ps1 | Saved sequence of commands |
| Module | ActiveDirectory | Package of related cmdlets and functions |
| Provider | HKLM: and Cert: drives | Navigate registry or certificates like folders |
| Variable | $servers | Store objects for later use |
| Alias | ls for Get-ChildItem | Short names for interactive typing |
Providers deserve special mention. They expose data stores such as the Windows registry, environment variables and the certificate store as drives, so the same commands that list files also list registry keys, which shortens the learning curve considerably.
PowerShell compared with other command-line tools
PowerShell coexists with older and neighboring tools on Windows, and each still has a legitimate place. The comparison clarifies when PowerShell is the better choice.
| Tool | Data model | Best suited for |
|---|---|---|
| PowerShell | Structured .NET objects | Administration, automation, remote management |
| Command Prompt | Plain text | Legacy commands and simple batch files |
| Batch file | Text with limited logic | Old login scripts and installers |
| Bash in WSL 2 | Text streams | Linux tooling and cross-platform scripts |
| Windows Terminal | Host application, not a shell | Running all shells in tabs |
| winget | Package commands | Installing and updating applications |
A frequent misunderstanding is to treat Windows Terminal as a replacement for PowerShell. It is only a modern window that hosts shells; PowerShell, Command Prompt and WSL distributions all run inside it.
Remoting, scripts and security controls
PowerShell remoting runs commands on remote computers over WS-Management (WinRM), by default on port 5985 for HTTP and 5986 for HTTPS, with traffic encrypted by Kerberos or TLS. Invoke-Command can run one script block on hundreds of servers in parallel and return their results as objects, while PowerShell 7 can also use SSH-based remoting.
Script execution is governed by the execution policy, which decides whether scripts may run and whether they must be signed. The execution policy is a safety feature, not a security boundary: it prevents accidental execution but can be bypassed by a user who deliberately runs commands.
| Policy | Effect | Typical use |
|---|---|---|
| Restricted | No scripts run, commands only | Default on Windows client editions |
| RemoteSigned | Downloaded scripts must be signed | Default on Windows Server, common choice |
| AllSigned | Every script must be signed | High-assurance environments |
| Unrestricted | All scripts run with warnings | Non-Windows default, rarely appropriate |
| Bypass | Nothing is blocked or warned | Automation that manages security elsewhere |
Real protection comes from script block logging, transcription, Constrained Language Mode and application control policies. Because attackers widely use PowerShell, security teams forward its logs to monitoring systems rather than trying to remove it.
Practical use and common mistakes
Good practice starts with testing before changing. Most cmdlets that modify the system support -WhatIf, which shows what would happen without doing it, and -Confirm, which asks before each change.
Most everyday administration relies on a small core of cmdlets that combine into longer pipelines. The table below lists frequent tasks and the commands that handle them.
| Task | Cmdlet | Note |
|---|---|---|
| Inspect services | Get-Service, Restart-Service | Restart needs elevation |
| Read event logs | Get-WinEvent | Use -FilterHashtable for speed |
| Query system data | Get-CimInstance | Replaces the older WMI cmdlets |
| Manage files | Get-ChildItem, Copy-Item | Works on any provider drive |
| Export results | Export-Csv, ConvertTo-Json | Keeps object properties as columns |
Additional modules are installed from the PowerShell Gallery with Install-Module, and personal settings and functions load automatically from a profile script at every start. Organizations often publish an internal module so that every administrator uses the same tested functions instead of private copies.
- Using aliases in saved scripts makes them hard to read; write full cmdlet names instead.
- Parsing formatted text output throws away the object model; filter on properties before formatting.
- Filtering late in the pipeline wastes time; use the
-Filterparameter of the source cmdlet when it exists. - Running everything as administrator increases damage from mistakes; elevate only when needed.
- Mixing PowerShell 5.1 and 7 without testing can break scripts that depend on older modules.
In simple terms
PowerShell is a typed conversation with Windows. Instead of clicking through many windows, an administrator writes short instructions such as “show me every stopped service” and the computer answers instantly.
Its special strength is that the answers are neat records rather than loose text, like a spreadsheet instead of a printed letter. That makes it easy to sort, filter and pass results on to the next step. The key benefit is that a task done once in PowerShell can be repeated on many computers without extra effort.
A practical example
A systems administrator at a logistics company must find out which of 180 Windows servers still have an outdated version of a monitoring agent before an audit. Checking each server by hand through Remote Desktop would take several days.
Instead, the administrator writes a script of about 15 lines that reads the server list from Active Directory, uses Invoke-Command to query the installed agent version on each machine in parallel and exports the results with Export-Csv. After a test with -WhatIf on the upgrade step, a second script installs the new agent on the outdated servers.
The whole inventory finishes in under ten minutes, and the CSV report becomes evidence for the audit. The administrator schedules the script to run weekly, so version drift is detected automatically from then on.