Page tree
Skip to end of metadata
Go to start of metadata

Scalability is largely determined by how many devices can be maintained simultaneously in a managed environment. A standalone FileWave Server can support a limited number of devices. Linux and macOS-based FileWave Servers can support between 1000-1500 desktop/laptop devices, and a Windows server can reliably support only about 500 devices (due to a problem with Apache and web services in Windows not playing well together). Because the Filesets sent to iOS devices usually consist of either profiles or URLs to the iTunes/App Store. The amount of data sent from the FileWave Server is a lot less with iOS devices, so a FileWave server can support many more iOS devices than it can computers.

If you also include Apple caching servers into your environment this will then allow iOS and MDM enrolled macOS devices to download VPP apps from your Apple caching servers instead of having to leave your network to get them.

Some rules-of-thumb for Booster planning:

  1. A Booster should be configured for every set of 2,000 or fewer devices.
  2. A Booster should be configured to support every physical location, such as a building, campus, or city.
  3. If there are multiple locations in a given geographic area that is removed from the data center hosting the FileWave Server, each of the location Boosters should connect to a central area Booster; e.g., city A has an area Booster, sites 1 – 4 each has at least one Booster, that is connected to Booster A, which in turn is connected to the FileWave Server.


The end result of the configuration model above is that each of the sites has between 1-3 FileWave Boosters, some of which are serving a couple of locations due to lighter loads, and some are consolidated into a "round-robin" load balancing cluster. There are a series of Boosters directly connected to the FileWave server to begin spreading out the load, then those Boosters provide Filesets to the individual site Boosters.

Boosters and Imaging

Since FileWave v9, Imaging has been able to take advantage of Boosters. Images are stored as Filesets, and as such, can be cached on Boosters. When you create an Image Fileset to use in deployment, the Imaging Virtual Server (IVS) handles the network boot drive for PXEboot; but the Image Fileset that is used in the deployment is stored at the main FileWave server - unless there is a Booster on the subnet where the IVS resides. In that case, the original Fileset will remain on the main server; but the Image Fileset that is used for the imaging process will come from the Booster on that subnet.