An Overview of Freeware Windows Sysadmin Tools for the Console

Q: Is there a supported way to read a service access list without editing it?

Yes, and it is worth making a habit of: sc sdshow <service> prints the descriptor and changes nothing. Reading before writing is the one procedural rule that prevents the worst outcome in this area, which is locking every account including your own out of a service.

Four narrow areas, one index. The freeware Windows sysadmin tools documented on this site all came from the same period and the same instinct. Do one thing from a console, print your own manual, return an exit code, and each of them sat on a platform gap that has since closed. This page is the map: what the area is, what the old notation meant, and which command owns it now.

An index of four tooling areas with the console command that now covers each.

The four areas, in one console overview

Grouping them this way is not arbitrary. Each area is defined by which part of the system owns the operation, and that ownership is exactly what determines whether the operation can be performed remotely, whether it needs a privilege, and whether it survives a reboot.

Service and driver access
A service is a securable object. Who may start it, stop it, read its configuration or rewrite its binary path is decided by an access list, not by group membership. Owned by the service control manager, editable remotely, survives reboots, and the one area here that has barely changed. Now: sc sdshow and sc sdset.
Power states and shutdown
Shutdown and restart have a remote interface; suspend and hibernate do not, because they belong to the local power manager. That split explains why half the flags on an old shutdown utility only worked locally, and why the ones that did not resorted to copying a binary onto the target. Now: shutdown and powercfg.
Identity and secondary logon
Running a program, or a whole desktop, as somebody else. The interesting constraint is not obtaining a token but obtaining one without granting a privilege that defeats the purpose. Now: runas, the secondary logon service, and whoami /all to verify what the token actually contains.
Shell metadata and property sheets
File metadata read and written through the shell rather than through an application. The registration mechanism for adding a tab to a property sheet is unchanged; what changed is that the shell now covers the common formats itself. Now: the built-in property handlers, plus a dedicated editor for anything in bulk.
The small utilities
Nine console programs for hardlinks, error codes, the clipboard, environment variables, battery state and account information. Seven have built-in replacements, one solved a problem that no longer exists, and one did something that is deliberately not supported any more.

Reading an old switch notation without guessing

The practical skill this material teaches is translation. Documentation from this period uses conventions that current tooling dropped, and a few of them change meaning rather than just spelling.

Conventions of the period

Forward slash switches: Standard on Windows. A leading dash usually signals a tool ported from Unix.
Bracketed letters in output: An access mask, not a status. [XR] is a set of rights.
A leading minus on an entry: A deny entry, evaluated before every allow entry regardless of position.
<code>\\MACHINE</code> as first argument: Remote target. Omitted means local.
An edit switch: Modify rather than replace. Its absence usually means destructive replace.
A nologo or quiet switch: Suppress the version banner so output can be parsed.
<code>(null)\(null)</code>: An identifier that does not resolve on this machine. The entry is still live.

The one that causes real damage is the edit switch. A tool whose default is to replace an access list will happily write exactly what you named and discard everything else, including your own right to edit it again. Both the tooling of the period and sc sdset today behave this way. Read the descriptor, modify the string, write the whole thing back.

What to reach for now, by task

A short overview of the supported commands, since half the reason to read old documentation is to find out what to type instead.

sc sdshow  Spooler                      ← read a service access list
sc sdset   Spooler "D:(A;;…)"           ← write one back, in full
shutdown /r /m \\HOST /t 120 /d p:2:4    ← remote restart with a reason
powercfg /devicequery wake_armed        ← what is allowed to wake this machine
runas /user:DOMAIN\name "program"       ← run as a second identity
whoami /all                             ← identity, groups and privileges of THIS process
mklink /H link target                   ← hardlink on NTFS
fsutil hardlink list file               ← how many names this file already has
net helpmsg 5                           ← decimal error number to text
certutil -error 0x80070005              ← hexadecimal or COM result to text

Why a freeware collection is worth an overview at all

Because the four areas turn out to answer the same three questions, and the answers all come from ownership. The service control manager owns service access, so an edit can be made across the network, needs an access right rather than a privilege, and survives a reboot because it lives in the descriptor. The local power manager owns suspend and hibernate, which is why those two have no remote form at all while shutdown and restart do. The secondary logon service owns identity, so a second account needs a logon right on every machine in scope and the result lasts exactly as long as the process it started. The shell owns property-sheet metadata, so the handler is a registry registration rather than a running program, and nothing changes until Explorer reloads it.

Read that way the switch tables stop being trivia: each flag is a claim about which subsystem is being asked. That is what makes the freeware Windows sysadmin tools collected here worth an overview rather than a list of names, and it sets a useful expectation for anyone evaluating Windows sysadmin tools today, because a utility that only wraps an existing interface will eventually be replaced by that interface getting a command of its own. The object model outlived the software by a long way, and reading the old switch tables remains one of the faster routes into it.

Questions about these Windows sysadmin tools

Are any of these tools still downloadable?

Not from anywhere maintained. The LS-Tools utilities were published as freeware for Windows NT and Windows 2000, the shell extension for Windows 9x as well, and development stopped; there is no current distribution and no security support. This site documents what they did and what does the same job now, which is the part that is still useful.

Should I run a twenty-year-old console binary on a current machine?

Generally no. A 32-bit console executable will usually start, but several of these called interfaces that have since changed, one installed a service to do its work, and none of them have been reviewed since. Every capability described here has a supported equivalent, and the supported equivalent is the one to use.

Why document tools nobody can install?

Because the documentation outlived the software. Runbooks, forum answers and internal wikis written between 1998 and 2010 are full of these switch notations, and a reader who cannot decode them cannot tell a safe instruction from a dangerous one. The mapping is the value.

What is the single most useful thing to learn from the set?

That a service is a securable object with its own access list. Most of the operational problems people hit are one access mask away from being solved properly rather than by handing out administrator rights.

Is PowerShell always the right replacement?

Not always. For anything that has to run inside a plain command prompt, a startup script, or a constrained environment, the classic console commands are still shorter and have fewer prerequisites. PowerShell wins where objects and pipelines help: collections of machines, structured output, credential handling.

Which of these areas changed most since?

Power management. The interface these tools used predates ACPI entirely, and modern power behaviour has no counterpart in the older model: connected standby, per-device wake permissions, hibernation files that may not exist. Service security, by contrast, is essentially unchanged.

Do the graphical utilities of that era have equivalents?

Mostly they were absorbed into the shell rather than replaced. Session switching, tabbed property sheets showing file metadata, and per-session drive letters were all third-party additions that later shipped in the box. That absorption is the recurring pattern of the period.

Is there a supported way to read a service access list without editing it?

Yes, and it is worth making a habit of: sc sdshow <service> prints the descriptor and changes nothing. Reading before writing is the one procedural rule that prevents the worst outcome in this area, which is locking every account including your own out of a service.

What replaced the MFC runtime archives that shipped alongside?

Redistributable runtimes are still a thing, they are just installed by the application rather than fetched separately by the user. The specific archives are obsolete; the failure mode is not: an executable that will not start because a shared library is missing.

Does anything here apply to Windows Server?

All of it, and service permissions more so. A server is where the case for granting a precise access mask instead of administrator rights is strongest, and where a security policy applied across the estate beats editing descriptors machine by machine.