Basic Requirements

Run database upgrade scripts

Open \\Virtual Hold Technology\SQL Server Database Installation Scripts and execute the following scripts:

• VHT_Config
• VHT_Config_Inserts
• VHT_RPT
• VHT_RPT_Inserts
• (Optional) VHT_Audit_Create_Tables

If the VHT_Config scripts fail to run when upgrading to On-Premise Callback version 8.10.1 or later, check the QueueGroups table for a site name record that does not exist in the SiteNameDesc table.

Set Outreach extensions

If upgrading to On-Premise Callback version 8.11.0 or later and using the Outreach application, the Outreach extensions must be updated to use Treatment Type 20 in the database.

(Optional) VHT_Audit_Create_Tables

If you set up user audit logging on a pre-8.2 version of On-Premise Callback, and you upgrade to a newer version, you must also run the VHT_Audit_Create_Tables.sql script after upgrading.

The following scripts are optional and only need to be run if you plan to audit and report user activity in the Launchpad:

• VHT_Audit_Create_Connection.sql
• VHT_Audit_Create_Tables.sql
• VHT_Audit_Report_Query_Example.sql

The following scripts are optional and only need to be run if you are working with Support to implement the Monthly License Utilization custom report:

• VHT_RPT_Utilization_CreateTableAndJob.sql
• VHT_RPT_Utilization_PopulateTable.sql

Install license files

Copy the license file (by MAC address) to the root installation directory (C:\Program Files (x86)\Virtual Hold Technology by default) on each Core instance. Within a minute or less, the license file is read by the Licensing component, and the licenses will be available.

If a larger license file is currently in use, the surplus licenses reside in the Global Pool.

Update Avaya UUI

The Call Type Indicator - Agent Priority setting specifies a string that writes in the UUI field for an Agent Priority call, and has a default value of 4. Existing call type indicators in the Avaya UUI menu (Configuration > Telephony > Avaya UUI) may need to be updated if previously configured to use 4.

Check Erlang Ports

Verify any manually-configured Erlang ports are still specified in the registry. If needed, recreate them from the notes you made before upgrading.

Within the registry of each Core and Management server:

1. Check the following paths: (The first is for 64-bit Erlang and the second is 32-bit. Either or both may be in use.)

   • HKLM\SOFTWARE\Wow6432Node\Ericsson\Erlang\ErlSrv\1.1\<service names>
   • HKLM\SOFTWARE\Ericsson\Erlang\ErlSrv\1.1\<service name>

2. Look for the following services:

   • VHT Configuration Management
   • VHT Core Monitor
   • VHT Datastore
   • VHT Management API
   • VHT Notification Server
   • VHT Peripheral Monitor

3. Inside each service, locate and edit the Args key.

4. If needed, add the following string to the beginning of the value, before the existing value already present inside the key.

   There must be a space between the "55999" and the existing value. The existing value should not be modified.

   -kernel inet_dist_listen_min 55000 -kernel inet_dist_listen_max 55999

   Replace 55000 and 55999 in the example with the minimum and maximum port numbers that you noted prior to upgrading.

Update the Core Monitor site.config file to define an Erlang port range

In order to define a fixed port range for firewall rules, you will need to add -kernel settings into the Core Monitor site.config file (located at \\Virtual Hold Technology\Core Monitor by default). The configuration will differ for On-Premise Callback 9.5.7+ and versions prior to 9.5.7.

9.5.7+

For version 9.5.7+, update the start_args in the qm_node_controller section to add -kernel configuration as follows:

{qm_node_controller,
          [{node_prefix,vht_ha_qm},
           {host_name,'FQDN'},
           {start_args,
               ["-kernel","inet_dist_listen_min","10001",
		"-kernel","inet_dist_listen_max","11001",
		"-setcookie","vht_cookie","-boot",
                "C:/Program Files (x86)/Virtual Hold Technology/Core Monitor/releases/9.5.7/vht_ha_qm",
                "-boot_var","RELEASE_DIR",
                "C:/Program Files (x86)/Virtual Hold Technology/Core Monitor"]},
           {max_restart_count,1},
           {restart_period_seconds,420},
           {use_longnames,true}]}

9.5.6 and earlier

For version 9.5.6 and earlier, update the start_args in the qm_node_controller section to add -kernel configuration as follows:

{qm_node_controller, [{node_prefix, vht_ha_qm},
           {host_name, 'FQDN'},
           {start_args, "-kernel inet_dist_listen_min 55000 -kernel inet_dist_listen_max 55999 -setcookie vht_cookie -boot \"C:/Program Files (x86)/Virtual Hold Technology/Core Monitor/releases/9.5.0/vht_ha_qm\" -boot_var RELEASE_DIR \"C:/Program Files (x86)/Virtual Hold Technology/Core Monitor\""},
           {max_restart_count, 1},
           {restart_period_seconds, 420}]} 

Restart the web browser

Restart the web browser before opening the Configuration app.

Start services

Re-establish service accounts for the following services:

• Core Monitor
• Authorization
• Management API
• Configuration Management

Steps to start Callback

To start On-Premise Callback, perform the following steps:

1. Verify the following services are already started on each Management instance:
   • RabbitMQ
   • VHT Authorization
   • VHT Management API
   • VHT Notification Server
   • VHT Statistics

2. Verify the VHT Datastore service is already started on each Core instance.

3. Start the VHT Core Monitor service on each Core instance.

4. Start the VHT Peripheral Monitor service on each Management instance.

5. On each Management instance, open the Configuration Management installation directory (C:\Program Files (x86)\Virtual Hold Technology\ConfigurationManagement by default) and confirm that a Mnesia node named "Mnesia.confmgmt@domain_name" has been created.

   If the Mnesia node does not exist, perform the following steps as an Administrator:

   1. If necessary, stop the VHT Configuration Management service.
   2. Navigate to the \bin directory inside the Configuration Management installation directory.
   3. Execute the first_time_initialization_of_configuration_management_datastore_connection.cmd script.
   4. Confirm that the Mnesia node now exists in the location listed above.
   5. Repeat these steps on each Management instance.
   6. Start the following services on each Management instance:
      • VHT Agent Priority (if you plan to use the Agent Priority feature)
      • VHT Configuration Management

Steps to stop Callback

To stop On-Premise Callback, perform the following steps:

1. Stop the following services on each Core instance:
   • VHT Core Monitor
   • VHT Datastore
2. Stop the following services on each Management instance.
   • VHT Agent Priority
   • VHT Authorization
   • VHT Configuration Management
   • VHT Management API
   • VHT Notification Server
   • VHT Peripheral Monitor
   • VHT Statistics
3. Stop the RabbitMQ service on all instances.

Manual VHT EyeQueue web.config file changes

When upgrading On-Premise Callback, the following changes must be made to the VHT EyeQueue web.config file so that selections of Holding, Callback, and Under Threshold Queue IDs for an incoming extension (from the VHT EyeQueue application) are successful.

1. Save a backup of the current VHT EyeQueue web.config file (located in the \\Virtual Hold Technology\VirtualHoldPub\EyeQueue directory) to another location.

2. Locate the serviceBehavior entry in the behaviors sub-section within the system.serviceModel section of the current web.config file and verify it matches the following:

   <serviceBehaviors>
       <behavior name="PickerServiceBehavior">
           <!--Uncomment the line below for SSL support-->
           <!--<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/> -->
           <serviceMetadata httpGetEnabled="true"/>
       </behavior>
   </serviceBehaviors>  

3. Locate the serviceBehavior entry in the services sub-section within the system.serviceModel section of the current web.config file and verify it matches the following:

   <service behaviorConfiguration="PickerServiceBehavior"
   name="VHT.EyeQueue.Presentation.Services.PickerService">
       <!--Uncomment the line below for SSL support-->
       <!--<endpoint address="" behaviorConfiguration="EndpBehavior" binding="webHttpBinding" bindingConfiguration="webBindingHttps" contract="VHT.EyeQueue.Presentation.Services.IPickerService" /> -->
       <endpoint address="" behaviorConfiguration="EndpBehavior" binding="webHttpBinding" bindingConfiguration="webBinding" contract="VHT.EyeQueue.Presentation.Services.IPickerService" />
       <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
   </service> 

4. Locate the webHttpBinding entry in the bindings sub-section within the system.serviceModel section of the current web.config file and verify it matches the following:

   <webHttpBinding>
   <!--Uncomment the webHttpBinding section below for SSL
       <binding name="webBindingHttps">
           <security mode="Transport"/>
       </binding>
   -->
       <binding name="webBinding">
           <security mode="None"/>
       </binding>
   </webHttpBinding>

Confirm the upgrade on a Core instance

The RabbitMQ and VHT Datastore Services should be running.

The Virtual Hold Registry should indicate the build number installed (8.7.0.653, for example).

On the root of C:\, a log named VHTInstallation is written with a modified date corresponding to the time the upgrade was performed.

Verify the Virtual Hold Technology directory contains:

• RabbitMQ Server
• ReaderBoardAdapter
• SQL Server Database Installation Scripts

Confirm the upgrade on a Management or Peripheral instance

Verify the Virtual Hold Technology directory contains:

• ConfigurationMangement
• RabbitMQServer
• SQL Server Database Installation Scripts directories.

Verify the \\Virtual Hold Technology\Management API directory contains a backup_site.config and site.config file.

Verify the \\Virtual Hold Technology\Notification Server directory contains a backup_site.config and a site.config file.

Verify the \\Virtual Hold Technology\RabbitMQ directory contains a db directory. This indicates that the datastores were correctly clustered.

Verify that the \\Virtual Hold Technology\ConfigurationManagement directory contains an Mnesia node named Mnesia.confmgmt@domain_name. If the Mnesia node does not exist, perform the following steps:

1. Stop the VHT Configuration Management service.
2. Navigate to the \bin directory inside the Configuration Management installation directory.
3. Execute the first_time_initialization_of_configuration_management_datastore_connection.cmd script.
4. Confirm that the Mnesia node now exists in the location listed above.
5. Start the VHT Configuration Management service.
6. Repeat these steps on each Management instance.

Verify the RabbitMQ, VHT Authorization, VHT Management API, VHT Notification Server, and VHT Statistics services are running.

Verify the Virtual Hold Registry indicates the build number (8.7.0.653, for example).

Verify the \\Virtual Hold Technology\SQL Server Database Installation Scripts directory contains the following scripts:

• VHT_Audit_Create_Connection
• VHT_Audit_Create_Tables
• VHT_Audit_Report_Query_Example
• VHT_Config
• VHT_Config_Inserts
• VHT_RPT
• VHT_RPT_Inserts
• VHT_RPT_Utilization_CreateTableAndJob
• VHT_RPT_Utilization_PopulateTable

On the root of C:\, a log named VHTInstallation is written with a modified date corresponding to the time the upgrade was performed.

Verify the Configuration Wizard and VHT EyeQueue icons display on the server desktop.

For On-Premise Callback versions 8.11.0 or later, verify the Configuration icon displays instead of the VHT EyeQueue icon.

Verify the IIS Application Pools have the Identity specified in the solution.json file, and Virtual Directories include ConfigurationManagment and Launchpad.

(9.5.5) Additional requirements

Core Monitor site.config file

When upgrading from 9.5.4 to 9.5.5, the Core Monitor site.config file must be updated manually. The one change required is to update the version in the URL after the -boot flag, as seen below:

Original version

{start_args, "-setcookie vht_cookie -boot \"C:/Program Files (x86)/Virtual Hold Technology/Core Monitor/releases/9.5.4/vht_ha_qm\" -boot_var RELEASE_DIR \"C:/Program Files (x86)/Virtual Hold Technology/Core Monitor\""}

Updated version

{start_args, "-setcookie vht_cookie -boot \"C:/Program Files (x86)/Virtual Hold Technology/Core Monitor/releases/9.5.5/vht_ha_qm\" -boot_var RELEASE_DIR \"C:/Program Files (x86)/Virtual Hold Technology/Core Monitor\""}

(9.5.7) Post-installation steps

After installing version 9.5.7 (or upgrading to 9.5.7), you will need to make two manual changes to Ruby configuration files to update the PATH variable appropriately. This does not need to be done for versions before or after 9.5.7.

1. Open the following files for editing:

   • C:\Ruby33-x64\lib\ruby\gems\3.3.0\gems\vht_auth_api-9.5.8.1\bin\VHTAuthApiService.cmd

     

   • C:\Ruby33-x64\lib\ruby\gems\3.3.0\gems\vht_stats_api-9.5.8.3\bin\VHTStatsApiService.cmd

     

2. In both files, update the set PATH line (line 5) to the following value:

   set PATH=C:\Ruby33-x64\bin;%PATH%

   

(9.5.7) Additional upgrade steps

Before upgrade

Before upgrading to version 9.5.7, copy the first_time_initialization_of_configuration_management_datastore_connection.cmd file from \\Virtual Hold Technology\ConfigurationManagement\bin and save it elsewhere for use after the upgrade finishes.

After upgrade

When the upgrade is complete, follow the steps below:

1. Paste the saved first_time_initialization_of_configuration_management_datastore_connection.cmd back into the \\Virtual Hold Technology\ConfigurationManagement\bin directory, which should be empty after the upgrade.

2. Copy and paste all files from the \\Virtual Hold Technology\Core Monitor\escripts directory into the \\Virtual Hold Technology\Peripheral Monitor\escripts directory.