Skip to main content

September 3, 2026

Update Omnissa Access Control Plane Deployments

This topic describes the recommended procedure for updating an existing Control Plane-based Omnissa Access deployment. It covers updating operating system packages, the Control Plane asset bundle, Access services, and the bootstrap VM.

Important: These update instructions are not applicable for upgrading versions 2412 or earlier.

Prerequisites

  • Run all commands from the bootstrap VM unless otherwise specified.
  • The existing deployment must be healthy. Run wso healthcheck and wso access check-service-readiness to confirm system health before you begin.
  • The offline asset bundle for the target release is downloaded and available in the bootstrap VM.
  • The OS security RPM is downloaded and available in the bootstrap VM, if this update includes OS package updates.

Update Workflow

An update consists of the following phases:

  1. Update Phase 1 - Download and configure the local repository for operating system updates (only when operating system package updates are required).
  2. Update Phase 2 - Download and configure the new Control Plane asset bundle.
  3. Update Phase 3 - Update the Control Plane, optionally including OS package updates.
  4. Update Phase 4 - Update Access services and validate services status.
  5. Update Phase 5 - If Update Phase 1 was applicable, update the bootstrap VM operating system.

Regardless of which phase you start from, complete the Prep section below first.

Prep - Export Shell Variables

Set the following variables in your shell before you begin. Later phases depend on them, including phases you might start from directly if you skip Update Phase 1.

export WORKDIR="/opt/wss/<cluster_name>"
export BOOTSTRAP_IP="<bootstrap-node-ip>"
export TARGETS="general_compute_linux:general_compute_access_linux"
export ASSET_DIR="${WORKDIR}/assets-<version>"

Update Phase 1 - Configure the Local Repository for OS Updates

Note: If this update does not include operating system package updates, skip to Update Phase 2 - Configure the New Asset Bundle.

Procedure:

  1. Untar the OS security RPM file you downloaded.

    tar -zxvf <filename>
    # Where <filename> is the name of the  OS security RPM file.
    
  2. Run the DNF repository update script on the bootstrap VM:

    sh /usr/local/sbin/update-dnf-repo.sh /opt/wss/<filename>
    
  3. Enable the local repository on the bootstrap VM and stage its CA certificate for distribution to the cluster nodes:

    sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/localrepo.repo
    mkdir -p ${WORKDIR}/access/localrepo_ca_path
    cp -f /etc/nginx/localrepo-certs/root-ca.crt \
      ${WORKDIR}/access/localrepo_ca_path/root-ca.crt
    
  4. Push the local repository configuration to the cluster nodes:

    1. Create the certificate directory on the cluster nodes:

      wso control-plane ansible -- -b -m file \
        -a "path=/etc/nginx/localrepo-certs state=directory owner=root group=root mode=0755" \
        "${TARGETS}"
      
    2. Copy the root CA certificate to the cluster nodes:

      wso control-plane ansible -- -b -m copy \
        -a "src=/workdir/access/localrepo_ca_path/root-ca.crt dest=/etc/nginx/localrepo-certs/root-ca.crt owner=root group=root mode=0644 force=yes" \
        "${TARGETS}"
      
    3. Point the cluster nodes at the bootstrap HTTPS repository:

      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=baseurl value=https://${BOOTSTRAP_IP}/" \
        "${TARGETS}"
      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslverify value=1" \
        "${TARGETS}"
      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslcacert value=/etc/nginx/localrepo-certs/root-ca.crt" \
        "${TARGETS}"
      wso control-plane ansible -- -b -m ini_file \
        -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=enabled value=1" \
        "${TARGETS}"
      
    4. Rebuild the DNF cache on the cluster nodes only from the local repository. This step must be repeated if you are applying multiple updates on top of the released version.

      wso control-plane ansible -- -b -m shell \
        -a "dnf clean all && rm -rf /var/cache/dnf/* && dnf --refresh makecache --disablerepo='*' --enablerepo=localrepo && dnf --refresh --disablerepo='*' --enablerepo=localrepo list available" \
        "${TARGETS}"
      

Update Phase 2 - Configure the New Asset Bundle

Procedure:

  1. Create a directory for the new asset bundle and download it:

    mkdir -p ${ASSET_DIR}
    cd ${ASSET_DIR}
    # Copy the target release asset bundle to this location ${ASSET_DIR}
    

    Important: Download the asset bundle that corresponds to your target release. Do not reuse a bundle from an older release.

  2. Extract the bundle and add the CLI to your path:

    # Ensure that you are in ${ASSET_DIR} before you unzip the asset bundle
    unzip asset-bundle.zip
    cp cli-distribution/linux/wso /usr/bin/
    cp: overwrite '/usr/bin/wso'? y # It will prompt for overwrite
    wso eula
    Do you agree to these terms ? [y/n]: y
    
  3. Configure the CLI to use the new bundle:

    cd ${WORKDIR}
    wso configure ${ASSET_DIR}
    

Update Phase 3 - Update the Control Plane

Procedure:

  1. Deploy the Control Plane with the new asset bundle. Include -u if this update also updates OS packages on the cluster nodes:

    #  To update without OS packages update
    nohup wso cp deploy &
    # To update with OS packages update
    nohup wso cp deploy  -u &
    

    This step will take some time to complete.

  2. Verify the deployment:

    wso version
    wso healthcheck
    
  3. If you deployed with -u, unseal the cluster:

    Note: You can skip this step if you have deployed without -u

    wso cp unseal
    

    This step will take some time to complete.

Update Phase 4 - Update Access Services

Procedure:

  1. Reconcile the Access configuration for the update:

    cd ${WORKDIR}
    wso access update-config set
    
  2. If a services directory exists in the working directory from a prior patch or update, use the command below so the deployment uses the images from the new bundle instead:

    mv ${WORKDIR}/services to ${WORKDIR}/services.bk
    
  3. Deploy all Access services:

    nohup wso services deploy --type full &
    
  4. Check the health of the services:

    wso access check-service-readiness
    
  5. After all services report healthy, exit update mode:

    wso access update-config reset
    
  6. Clean up assets from the previous release:

    wso cp reset-assets
    

Update Phase 5 - Update the Bootstrap VM Operating System

Perform this phase only after the cluster update has completed successfully. You can perform your cluster operations once you complete Update Phase 4.

For this phase, choose either to perform in-place update or to replace the VM.

In-Place Update

  1. Update packages and reboot the bootstrap VM:

    dnf update -y
    reboot
    
  2. After the bootstrap VM comes back online, validate the cluster:

    wso healthcheck
    wso access check-service-readiness
    

Replace the VM

Use this option when you want to deploy a new bootstrap VM from the latest Omnissa OVA instead of patching the existing bootstrap VM in place. This approach is recommended for major OS updates.

Step 1 - Create a Migration Package from the Existing Bootstrap VM

cd /opt/wss/<cluster_name>

tar czpvf /opt/wss/<cluster_name>-migration-$(date +%Y%m%d).tar.gz \
  profile.yml \
  logging \
  telegraf_plugin \
  ansible_extra_vars.yml \
  access \
  cp-cluster \
  additional_env_vars.env \
  deploy_services.log \
  deployment-config.yml

Step 2 - Copy the Migration Package to the New Bootstrap VM

scp /opt/wss/<cluster_name>-migration-*.tar.gz configuser@<new-bootstrap-machine>:/home/configuser/

Step 3 - Restore the Configuration on the New Bootstrap VM

mkdir -p /opt/wss/<cluster_name>
cd /opt/wss/<cluster_name>

tar xzpvf /home/configuser/cp-cluster-migration-*.tar.gz

The new bootstrap VM now contains the same deployment configuration as the previous bootstrap VM.

Step 4 - Configure the Asset Bundle

Copy the asset bundle used with the existing bootstrap VM to the new bootstrap VM and then execute the steps that follow.

mkdir -p assets
cd assets
# COPY asset bundle at this path.
unzip asset-bundle.zip
cp cli-distribution/linux/wso /usr/bin/
wso eula
wso configure /opt/wss/<cluster_name>/assets/
cd ..

Step 5 - Validate the New Bootstrap VM

wso version
wso healthcheck
wso access check-service-readiness

Verify that the CLI version, Control Plane image version, CPS image version, cluster health, and Access service readiness are all correct. All Access services should report a status of READY.

Was this page helpful?

Provide feedback for this topic

Was this topic helpful?

Please do not include any personal or confidential information.

Generating link…