PsTools

Administering a machine you are not sitting at usually means opening a remote session, waiting for a desktop to appear, doing one thing and closing it again. PsTools replaces that with a set of command-line utilities that each do one job on a machine somewhere else, without a session and without anything installed on the target.

PsTools covers roughly a dozen utilities. Running a program remotely, listing processes, killing them, suspending them, examining services, reading event logs, finding who is logged on, shutting a machine down, changing passwords and reporting system information.

Each one takes a machine name and does its work. That is the whole design and it is why the set has remained standard for so long.

Nothing is installed on the target

The architectural point that makes PsTools useful is the same one that makes it slightly unnerving.

No agent exists. When you run a program on a remote machine, a small service is copied across, does the work, and is removed afterwards, leaving nothing behind. Everything else operates over the administrative channels the system already provides.

That means a machine you have never touched can be administered immediately, provided you already hold administrative credentials on it and the usual channels are reachable. Nothing needs preparing on the far end.

The same agentless approach organised into a management console rather than a command line is what BatchPatch provides, for anybody who would rather select rows in a grid than type machine names.

The one everybody knows

Of the dozen, the tool that runs a program on a remote machine is the one people mean when they say PsTools.

It executes anything you specify on the far machine, optionally interactively, optionally as a different account, with the output returned to your own window. Restarting a service, running a script, applying a fix or launching a diagnostic on a machine three floors away all become one line.

That capability is also why security software frequently objects to it, and the reason is worth understanding rather than working around. Somebody who has obtained credentials on a network uses exactly this technique to move from machine to machine, so the pattern is monitored closely.

The tool does not grant access. It uses access you already have, which is the distinction between an administration tool and an intrusion tool, and it explains both its usefulness and its reputation.

The rest of the set

The other PsTools utilities are less famous and get used more often than people expect.

Listing processes on a remote machine, killing one that has hung, or suspending one temporarily covers the majority of support calls that would otherwise need a session. Service control does the same for services, which is where a surprising number of problems actually live.

Event log extraction pulls logs to your own machine for reading, which beats scrolling through a viewer over a slow connection. Finding who is logged on answers the question that precedes any reboot, and the shutdown tool handles the reboot itself with a delay and a message to whoever is sitting there.

For examining processes on the machine in front of you, with far more detail than a list, Process Explorer shows what each one has loaded and what it is doing.

Scripting is the real use

Individually the PsTools utilities are conveniences. Together in a script they become something else.

Because each tool takes a machine name and returns output, a list of machines and a loop covers an entire network. Checking a service across sixty machines, collecting event logs from all of them, or applying the same fix everywhere becomes a file you run rather than an afternoon.

That is how the collection is actually used by people who use it daily, and it is why a command-line interface is a feature rather than a limitation here.

Knowing which machines are present to loop over is the prerequisite, and Advanced IP Scanner produces that list quickly.

What it asks of you

PsTools has two requirements, and neither is negotiable.

Administrative credentials on the target, because everything here operates with the rights of the account you supply. Without them nothing works, which is the correct arrangement.

And reachability, meaning the administrative channels available and the firewall permitting the traffic. A machine that refuses to respond is a configuration question on that machine rather than a fault in the tool, and it is where most of the setup time goes.

Keeping the whole set alongside other diagnostic utilities is the usual arrangement, and a launcher that organises collections of small system tools is where that folder tends to end up.

Conclusion

PsTools has stayed standard for decades because the design was right the first time. One job per tool, a machine name as the argument, output returned to you, nothing installed anywhere, and everything scriptable.

Approach it knowing the two constraints. It uses credentials you already hold rather than granting anything, and it needs the administrative channels reachable, which is where the setup effort goes on a network that was not built with this in mind. Past that, a command line and a text file of machine names cover work that would otherwise mean walking to each desk.