File Server Agent Deployment
Deploying the agent to one file server and deploying it to a fleet of them raise different questions. None of the guidance below is a configuration setting to turn on — it is what to understand about how the agent already behaves, so a larger rollout does not produce noise or false alarms.
Manual bandwidth throttling is generally unnecessary
The agent does not upload at a fixed concurrency that someone has to size for the network it happens to be running on. It runs an adaptive concurrency controller that watches its own recent upload outcomes — throughput and failures over a rolling window — and raises or lowers how many files it uploads at once in response: a job starts at maximum concurrency and is cut in half the moment either a real failure rate or a real throughput collapse is detected, then climbs back up gradually once conditions have stayed healthy for several consecutive windows.
The full mechanics, including the exact thresholds, are documented in Agent: Bandwidth & Concurrency.
No per-machine number to configure
For a fleet rollout, the practical implication is that there is no per-machine or per-site bandwidth number to configure before deployment — no such setting exists even if one wanted to precompute one.
A file server on a constrained office uplink and a file server on a data-center-grade connection both start at the same default and settle at whatever concurrency their own network actually supports. Sizing a manual cap in advance is unnecessary and, because it does not adapt if conditions change later, likely to be wrong in one direction or the other by the time it matters.
Understand the stale-agent alert before scheduling a maintenance window
BYOVault runs an hourly check across every active file server agent, for every tenant, looking for any agent that has gone completely silent — no successful poll at all — for more than 30 minutes.
The agent checks in roughly every 60 seconds under normal operation, so a single missed check-in or a brief network blip is expected noise and does not trigger anything. Thirty minutes of total silence means dozens of consecutive missed polls, which is treated as a real signal rather than a fluke.
This matters for planned maintenance. Stopping the BYOVaultAgent service, rebooting the machine, or taking a file server offline for longer than 30 minutes will cause that machine to appear in the next hourly check as a stale agent, and every configured notification recipient for that tenant receives an alert email listing it.
The check has no awareness of planned maintenance windows — it only measures elapsed time since the last successful poll.
- A short maintenance window (well under 30 minutes) will typically resolve before the next hourly check runs and never surface at all.
- A longer one will not, and that is expected behavior rather than a false positive to chase down.
Rolling a fleet-wide change across many machines at once multiplies this — for example a reboot cycle, a network re-architecture, or a bulk reinstall. Every machine down for more than 30 minutes at the top of an hourly check window generates its own line in that tenant’s alert email.
This is expected under the circumstances, not a symptom of anything wrong with the agents themselves, but it is worth knowing in advance so the alert is recognized for what it is rather than treated as an incident.
Enroll every machine with a descriptive name
During device-pairing enrollment, the admin completing the pairing step gives the file server a name that is stored separately from its reported hostname. That name field is pre-filled with the machine’s hostname but is editable at the moment of enrollment.
It is this name, not the hostname alone, that appears first and in bold in the stale-agent alert email, alongside the hostname, reported agent version, and last-seen time.
On a single-machine deployment this distinction rarely matters. Across a larger fleet, machines are prone to receiving generic or near-identical hostnames, which makes an alert listing several stale machines by hostname alone genuinely hard to act on quickly. Common culprits include:
- Sequential asset tags
- Default NAS naming
- Whatever a base image happened to assign
Taking the time to give each machine a real, site- or role-specific name at enrollment (for example, a branch name and its function rather than an asset tag) is what makes a future stale-agent alert immediately actionable rather than a hostname someone then has to go look up.
See Agent: Install & Enrollment for the full pairing flow this naming step is part of, and Agent: Updates & Lifecycle for how the same 60-second poll loop also drives the agent’s self-update checks.