Another Day – Another Problem to Solve!

We’re taking it technical in this blog!

By Ruslan Makrushin
Avaya Engineer, Rostelecom Digital Technologies

Another day has arrived in the life of a UC engineer in a large company providing implementation and support of Avaya solutions for a large customer.

Several problems have to be solved today:

One new user test05@company.com reports that he cannot log in to his computer in his IX Workplace application, and I need to continue working on an Avaya Service Request created to address the issue that one of the AADS servers is not synchronizing in System Manager.

To deal with the first issue, I begin by checking if the user test05@company.com exists in System Manager:

As we can see, there is no specified user in the System Manager.

But user test05@company.com has to be in System Manager since this user is in the Active Directory server.

That can be checked in AD: Find …  Enter user  in Name field   click Find button.

Now, we copy the user’s telephone number 00101 from AD and paste it in System Manager: 

This shows us that another user3 with telephone number of user5 is already in the System Manager.

This is the reason why our user5 is not in the system: System Manager will NOT add a user with a phone number that another user already added in System Manager.

So we need delete user3 from System Manager and again synchronize System Manager with AD.

To check a reason why a user has not been added in System Manager when synchronizing with AD click Users  Directory Synchronization  Sync Users  Synchronization History TAB  View Job Summary.

Now, we move on to the second problem: A customer reports  that users fail trying to log in their IX Workplace apps.  In this situation, first we have to check the AADS availability and AADS synchronization status:

AADS Synchronization status can be checked:

System Manager web page  Services TAB  Replication  UCAppsServer

During work on the Service Request created in Avaya, Avaya engineers recommended to check the following:

cd /var/log/Avaya/DeviceServices/8.x/tomcat-main/
ls –ltrh

df -h

According the outputs of these two commands we found out that localhost log file is not rotating in AADS. This looks to us an issue in AADS:

-rw-r—–. 1 ucapp ucgrp  37G Apr  23 12:58 localhost

Also below details were checked together with Avaya engineer:

svc aads swversion
app status all
svc aads status

[cust@aads-01n02 tomcat-main]$ svc aads swversion
DeviceServices:8.0.2.0.288
[cust@aads-01n02 tomcat-main]$ app status all

2021-03-09_17:52:04 Displaying status for Avaya Aura Device Services Application
2021-03-09_17:52:04 ulimit file count ……………….  [  OK  ]
2021-03-09_17:52:04 ulimit process count …………….  [  OK  ]
2021-03-09_17:52:05 firewalld status …………………  [  OK  ]
2021-03-09_17:52:05 net-SNMP status …………………  [  OK  ]
2021-03-09_17:52:05 AADSKeepalived status ……………..  [  OK  ]
2021-03-09_17:52:06 AADSTomcat status …………………  [  OK  ]
2021-03-09_17:52:06 AADSNginx status …………………  [  OK  ]
2021-03-09_17:52:06 AADSCassandra status ……………..  [  OK  ]

[cust@aads-01n02 tomcat-main]$ svc aads status
Status of Avaya Aura Device Services Application
AADSTomcat      Running         n/a             3819
AADSNginx       Running         n/a             3590
AADSCassandra   Running         n/a             2869
AADSPostgres    Running         n/a             2644
AADSKeepalived  Running         n/a             3645

Avaya R&D is fixing the problem with the log file rotating.

Now the issue is fixed by removing localhost file and changing Service Logging Level to Warning in AADS WEB page:

Now, we check AADS synchronization status (below), and everything looks good. Another day, another problem solved!

Leave a Reply

Your email address will not be published.