Starting with this release, 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 Deploy Omnissa Access Manually.
Note: Access Wizard 26.07 supports a greenfield deployment of Omnissa Access 26.07.0.0. Updating an existing deployment and deploying later releases are outside the scope of this version.
Answering the questionnaire takes a few minutes if you have the required IP addresses, certificates, and other information ready. The automated deployment that follows takes approximately 1.5 to 2 hours.
Before You Begin
Confirm the following before you start:
- The Bootstrap, Infrastructure, and Omnissa Access virtual machines from Phase 1 - Prepare Virtual Machines for Omnissa Access Installation and Phase 2 - Deploy 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 Manage 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 Phase 1 - Prepare Virtual Machines for Omnissa Access Installation before you begin.
- The Access Wizard RPM is digitally signed. Verifying the signature (see Trust 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.
Download and Verify the Access Wizard
Procedure:
-
Sign in to Omnissa Customer Connect and download:
- The Omnissa Access asset bundle (the ZIP file containing the Control Plane manifest and container images).
- The Access Wizard RPM bundle — a ZIP file containing three items: the RPM (
access-wizard-26.07.noarch.rpm), its.sha256checksum file, and the Omnissa RPM signing public key (omnissa-linux-rpm-gpg-key.pub).
-
Unzip the RPM bundle on your local machine (or after copying it to the Bootstrap node — see the next section):
unzip <wizard-bundle>.zip -
Verify the RPM against the
.sha256file included in the bundle, and verify the asset bundle against its published checksum:sha256sum -c access-wizard-26.07.noarch.rpm.sha256 sha256sum <asset-bundle>.zipDo not proceed if either value does not match.
Upload the Files to the Bootstrap Node
Procedure:
-
Copy both zips to the Bootstrap node:
scp <wizard-bundle>.zip <asset-bundle>.zip \ configuser@<bootstrap-ip>:/home/configuser/ -
Connect to the Bootstrap node as
configuserand unzip the RPM bundle:ssh configuser@<bootstrap-ip> unzip <wizard-bundle>.zipRemain logged in as
configuserfor the rest of this procedure. All subsequent commands use explicitsudo.
Trust the Signing Key and Verify the RPM
Procedure:
-
Import the Omnissa RPM signing public key (run from the directory where you unzipped the RPM bundle):
sudo rpm --import omnissa-linux-rpm-gpg-key.pub -
Verify the RPM signature and integrity:
sudo rpm -K access-wizard-26.07.noarch.rpmThe output must indicate valid digests and signatures. Do not install the RPM if verification fails.
Install the RPM
Procedure:
sudo dnf install -y access-wizard-26.07.noarch.rpm
The installed package identity is access-wizard-26.07-1.noarch.
Confirm the Installation
Procedure:
sudo access-wizard --version
Expected output:
access-wizard 26.07
Start the Guided Deployment
Procedure:
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
• Release Notes
- https://docs.omnissa.com/bundle/workspace-one-access-release-notesV26.07/page/workspace-one-access-release-notes.html
• Install Omnissa Access
- https://docs.omnissa.com/bundle/workspace-one-access-installation-guideV26.07/page/InstallingOmnissaAccess.html
• Deploy Access & Infrastructure
- https://docs.omnissa.com/bundle/workspace-one-access-installation-guideV26.07/page/DeploytheOmnissaAccessandInfrastructureServices.html
View or copy all official documentation URLs: sudo access-wizard docs
-------------------------------------------------------------
Omnissa Access - guided deployment
-------------------------------------------------------------
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
https://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> -
Choose a cluster name. This determines the working directory path,
/opt/wss/<cluster_name>.------------------------------------------------------------- Cluster ------------------------------------------------------------- Choose a short name for this deployment. The wizard creates /opt/wss/<cluster_name>. This becomes the working directory for future WSO administration and maintenance commands. What would you like to call this cluster?: <cluster_name> Working directory will be /opt/wss/<cluster_name> Your answers are saved to /opt/wss/<cluster_name>/wizard.ini -
Choose the deployment size — Small, Medium, or Large. The wizard displays the node topology for each option.
What size deployment is this? Every deployment uses 3 Infrastructure nodes. The number of Access nodes and supported scale depend on the deployment size. 1) Small 2 Access nodes 300,000 users 3,000 groups 50 apps 2) Medium 2 Access nodes 1,000,000 users 10,000 groups 150 apps 3) Large 3 Access nodes 1,000,000 users 20,000 groups 500 apps Choose 1-3: 1 ✓ Deployment size Small Topology: 3 Infrastructure + 2 Access nodes -
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.
-
Password
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: 1 -
ssh_key
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: 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 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.
Note: The Bootstrap node validates DNS name resolution for the NTP server you enter.
=============================================================
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
-------------------------------------------------------------
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
-------------------------------------------------------------
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:
Deployment Stages
The wizard runs the following seven stages automatically. Keep the terminal session open to monitor progress.
| Stage | Name | What Happens |
|---|---|---|
| 1 | Validate prerequisites | Root privileges, required commands, node authentication, OS validation, asset bundle integrity, disk space, load balancer check |
| 2 | Prepare deployment assets | Working directory, asset bundle staging and extraction, CLI installation, container image loading |
| 3 | Initialize the cluster | Cluster configuration, SSH key distribution (if selected), cluster inventory, Control Plane profile |
| 4 | Validate the cluster | Configuration precheck, inventory validation |
| 5 | Deploy the Control Plane | Vault, Consul, Nomad, and platform services; platform health validation |
| 6 | Deploy Access services | Access profile, configuration sync, all Access application services, service readiness gate |
| 7 | Create the tenant | Tenant creation, reset-link handoff, SMTP configuration (if selected) |
-------------------------------------------------------------
Stage 1 of 7 - Validate prerequisites
-------------------------------------------------------------
✓ Root privileges running as root
✓ Required commands all available
✓ Node authentication 6 nodes verified (password)
✓ Node OS validation 6 nodes running <supported-os>
✓ Asset bundle located <asset-bundle>.zip
✓ Asset bundle structure manifest and Linux CLI found
✓ Working-directory disk space <nn> GB available
✓ Docker storage <nn> GB available at <docker-root>
✓ Disconnect protection systemd transient services
✓ Cluster node connectivity 5/5 answering on SSH
✓ Load balancer port 443 <load-balancer-ip> is listening
✓ Tenant certificate self-signed selected
OK All prerequisites passed
-------------------------------------------------------------
Stage 2 of 7 - Prepare deployment assets
-------------------------------------------------------------
✓ Working directory /opt/wss/<cluster_name>
✓ Asset bundle staged ...
✓ Asset bundle extracted ...
✓ WSO CLI installed /usr/bin/wso
✓ EULA acceptance recorded by the CLI
▓ Loading images <elapsed>
✓ Container images loaded and verified
-------------------------------------------------------------
Stage 3 of 7 - Initialize the cluster
-------------------------------------------------------------
✓ Cluster initialization cp-cluster / <size>
✓ Cluster inventory 5 nodes across 12 groups
✓ Control Plane profile generated defaults retained
-------------------------------------------------------------
Stage 4 of 7 - Validate the cluster
-------------------------------------------------------------
• Optional Control Plane precheck skipped
✓ Cluster inventory validated
-------------------------------------------------------------
Stage 5 of 7 - Deploy the Control Plane
-------------------------------------------------------------
▓ Control Plane deployment <elapsed>
✓ Control Plane deployed
✓ Platform health Vault, Consul, and Nomad healthy
-------------------------------------------------------------
Stage 6 of 7 - Deploy Access services
-------------------------------------------------------------
✓ Access profile written
✓ Access configuration synced to Vault and Consul
✓ <service-1> deployed
✓ <service-2> deployed
...
✓ <service-47> deployed
✓ Access services 47/47 · 100%
✓ Service readiness all services READY
-------------------------------------------------------------
Stage 7 of 7 - Create the tenant
-------------------------------------------------------------
▓ Tenant creation <elapsed>
✓ Tenant created successfully
If Your Connection Drops or You Interrupt the Wizard
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.
- During the questionnaire: Pressing Ctrl+C and then running
resumerestores the answers you already saved. - While monitoring a protected deployment stage: Pressing Ctrl+C detaches your terminal. It does not stop the deployment. Protected stages continue running even if your SSH session disconnects.
To check progress or continue in either case, reconnect and run:
sudo access-wizard status
sudo access-wizard resume
Tenant Creation and Completion
Near the end of Stage 7, a one-time password reset link is displayed on screen. Copy it immediately — it expires in 24 hours and is not written to any log file. Type CONTINUE after saving it.
=============================================================
COPY THIS NOW - the link expires in 24 hours
=============================================================
Login URL https://<tenant-name>.<base-domain>
Username admin
Reset your password at:
<one-time-reset-link>
If SMTP was configured during the questionnaire, the Omnissa CLI securely prompts for the SMTP service account password at this point.
SMTP uses a secure password prompt from the Omnissa CLI.
Enter SMTP Password: ********
✓ SMTP configured
When deployment finishes, the wizard displays a completion summary with the total deployment time, tenant URL, administrator username, cluster name, and node count. If any optional item was skipped during the questionnaire, a "Still outstanding" line lists what to configure later.
---------------------------------------------------------------
Deployment complete
---------------------------------------------------------------
✔ All done - total time: <elapsed>
Tenant URL https://<tenant-name>.<base-domain>
Administrator admin
Cluster <cluster_name>
Nodes 3 Infrastructure, 2 Access
Still outstanding:
SMTP is not configured. Run: sudo access-wizard configure
PLATFORM ACCESS
From /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
Nomad https://<nomad-ip>:4646
Consul https://<consul-ip>:8501
Vault https://<vault-ip>:8202
Administrative tokens are stored in the protected environment file:
/opt/wss/<cluster_name>/cp-cluster/cp-cluster.env (root-only, mode 600)
To display tokens securely:
sudo access-wizard show-tokens
Logs from this run are in: /opt/wss/.omnissa-wizard/logs/
For troubleshooting, the same values can be read directly from the node instead of through show-tokens:
sudo cat /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
After Deployment
Check status:
sudo access-wizard status
---------------------------------------------------------------
Progress
---------------------------------------------------------------
Cluster <cluster_name>
Tenant <tenant-name>.<base-domain>
done Prerequisite validation
done Working directory preparation
done Deployment asset preparation
done Workspace ONE configuration
done Cluster initialization
skipped SSH key configuration
done Cluster configuration
done Control Plane profile
skipped Control Plane precheck
done Cluster inventory validation
done Control Plane deployment
done Platform health validation
done Access profile preparation
done Access configuration synchronization
done Access services deployment
done Service readiness
done Tenant creation
done SMTP configuration
All phases complete.
Reveal platform tokens (Nomad, Consul, Vault are not shown automatically after deployment):
sudo access-wizard show-tokens
Requires an interactive terminal. Type REVEAL when prompted.
Configure SMTP, NTP, NFS, or Cert-Proxy. The access-wizard configure command runs only after deployment completes. The command walks through all four items in one pass, prompting [y/N] for each. Answer n to leave a setting unchanged:
[root@ng-bootstrap wss]# access-wizard configure
Full session log: /opt/wss/.omnissa-wizard/logs/session-20260807-220226-configure.log
-------------------------------------------------------------
Optional configuration
-------------------------------------------------------------
Configure the optional settings you need. Answer no to leave a
setting unchanged and continue to the next one.
Configure SMTP? [y/N]: n
Configure NTP? [y/N]: n
Configure NFS? [y/N]: n
Configure Cert-Proxy (Mobile SSO for Android)? [y/N]: n
-------------------------------------------------------------
Configuration complete
-------------------------------------------------------------
SMTP unchanged
NTP unchanged
NFS unchanged
Cert-Proxy unchanged
Collect a support bundle, if Omnissa asks you to send diagnostics:
sudo access-wizard support-bundle
This writes a redacted archive of logs, configuration, and environment details to /opt/wss/.omnissa-wizard/. Review it before sending.
Additional commands: access-wizard also provides credentials, verify-control-plane, docs, and a deploy --dry-run option. Run access-wizard --help for full usage.
If a Service Fails During Deployment
If Stage 6 (Deploy Access services) reports a service as unhealthy, recover it without restarting the entire deployment:
-
Check which stage or service is stuck:
sudo access-wizard status -
Decide how to proceed based on what the status shows:
-
If Control Plane deployment is
running, do not attempt to resume. Open a support ticket with Omnissa Support instead, and attach a support bundle:sudo access-wizard support-bundle -
If Control Plane deployment is
doneand nothing specific is called out as failed, resume with:sudo WIZ_CP_REDEPLOY=yes access-wizard resumeThis picks up from health validation, then Access profile, then Access services.
-
If Control Plane deployment is
doneand the status output points to a specific failed Access service (reported as X/47), resolve that service first:-
Open the Nomad UI, find the failing job, and purge it (stop and remove, not just restart).
-
Redeploy just that one service from the Bootstrap node's cluster working directory:
cd /opt/wss/<cluster_name> wso services deploy -s <service-name>Note: Deploy only the service that failed during the automated flow.
-
Once that service redeploys successfully, resume the wizard:
sudo access-wizard resume
List of services deployed in order:
control-plane-logging host-logging telegraf-statsd telegraf-asset-server ingress ingress-gateway-route-reloader control-plane-backup client-side-load-balancer telegraf-uptime cp-ops-dispatch cp-ops-output-processor kafka kafka-monitoring postgres postgres-monitoring pgbouncer postgres-backup postgres-diff-backup postgres-operations postgres-operations-vacuum redis redis-monitoring opensearch coredns eecache nginx-http acs crypto cds token analytics saas federation authcontrol greenbox ws1notifications ws1ntfmanager skycap cas certproxy commchannel launcher ws1admin hubconsole mpsso nginx-stream usergroup -
-
This applies any time a service goes into a bad state, not only during initial deployment. The same recovery flow works after a completed deployment or during an upgrade.
Was this page helpful?