Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Definity/CM Regular Maintenance Routines 1

Status
Not open for further replies.

kulabird

Technical User
Jan 13, 2010
48
US

My question to those who have been (or currently still are) working on large installations: What do you do for maintenance on a regular basis? What tools/procedures/habits have you developed which made you a better administrator?

BACKGROUND
I have been on the installation side for quite sometime and now am ensconced at a single location on contract. With time, I've taken care of all emergencies and now have settled into day-to-day operations and I am looking to improve current operations. I have backups for the various servers in System Platform and Virtual Machines and use 'display alarm/event/error' on a regular basis though some is still a mess of trying to understand. Inventory management is nonexistent - any recommendations? I'd really like a better way to have realtime tracking of alarms - maybe running multiple putty windows or indigo terminal emulator?

SITE
CM 6.3 (duplex core and duplex ESS) running on HP DL360s
CMM 6.3 running on HP DL360
G650 Media Gateways (some 20+ across 7 port networks)
 
I guess it depends how thorough you want to be. In /var/log/ecs on CM you get some good details about any processor errors and denial events - you might find any number of things in there like a call recorder trying to login a recording station that was removed from the PBX long ago.

If you have System and Session Manager and CMS and AES and SBCs and SIP trunks and other stuff hanging off the environment, then there's no shortage of things you can spend time checking to make sure you're running a clean PBX.

What's your survivability and network region design look like? Math out how the thing uses DSPs and how it *should* failover vs how it performs in a failover test and work towards an optimal end state and you can probably justify your existence as long as you're willing to do the job :)
 
Drat. No System Manager, Session Manager, CMS, AES, SBC, or SIP trunks. Only PRI trunks. I'm looking at 7.1 running on VMWare in the future but...that is the future some many months out.

Nice to know about the /var/log/ecs. I've never delved that deep before, usually leaving that to Avaya remote support when fecal matter hits the rotary oscillator. Oh, the fun I will have. Any other suggestions?
 
You I'd say map out the network regions and failover design. That'll give you some work.
 
Kula I can relate. I'm 40 years in telecom and 2 months into Avaya. Just landed a new job with a somewhat large and dispersed system. I'm trying to be proactive and trying to learn all I can in this new Avaya world. I have set the system up to email me with any unresolved alarms. I think that's pretty cool. But I'm open to digging deeper and learning any tricks that I can. Look forward to hearing more from the Avaya folks.
 
Having worked with Avaya for a few years now and that deployment guide that Kyle posted is some really good stuff. Definitely star worthy. Quite a bit of it is actually applicable to the SIP world too but it really is geared toward the H.323 environment.
 
Thanks! I read that book front to back over and over. It's how I started learning Avaya PBX and I still go back to it all the time.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top