(9.1+) Callback troubleshooting

Use the following guides to assist with each listed issue. For further assistance, contact a VHT® Support engineer.

Core components

Backup Core instances not in the correct mode after losing network connection

If the backup Core instance does not go to Standalone mode (or goes to Standalone mode but its Queue Manager is not running) after the primary Core Instance losses and then regains network connection, perform the following corrective actions:
  • If the backup Core instance just fails to change to Standalone mode (as displayed in the System Manager interface), restart the Core Monitor service of the instance currently in Connection Lost mode.
  • If the backup Core instance changes to Standalone mode but its Queue Manager is not running, increase the start_qm_node_timeout_ms value (in the VH_root_directory\Core Monitor\site.config file) for each Core instance and restart the Core Monitor service of each Core instance. The VH_root_directory is C:\Program Files (x86)\Virtual Hold Technology by default.

Correcting datastore clustering issues

During Callback installation, it is possible that the Notification Server and Management API datastores never connected (clustered) or became disconnected. Two possible scenarios are listed in the following topics.

Management API failure (standalone and high availability)

During the installation of a Management instance (Standalone deployment) or the first Management Instance (High Availability deployments), the following popup message is displayed:

The installer could not automatically configure data sharing between this Management API and other nodes. Manual steps are required and can be found in the appendix of the "Deployment Guide".

This is probably caused by the Notification Server not being started prior to attempting to cluster the datastores.To manually cluster the Management API and Notification Server datastores:
  • Complete the Callback installation process.
  • Start the VHT Notification Server service from the Windows Control Panel. If the service cannot be started, contact Customer Support for assistance.
  • Stop the VHT Management API service.
  • Click Start.
  • In the Search field, enter command prompt.
  • Right-click Command Prompt and select Run as administrator to open a command window.
  • Navigate to the Management API installation directory. \Program Files (x86)\Virtual Hold Technology\Management API for example.
  • Execute the following command to cluster the datastores:bin\management_api_node.cmd join_db fully_qualified_domain_name_of_this _Management_server
  • Start the VHT Management API service.

Notification Server failure (high availability)

During the installation of the second Management instance (on a separate server), the following popup message is displayed:

The installer could not automatically configure data sharing between this Notification Server and other nodes. Manual steps are required and can be found in the appendix of the "Deployment Guide".

Probable causes are:
  • Incorrect fully qualified domain name supplied when joining the datastores during installation of the first Management instance.
  • All VHT services where not running on the Management instance installed first.
  • Communication between this server and the first Management instance server was impaired during installation.
To manually cluster the Management API and Notification Server datastores:
  • Verify all VHT services are running on the Management instance installed first. If necessary, start the services or contact Customer Support for assistance.
  • On the second Management instance, stop the VHT Notification Server service from the Windows Control Panel.
  • Stop the VHT Management API service.
  • Click Start.
  • In the Search field, enter command prompt.
  • Right-click Command Prompt and select Run as administrator to open a command window.
  • Navigate to the Notification Server installation directory. \Program Files (x86)\Virtual Hold Technology\Notification Server for example.
  • Execute the following command to connect the Notification Server to the first Management instance:bin\notification_receiver_node.cmd join_db fully_qualified_domain_name_of_first _Management_server
  • Start the VHT Notification Server service.
  • Navigate to the Management API installation directory. \Program Files (x86)\Virtual Hold Technology\Management API for example.
  • Execute the following command to connect the Management API to the second (local) Management instance:bin\management_api_node.cmd join_dbfully_qualified_domain_name_of_first _Management_server
  • Start the VHT Management API service.

Recovering from a netsplit and Queue Manager cannot start

Recovering

Only apply this recovery setting if Queue Manager cannot start after a netsplit occurs.
  • Make sure VHT Datastore service is running.
  • Go to "C:\Program Files (x86)\Virtual Hold Technology\Datastore\bin" and run "attach_to_datastore.bat".
  • From erlang shell, input the command: mnesia:info().
  • Locate the running db nodes information and copy it.
  • From erlang shell, input the following command, which replaces the node list with the running db nodes from mnesia:info().mnesia:set_master_nodes(['vht_ha_qm@somefqdn', 'confmgnt@somefqdn', 'vht_datastore@somefqdn']).

IMPORTANT

Replace @somefqdn with the mnesia information from Step 4.

  • Restart VHT Datastore service.

When and how to remove the setting

Only remove this setting after a successful recovery from the netsplit.

  • Make sure VHT Datastore service is running
  • Go to "C:\Program Files (x86)\Virtual Hold Technology\Datastore\bin" and run "attach_to_datastore.bat"
  • From erlang shell, input:mnesia:set_master_nodes([]).
  • Restart VHT Datastore service.

Core Monitor service will not start (Error 1067)

This section describes a potential cause of the "Error 1067: The process terminated unexpectedly" popup when attempting to start the VHT Core Monitor service.

Troubleshooting tips

We've identified one potential cause in the following scenario:

  • Readerboard Adapter is installed, and...
  • The Core Monitor site.config file has been run through the Erlang syntax validator, and...
  • The output of the Erlang syntax validator was pasted directly back into the Core Monitor site.config file.

In this scenario, the Readerboard Adapter entry in the Core Monitor site.config file can be invalid for Core Monitor itself. The syntax will still be valid for Erlang, but Core Monitor will not be able to read the file successfully. This will result in the 1067 error when starting the service.

If you think this may be the cause, compare the Core Monitor site.config file to the valid and invalid examples below:

Valid Core Monitor syntaxInvalid Core Monitor syntax

On a single line:

... {application_list,                         [ {name, readerboard_adapter}, {exe, "C:/Program Files (x86)/Virtual Hold Technology/ReaderBoardAdapter/VHT_Readerboard_Adapter_Console.exe"}, qm_controlled ],...

Broken into multiple lines:

...[{name,readerboard_adapter},                         {exe,                          "C:/Program Files (x86)/Virtual Hold Technology/ReaderBoardAdapter/VHT_Readerboard_Adapter_Console.exe"},                         qm_controlled],...

Delete

Wide area network (WAN) issues

Delayed or lost callbacks

Current behavior

High network latency and call volume are two possible scenarios that can reduce the time difference between callbacks (ASAP or Scheduled) to a value less than the average roundtrip network latency. In these cases, the datastore cannot store the callback data fast enough resulting in delayed or lost callbacks or eventual Core instance/Queue Manager failure.

Incoming calls and call data are handled sequentially and one at a time. Calls are sent to the current primary Core instance (datastore) and a response is sent to and returned from the current secondary Core instance (datastore) before the next call is handled.

Optional behavior

Adding the is_datastore_wan parameter and setting it to true causes:

  • Datastores to be placed in a mode allowing simultaneous processing of calls.
  • Calls to be sent to both Core instances (datastores) simultaneously.

To enable this behavior, place this parameter within the vht_ha_qm > vht_logger_options area of the C:\Program Files (x86)\Virtual Hold Technology\Core Monitor\site.config file on each Core instance. Refer to the following example.

{vht_ha_qm, [     {vht_logger_options, [{base_log_file_path, "c:/Program Files (x86)/ Virtual Hold Technology/     VHLogs/Logs"}]},         {is_datastore_wan, true},     {qm_app_controller, ["c:/Program Files (x86)/Virtual Hold Technology/QueueManager/VHT_QueueManager_NIF_DLL"]} ]},    

Using this parameter causes Callback to bypass normal interaction handling processes!

Smart Rules errors

"Unable to retrieve token" / Cannot add a rule

Starting with On-Premise Callback 9.1, the Smart Rules installer automatically runs additional database scripts to update key entries needed by the application. If the installer fails to execute the scripts, you will see errors in the UI and Smart Rules logs when trying to use the feature.

Troubleshooting scenario

You've just installed Smart Rules, and now you see an error similar to the following in Smart Rules Engine logs:

Unable to retrieve token from: <address>

You also may notice an Authentication error in the Launchpad, or unexpected issues when trying to add a rule in the Smart Rules UI.

Resolution

The installer may not have successfully run the necessary database scripts. Try the following steps to resolve the issue:

  • Stop the Smart Rules Engine service
  • Executive the following DB scripts, which will update tables in the VHT_Config and VHT_RPT databases. The installer will automatically save the scripts to <Callback Installation Directory>\SQL Server Database Installation Scripts by default.
    • VHT_BusinessRulesConfig.sql
    • VHT_BusinessRulesReport.sql
    • VHT_BusinessRulesConfig_pre_8_11_3.sql (for versions earlier than 8.11.3)
  • To verify the scripts have been run successfully, check for a new entry in the userProfiles table (in VHT_Config) for a new user named smart_rules_api.
  • Restart the Smart Rules Engine service and try again.

Installer Server page error

C++ 2017-2019 is already installed on servers

If you already have C++2017-2019 installed on your servers, you will receive the following error in the Server page of the installer.

525530 servers added (minmum: 1, maximum:0)

Resolution

Uninstall C++ 2017-2019 redistributables from the Prerequisites directory. Then, install the C++ 2015-2019 redistributables from the Prerequisites directory.