Agent Rollout — Bounded Retries, an OS Check, and Keys That Stay ​

September 1, 2026 · InfraScout Team

Four changes to agent rollout and updating. Two of them change behavior you may be relying on, so they are first.

A failing update now stops ​

An update that fails is retried on a ladder — four attempts per host per target version, spaced 15 minutes, 1 hour, and 6 hours apart — and then it stops. The row stays failed until something changes.

Previously there was no cap. A host that could not install a build would re-queue the update each time it reconnected, and since a failed install usually means the agent restarts on its old binary and reconnects, that is a loop with no exit. There was no mechanism by which the platform could conclude that a host was never going to succeed.

If you have a host that has been retrying for weeks, expect it to stop and report failed. That is the fix rather than a regression: a bounded ladder is what makes an impossible install visible instead of endless.

Two details worth knowing:

  • Retries land inside the maintenance window. A retry is scheduled to the host's next window rather than to whenever the clock reaches the interval, so the six-hour rung cannot restart an agent service on a workstation mid-morning.
  • Publishing a new agent version starts a fresh ladder, because the cap is per target version. A host that failed on one build picks up the next one normally.

When a card shows an exhausted ladder, read the agent log on the last attempt. The usual causes are a host that cannot run the binary at all, a maintenance window too narrow to complete an install, and a disk with no room for the package.

The Windows floor is Windows 10 and Server 2016 ​

Windows 7, 8, 8.1, Server 2008 R2, Server 2012 and Server 2012 R2 cannot run the current agent. The current agent binary declares Windows 10 as its minimum supported version, and those loaders refuse it outright with "%1 is not a valid Win32 application" — the service never starts. It is a hard floor rather than a setting: nothing we can change in the build brings those versions back.

Agent releases up to v0.30.2 still ran on them. From v0.32.1 onward they do not.

The rollout script now checks the host's version and refuses before downloading anything, naming the reason.

That refusal is the useful part, because the problem was otherwise invisible at exactly the point you would want to know about it. Enrollment on such a host succeeded — the key was consumed, the identity written, the service installed — and only then did every start attempt fail. The result was a host that looked enrolled, never checked in, and re-queued its update on every reboot.

The check fails open on a version it cannot parse, so an unusual-but-supported host is never blocked by a bad reading. It also reads the version from the system's own inventory rather than the process environment, because Windows' compatibility shim reports an older version to a script than the machine actually runs — which would otherwise misjudge a supported host as unsupported.

If you have hosts below the floor, they need a supported OS before InfraScout can assess them from the inside. Where that is not on the cards, the Microsoft Cloud tools can still tell you a good deal about them from Intune, Defender and the directory with no agent on the host at all.

A queued update shows what it will really install ​

A pending update's target version is fixed when the row is written, and the platform only refreshes it while the agent is reachable. So an offline host accumulates a row naming a version that has since been superseded — and nothing was going to install that version, because it is replaced before dispatch.

The Updates board now shows both: v0.31.2 → v0.32.0, with the stale half muted and the reason on hover. The right-hand version is what will actually ship when the host comes back. The in-flight banner on the Agents page shows the same thing, so the two surfaces cannot disagree about one row.

An expired enrollment key is now a record ​

A bulk enrollment key used to disappear twice over: it left the admin list the instant it expired, and was deleted outright shortly after. What went with it:

  • Any record the key had existed — its name, who minted it, how many hosts it enrolled.
  • The Enrolled hosts and Delete enrolled agents actions, which kept working against a deleted key by design but had no row left to press them from.
  • Any signal it had happened. A rollout whose key quietly ran out looked exactly like one that had finished.

Expiry still stops a key working — every redemption path keeps its own expiry check, so a retained key is a record, never a usable credential. What it no longer does is erase it.

Expired keys now sit in the same list with a Status column. The action reads Delete rather than Revoke, since there is nothing left to revoke, and deleting is the only thing that removes one.

One design note. There is a cap on how many live keys a tenant may hold, so that a key can never be pushed off the end of a list where it cannot be revoked while it goes on minting agents. Retaining expired keys meant ordinary churn could bury a live key beneath newer expired ones. The fix is ordering rather than a second cap: every live key sorts above every expired one, so the live cap bounds what you have to look through. A cap on retained keys would have been the wrong answer — it would wedge a rollout at the worst possible moment.

See Fleet Rollout and Agent Updates.

Questions or feedback? Reach us at info@infrascout.cloud.