TBUG632 in Telephony manager

[CanGoalie]

thread798-1592416

CS1000 MG Release 5.0 / TM 4.0
When acessing the troubleshooting tab for a particular set, I get the TBUG632 message instead of IDLE or BUSY.

Noticed that it does not do it for older systems 25.40B or on a particular release 5.0 system without a DEP list installed.

Any ideas? Wondering if the user in the referenced thread had success rectifying his problem.

 

[NortelGuy1979]

There is patch for this that we made Nortel design - apparently we were the first to find it.

I had to dig thru case history here:

***Date (ET): 2010-02-03 1:03:46 PM Who: Service Requests Web Tool
***Activity Name: Notes Action Type: Customer comment
*** Performed by contact: Matthew Heavner, 310-xxx-xxxx
I have received an email from our CSAM which via the PLM indicates that a VO patch is available 4000121P6; I have been requested by the CSAM / PLM to trial on-site; awaiting customer approval.

It was CR#:

Solution S00339255
Knova: Wrong info displays in Maintenance page
Problem:
4580125: Wrong info displays in Maintenance page

Resolution:
Some set types as I2004, I2001, I2002, IPACD and I2050 didn¿t support on Call Server Rls 6.0 but they still display on Maintenance page. In addition, tries to register IP phones to system, user sees that the status of sets is TBUG632. The status must be Idle or Busy. This status always display for 1150 set despite set registered or not.

After that, we had a couple other issues:
Problem Scenario (A detailed summary description of the symptoms) :
Problem: The designer (P6) patch has fixed the TBUG, but now the ¿Troubleshoot Problems¿ page just hangs after trying to run a command. It still does not show you what commands are being performed. However, the command does get through. There is just no way to tell until you check the actual phone, or close and reopen the explorer window
TM 4.0 with SU1+P6 patch on Win 2003
Reference Case# 091020-37325 for more info.

So we opened another case, and got this:
***Date (ET): 2010-04-14 7:40:26 PM Who: davidro3
***Activity Name: Email Out Action Type: External email
Hi Jeff,

Hope you are fine, I'm David Roman from Avaya Global Support Services and I'm the owner of this ticket.

I wanted to inform you that this is a design intent issue as we found on case 091020-37325, I have created the CR Q02134252 and dispatched to the design group. I will keep you informed with the details of the investigation and if necessary will contact you to get remote access to the TM server.

Thanks and regards,

David Roman
Avaya GSS

Then this:
***Date (ET): 2010-04-23 7:12:54 PM Who: rsatri
***Activity Name: Notes Action Type: Progress update
Assisted David with the issue.
Issue is similar to the one noted in CR 2042984-01.
Resolved by changing the binding order where ELAN first and then CLAN.

However after fixing the above we saw that alarms was not being received.
We changed the binding order back and still no alarms.
Found that switch had no alarm table set. Built it and checked all TM alarm configuration however still not results.
Put back the binding order as ELAN CLAN back since we fixed the original issue of this case in that order and started to troubleshoot this issue.
Sending test alarms from PBX and it is received by the alarm banner but not in the alarm module window.
Checked traces and we do not see the traps coming from the PBX.
In the lab Rls 6.0 system we can see the traps during test alarms.

IN SHORT - I think its fixed on the latest patch, but we had quite a bit of fun resolving it.

Matthew - Technical Support Engineer

http://www.linkedin.com/in/matty79