The command line, and the twenty commands that earn their place

Why this matters

The command line has a reputation problem in support work: people either avoid it entirely or treat fluency in it as the point. Neither is useful. It is a tool that does a small number of things much better than clicking does, and the exam tests exactly those things.

What makes it worth learning is that it answers questions precisely. A graphical network status says "connected". ipconfig says which address, from which server, with which gateway and which resolvers — and half the faults in this course are diagnosed by reading those four values. The command line is where the machine tells you what it actually thinks, rather than what it thinks you want to hear.

The lesson

Why a support technician needs a shell at all when the graphical tool exists

There are three honest reasons, and "it is faster" is not really one of them.

It reports exactly rather than approximately. A graphical indicator summarises; a command prints values. When a user says the internet is down and the icon says connected, the icon has told you nothing and four commands tell you where in the chain it broke.

It works where the desktop does not. The recovery environment, a machine that boots to a black screen, a remote session over SSH, a server with no graphical shell. The troubleshooting objective in this course leans on this repeatedly: when the desktop is the broken thing, the command line is what is left.

It is repeatable and describable. "Run ipconfig /all and send me the output" is a sentence a user can follow. "Click the network icon, then properties, then scroll down" is a sentence they cannot, and the result is a screenshot of the wrong pane.

What it is not better at: anything involving exploration, anything you do once, and anything where the graphical tool shows relationships — Disk Management's layout view is genuinely clearer than the command-line equivalent, and using the harder tool to prove a point is not professionalism.

Navigation, files and directories, and the commands that are the same everywhere

A small set of commands does the same job on every system you will meet, and learning the shape once is worth more than memorising two dialects.

Windows, with the equivalent idea in brackets:

• cd — change directory. The same word everywhere.
• dir (ls) — list what is here.
• md / rd (mkdir / rmdir) — make and remove directories.
• copy, move, del (cp, mv, rm) — the obvious three.
• xcopy and robocopy — copy trees, with robocopy being the one that handles long paths, retries, and mirroring properly. Robocopy is the right answer whenever a scenario involves copying a large folder structure reliably.
• type (cat) — print a file to the screen.
• cls (clear) — clear the screen.
• help <command> or <command> /? — the built-in manual, and the habit worth having.

Two conventions that cause more confusion than they should: Windows uses backslashes between path components and forward slashes for options, while Unix-like systems use forward slashes for paths and dashes for options. And any path containing a space must be quoted, on every system, which is the cause of a large share of "the command does not work" reports.

The practical skill is not recall. It is knowing that these exist, knowing that /? will tell you the rest, and being unafraid of a prompt.

Network commands: ipconfig, ping, tracert, nslookup, netstat and what each proves

These five are the diagnostic core of this exam, and each answers exactly one question.

• ipconfig /all — what do I think my own configuration is? Address, mask, gateway, DNS servers, DHCP server, lease. An address starting 169.254 means DHCP failed and nothing answered. No gateway means nothing remote will work. No DNS servers means addresses will work and names will not.
• ping — can I reach that host, and how long does it take? Pinging the gateway separates "my network" from "the internet". Remember that many hosts deliberately ignore ping, so a failure is not proof of a fault.
• tracert — where does it stop? Useful when something distant is unreachable and you need to know whether the problem is near you or far away. Middle hops that do not answer are normal; a route that stops at the same place every time is informative.
• nslookup — what does DNS actually return, and from which server? This is how you separate a name problem from a connectivity problem in one step.
• netstat — what is this machine connected to, and what is listening? With -a -n -o it shows every connection and the process behind it, which is how an unexplained connection gets a name.

The order that solves most cases: ipconfig /all to see the configuration, ping the gateway, ping an address on the internet, ping a name. Where the chain first fails tells you which layer to look at, and it takes under a minute.

Disk and system commands: chkdsk, sfc, dism, gpupdate, and when each is the answer

Four commands cover most system-level repair in this exam, and each has a specific moment.

• chkdsk checks the file system for structural problems. With /f it fixes them; with /r it also looks for bad sectors, which takes a long time. It usually requires a restart to run on the system volume. Reach for it when files or folders behave impossibly.
• sfc /scannow checks protected system files against their known-good versions and repairs them. Reach for it when Windows components misbehave after a crash or a failed update.
• DISM /Online /Cleanup-Image /RestoreHealth repairs the component store that sfc repairs from. This is the ordering fact the exam wants: when sfc reports corruption it cannot fix, run DISM and then run sfc again.
• gpupdate /force re-applies group policy immediately rather than waiting for the refresh interval. Reach for it after a policy change on a domain machine, and use it as a test: if a setting appears after gpupdate, policy is the cause.

One more worth knowing because it appears in shutdown scenarios: shutdown with its switches restarts, shuts down, or restarts into the firmware settings (shutdown /r /fw /t 0), which is the reliable way onto a machine that boots too fast to catch a key.

Running as administrator, and the commands that silently do nothing without it

Some commands fail loudly without administrative rights. The dangerous ones fail quietly, or appear to work and change nothing.

Windows shows this clearly enough once you know: an elevated prompt usually opens in C:\Windows\System32 and says Administrator in the title bar. A non-elevated prompt opens in the user's profile folder. That is a two-second check and it is worth making a habit.

Commands that need elevation and are commonly run without it: sfc, DISM, chkdsk /f, netsh when changing configuration, sc when changing services, and anything writing outside the user's own profile.

The quiet failure worth knowing about is file system virtualisation: older applications writing to protected locations without elevation are silently redirected to a per-user copy. The write succeeds, the application is happy, and the file is not where anyone will look for it. A setting that "does not save" for one user and saves for another is often this.

On Unix-like systems the same idea is sudo, with one difference worth carrying: sudo asks and then tells you clearly when you are not permitted, which is a better failure mode than silent redirection.

The professional point: elevate deliberately, for the command that needs it, and close the elevated prompt afterwards. Working all day in an administrative shell is the command-line version of browsing the web as an administrator, and the security objectives have a good deal to say about that.