Skip to main content

Booster Deployment Planning

What a Booster changes

A FileWave Booster caches Filesets and application installers closer to macOS and Windows clients. This can reduce load on the FileWave Server, avoid repeatedly moving the same large content across a WAN or VPN path, and improve deployment performance at distributed locations. Boosters are optional for both FileWave-hosted and self-managed environments.

Use the right cache for the content. A Booster can also cache Microsoft OS updates and patches for Windows devices. For Apple-distributed OS updates, upgrades, and apps on macOS, iOS, iPadOS, and tvOS, use Apple Content Caching.

Plan around network paths and active connections

Do not size a Booster from total fleet count alone. Consider how many clients may request content at once, the size and frequency of Filesets or Windows updates, available disk space, the Booster host platform, and the WAN path between clients, Boosters, and FileWave Server.

  • Use the platform connection limit as a ceiling, not a fleet-size promise. macOS and Windows Boosters support up to 400 active client connections; Linux Boosters support up to 2,000. When a Booster reaches its connection limit, a client tries the next Booster in its configured list and ultimately falls back to FileWave Server.
  • Place content near constrained network paths. A campus, branch office, building, city, or VPN population may need a local Booster when repeated downloads would otherwise cross a slow or costly link. Smaller locations can share a Booster when the network route and measured load make that practical.
  • Plan for remote clients deliberately. If off-LAN clients should use a Booster, provide a reachable Internet-facing Booster and include safe fallback targets. Do not assume an internal site Booster is reachable from home networks.
  • Size storage for real content. Include the largest Filesets, Windows update cache, and Image Filesets you expect the location to request. Monitor disk growth rather than relying only on a device count.

Build an ordered Booster tree, not DNS round-robin peers

For distributed environments, configure each site Booster with an ordered upstream list. The first entry is normally an area Booster or FileWave Server. Additional entries can provide upstream fallback, and FileWave Server should be the final entry when it is not already first.

Do not point peer Boosters at one another through DNS round robin. That design can leave Boosters asking each other for content none of them has. Clients already move to the next configured Booster when one is unavailable or at its connection limit.

Example topologies

  • School or branch: Put a local Booster on the site network when it avoids repeated WAN transfers. A Linux Booster may serve up to 2,000 active connections; macOS and Windows Boosters have a 400-connection limit. A smaller site may share an upstream area Booster if network performance is acceptable.
  • Multi-site organization: Local Boosters can connect to a regional Booster, which then connects to FileWave Server. Keep the main server as the last upstream fallback and monitor each tier for overload and storage pressure.
  • Remote workforce: Assign reachable Internet-facing Boosters in a deliberate order, then retain FileWave Server as fallback. Test the path from an external network rather than validating only from the office.

Validate before broad rollout

  1. Pilot one representative location or client group.
  2. Deploy a realistically large Fileset or Windows update. The first requesting client may wait while the Booster fills its cache; later clients should receive the cached content locally.
  3. In FileWave Central, monitor requests per second, Booster overload, check-in state, and available storage while the pilot runs.
  4. Confirm that clients try the next configured Booster or FileWave Server when the preferred Booster is unavailable or reaches its connection limit.
  5. Adjust placement, host platform, storage, or upstream order from measured results before expanding the deployment.

Boosters and Windows Imaging

Windows Image Filesets can be cached on Boosters. The Imaging Virtual Server (IVS) handles the PXE network-boot environment, while the Image Fileset remains sourced from FileWave Server. When a Booster is available on the IVS subnet, the IVS can receive that cached Image Fileset from the local Booster instead of transferring it across the network from the main server. Allow enough storage for image content and avoid throttling the Booster-to-IVS transfer unless the network design requires it.

Related content

No comments to display

Back to top