The 9.5.4 upgrade utility misconfigures two registry keys when On-Premise Callback is installed on a drive other than C.

The updater will configure the location of the vht_stats_api-config.yml and vht_auth_api-config.yml files as the C drive regardless of the true drive letter. The configuration is contained in the following registry keys:

• \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VHT_Statistics\ImagePath
• \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VHT_Authorization\ImagePath

Versions affected: 9.5.4

Workaround: Manually update the values of the affected registry keys as seen below, replacing <drive> with the desired drive letter.

For \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VHT_Statistics\ImagePath:

<drive>:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/vht_stats_api-9.5.3.5/bin/VHTStatsApiService.cmd --config="<drive>:\Program Files (x86)\Virtual Hold Technology\Dashboard\vht_stats_api-config.yml"

For \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VHT_Authorization\ImagePath:

<drive>:/Ruby32-x64/lib/ruby/gems/3.2.0/gems/vht_auth_api-9.5.3.5/bin/VHTAuthApiService.cmd --config="<drive>:\Program Files (x86)\Virtual Hold Technology\Dashboard\vht_auth_api-config.yml"

Secure-channel RabbitMQ is not functional in On-Premise Callback 9.5.4.

Secure-channel functionality for RabbitMQ will be restored in a future release.

The config_inserts SQL script cannot be executed without manual updates in this version.

Two lines of the default script must be manually removed before the script will run successfully.

Versions affected: 9.5.4

Workaround: Remove the following lines from the config_inserts.sql script before executing.

(223) EXEC #initializeRow 0, 203;(252) EXEC #initializeRow 12, 203;

The Interaction Service component fails to initialize RabbitMQ.

This affects organizations using Agent Priority in On-Premise Callback 9.5.0. An issue in this version causes Interaction Service to continually attempt and fail to initialize RabbitMQ.

Versions affected: 9.5.0

Workaround:

For Interaction Service to start, you will need to manually configure the default RabbitMQ username (guest) and password (guest) to the Rabbit section of your appsettings.json file (Virtual Hold Technology\Interaction Service\appsettings.json).

That section by default looks like this:

  "Rabbit": {    "Host": "localhost",    "Port": 5672,    "Exchange": "vht_call_exchange",    "ExchangeType":  "fanout"  }

Modify that section to look like this:

  "Rabbit": {    "Host": "localhost",    "Port": 5672,    "Exchange": "vht_call_exchange",    "ExchangeType":  "fanout",    "Username": "guest",    "Password": ""  }

The password will need to be encrypted. To do this, you will need the Password Encryptor app (Virtual Hold Technology\SmartRulesEngine\PasswordEncryptor). Run the Password Encryptor and enter "guest" as your password. Encrypt and copy the result to the password field of your appsettings.json file.

Your final Rabbit section should look something like this:

  "Rabbit": {    "Host": "localhost",    "Port": 5672,    "Exchange": "vht_call_exchange",    "ExchangeType":  "fanout",    "Username": "guest",    "Password": "ZsbeG4YJXa2nAwirFNqseg=="  }

NOTE

In a high-availability installation, the Password Encryptor must be used on each server. Each server in a high-availability solution will have a unique encryption key and vector. Note that when you use the Password Encryptor on Server A to encrypt your password, Server B will not be able to decrypt and use that password.

A memory leak affecting TIAL ICM environments can cause system failure.

TIAL ICM environments using ECC variables can experience a memory leak within the cti_connector_host process. This memory leak can eventually overwhelm the process, causing delays in processing and eventually causing it to halt.

Workaround: Restart Core Monitor periodically to release the leaked memory. We ultimately recommend upgrading to a version of On-Premise Callback containing a resolution.

Versions affected: 9.0 to 9.3.3 (resolution is available in 9.2.4)

Installing On-Premise Callback to a non-standard location can cause startup failures in a specific scenario.

If the software is installed to a directory that does not contain the text "Virtual Hold Technology", QueueManager will be unable to load the appropriate TIAL DLL for the integration. The installation will appear successful but startup will fail.

Workaround: Uninstall On-Premise Callback and reinstall the software to a supported path that contains "Virtual Hold Technology".

Versions affected: 9.2.0 and higher

When an installation is configured for SSL, is not possible to invoke web service methods remotely through pages hosted in IIS.

This applies to PTK methods listed on the methodlist.aspx page and any other web services hosted in IIS. To invoke these methods directly (for testing or validation), you must do so on the host server using the server's loopback address. This means that any attempt to directly invoke web service methods via IIS from a remote server will produce 404 errors.

Note that this does not affect the use of web services and PTK methods in general, but only the invocation of these methods directly from IIS on a remote server. API calls are not affected. This also does not affect installations not utilizing SSL.

Workaround: (Not recommended) It is possible to allow remote invocation by updating the IIS binding to *, but that would introduce a security vulnerability.

Versions affected: 9.2 and higher

An issue with the OpMode Server component can cause the normal operation mode schedule to override the holiday operation mode schedule in a specific scenario.

If the OpMode Server component is restarted after a scheduled holiday operation mode change is configured, it is possible for the normal (non-holiday) operation mode schedule to override the configured holiday schedule. This is not intended, as the holiday schedule should always take precedence over the normal schedule.

Workaround: None

Versions affected: 9.3.0 and earlier

Holding calls can appear to be stuck in the Dashboards UI in a specific scenario.

A rare case can cause QueueManager to receive updated call data without an External Tracking ID (combination of RouterCallDay|RouterCallKey) after certain identifiers have been assigned to the call. When this happens, QueueManager incorrectly removes RouterCallDay|RouterCallKey values, which causes the call status not to be updated when answered. This results in calls appearing to be stuck in the Dashboards UI without being cleared.

Versions affected: All

Workaround: Contact the VHT Support team for assistance in removing the call records. The Support team will require logs containing the relevant RouterCallDay|RouterCallKey.

An issue with the default configuration for RabbitMQ in the VHT_Config database can cause RabbitMQ to discard messages rather than ingesting them in a specific scenario.

The default value of the EnableCallDataFeed system variable (TRUE) assumes that the Callback installation uses Enterprise Pulse, Hybrid Cloud Connector, or Agent Priority. If none of these components are used, this configuration can cause a buildup of RabbitMQ index files (.idx) that consume storage space unnecessarily.

Workaround for new installations: Execute the DB installation scripts manually (located at \\Program Files (x86)\Virtual Hold Technology\SQL Server Database Installation Scripts by default), then ensure that EnableCallDataFeed is set to TRUE (VHT_Config DB > SystemVariables table).

Workaround for upgrades: Check the value of the EnableCallDataFeed system variable and set it to FALSE if it is not already. You can use the SQL query below to check the value:

SELECT [SiteName]    ,[VariableName]    ,[Value]  FROM [VHT_Config].[dbo].[SystemVariables]  WHERE [VariableName] = 'EnableCallDataFeed'

If EnableCallDataFeed is not present in the SystemVariables table, add it into the table with a value of FALSE and restart QueueManager for the change to take effect.

Versions affected: 9.1 to 9.2.3

In CIC environments, when an ASAP callback fails due to no answer from the customer, an unknown disposition is received from CIC.

Because of this, the call is assigned a final fate of Q9 - Max Try Again, rather than the expected Q6 - Max No Answer.

Versions 8.6 - 8.10.3: Set Callback Double Check -Scope to Global

Versions 8.10.4 or later: Set Callback Double Check -Where to Check for Duplicates to All Queues