File Server Agent: Updates & Lifecycle
The agent updates itself on a schedule it does not control, one machine can be opted into early access to a new build, and BYOVault separately alerts you when a machine has gone quiet.
The poll loop
The agent runs one continuous loop, once every 60 seconds. Each iteration proceeds in a fixed order:
- Check whether an update is required
- Run a backup poll cycle
- Run a restore poll cycle
- Sleep until the next iteration
The update check always runs first. If it determines an update is required, the agent launches its updater helper process and exits the loop immediately, without starting that iteration’s backup or restore work — so an update is never applied in the middle of a backup or restore job; the earliest it can happen is the gap between one iteration finishing and the next one beginning.
A failed update check — a network blip, or BYOVault being briefly unreachable — is caught and logged, never allowed to block that iteration’s backup or restore polling. The agent simply retries the version check on the next iteration, roughly a minute later.
How an update is decided
The agent does not decide for itself what counts as current. BYOVault determines whether a given agent needs to update, and supplies the update when it does.
BYOVault controls when a new version becomes required fleet-wide, and can stage a new build on select machines first before requiring it everywhere.
If the agent cannot reach BYOVault at all, it does not update, and does not treat the failure as anything more than a reason to try again on the next iteration.
Early access: staging one machine ahead of the fleet
A single file server can be opted into receiving a new build before the rest of the fleet.
On that machine’s entry in the File Servers tab, an operator can turn on Receive new agent versions early; the machine is then labeled Early updates in the source list.
This lets BYOVault watch a new build running on one real machine before it is required fleet-wide, while every other agent continues to follow the general rollout rule.
Applying the update
When an update is required, the agent downloads the new installer to a local working directory and hands off to a separate updater helper process rather than modifying its own running files.
That helper is responsible for:
- Stopping the Windows service
- Applying the new installer
- Starting the service back up
The agent’s own poll loop exits as soon as the helper is launched, since a service that is about to be stopped from outside should not also be racing its own next poll cycle.
Repeated update attempts are automatically rate-limited, so a build that fails to take effect is not re-downloaded on every single poll.
Stale-agent alerting
Separately from the update mechanism, BYOVault runs an hourly check across every active file server agent, for every tenant, looking for any agent that has not checked in at all for more than 30 minutes.
Because the agent polls roughly every 60 seconds, 30 minutes of total silence means dozens of missed polls in a row — a real signal, not a single missed check-in.
When a tenant has one or more stale agents, BYOVault sends that tenant’s own configured notification recipients a single email listing every stale machine found — one email per tenant, not one per machine. That email includes, for each machine:
- Its hostname
- Its reported version
- When it was last seen
A tenant with no notification recipients configured is not left unalerted; the notice falls back to the BYOVault operator instead. See Notifications & Alerts for where those recipients are configured and how the fallback resolves.