Users losing local VMPK programming


#1

We experienced a strange issue this morning. We updated all SIP extensions in Zero Config after a minor change to the default model template. I don’t believe the nature of the change to be pertinent, but it was to add a couple of pcodes to set up distinctive rings for calls coming in a certain inbound route. None of the templates or policies (model, global, etc.) define a single VMPK (other than extension board ones) and when we updated all extensions en masse, anyone who had locally programmed VMPKs had them overwritten to default settings.

The management team at the company was really upset, understandably, and we can’t explain why it happened or, therefore, prevent it from happening again. We have tested and have been unable to repeat the issue. Not wanting to impact the whole company (50 extensions/handsets) we have been pushing updates to one or two phones and the issue hasn’t occurred again.

Has anyone else run into this? Is there a setting somewhere we can employ to prevent local programming (VMPKs in particular) from being wiped by a model template or global policy? TIA!


#2

That is the exact opposite of normal behavior. Typically that would only occur with a factory reset or if the settings in question were told to change.

If no setting changes are in place for that phones VPKs in zero config it shouldn’t have happened. I’d look there again for the phone(s) in question or inquire of anyone going, “just factory reset it, it’ll regrab everything” not realizing the VPKs were not set that way.


#3

Thanks. We never did figure out what happened. Today, the user with the lowest tolerance for this (very heavy landline user, lots and lots of speed dials) lost 25% of his VMPKs. He has 4 pages of them and went to page 4 today and all but one entry was missing. Really wish we knew what caused these random losses of programming.

EDIT: 4 Pages of speed dial entries as VMPKs.


#4

if I remember well somewhere on the warnings of GS there was written that a “blank” key overwrites the key set in the phone, so it is worth flagging zero side config only the keys you really want to send to the phone to avoid these problems, a tip -> when you make changes never do mass provisioning, but test one at least, then do the others.


#5

Thank you. That gave me something to look into. The only zero config settings applied to this individual’s phone are the Global Policy and the default model template. The only programmable keys defined in either are for extension boards, and this user doesn’t have an extension board attached. I dunno!


#6

attention to priorities in zero config between custom templates, global settings, etc…