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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Merge causes Reboot!

Status
Not open for further replies.

cztech

Technical User
Jul 2, 2003
416
US
I have just started experiencing this with a customer today - is anyone familiar with this problem? Even if minimal or no changes are made to the config file, a merge will act like an immediate reboot and disconnect all active calls. I'm using 2.1(15). Haven't heard of this occuring before, I'm just glad for now that I've made the determination of what is causing the reboots. Waiting to hear from Avaya on this as well.
 
I have not seen that happen yet. Best thing to do is upgrade to 2.1.24. It's been on the Avaya web site since Tuesday. Go to the avaya web site, choose Support/Software & Firmware Downloads/IPOffice/All Documents. Once here under the heading Software Downloads, Count # is 4 2.1.24 Core Binaries. Hope this helps. Save files, unzip them, copy all 13 files at once, go to start/c:/program files/avaya......until you get to the manager files, paste and yes to all. I store the complete file in the manager folder after all this for future. This most likely will take care of many bugs not yet published. If it doesn't work buzz back.
 
Havent seen this since V 1.0 when a merge would erase the VM Pro data base and default the system, the good old days.
I would suspect there is something corrupt in your database, try going back over any recent changes additions to cfg, you can always put the back up cfg that I'm sure you have into the unit.

Soopa Doopa Intergalactic IP Office installation mechanic and configuration corruptor from way back.
 
Upgrade to 2.1.24 before you do anything else. Several issues that caused reboots have been resolved in this build.

Peter
 
I upgraded to 2.1.24 yesterday, but I'm still having the same problem. I corrected another problem where a hunt group name was the same as a users name - I thought this might be the solution. So, system is still rebooting on merges. Hope to get to the bottom of this by the weekend.
 
It might be a long weekend. Is this a new install with 2.15? If not did you have the problem before 2.15 or is it occurring after an upgrade. Only thing that I can think of now is what IPAlot suggested, that you have something corrupt with your S/W. Like he said save your current config. to, lets say My Documents, try grabbing an alternate config. Either of the existing customer when you know the reboot was never an issue, choose an alternate customers config. of similar nature load it see if the merge still causes the reboot. All else failing I would revert to the DTE port hit it with AT-X commands wipe out everything and start from scratch. Program a few key users and see if the trouble is still there. Problems fixed enjoy your Friday night and/or Saturday morning. Problems still there, reload your original config. go home.
Avaya calls good luck at least you know what you're upto for the next while.

Let us know how it goes, I too am curious.

I was reading that there is an AT-X4 command, I can't remember where I saw it and what it was used for. Any of you guys know? Thanks.
 
I can almost guarantee that the config is corrupt. We have this at a location that has been upgraded from 1.3-1.4-2.0-2.1 with all equipment replaced. Final verdict was corrupt file. Erase and start over or export specific lists such as users and short codes, but the problem might be within those fields. Good luck.
 
put a default config in and make mergable changes and watch if the unit reboots.
 
Well, it turns out that the problem has to do with the large number of Account Codes this customer has (3000+). That is the Avaya explaination, atleast. I have yet to receive the fix for it - hopefully by the end of this week it will be in place.

I would have rebuilt the config, but the prospect of entering the 3000 account codes again was not that appealing.

 
You could check your config within the Wizard, it will do a proper check on your config.
For your 3000 accountcodes, you can make a .CSV textfile wich can be imported and merged with current config.
It should be like this:
AC_AccountCode,AC_Cli,AC_RecordInbound,AC_RecordOutbound,AC_TimeProfile
1234,102582581,None,None,

You can create it with Excel and import it as a text file within Manager.

However, keep in mind that the IP Office has limited memory for the config, it should not grow to big. I've seen a customer with well over 3000 PhoneBook entries suffering the same problems as you have.
It did work on the 1.3 version but not on 2.1 because 2.1 has far more facilities thus using more memory as the 1.3 version.
 
3000 individual account codes is almost 50% of the available configuration memory on most control units.

A useful little tweak might be that account codes entered in the Manager can include wildcards, ie. ? for a single character and * for anything.

For example (and I paraphrase the Manager help):

- 123??? will match any 6 digit account code beginning 123.

- 456* will match any account code begining with *.

May help remove a lot of repetition from the accounts codes that need to be entered.
 
The config checks out in the Wiz. OK...

As far as importing the files via Wiz. - client is only using Account Code - just one field, no names, CID's, etc. My only concern is that if they import the remaining 1000 or so entries, the 3000 already entered will be wiped out. I guess that's why we save config files. Good advice all around. I still hope Avaya has a patch for me soon that will prevent the reboot.
 
Hi Orlando21,

Reference your question on the AT-X4 command: it is used following the AT-X3 command ONLY for IP403 when erasing configuration from flash memory.

Alex
 
I've had something very similar to this on my IPO406. It turned out to be something in the config. In fallback extension / group in the Incomming call route had suprious characters in it (eg. Instead of IncomingOverflo it would have IncomingOverfloü (notice the extra character at the end)).

By deleting the Fallback group from the Incomming call route, resolved the problems.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top