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

9.1.5.0 Lost all Hunt Groups in Config 4

Status
Not open for further replies.

Signo

IS-IT--Management
Oct 5, 2006
141
US
Has anyone ever had all the hunt groups disappear in programming?

I had a client say they could not receive any calls but could make calls. I go check it out and all the hunt groups were gone, the system showed 0 hunt groups.

So naturally my incoming call routes pointed to a non existent group since they were gone . The only thing missing was the hunt groups all other programming was intact. I just uploaded a config from the last time I was on site and all was back to normal. System has embedded voicemail and Group mailboxes still had greetings and no messages were lost once I put the old config back in.

I checked the audit trail and I was the last user logged in and that was in April of 2016. The audit trail shows a warm reboot the night before the trouble started. I would venture to guess that it lost something in the config when it had its random reboot.

I took the system up to 9.1.8.0, but I have never seen this and was wondering what you guys think.
 
Seen it when LAN1 is set to DHCP client, don't do that, set it static and/or use LAN2/WAN :)

 
amriddle01,

The system is in fact set to dhcp on lan1. The system is in a church and the "IT" guy was supposed to setup a static reservation for it months ago. I noticed today when I connected the IP was way up in the range for the network. We actually talked about him fixing it today. I guess it’s a real priority now!! lol

I would have never guessed that having lan1 set to dhcp would cause that kind of problem. It is also the only system I have that is not on a static IP, guess that’s why I have never seen it.

You sir are a wealth of knowledge.

Thank you.
 
Avaya put it in as an Easter egg to sort out the wheat from the chaff.

Did you know?
If they name the hurricane after you, you have to pay for the damage.
 
There is some hidden correlation between LAN1's IP and huntgroups for SCN purposes I think, Avaya make no reference to this and have never admitted as much. But I've seen this and them still showing, but greyed out (so they can't be edited) with an IP next to the group name exactly as in an SCN, even when SCN is never and was never used :)

 
I've seen it too.

Did you know?
If they name the hurricane after you, you have to pay for the damage.
 
When the hung groups were missing I was looking at SSA and the calls didnt show up at all even though I could see them alerting on the front panel leds.

Then I noticed I had a some service alarms, so I looked and it had an alarm that said the system was trying to use a multi site license that it didnt have. The system is stand alone, so that made no sense, at first I though it got hacked. Then I noticed every incoming call made the multi site alarm count tick up one.

So amriddle01 when there were no hunt groups it was routing over and scn line that didnt exist, there is your direct corolation between the two.

Thanks guys
 
I have seen this happen as well. I did some testing on my test system and was able to replicate it(I made a post about it a while back). If you are set to DHCP and then the IP address of your control unit changes you will lose all your groups(actually they are not "lost" but instead associated with a nonexistent SCN site associated with the old IP address). This happens both in basic and standard and is far worse in basic since there is no way to re-add the groups(seems odd to me this would happen in basic but who uses that crap?). If you were to then reserve the original IP and have it DHCP back to that IP the groups would come back(be associated with your control unit again and be editable/useable). As stated this some kind of undocumented SCN issue/"feature". This will not happen with a static IP or if you reserve the IP address in the DHCP pool.
 
I've had this happen many times with different systems on 9.1.7, I'll try the non DHCP route.

Thanks for the advice.
 
It's happened since R5 or so, it isn't going to go away any time soon, so best to avoid it :)

 
If you absolutely must use DHCP client , then use LAN2/WAN, it's fine then :)

 
That is the truly odd part is that WAN/LAN2 is not effected by it lol
 
I got a call from the customer first thing this morning that the system was not working, I tested before I left last night so I knew that was not true. I figured maybe it lost the groups again since I didnt know about the fix until after I left there yesterday

Turns out park was not working. I had it set to one button park and retreive, and the "upgrade" to 9.1.8.0 has the nasty bit of poor programing that makes parking a two button press procedure that you cant change. I read about it here and totally forgot about the bug.

I ended up rolling the system back to 9.1.6.0 to get park retreive back to normal and setting a staic IP and hopeully I am done with it now. I feel pretty good since you guys have seen this problem before and had a fix to suggest.

My company went MetaSwitch a few months back and I have been gearing up to do hosted off of it, and I admit I have not been keeping up with IPO like I should. You guys really saved me on this one.

Thanks everyone.

 
Personally I have not seen this but that will be because we never leave an IPO dect as a DHCP client.

It has never been a sensible option because if it's IP address can change things like Soft-console etc can no-longer connect, it also makes our remote access setup considerably harder if we dont know the system IP address to start with


Do things on the cheap & it will cost you dear
 
That's what I do to them when they ask us to fix it, I use their head on the wall :)

 
It was left dhcp because the client wanted to static reservation instead of us putting the static in the unit. The real issue was the fact that after 6 months he never put the reservation in the dhcp server. I trusted he would do his job. We have never left a system on dhcp without a static reservation on purpose. I normally just put the static in, but they insisted on a reservation on the server side.

We were not trying to be cheap in any way. I know I should not trust people to do what they say they are going to do without going back and verifying. So it is my fault for trusting the IT guy. I learned from the experience and will not allow it to happen again.
 
my experience has always been that if you leave a customer with a "working" system & instructions that they must do XYZ to complete the setup they invariably will see the fact that the system is working as an indication that thy can completely ignore you.

In this case the safe way would have been to let dhcp get an ip address & then configure the IPO to use that address a a fixed address, then if the cust "forgets" to add it to their scope the worst it can do is disable the networking on a users PC or the IPO when they end up with a duplicate address on the network

As they have failed to follow your instructions at the time of install I would now say you should charge then for the remedial action


Do things on the cheap & it will cost you dear
 
Sad thing is, DHCP is a very basic thing and should work as programmed.
Rather then questioning why IP Office has a long standing bug where it looses hunt groups we have become accustomed to working around the bugs and question why it wasn't set as static, almost as if it's the IT guy or Interconnects fault.
Imagine if we used the same argument for all the PC's in an organization that had DHCP.

Either way, glad to learn another way to work around a problem that will likely never get fixed.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top