Here’s how to troubleshoot the issue:

If the issue is not resolved, please contact Netskope Support.

You need to check the status of the cloud exchange container. Check the status using these commands:

For Ubuntu/CentOS:
sudo Docker ps

For RHEL:
sudo podman-compose ps

If the containers are not running, use this command to start the containers:
./start

If you are using RHEL, make sure SELinux is disabled, because Cloud Exchange is not officially tested on SELinux. We recommend that you disable the SELinux.

Also check the status of ipv4 forwarder status using this command:
systemctl net.ipv4.ip_forward

If the value of this command is 1, that means it is enabled. But if the value is 0, then you need to enable this by executing this command:
systemctl net.ipv4.ip_forward=1

In order to check the container status, you need to go to the folder ta_cloud_exhange.

If your containers are running, then you need to check your network connectivity of the host machine. You can use these commands to check the connectivity:
curl -v <IP of Local Host>:443 [i.e curl -v 127.0.0.1:443]
curl -v www.github.com:443

If the connectivity is working, then you check by restarting CE. Use these command to restart CE:
./stop
./start

Also, there is a possibility that your SSL certificate has expired. If you are using any corporate SSL certificates, then validate the certificate. If you are using the default Cloud Exchange SSL certificate, then the certificate is valid for one year. Check that also.

If the certificate has expired, then follow the instructions in this document.

Now try rebooting the VM.

Scenario: In older versions of CE user might start seeing errors related to the importing of plugins continuously.

Impact: CE is functioning correctly but import errors are continuously getting logged in CE Audit logs.

Resolution: There is no functional impact of this error, so you can safely ignore this error.

Issue Description

When attempting to save the plugin, you encounter the following error:

Error: Value error, Validation error occurred. No AWS Credentials were found in the environment. Deploy the
plugin into AWS environment or use AWS IAM Roles Anywhere authentication method.

When you face this error the primary reason is likely related to the “HTTP PUT response hope limit” configured at your AWS EC2 instance metadata. It determines how far HTTP requests to the Instance Metadata Service can travel in the network before being discarded.

What to Do

To resolve this issue, youʼll need to increase the “HTTP PUT response hop limit” on your EC2 instance. Based on your preference, proceed with one of the options below to update this setting.

Option 1 : Update Metadata Settings via AWS Console

1. Navigate to EC2 instance in the AWS Console < Select the EC2 instance < Actions < Modify Instance Metadata Options.

2. Once you click on the “Modify Instance Metadata Options” you will see something like below.

3. You likely find the Default hop limit set to 1. This means the metadata response will only go to the originating instance, and not be routed beyond that. Update the “HTTP PUT response hope limit” value to 3 and save the configuration.

4. Once done Navigate to Cloud Exchange and try to save the plugin. It should result in successful plugin configuration.

Option 2 : Use AWS CloudShell (Command Line)

If you prefer using the CLI or donʼt see the option in the console:

1. Open AWS CloudShell.

2. Check the current hop limit (replace i-xxxxxxxxxxxxxxxxx with your EC2 instance ID):

aws ec2 describe-instances --instance-ids i-xxxxxxxxxxxxxxxxx --query
'Reservations[].Instances[].MetadataOptions'

3. Verify the current value of the http-put-response-hop-limit parameter.

4. Update the hop limit to 3 (replace i-xxxxxxxxxxxxxxxxx with your EC2 instance ID):

aws ec2 modify-instance-metadata-options \
2 --instance-id i-xxxxxxxxxxxxxxxxx \
3 --http-put-response-hop-limit 3

5. Confirm the change using below command.

aws ec2 describe-instances --instance-ids i-xxxxxxxxxxxxxxxxx --query
'Reservations[].Instances[].MetadataOptions'

6. When done, go to Cloud Exchange and try to save the plugin. It should result in successful plugin configuration.

RabbitMQ Container status is showing down. To troubleshoot: Open CE UI and check container status for RabbitMQ container in Each node and if RabbitMQ Container status is down in majority of nodes, perform these steps: 

1. Open RabbitMQ Management UI this URL:

http://<CE_UI_IP>:15672/

Username: user Password: Maintenance password of CE  If you have observed these errors:Network partition Detected.mnesia reports that this RabbitMQ cluster has experienced a network partition. Steps to Resolve Network partition issue 1. Stop containers one by one using stop script:

$ sudo ./stop

2. Start CE nodes again one by one(Run Start script in primary node first):-

$ sudo ./start

3. Monitor CE Home dashboard and RabbitMQ Dashboard as well. Note: In queue ingestion/sharing tasks will be lost present in CE that are not yet performed by CE.

Scenario: If you are modifying an existing cluster and experience clustering issues after halting with the stop script and then initiating with the start script, particularly during node addition/removal or migration, this problem may arise.

Resolution: If your message is as below that means there was some issues while removing instance2 from the cluster. “Node ‘rabbit@instance1’ thinks it’s clustered with node ‘rabbit@instance2’, but ‘rabbit@instance2’ disagrees”

1. Execute the stop script in the instance2.
   $ sudo ./stop
2. Go to the instance1 and execute below command. (make sure to replace the instance1 with the actual IP or hostname). If you are running docker, use this command:
   $ docker-compose -f docker-compose-ha.yml exec -- rabbitmq-stats rabbitmqctl forget_cluster_node rabbit@instance2
   In case of podman, use this command:
   $ podman-compose -f podman-compose-ha.yml exec -- rabbitmq-stats rabbitmqctl forget_cluster_node rabbit@instance2
3. Then execute start script in instance2.
   $ sudo ./start

Scenario: While executing the setup script, you might see the following error due to a system specification that is not compatible with CE: CE Sizing Profile Check: Failed for Large profile” or “CE Sizing Profile Check: Failed for Medium profile”.

Impact: You will not be able to configure the CE until the minimum system requirements are met.

Resolution:

• Make sure your machine has exactly 8 or 16 CPU count to determine the medium or large profile respectively.
  Note that if the machine is deployed on an on-premises infrastructure, update the CPU count to match the profile as per your requirements. If the machine is deployed on a cloud infrastructure (like AWS, Azure), you will need to create a new instance.
• For medium profile minimum RAM and Total disk space is 16GB and 80 GB, respectively.
• For large profile minimum RAM and Total disk space is 32GB and 120 GB, respectively.
• Minimum 20 GB free disk space is required for both profiles.

If you encounter freezing or inaccessibility of the Cloud Exchange UI from your browser, this may be related to a configuration requirement in Docker/Podman environments. Docker specifically requires the net.ipv4.ip_forward setting to be enabled for outbound connectivity (https://github.com/moby/moby/issues/490). It’s important to note that while Docker expects users to enable this setting manually, Podman handles this differently, see https://github.com/containers/podman/issues/399.

If you encounter any errors during the installation, migration, or upgrade of Cloud Exchange, we’re here to assist you. Please follow the steps below to get help:

1. Open a Support Ticket: If you encounter any error during installation, migration, or upgrade of Cloud Exchange, please open a support ticket with Netskope support. Our team of engineers will promptly assist you in resolving the issue.
2. Provide Relevant Details: When opening a support ticket, please ensure to include the following details:
   • Platform logs: You can export platform logs by going to Cloud Exchange > Logging > Export Logs.
   • Diagnostic logs: Refer to the documentation here to collect diagnostic logs.

Additional Resources:

For detailed documentation on various aspects of Cloud Exchange, please refer to the following links:

• For Installation: Installation Documentation
• For Upgrading and Migration: Upgrading to the Latest Version Documentation
• For High Availability Deployment: High Availability Deployment Documentation

We’re committed to ensuring a smooth experience with Cloud Exchange and are here to support you every step of the way.

The error message is this:

Network netskope-cloud-threat-exchange-docker-compose_default Error 0.0s failed to create network netskope-cloud-threat-exchange-docker-compose_default: Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network.

The issue is specific to the network of the machine. The docker network conflicts with the host network and because of that the docker network is not created successfully. To change the network configuration of the docker you can refer to: https://docs.docker.com/compose/compose-file/06-networks/

Possible Root Cause

• Core Container was restarting. Check the core container status using these commands:.
  

  docker ps [Ubuntu]
  podman-compose ps [RHEL]

1. First review the dore container logs.
   

   docker compose logs -f core [Ubuntu]
   podman-compose logs -f core [RHEL]

   If you observe the below error, it indicates that the Core container is not able to connect to the RabbitMQ container.
   

   PLAIN login refused: user 'user'

   First you can remove the RabbitMQ data using this command.
   Go to Cloud Exchange folder.
   

   rm -rf data/rabbitmq/data/rabbit@rabbitmq-stats*

   But this will result in data loss of current queues. Another step is to re-create the RabbitMQ user.Log in in to RabbitMQ container.
   

   docker exec -ti <Container ID> sh
   podman exec -ti <Container ID> sh

• List Users
  

  rabbitmqctl list_users	

  Delete Existing User
  

  rabbitmqctl delete_user user

  This adds a new user and password.
  

  rabbitmqctl add_user user <MAINTENENCE_PASSWORD>

  This makes the user an administrator.
  

  rabbitmqctl set_user_tags user administrator

  This sets permissions for the user.
  

  rabbitmqctl set_permissions -p / user "." "." ".

There are 3 possible causes:

1. Mongo data directory permission issue.
2. The Core/Mongo-DB container is down.
3. The CE maintenance password is incorrect.

1. For the Mongo data directory permissions issue

Verify

Execute ls -lRn . inside the directory with docker-compose.yml.

The mongo-data dir should be read/write accessible to the user with UID 1001.

./data/mongo-data:
total 0
drwxr-xr-x. 3 1001 0 16 Apr 14 18:16 data

Solution to mongo data directory permissions issue:

Execute the setup script again using ./setup to fix the file permissions.

Restart CE.

2. For the core/mongo-db container is down issue

Verify

Check the container status using sudo docker-compose ps, all the containers should be Up.

$ sudo docker-compose ps
Name Command
State Ports
---------------------------------------------------------------------------------------------------------------- 
ce_330_core_1 /bin/sh start.sh Up 80/tcp
ce_330_mongodb-primary_1 /opt/bitnami/scripts/mongo ... Up 0.0.0.0:27018->27017/tcp ce_330_rabbitmq-stats_1 /opt/bitnami/scripts/rabbi ... Up 15671/tcp, 0.0.0.0:15672->15672/tcp, 25672 /tcp, 4369/tcp, 5551/tcp, 5552/tcp, 5671/tcp, 0.0.0.0:5672->5672/tcp
ce_330_ui_1 /bin/sh start.sh Up 0.0.0.0:443->3000/tcp, 80/tcp ce_330_watchtower_1 /watchtower --http-api-update Up 0.0.0.0:8080->8080/tcp

Solution to core/mongo-db container is down:

If any containers are down follow the below steps:

sudo docker-compose down
sudo ./start

3. For the maintenance password is incorrect Issue

Verify

Check the core logs using `sudo docker-compose logs core` for any “authentication error”.

Check if the customer is using CE version 3.2.0 or below 3.2.0 with the same MongoDB.

Solution to the maintenance password is incorrect:

Perform these steps:

sudo docker-compose down
sudo rm -rf .env
sudo ./setup
Add maintenance password as "cteadmin"
sudo ./start

A special character was potentially used for the maintenance password during setup, which RabbitMQ does not support and causes issues with other services attempting to schedule tasks as cross-container communication fails to engage RabbitMQ.

Run the following commands from the directory where docker-compose.yml resides to reconfigure the maintenance password:

sudo docker-compose down
sudo rm -rf .env
sudo ./setup
Add maintenance password.
sudo ./start

This issue arises because Podman does not include the facility to automatically restart containers after a reboot. This behavior is particularly relevant for users of RHEL (Red Hat Enterprise Linux) servers where Podman is commonly used. Users will need to manually start the containers post-reboot. Here are the detailed steps to do so:

1. Go to the Cloud Exchange Directory:

$ cd <ce_directory>

Note that for CE as a VM, the Cloud Exchange directory is:

/opt/cloudexchange/cloudexchange

2. Check the Status of the Containers:

$ podman-compose ps

3. Start Cloud Exchange:

$ ./start

For users operating with Docker on other VMs like Ubuntu or CentOS, there’s no need to take any manual action for container restarts. Docker includes an auto-restart feature that ensures containers automatically restart after a reboot. This automatic restart functionality provides a seamless experience without the need for manual intervention post-reboot.

Cloud Exchange (CE) may become inaccessible after a restart, migration, or infrastructure change. This can appear as the web UI not loading or core services failing to start.
A common reason is that the system does not have AVX (Advanced Vector Extensions) support, which is required by MongoDB 5.0+ (used in CE).

Typical Symptoms

• CE web interface shows errors (e.g., 400 Bad Request).
• mongodb-primary and core containers are in an exited state, while other containers (UI, RabbitMQ) are still running.

CE was working fine earlier but became inaccessible after a restart, migration or upgrade.

Root Cause

MongoDB 5.0+ requires CPUs with AVX instructions. If the host machine (physical or virtual) does not support AVX or if AVX is disabled MongoDB cannot start, which in turn stops core CE services.

Steps to Troubleshoot

• Check container status
  podman ps -a

• Look at the state of mongodb-primary and core containers.

• Review MongoDB logs
  From the CE directory, run:
  sudo docker-compose logs -f mongodb-primary | grep "AVX"

• If AVX support is missing, you will see warnings like:
  MongoDB 5.0+ requires a CPU with AVX support, and your current system does not appear to have that!

• Check AVX availability
  lscpu | grep -i avx

Resolution

• Ask your IT/VM team to confirm and enable AVX support on the host or VM.
• For virtual machines, ensure AVX is exposed to the guest system.

After enabling AVX, restart CE services:

• podman-compose down && podman-compose up -d

Confirm that MongoDB and core containers start successfully, and that the CE UI is accessible.

Next Step: If AVX is enabled but the issue continues, please share logs/screenshots with the support team so we can assist further.

Issue Overview

Cloud Exchange UI inaccessible due to missing DNS resolution getting “Hostname does not resolve error when try to execute any command in Cloud Exchange Host Machine”

Typical Symptoms

• Cloud Exchange UI is not accessible.
• When you try to restart the Cloud Exchange, getting Hostname does not resolve error.

Root Cause

The file which contains all the DNS configuration got removed. Due to this, the machine is not able to resolve the hostname.

Steps to Troubleshoot

1. Check the DNS resolution on the Cloud Exchange server by attempting to run basic Docker commands:

   sudo docker ps

2. If you receive Name does not resolve errors, proceed to next step.
3. Verify the existence of the resolv.conf file:

   cat /etc/resolv.conf

4. If the resolv.conf file is missing, create it and add your DNS server details:

   vi /etc/resolv.conf

5. Add your DNS server entries in the following format:

   nameserver [DNS_SERVER_IP_1] 
   nameserver [DNS_SERVER_IP_2]

6. Save this file.
   • Press Esc
   • Type :wq!
   • Press Enter (key)
7. Reboot the machine to apply the DNS configuration changes.
8. Verify that all Docker containers are running properly:

   sudo docker ps

9. Ensure the following containers are up and running:

   cloudexchange_ui_1
   
   cloudexchange_core_1
   
   cloudexchange_rabbitmq-stats_1
   
   Cloudexchange_mongodb-primary_1

10. If still facing the issue, please collect the diagnose logs and create a support case. For diagnostic log generation troubleshooting, refer to: Generate Diagnostic Logs.

Issue Summary:

• While installing Cloud Exchange in your RHEL server, you are observing the following error: “Could not verify Podman/Podman-compose/Podman-plugins version of the machine” and you have confirmed that podman, podman-compose, and podman-plugins are already installed on the server as per the following guideline documentation here.

Common Symptoms:

Firstly, please check the python3 version on your server:

• Please confirm the python3 version in your machine using the command: python3 --version

If you are using Python 3.6.8 or older version on your server, then this is the reason for your issue.

Root Cause:

• With python 3.6.8 and its associated pip3, the podman-compose is installed and causes conflicting issues.

Troubleshooting Steps/Resolution:

Please note that Cloud Exchange utilizes python 3.11 or above as we have highlighted in the following documentation as well: /en/cloud-exchange-system-requirements#system-specifications

Hence, we recommend you to please remove podman-compose and then install python3.11 and then reinstall podman-compose. Please follow below steps:

• Remove podman-compose using command:
  sudo pip3 uninstall podman-compose
• Install python3.11 and setting alternative:
  yum install -y python311
yum module enable python311
alternatives --set python3 /usr/bin/python3.11
python3 --version (should point to Python 3.11.x)
• Podman-compose installation commands:
  sudo pip3 install podman-compose
sudo ln -s /usr/local/bin/podman-compose /usr/bin/podman-compose (soft link for podman-compose)

Once these steps are completed, you can confirm the podman-compose version using the previously shared command and then you move forward with Cloud Exchange installation with setup script execution.

Reference:

• For your reference, you can review this guide wherein CE system specifications are highlighted: CE System Specifications

Issue Summary: Setup script fails during fresh installation or upgrade/migration with the following error message:

Incompatible versions found for pyyaml. Please make sure the dependencies (pyyaml>=6.0.0 | python-dotenv>=0.20.0,<=1.0.0 | pymongo>=4.6.3，<=4.7.3) are satisfied before running •/setup script.

Common Symptoms: Either the python dependencies are not present or the version is not compatible with the current CE version being installed.

Root Cause:

Potentially, due to CE upgrade from a lower to a higher version, the supported minimum versions were upgraded or during a fresh installation all the dependencies were not installed properly.

Troubleshooting Steps/Resolution:

First, navigate to the cloudexchange root directory where the environment is stored.

Cloud Exchange as a VM Deployment

cd /opt/cloudexchange/cloudexchange

If using Containerized Deployment

cd  <ta_cloud_exchange_directory>

Recreate the Virtual Environment

python3 -m venv --clear .cevenv

Activate the Virtual Environment

source ./.cevenv/bin/activate

Install Required Packages

pip3 install "pyyaml>=6.0.0" 

pip3 install "python-dotenv>=0.20.0,<=1.0.0" 

pip3 install "pymongo>=4.6.3,<=4.7.3"

Deactivate the Environment

deactivate

Issue Summary: Setup script fails during HA setup due to input/output error .

Troubleshooting Steps/Resolution:

First, navigate to the cloudexchange root directory where the environment is stored for that particular node.
Cloud Exchange as a VM Deployment

cd /opt/cloudexchange/cloudexchange

If using Containerized Deployment

cd  <ta_cloud_exchange_directory>

Run the this command (replica 1for first secondary node else replica 2 for second secondary node)

gluster volume remove-brick CloudExchange replica 1 <node_ip>:/opt/shared/gluster/bricks/1/brick force 

Run this on primary node

gluster peer detach <replica node_ip>

umount /opt/shared/data

rm -rf /opt/shared/*

Issue Description

During the execution of the setup script for containerized deployments of Cloud Exchange, users encounter a connection timeout error when attempting to connect to hub.docker.com. This occurs even when network settings appear to permit the connection.

Root Cause

The issue is linked to recent changes on Docker Hub (Docker’s side) and is not related to Cloud Exchange itself.

These changes are causing the Cloud Exchange setup pre-requisite check for Docker Hub to fail specifically for containerized deployments.

Users deploying Cloud Exchange as VM) are not affected by this issue.

 Interim Workaround

While the product team is actively working on a permanent fix, you can use the following workaround:

1. Standalone Deployments

For standalone deployments only, you can bypass the failing prerequisite check by using the –ignore-failures flag with the setup script.

• python3 ./setup --ignore-failures 

2. High Availability (HA) Deployments

For High Availability (HA) deployments, reach out to the support team for assistance with the setup.

Resolution

The team is actively working on a fix for this issue. Please monitor release notes for updates that address this known limitation.

Issue Overview

When a secondary node is added to the Cloud Exchange HA cluster, sometimes because of the network throughput and latency the new docker image pull might take some elongated time. due to which the containers on the new node does not get started automatically.

Steps to start the services on new node

1. Go to the CE installation directory on the newly added secondary node
2. Execute the start script
   sudo ./start
3. Verify the status of the services of newly added node after completion of start script.

Scenario

This guide walks you through completely removing GlusterFS and clearing all leftover FUSE state to permanently resolve the error:

Transport endpoint is not connected

The fix requires three things: uninstalling packages, cleaning all leftover FUSE and mount cache, and rebooting the server. Skipping any step may leave the system in a broken state.

Prerequisites

• Root or sudo access on the affected server
• GlusterFS service must be stopped before proceeding
• Schedule a maintenance window a reboot is required

Resolution

Step 1 — Stop GlusterFS Service:

• For RHEL Operation System

systemctl stop glusterd
systemctl disable glusterd

• For Ubuntu Operating System

Give sudo its own private PATH (secure_path)

Use a python3 that points to 3.11, while leaving the system-wide /usr/bin/python3 untouched.

# 1. install python3.11 
sudo dnf install -y python3.11

# 2. sudo-only bin dir with a python3 -> 3.11 symlink
sudo mkdir -p /usr/local/sudo-bin
sudo ln -sf /usr/bin/python3.11 /usr/local/sudo-bin/python3

# 3. Write the sudoers override LOCALLY first, then copy in
cat > /tmp/python311_secure_path << 'EOF'
Defaults secure_path="/usr/local/sudo-bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
EOF

# 4. Validate BEFORE installing into /etc/sudoers.d
sudo visudo -cf /tmp/python311_secure_path

# 5. Install (only if step 4 said "parsed OK")
sudo install -m 0440 -o root -g root /tmp/python311_secure_path /etc/sudoers.d/python311_secure_path
rm -f /tmp/python311_secure_path

# 6. Re-validate the whole sudoers config
sudo visudo -cf /etc/sudoers

Add an alias Python3 -> 3.11 for Interactive Shells (normal user + root)

# normal user (~/.bashrc)
echo "alias python3=/usr/bin/python3.11" >> ~/.bashrc

# root (/root/.bashrc) — needed separately, root has its own rc file
sudo bash -c 'echo "alias python3=/usr/bin/python3.11" >> /root/.bashrc'

# apply to current shells
source ~/.bashrc
sudo -i bash -c 'source /root/.bashrc'

Configure a Systemd Drop-In Override 

# add a drop-in override (survives ./setup regenerating the base unit file)
sudo mkdir -p /etc/systemd/system/cloud-exchange.service.d
sudo tee /etc/systemd/system/cloud-exchange.service.d/override.conf << 'EOF'
[Service]
Environment="PATH=/usr/local/sudo-bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
EOF

#If the Management Server is running, perform a restart.
sudo systemctl daemon-reload
sudo systemctl restart cloud-exchange

Validate Changes

sudo python3 --version   # -> Python 3.11.x   (via /usr/local/sudo-bin/python3)
python3 --version        # -> python3.11.x       (system default)

Scenario: After migrating to 5.1.0, the CE core container is getting restarted and following errors are observed in the core container logs.

Impact: CE is not accessible.

Resolution: Reach out to Netskope Support team with the diagnostic logs.

Get errors like InvalidReplicaSetConfig while running ./start script while deploying Cloud Exchange with High Availability

During the initialization of a MongoDB replica set, an error message may surface, indicating: “No host described in new configuration with {version: 1, term: 0} for replica set mongo_replic_set maps to this node.” This issue commonly arises when the MongoDB container encounters difficulty connecting via the specified IP address or hostname in the setup script. To effectively resolve this issue, it is crucial to ensure that the necessary ports are allowed through the firewall. Facilitating seamless MongoDB initialization hinges on granting access to these essential ports, thereby enabling smooth communication and operation within the replica set. These are the ports to allow.

• 4369 (A peer discovery service used by RabbitMQ nodes and CLI tools)
• 5672 (Used by AMQP 0-9-1 and AMQP 1.0 clients without and with TLS)
• 15672 (HTTP API clients, management UI and rabbitmqadmin, without and with TLS)
• 25672 (Used for inter-node and CLI tools communication)
• 35672 (Used for CLI tools communication)
• 27017 (The default port for mongod and mongos instances.)
• Selected UI port (Default 443 for HTTPS and 80 for HTTP) (To access the UI and internode healthcheck)

Use these steps to allow port numbers:

1. Check the Status of Ports:

   For Ubuntu:

   $ sudo ufw status PORT_NUMBER

   For Redhat:

   $ sudo firewall-cmd --list-ports=PORT_NUMBER/tcp

2. If the port is not allowed then perform the following:

   For Ubuntu:

   $ sudo ufw allow PORT_NUMBER

   For Redhat:

   $ sudo firewall-cmd --zone=public --add-port=PORT_NUMBER/tcp --permanent

3. Reload the firewall:

   For Ubuntu:

   $ sudo ufw reload

   For Redhat:

   $ sudo firewall-cmd --reload

This error occurs during upgrading Cloud Exchange from 3.x/4.x to the latest version:

ta_cloud_exchange_mongodb-primary_1 |

{"t":{"$date":"2025-01-15T10:17:50.744+00:00"},"s":"F", "c":"CONTROL",

"id":20573, "ctx":"initandlisten","msg":"Wrong mongod version","attr":{"error":"UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document (ERROR: Location4926900: Invalid featureCompatibilityVersion document in admin.system.version: { _id:

"featureCompatibilityVersion", version: "4.4" }.

Primary Observed Issue: Migration/Upgrade failed.

Follow these steps to analyze the issue you are facing

1. First you to check the docker and docker compose version. Use below commands to check the version
   • docker version
   • docker compose version/docker-compose version.
2. If the docker version is lower than 25, you need to upgrade the version.
3. Follow the instructions in this document. https://docs.docker.com/engine/install/ubuntu/.
4. For docker-compose, use this document. https://docs.docker.com/compose/install/standalone/.

The maintenance password entered is not correct

The user encounters the error message mentioned below while executing the setup script during the migration or upgrade process. Error occurred while executing this command. Error: Command ‘docker exec mongo-migration mongo -u root –password <pass> admin –eval ‘db.adminCommand({setFeatureCompatibilityVersion: “5.0”})” returned non-zero exit status 1. To verify the error resulting from an incorrect maintenance password, the user must run the specified command using either podman or docker:

$ sudo docker ps

$ sudo podman ps

If you can observe a running container named “mongo-migration,” it indicates that an incorrect maintenance password was added during the migration process. 

If this is the situation, you should execute the setup script again based on the deployment type. Additionally, you need to enter the same maintenance password that was used during the old setup of Cloud Exchange. For Containerized CE or CE as HA, the command to rerun the setup script is:

$ sudo python3 ./setup

For CE as VM Instance, the command to rerun the setup script is:

$ sudo ./setup.

If the user is unable to locate the running container, they may need to refer to the troubleshooting steps provided below.

Incompatible Mongo Feature Compatibility Version

You encounter the error message mentioned below while executing the setup script during the migration or upgrade process. Error response from daemon: Container <Container_ID> is not runningError occurred while executing command. Error: Command ‘docker/podman exec mongo-migration mongo -u root –password <pass> admin –eval ‘db.adminCommand({setFeatureCompatibilityVersion: “5.0”})” returned non-zero exit status 1. To prevent this error from occurring, please follow the instructions below.
For those who are utilizing a Containerized CE, follow these steps:
1. Run this command:

$ echo MONGO_COMPATIBILITY=True >> .env

2. To verify the changes, use this command for Containerized CE instance:

$ cat .env

3. Run the setup script again. If you are using the below command:

$ sudo ./setup

If you are using CE as HA (Containerized) based instance, follow these steps:
1. Run this command:

$ echo MONGO_COMPATIBILITY=True >> <shared_drive>/config/.env

2. To verify the changes, use the following command for CE as an HA-based instance:

$ sudo cat <shared_drive>/config/.env

3. Run the setup script again on the current node. This time, the error should not appear.

$ sudo ./setup

If you are using CE as OVA instance, follow these steps:
1. Run this command:

$ sudo vi /opt/cloudexchange/cloudexchange/.env

If you have opted HA in CE as VM-based instances, proceed by executing this command:

$ sudo vi <shared_drive>/config/.env

2. Insert the following line into the .env file and remember to save the changes.

MONGO_COMPATIBILITY=True

3. Re-run the setup script by using the command below:

$ sudo ./setup

 Scenario: When a customer attempts to migrate to v5.1.1 HA from an older HA version, they must run the restore_ha_backup script. However, in certain shell versions, particularly on Ubuntu 22.04/ CE as a VM Images, this script encounters an error while exporting environment variables.

Resolution: To prevent this error from occurring, please follow the instructions below instead of running ./restore_ha_backup script.

1. Execute the following command to export necessary environment variables:
   $ export MONGO_INITDB_ROOT_PASSWORD=<Enter_maintenance_password>
$ export HA_PRIMARY_NODE_IP=<Enter_current_node_ip>
   
2. Use the following command to start MongoDB Container:
   
   • Run below command for docker based system like Ubuntu:
     $ sudo docker compose -f docker-compose-ha.yml up mongodb-primary -d
   • Run below command for podman based system like RHEL:
     $ sudo podman-compose -f podman-compose-ha.yml up mongodb-primary -d
3. Run this command to assign new primary IP to the cluster after migration using the below command:
   
   • Run below command for docker based system like Ubuntu:
     $ sudo docker compose -f docker-compose-ha.yml exec mongodb-primary bash -c "mongosh -u root -p $MONGO_INITDB_ROOT_PASSWORD --eval 'cfg = rs.conf();cfg.members[0].host = "$HA_PRIMARY_NODE_IP:27017";rs.reconfig(cfg, { force: true })'"
   • Run below command for podman based system like RHEL:
     $ sudo podman-compose -f podman-compose-ha.yml exec mongodb-primary bash -c "mongosh -u root -p $MONGO_INITDB_ROOT_PASSWORD --eval 'cfg = rs.conf();cfg.members[0].host = "$HA_PRIMARY_NODE_IP:27017";rs.reconfig(cfg, { force: true })'"
4. Run the below command to stop MongoDB container:
   
   • Run below command for docker based system like Ubuntu:
     $ sudo docker compose -f docker-compose-ha.yml down -v
   • Run below command for podman based system like RHEL:
     $ sudo podman-compose -f podman-compose-ha.yml down -v

Issue Summary: Cloud Exchange is not getting started after the RHEL OS upgrade on your server.

Common Symptoms: you might be receiving error in relation to podman or podman-compose being not present in your system while you are trying to execute the start script to initiate the Cloud Exchange containers

Root Cause:

Potentially, it seems that due to OS upgrade in the server, these files and packages were removed from your machines. Hence, we would recommend you to please check with your IT or VM team for the exact cause.

Troubleshooting Steps/Resolution:

Podman, Podman-compose, and Podman-plugins are prerequisites for Cloud Exchange and hence, you would have to install them back again in your machine. 

So, please follow the below steps:

• Podman installation command:
  sudo yum install podman
• Podman-compose installation commands:
  sudo pip3 install podman-compose
• Creating soft link for podman-compose:
  sudo ln -s /usr/local/bin/podman-compose /usr/bin/podman-compose 
• Podman-plugins Installation command:
  sudo yum install podman-plugins

Once these dependencies are installed, please execute the following command to recreate podman system details: sudo podman system reset

After these steps are followed, please restart the Cloud Exchange using the following commands:

1. sudo ./stop
2. sudo ./start

 Now, you should be able to start your Cloud Exchange in your machine without losing any previous configurations.

When configuring the Netskope Log Shipper plugin in Cloud Exchange, users may encounter a validation error:

TENANT Netskope Tenant (Required) []: Validation error occurred, Received exit code 403, Forbidden, Verify the V1, V2 API Token provided in the configuration parameters.

Typical Symptoms

• Issue occurs even when permissions appear correct.
• Error banner while saving plugin configuration.
• Message references invalid/insufficient V1 or V2 API token.

Root Cause

• From Cloud Exchange v5.1.1 with CLS Plugin v2.2.0+, a new Client Status event type was introduced.
• This event type uses the endpoint:
  /api/v2/events/dataexport/iterator
/api/v2/events/datasearch/clientstatus  
• This V2 API Token must have READ + WRITE permissions for this endpoint.

Steps to Troubleshoot

1. Check plugin version; it must be CLS v2.2.0 or above.
2. Verify token permissions:
   • Ensure all /api/v2/events/dataexport/* as well as /api/v2/events/datasearch/clientstatus endpoints are included.
   • Confirm /api/v2/events/dataexport/iterator has READ + WRITE.
3. Update or recreate the V2 API token with correct permissions.

Save updated token in CLS plugin configuration.

Resolution

• Add required dataexport permissions (READ + WRITE for iterator).
• Retry saving the CLS configuration.
• If Client Status is not needed, temporarily deselect this event type to bypass until the token is updated.
  

You see this error:

- Error: Value error, please check the Tenant Name field has no special characters, ensure V1 and V2 tokens are valid.

Troubleshooting Steps

1. First, make sure that REST API Status is enabled for REST API v2 in the Netskope tenant.
   
2. Confirm that you have created the REST API v2 Token with the necessary Netskope Endpoint Permissions/Scopes as documented here.
3. Check your existing REST API v2 Token, and if required, modify the Netskope Endpoint Permissions/Scopes as per the above documentation. Try again to save the Netskope Tenant in the Cloud Exchange UI.
4. If the issue continue to persists, execute the following curl request in the host machine wherein Cloud Exchange is deployed:

   Note

   Before executing the above command, make sure to replace the <tenant-name> with Netskope Tenant Name and <V2 token> with the existing REST API v2 token.

   curl --location https://<tenant-name>.goskope.com/api/v2/events/dataexport/events/page?index=tenant --header 'Netskope-Api-Token: <V2 token>'

Command Output
If you observed the output of the command as Unauthorized for the IP address x.x.x.x, then add the highlighted IP address in the Custom IP Addresses section (enable it, if disabled) under IP Allowlist in your Netskope tenant.

Path for IP Allowlist

Log in to the Netskope tenant and go to Settings > Administration > IP Allowlist > Custom IP Addresses.

If you observed this banner in Cloud Exchange UI, this indicates that REST API V2 token is expired.

Follow these steps to resolve this error

1. In your Netskope tenant, go to Settings > Tools > REST API V2 and select an API Token. Click on the three dots dropdown and select Change Expiration Date.
2. Now you need to re-issue the token. For your API Token, click on the three dots dropdown and select Reissue.
3. Copy the new token and use that in your Cloud Exchange Netskope Tenant configuration.

SSO requires a top level domain (TLD). Not adding a TLD in the hostname while mapping the URL and upon enabling SSO in CE, a customer will receive the error “Invalid Hostname, Top Level Domain required”. This is resolved by adding proper TLD (like netskope.com).

If you receive this kind of error then it’s because Netskope CE by default supports TLSv1.3 only. To resolve this error, you should allow Netskope CE to run on TLSv1.2 along with TLSv1.3 and for that you have to change the TLS version from the setup script. Re-run the setup script again and enter ‘Yes’ to the following question.

Do you want to enable TLSv1.2 along with TLSv1.3 for CE UI.

Then execute the start script.

If your certificates are expired then follow below steps to regenerate the certificates.

1. Down all the containers.
2. Remove the certificate files (cte_cert.crt, cte_cert_key.key) from data/ssl_certs folder.
3. Re-run the setup script to regenerate the certs. Enter “https” to the below question:

   Do you want to access CE over HTTP, or HTTPS (HTTPS is recommended)? https

4. Execute the start script.

To reset the administrator password, refer to Reset Password in the Account Settings section. Make sure to change the password from Account Settings after the CE administrator has reset the password.

To reset any other user’s password, the Super Admin can update a user password from Settings > Users, and then click the Edit icon on the right.

To change the SSO configuration, you need to disable SSO using the toggle on the SSO Configuration tab in the CE UI. To do so, follow the following steps:

1. First, save your details related to SSO configuration from Okta in a file (Identity Provider Issuer URL, Identity Provider SSO URL, Identity Provider SLO URL, and Public x509 Certificate).
2. Next disable the SSO using the toggle which can be seen on the SSO Configuration page in the CE UI.
3. After disabling SSO, the change in the domain should be reflected in the Service Provider Entity ID, Service Provider ACS URL, and Service Provider SLS URL as per your modified domain.
4. When you see this in the CE UI, re-enable SSO using the toggle.
5. Re-enter the details saved in the first step from the file.

Note that you would also have to update your IdP (like) Okta details pertaining to the Service Provider Entity ID, Service Provider ACS URL, and Service Provider SLS URL so that it also reflects the change with respect to your modified domain.

Issue Overview

SSL certificate expiration banner has been visible on Cloud Exchange Web UI after completing an upgrade.

Steps to Troubleshoot

1. Go to the CLI of the Cloud Exchange host machine.
2. Go to the Cloud Exchange directory.
3. Stop the Cloud Exchange services:

   sudo ./stop

4. Now remove the existing SSL certificate:

   rm -rf data/ssl_certs/cte_cert.crt
   rm -rf data/ssl_certs/cte_cert_key.key

5. After finishing this, re-run the setup script:

   sudo python3 ./setup

6. Note, if you have deployed Cloud Exchange as a VM, run:

   sudo ./setup

7. Now run the start script:

   sudo ./start

These steps will have generated the latest SSL certificate.

Issue Overview

During HA configuration, all nodes must use the same JWT secret as the primary node. If the JWT secret generated or configured during the primary node setup is not available, generate a new JWT secret and configure it on all nodes in the cluster.

Steps to Regenerate JWT TOKEN

1. Navigate to the CE installation directory (primary node). Follow the appropriate steps based on your deployment type:
   • Containerized CE deployment
     cd <ta_cloud_exchange_directory_path>
   • CE deployed as a VM
     cd /opt/cloudexchange/cloudexchange
2. Stop the containers.
   sudo ./stop
3. To set a specific JWT secret, modify the cloudexchange.config file and provide the value for JWT_SECRET.
   sudo cp cloudexchange.config.example cloudexchange.config
sudo vi cloudexchange.config

4. Run the setup script.
   sudo ./setup
5. Restart the containers.
   sudo ./start

Scenario: CE automatically detects the data type (string, number, or boolean) of incoming fields and adjusts operators based on new data type across all CE filter views accordingly upon data retrieval. If a field’s data type changes, any configured business, mute, or dedup rules using that field will show a red error icon. You need to reconfigure these rules through the edit option.

Impact: Module specific lifecycle tasks, like filtering, transformation, ticket creation, dedup, and mute rules evaluation will be stopped for incoming alerts/events/logs, and incoming data processes to third-party will be skipped. Invalid rules will prevent CE from processing incoming alert or event batches and will trigger an error message in the Logging tab.

Resolution: You need to reconfigure these rules through the edit option.

1. Go to the respective Business Rule page.
2. Click Edit.
3. Modify the filter as needed to address the issue.
4. Click Save to apply the changes.

Scenario: If you configure SIEM and delete that particular SIEM, and on reconfiguring it back while historical pulling is in progress for initial range mentioned in plugin configuration, CE is creating multiple tasks (One is on the creation of SIEM mapping time, and another one is on reconfiguration of SIEM Mapping). 

To resolve this, restart CE using the stop and start scripts and perform a manual sync in Log shipper > SIEM Mappings manual sync with historical range.

Scenario: While sharing the Threat IoCs to Netskope, you might see this error.

Impact: IoCs will be shared to Netskope but the functionality of tagging the indicators will be affected. This might also impact the IoC retraction functionality.

Resolution:

1. Go to Settings > Repository and click Check for Updates to fetch the updates for the Default repository.
2. Click Update Plugins, select the Netskope Threat Exchange plugin, and click then Save and follow the prompts.
3. Wait for the next execution for sharing, and then check if the error is no longer visible in the audit logs.

Scenario: While fetching the updates from Default plugin Repository after migration from the old CE, this error occurs.

Impact: Not will be able to fetch plugin updates from Github for Default repository.

Resolution:

1. SSH into CE instance and go to the Cloud Exchange installation package directory.
2. Remove all untracked files using this command: (Use podman-compose instead of docker-compose in RHEL-based OS).

$ docker-compose exec -w /opt/netskope/repos/Default core git clean -df

Note that if you receive any error while running above commands, try this command to remove untracked files.

$ cd data/repos/Default (cd <shared_drive>/repos/Default for HA deployment) 
$ sudo rm -rf crowdstrike_identity_protect_ztre/ crowdstrike_ztre/ microsoft_entra_id_ztre/ mimecast_ztre/ netskope_ztre/ okta_ztre/

To address this issue, it is crucial to verify that the Business Rule and SIEM mapping used are correct. Additionally, ensure that all parameters are accurately filled out during the plugin configuration process. It is also important to review the sharing configuration to confirm it matches the IoCs you expect to share. If the sharing filter is incorrect, adjust the sharing criteria accordingly.

To retrieve any historical data that might have been missed due to a misconfiguration, consider removing and then re-adding the sharing configuration. By taking these steps, you can ensure that the IoCs are properly shared with the intended threat source.

Netskope only accepts URLs with wildcard characters that are in front of the domain, others will be rejected when Threat Exchange tries to send it. So *.google.com will be accepted by the Netskope tenant,but google.com/* will not. If your Threat Exchange database contains wildcards, you will need to manually tag to share.

By default, all your uploaded plugins are stored inside the ./data/custom_plugins directory. However, this can be changed from the docker-compose by mounting a different directory or the Admin can add an additional repository to download custom plugins from. This is configured within the Settings menu. This is the best method of adding additional plugins to your CE instance, and the only method for adding additional CTO, CLS, and CRE plugins.

Scenario: After migrating to 5.1.0 User might see the below error while updating the existing Business Rule for CTO module.

Impact: You will not be able to update the existing rule until the you redefine the rule.

Resolution: Redefine the business rule from the UI and update it.

The platform by default searches for the last 7 days of IoCs. If there are too many IoCs (more than 1 million) and no filter selected, the search performance will be slow.

Proposed solution: Consider applying the filters and narrowing the search criteria. Performance is best when the data set is ~100K records or less.

Verify if the outgoing API calls require a proxy. If your network deployment expects a proxy for HTTP API calls and a proxy is configured, the plugin operations would be impacted.

Proposed Solution:

1. Go to Settings > General > Proxy.
2. Edit the existing configuration and enable Use System Proxy.

CE relies on an internal scheduling mechanism for the plugin’s task. There are workers which execute the plugin tasks, by picking up a task from the queue one by one. The number of workers available in your system depends on the number of cores. If the available workers are busy serving plugin task, the already queued up task has to wait till the existing worker is available. This situation may usually occur during initial data ingestion, where there’s more data to be processed.

Proposed Solution: Consider increasing the cores of the system if you have a large number of configured plugins, and the configured plugins are consistently lagging behind. For initial ingestion, the system should pick up the backlog post initial ingestion and behave normally if the incremental data is not large.

If there is a red alert icon on one of the configurations, it indicates that there was one or more problems while polling the plugged-in system for data per that configuration. This could be related to API, proxy, or SSL settings.

Proposed Solution:

• Make sure the Plugin Configuration has correct parameters for API, Secret key, URL, etc.
• Make sure Enable Proxy is selected and your proxy is configured if outbound network calls require a proxy connection.
• Check logs for errors occurring around the last run time displayed on the configuration from the Audit section.

When a user tries to upload a plugin with a tar.gz package using the browse button, tar.gz files are not selectable by default.

Proposed Solution: Drag and drop plugin packages to the drop area of the UI.

Open the plugin configuration and set the Last Run value to an older date-time and save the configuration. Make sure that the configuration is currently not running when you update the Last Run value.

• For a Docker-based deployment:
  1. Retrieve the core container logs using this command:
     $ docker-compose logs core | grep WorkerLost
     If the logs containing WorkerLost appear around 5-6 times, this indicates there’s an issue. Restart the containers using these commands:
     $ ./stop
$ ./start
• For a Podman-based deployment:
  1. To access the core container logs, use this command:
     $ podman-compose logs core | grep WorkerLost. If the logs containing WorkerLost appear around 5-6 times, this indicates there’s an issue. Restart the containers using these commands:
     $ ./stop
$ /start

Scenario: In core logs, you might observe “Process ‘ForkPoolWorker-**’ pid:552 exited with ‘signal 9 (SIGKILL)’”

Impact: Often the core container might get restarted and you may experience delay in tasks performed by CE (like logs ingestion getting delayed).

Resolution:

• Make sure the CE is hosted on a machine having at least 2.2 GHz CPU frequency.
• If you’re not meeting the CPU frequency criteria please migrate to the machine which meets the criteria.
• If you’re already meeting the CPU frequency criteria, reach out to the support team.

Cloud Exchange (CE) populates warning log messages for the “networksessionID” field in the Logging section while sending Network Events logs from the CLS Syslog/Qradar plugin.

Example Warning Log Message in Cloud Exchange UI (under Logging Section):

CLS QRadar [QRadar]([events][network]): An error occurred while generating CEF data for field: “networkSessionId”. Error: networkSessionId: Error occurred while converting to integer. Field will be ignored

Root Cause:

In Network events, Cloud Exchange is expecting networkSessionId field to be one of the following:

1. Not present
2. Present with a valid number enclosed in double quotes (i.e. a JSON string)
3. Present with a valid number (i.e. a JSON number)

This warning message indicates that the field “networkSessionId” is not available/present in unexpected manner in raw logs from your Netskope Tenant and because this field is added in the default mapping file of the respective plugin due to this, Cloud Exchange skips this field from ingestion with the above-mentioned warning.

Troubleshooting Steps/Resolution:

In such a case, you can create a custom mapping and remove this field from the Mapping file to suppress this warning. This will not cause any impact on Cloud Exchange workflow.

This field is available under Network Events in the Default Mapping file. Hence, you can follow below steps to create a custom mapping to remove “networkSessionId” field and utilize it in the respective plugin:

• Log into Cloud Exchange UI. Select Settings.
• Select Log Shipper on the side-panel and move to Mappings.
• Look for the respective plugin’s Default Mapping file (for example: Qradar Default Mapping).
• Click on the Clone action to make a copy of the Default Mapping file.
• Provide Some Name to this Custom Mapping file.
• Now, go to the Events tab and expand the Extensions part in the Network Events section.
• Search for the “networkSessionId” field and remove it from the mapping.
• Save the mapping file.
• Now, using the back-arrow key, go back and into the Log Shipper Module.
• Select Plugins and edit the respective plugin (Syslog/Qradar).
• Change the selected mapping from the dropdown list and select the recently created Custom Mapping.
• Now, click Save for the plugin.

After some time, you should be able to see in the Logging Section that the “networkSessionId” field related warning messages are no longer getting populated

For your reference, you can follow this document for creating a mapping: Create a Mapping File in Log Shipper

Issue Overview :

Users configuring a Netskope provider plugin within Cloud Exchange may encounter an error related to the Client Status iterator. This occurs when the tenant already has a Client Status iterator created by another module (e.g., Netskope CLS or Netskope CRE) via different user or another CE instance.

Error:

TENANT Netskope Tenant (Required) [Support Tenant]: Error while creating iterator with name netskope_ce_cs_iterator. Cannot create Client Status Iterator. One iterator already exists for the Client Status event for your tenant. Delete the existing iterator to continue.

Root Cause:

• Each Netskope tenant supports only one Client Status iterator.
• When a plugin (Netskope CLS or Netskope CRE) is configured, Cloud Exchange checks for an existing iterator:

1. If missing → creates a new iterator.
   
2. If already present → validation fails if it is triggered via a different user or another CE instance, returning the error.

This behavior is by design: multiple modules must share the same iterator, and a second cannot be created.

Steps to Troubleshoot:

1. Confirm existing iterator

• The error indicates one is already present on the tenant.
• This usually happens if CLS (with Client Status enabled) or other integration has been configured previously.

Confirm the name of the existing Iterator via CE error logged upon trying to add the Plugin.

API response: {"message":"Only one iterator is allowed per event type. Please use the existing iterator, netskope_ce_cs_iterator_70332c65-aad4xxxxxxxxxxxxxxxxxx, or delete the existing iterator."}

2. Delete the existing iterator

• Use the below script to delete the existing iterator

curl –location –request DELETE ‘<Tenant_url>/api/v2/events/dataexport/iterator/<iterator_name>’ –header ‘Authorization: Bearer <token>’ 

• Replace the following:
  ○ <Tenant_url>
  ○ <iterator_name>: Copy the highlighted iterator name from the error log in logging section
  ○ <token>

3. Reconfigure plugins in Cloud Exchange

• Configure the Provider plugin first.
• Then add CLS, CRE, and other modules.
• All modules created by the same Provider plugin in the same CE instance will share the same iterator.

Resolution:

• Deleting and reconfiguring the iterator allows the same user to configure all plugins successfully in a single CE instance.

Issue Overview

When Diagnosis is triggered from the Cloud Exchange > Settings > General Tab, the status of the job stays in the “Running” state. Since Diagnosis collects exhaustive details about the Cloud exchange deployment it will take few minutes to execute, however if it stays in the “Running” state even after considerable about of time then follow below steps to stop existing diagnose job.

Steps to stop the existing diagnose job

1. Navigate to the CE installation directory (In case of HA, use the node from where diagnose is triggered)
2. Verify already running diagnose jobs
   sudo ps -A | grep diagnose
3. Run command to kill existing diagnose jobs
   sudo pkill diagnose
4. Remove stale diagnose metadata files.
   • For HA Deployments
     • sudo cd {HA_NFS_DATA_DIRECTORY}
     • sudo rm -f ./diagnose_output/.diagnose_job_*
   • For Standalone Deployments
     • sudo cd {CE installation directory}
     • sudo rm -f ./data/diagnose_output/.diagnose_job_*
5. Re-trigger the Diagnose job execution

While configuring Queue Configuration in the Ticket Orchestrator module for the ServiceNow plugin, you may notice that not all expected target fields are available under the Map Fields section.

Cause

The target fields displayed in the Map Fields section are dynamically retrieved from the configured Destination Table in the ServiceNow plugin using the /api/now/table/sys_dictionary endpoint.

During this process:

• Only fields returned by the sys_dictionary API are available for mapping.
• System-defined fields (fields whose names begin with sys_) are intentionally excluded because ServiceNow does not allow these fields to be modified through the API.

As a result, if a field is not returned by the sys_dictionary endpoint, it will not be available for mapping within the Queue Configuration.

Resolution

To verify which fields are available for mapping, run the following cURL command against your ServiceNow instance.

Before running the command:

• Replace <Instance URL> with your ServiceNow instance URL.
• Replace <Username> with your ServiceNow username.
• You will be prompted to enter your ServiceNow password.

cURL Command:

curl --location '<Instance URL>/api/now/table/sys_dictionary?sysparm_query=name%3Dincident%5EORname%3Dtask%5Einternal_type!%3Dcollection&sysparm_fields=column_label%2Celement%2Cinternal_type&sysparm_offset=0&sysparm_limit=1000' -u '<Username>' -H 'Accept: application/json'

Expected Output

The command returns a JSON response containing the fields available for the selected destination table.

Each entry includes information such as:

• column_label – Display name of the field.
• element – Internal field name.
• internal_type – ServiceNow field type.

Review the returned fields to determine which fields are available for mapping within the Queue Configuration.

Validation

• If the expected field is present in the API response, it should also be available for selection in the Map Fields section of the Queue Configuration.
• If the expected field is not present in the API response, the field is not available for mapping because it is not being returned by the ServiceNow sys_dictionary API for the configured destination table.
• Fields prefixed with sys_ are expected to be absent, as they are excluded by design.