Installing Omnissa Access

To deploy Omnissa® Access™ on the Control Plane, follow the instructions provided in this guide.

This Installing Omnissa Access section of the Installing and Configuring Omnissa Access guide walks you through the end-to-end process for deploying Omnissa Access in your environment. It includes a deployment overview, a description of the platform components that make up an Omnissa Access cluster, the supported deployment architecture, and a phased installation sequence that takes you from initial virtual machine preparation through tenant creation — either with the guided Access Wizard or, if you prefer direct control over each step, manually.

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.

After you complete the installation, the guide continues with configuration and management topics that help you prepare and operate your deployment.

After you complete the configuration, you can use the Omnissa Access console to manage users and groups, set up and manage authentication and access policies, and add resources to the catalog and manage entitlements to those resources. You can also configure Workspace ONE UEM integration, and launch Hub Services.

Architecture Overview

Omnissa Access runs as a set of containerized microservices managed by the Control Plane. The services that make up Omnissa Access are distributed across a cluster of dedicated virtual machines, all running AlmaLinux 9.6, and are deployed and operated as independent workloads. Because each service runs on its own, services can be updated, restarted, scaled, and recovered individually.

The Control Plane

The Control Plane is the platform that installs, runs, scales, and monitors the services that make up an Omnissa Access deployment. It coordinates every service in the cluster using three platform services:

• Nomad schedules and orchestrates the service workloads.
• Consul provides service discovery and secure internal communication between services.
• Vault stores and manages secrets, certificates, and tokens.

Service categories

An Omnissa Access deployment is made up of three categories of services:

Node types

An Omnissa Access cluster is built from three types of virtual machine, plus a load balancer:

• Bootstrap Node — the deployment controller. You run the WSO CLI from this node to deploy and operate the cluster.
• Infrastructure/Platform Nodes — host the Platform services and the Infrastructure services.
• Omnissa Access Nodes — host the Omnissa Access services. Platform services also run on these nodes.
• Load Balancer — distributes traffic across the Omnissa Access Nodes and provides high availability for the Access services.

Platform services run on both the Infrastructure/Platform Nodes and the Omnissa Access Nodes, so orchestration, service discovery, and secrets management continue to function across the whole cluster rather than depending on any single node.

The WSO CLI

The WSO CLI (Workspace ONE Command-Line Interface) is the primary interface for deploying and operating Omnissa Access. You run WSO CLI commands from the Bootstrap Node.

Deployment Overview

Omnissa Access is deployed on the Control Plane platform in multiple phases. Each phase depends on the successful completion of the previous phase.

Deployment Phases

1. Prepare virtual machines.
2. Deploy the virtual machines.
3. Deploy Omnissa Access — choose one:
   • Option 1: using the Access Wizard.
   • Option 2: manually, step by step.

Deployment Architecture

Ensure that the following architecture-related details are met, as required for Omnissa Access:

• Required Virtual Machines

  Node Type	Count	Purpose
  Infrastructure/Platform Nodes	3	Infrastructure services
  Omnissa Access Nodes	2 for small and medium 3 for large	Access application services
  Bootstrap Node	1	Deployment controller
  Load Balancer	-	For HA of Access services

  Note: Platform services run on both the Infrastructure/Platform Nodes and the Omnissa Access Nodes.

• Service Placement

  Node	Services
  Infrastructure/Platform Nodes	Nomad, Consul, Vault, Postgres, Redis, Kafka, OpenSearch
  Omnissa Access Nodes	Nomad, Consul, Vault, Access services
  Bootstrap Node	Deployment/Administrative Operations

  Ensure that all nodes meet the following requirements:

  • Run AlmaLinux 9.6
  • Have static IP addresses
  • Have unique hostnames
  • Have SSH access from the bootstrap node

• Load Balancer Configuration

  Configure your load balancer and add your access service nodes upstream, enabling the load balancer to redirect to any of the nodes. See Using a Load Balancer or Reverse Proxy to Enable External Access to Omnissa Access for configuration requirements.

• DNS Resolution

  • DNS entry: Ensure that a DNS entry resolves to FQDN IP (Load Balancer IP).

    tenant.example.com

• Certificate Requirements

  • Common Name (CN): Load balancer hostname (tenant.example.com).

  • Subject Alternative Names (SANs):

    • Examples:
      • tenant.example.com
      • tenant-cert.example.com
      • tenant-amsso.example.com

    Ensure that the domain portion of all SAN entries matches the domain used by the load balancer and cluster nodes.

    Notes:

    • You can choose to use a wildcard certificate, such as *.example.com to cover all SANs.
    • If you are not using certificate-based authentication, tenant.example.com is the only required SAN. You can omit tenant-cert.example.com and tenant-amsso.example.com.

  CSR Reference

  Use one of the following configurations depending on your certificate type.

  Wildcard certificate

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = *.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = *.example.com
  

  Non-wildcard certificate (all SANs required)

  If you are not using a wildcard certificate, list each Subject Alternative Name explicitly.

  [ req ]
  default_bits       = 2048
  prompt             = no
  default_md         = sha256
  distinguished_name = dn
  req_extensions     = req_ext
  
  [ dn ]
  CN = tenant.example.com
  
  [ req_ext ]
  subjectAltName = @alt_names
  
  [ alt_names ]
  DNS.1 = tenant.example.com
  DNS.2 = tenant-cert.example.com
  DNS.3 = tenant-amsso.example.com