Upgrade the Cortex XSOAR Server - Upgrading the Cortex XSOAR server including preparation, upgrade and post upgrade steps. - Administrator Guide - 6.13 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Administrator Guide
Product
Cortex XSOAR
Version
6.13
Creation date
2024-04-15
Last date published
2026-06-01
Category
Administrator Guide
Abstract

Upgrading the Cortex XSOAR server including preparation, upgrade and post upgrade steps.

The installer automatically detects the existing configurations and applies them to the upgraded server.

When performing an upgrade, the following core content packs may automatically upgrade to a newer version:

Before you begin

  • If you are using a server with Elasticsearch for indicators only, you need to migrate all the data to Elasticsearch using the Migration Tool before upgrading.

  • Verify that your system meets the system requirements, including the required operating system.

  • You can upgrade by up to two versions at a time. For example, if you want to upgrade to Cortex XSOAR 6.13 and you are in Cortex XSOAR 6.2, you upgrade to Cortex XSOAR 6.4 >  Cortex XSOAR 6.6 > Cortex XSOAR 6.8 >  Cortex XSOAR 6.10 >  Cortex XSOAR 6.12 >  Cortex XSOAR 6.13.

  • You can upgrade multi-tenant deployments, including high availability or disaster recovery.Upgrade Your Multi-Tenant Deployment

  • (High Availability) - When upgrading a high availability environment, you must stop the demisto service on all application servers prior to performing the upgrade.

  • Rolling upgrades are not supported.

How to upgrade

  1. Prepare the Cortex XSOAR server for upgrade.

    1. Take a snapshot of the server.

    2. Back up your content by selecting Settings > About > Troubleshooting > Export.

    3. Disable any external systems that push incidents to Cortex XSOAR, such as Splunk and Elasticsearch.

    4. Obtain a list of integrations that are in a failed state by running the !FailedInstances command in the CLI. This is useful to compare after upgrade.

    5. Download the new installer from Cortex Gateway.

      1. Log in to Cortex Gateway.

      2. Locate the specific tenant you want to upgrade.

      3. Click Re-Download On-Prem.

        By default, the Production-Standalone license is selected. You can also select Dev.

      4. Click Next.

      5. Under Choose Download Option, select Installer.

        Note

        If you are using the same license, deselect Download License file(s).

      6. Select the checkbox to agree to the terms and conditions of the license and click Download.

        Tip

        In Google Chrome, to download the image and license files together, you may need to set the browser Settings → Privacy and security → Site settings → Additional permissions → Automatic downloads to the default behavior Sites can ask to automatically download multiple files.

        Two files download: the demistoserver-xxxxx.sh installer file and a zipped JSON license file.

        Note

        You can copy the download link button from the Downloads section in your browser to get the token needed for offline installation.

  2. Copy the file to all the servers that will be upgraded.

    (Optional) If using a specific target directory: Cortex XSOAR uses the /tmp folder for installation. If the folder is blocked by policy, you need to specify a new directory or use /var/tmp directory by adding the -target argument to installation before any other flag. For example, sudo ./demisto.sh -target /var/tmp --multi-tenant

  3. (Disaster Recovery and High Availability only) Run the following command to stop the Cortex XSOAR server.

    sudo service demisto stop

    If you are using backup servers for Disaster Recovery, first stop the primary server and then any backup servers.

    For High Availability, stop all app servers.

  4. (Optional) If you are deploying Cortex XSOAR using a signed installer (GPG), you need to import the GPG public key that was provided with the signed installer. Open a ticket with Palo Alto Networks support to get the public key (see here).

    Note

    You may also need to manually install the makeself package by running the yum install makeself command.

    For example, you can use the rpm --import public.key command to import the public key into the local GPG keyring. Note that each operating system has specific requirements.

  5. Allow the .sh file to run as an executable file by running the following command.

    chmod +x demisto.sh

  6. Execute the .sh file by running the following command.

    sudo ./demisto.sh

    For Disaster Recovery, run the installer on the secondary (backup) server. Once it is up and running, run the installer on the primary server.

    For High Availability, run the installer file on one app server to trigger the database upgrade. When available, log in to the app server. You can then upgrade any additional app servers.

  7. Accept the EULA and add the information when prompted.

    1. The Server HTTPS port (default is 443)

    2. If you are using Elasticsearch, enter the Elasticsearch details, such as the URL, timeout, etc.

    3. Type the name of the Admin user (default is admin).

    4. Type the password (default is admin).

  8. After the upgrade completes, do the following.

    1. Confirm the Cortex XSOAR server status is active by running the systemctl status demisto command.

      If the server is not active, run the systemctl start demisto command to start the server.

    2. Confirm the Docker service status is active by running the systemctl status docker command.

    3. Check that all custom content prior to upgrade appears.

    4. Check that all incidents prior to upgrade appear.

    5. Run the !FailedInstances command to compare the results in step 1 and fix any failed instances.

    6. Ensure all integrations that were enabled prior to upgrade are available in the CLI/Playbooks.

    7. Upgrade any existing engines.

    8. Enable the external systems you disabled in step 1c.

    Note

    If you are upgrading from version 6.0 or older, all installed incident types are in a Detached state, which means that updates from content packs do not affect the incident type configuration. If you want to receive content updates for detached incident types, you must manually reattach the incident type.