Zoom Node Post-Deployment Configuration and Management

Complete this section after deploying your hypervisor solution to configure network settings, manage certificates, and more.

After deploying Zoom Node to a hypervisor environment, configuration begins with the terminal user interface (TUI), where administrators complete essential platform setup tasks such as setting system passwords and enabling network interfaces.

Once the initial configuration is complete, platform management transitions to the Zoom Node web GUI, which provides a centralized interface for advanced operations. From this interface, administrators can configure detailed network settings, register the Node with Zoom, manage certificates, and deploy functional modules.

Each step within the configuration workflow is described in this section, and this workflow supports deployments that are secure, scalable, and aligned with your policies.

Initial platform configuration via console and web GUI

Zoom Node configuration begins through the hypervisor console, where administrators configure a secure password and hostname. After this initial setup, you’ll use the local web GUI for network configuration, static IP assignment, and platform registration.

This section walks through the full setup workflow to prepare the Node for service deployment.

Console Access and Initial Setup

To configure Zoom Node:

  1. Access the console of the Zoom Node VM through the Hypervisor console.

  1. The Node will boot and wait for a new password to be configured.\

You may need to hit ESC a couple times to get back to this screen if invalid characters have been sent to the console.

  1. Enter a password which meets the following requirements:

    1. 8-16 characters with a number

    2. A symbol from these choices ( ! . @ % # * _ ~ ?)

    3. An uppercase letter and a lowercase letter

  2. Enter the password a second time.

The username used for local access is zoom-setup (lowercase and hyphenated). This username will be required for Local GUI or console access.

  1. Select Enter to change the hostname.\

  2. Enter the Fully Qualified Domain Name (FQDN), which is the hostname and any domain suffix.

    1. In this example, the Node is named zn-sjc-zn01.localdomain.com.

This FQDN will be used for certificate management and to name the Zoom Node in the Zoom admin portal. If you plan to use your own certificates rather than Zoom’s automatically managed certificates, then this FQDN must exactly match the CN or SAN in the certificate.

  1. Select Enter to accept the name.

  2. Select the ESC key twice to get back to the main menu. The screen will look similar to the following image:\

The IP addresses can be configured either using the console Text User Interface (TUI) or via the local Graphical User Interface (GUI, aka the web portal) using a browser once the Node has an address assigned to it.

In the screenshot above, the Zoom Node has been deployed on a network with a DHCP server and been given the IP address 10.15.1.126.

If no DHCP server is available on the subnet, then the first address must be manually configured via the TUI. You can then configure subsequent addresses using either the TUI or GUI.

Network Configuration

Zoom recommends using the local GUI as a simpler method. To configure with the local GUI:

  1. Browse to the URL displayed in blue on the Zoom Node console page.

    1. In the previous section's example, it was: https://10.15.1.126:8443.

  2. Accept the self-signed certificates.

  3. The Zoom Node login screen appears.\

  4. Enter the password set in the TUI.

  5. The Node Local Admin Portal dashboard appears.\

  6. Click Network on the left-hand side of the screen.\

  7. Click the Configure button to modify network settings.

A Zoom Node will use up tofive (5) IP addresses, one for the Node OS and one for each service deployed on the Node. Zoom Node can share the OS IP address with the first service deployed. Depending on the purpose of this Zoom Node, between one (1) and five (5) IP addresses will be required. For example, Zoom Meetings Hybrid requires a minimum of two (2) per Node (1 ZCP + 1 HMMR) and up to five (5) (1 NodeOS + 1 ZCP + 3 HMMRs).

In this example, DHCP has automatically assigned the first IP address. It is highly suggested to give the Zoom Node static IP addresses to ensure it doesn’t change if the DHCP server gives out a different one in the future.

Because you’re actively communicating with the Zoom Node local GUI on the IP address assigned by DHCP, you can’t remove it. That would disconnect you from the Node. You must add the other addresses first, then you can connect to the GUI using the new IP and remove the DHCP IP after.

Adding additional IP Addresses

To add additional addresses:

  1. Click the plus button above IP Address 1.

  1. Enter the new IP address in the CIDR format.

    1. The CIDR format includes the subnet mask at the end, in slash notation. Example: /24 equates to 255.255.255.0; /23 is 255.255.252.0; /16 is 255.255.0.0; and so on.\

  2. Click Add to enter the address.

  3. (Optional) Repeat this process for as many IP addresses as you need.

  4. Once the IP addresses are added, click Save to apply the addresses to the Zoom Node.\

  5. Review the Network tab of the dashboard, and under the Interface tab you’ll see all added IP addresses.\

Connect to the New IP Address

After adding the four static IP addresses, the old DHCP address is assigned to the Node in the list.

Before removing the DHCP address, you need to connect to one of the static assigned IPs. In the following example, the primary address will be 10.15.1.90.

To connect:

  1. Modify the URL in a browser window to use the new IP address. Connect to: https://10.15.1.90:8443.

  2. Accept the self-signed certificate to connect.

  3. Enter the password you assigned to the Node.

  1. The main menu will appear again.

  2. Click Network from the left-hand side of the screen.\

  3. Click Configure.

  4. Search the list for the IP address assigned via DHCP.

  5. Click the - (minus) button next to the DHCP address to remove it.

  6. Click Delete to confirm.

  7. Click Save to apply the IP address settings.

In the following example screenshot, we now have the four static IP addresses we want assigned to the Node.

Optionally, you may configure other network settings such as DNS, proxy server settings, or additional Network Interfaces.

Be aware that Zoom Node will automatically look for additional NICs assigned to the VM and allow configuration if a multi-NIC deployment is desired.

Platform Registration

As mentioned earlier in the Field Guide, you’ll need to ensure that your vanity URL was approved by Zoom Support and applied to your account. This is mandatory.

To determine if you have a Vanity URL assigned, log in to the Zoom admin portal. Click on Account Management > Account Profile and then scroll down to the Vanity URL section.

Next, ensure that the network and firewall rules are in place to let Zoom Node communicate with Zoom’s cloud per the stated prerequisites in this document.

To determine if Zoom Node has sufficient connectivity to Zoom’s cloud, click the Diagnostics menu from the Zoom Node Local GUI:

The above screenshot shows that Zoom Node has full connectivity and is ready to be registered to the Zoom cloud.

Now, you’ll create a registration code. Log back in to the Zoom admin portal.

From the main page, scroll down and click the Node Management drop down under the Admin section. Click Modules. Then, click the Nodes tab at the top of the screen.

By default, the Zoom Node - Meetings Hybrid section appears. You can click that module name at the top of the screen, which acts as a drop-down list. Then, you can select additional Service Modules as necessary.

The Zoom Node needs to be deployed under the appropriate module family. For example, if you’re deploying a Recording Hybrid module, it belongs to the same family as the Meetings Hybrid module. That allows them to be deployed on the same Zoom Node with reduced capacity.

It is important to understand that, currently, a single Zoom Node cannot run modules from different families at the same time. A single Zoom Node VM can only serve a single module family type like Meetings Hybrid or Team Chat Hybrid.

Reviewing the Running Node Agent

After setup, Zoom Node must be confirmed as active and registered in the Zoom admin portal. The Node Agent status can be verified from the local GUI, while final registration occurs in the portal’s Unconfirmed Nodes section. Once confirmed, the system automatically installs the required agents to complete activation.

To confirm Zoom Node is active:

  1. Click Home on the left-hand side of the screen.

  2. Under the Service Status section, you’ll see that the Node Agent is running.

  1. Click your open Zoom admin portal tab. If it was still open from the previous step, you’ll see the Generate Code screen.

  2. Click the < Back link at the top of the page to return to the list of Nodes.

  3. (Optional) Otherwise, browse to the Nodes section of the admin portal.

  1. Review the Unconfirmed Nodes tab at the top of the screen. Notice that there is now a little red dot next to Unconfirmed Nodes showing that a new Node was registered. It needs confirmation.

  2. Click the Unconfirmed Nodes tab.

  3. Verify if the Node name and IP addresses are correct for the new Node.

  1. Click the Confirm button when ready.

  2. A new dialogue window appears.

  1. (Optional) Enter a description of the Node if desired.

  2. Click the Node Location field and enter the physical location of the Node.

  3. Click Confirm.

The Node will now disappear from the Unconfirmed Nodes page.

On the main Node page again, click the Confirmed Nodes tab at the top of the screen to see the Node listed.

The Node is now registered to the Zoom Cloud. Once the Node is registered, it will begin a procedure to push the latest Node Agents to the system. This can take up to five (5) minutes.

You can click the Zoom Node name to get details about the agents. This may take several minutes. Wait a few minutes and return to or refresh the page to check the status.

Once all three agents are installed and running, the Node confirmation is complete.

Certificate Management (BYOC)

If you choose to provide your own certificates rather than using Auto-PKI, then you must enroll the certificates by accessing the Zoom Node Local GUI. You have the option to either generate a Private Key and a CSR file for signing by a publicly trusted CA, or you can import your own Private Key and certificate generated elsewhere and signed by the publicly trusted CA.

You should have a browser tab open to your Zoom Node local GUI if you followed the previous setup and configuration instructions.

You can also browse to https://<NODE IP>:8443 to login.

Authenticate using the credentials established during Node deployment. The username is zoom-setup, and the password is your configured password.

Enrolling the Certificate

To deploy and enroll your certificate:

  1. Click Certificate on the left-hand side of the screen.\

  2. Click Upload your certificate to begin the enrollment process.

    1. No uploads will occur just yet.\

  3. Under the Certificate section, choose a method to provide the certificate.

If you are unsure which option to choose, contact the security team that handles certificates for your organization. It is a more common workflow for individual servers to generate a CSR, have it signed, and then upload the certificate to the server. If you already have a private key and certificate which has been signed and meets the requirements, you can upload them directly.

Certificates for Zoom Node must be Base-64 encoded and typically have an extension like pem, cer or crt). The files are editable in a text editor and will include headers like the following:

-----BEGIN CERTIFICATE-----

Example image:

Guidance on both options follows below.

Option 1: Upload an Existing Certificate and Private Keypair

The following screen appears after selecting this option:

Next, you must provide three files for upload for each section prompt:

  • Select the server CRT file: This is the base-64 encoded server certificate itself.

    • This server certificate will be a single block of text that has a ----BEGIN CERTIFICATE---- header and an ----END CERTIFICATE---- footer.

  • Select the private key file: This is the private encryption key the server uses.

    • The confidentiality of this file is paramount. Do not share it.

  • Select the trustchain CRT file: This file contains any intermediate and root certificates that your server CRT was signed with from the public CA.

    • Sometimes a certificate chain can include the server cert portion. You will only use all the intermediate and root certs in this file, but not the server portion.

A single certificate file often contains the server certificate, followed by the intermediate(s) and root in a chain. You will need to use a text editor to separate the server certificate (typically at the top) from the rest of the trust chain. This will produce two certificate files (one for the server and one for the trust chain) and a single private key file.

Option 2: Generate a Certificate Signing Request (CSR)

The following screen appears after selecting this option:

  1. Complete all fields with your organization’s information.

    1. Recall it is critical to have any SANs included in the CSR before it is signed.

  2. Click Next.\

  3. Click the Download CSR File button.

  4. Click the Download Private Key File button.

The CSR needs to be sent to the publicly trusted CA for signing. Once it has been signed, you may continue the process.

  1. Scroll down to the next section.\

Next, you must provide three files for upload for each section prompt:

  • Select the server CRT file: This is the base-64 encoded server certificate itself.

    • This server certificate will be a single block of text that has a ----BEGIN CERTIFICATE---- header and an ----END CERTIFICATE---- footer.

  • Select the private key file: This is the private encryption key the server uses.

    • The confidentiality of this file is paramount. Do not share it.

  • Select the trustchain CRT file: This file contains any intermediate and root certificates that your server CRT was signed with from the public CA.

    • Sometimes a certificate chain can include the server cert portion. You will only use all the intermediate and root certs in this file, but not the server portion.

A single certificate file often contains the server certificate, followed by the intermediate(s) and root in a chain. You will need to use a text editor to separate the server certificate (typically at the top) from the rest of the trust chain. This will produce two certificate files (one for the server and one for the trust chain) and a single private key file.

Last updated

Was this helpful?