IPoffice Change IP address and VoiceMail

[pgordemer]

We have an older IP 406 in our Main office and 3 IPOffice units running 3.2. This has been running OK for quite awhile. (save the occasional VoiceMail reboots for sanity).

We changed the IP address of 2 of the units, and updated the VOIP IP address in all the units. We are communicating correctly, SCN seems to be working fine, but for 1 office, if the call is not answered and it bounces back to Voicemail, you get bounced to your own voicemail. Its as if the VoiceMail server isn't seeing the new Ipoffice unit at the IP. I can ping all the units and they can all see each other.

Any thoughts on where to look.

 

[pgordemer]

What makes this more challenging is the current running install is 3.1.5378. It was a special build (have no idea why) and I don't have the distribution for it. (Keep in mind this is an inherited system). The machine with this manager on it is the Voicemail computer in the HQ location.

Can the Manager programs for that version, just be copied out onto my laptop, or are their dependency/dlls that have to be registered.

I am hoping it can be as simple as connecting to the unit directly, use manager to say erase config, change ip of laptop to be back in the range of 192.168.43.x, use manager to send original configuration.

 

[pgordemer]

Getting closer.....

I deleted 4 extensions, saved the config, rebooted. Recreated the 4 extensions and used different Box names. This time it DID create the VM boxes and SCN shows the users. I am able to get it to work.

But here is the rub, if I make any change to the extensions (change name, or anything on that extension), then it stops working for that user.

 

[aarenot]

If you are going to keep any of the units on 3.1.5378 then you should move them all to 3.1.5378. You said you have 3 units on 3.2, so I would suggest you bring them all to the same release. The IPO is not really meant to be running in an SCN with units on different releases.

Also, having more than one release means you must have more than one release manager to manage the units. If you do not have more than one release of manager installed, and being used then it lends itself to a probability that the 3.1 unit has been managed with the 3.2 manager. Even if you do have both releases of manager installed somewhere on different PC's on your network the probability that someone forgot, and used the 3.2 to manage the 3.1.5378 system is high.
If the 3.1.5378 system has been managed with the 3.2 manager then I suggest that you default the 3.1.5378 system, rebuild the CFG from scratch, and then upgrade, or downgrade all of the units to be on the same release as they should be. Running 3.1.5378, and 3.2 on the same SCN is only something that should be done on a temporary basis while you migrate through the process of changing the units over, and is not a long term solution.
The issues when you make changes in my opinion lends itself to the system CFG being corrupt, and probably from mis-management with mis-matched manager software.
Finally, I have come in to work on systems that have been having weird issues so many time that I can not even remember them all. Simply by defaulting the switch, downgrading it to the original release it came with, and then re-upgrading it has fixed a myriad of systems from having the weird issues. Improper upgrades can corrupt the system, and or the CFG causing unexplained issues such as this. Rebuilding one system CFG is not that hard especially if you have the old CFG to load up on a laptop to look at to recreate it with. Do not however just load the old CFG on the system after you re-upgrade it as that will just bring the problem along with you back to the new scenario if the CFG is corrupt.

I realize this is not what you want to hear, but it has worked for me when coming in after someone else has been managing the IPO, and it is not working properly. I realize that some may not have had issues like this with the systems they have implemented, and neither have I. I have had them with other peoples systems though. I believe that many do not follow the proper procedures when upgrading the IPO, and corrupt the system, and the CFG by doing so.

It is best not to assume that the IPO has been upgraded competently when issues arise that are not inherent to systems which have been upgraded properly. Issues of this sort from my experience with inability to make changes to the mismatched release unit on an SCN without errors, inability of only that same mismatched system to communicate properly on the SCN, and a programming change occurrence having been the catalyst for the failure events all leads to corruption as the diagnosis. What release of manager was used to change the IP on the system having errors? If you can not certify that the change was made with the

3.1.5378 manager to the 3.1.5378 unit then the next step is obviously downgrade, and re-upgrade the system, and default it to start from scratch. You could default, and DTE the system, but I have never messed one up bad enough to have had to DTE one yet, so I am not the best guy to instruct you on that. I am well over 100 units serviced, and never had a DTE cable out yet, and hoping to make it to 200, no 300.