Engines and Disaster Recovery Troubleshooting - Administrator Guide - EoL - 6.10 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Administrator Guide

Cortex XSOAR
Creation date
Last date published
Administrator Guide
End of Life > EoL

Troubleshoot Cortex XSOAR engine failover issues when an engine does not automatically fail over to the active node in a disaster recovery situation.

In the event of a failover between the Cortex XSOAR servers, engines are capable of dynamically failing over to the active node. This should happen automatically if the engine was deployed after DR was configured.


Assuming all is configured and working properly, it should not be necessary to change the DNS to affect an engine failover when a server failover occurs.

If engine failover is not working when failing over between Cortex XSOAR servers (i.e., does not display as Connected: false in SettingsIntegrationsEngines), it is likely due to one of the following causes:

  • The file /var/lib/demisto/d2_server.key is not the same on each Cortex XSOAR server. This can sometimes happen if Live Backup was previously configured using Cortex SOAR (Demisto) 4.0 and this file did not exist at the time that Cortex XSOAR was first configured. Copy this file from the primary server to the backup server and restart the backup server service.

  • On the engine, if the EngineURLs array property of /usr/local/demisto/d1.conf is missing the IP or host name of the backup Cortex XSOAR server, do the following:

    Simply redeploy the engine from SettingsIntegrationsEngines. This should automatically include both servers in the d1.conf file.

    Modify the JSON in conf file manually, to add the other server to the EngineURLs array, and restart the engine. If a syntax error is detected in the JSON, the engine service refuses to start and may not log any error messages. The array should now look something like:

    EngineURLs": [
    "wss://cortex xsoarserver1:443/d1ws",
                    "wss://cortex xsoarserver2:443/d1ws"
  • Host name resolution is broken from the engine to one of your servers. Use ping or nslookup to confirm that the engine host can resolve the backup server, and that the IP address of the server is correct. If not, it may require a change to your DNS environment or a network or host firewall is blocking connectivity from the engine to your backup Cortex XSOAR server.