When Remote Fixes Don't Land: Auditing Fleet Command Failures

You pushed a policy to the fleet: every node must have SMBv1 disabled by Friday. WinSentinel dispatched an apply_fix to all 40 machines. The dashboard turns green. You close the ticket.

But three of those machines are laptops that were asleep when the command was issued. One is a server where the agent is running as a low-privilege account that can't touch the registry key. Another timed out. The apply_fix was dispatched to all 40 — it landed on 35. Five nodes are still exposed, and nothing on the summary screen tells you that.

This is the gap between dispatch and delivery. Fleet orchestration is only as good as its ability to tell you when a remote command didn't take — and the machines where it didn't take are, by definition, the ones still carrying the risk you thought you'd remediated.

Dispatched is not the same as done

Every remote command WinSentinel Pro sends to a node — scan_now, apply_fix, push_policy, update_agent — moves through a lifecycle: pending → acknowledged → a terminal state of completed, failed, or expired.

• failed — the node picked up the command and tried, but it errored: insufficient privilege, a locked resource, a fix that couldn't apply cleanly.
• expired — the node never acknowledged in time. Offline, asleep, or an agent that stopped heartbeating. The command aged out unexecuted.

A rollup that only counts dispatched commands hides both. A velocity view (mean time to completion, success rate over a window) tells you the fleet is generally healthy but not which machines are the holdouts. What an admin actually needs is the failure-first cut: the specific nodes and command types where remediation is not landing.

The failure-first view

The Pro admin CLI has a dedicated verb for exactly this:

winsentinel-fleet commands failures --license-key WSP-XXXX-XXXX-XXXX

It isolates the terminal failures (failed and expired) from the whole dispatch history and ranks them two ways — worst first:

Command failures (all time)
  7 failures of 42 terminal  -  17% fail rate  (4 failed, 3 expired)
  Worst node app-sql-02 (3)  -  worst type apply_fix (5)

  Worst nodes (most failures first):
    app-sql-02   3 of 4        75% fail  [2 failed, 1 expired]
    laptop-1477  2 of 2       100% fail  [2 expired]
    web-fe-09    1 of 6        17% fail  [1 failed]
    kiosk-03     1 of 1       100% fail  [1 failed]

  Worst command types (most failures first):
    apply_fix    5 of 20       25% fail  [3 failed, 2 expired]
    update_agent 2 of 8        25% fail  [1 failed, 1 expired]

Why the failure rate matters, not just the count

Raw failure counts mislead. A busy node that ran 200 commands and failed 3 is healthier than a node that ran 3 and failed all 3 — even though the second has fewer failures. That's why every row carries a failure rate (failures ÷ terminal commands): laptop-1477 at 100% of 2 is a machine you can no longer reach at all, while web-fe-09 at 17% of 6 had one bad apply and is otherwise responsive.

The pattern also reads by type. If apply_fix fails disproportionately but scan_now never does, the agents are online and reporting — they just can't remediate. That usually points at a privilege problem (the agent isn't elevated) rather than a connectivity one. A high expired share, by contrast, means machines that aren't there to receive the command at all.

Wire it into monitoring

The verb exits non-zero when there is any failure in the window, so it drops straight into a scheduled check:

# Alert if any dispatch failed in the last 7 days
winsentinel-fleet commands failures --window 7 --license-key WSP-... || notify-team

Add --csv for an audit-evidence export (one self-describing row per failing node and type, ranked worst-first) or --json for a pipeline. Pair it with fleet fix-all --dry-run before a real remediation so you know a fix is applicable everywhere before you dispatch it — and commands failures after, to prove it actually landed.

The takeaway

A green dashboard means the fleet dispatched your remediation. It does not mean the fleet applied it. The machines where a remote fix silently failed are exactly the machines still carrying the exposure you closed the ticket on. Auditing command failures — by node, by type, by rate — is how you close the loop between "we pushed the fix" and "the fix is live everywhere."

Fleet command dispatch, delivery tracking, and failure analytics are part of WinSentinel Pro. The single-machine tool — every audit module, the monitor, scheduled scans, PDF reports, and one-click fixes — is free and always will be. See pricing for how the fleet control plane works.