This page describes greenfield deployment using Access Wizard 26.10.0. Access Wizard 26.10.0 supports greenfield deployment of Omnissa Access 26.10.0.0 with full feature support including password rotation, version display, and live-validated deployment workflow.
Phase 3, Option 1 - Deploying Omnissa Access Using the Access Wizard
As of release 26.07, access-wizard automates the Bootstrap node setup, Control Plane initialization, Control Plane deployment, Access and Infrastructure service deployment, and tenant creation steps into a single guided command. The wizard asks a short set of questions, writes the configuration files for you, and then runs the deployment stages in order. If you'd rather perform these steps individually, see Deploying Omnissa Access Manually.
Note: Access Wizard 26.10.0 supports a greenfield deployment of Omnissa Access 26.10.0.0. Updating an existing deployment and deploying later releases are outside the scope of this version.
Duration: Answering the questionnaire takes a few minutes with required information ready. The automated deployment that follows takes approximately 1.5 to 2 hours. The deployment is live-validated — a complete greenfield deployment was successfully tested with all 47 services becoming healthy.
Before You Begin
Confirm the following before you start:
- The Bootstrap, Infrastructure, and Omnissa Access virtual machines from Phase 1 - Preparing Virtual Machines for Omnissa Access Installation and Phase 2 - Deploying the Virtual Machines for Omnissa Access Installation are deployed and powered on.
- The load balancer is configured as described in Using a Load Balancer or Reverse Proxy to Enable External Access to Omnissa Access, with X-Forwarded-For headers enabled and listening on port 443.
- DNS for your tenant FQDN (for example,
tenant.example.com) resolves to the load balancer IP address. - You have the
configuserpassword that was set on every node during OVA deployment. See Managing Omnissa Access Control Plane Cluster Nodes if this password has expired or needs to be reset. - You have a TLS certificate ready, either self-signed (the wizard can generate one for you) or a full-chain PEM certificate and matching unencrypted private key from your own CA.
Notes:
- The wizard validates disk space and Docker storage on the Bootstrap node and checks SSH connectivity and authentication to every other node. It does not independently verify the CPU, RAM, or disk sizing of remote nodes — confirm those against the sizing table in Hardware Sizing Requirements before you begin.
- The Access Wizard RPM is digitally signed. Verifying the signature (see Trusting the Signing Key and Verify the RPM, below) is a separate check from the SHA-256 checksum verification in the next section — the checksum confirms the download wasn't corrupted, not that it's genuinely from Omnissa.
Step 1: Download and verify the Access Wizard
On your local machine:
- Sign in to Omnissa Customer Connect and download:
- The Omnissa Access asset bundle (ZIP file with Control Plane manifest and container images)
- The Access Wizard RPM bundle (ZIP file containing:
access-wizard-26.10.0.noarch.rpm,.sha256checksum file, andomnissa-linux-rpm-gpg-key.pub)
- Unzip the RPM bundle on your local machine:
unzip <wizard-bundle>.zip - Verify both files:
sha256sum -c access-wizard-26.10.0.noarch.rpm.sha256 sha256sum <asset-bundle>.zip
Do not proceed if either checksum does not match.
Step 2: Upload files to the Bootstrap node
On your local machine:
scp <wizard-bundle>.zip <asset-bundle>.zip \
configuser@<bootstrap-ip>:/home/configuser/
Then on the Bootstrap node:
ssh configuser@<bootstrap-ip>
unzip <wizard-bundle>.zip
Remain logged in as configuser. All subsequent commands use explicit sudo.
Step 3: Trust the signing key and verify the RPM
On the Bootstrap node:
Import the Omnissa RPM signing public key:
sudo rpm --import omnissa-linux-rpm-gpg-key.pub
Verify the RPM signature and integrity:
sudo rpm -K access-wizard-26.10.0.noarch.rpm
The output must indicate valid digests and signatures. Do not install if verification fails.
Step 4: Install the RPM
On the Bootstrap node:
sudo dnf install -y access-wizard-26.10.0.noarch.rpm
Step 5: Confirm installation
On the Bootstrap node:
sudo access-wizard --version
Expected output: access-wizard 26.10.0
Step 6: Start the guided deployment
On the Bootstrap node:
sudo access-wizard deploy --asset-bundle /<path>/<asset-bundle>.zip
The wizard displays a welcome screen listing the six questionnaire sections (Basic information, Tenant, Infrastructure nodes, Access nodes, Certificates, Optional services), then prompts you to press Enter to begin.
● OMNISSA ACCESS — Deployment Wizard
Official documentation (Omnissa Access)
• https://docs.omnissa.com/category/Workspace_ONE_Access_On-premises
View or copy all official documentation URLs: sudo access-wizard docs
-------------------------------------------------------------
Omnissa Access - guided deployment
-------------------------------------------------------------
Access Wizard 26.10.0
This wizard asks what it needs, writes your config files, and runs
the deployment in the right order. If a step doesn't validate, it
stops and tells you what to look at rather than pressing on.
There are 6 sections of questions.
The deployment itself takes about two hours. If your connection
drops during it, reconnect and run:
sudo access-wizard resume
It continues from the last completed deployment stage without asking the
questionnaire again.
1. Basic information
2. Tenant
3. Infrastructure nodes
4. Access nodes
5. Certificates
6. Optional services
Press Enter to begin.
Section 1: Basic Information
-
Review the EULA at www.omnissa.com/general-terms and accept it.
============================================================= Section 1 of 6: Basic information ============================================================= ------------------------------------------------------------- License agreement ------------------------------------------------------------- Before anything else, please read and accept the end user license agreement. Review it at https://www.omnissa.com/general-terms/ Do you agree to these terms? [Y/n]: EULA accepted <acceptance-timestamp> -
Confirm the asset bundle the wizard finds automatically. The wizard validates its integrity against a published checksum.
------------------------------------------------------------- Asset bundle verification ------------------------------------------------------------- ✓ Asset integrity <verification-detail> -
Deployment will be performed directly under.
/opt/wss/access.------------------------------------------------------------ Cluster ------------------------------------------------------------- Working directory: /opt/wss/access Your answers will be saved to /opt/wss/access/wizard.ini -
Choose the deployment size —
Extra Small,Small,Medium, orLarge. The wizard displays the node topology for each option.Note: As of release 26.10, a new deployment size of
Extra Smallwas added.------------------------------------------------------------- Cluster ------------------------------------------------------------- Working directory: /opt/wss/access Your answers will be saved to /opt/wss/access/wizard.ini What size deployment is this? Every deployment uses 3 Infrastructure nodes. The number of Access nodes and supported scale depend on the deployment size. Size Access nodes Users Groups Apps 1) Extra Small 2 100,000 1,000 50 2) Small 2 300,000 3,000 50 3) Medium 2 1,000,000 10,000 150 4) Large 3 1,000,000 20,000 500 Choose 1-4: 2 ✓ Deployment size Small Topology: 3 Infrastructure + 2 Access nodes -
As of release 26.10, the concept of deployment type was introduced. Specify a deployment type of
Production,UAT, orDevelopment.Note: A deployment type of
Productionrequires NFS. NFS is necessary for the ability to recover from a disaster.What type of deployment is this? 1) Production 2) UAT 3) Development Choose 1-3: 1 ✓ Deployment type: Production -
Confirm the Bootstrap node’s detected IP address.
------------------------------------------------------------- This node ------------------------------------------------------------- This looks like the Bootstrap node, with IP address <bootstrap-ip>. Is that right? [Y/n]: Y -
Enter the shared
configuserpassword. The wizard validates it immediately against the Bootstrap node. See Manage Omnissa Access Control Plane Cluster Nodes to reset this password if needed.------------------------------------------------------------- Credentials ------------------------------------------------------------- The credentials the cluster uses to reach every node. This is the configuser password you already set when you deployed the OVA. Not a new one. It must be the same on every node. Enter the configuser password:******** Enter it again to confirm:******** Validating configuser authentication on Bootstrap (<bootstrap-ip>)... configuser password validated against Bootstrap. -
Choose how the cluster authenticates to the other nodes: the password you just entered, or a generated SSH key pair.
It is suggested to use the option
ssh_keyfor cluster authentication. This method has the following benefits:- More secure
- No expiration (passwords rotate every 60 days)
How should the cluster authenticate to the Infrastructure and Access nodes? 1) password use the password you just entered 2) ssh_key generate a key and copy it to every node Choose 1-2: -
Enter the load balancer IP address, and X-Forwarded-For IP address if applicable to your deployment. The wizard checks port 443 connectivity.
------------------------------------------------------------- Load balancer ------------------------------------------------------------- The load balancer sits in front of your Access nodes. It should already be configured with X-Forwarded-For headers enabled. You'll add the Access nodes as upstreams once they're deployed. What is the load balancer IP address: <load-balancer-ip> Checking... Load balancer <load-balancer-ip> port 443 reachable ------------------------------------------------------------- X-Forwarded-For trusted proxies ------------------------------------------------------------- The load balancer and Access node IPs are included automatically. Enter only additional trusted proxy, WAF, CDN, or other forwarding-hop IPs. Do you need to add any additional IPs for X-Forwarded-For? [y/N]: y Additional trusted IP: <trusted-proxy-ip> Added <trusted-proxy-ip> Add another trusted IP? [y/N]: n Section 1 complete.
Section 2: Tenant
Enter the tenant prefix and base domain — users reach the deployment at https://<tenant-name>.<base-domain>. The wizard checks that the FQDN resolves to the load balancer IP, then asks for the tenant administrator’s username (defaults to admin), first name, last name, and email address.
=============================================================
Section 2 of 6: Tenant
=============================================================
Now configure the tenant your users will sign in to.
Load Balancer URL: https://tenant.acme.example.com
Tenant: tenant
Base domain: acme.example.com
What should the tenant be called: <tenant-name>
What is the base domain: <base-domain>
Users will reach this deployment at:
https://<tenant-name>.<base-domain>
Checking DNS...
<tenant-name>.<base-domain> resolves to <load-balancer-ip>
Matches the load balancer.
-------------------------------------------------------------
Tenant administrator
-------------------------------------------------------------
The first administrator account for this tenant.
What should the administrator's username be? [admin]: admin
Administrator's first name: <first-name>
Administrator's last name: <last-name>
Administrator's email address: <administrator-email>
Section 2 complete.
Section 3: Infrastructure Nodes
Enter the IP address of each of the 3 Infrastructure nodes. The wizard checks SSH reachability and authenticates against each node as you enter it. Duplicate addresses are rejected.
=============================================================
Section 3 of 6: Infrastructure nodes
=============================================================
Every deployment uses 3 Infrastructure/Platform nodes, regardless
of size.
These run the platform services (Vault, Consul, Nomad) and the
shared infrastructure: PostgreSQL, Redis, Kafka, and OpenSearch.
What is the IP address of Infrastructure node 1: <infra-ip-1>
What is the IP address of Infrastructure node 2: <infra-ip-2>
What is the IP address of Infrastructure node 3: <infra-ip-3>
Checking SSH reachability and authentication on each Infrastructure node...
✓ Infrastructure node 1 <infra-ip-1> reachable and authenticated
✓ Infrastructure node 2 <infra-ip-2> reachable and authenticated
✓ Infrastructure node 3 <infra-ip-3> reachable and authenticated
All 3 Infrastructure nodes are reachable and authenticated.
Section 3 complete.
Section 4: Access Nodes
Enter the IP address of each Access node (2 for Extra Small, Small or Medium, 3 for Large). The wizard checks reachability and authentication for each one.
=============================================================
Section 4 of 6: Access nodes
=============================================================
Your small deployment uses 2 Omnissa Access nodes.
These run the Access application services and sit behind your load
balancer. Platform services also run here.
What is the IP address of Access node 1: <access-ip-1>
What is the IP address of Access node 2: <access-ip-2>
Checking SSH reachability and authentication on each Access node...
✓ Access node 1 <access-ip-1> reachable and authenticated
✓ Access node 2 <access-ip-2> reachable and authenticated
All 2 Access nodes are reachable and authenticated.
Section 4 complete.
Section 5: Certificates
Choose the TLS certificate Access uses for the tenant FQDN:
- Self-signed: Generated automatically during deployment.
- Custom: Upload your own PEM certificate and private key to the Bootstrap node. The wizard validates the certificate chain, key match, and tenant FQDN coverage.
Self-signed
=============================================================
Section 5 of 6: Certificates
=============================================================
Access needs a TLS certificate for <tenant-name>.<base-domain>.
What certificate should Access use?
1) self-signed generated for you during deployment
2) custom your own certificate from a CA
Choose 1-2: 1
Section 5 complete.
Custom
=============================================================
Section 5 of 6: Certificates
=============================================================
Access needs a TLS certificate for <tenant-name>.<base-domain>.
What certificate should Access use?
1) self-signed generated for you during deployment
2) custom your own certificate from a CA
Choose 1-2: 2
-------------------------------------------------------------
What you need
-------------------------------------------------------------
Two files, both PEM format:
Certificate complete chain, with the server certificate first,
followed by any intermediate CA certificates;
the file starts with
-----BEGIN CERTIFICATE-----
Private key text file starting with
-----BEGIN PRIVATE KEY----- or
-----BEGIN RSA PRIVATE KEY-----
It must not be encrypted or password protected.
The certificate must cover <tenant-name>.<base-domain>, as the Common
Name or a Subject Alternative Name. A wildcard (*.<base-domain>)
also works.
Upload both to this node. From your workstation:
scp mycert.pem mykey.pem configuser@<bootstrap-ip>:/home/configuser/omnissa-upload/
I've created /home/configuser/omnissa-upload for you.
Where are your certificate files?
1) Already uploaded to this node
2) Not yet, I'll upload now - wait for me
3) Actually, use a self-signed certificate instead
Choose 1-3: 1
Checking /home/configuser/omnissa-upload...
<mycert>.pem <size> KB certificate
<mykey>.pem <size> KB private key
Found a certificate and key. Use these? [Y/n]: Y
Checking the certificate...
Format PEM certificate
Covers <tenant-name>.<base-domain> (via wildcard *.<base-domain>)
Issued by <Issuer>
Valid until <date> (<> days from now)
Key match yes
Certificate accepted.
Both files will be copied into place when deployment starts.
Section 5 complete.
Section 6: Optional Services
Four optional items: SMTP, NTP, NFS shared storage, and Cert-Proxy for Mobile SSO for Android. Answer n at any [y/N] prompt to defer that item. All four can be revisited after deployment completes with access-wizard configure.
-
SMTPsupports the following security types:STARTTLS- Explicit TLSSSL_TLS- Implicit TLSNONE- No encryption
-
NTPis used for ensuring time clock synchronization. The Bootstrap node validates DNS name resolution for the NTP server you enter. If anNTPserver is not explicitly defined, a default server will be used. -
NFS shared storageis strongly recommended for disaster recovery. Refer to Configuring Disaster Recovery for Omnissa Access for additional information. -
Cert-Proxyis supported for Android Mobile SSO. Refer to Using a Load Balancer or Reverse Proxy to Enable External Access to Omnissa Access for design considerations and configuration.
=============================================================
Section 6 of 6: Optional services
=============================================================
Four optional items. All can be configured later if you'd rather
get the deployment running first.
-------------------------------------------------------------
Email (SMTP)
-------------------------------------------------------------
Access sends email for password resets, notifications, and new
user invitations. Without it, the administrator can still sign in
using the reset link created at the end of this deployment, but no
other user will receive email.
Configure SMTP now? [y/N]: n
-------------------------------------------------------------
Time synchronization (NTP)
-------------------------------------------------------------
Cluster nodes need their clocks in sync. Certificate validation and
token expiry both depend on it, so drift causes authentication
failures that are hard to trace.
Do you have an NTP server? [y/N]: n
-------------------------------------------------------------
Shared storage (NFS)
-------------------------------------------------------------
Optional shared storage for the cluster.
Do you have NFS storage to configure? [y/N]: n
-------------------------------------------------------------
Centralized logging
-------------------------------------------------------------
Forward cluster logs to an external aggregation service.
Supports Loki, OpenSearch, and Syslog independently or together.
Do you want to configure centralized logging? [y/N]: n
-------------------------------------------------------------
Cert-Proxy (Mobile SSO for Android)
-------------------------------------------------------------
Cert-Proxy enables Mobile SSO for Android devices.
It can be configured later if you skip it now.
Configure Cert-Proxy (Mobile SSO for Android)? [y/N]: y
Which certificate should Cert-Proxy use?
1) Reuse the Load Balancer certificate selected above (recommended)
2) Use a different certificate and private key
Choose 1-2: 1
Section 6 complete.
Review and Confirm
After all six sections, the wizard shows a full summary of your answers.
=============================================================
Ready to deploy
=============================================================
CLUSTER
Name <cluster_name>
Working directory /opt/wss/<cluster_name>
Size small
Bootstrap <bootstrap-ip>
Load balancer <load-balancer-ip>
Credentials configuser (password set)
Authentication SSH key
password used for initial key distribution
Asset bundle <asset-bundle>.zip
EULA <verification-detail>
TENANT
URL https://<tenant-name>.<base-domain>
Username <username>
Administrator <first-name> <last-name>
Email <administrator-email>
INFRASTRUCTURE NODES
Node 1 <infra-ip-1>
Node 2 <infra-ip-2>
Node 3 <infra-ip-3>
ACCESS NODES
Node 1 <access-ip-1>
Node 2 <access-ip-2>
X-FORWARDED-FOR TRUSTED HOPS
Load balancer <load-balancer-ip>
Access nodes <access-ip-1>, <access-ip-2>
Additional trusted IPs <trusted-proxy-ip>
Final trusted list <load-balancer-ip>, <access-ip-1>, <access-ip-2>, <trusted-proxy-ip>
CERTIFICATE
Type custom
Covers <tenant-name>.<base-domain> (via wildcard *.<base-domain>)
Expires <date>
OPTIONAL
Cert-Proxy enabled (FQDN_CERT)
SMTP not configured
NTP not configured
NFS not configured
Logging not configured
-------------------------------------------------------------
This takes roughly 1.5 to 2 hours:
Loading images 5 minutes
Control plane deploy 30-60 minutes
Services deploy 40 minutes
Tenant creation 5-10 minutes
You don't need to stay at the terminal. Progress is shown here
and written to /opt/wss/.omnissa-wizard/logs/
At the end you'll get a password reset link for the
administrator account. It expires in 24 hours, so be ready to
copy it.
Everything above has been saved to /opt/wss/<cluster_name>/wizard.ini
If you stop now, nothing has been changed on any node.
-------------------------------------------------------------
Is everything above correct?
1) Yes, continue to validation
2) No, let me change something
3) Exit without deploying
Choose 1-3:
Choose 1 to proceed to validation, 2 to change something, or 3 to exit without deploying.
Is everything above correct?
1) Yes, continue to validation
2) No, let me change something
3) Exit without deploying
Choose 1-3: 1
The wizard then shows a final readiness summary and asks you to start the deployment.
-------------------------------------------------------------
Deploying
-------------------------------------------------------------
✓ Workflow continuation protected from SSH disconnects
-------------------------------------------------------------
Stage 1 of 7 - Validate prerequisites
-------------------------------------------------------------
Checking this Bootstrap node before making deployment changes.
✓ Root privileges running as root
✓ Required commands all available
✓ Node authentication 6 nodes verified (password)
✓ Bootstrap <bootstrap-ip> AlmaLinux 9.6
✓ Infrastructure 1 <infra-ip-1> AlmaLinux 9.6
✓ Infrastructure 2 <infra-ip-2> AlmaLinux 9.6
✓ Infrastructure 3 <infra-ip-3> AlmaLinux 9.6
✓ Access 1 <access-ip-1> AlmaLinux 9.6
✓ Access 2 <access-ip-2> AlmaLinux 9.6
✓ Node OS validation 6 nodes running AlmaLinux 9.6
✓ Asset bundle located access-26.07-assets.zip
✓ Asset bundle structure manifest and Linux CLI found
✓ Working-directory disk space 132 GB available
✓ Docker storage 44 GB available at /var/lib/docker
✓ Disconnect protection systemd transient services
✓ Cluster node connectivity 5/5 answering on SSH
✓ Load balancer port 443 <load-balancer-ip> reachable
✓ Tenant certificate files certificate and key available
Pre-deployment readiness
✓ Bootstrap authenticated · <boostrap-ip>
✓ Infrastructure nodes 3/3 authenticated
✓ Access nodes 2/2 authenticated
✓ Node addresses unique and validated
✓ Configuration ready for deployment
1) Start deployment
2) Review or change configuration
3) Re-enter the shared configuser password
4) Exit safely
Choose 1-4:
Questionnaire sections
The deployment questionnaire follows a similar flow to 26.07 with these sections:
- Basic information: Review EULA, confirm asset bundle, choose cluster name, select deployment size, confirm Bootstrap IP, enter configuser password, choose authentication method, enter load balancer IP
- Tenant: Enter tenant name, base domain, administrator username, first name, last name, email
- Infrastructure nodes: Enter IP addresses of 3 Infrastructure nodes
- Access nodes: Enter IP addresses of Access nodes (2 for Small/Medium, 3 for Large)
- Certificates: Choose self-signed or custom certificate
- Optional services: Configure SMTP, NTP, NFS, Cert-Proxy, Logging (can defer all to later)
Review and confirm
After all sections, the wizard displays a summary of all answers. Review carefully. Choose 1 to proceed, 2 to change something, or 3 to exit without deploying.
Deployment stages (7 stages for 26.10.0)
| Name | Operations |
|---|---|
| Stage 1 - Validate prerequisites | Root privileges, required commands, node authentication, OS validation, asset bundle integrity, disk space, load balancer check |
| Stage 2 - Prepare deployment assets | Working directory, asset bundle staging and extraction, CLI installation, container image loading |
| Stage 3 - Initialize the cluster | Cluster configuration, SSH key distribution (if selected), cluster inventory, Control Plane profile |
| Stage 4 - Validate the cluster | Configuration precheck, inventory validation |
| Stage 5 - Deploy the Control Plane | Vault, Consul, Nomad, and platform services (47 total); platform health validation |
| Stage 6 - Deploy Access services | Access profile, configuration sync, all Access application services, service readiness gate |
| Stage 7 - Create the tenant | Tenant creation, reset-link handoff, SMTP configuration (if selected) |
Live validation status: A complete greenfield 26.10.0 deployment was successfully tested in production environment - all 47 services deployed and became healthy.
You do not need to stay at the terminal. Progress is displayed and written to /opt/wss/.omnissa-wizard/logs/.
Tenant creation and completion
Near the end of Stage 7, a one-time password reset link is displayed. Copy it immediately - it expires in 24 hours and is not written to any log file. Type CONTINUE after saving it.
When deployment finishes, the wizard displays completion summary with total time, tenant URL, administrator username, cluster name, and node count.
Disaster Recovery
When the deployment is completed, Omnissa strongly recommends backing-up critical files on the bootstrap node. Recovery is not possible, without completing the steps in: Back Up Bootstrap Node Data.
26.10.0 enhancements
What's new in 26.10:
- Password rotation: Use
sudo access-wizard rotate-passwordto rotate root and configuser passwords on all nodes after deployment. - Version display: All logs and deployment output include wizard version (26.10.0) and build information.
- Update support: After deployment, update the cluster with
sudo access-wizard updatefor OS packages, asset bundles, or both combined.
Troubleshooting
Quick reference for potential issues.
If your connection drops
The resume command continues from the last completed deployment stage. Completed work that remains valid is skipped, and previously saved questionnaire answers are not requested again.
To check progress or continue:
sudo access-wizard status
sudo access-wizard resume
After deployment
Check status:
sudo access-wizard status
Reveal platform tokens (Nomad, Consul, Vault):
sudo access-wizard show-tokens
Configure SMTP, NTP, NFS, or Cert-Proxy:
sudo access-wizard configure
Rotate passwords:
sudo access-wizard rotate-password
Collect support bundle (if needed):
sudo access-wizard support-bundle
If a service fails during deployment
If deployment reports a service as unhealthy:
-
Check status:
sudo access-wizard status -
If Control Plane is running, open a support ticket with Omnissa Support and attach a support bundle.
-
If Control Plane is done and nothing specific is called out as failed, resume with:
sudo WIZ_CP_REDEPLOY=yes access-wizard resume -
If Control Plane is done and a specific Access service failed, resolve that service first and then resume.
Cette page vous a-t-elle été utile ?