This page describes how to upgrade an existing Omnissa Access deployment using the Access Wizard. This is preferred method for upgrading Omnissa Access. Access Wizard has the following benefits:
- Ease of use
- Ability to resume deployment
- Certificate validation
- Keys are automatically propagated to all nodes
- OS upgrade automatically reboots nodes
Use this procedure to perform:
- An OS security package upgrade
- An Access asset bundle upgrade
- A combined OS security package + Access asset bundle upgrade
For a new Omnissa Access deployment, see Deploying Omnissa Access Using the Access Wizard.
Important: This procedure applies to an existing Omnissa Access deployment. The deployment must be healthy before beginning the upgrade.
Service availability during the upgrade
The Access Wizard performs upgrades using a rolling upgrade process. The upgrade does not require a full environment outage; however, the deployment operates in a degraded-capacity state while individual nodes are being upgraded.
-
OS security upgrades: The Wizard upgrades and restarts one node at a time. The remaining nodes continue servicing requests while the upgraded node restarts and returns to service.
-
Access asset bundle upgrades: The Wizard removes and redeploys Access services one node at a time. The remaining nodes continue servicing requests while services are redeployed on the selected node.
-
Load balancing: Service availability and traffic distribution between the Access nodes are handled automatically throughout the upgrade process.
Important: No manual load balancer changes, node removal, or traffic-management changes are required before, during, or after the Wizard upgrade. The Wizard coordinates the rolling upgrade so that available nodes continue servicing requests while each node is upgraded.
Before you begin
Perform the upgrade from the bootstrap node.
Have the following ready:
- SSH access to the bootstrap node as
configuser. sudoaccess on the bootstrap node.- Current
configuserpassword for the cluster nodes.
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 is a separate check from the SHA-256 checksum verification in the next section — the checksum confirms the download was not corrupted, not that it is genuinely from Omnissa.
Plan an appropriate maintenance window for the upgrade.
In one validated 26.07 to 26.10 combined upgrade, the complete process took approximately 145 minutes (2 hours 25 minutes). Actual upgrade duration varies depending on the environment, infrastructure performance, and selected upgrade type.
Step 1: Verify version of current Access deployment
This guide is intended for upgrading Omnissa Access 26.07.0.0.
Connect to the bootstrap node as configuser:
ssh configuser@<bootstrap-ip>
Confirm current Access version by running:
sudo bash -lc 'cd /root/cp-cluster && wso version'
The expected result should be:
Workspace ONE CLI
Platform: linux/amd64
Version: 26.07.0.0-2026.07.13-528-eb05a4e
Build time: Mon Jul 13 10:26:53 UTC 2026
CP Image Version: 0.5.0-2026.07.10-829-05c0b8a
CPS Image Version: 0.1.2-2026.07.13.0-e4b30287895ad3339b27adf97e2273a082a4a033
Important: Do not proceed if Access version does not match expected output.
Step 2: Download and validate files for upgrade
On your local machine:
-
Sign in to Omnissa Customer Connect.
-
Download
<access-wizard-bundle>.zip(Containsaccess-wizard-26.10.0.noarch.rpm,.sha256checksum file, andomnissa-linux-rpm-gpg-key.pub). -
Based on the type of upgrade, download the following files:
-
For an OS security package upgrade:
<os-security>.tar.gz- Contains OS security updates<os-security>.tar.gz.sha256- Used to validate the integrity of<os-security>.tar.gz
-
For an Access asset bundle upgrade:
<access-asset-bundle>.zip- Contains Control Plane manifest and container images<access-asset-bundle>.zip.sha256- Used to validate the integrity of<access-asset-bundle>.zip
-
For a combined OS + Access upgrade, all four files are required.
Important: The
.sha256checksum file is required for each upgrade package. The Access Wizard validates the supplied artifact against its corresponding.sha256file before beginning the upgrade. If the checksum file is missing or checksum validation fails, the upgrade does not proceed. -
-
Unzip the Wizard 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 3: Place files on the bootstrap node
On your local machine:
scp <wizard-bundle>.zip <asset-bundle>.zip \
configuser@<bootstrap-ip>:/home/configuser/
Connect to the bootstrap node as configuser:
ssh configuser@<bootstrap-ip>
On the bootstrap node:
unzip <wizard-bundle>.zip
Remain logged in as configuser. All subsequent commands use explicit sudo.
Step 4: Install or Upgrade to Access Wizard 26.10.0
The upgrade must be performed using the Access Wizard version intended for the 26.10 release. If an earlier Access Wizard is already installed, it will be upgraded in-place. You do not need to uninstall the previous Access Wizard first.
The following steps will depend on how Omnissa Access was previously deployed: Wizard or Manual. From the bootstrap node, proceed with one of the following options:
-
Option 1: Wizard
If the previous deployment or upgrade was performed using the Wizard, then the Wizard will have to be replaced.
-
Confirm current version of Access Wizard.
rpm -qa | grep -i access-wizard -
Upgrade the Access Wizard.
sudo rpm -Uvh \ --replacepkgs \ /home/configuser/access-wizard-26.10.0.noarch.rpm
-
-
Option 2: Manual
If the previous deployment or upgrade was performed was manual, then the Wizard will have to be installed.
-
Import the Omnissa RPM signing public key:
sudo rpm --import /home/configuser/omnissa-linux-rpm-gpg-key.pub -
Verify the RPM signature and integrity:
sudo rpm -K /home/configuser/access-wizard-26.10.0.noarch.rpmImportant: The output must indicate valid digests and signatures. Do not install if verification fails.
-
Import the Omnissa RPM signing public key:
sudo rpm --import /home/configuser/omnissa-linux-rpm-gpg-key.pub -
Install the RPM:
sudo dnf install -y /home/configuser/access-wizard-26.10.0.noarch.rpm
-
Verify the correct version of Access Wizard is now installed.
rpm -qa | grep -i access-wizard
Important: Do not delete the existing Wizard state or the Access cluster working directory when upgrading the Wizard.
Installing or upgrading the Wizard RPM does not itself upgrade the existing Omnissa Access deployment.
Step 5: Verify the existing deployment
Before staging or applying the upgrade, verify that the existing deployment is healthy.
Check the Access Wizard status:
sudo access-wizard status
Verify the Control Plane:
sudo access-wizard verify-control-plane
Verify that:
- Vault is responding and unsealed.
- The Control Plane is healthy.
- Cluster nodes are reachable.
- Access nodes are reachable.
- No previous upgrade or deployment operation requires attention.
If the Wizard reports an unhealthy service, unreachable node, or Control Plane issue, resolve the problem before proceeding.
Important: Do not begin the upgrade against an unhealthy Access deployment.
Step 6: Stage the upgrade artifacts
Copy the required upgrade package and its corresponding .sha256 checksum file to the bootstrap node.
OS security bundle
For example:
/home/configuser/<os-security>.tar.gz
/home/configuser/<os-security>.tar.gz.sha256
Access asset bundle upgrade
For example:
/home/configuser/<access-asset-bundle>.zip
/home/configuser/<access-asset-bundle>.zip.sha256
Combined OS + Access upgrade
For a combined upgrade, stage all four files:
/home/configuser/<os-security>.tar.gz
/home/configuser/<os-security>.tar.gz.sha256
/home/configuser/<access-asset-bundle>.zip
/home/configuser/<access-asset-bundle>.zip.sha256
Confirm that the files are present:
ls -lh /home/configuser/<os-security>.tar.gz*
ls -lh /home/configuser/<access-asset-bundle>.zip*
The expected output should show both the upgrade package and its corresponding .sha256 file.
The Access Wizard performs checksum validation automatically. Manual checksum verification is not required as part of the standard upgrade procedure.
Step 7: Start the guided upgrade
For this step, follow procedures for only one option. Select the command(s) that corresponds to the upgrade you want to perform.
Option 1: Combined OS + Access upgrade
Run:
sudo access-wizard upgrade \
--os-package /home/configuser/<os-security>.tar.gz \
--asset-bundle /home/configuser/<access-asset-bundle>.zip
Option 2: OS security package only
Note: For option 2, OS upgrade must be performed prior to asset bundle.
Run:
sudo access-wizard upgrade \
--os-package /home/configuser/<os-security>.tar.gz
Option 2: Access asset bundle only
Note: For option 2, OS upgrade must be performed prior to asset bundle.
Run:
sudo access-wizard upgrade \
--asset-bundle /home/configuser/<access-asset-bundle>.zip
You specify the upgrade package on the command line. You do not specify the .sha256 file separately.
The Wizard automatically locates and validates the corresponding .sha256 checksum file.
Important: Do not use options that bypass Wizard version or upgrade-path validation unless specifically instructed by Omnissa Support or Engineering.
Step 8: Confirm the upgrade target and upgrade options
Before making changes, the Wizard validates the supplied files and collects the information required to perform the upgrade.
The Wizard prompts you to confirm the cluster working directory.
For example:
CONFIRM the full path of the cluster to upgrade
(contains cp-cluster/cp-cluster.ini) [/opt/wss/access]:
For standard Access Wizard deployments, the cluster working directory is:
/opt/wss/access
The Wizard then displays information about the planned upgrade.
For example:
Confirmed upgrade target /opt/wss/access
Target Access release 26.10.0.0
Bootstrap IP <bootstrap-ip>
Upgrade questions complete
If the upgrade includes OS security packages, the Wizard also prompts you to determine whether the bootstrap node should automatically reboot when required.
Review the information carefully before allowing the upgrade to continue.
Step 9: Wizard prerequisite validation
Before changing the environment, the Wizard validates the upgrade prerequisites.
Validation includes checks such as:
- Root privileges
- Required commands
- Existing cluster working directory
- Upgrade package integrity
.sha256checksum validation- Access asset bundle release
- Available disk space
- Bootstrap node information
- Ansible upgrade targets
- Cluster connectivity
- Vault health
For example:
Upgrade stage 1 of 6 - Validate the upgrade prerequisites
Checking this bootstrap node, the staged artifacts, and current health.
✓ Root privileges
✓ Required commands
✓ Cluster working directory
✓ OS package integrity
✓ Access asset integrity
✓ Upgrade disk space
✓ Ansible upgrade targets
✓ Vault
Upgrade prerequisites passed
If prerequisite validation fails, the Wizard stops before the upgrade proceeds.
Resolve the reported issue and retry or resume as appropriate.
Step 10: Allow the Wizard to perform the upgrade
A combined OS + Access upgrade contains six major stages.
Stage 1 - Validate the upgrade prerequisites
The Wizard validates:
- Bootstrap configuration
- Upgrade artifacts
- Checksums
- Disk space
- Connectivity
- Cluster health
- Vault health
- Upgrade targets
Typical duration:
Approximately 2–5 minutes
Stage 2 - Upgrade the OS package repository
If an OS security package was supplied, the Wizard:
- Extracts the OS package.
- Applies required OS preparation.
- Builds the local package repository.
- Configures the cluster nodes to use the upgrade repository.
Typical duration:
Approximately 5–10 minutes
This stage is skipped for an Access asset-only upgrade.
Stage 3 - Refresh the Access asset bundle
If an Access asset bundle was supplied, the Wizard:
- Unpacks the target release bundle.
- Validates the Access release.
- Prepares the refreshed CLI/runtime.
- Loads the target-release components.
Typical duration:
Approximately 5–10 minutes
This stage is skipped for an OS-only upgrade when an Access asset refresh is not required.
Stage 4 - Upgrade the Control Plane
The Wizard applies the selected Control Plane upgrade and performs required Control Plane operations.
These operations can include:
- Validating Control Plane assets.
- Validating the deployed and target versions.
- Unsealing Vault.
- Upgrading Control Plane prerequisites.
- Upgrading Control Plane components.
- Upgrading cluster configuration.
- Applying OS package updates to applicable cluster nodes.
- Performing post-upgrade Control Plane verification.
Typical duration in the validated combined upgrade:
Approximately 45 minutes
This is a long-running stage.
The Wizard protects supported long-running operations from SSH disconnections.
SSH disconnect protection
If your SSH connection is interrupted during a protected upgrade operation, do not start a new upgrade.
Reconnect to the bootstrap node:
ssh configuser@<bootstrap-ip>
Then run:
sudo access-wizard resume
The Wizard reads the saved upgrade state, verifies previously completed work, and continues from the appropriate stage.
Stage 5 - Redeploy Access services
For an Access asset upgrade, the Wizard:
- Places Access into upgrade mode.
- Redeploys the Access services.
- Verifies service health.
- Leaves upgrade mode.
- Cleans up old assets after successful deployment.
In a validated 26.07 to 26.10 upgrade, all Access services were reported healthy before the Wizard proceeded.
Typical duration in the validated combined upgrade:
Approximately 40 minutes
This is also a long-running stage and is protected from SSH disconnections where supported.
If the SSH connection is interrupted:
sudo access-wizard resume
Stage 6 - Finalize the bootstrap OS upgrade and reboot
For updates that include OS security packages, the Wizard applies the OS updates to the bootstrap node.
When a reboot is required, the Wizard displays a message similar to:
Rebooting the bootstrap node
The bootstrap node will reboot now to finish the OS upgrade.
After it comes back, log in and run:
sudo access-wizard resume
The SSH session then closes when the bootstrap node reboots.
Typical duration in the validated combined upgrade:
Approximately 20 minutes
This stage is not applicable in the same way for updates that do not require a bootstrap OS upgrade.
Step 11: Reconnect after the bootstrap node reboot
Wait until the bootstrap node is available again.
Reconnect:
ssh configuser@<bootstrap-ip>
Then run:
sudo access-wizard resume
The Wizard loads the saved upgrade state.
Previously completed stages are verified and are not unnecessarily repeated.
For example:
Previous upgrade steps verified as complete:
✓ Upgrade prerequisites
✓ OS package extraction
✓ OS local repository
✓ OS repo staging
✓ OS repo push to nodes
✓ Asset bundle refresh
✓ Control Plane upgrade
✓ Control Plane unseal
✓ Post-upgrade verification
✓ Enter upgrade mode
✓ Access services redeploy
✓ Leave upgrade mode
✓ Asset cleanup
✓ Bootstrap OS upgrade
✓ Bootstrap reboot
The Wizard then performs the required post-reboot validation.
Continue until the Wizard reports:
Upgrade complete
Step 12: Validate the completed upgrade
Do not consider the upgrade successful based only on the reported Access version.
A successful upgrade requires:
- The Access Wizard workflow to complete successfully.
- Platform health validation to succeed.
- Access service readiness validation to succeed.
- The expected Access version to be reported.
Confirm Wizard completion
The Wizard must report:
Upgrade complete
Check platform health
Run:
sudo wso healthcheck
Confirm that the Control Plane and platform are healthy.
Check Access service readiness
Run:
sudo wso access check-service-readiness
Confirm that the Access services are ready.
Confirm the Access version
Run:
sudo wso version
Confirm that the expected target Access version is reported.
For a 26.10 upgrade, the expected Access release is:
26.10.0.0
Important: wso version alone does not confirm that the upgrade completed successfully. Wizard completion, platform health, and Access service readiness must also be verified.
Upgrade stage summary
| Operation | Duration | Description |
|---|---|---|
| Stage 1 - Validate prerequisites | 2–5 min | Validate cluster health, upgrade artifacts, checksums, disk space, connectivity, and Vault |
| Stage 2 - Upgrade OS repository | 5–10 min | Extract OS packages, build the local repository, and configure cluster nodes |
| Stage 3 - Refresh Access asset bundle | 5–10 min | Validate and stage the target Access release |
| Stage 4 - Upgrade Control Plane | ~45 min | Upgrade Control Plane components and perform health verification |
| Stage 5 - Redeploy Access services | ~40 min | Enter upgrade mode, redeploy Access services, verify health, exit upgrade mode, and clean old assets |
| Stage 6 - Finalize bootstrap OS upgrade and reboot | ~20 min | Apply bootstrap OS updates, reboot when required, and perform post-reboot validation |
Example combined upgrade total:
Approximately 145 minutes (2 hours 25 minutes)
These timings are examples from a validation environment and are not guaranteed upgrade times.
Disaster Recovery
When the upgrade 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.
Real-world upgrade example: Access 26.07 to 26.10
The following workflow was validated using a combined OS security package and Access asset bundle upgrade.
Initiate Omnissa Access Wizard upgrade process
[configuser@ng-bootstrap ~]$ sudo access-wizard upgrade --os-package /home/configuser/os.tar.gz --asset-bundle /home/configuser/asset-bundle2610.zip
Full session log: /opt/wss/.omnissa-wizard/logs/session-20260901-164645-upgrade.log
Access Wizard 26.10.0
Omnissa Access upgrade
-------------------------------------------------------------
Omnissa Access upgrade
-------------------------------------------------------------
Access Wizard 26.10.0
This wizard updates your existing Omnissa Access deployment using the
selected OS package, Access asset bundle, or both.
Before making any changes, the wizard validates the supplied files and
collects the required information. Your answers and upgrade progress are
saved automatically, allowing the operation to resume after an SSH
disconnect or system reboot.
CONFIRM the full path of the cluster to upgrade (contains cp-cluster/cp-cluster.ini) [/opt/wss/access]:
✓ Confirmed upgrade target /opt/wss/access
Upgrade questions
-------------------------------------------------------------
Upgrade questions
-------------------------------------------------------------
✓ Confirmed upgrade target /opt/wss/access
✓ Target Access release 26.10.0.0 (from approved bundle)
✓ Ansible targets general_compute_linux:general_compute_access_linux
Automatically reboot the bootstrap node at the end of the upgrade? [Y/n]:
✓ Bootstrap IP 10.0.0.1 (auto-detected)
✓ Upgrade questions complete
Upgrading Omnissa Access
-------------------------------------------------------------
Upgrading Omnissa Access
-------------------------------------------------------------
✓ Workflow continuation protected from SSH disconnects
Upgrade stage 1 of 6 - Validate the upgrade prerequisites
-------------------------------------------------------------
Upgrade stage 1 of 6 - Validate the upgrade prerequisites
-------------------------------------------------------------
Checking this bootstrap node, the staged artifacts, and current health.
✓ Root privileges running as root
✓ Required commands available
✓ Cluster working directory /opt/wss/access
✓ OS package integrity private staged copy verified
✓ Access asset integrity verified release 26.10.0.0
✓ Local repository helper /usr/local/sbin/upgrade-dnf-repo.sh
✓ Bootstrap IP 10.0.0.1
✓ Upgrade disk space 109 GB free at /opt/wss/access
✓ Ansible upgrade targets 5 host(s)
• Checking Vault
OK Upgrade prerequisites passed
Upgrade stage 2 of 6 - Upgrade the OS package repository
-------------------------------------------------------------
Upgrade stage 2 of 6 - Upgrade the OS package repository
-------------------------------------------------------------
Extracting the OS security package and configuring the cluster's local repo.
Extracting the OS security package
$ tar -xvf /opt/wss/.omnissa-wizard/upgrade-artifacts/os-d06a1a75474c3cfd43cf95e4c2d690f9b6225e85bf4221278a4ba444af0fe547.tar.gz -C /opt/wss/access/os-upgrade-d06a1a75474c.extracting
• security-rpms.tar.gz
✓ OS package extraction /opt/wss/access/os-upgrade-d06a1a75474c
Applying AlmaLinux portable fixes (before repo refresh)
$ sh /opt/wss/access/os-upgrade-d06a1a75474c/cp-alma-portable-fixes-v1.sh
• [2026-09-01T16:49:35Z] Configuring /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf
• [2026-09-01T16:49:36Z] Adding obsolete RPM list from /opt/wss/access/os-upgrade-d06a1a75474c/removed-packages.txt
Building the local dnf repository
$ sh /usr/local/sbin/upgrade-dnf-repo.sh /opt/wss/access/os-upgrade-d06a1a75474c/security-rpms.tar.gz
• Extracting tarball: /opt/wss/access/os-upgrade-d06a1a75474c/security-rpms.tar.gz -> /root/alma-localrepo-bundle.d
• Upgrading /opt/localrepo from /root/alma-localrepo-bundle.d/*.rpm (flat bundle)
✓ OS local repository built from /opt/wss/access/os-upgrade-d06a1a75474c/security-rpms.tar.gz
✓ OS repo staging /opt/wss/access/access
• uid: 0
• uid: 0
• uid: 0
• vim-minimal.x86_64 2:8.2.2637-22.el9_6.1.tuxcare.els40 localrepo
• [2026-09-01T16:51:03Z] Configuring nginx access-log rotation
✓ OS repo push cluster nodes configured for the local repository
Upgrade stage 3 of 6 - Refresh the Access asset bundle
-------------------------------------------------------------
Upgrade stage 3 of 6 - Refresh the Access asset bundle
-------------------------------------------------------------
Unpacking the target-release bundle and configuring the refreshed CLI.
Unpacking the asset bundle
$ unzip -o /opt/wss/.omnissa-wizard/upgrade-artifacts/asset-b5f36cf2c8a59afa5e56970140221ef742f758903ac06fa0974a640d776f45cc.zip -d /opt/wss/access/assets-upgrade-b5f36cf2c8a5.extracting
• inflating: /opt/wss/access/assets-upgrade-b5f36cf2c8a5.extracting/control-plane-images.tar.gz
• inflating: /opt/wss/access/assets-upgrade-b5f36cf2c8a5.extracting/offline-hydrater.tar.gz
✓ EULA acceptance recorded by the refreshed CLI
• Version control is enabled. Validating bundle version and upgrade path.
• Preparing the WSO CLI runtime
• Loading Workspace ONE components
✓ Asset bundle configured from /opt/wss/access/assets-upgrade-b5f36cf2c8a5
Upgrade stage 4 of 6 - Upgrade the Control Plane
-------------------------------------------------------------
Upgrade stage 4 of 6 - Upgrade the Control Plane
-------------------------------------------------------------
Applying the selected upgrade, unsealing, and verifying (long).
Log: /opt/wss/.omnissa-wizard/logs/access-20260901-165457-control-plane-deploy-u.log
Connection protection: active
If SSH disconnects, non-interactive deployment continues in the background.
Recovery command: sudo access-wizard resume
• Validating bundled Control Plane assets
• Validating control plane version against deployed version
• Unsealing Vault
• Provisioning prerequisites
• Updating Firewall rules
• Configuring telemetry
• Provisioning vault prerequisites
• Deploying vault
• Adding PKI root CA cert to truststore
• Initializing vault
• Unsealing Vault
• Adding PKI root and intermediate CA to truststore
• Creating vault integration tokens for nomad
• Provisioning consul prerequisites
• Deploying consul
• Unsealing Vault
• Provisioning nomad prerequisites
• Deploying nomad
• Provisioning cpautoremediation prerequisites
• Deploying cpautoremediation
• Deploying consul-template
• Updating control plane version in consul
• Updating telemetry port and folder hash kv in consul
• Provisioning asset server prerequisites
• Deploying asset server
• Adding PKI root CA certificate to docker truststore
• Updating package repository URL
• Provisioning package upgrade prerequisites
• Updating package repository cache
• Updating general compute nodes
• Cleaning up
• Generating environment file with cluster details and secret tokens
• Verify that CA is present in trust bundle on all nodes
✓ Control Plane upgrade selected upgrade applied
• Unsealing Vault
✓ Control Plane unseal unsealed
• CPS Image Version: 0.1.2-2026.08.29.0-5cc6af9d253c7ddac62d25d9d4448a181056893f
• Checking Vault
✓ Post-upgrade verification version and health checked
Upgrade stage 5 of 6 - Redeploy Access services
-------------------------------------------------------------
Upgrade stage 5 of 6 - Redeploy Access services
-------------------------------------------------------------
Entering upgrade mode, redeploying all services, then resetting (long).
• API Gateway TLS is not enabled or enforced
• API Gateway TLS is not enabled or enforced
✓ Access upgrade mode enabled
Log: /opt/wss/.omnissa-wizard/logs/access-20260901-175158-services-deploy-type-full.log
Connection protection: active
If SSH disconnects, non-interactive deployment continues in the background.
Recovery command: sudo access-wizard resume
Deploying services
✓ control-plane-logging deployed
✓ host-logging deployed
✓ telegraf-statsd deployed
✓ telegraf-asset-server deployed
✓ ingress deployed
✓ ingress-gateway-route-reloader deployed
✓ control-plane-backup deployed
✓ client-side-load-balancer deployed
✓ telegraf-uptime deployed
✓ cp-ops-dispatch deployed
✓ cp-ops-output-processor deployed
✓ postgres deployed
✓ postgres-monitoring deployed
✓ pgbouncer deployed
✓ postgres-backup deployed
✓ postgres-diff-backup deployed
✓ postgres-operations deployed
✓ postgres-operations-vacuum deployed
✓ redis deployed
✓ redis-monitoring deployed
✓ opensearch deployed
✓ kafka deployed
✓ kafka-monitoring deployed
✓ coredns deployed
✓ eecache deployed
✓ nginx-http deployed
✓ acs deployed
✓ crypto deployed
✓ cds deployed
✓ token deployed
✓ analytics deployed
✓ saas deployed
✓ federation deployed
✓ authcontrol deployed
✓ greenbox deployed
✓ ws1notifications deployed
✓ ws1ntfmanager deployed
✓ skycap deployed
✓ cas deployed
✓ certproxy deployed
✓ commchannel deployed
✓ launcher deployed
✓ ws1admin deployed
✓ hubconsole deployed
✓ mpsso deployed
✓ nginx-stream deployed
✓ usergroup deployed
✓ Access services redeployed (full)
• API Gateway TLS is not enabled or enforced
✓ Access upgrade mode reset
• Cleaning up unused images and binary assets
✓ Asset cleanup old assets reset
Upgrade stage 6 of 6 - Finalize the bootstrap OS and reboot
-------------------------------------------------------------
Upgrade stage 6 of 6 - Finalize the bootstrap OS and reboot
-------------------------------------------------------------
Upgrading the bootstrap packages and rebooting; validation runs after boot.
• Last metadata expiration check: 1:41:00 ago on Tue 01 Sep 2026 05:29:58 PM UTC.
• Running transaction check
• Running transaction test
• Running transaction
• Upgrading : glibc-common-2.34-169.el9_6.1.tuxcare.els5.x86_6 1/176
• Running scriptlet: glibc-2.34-169.el9_6.1.tuxcare.els5.x86_64 4/176
• Upgrading : libattr-2.6.0-1.el9_6.tuxcare.els1.x86_64 9/176
• Running scriptlet: docker-compose-plugin-5.5.0-1.el9.x86_64 16/176
• Upgrading : python3-3.9.21-2.el9_6.2.tuxcare.els18.x86_64 25/176
• Upgrading : libsss_nss_idmap-2.9.6-4.el9_6.2.tuxcare.els7.x8 30/176
• Running scriptlet: systemd-libs-252-51.el9_6.3.alma.2.tuxcare.els4. 42/176
• Running scriptlet: util-linux-core-2.37.4-21.el9_6.tuxcare.els4.x86 48/176
• Running scriptlet: systemd-252-51.el9_6.3.alma.2.tuxcare.els4.x86_6 51/176
• Running scriptlet: systemd-udev-252-51.el9_6.3.alma.2.tuxcare.els4. 52/176
• Upgrading : openssh-8.7p1-45.el9_6.tuxcare.els15.x86_64 54/176
• Running scriptlet: docker-ce-rootless-extras-29.7.2-1.el9.x86_64 56/176
• Running scriptlet: docker-ce-3:29.7.2-1.el9.x86_64 57/176
• Running scriptlet: sssd-common-2.9.6-4.el9_6.2.tuxcare.els7.x86_64 60/176
• Upgrading : dracut-057-89.git20250311.el9_6.tuxcare.els2.x86 62/176
• Installing : kernel-modules-core-5.14.0-570.62.1.el9_6.tuxcar 63/176
• Running scriptlet: kernel-core-5.14.0-570.62.1.el9_6.tuxcare.5.els1 64/176
• Running scriptlet: kernel-modules-5.14.0-570.62.1.el9_6.tuxcare.5.e 65/176
• Running scriptlet: systemd-resolved-252-51.el9_6.3.alma.2.tuxcare.e 79/176
• Upgrading : python3-lxml-4.6.5-3.el9.x86_64 85/176
• Running scriptlet: openssh-clients-8.7p1-45.el9_6.tuxcare.els6.x86_ 100/176
• Running scriptlet: nginx-2:1.20.1-22.el9_6.3.alma.2.tuxcare.els6.x8 122/176
• Cleanup : epel-release-9-9.el9.noarch 132/176
• Running scriptlet: systemd-252-51.el9_6.3.alma.2.tuxcare.els2.x86_6 146/176
• Running scriptlet: kernel-modules-core-5.14.0-570.62.1.el9_6.tuxcar 176/176
• Running scriptlet: kernel-core-5.14.0-570.62.1.el9_6.tuxcare.5.els1 176/176
• Running scriptlet: glibc-common-2.34-169.el9_6.1.tuxcare.els4.x86_6 176/176
• Verifying : vim-minimal-2:8.2.2637-22.el9_6.1.tuxcare.els37. 176/176
• Complete!
✓ Bootstrap OS upgrade applied
Rebooting the bootstrap node
-------------------------------------------------------------
Rebooting the bootstrap node
-------------------------------------------------------------
The bootstrap node will reboot now to finish the OS upgrade.
After it comes back, log in and run:
sudo access-wizard resume
The wizard will then run post-reboot validation.
Broadcast message from root@alma-minimal on pts/1 (Tue 2026-09-01 19:13:19 UTC):
The system will reboot now!
Connection to 10.0.0.1 closed by remote host.
Connection to 10.0.0.1 closed.
admin@localhost python % ssh configuser@10.0.0.1
Authorized users only. All activity may be monitored and reported.
configuser@10.0.0.1's password:
Last login: Tue Sep 1 16:46:34 UTC 2026 from 10.0.0.100 on pts/0
Last login: Tue Sep 1 19:13:56 2026 from 10.0.0.100
[configuser@ng-bootstrap ~]$ sudo access-wizard resume
Full session log: /opt/wss/.omnissa-wizard/logs/session-20260901-191405-resume.log
Access Wizard 26.10.0
Upgrading Omnissa Access
-------------------------------------------------------------
Upgrading Omnissa Access
-------------------------------------------------------------
✓ Workflow continuation protected from SSH disconnects
Previous upgrade steps verified as complete:
✓ Upgrade prerequisites
✓ OS package extraction
✓ OS local repository
✓ OS repo staging
✓ OS repo push to nodes
✓ Asset bundle refresh
✓ Control Plane upgrade
✓ Control Plane unseal
✓ Post-upgrade verification
✓ Enter upgrade mode
✓ Access services redeploy
✓ Leave upgrade mode
✓ Asset cleanup
✓ Bootstrap OS upgrade
✓ Bootstrap reboot
Upgrade stage 1 of 6 - Validate the upgrade prerequisites
-------------------------------------------------------------
Upgrade stage 1 of 6 - Validate the upgrade prerequisites
-------------------------------------------------------------
Checking this bootstrap node, the staged artifacts, and current health.
✓ Upgrade prerequisites already validated
Upgrade stage 2 of 6 - Upgrade the OS package repository
-------------------------------------------------------------
Upgrade stage 2 of 6 - Upgrade the OS package repository
-------------------------------------------------------------
Extracting the OS security package and configuring the cluster's local repo.
✓ OS package extraction already done
✓ OS local repository already prepared
✓ OS repo staging already staged
✓ OS repo push already pushed
Upgrade stage 3 of 6 - Refresh the Access asset bundle
-------------------------------------------------------------
Upgrade stage 3 of 6 - Refresh the Access asset bundle
-------------------------------------------------------------
Unpacking the target-release bundle and configuring the refreshed CLI.
✓ Asset bundle already configured
Upgrade stage 4 of 6 - Upgrade the Control Plane
-------------------------------------------------------------
Upgrade stage 4 of 6 - Upgrade the Control Plane
-------------------------------------------------------------
Applying the selected upgrade, unsealing, and verifying (long).
✓ Control Plane upgrade already applied
✓ Control Plane unseal already unsealed
✓ Post-upgrade verification already done
Upgrade stage 5 of 6 - Redeploy Access services
-------------------------------------------------------------
Upgrade stage 5 of 6 - Redeploy Access services
-------------------------------------------------------------
Entering upgrade mode, redeploying all services, then resetting (long).
✓ Access upgrade mode already set
✓ Access services already redeployed
✓ Access upgrade mode already reset
✓ Asset cleanup already done
Upgrade stage 6 of 6 - Finalize the bootstrap OS and reboot
-------------------------------------------------------------
Upgrade stage 6 of 6 - Finalize the bootstrap OS and reboot
-------------------------------------------------------------
Upgrading the bootstrap packages and rebooting; validation runs after boot.
✓ Bootstrap OS upgrade already applied
✓ Bootstrap reboot already completed
• Checking Vault .
• API Gateway TLS is not enabled or enforced
✓ Post-upgrade validation healthcheck and readiness executed
Upgrade complete
-------------------------------------------------------------
Upgrade complete
-------------------------------------------------------------
The OS package and Access asset upgrade finished on this cluster.
Total elapsed time: 145 min 41 sec.
Access Wizard 26.10.0
Access before: 26.07.0.0-2026.07.13-528-eb05a4e
Access now: 26.10.0.0
Recommended next checks:
wso healthcheck
wso access check-service-readiness
Resume and recovery
The Access Wizard automatically saves upgrade progress.
Use resume when an upgrade has already started and continuation is required.
Examples include:
- The SSH session was disconnected.
- The administrator workstation lost connectivity.
- The bootstrap node rebooted as part of the OS upgrade.
- A recoverable issue was resolved and the existing upgrade needs to continue.
Reconnect to the bootstrap node and run:
sudo access-wizard resume
Important: Do not start a new access-wizard upgrade operation when an existing upgrade needs to be resumed.
The Wizard verifies previously completed work and continues from the appropriate point.
Troubleshooting
The Wizard reports that a .sha256 file is missing
Each upgrade artifact requires its corresponding .sha256 checksum file.
For example:
os-security-2026.09.tar.gz
os-security-2026.09.tar.gz.sha256
Or:
access-bundle-26.10.0.0.zip
access-bundle-26.10.0.0.zip.sha256
Copy the missing .sha256 file to the same staging location as the corresponding package and retry the operation.
Checksum validation fails
Do not continue with an artifact that fails checksum validation.
Verify that:
- The correct
.sha256file was provided. - The
.sha256corresponds to the exact upgrade package being used. - The upgrade package was completely copied to the bootstrap node.
- Neither file was modified after download.
Replace the affected files with the correct release artifacts before retrying.
A cluster node is unreachable
Resolve the network or SSH connectivity issue before continuing.
After connectivity has been restored, run:
sudo access-wizard resume
Do not restart the entire upgrade unless specifically instructed to do so.
My SSH session disconnected during the upgrade
Reconnect to the bootstrap node:
ssh configuser@<bootstrap-ip>
Then run:
sudo access-wizard resume
The Wizard determines which work has already completed and continues from the saved state.
The bootstrap node rebooted
A bootstrap node reboot is expected when required as part of an OS upgrade.
After the node becomes available, reconnect and run:
sudo access-wizard resume
The Wizard performs the required post-reboot validation before reporting the upgrade as complete.
Verify cluster health (pre-upgrade)
On the bootstrap node (as root or with sudo):
$ sudo access-wizard status
Phases completed: 1-7
Last deployment: 2026-08-15 14:23 UTC
Cluster: tenant.example.com
All services: healthy
Also confirm:
$ sudo access-wizard verify-control-plane
Checking Control Plane health...
✓ Vault unsealed and responding
✓ Kubernetes API responding
✓ All infrastructure nodes reachable
✓ All access nodes reachable
Control Plane is healthy and ready for updates.
If any service is unhealthy, investigate and resolve the issue before proceeding with the upgrade.
Frequently Asked Questions
Can I perform only the OS security package upgrade?
Yes.
Supply only the OS package:
sudo access-wizard upgrade \
--os-package /home/configuser/os-security-2026.09.tar.gz
The corresponding .sha256 file must also be present:
/home/configuser/os-security-2026.09.tar.gz.sha256
Can I perform only the Access asset bundle upgrade?
Yes.
Supply only the Access asset bundle:
sudo access-wizard upgrade \
--asset-bundle /home/configuser/access-bundle-26.10.0.0.zip
The corresponding .sha256 file must also be present:
/home/configuser/access-bundle-26.10.0.0.zip.sha256
I already have an earlier Access Wizard installed. Do I need to uninstall it?
No.
Upgrade the Wizard in place using the 26.10 RPM:
sudo dnf install -y /home/configuser/access-wizard-26.10.0.noarch.rpm
Do not delete the existing Wizard state or Access cluster directory.
How do I know that the upgrade succeeded?
Do not rely only on wso version.
Confirm all of the following:
-------------------------------------------------------------
Upgrade complete
-------------------------------------------------------------
The OS package and Access asset upgrade finished on this cluster.
Total elapsed time: 145 min 41 sec.
Access Wizard 26.10.0
Access before: 26.07.0.0-2026.07.13-528-eb05a4e
Access now: 26.10.0.0
Recommended next checks:
wso healthcheck
wso access check-service-readiness
Only after these validations succeed should the upgrade be considered complete.
War diese Seite hilfreich?