Planning and prerequisites for Enhanced Room Management
This topic contains useful planning and prerequisite information that should be understood before you install ERM. It covers:
- Understanding the Virtual Machine and ERM components
- Network interface setup
- Network schematics
- Server specifications
- Firewall ports
- LDAP authentication
The ERM product is deployed as a Virtual Machine within an on-premises IaaS environment (VMware or Hyper-V) or to a cloud provider (Azure or GCP). You can deploy the ERM VM in one of two modes:
- Online: it is deployed as a single VM with access to the Internet and the ERM online licensing and upgrade servers. The VM also provides the main ERM functions.
- Offline: it is deployed as two VMs — a secondary VM that has access to the Internet to activate licenses and fetch upgrades, and a primary VM that is "air-gapped" from the secondary VM and the internet and that provides the main ERM functions. There is no difference in the VM images you deploy, just in the way you configure and use them.
The ERM VM performs several functions using different services:
ERM Installer: allows administrators to set up and configure the ERM product. The primary purpose of the installer is to enable the deployment, configuration and updating of the main ERM modules.
Currently, there is only one module, the core Enhanced Rooms Management application. Pexip intends to release additional modules in due course.
The installer is used to deploy ERM modules directly within the same VM or to create "offline bundles" for use within a second air-gapped VM. In addition, the administrator can activate a license key (enabling specific modules and features), set basic network details (such as FQDNs), configure TLS certificates, and define an LDAP connection for AD multi-user login, and to manage upgrades of the various modules.
Enhanced Rooms Management application: within this module, there are two separate functions:
- ERM GUI: provides the primary user interface for support personnel to manage videoconferencing endpoints within their estate. For example, the administrator can add video systems, prepare configuration templates, monitor their usage, define firmware updates and address books, apply branding, etc.
- ERM API service: provides RESTful endpoints to allow the provisioning of supported Cisco videoconferencing devices and updates to phonebooks.
- Internal proxy service: handles the proxying of HTTP requests to the various ERM services. This service does not require manual intervention as it is automatically configured depending on how the administrator configures the ERM modules.
Note that the different functions of the ERM VM can be updated independently, therefore, they each have their own version numbering.
See ERM deployment overview for more information.
The ERM Proxy is a virtual machine that is installed separately from the rest of the Enhanced Room Management product suite. It allows an ERM server to provision multiple Cisco endpoints located on a private network, such as behind a firewall/NAT router, that would otherwise be non-directly contactable by ERM.
See ERM Proxy virtual machine for more information.
An ERM VM can be configured with either one or two network interfaces (NICs). The purpose of the NICs is to allow for a separation of network layer traffic. All transport layer ports and higher layer services are bound to both interfaces so all ERM services can be reached through either interface. The internal ERM proxy/routing engine uses the SNI (Server Name Indication) and the FQDN of the relevant ERM service supplied by the client, to route traffic to the correct service.
- Single NIC configurations: For a VM deployment that uses a single NIC, the first NIC handles all traffic (internal and external). A single IP address is assigned; however, different FQDNs can be applied to the different services, and the internal proxy/routing engine will route traffic appropriately using SNI.
- Dual NIC configurations: For a VM deployment with a dual NIC configuration. the first NIC is designed to handle all DMZ and public routed traffic, and the second NIC is designed to handle all internal traffic. However, there is no separation of services across the NICs, thus a service can be reached via either NIC. The intention is to provide more distinct routing capabilities.
ERM can be deployed in your network in a number of different ways that suit your organization.
This diagram shows a single VM and access control using a load balancer for external clients:
This diagram shows a single VM and access control using a load balancer for all clients:
Before you install the ERM Installer VM, please review the following recommended system requirements for a production use, single server/VM:
|Normal traffic installation||High traffic installation *|
<1000 concurrent call participants
<500 managed endpoints/devices
>1000 concurrent call participants
>500 managed endpoints/devices
100GB storage, SSD/SAN is recommended **
1x NIC, possibly behind firewall/reverse proxy
200GB storage, SSD/SAN based **
1x NIC, possibly behind firewall/reverse proxy
* For larger installations, contact Pexip for a customized deployment.
** In ERM installations, you need to take the disk space of firmware files into consideration. Each firmware version may require 1-2 GB of additional storage space.
We recommend using thick disk provisioning for your virtual machine, thin disk provisioning will also most likely work but use with caution.
As the ERM product has several functions within a single VM, you should define DNS FQDNs that can be used to access these services.
For example, for services that share the same listening port binding, a proxy service on the VM uses the TLS SNI header to determine which request should be directed to which service:
- The ERM Installer (such as erm-installer.example.net). This service binds to port 8999.
- The ERM core application management interface (such as erm-mgt.example.net). This service binds to ports 80 and 443.
- (Optional) The ERM API service for video endpoint API requests (for access control) (such as erm-api.example.net). This service binds to ports 80 and 443. Note that this service can be combined with and accessed using the ERM core application FQDN.
See Network schematics above for more information.
In addition to defining DNS FQDNs, TLS certificates should be used to secure the ERM services. You can use individual certificates, a single SAN certificate (combining all DNS FQDNs), or a wildcard certificate (which would secure an entire domain space, such as *.example.net).
See ERM certificate management for more information.
Configure firewall ports according to the ERM network port requirements.
You can optionally use an external LDAP / Active Directory database to authenticate users accessing ERM.
See LDAP authentication settings for more information.