This section covers common issues that may occur during administration of iManage Threat Manager, and how to resolve them.

In this section:

(On-premises) Ingestion failure

Problem: Initial or large incremental ingestions are not completing.

Cause: The Microsoft SQL database compatibility level may be lower than 110.

Solution: Check the Microsoft SQL database compatibility level. If it is lower than 110, the YAML file must be adjusted by a system administrator. For instructions, refer to DATAIMPORTER_WORKETL_EXTRACTOR_PAGESIZE in (On-premises) Advanced configuration.

For specific error types, refer to the following sections in (On-premises) Advanced configuration:

  • Batching errors in log files: refer to Adjust ingestion resolution in event of batching errors.

  • Out of memory errors: refer to Adjust ingestion batch size in event of "out of memory" errors.

(On-premises) Recommendations for restarting the iManage Threat Manager appliance

Restarting the physical device running iManage Threat Manager may be required for administrative tasks or hardware changes such as adding memory. Follow these steps to restart safely.

(On-premises) Task: Restart the Threat Manager appliance

  1. Enable Maintenance Mode. For instructions, refer to System > Maintenance mode.

  2. Wait five minutes before rebooting the host device.

  3. Reboot the host device.
    After restart, all iManage Threat Manager services restart automatically. It may take a few minutes before everything is operational.

  4. When iManage Threat Manager is running, turn off Maintenance Mode.

(On-premises) Can’t connect to iManage Work Server

Several issues can prevent Threat Manager from connecting to iManage Work Server. Identify the relevant cause below and follow the resolution steps.

In this section:

  • (On-premises) Docker networking restart not performed to detect transition from DHCP to static IP

  • (On-premises) DNS configuration issues

  • (On-premises) iManage Work Server or SQL Server on 10.0.0.x subdomain

  • (On-premises) iManage Work Server isn't configured for HTTPS compliance

(On-premises) Docker networking not restarted after static IP assignment

Problem: After assigning a static IP address to the Threat Manager appliance, connectivity issues occur.

Cause: Assigning a static IP address requires a restart of the appliance before changes take effect.

Solution:

  1. Reboot the OS to ensure network interface card (NIC) changes are applied:

    sudo reboot

  2. Connect to a console session of your virtualization platform.

  3. Confirm that network changes are in place. For more information, refer to Steps 2–3 of Provisioning the iManage Threat Manager Open Virtual Appliance (OVA) in iManage Threat Manager Installation Guide.

NOTE: For additional information on Docker networking, refer to the Docker documentation at https://docs.docker.com/network/network-tutorial-host/.

  1. Open a terminal application (SSH) session and shut down the Threat Manager appliance:

    docker stack down tmstack

  2. Restart the appliance:

    docker stack deploy tmstack --compose-file docker-compose_v10.yaml --with-registry-auth

(On-premises) DNS configuration issues

Problem: Threat Manager cannot connect to iManage Work.

Cause: DNS configuration issues can prevent connectivity. Common causes include, for example:

  • The DNS NameServer field is not set in the OVA template file for the NIC.

  • The DNS NameServer field is set to an inaccessible range.

  • No DNS A record is configured to communicate the DNS reply.

Solution: Troubleshoot DNS issues using the guidance at https://netplan.io/faq/#find-the-current-dns-servers .

(On-premises) Work Server or SQL Server on 10.0.0.x subdomain

Problem: After completing the steps in (On-premises) System > Work Server Configuration, Threat Manager still cannot connect to iManage Work Server.

Cause: If iManage Work Server or SQL Server is on the 10.0.0.x subdomain, you must initialize Docker Swarm with a different address pool.

IMPORTANT: Note all Docker secrets (set passwords) before starting. These are removed during this procedure and must be re-entered.

NOTE: This procedure requires Docker API version 1.39 or higher. Steps to check and upgrade the Docker API version are included below.

Before you begin: Confirm that iManage Work Server or SQL Server is on the 10.0.0.x subdomain. If not, see the other topics in this section.

Solution:

  1. Bring down the Docker stack:

    docker stack down tmstack

  2. Leave the Docker Swarm:

    docker swarm leave --force

  3. Check the Docker API version:

    docker version

    • If the API version is 1.39 or higher, proceed to step 4.

    • If the API version is lower than 1.39:

      1. Update the package list: sudo apt update

      2. Upgrade Docker: sudo apt upgrade -y

      3. Verify the upgraded version: docker version

  4. Initialize Docker Swarm with a network range not used in your organization:

    docker swarm init --default-addr-pool <pool_range>

    For example: docker swarm init --default-addr-pool 11.11.0.0/16
    This range persists for the lifetime of the system swarm initialization (so set a network range (pool range) that is not used in your organization).

  5. Run the setup script:

    sudo ./setup.sh

  6. Set the locale and passwords, and bring up the Docker containers. For instructions, see Step 5: Configure and deploy service of Provisioning the iManage Threat Manager Open Virtual Appliance (OVA) in iManage Threat Manager Installation Guide.

(On-premises) Work Server not configured for HTTPS compliance

Problem: Threat Manager cannot connect to iManage Work Server and the logs show SSL-related errors.

Cause: By default, Threat Manager only allows connections to HTTPS-compliant iManage Work Servers. This prevents Threat Manager from connecting to, for example, Work Servers using self-signed certificates.

Solution: Check the Web Service logs in Configuration > Settings > Status, or in Configuration > Settings > Logs > Web Service Log section.

If the logs show errors such as requests.exceptions.SSLError or SSL: CERTIFICATE_VERIFY_FAILED, the Work Server is not HTTPS-compliant. Refer to iManage Work Server SSL Setting in (On-premises) Advanced configuration.

(On-premises) Detect and Protect: “Disable Account” action not working

Problem: The Detect and Protect Disable Account action is not disabling user accounts.

Cause: iManage Threat Manager uses a privileged iManage Work account to disable user accounts when the Disable Account action is triggered. If this account has not been configured, or does not have the DISABLE_ACCOUNTS privilege (granted via Tier 1 iManage Control Center Access), the action will not work.

(On-premises) Task: Configure the Detect and Protect Work account

You need an iManage Work account assigned a role with Tier 1 iManage Control Center Access privileges to complete this task.

  1. In Configuration > Settings > System, go to the Detect and Protect Work Account section.

  2. In User, enter the iManage Work account user name.

  3. In Password, enter the password for the account.

  4. Select Save.

(On-premises) Task: Stop and restart the Docker stack

Changes made in the docker-compose_v10.yaml file take effect only after the Docker stack is stopped and restarted.

  1. From a terminal connected to the Threat Manager appliance, bring down the Docker containers and shut down the stack:

    docker stack down tmstack

  2. Wait approximately 30 seconds for the stack to shut down.

  3. Restart the containers:

    docker stack deploy tmstack --compose-file ./docker-compose_v10.yaml --with-registry-auth

The appliance restarts, applying the settings configured in docker-compose_v10.yaml.