Prepare Virtual Machines for Omnissa Access Installation

This preparation phase ensures that all virtual machines, networking, certificates, and infrastructure prerequisites are prepared before you start a Control Plane-based deployment of Omnissa Access.

In this deployment model, platform and application services are deployed across dedicated virtual machines and orchestrated through the Control Plane framework. All required virtual machines and supporting infrastructure must be provisioned and validated before beginning the deployment workflow.

NFS storage is required if you plan to configure a disaster recovery (DR) site for your deployment. See Configure Disaster Recovery for Omnissa Access for prerequisites.

Deployment Topology Requirements

The deployment model uses dedicated virtual machines for bootstrap, infrastructure/platform services, and Omnissa Access services.

A standard production deployment consists of the following nodes:

Important:

• All virtual machines must be deployed and accessible before starting the installation workflow.
• Static IP addresses, DNS records, and hostnames must be configured for all nodes.
• The configuser password must be configured consistently across all nodes.
• Default password expiry of configuser is 60 days from the date of the OVA deployment. You must reset the same password across all cluster nodes.
• After Control Plane bootstrap and cluster initialization are completed, changing node roles or deployment topology is not supported.
• All nodes must be able to communicate with each other over the required network ports.
• A load balancer must be configured in front of the Omnissa Access Nodes before deployment.

Hardware Sizing Requirements

The following sizing applies to Control Plane-based deployments of Omnissa Access only.

Choose a deployment size based on the number of users, groups, and applications in your environment.

The following table shows the minimum hardware configuration required for each deployment size.

Minimum Hardware Configuration by Deployment Size:

¹ Infrastructure/Platform Nodes host internal platform services including database, messaging, caching, and search (PostgreSQL, Redis, Kafka, and OpenSearch).

*The Bootstrap Node requires exactly 8 vCPUs regardless of deployment size.

Important:

• Resource sizing may vary depending on authentication load, enabled services, and integration requirements.
• Additional storage allocation may be required based on logging, audit retention, and operational requirements.

Infrastructure Setup Guidelines for High Availability

To ensure the system stays up and running even if something goes wrong, follow these rules when creating virtual machines (VMs) for Infrastructure and platform.

Run each node on a different physical machine (ESX Hosts) For example, if you need three Infrastructure/Platform nodes and two Omnissa Access nodes, place them as such:

• Bootstrap Node → Physical Host 1
• Infrastructure/Platform Node 1 → Physical Host 1
• Infrastructure/Platform Node 2 → Physical Host 2
• Infrastructure/Platform Node 3 → Physical Host 3
• Omnissa Access Node 1 → Physical Host 1
• Omnissa Access Node 2 → Physical Host 2

With this approach, if one physical host goes down, the service can still run using the other two, keeping your system available and stable.

Requirements for All Nodes

Download the Omnissa Access OVA from Omnissa Customer Connect page and select Omnissa Access. After you download the file, deploy all the virtual machines as described in Deploy the Virtual Machines for Omnissa Access Installation

Ensure that the following requirements are completed for all nodes before deployment:

• Static IP address assigned.
• Hostname configured correctly.
• DNS resolution configured.
• All nodes reachable from each other over the network.
• Load balancer configured and reachable. See Using a Load Balancer or Reverse Proxy to Enable External Access to Omnissa Access for configuration requirements.

The objective is to ensure that the operating system and base infrastructure are fully prepared and do not interfere with Platform services during deployment.

Certificate Requirements

A TLS certificate is required for the Omnissa Access deployment FQDN:

• PEM format .pem.
• CN must match the primary tenant FQDN.
• The certificate must include the following Subject Alternative Names (SANs), where example.com is replaced with your deployment domain:
  • tenant.example.com
  • tenant-cert.example.com
  • tenant-amsso.example.com

Wildcard certificates are supported if they satisfy the required SAN entries. Self-signed certificates are also supported.

The certificate and private key files are required during deployment configuration.

Network Configuration Requirements

Unified Access Gateway supports reverse proxy functionality to allow users to access the Omnissa Access unified catalog remotely and securely. Unified Access Gateway can be deployed in the DMZ behind the load balancers that is front-ending the Omnissa Access appliance.

Port Requirements

To determine which ports are needed for this Omnissa Access release, see the Omnissa Access Ports and Protocols page, where you can use the filters, such as the Version filter to customize the list to your needs.

Important:

• Ensure that required firewall rules are configured before deployment.
• Internal platform ports must be accessible between infrastructure and Omnissa Access Nodes.
• Public-facing ports should be exposed only through the load balancer or reverse proxy.
• Port exposure may vary depending on deployment architecture and security requirements.