Jump to: navigation, search

Troubleshooting

Workbench Installation

Administrator/Sudo Permissions

Important
  • Ensure Workbench is installed with Administrator (Windows) or Sudo (Linux) permissions
    • i.e. for Windows open a Command/Powershell Console As Administrator and run install.bat.
    • i.e. for Linux open a Terminal run ./install.sh with a user that has sudo permissions - do not prefix ./install.sh with sudo

CME Templates

Important
  • Ensure each and every Engage CME Application has an assigned Template else the Workbench installation will fail.

CME Host IP Addresses

Important
  • Ensure Engage CME Hosts Objects have an IP address assigned else the Workbench installation will fail.

Network Ports

Workbench components use the network ports below, from a firewall perspective, please review, edit and ensure not already in use.

Warning
  • Double-check, the network ports, that are used by Workbench, are from a firewall perspective, open and not already in use by other applications

Logs


When opening a Genesys Customer Care Workbench support Case, it is useful to include Workbench log files to enable efficient troubleshooting.

Workbench produces log files for several Workbench components, the sections below detail log files to include in support Cases:

Workbench Logs


All logs from "<WORKBENCH_HOME_INSTALL_FOLDER>\karaf\data\log" covering issue occurence

Workbench Kibana Logs


All logs from "<WORKBENCH_HOME_INSTALL_FOLDER>\Kibana\logs" covering issue occurence (ideally Verbose Log Level)

Client Browser Logs


Ideally Client Browser logs covering issue occurence

The Chrome Dev-Tools may be useful: https://developers.google.com/web/tools/chrome-devtools

Client Browser URL is big and Kibana might stop working


If a The URL is big and Kibana might stop working error message is encountered, Genesys recommends:

  • Login into Workbench
  • Open a new Browser tab
  • Navigate to http://<WB_HOST>:8181/app/kibana#/management/kibana/settings/
  • Scroll down to Store URL's in session storage and set state:storeInSessionStorage to ON

Temp Directory

For the Elastic stack components, Elasticsearch and Logstash are the main Workbench components that write to the node/host system Temp directory; these Temp directory locations can be changed via the respective local config files.

For the Logstash component please change the following file:

  • {WB_Install_Home_Location}\Logstash\config\jvm.options
  • Within the jvm.options file, uncomment (remove the “#”) from the start of “-Djava.io.tmpdir=$HOME”
  • Replace “$HOME” with the directory location that you would like to use for Temp.
  • After saving the file, restart the Windows WB_Logstash_9.1.x Service for the changes to take effect.

For Elasticsearch, change the Temp directory by setting the following environment variable:

  • "ES_TMPDIR".
  • After setting that environment variable, please restart the WB_Elasticsearch_9.1.x Service for the changes to take effect.

Workbench Services

Workbench should only be Stopped/Started using the respective Workbench Services that are added during installation.

If the Workbench Services are not visible please ensure the Workbench installation was performed as an Administrator (Windows) or with sudo (Linux) permissions.

Changes Console 'ChangedBy' shows User = "N/A"


For the Changes Console ChangedBy field to be accurate (not "N/A"), the following Genesys Engage configuration is required:

  • A connection from the respective Genesys Engage Configuration Server or Configuration Server Proxy to the Genesys Engage Message Server that Workbench is connected to.
  • If not already, standard=network added to the log section of the Configuration Server or Configuration Server Proxy that Workbench is connected to.

Also, this issue may occur if the Genesys Engage Message Servers have been Stopped/Started/Terminated; if so, restart the WB_IO_Primary application and the ChangedBy field should show the correct Username.

Workbench Upgrade failure

Single Node deployment, or Primary node deployment in cluster, upgrade failed

  1. To enable troubleshooting, backup logs for Workbench 9.0.1:
  • WBAgent logs: C:\Program Files\Workbench_9.0.100.00\WorkbenchAgent\logs
  • ElasticSearch logs: C:\Program Files\Workbench_9.0.100.00\ElasticSearch\logs
  • Zookeeper logs: C:\Program Files\Workbench_9.0.100.00\ZooKeeper\logs
  1. Extract the downloaded Workbench_9.0.100 .00_Pkg.zip compressed zip file.
  • Browse to Worbench installation folder (C:\Program Files\Workbench_9.0.100.00) and locate file uninstall.bat
  • Execute uninstall.bat file as administrator
  • After the uninstall in complete, delete any traces of sub-folder or files in the Workbench_9.0.100.00 or installation folder.
  1. After successful uninstall, reinstall Workbench 9.0.1.

Cluster deployment, upgrade failed

If there was a successful upgrade on the primary node but an unsuccessful upgrade in an additional node:

  1. To enable troubleshooting, backup logs for Workbench 9.0.1:
  • WBAgent logs: C:\Program Files\Workbench_9.0.100.00\WorkbenchAgent\logs
  • ElasticSearch logs: C:\Program Files\Workbench_9.0.100.00\ElasticSearch\logs
  • Zookeeper logs: C:\Program Files\Workbench_9.0.100.00\ZooKeeper\logs
  1. Uninstall Workbench 9.0.1.
  • Browse to Workbench installation folder (C:\Program Files\Workbench_9.0.100.00) and locate file uninstall.bat
  • Execute uninstall.bat file as administrator
  • After uninstall also delete traces of folder
  1. After successful uninstall, reinstall Workbench 9.0.1.
Important
  1. Run these steps only on the additional node where the upgrade failed.
  2. At the end of an upgrade, all primary and additional nodes should be at same version (Workbench_9.0.100.00).
This page was last edited on August 23, 2021, at 14:35.
blog comments powered by Disqus