PowerShell and scripting, at the depth a support role actually uses

Why this matters

Scripting sits awkwardly in a support role. You are not a developer, you will not be asked to build anything, and yet scripts are everywhere: in the onboarding process, in the software deployment, in the thing that maps the drive at logon, and in the file a user was emailed and would like you to check before they run it.

So the useful depth is narrow and precise. Recognise what kind of script you are looking at. Know why PowerShell is different from the old shell. Know why the first script anyone runs is blocked, and what the correct response to that block is. And be able to read a script well enough to say whether it should be run — which is a security skill more than a programming one.

The lesson

Script file types by extension, and what each one is run by

Extension tells you the interpreter, and the interpreter tells you what the file can do.

• .bat and .cmd — batch files, run by the traditional Windows command interpreter. Old, limited, still everywhere.
• .ps1 — PowerShell. The current Windows scripting language, and the one a modern estate uses.
• .vbs — VBScript, run by the Windows scripting host. Legacy, and disproportionately common in malicious email attachments precisely because it is old and widely enabled.
• .sh — a shell script, run by a Unix-like shell. Also what a macOS machine runs.
• .py — Python, which runs anywhere Python is installed and nowhere it is not.
• .js — JavaScript. Harmless in a browser sandbox; a real program when run by the Windows scripting host, which is the distinction that makes .js attachments dangerous.

Two practical notes. Extensions can be hidden by default, so invoice.pdf.js displays as invoice.pdf with a slightly odd icon — this is a genuine and current technique and it belongs in your head next to the social engineering material. And a text file is only a script when something runs it: renaming a .txt to .ps1 makes it a script, which is why "it was only a text file" is not a defence.

PowerShell against cmd: objects rather than text, and why that changes everything

The old command interpreter passes text between commands. PowerShell passes objects, and almost every practical difference follows from that.

With text, getting a value out of a command's output means finding it by position or by pattern — counting columns, matching on a word — and it breaks when the output format changes or the machine is in a different language.

With objects, a command returns things with named properties, and you ask for the property. Get-Process returns process objects with a CPU property, so sorting by processor time is asking for that property rather than parsing a column. Nothing has to be re-parsed when the display changes, and nothing breaks in another language.

The other differences worth knowing for the exam:

• Verb-noun naming. Get-Service, Stop-Process, Set-ExecutionPolicy. Guessing a command name is often correct, which is unusual and useful.
• Get-Help <command> and Get-Command, which make the shell self-documenting.
• -WhatIf, which shows what a command would do without doing it. For a support technician this is the single most valuable feature in the language, and the habit of appending it first is worth building now.
• PowerShell runs on macOS and Linux too, which surprises people.

None of this makes the old interpreter useless — a two-line batch file that maps a drive is perfectly good — but new work goes in PowerShell and estates are managed with it.

Execution policy, signing, and the block every first script runs into

Almost everyone's first PowerShell script refuses to run, with a message about execution policy. The right response is to understand it rather than to disable it.

Execution policy decides which scripts the shell will run. The common settings:

• Restricted — no scripts at all. The default on client Windows, which is why the first script fails.
• AllSigned — only scripts signed by a trusted publisher.
• RemoteSigned — local scripts run; scripts downloaded from elsewhere must be signed. This is the sensible working setting and the usual answer.
• Unrestricted / Bypass — everything runs. Appropriate for a specific automated context, not for a workstation.

Two facts the exam likes. Execution policy is not a security boundary — it stops accidents, not attackers, and there are ordinary documented ways to run a script's contents without changing it. And the mark of the web is what makes a downloaded script "remote": the file carries a marker saying it came from the internet, which can be inspected and removed deliberately.

The professional response to a blocked script is therefore not Set-ExecutionPolicy Unrestricted machine-wide. It is: read the script, decide whether it should run, and if so run it in a scope that ends when the window does — -Scope Process — or have it signed properly if it is going to be used repeatedly. A technician who solves this by disabling the policy globally has removed a speed bump for every future script too, including the ones nobody chose.

What scripting is legitimately used for here: mapping drives, installs, reporting

Scripting in this role is a small, specific list, and it is worth knowing what belongs on it.

• Mapping drives and printers at logon. The classic, and still the most common script a support technician meets.
• Installing or updating software across a set of machines, usually invoked by a management system rather than by hand.
• Collecting information. "Which machines have less than 10 GB free?" is a question that takes one line and answers itself, and doing it by hand across forty machines is a day.
• Repetitive account or file work — creating a batch of accounts, applying a permission change to a set of folders, clearing a cache directory on every machine.
• Scheduled maintenance — a nightly job that tidies temporary files or exports a report.

What is not in scope for this role: writing applications, building infrastructure automation, or replacing a management system with scripts. A support technician who ends up maintaining a hundred scripts has usually been handed somebody else's job.

The judgement worth applying is simple: automate something you have done three times and will do again, keep it short enough to read in one screen, and write a comment at the top saying what it does and who to ask. The operational procedures objective calls this documentation, and a script with no comment is a script nobody else can safely change.

The risks of running a script you did not write, and how to read one first

This is the part of the objective that is really a security skill, and it comes up constantly: a user forwards a script, or a web page says to run one command to fix a problem.

The rule first: do not run a script you have not read, and do not run one you cannot read. A script that is obfuscated, encoded, or downloads and executes something else is not a script you can evaluate, and "it is from a reputable site" is not evidence because the script is what it is regardless of the page around it.

What to look for when reading one:

• Where does it get things from? Any download from a URL is the most important line in the file. Is the host one you recognise?
• What does it delete or overwrite? Search for remove, delete, format, and any redirection into an existing file.
• Does it change security settings? Firewall rules, execution policy, accounts, group membership, scheduled tasks, startup entries.
• Does it need administrative rights, and why? A script that asks for elevation to do something that should not need it is the clearest warning sign there is.
• Is any of it encoded? A long base64 blob passed to the interpreter is deliberate concealment, and there is no innocent reason for it in a script a user was emailed.

Then run it the safe way: on the disposable machine, with a snapshot taken, isolated, and with -WhatIf first if it supports it. That is exactly what the supplementary lesson set the machine up for, and this is the first place in the course that spends it.