VMS Design Guide

Notes to presented VMS designs:

This guide presents the VMS implementation designs that are recommended for the most typical installations. In addition to these typical implementation designs, it is of course possible to design and implement the VMS in other ways to suit specific needs.

Server specifications:

To get server recommendations for specific projects, use the XProtect Server Calculator (Note: requires a My Milestone login).

Standard system designs guide

When deciding how to implement the VMS, the first things to consider are the physical location of the sites that should be surveyed, where the users of the VMS are located, and the quality of the network infrastructure if the installation covers multiple physical locations.


For typical VMS installations, this design guide can help to choose the recommended way to implement the system.

Note: The ‘Number of cameras’ decicion limits are based on cameras set to: H.264/H.265, 1080p, 25/30 FPS and a bitrate of 3-5 Mbit/s.

  • With lower resolution/bitrates, the limits will be higher

  • With higher resolution/bitrate, the limits will be lower

Design 1 – Single system - Less than 100 cameras / Demo system

This VMS design is the simplest possible design where everything is connected to the same network and all server components, and maybe even the clients, are installed on the same computer.

Typically, for real-world usage, it is recommended that the VMS servers and VMS clients are installed on separate computers. However, if the computer is powerful enough, everything could be installed on the same computer – for instance, a laptop to try out or demonstrate the XProtect VMS.

Design 2 – Single system - Up to 300 cameras

With this design, the recording server is installed on a dedicated server to ensure optimal performance. To provide live and recording capabilities in scenarios where the recording server has failed or is stopped for maintenance, a failover recording server can be added.

Design 3 – Single system - More than 300 cameras

Note: When the system is larger than ~300 cameras, it is recommended to run the SQL server on a dedicated server and use either the Standard or Enterprise edition of the SQL server.

Furthermore, with many cameras in the system, it is recommended to separate the network into a ‘client network’ and a ‘camera network’.

Separating the camera network from the client network increases performance, stability and security and furthermore makes it easier to dimension the network.

  • Performance is increased by separating the traffic to and from recording servers so any high load on the client network does not impact the recording performance

  • Stability is increased because any network interference on the client network does not affect the camera network

  • Security is increased because the cameras are protected behind the recording servers, and they can therefore not be accessed, hacked, or blocked by users or other equipment connected to the client network

  • Dimensioning of the network is made easier because the load is separated into several different network segments where the load, especially on the critical camera network, can easily be calculated

Design 4 – Single system, multiple sites. No direct user access in remote sites

This design is essentially the same as design 3. The only difference is that the cameras and recording servers are located on physically remote sites, and not on the main site where the management server and the VMS users are located.

The advantage of this design is that the bandwidth from the remote sites to the central site can be much lower compared to recording all cameras from the remote sites on the central site. Basically, the network requirements are set by the number of cameras from the remote site that must be viewable at the same time by the clients on the central site.

An example with some requirements to illustrate it:

  • Each site has one recording server that records 100 cameras at: 1080p, 25/30 FPS, 4 Mbit/s, H.264/H.265

  • The users on the central site must be able to view a maximum of 10 cameras at the same time for each remote site

If the recording servers were placed on the central site, as shown on the previous design 3, a bandwidth of 100 * 4Mbit/s = 400 Mbit/s would be needed 24/7 from each remote site to the central site.

However, by placing the recording servers at the remote sites, only the bandwidth for cameras actively viewed by in the clients on the central site are needed. With a maximum of 10 cameras viewed, only 10 * 4Mbit/s = 40 Mbit/s are needed – and furthermore, this is only during periods where the cameras are viewed in the clients.

Should failover functionality be needed, it is recommended to place a failover recording server on each remote site to contain the traffic to the remote site in case of failure.

Design 5 - Multiple systems, multiple sites. Direct user access to remote sites using Milestone Federated Architecture

In a geographically distributed VMS system, where the network connection is stable and where users must access video locally on each of the remote sites, it is recommended to design the system using Milestone Federated Architecture.

Milestone Federated Architecture offers several advantages:

  • Independent design and configuration

    • Each site can be designed independently, only taking the number of cameras and user requirements on the individual site into consideration

    • Each site are configured independently, keeping the complexity of the overall system low

    • User and administrator permissions can be set per site

  • Seamless access

    • Users located at the central site can access the entire federated system seamlessly via a single log-in

    • Local users on the remote site can access the system on their site even if the connection to the central site is broken

For more information: White Paper - Milestone Federated Architecture

Design 6 – Multiple systems, multiple sites. Direct user access to remote sites using Milestone Interconnect

In a physically distributed VMS system, where there is a need for accessing video locally by users on remote sites and where the network connections between the remote and central sites may be unstable or have limited bandwidth, it is recommended to use Milestone Interconnect.


Secondly, if the remote sites are on different domains, or maybe even use workgroups, it is also recommended to use Milestone Interconnect as it is domain agnostic. This means that any combination of domains and workgroups between the central and remote sites is supported.

Furthermore, Milestone Interconnect supports interconnecting all of the XProtect VMS products - except the free XProtect Essential+ product.

Milestone Interconnect offers several benefits:

  • Independent design and configuration

    • Each site can be designed independently, only taking the number of cameras and user requirements on the individual site into consideration

    • Each site can be configured independently, keeping the complexity of the overall system low

    • User rights can be set and controlled per site

  • Seamless access

    • Users on the central site can access the central and interconnected remote sites seamlessly via a single log-in

    • Local users on a remote site can access the system on their local site even if the connection to the central site is not working

  • Flexible recording

    • In case the connection between the central site and remote site has been lost for a period and then later restored, the central site can automatically retrieve recordings made on the remote system during the period with network outage. This could for instance be used for surveillance in vehicles like cars, buses, trains, airplanes and ferries

    • In addition to automatic retrieval upon network reconnection, the system offers user-activated, rule-activated, scheduled, and MIP SDK-activated retrieval of recordings

    • Alternatively, instead of recording or retrieving recordings on the central site, the interconnected systems can be configured so clients on the central site play back recordings directly from the remote sites without first having to transfer them to the central site

  • Resilient

    • With Milestone Interconnect, the system can handle unstable and intermittent network connections between the central and remote sites without impacting client log-on time, performance or management of the central or remote site

For more information: White paper - Milestone Interconnect