Article Title
I wanted a safer way to run the boring Windows admin jobs
Author Name
Jeff Friedler
Affiliation: Fusion Technology Strategies
Submission Type
Draft: Full article included below
Description
Windows administration is rarely difficult because a command is unavailable. The harder problem is controlling what runs, what happens after an interruption, and what evidence remains. This article explains the guardrails behind Windows Admin Toolkit, including preflight checks, bounded retries, policy profiles, signed distribution, and interruption-safe orchestration.
Category
PowerShell for Admins
Tags
PowerShell, Windows administration, WinRM, automation, RMM
Summary / Pitch
I built this after seeing the same operational problem repeat across support, MSP, and RMM work. Running a command is usually the easy part. The difficult part is proving what was authorized, limiting what can happen, handling interrupted work safely, and leaving behind evidence another technician can understand. The article focuses on those design decisions rather than presenting a list of commands.
Article Content
There are plenty of Windows administration scripts online. The problem is not finding one that can restart a service or pull an event log. The problem is knowing what else it might change, what happens when the network drops halfway through, and what evidence is left when the work is over.
That is the problem I wanted Windows Admin Toolkit to solve.
The toolkit is a single PowerShell file with twenty common administration workflows. It can collect system and hardware information, inspect disks and networking, query event logs and the registry, review updates, manage services and processes, schedule a reboot, and handle a few other jobs that come up constantly in support work.
The list of actions is useful, but it is not the interesting part. The guardrails are.
The default remote transport is WinRM. The optional PsExec path accepts only a current Microsoft-signed Sysinternals build and does not pass an alternate password on the command line. State-changing work uses PowerShell approval controls and exact confirmation phrases. Read-only work can be retried within a limit, while a state change is never repeated automatically just because a connection failed at an awkward moment.
The toolkit also has a preflight mode. It checks whether an action is ready without executing the requested action. That sounds simple, but it makes a big difference when the same workflow will eventually run through an RMM platform or against more than one endpoint.
For automation, each named action can return a stable JSON envelope and a useful exit code. Optional policy profiles can narrow the available actions, target modes, transports, runtime limits, and supported inputs. They cannot broaden the built-in behavior.
Audit records are deliberately conservative. They keep useful action summaries and target identifiers without recording passwords, custom source text, or raw custom-command output. Change plans bind the action, inputs, ordered targets, transport, policy, and safety settings before approval. If a run is interrupted, the resume logic does not quietly repeat a target left in an uncertain state.
The current public release is Authenticode-signed. The repository includes a verification-first installation path that checks the expected file hash, the complete approved signer identity, and the timestamp before the script is installed.
If you want to look at it, start with the guarded automation diagram and the sanitized examples. You can run the catalog and preflight paths without pointing it at a production endpoint. That is the right place to decide whether the operating model fits your environment.
Repository: https://github.com/fusiontechstrategies/Windows-Admin-Toolkit
Latest signed release: https://github.com/fusiontechstrategies/Windows-Admin-Toolkit/releases/latest
Author Website or Social Link
https://github.com/fusiontechstrategies
Submission Agreement
Article Title
I wanted a safer way to run the boring Windows admin jobs
Author Name
Jeff Friedler
Affiliation: Fusion Technology Strategies
Submission Type
Draft: Full article included below
Description
Windows administration is rarely difficult because a command is unavailable. The harder problem is controlling what runs, what happens after an interruption, and what evidence remains. This article explains the guardrails behind Windows Admin Toolkit, including preflight checks, bounded retries, policy profiles, signed distribution, and interruption-safe orchestration.
Category
PowerShell for Admins
Tags
PowerShell, Windows administration, WinRM, automation, RMM
Summary / Pitch
I built this after seeing the same operational problem repeat across support, MSP, and RMM work. Running a command is usually the easy part. The difficult part is proving what was authorized, limiting what can happen, handling interrupted work safely, and leaving behind evidence another technician can understand. The article focuses on those design decisions rather than presenting a list of commands.
Article Content
There are plenty of Windows administration scripts online. The problem is not finding one that can restart a service or pull an event log. The problem is knowing what else it might change, what happens when the network drops halfway through, and what evidence is left when the work is over.
That is the problem I wanted Windows Admin Toolkit to solve.
The toolkit is a single PowerShell file with twenty common administration workflows. It can collect system and hardware information, inspect disks and networking, query event logs and the registry, review updates, manage services and processes, schedule a reboot, and handle a few other jobs that come up constantly in support work.
The list of actions is useful, but it is not the interesting part. The guardrails are.
The default remote transport is WinRM. The optional PsExec path accepts only a current Microsoft-signed Sysinternals build and does not pass an alternate password on the command line. State-changing work uses PowerShell approval controls and exact confirmation phrases. Read-only work can be retried within a limit, while a state change is never repeated automatically just because a connection failed at an awkward moment.
The toolkit also has a preflight mode. It checks whether an action is ready without executing the requested action. That sounds simple, but it makes a big difference when the same workflow will eventually run through an RMM platform or against more than one endpoint.
For automation, each named action can return a stable JSON envelope and a useful exit code. Optional policy profiles can narrow the available actions, target modes, transports, runtime limits, and supported inputs. They cannot broaden the built-in behavior.
Audit records are deliberately conservative. They keep useful action summaries and target identifiers without recording passwords, custom source text, or raw custom-command output. Change plans bind the action, inputs, ordered targets, transport, policy, and safety settings before approval. If a run is interrupted, the resume logic does not quietly repeat a target left in an uncertain state.
The current public release is Authenticode-signed. The repository includes a verification-first installation path that checks the expected file hash, the complete approved signer identity, and the timestamp before the script is installed.
If you want to look at it, start with the guarded automation diagram and the sanitized examples. You can run the catalog and preflight paths without pointing it at a production endpoint. That is the right place to decide whether the operating model fits your environment.
Repository: https://github.com/fusiontechstrategies/Windows-Admin-Toolkit
Latest signed release: https://github.com/fusiontechstrategies/Windows-Admin-Toolkit/releases/latest
Author Website or Social Link
https://github.com/fusiontechstrategies
Submission Agreement