Avaya Analytics for Oceana - Release 4.1.1.

0
Avaya_Analytics_4.1.1.0_104_009 ReadMe

Issue Date (DD/MM/YYYY): 11/09/2024

Patch ID: Avaya_Analy cs_4.1.1.0_104_009

Patch Type: Bug Fix

Applica on Name: Avaya Analy cs for Oceana

Product version: 4.1.1.0
Component versions:
Analy cs Orca chart 5.3.104
MSTR chart 5.3.52
Async Async Chart 0.2.12
Required CSP CSP Version 1.2.100021330016
CCM Version 1.2.0.2.128003

Note:
The build number (e.g. 5.3.xxx below) that shows up in version checks on the server is an internal build number.

Product Version InstanceId Health

Analytics 5.3.xxx orca -

The patch version is not displayed, it must be deduced from orca chart version and release notes.
e.g. Orca chart = 5.3.xxx
Release = 4.1.1.0
Patch number = 999
Patch Name = Avaya_Analy cs_4.1.1.0_xxx_999

From 4.1.1.0 Patch 5 onwards, this number has been incremented to 5.3.xxx so the nal 3 digits may be
lower than what was included in previous patches.

Patch Overview
This patch contains updated non-expiring license key for MSTR.
ti
ti
ti
ti
ti
fi
 Pre-Staging Feature Overview

Pre-staging allows all Avaya Analy cs and Common Services so ware to be downloaded prior to
upgrading the system. This reduces the maintenance window required to upgrade the system as
previously this download had to be performed during the maintenance window.

How to use the Pre-Staging Feature (no maintenance window required)

1. You will now be able to use the pre-staging feature.

2. Fill out the Deployment Excel provided with this Patch and transfer to the CCM.

3. To calculate the download size of the required so ware run:

ccm upgrade spec <Deployment Excel File> --stage --calculate-size

This command will take around 15 minutes to run and will output the size of the download
required.

4. Prior to running the next command, please start a “screen” session to avoid the SSH connec on
ming out during the staging process.

5. To pre-stage the so ware run:

ccm upgrade spec <Deployment Excel File> --stage

This command will download all so ware required to upgrade the system. Depending on
bandwidth, this can take 1-2 hours to complete.

6. To check the staging has completed successfully run:

ccm upgrade spec <Deployment Excel File> --status

2
ti
ft
ti
ft
ft
ft
ti
 Patch Install Steps
This table describes the steps required for each of the supported deployment paths. Links to the
appropriate sec on describing the steps are included.

Install Path Steps Required

Upgrade 4.1.1.0 GA Patch 8 to 4.1.1.0 Patch 9 Upgrade Avaya Analy cs Services
Post Installa on Instruc ons

4.1.1.0 Patch 8 -> 4.1.1.0 Latest Patch 9

This patch may be used to perform an upgrade from a 4.1.1.0 Patch 8 install to the latest 4.1.1.0 patch.

1) Pre-Upgrade Steps
a) Verify system health by running ccm smoke-test and checkInfra
b) Follow the steps in the “Pre-installation instructions” section in this ReadMe.
2) Upgrade Products
a) If using the pre-staging feature highlighted in the Patch Overview, do so now.
b) Follow the steps in the “Upgrading Avaya Analy cs Services” chapter in this ReadMe to
apply the patch.
3) Post Upgrade Steps
a) Restart the MSTR srv pod.
Note: Ensure you logged in to CCM using cust and then switch to root user.
i) Wait un l pod is 1/1 a er the upgrade. That ensures all mstr objects are updated. If restart
is done before pod is in 1/1 state one more restart may be required.

ii) Find srv pod name: kubectl get pods -n mstr | grep mstr-srv

iii) Restart mstr-srv pod: kubectl delete pod -n mstr <mstr-srv-pod-name>

Patch Deployment Instructions

This sec on covers the upgrade from 4.1.1.0 Patch 8

General
This patch includes:
Updates to mstr services

3
ti
ti
ti
ti
ti
ft
ti
ti
 Current Active Line-up
Analy cs 4.1.1.0 follows a cumula ve patch line-up. Unless otherwise stated this patch rolls up all
previous patches.

Patch Install Timings

A maintenance window is required to perform a patch update. Rolling updates are not currently
supported. No contact center ac vity can occur during this window.

The following mings are indica ve and approximate mings to help be er plan the maintenance
window. These mings may vary based network bandwidth, hardware capacity, etc.

Approximate Timing

4.1.1.0 Patch 8-> 4.1.1.0 Patch 9

Pre-staging mming 40-50 minutes
Upgrade of MicroStrategy 60-70 minutes

A similar amount of me is required to rollback a patch if that is deemed necessary.

Pre-installation instructions
Important:
1. Before installing this patch ensure you take a database backup using the Analy cs control script.
• See sec on Avaya Analy cs™ backups in Chapter: Maintaining Avaya Analy cs™ using
the Cluster Control Manager console of the Maintaining and Troubleshoo ng Avaya
Analy cs for Oceana guide.

2. Before installing this patch ensure all custom reports have been archived.
o Method
• Run ccm release orca analy cs
• Select “Historical Repor ng”
• Select “Backup Metadata”
• Select “Backup Metadata” again
• Wait for the backup to nish
• Press b for back
• Select 4. Historical Repor ng
• Select 8. Export Backups
• Wait for export to nish
• Press q to quit
• Verify that the backup is now located in the /home/<customer_account_login>/
historical_md_backups/ directory on CCM.

3. Before installing this patch ensure the following creden als are s ll valid.
o Harbor
o vCenter

4
ti
ti
ti
ti
ti
ti
fi
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
tt
ti
ti
ti
 Use the checkInfra script to check vCenter creden als, con gura on and network connec vity.

4. The spreadsheet needs to be updated with the current MicroStrategy passwords.

5. Preparing the deployment spreadsheet

a. Use spreadsheet delivered with this patch as primary spreadsheet.
b. Enable the macros before you start edi ng the worksheets.
c. If latest spreadsheet used for earlier deployment and/or patches is available retrieve that and
copy to a loca on that you can access from your desktop.
d. Open current patch spreadsheet.
e. Click the Deployment Proper es tab.
f. To copy your con gura on from the previous version of the deployment spreadsheet click Load
Previous Con gura on Values.
g. To import the le from your local machine, browse for the le and click Open.
h. A er the spreadsheet is updated, review the all the con gurable elds, and update any value that
is incorrect or missing.
NOTE: The key con gurable elds are marked in orange in the spreadsheet. The corresponding rows
describe the informa on that you must enter in the respec ve elds. If required review Chapter tled
“Planning and precon gura on”, of the Deploying Avaya Analy cs for Oceana guide, sec on “Avaya
Analy cs™ deployment spreadsheet overview” for instruc on on how to complete the spreadsheet.

6. Take VM Snapshot of CCM

o Login to vCenter managing the Analy cs Cluster and take a virtual machine snapshot of the
Cluster Control Manager.
NOTE: The recommenda on is to avoid using a snapshot for more than 72 hours to avoid risking
performance degrada on of the virtual machine as well as the ESXi host.

5
ft
ti
fi
ti
fi
fi
ti
fi
ti
ti
fi
ti
ti
ti
ti
fi
ti
ti
ti
fi
ti
fi
fi
ti
ti
fi
fi
ti
ti
ti
ti
 Upgrade Avaya Analytics Services
Before You Begin
Ensure the correct installa on method is chosen. This will most likely be the method used at the original
installa on me. Review the following chapters of the Deploying Avaya Analy cs for Oceana guide if
unsure:

• Chapter 9: Deploying Avaya Analy cs online

• Chapter 10: Deploying Avaya Analy cs o ine

Important:
Manual Con g. Map changes are not supported. Patches will overwrite these.

Verify DB Pods in standard state

Check the status of the crunchy pods using commands below:

1. Connect to the CCM server using the customer account log in using cust and then switch to root
user.

2. Check the status of the crunchy pods

k describe pod crunchy-primary-service-orca-dbmgr-0 | grep name=

k describe pod crunchy-replica-service-orca-dbmgr-0 | grep name=

3. If output similar to above is observed, then DB pods are in Rainy Day/non-standard state.
Primary de ni on is poin ng at replica pod as end point while replica is poin ng at primary pod.
If in this state follow the steps below otherwise proceed with appropriate upgrade procedure.

4. Delete the replica db pod

k delete pod crunchy-replica-service-orca-dbmgr-0

5. Wait for all the pods to be in running state

[root@ccm112 cust]# k get pods | crunchy

crunchy-pgpool-orca-0 1/1 Running 0 4h57m
crunchy-primary-service-orca-dbmgr-0 1/1 Running 0 28m
crunchy-replica-service-orca-dbmgr-0 1/1 Running 0 28m
crunchy-watch-orca-56fdc58f94-24p7t 1/1 Running 0 28m

6
ti
fi
ti
fi
ti
ti
ti
ti
ti
ffl
ti
ti
 [root@ccm112 cust]#

6. Check the status of the crunchy pod. Pod status should be the same as below. This is Sunny Day
state in terms of primary/replica roles. If so, con nue with upgrade.

Online Procedure
1. Connect to the CCM server using the customer account log in.

2. Copy <solution spreadsheet name>.xlsm to a loca on on the CCM server.

3. Switch to root user and execute the following command as root to remove crunchy watch before
star ng upgrade

k scale deployment crunchy-watch-orca --replicas=0

A er this exit from root user

4. From the directory on CCM that contains the excel le, enter the following command with cust
user:

screen

5. Run the following command:

ccm upgrade spec <solution spreadsheet name>.xlsm –-products

If the Prometheus pod is not star ng or an Async pods in a 0/1 Ready state and either of this
cause the upgrade to not complete, then the valida on checks on these pods can be skipped by
adding the --force op on to the end of the command

7
ft
ti
ti
ti
ti
fi
ti
ti
 6. When prompted:

a. Enter vCenter creden als

b. Enter creden als

c. Accept the EULA.

d. Con rm Upgrade

7. The installa on starts downloading and installing.

8. Run the following command to monitor the progress of the install:

tail -f /var/log/avaya/ccm/ccm-main.log

9. The upgrade command will exit when complete.

10. Execute the following command as root to set the replica count for crunchy watcher back to 1.

k scale deployment crunchy-watch-orca --replicas=1

11. Con rm the opera onal state of the Analy cs cluster. Run the following command:

ccm status --pod-details

All pods should report running with n/n repor ng ready before con nuing to the next step. Refer
to Post-installa on veri ca on chapter of Deploying Avaya Analy cs for Avaya Oceana for
further details on con rming the status of Analy cs.

Important:
If the ccm upgrade spec command fails, resolve the issue causing the failure and restart the
upgrade by running: ccm upgrade resume command. For more informa on about troubleshoo ng
installa on failures, see Maintaining and Troubleshoo ng Avaya Analy cs™ for Avaya Oceana.

O ine Procedure
Downloading Avaya Analy cs chart and images
Before you begin you must have:

• Valid Avaya SSO creden als.

8
ffl
fi
fi
ti
ti
ti
ti
ti
ti
fi
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
 • A func onal ccm-agn-ctl container on your laptop.

7. On your Windows PC or client computer, save the Analy cs Excel Spreadsheet in c:

\avaya\downloads.
Note: Windows and the CCM Controller container share a mount point, which are c:
\avaya\downloads and /root/downloads respec vely.

8. In the ccm-agn-ctl container, run cd /root/downloads.

9. To download the Avaya Analy cs™ charts and images from the Avaya repository, run the
following command:
agn download <solu on spreadsheet name>.xlsm

10. When requested enter creden als.

The agn script processes the excel spreadsheet and the Avaya Analy cs™ charts and docker
images start downloading. The ccm-agn-ctl container displays an Image Pull Report when the
download is complete.

11. To view a list of the downloaded images, run the following command:
docker image ls

12. To view a list of the downloaded charts, run the following command:
ls /root/downloads/*.tgz

13. (Op onal) If you see a docker pull error, you can view or retrieve the logs within the ccm-agn-ctl
container at /var/log/avaya/ccm/ccm-main.log.
For more informa on on possible issues and the respec ve troubleshoo ng solu ons, see the
Maintaining and Troubleshoo ng Avaya Analy cs for Oceana guide.

Uploading Avaya Analy cs chart and images

Before you begin:

• Ensure air-gap running

agn-ctl status

• If not running, then run the following:

agn-ctl setup

agn-ctl start

14. Connect to your air gap network using your Windows PC or laptop.
15. Start the ccm-agn-ctl container by using the following ccm-agn-ctl.bat le in the Windows
PowerShell console: C:\avaya\ccm-agn-ctl.bat

9
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
 16. Using the ccm agn deployed container, run the following command: agn upload <CCM FQDN>,
where <CCM FQDN> is the FQDN of your CCM.
17. To access the CCM docker registry and ChartMuseum, enter the username when prompted.
18. Enter the password.
19. Re-enter the password.
The agn command starts the following in a sequence:

20. Processes the available chart and image data on the Windows PC or laptop.
21. Starts uploading the charts and images to CCM. When the upload is complete, the console
displays an image push report.
22. (Op onal) If you see a docker pull error, you can view or retrieve the logs within the ccm-agn-ctl
container at /var/log/avaya/ccm/ccm-main.log.
For more informa on on possible issues and the respec ve troubleshoo ng solu ons, see the
Maintaining and Troubleshoo ng Avaya Analy cs for Oceana guide.

23. To copy the <solu on spreadsheet name>.xlsm le, run the following command in the ccm-agn-
ctl container:scp /root/downloads/
<solu on spreadsheet name>.xlsm <ccmUser>@<CCM FQDN>:,

where <ccmUser> is the CCM customer login account and <CCM FQDN> is the FQDN of your CCM.

Note: Do not skip the colon at the end of the command.

24. In the Are you sure you want to con nue connec ng eld, type yes and press Enter.
25. At the prompt, enter the CCM user password.
The ccm-agn-ctl container uploads the images and charts, which you earlier downloaded

on the Windows PC or client laptop, into the local CCM docker registry and chartmuseum.

Upgrading Avaya Analy cs services

26. Log in to the Cluster Control Manager (CCM) console as the customer account user.
27. To switch to the root user, enter su.
28. To con rm that the local CCM docker registry and chartmuseum is running, run the following
command:
agn-ctl status
29. Copy <solu on spreadsheet name>.xlsm to a loca on on the CCM server.
30. From the directory on CCM that contains the excel le, enter the following command:
screen
31. Run the following command:
ccm upgrade spec <solu on spreadsheet name>.xlsm --products

10
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
fi
fi
ti
ti
ti
 If the Prometheus pod is not star ng or an Async pods in a 0/1 Ready state and either of these
cause the upgrade to not complete, then the valida on checks on these pods can be skipped by
adding the --force op on to the end of the command
32. When prompted:
33. Enter your Avaya SSO creden als.
34. Accept the EULA.
35. Enter the vCenter user ID and password.
36. Re-con rm the password.
37. The installa on starts downloading and installing the following:
• The Avaya Analy cs™ so ware
38. Run the following command to monitor the progress of the install:
tail -f /var/log/avaya/ccm/ccm-main.log
39. The upgrade command will exit when complete
40. Con rm the opera onal state of the Analy cs cluster. Run the following command:
ccm status --pod-details
All pods should report running with n/n repor ng ready before con nuing to the next step. Refer
to the post-installa on veri ca on chapter of Deploying Avaya Analy cs for Avaya Oceana for
further details on veri ca on.

Important:
If the ccm upgrade spec command fails, resolve the issue causing the failure and restart the upgrade by
running: ccm upgrade resume command. For more informa on about troubleshoo ng installa on
failures, see Maintaining and Troubleshoo ng Avaya Analy cs™.

11
fi
fi
ti
ti
ti
ti
ti
fi
ft
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
 Post Installation Instructions

Restart MSTR srv pod

a) Switch to root user and restart the MSTR srv pod.

i) Wait un l pod is 1/1 a er the upgrade. That ensures all mstr objects are updated. If restart
is done before pod is in 1/1 state one more restart may be required.

ii) Find srv pod name: kubectl get pods -n mstr | grep mstr-srv

Verify Running Solution

To verify the solu on is back running fully:

1. Follow the instruc ons in the chapter: Post-installa on veri ca on of Deploying Avaya Analy cs
for Oceana guide.

2. Run smoke test

a. Connect to the CCM server

b. Run the following command with root user

ccm smoke-test

c. Verify pods are in a running state with root

3. Verify Historical Repor ng.

a. Login to Historical repor ng.

b. Run one or more reports.

4. Verify Real Time repor ng.

a. Ini ate voice or mul media contact.

b. Login into Workspace and verify the real- me reports are upda ng.

5. Remove the CCM Virtual Machine snapshot taken at the beginning of the upgrade procedure.
Failure to do so can result in performance degrada on of the CCM as well as the ESXi host.

12
ti
ti
ti
ti
ti
ft
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
 Rollback Procedure
In the event a patch install cannot be completed, and it is required to roll back to the prior release use
the following procedure.

1. Rollback to previous version of so ware:

i. Connect to the CCM server using the customer account log in.

ii. Copy excel sheet backed up during Pre-installa on instruc ons to a loca on on the CCM
server.

iii. From the directory on CCM that contains the excel le, enter the following command:

screen

iv. Run the following command:

ccm upgrade spec <solution spreadsheet name>.xlsm

v. When prompted:

• Accept the EULA.

• Con rm Upgrade

vi. The installa on starts downloading and installing.

vii. Run the following command to monitor the progress of the install:

tail -f /var/log/avaya/ccm/ccm-main.log

viii. To check if the installa on is successful, run the following command on the CCM console:

ccm status

2. Rollback to previous version of custom reports:

i. Bash onto mstr-md pod

kubectl exec -it <mstr-md-hashed-number> --namespace=mstr -- /
bin/bash

ii. Create directory to save backup to:

mkdir -p /opt/app-root/src/md_full_backup/

iii. Type 'exit' to exit the pod

iv. On ccm change directory to where backup was exported
cd /home/cust/historical_md_backups

v. Copy the full MicroStrategy backup le onto the pod

13
fi
ti
ti
ft
fi
ti
fi
ti
ti
 kubectl cp <full_backup_Date-Time.bkp> --namespace=mstr <mstr-
md-hashed-number>:/opt/app-root/src/md_full_backup/
<full_backup_Date-Time.bkp>

vi. Bash onto mstr-md pod

kubectl exec -it <mstr-md-hashed-number> --namespace=mstr -- /
bin/bash

vii. Run the command to restore full backup

psql -U postgres -f /opt/app-root/src/md_full_backup/
<full_backup_Date-Time.bkp> postgres

viii. The output on the console can have to Errors pertaining to the postgres user. These can be
ignored.
psql:/opt/app-root/src/md_full_backup/
full_backup_2020_05_27_16_20_23.bkp:23: ERROR: current user cannot be
dropped

psql:/opt/app-root/src/md_full_backup/
full_backup_2020_05_27_16_20_23.bkp:31: ERROR: role "postgres" already exists

ix. Connect to postgres database

psql

x. List available databases with \l command. Con rm the avaya_analy cs_md db.
postgres=> \l

xi. Quit databases with \q command.

postgres=> \q

xii. Type 'exit' to exit the pod

xiii. Verify that the custom reports have been restored

DR Installation
If installing this patch into a solu on with a disaster recovery site, the following is the recommended
order:

1. Apply patch to primary side.

2. When complete, apply patch to DR site.

Note: Data from the database will be replicated between the primary site and the DR site in the normal
way. See Deploying Avaya Analy cs for Oceana guide for details.

Before star ng installa on on DR site Ensure DB pods are in standard state as explained in sec on Verify
DB Pods in standard state.

If upgrading from a previous version of Analy cs it is advised to rebuild DR as outlined in Analy cs

Deployment Guide, sec on Con guring Avaya Analy cs™ for Disaster Recovery.

14
ti
ti
ti
fi
ti
ti
ti
fi
ti
ti
ti
ti
15
 Deployment Excel Deployment Options
The deployment excel now supports two deployment op ons, Produc on and Lab

• The “Lab” op on is for lab only installa ons adding support for Async as part of a Non-
HA deployment.
• The “Produc on” op on must be selected for all produc on-based deployments as lab
based deployment will not be supported in produc on.

16
ti
ti
ti
ti
ti
ti
ti
ti
 Known Issues
Issue 1
Upgrade may fail due to lack of space.

If an a empt is made to perform an upgrade on a system where a number of upgrades/patches have

already been installed it may fail with a lack of space due to ccm unstage not cleaning up orca and mstr
images.

This workaround is only required if the space usage of /var/lib/docker/ is above 75%.

1. Switch to root using “su – root”

2. Check the space usage of /var/lib/docker/
df -h
3. If above 75% then unstage older undeployed charts.
ccm unstage <chart>
4. Orca and MSTR charts will need some manual clean up a er being unstaged.
5. Run the following on the CCM to create a list of orca and mstr images:
If upgrading from Analy cs 4.0.0.1:
docker images | grep orca | grep 4.1 - check for repeated image names and remove
the older version of the repeated image (e.g. 4.1.12 vs 4.1.14, remove the 4.1.12 image)

If upgrading from Analy cs 4.1.0.0:

docker images | grep orca | grep 4.1 - remove all
docker images | grep orca | grep 5.0 - check for repeated image names and remove
the older version of the repeated image (e.g. 5.0.12 vs 5.0.14)

docker images | grep mstr | grep 4.0.11 - remove all

docker images | grep mstr | grep 4.1 - check for repeated image names and remove
the older version of the repeated image (e.g. 4.1.11 vs 4.1.12, remove the 4.1.11 image)

If upgrading from Analy cs 4.1.0.1:

docker images | grep orca | grep 4.1 - remove all
docker images | grep orca | grep 5.0 - remove all
docker images | grep orca | grep 5.1 - check for repeated image names and remove
the older version of the repeated image (e.g. 5.1.12 vs 5.1.14, remove the 5.1.12 image)

docker images | grep mstr | grep 4.0.11

docker images | grep mstr | grep 4.1 - check for repeated image names and remove
the older version of the repeated image (e.g. 4.1.11 vs 4.1.12, remove the 4.1.11 image)
Example:

17
tt
ti
ti
ti
ft
 Here remove the “4.1.1.13” images and not the “4.1.1.14” images.

6. Important: Before proceeding, take note of each Image displayed, including Image Name, Image
Tag and Image ID. You will need this informa on later.
7. Run "docker image rm" for each of the relevant Image IDs
docker image rm <Image ID 1> <Image ID 2> <Image ID 3> ...
Example: docker image rm 663e8a4e29d0 76b929a2c9a1
8. Once nished cleaning up the Images from CCM, they will also need to be purged from the
cluster registry
9. Create a list of images available in the cluster registry
ccm registry repos --tags | grep orca
ccm registry repos --tags | grep mstr
10. For each image removed in step 7, run:
ccm registry purge <image name> <image tag>
Example: ccm registry purge ex/mstr-av-web11.2.1 4.1.12
Note: there is a space between <image name> and <image tag>

Issue 2
The following message may be reported during install.
WARNING: Service release "orca" did not become ready in the allo ed me. Processing will con nue.
This usually can be ignored as the it is just a warning that a pod is slower than others to start-up. If a er
the rest of the install completes all orca pods look healthy, then there is no issue here.

Compatibility with Existing Data

This Analy cs patch does not retrospec vely x data already stored in the database before this patch is
applied.

18
fi
ti
fl
ti
ti
fi
tt
ti
ti
ft
 Appendix
Solu ons provided in Avaya_Analy cs_4.1.1.0_104_009
JIRA ID Title Impact
WAVE-50404 MSTR Master Licenses Key Update: Patch Update non-expiry licence key in mstr for
Crea on with new non_expiry licence keys analy cs 4.1.1.0 patch 8.

Solu ons provided in Avaya_Analy cs_4.1.1.0_101_008

JIRA ID Title Impact

WAVE-22467 MSTR 2020 Update 6 – Log4J Vulnerability CVE-2021-44228/CVE-2021-45046
mi ga on
FLEX-24174 Move log4j2 dependency version from 2.x.x CVE-2021-44228/CVE-2021-45046
to 2.15.0 in the Alarming chart services
FLEX-24210 Log4J zero-day exploit x CVE-2021-44228/CVE-2021-45046
FLEX-24170 Move log4j-core from 2.x.x to 2.17.1 in the CVE-2021-44228/CVE-2021-45046
even ng chart services
FLEX-24178 Changes to address log4j-core jar CVE-2021-44228/CVE-2021-45046
vulnerabili es in the logging service chart

Enhancement provided in Avaya_Analy cs_4.1.1.0_100_007

JIRA ID Title Impact

WAVE-20728 Analy cs SLA repor ng on each me the 3 new Call Pro le reports were
call is routed into the CC from IVR implemented to allow to correctly
calculate SLA for calls transferred to IVR

Solu ons provided in Avaya_Analy cs_4.1.1.0_94_006

JIRA ID Title Impact

WAVE-22047 Historical Repor ng MicroStrategy license Historical Reports no longer accessible on sites
key expired which have the expired license installed

Solu ons provided in previous patches

JIRA ID Title Impact
WAVE-19148 Contacts wai ng in Rou ng Performance Incorrect values displayed for Contacts
RTD is incorrect a er midnight pump-up Wai ng on the Rou ng Performance Real
Time Dashboard
WAVE-19116 Real me Reports lagging behind by up Updates to Real me Dashboards were
to 1 hour delayed by up to one hour

19
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ft
ti
ti
fi
ti
ti
ti
ti
ti
ti
 WAVE-18678 Agent logon dura ons are doubled when Agent Logon dura ons were repor ng
searching by Agent Groups incorrectly on Historical Reports
WAVE-18572 Hold me dura on is not calculated Hold Time Dura on repor ng inaccurately
correctly when consult call is held for consult calls
WAVE-18280 Agent Login\Logout report missing Historical reports missing data for Agent
records Login/Logout
WAVE-18158 Analy cs 4.1.0.1 Patch 3 Excel Deployment Excel did not re ect the
Spreadsheet no longer updates Available Available Hosts entry correctly
Hosts cell for non-HA con gura on
WAVE-18139 Maintaining and Troubleshoo ng M&T Guide missing informa on to
method needed when 'Send now' op on troubleshoot a issue
sends rst page only of PDF
WAVE-18121 Data on Real me Repor ng Dashboard Delay in midnight reset on Real me
not cleared at Midnight but 8 hours later Dashboards
WAVE-18069 Abnormal on not ready Meal Break code Not Ready dura on calculated incorrectly
which exceed login me on certain Reason Codes
WAVE-17816 Contacts Wai ng does not decrement Contacts Wai ng Real me Dashboard was
correctly repor ng inaccurately
WAVE-16381 Rou ng service group are shown not Rou ng Service Group prompts in
assigned to supervisor in historical Analy cs Historical Reports may show all
reports groups which contain rou ng services
assigned to supervisor while supervisor
may be not assigned sone of these groups.
WAVE-14681 Help les for Standard Func ons (used in Historical Repor ng Help Files were not
Reports) are missing func oning
WAVE-6329 MSTR shows all the groups (not Agent Group Filter was showing all Agent
monitored by supervisor) to which agent groups that an Agent was assigned
is assigned incase agent is also part of regardless of what Agent Group the
monitored group of logged in supervisor Supervisor was assigned

Further Support Assistance

For further assistance please contact your Avaya Support representa ve for any queries on this patch or
readme.

Copyright © 1999-2022 Avaya Inc. All rights reserved.

20
ti
ti
ti
fi
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
fl
ti
ti
ti
ti
ti
ti