19 You call this scripting?

This chapter reassures administrators that you can get far in PowerShell without “programming,” then shows how lightweight scripting mainly saves keystrokes and makes repeat tasks consistent. Before writing scripts, it squarely addresses security: PowerShell honors existing user permissions and isn’t a bypass mechanism; its execution policy is about reducing accidental script execution, not stopping a determined user. You learn the defaults and trade-offs (for example, Restricted on Windows 10, RemoteSigned on Windows Server, and no enforcement on non-Windows), ways to set or override policy (Set-ExecutionPolicy, Group Policy, or the PowerShell.exe switch), and why Microsoft commonly recommends RemoteSigned as a balance of safety and convenience.

From there, the chapter treats scripts like enhanced batch files: capture a command you already run, format it for readability, and save it—ideally using VS Code for easy editing, testing (Run/F5, selective F8), and discoverability. It demonstrates turning a multi-line pipeline (such as a disk inventory built with CIM, sorting, and custom formatting) into a reusable script with a clear, verb-noun name. To make commands repeatable and shareable, you first replace changeable values with variables, then upgrade them to input parameters via a Param() block and sensible defaults. You also see how PowerShell supports both positional and named parameters, tips for multi-line pipelines, and how to embed comment-based help (.SYNOPSIS, .DESCRIPTION, .PARAMETER, .EXAMPLE) so users can call Help on your script just like a built-in cmdlet.

The chapter closes with two essential mental models for reliable scripts. First, “one script, one pipeline”: when multiple commands run inside a script, their outputs flow into a single pipeline and formatter—so mixing object types can yield unexpected displays; aim to output one object type or explicitly format. Second, scope: variables, aliases, and functions live in scopes (global, script, function), are short-lived with their scope, and local definitions shadow parents. Don’t depend on parent scope state inside your scripts; define what you need (often via parameters) to keep behavior predictable. The overall takeaway is pragmatic: keep scripts simple, parameterize what varies, document them, and understand execution policy, pipelines, and scope so your automation is safe, readable, and repeatable.

Finding the Windows PowerShell settings in a Group Policy object

Changing the Windows PowerShell execution policy in a Group Policy object

Entering and running a command in vscode using the two-pane layout

Viewing the help by using the normal help command

Two commands, two pipelines, and two sets of output in a single console window

All commands within a script run within that script’s single pipeline.

Global, script, and function (private) scopes

FAQ