Upgrade Preparation Tasks

Complete the following tasks to prepare for the upgrade to NetWitness

Warning: The RSA S4 and S4s appliances reached the End of Life (EOL) in June 2021. We recommend that you discontinue installation or upgrade activities on these and upgrade to new hardware. For more information on End of Life hardware support, see https://community.netwitness.com/t5/product-life-cycle/product-version-life-cycle-for-rsa-netwitnessplatform/ta-p/569875.

Task 1. (Optional) Remove Legacy Package Repositories

Perform this task to free up space by removing unused repositories from previous releases from your system.

  1. Determine the version of the oldest NetWitness Platform host in your environment by reviewing the host list in the Admin user interface, or by running the following command on the NW Server: upgrade-cli-client --list
  2. You can safely remove all legacy package repository folders located at /var/netwitness/common/repo/<version> on the NW Server for all versions prior the baseline major release version of the oldest active host in the environment.
    • If the oldest host version is 11.7.x.x, you can safely remove 11.0.x.x, 11.1.x.x, 11.2.x.x, 11.3.x.x, 11.4.x.x, 11.5.x.x, and 11.6.x.x repository folders. However, do not remove repository versions greater than or equal to
    • If the oldest host version is 11.3.x.x, you can safely remove 11.0.x.x, 11.1.x.x, and 11.2.x.x repository folders. However, do not remove repository versions greater than or equal to

Task 2. Backup and Remove the Rotated RabbitMQ Logs

Before upgrading from 11.6.x or 11.7.x to, you must remove the old RabbitMQ logs and free up the space in /var/log mount disk. Follow the below procedure to free up the space in /var/log mount disk.

  1. Backup the rotated RabbitMQ logs into var/netwitness directory. Do the following.

    mkdir /var/netwitness/rabbitmq_logsbkp

    scp -r /var/log/rabbitmq/ /var/netwitness/rabbitmq_logsbkp

  2. Remove the rotated RabbitMQ logs from /var/log/rabbitmq pre-upgrade. Do the following.

    cd /var/log/rabbitmq

    rm -f rabbit\@<sa-uuid>.log.*

    rm -f rabbit\@<sa-uuid>_upgrade.log.*

    rm -f *.gz

    rm -f rabbit@<sa-uuid>.log-*

    - This procedure must be performed only once before upgrading to Post-upgrade, the RabbitMQ service automatically handles the log rotation.
    - The command rm -f rabbit\@<sa-uuid>.log.* is used to clean up the old uncompressed logs such as log.1, log.2, and log.3.
    - The command rm -f rabbit\@<sa-uuid>_upgrade.log.* is used to clean up the old uncompressed upgrade logs.
    - The command rm -f *.gz is used to clean up the old compressed logs.
    - The command rm -f rabbit@<sa-uuid>.log-* is used to clean up the old uncompressed logs rotated with logrotate.

Task 3. Uninstall the Security Analytics l10n language pack

Before you upgrade from 11.6.x.x to 11.7.x.x or version, you must uninstall the Security Analytics l10n language pack.

Task 4. Preparing ESA Deployments for Migration to

Before upgrading to, NetWitness recommends that all the ESA deployments maintain an error-free state and remove any unused ESA deployments, as ESA deployments will be migrated to policies and groups after upgrading to

Note: Make sure that you plan the upgrade process so that Correlation servers are upgraded immediately after the Admin Server is done. The deployments will not be accessible until the corresponding Correlation servers are upgraded. This action will not affect the events and alerts processing by correlation servers.

IMPORTANT: If there is any need to import ESA Rules and Enrichments. NetWitness recommends importing those missing rules and enrichments before the upgrade.

The pre-upgrade and post-upgrade states of deployments are represented in the following table.

SlNo Pre-upgrade Deployment State Post-upgrade Deployment State
Creates Policy Creates Group The policy will be Published
1 Healthy deployment




2 Deployment with errors Yes Yes Yes
3 Deployment with only rules




4 Deployment with no rules No No No

Healthy deployment contains no errors, and the required resources such as ESA Server, Data source, and ESA rule are added.

Note: NetWitness recommends that all the deployments maintain an error-free state and also remove any unnecessary or unused ESA deployments.

Task 5. Backup Elasticsearch Data (Users, Entities, Alerts, and Indicators)

Before upgrading the UEBA host to, you must perform the backup of your Elasticsearch data such as Users, Entities, Alerts, and Indicators (using the Elasticsearch migration tool) to retain them post upgrade.


Make sure the following prerequisites are met before you perform data backup:

  • The current Elasticsearch version must be 5.5.0.

  • Presidio rpms version must be less than or equal to

  • ueba_es_migration_tool.zip file must be downloaded.

    Note: ueba_es_migration_tool allows you to migrate presidio Elasticsearch data from Elasticsearch version 5.5.0 to 7.15.2 while upgrading the UEBA host to from and older versions. This tool contains elk-migration-script.sh script file and presidio-elk-migration-1.0.0.jar file and it can be downloaded from https://community.netwitness.com/t5/netwitness-platform-downloads/ueba-elasticsearch-migration-tool/ta-p/687496.

To backup the Elasticsearch data:

  1. Select the available directory and unzip the ueba_es_migration_tool.zip file.

  2. Go to cd ueba_es_migration_tool. Run the following command.

    sh elk-migration-script.sh

    The Elasticsearch migration tool guide is displayed.


  3. Select Export documents from elasticsearch 5.5.0 and enter yes when prompted to stop the airflow scheduler.

    Note: When you enter yes, the airflow scheduler stops consuming the fresh incoming data such as Users, Entities, and Alerts. This avoids data loss during the export process.

  4. In the next step, select Fresh Export to export the existing data.


    - If the Export operation fails due to some technical issue, select Resume Export once the issue is resolved, to resume the Export operation.
    - Go to <backup_directory_path>/log/log/es-migration-export.log if you want to view the log for the succeeded or failed processes.

    Task 6 (Optional). Disable STIG-based FIPS Kernel Controls

    If you enabled STIG-based FIPS Kernel controls, you must disable them before initiating the NetWitness Platform upgrade process to avoid boot errors. To disable STIG-based FIPS Kernel controls, run the following commands:

    manage-stig-controls --disable-control-groups 3 --host-all

    grub2-mkconfig -o /boot/grub2/grub.cfg

    After you upgrade NetWitness Platform, ensure that you enable STIG-based FIPS Kernel controls.

    Note: STIG-based FIPS Kernel controls which require modifications to kernel boot options are not enabled by NetWitness out-of-the-box.

    Task 7 (Optional). Verify Connection for Live Server

    Go to admin/system/live services and do a test connection to verify if you are able to connect to the live server as this is essential for the source-server from 12.x and above. This is an optional step and applicable only for customers who have configured live.