key deleted on phone, phantom voicemail number not working

[comn8u]

We have a phantom voicemail number not working since a phone was changed out from a 48 key to a 9 key phone.  We have 5 controllers that are clustered, which the phantom extension can be seen on except for the controller that the phone was changed out on.

Any idea of where to start to look for a solution before contacting Mitel support.  I'm hoping some Mitel guru on here can share some good tips.

Thanks

[ralph]

Here's what I suspect happened:
Below the latest release (5.0) if you wanted a VM box only line what the tech would do is create a phantom phone will a whole bunch of keys.  He may even add a PKM for more keys.  This phone is expected to never be used as a real station.

Then, when you need a phantom line that rolls immediately to voice mail, he would program that number on that phantom phone and then system reroute it to voice mail.

I would bet what happened here is that you deleted all the keys programmed on the phone above key 9.   Now when you call the number you get an "invalid".

If it's only one number that isn't working, I'd create a hunt group with that number and forward it to VM via system rerouting.  That should solve your problem.   If it's more than one number you have a choice:  re-create a new phantom phone and put all the numbers on as keys or create all of them as hunt groups.  -There's a limited amount of hunt groups you can create this way.  That's why we use phantom phones with a lot of keys.

Ralph

[comn8u]

I'm looking into to this right now.  Ralph, thanks for your reply.  I also got a lot of help from another post of yours:
http://mitelforums.com/forum/index.php?topic=1732.0

Out of 5 controllers, after running the locate command, 4 out of 5 came back with this:
- LOCATE NUMBER 6650
- LOCATE FEATURE EXTENSION 6650
The number refers to a remoate directory number.
Remote DN to CEID 3, routing digits 1113

The controller that the phone was attached to, came back with this after running the command:
- LOCATE NUMBER 6650
- LOCATE FEATURE EXTENSION 6650
The number is not in use.
LOCATE: Invalid or nonexistent extension number or id number.

On the same controller with the problem, I went to ARS Digits Dialed, and 1113 was not displaying.  If you try to manually add 1113 to Digits Dialed, it says "The digits already exist." after hitting submit.  So, something is definitely messed up.


Do you think a restore of the controller would fix the issue?  Also, this extension is connected to our external phantom mailbox number.  People call from home to xxx-xxx-6650.  So, we are not even using it internally, but it still needs to know where to go.  We've already got a button for internal voicemail, which is setup as a CDE Speedcall to number #69999, which is separate from the external phantom number 6650 (that is not working).

The vendor is telling us that he is going to have to call Mitel on Monday for the issue, because he can't fix it.  Do you think this is true? 

So, you are saying that a hunt group setup would fix this issue?

Thanks,

[comn8u]

When you were referring to, "This phone is expected to never be used as a real station.".  Is it that we need to make sure that this is not on a live phone that someone uses?  Because right now, the phone that caused this issue was at our front desk(which also has the main line on it).  Just want to know best practices.

Also, the phone was a 5340.  The extension was programmed on button 41.  It wasn't needed anymore, so the facility decided to have the extension moved to another room and a 5304 phone.  So, I think you are absolutely correct on how it happened (with above 9 keys). 

[ralph]

You didn't say what version of software you are running or if you're using OPSMan.

If you're running 4.0 with the SDS database or 4.1 or greater you may simply need to resync your nodes.
If you're using resiliency then you're probably pretty screwed up.

Under maintenance, look at your SDS logs and see how logs are there.   My bet is you have a lot.

You may be able to resolve this just by putting the key back on a phone somewhere.   Set it not to ring and then forward it to VM.

Ralph

[comn8u]

Well, under System Feature Settings --> System Options, "System Data Synchronization" is enabled.  We are running 5 controllers with 4.1 SP1.  Each controller is clustered.  There is a little yellow/green arrow icon that says SDS Share at the top left.  I don't see where the SDS logs are.  Under Software --> Errors, I see a lot of CAVH_WEBSET errors since yesterday, but not sure what that is.

CAVH_WEBSET error reads (not sure if it's related):
updateTuple()->Failed to update Hosted User Service: Need to rollback MLSKA update  The value entered for the following field already exists as a key : 'Service Alias Primary Host Network Element Guid Ref"

Where do I look for resyncing?  I would just like to know where this is at.

Also, it may be an issue.  When the vendor was troubleshooting, he ended up deleting the extension that the key was on.  He discovered that he couldn't delete the extension in the Remote Directory.  I was thinking the same thing, because even though you change it to a 9 key, I thought I remember the values of the buttons still being there if you change the it back to the 48 key (keys 10-48).  I could be wrong, but I thought I saw that before.

I appreciate your help on this...

[ralph]

I'm doing this from memory so bear with me if I don't have it right.

The SDS logs are under alarms.

To resync, you'll have to go to the network elements forms.   If I remember correctly  the option to resync is there.

updateTuple()->Failed to update Hosted User Service: Need to rollback MLSKA update  The value entered for the following field already exists as a key : 'Service Alias Primary Host Network Element Guid Ref"

I haven't see that log before.  It may be related but I still think the fix is to do a resync.


Ralph

[comn8u]

I talked to the vendor about re-syncing and he said that it would screw things up even more.  He said that there are no syncronization issues.  He also said that the phantom number 6650 exists behind the scenes and that he would have to consult with Mitel to fix the database.

The phone and extension is back up and running, but I didn't get an explanation yet on how it was fixed.  He said that every extension must exist somewhere.  If it is not a hunt group, email port, ring group, or ACD path, then it must exist as a single line extension.  And the only way to create a single line extension, he said, is to tie it to a phone.  He believes that the proper way of setting up this phantom number, 6650, is to tie it to a phone.  The question I have is, if this phone was unplugged or blew up, for some reason, the phantom line would be affected.

Now, when I do a trace on 6650, it's coming back as a "Non Prime Broadcast Group", so it changed from the original setting of "The number refers to a remote directory number".  He said that Mitel had to dial in with Putty to fix the issue.  I still need an explanation on how they fixed it though, so I understand for future reference.  Can you make anything of this?

Once again, thanks Ralph for all your help on this.

[ralph]

The phone and extension is back up and running, but I didn't get an explanation yet on how it was fixed.  He said that every extension must exist somewhere.  If it is not a hunt group, email port, ring group, or ACD path, then it must exist as a single line extension.  And the only way to create a single line extension, he said, is to tie it to a phone.  He believes that the proper way of setting up this phantom number, 6650, is to tie it to a phone.

Yes.  His is correct.  That's how it's done.   I'm still thinking you may need to re-sync but I'm not the one with hands on do I defer to your tech.

Now, when I do a trace on 6650, it's coming back as a "Non Prime Broadcast Group",

That's just telling you that it's programmed as a key on a phone.

He said that Mitel had to dial in with Putty to fix the issue.

That suggest to me that the database was screwed up so Mitel had to get in at a low level and strip it out of the remote directory database before your tech could do what he needed to do.   I believe the original issue was that you changed a phone from a model with more buttons than the one you replaced it with.   The system will remove any keys above key X.  The problem occurred because of the way resiliency works.  It removed the keys locally but not on the resilient controller.  Creating the database error.    The way to not have this happen again is to remove resiliency for that device before changing the phone model.   Even then you should remove all keys above key X before changing the phone model.

Ralph
West Michigan Mitel Dealers