Provisioning setting stuck? Locked phones

[giwm]

I was setting up a T40P yesterday with a custom provisioning template so that it had a number of specific features - namely that the phone lock was enabled. I had to add phone_setting.phone_lock.enable = 1 to enable this. Got it working, no problem.

However, this morning I reprovisioned 33 T40P phones with a new custom template (based off SP1) - and every one of them had lock enabled. I switched back to my non-SP1 custom template that they'd been running off of and the lock enabled was still true. So I explicitly added phone_setting.phone_lock.enable = 0 to both templates in turn... no change.

I then navigated here: http://##Redacted##/provisioning/w9454nvv4g/y000000000054.cfg and it's the T40P I was working on yesterday. Is that really correct? Also... where is that file actually located, as I can't seem to navigate to it on the server, only through the URL.

I ended up manually turning off the phone lock on each and every unit.

Any idea what may be happening?

 

[giwm]

I added a new phone with the same provisioning template I'd been trying to use for reprovisioning the 33 T40P phones... and y000000000054.cfg updated.

Is there perhaps a bug in 15.5 SP1 that the .cfg files are not updating properly when reprovisioning an existing phone? I'll keep testing, but curious if anyone else has ran into this? I'm using a Windows box.

 

[giwm]

After adding the new phone, the .cfg files are updating appropriately and I can reprovision now, but pre-programmed line keys aren't populating.

 

[NickD_3CX]

Read the following article about how to create custom templates properly, and specifically the part where it says "Yealink-Specific changes"

https://www.3cx.com/docs/custom-ip-phone-templates/

Long story short, if you don't have unique y00000000000xx.cfg filenames across all templates, you will have such problems.

 

[giwm]

Wow... I don't know how I've been operating for over a year from V14 on through without running into this until now. And how I missed that. :|

So if I change those templates (say in Notepad++ cause it's easier) and save them, what will force the generation of the new y#000000##.cfg files?

I ask because I made the changes and I'm not seeing it populate using the url (nor is the %%mac%%.cfg file).

 

[NickD_3CX]

So if I change those templates (say in Notepad++ cause it's easier) and save them, what will force the generation of the new y#000000##.cfg files?

Correct, just make sure that you change all references to the y00000000xx.cfg files in the templates and more importantly, if you have multiple custom templates, in the first one have the files aas y100000000000xx.cfg, in the second one y20000000000xx.cfg, etc....

 

[giwm]

Eureka! Now I know what the new regenerate button is for. Regenerates those y##00000##.cfg files.

 

[giwm]

Eureka! Now I know what the new regenerate button is for. Regenerates those y##00000##.cfg files.

Oh... crap. Apparently that killed server to all my phones. :|

 

[giwm]

Actually it blacklisted all my phone IPs

 

[NickD_3CX]

This action in itself does not affect the blacklisting of devices, so probably something else triggered that.

If you are using a V14, after changing the templates though Notepad++, you must restart the services to be sure.
Also, in order to make sure that the right files have been regenerated, for each extension you have the template on add a BLF, press Apply, remove the BLF, the press Apply again.

For V15, if you make changes to templates from the Management Console template editor, the above is not required.

 

[giwm]

Well... it doesn't blacklist them directly. But it apparently resets the phone password with out any warning or confirmation. So they fail too many auths and get blacklisted. I found another forum post of someone who had the same issue. REALLY need a warning on that button.

 

[giwm]

Yeah... changing the template in the Console on 15.5 SP1 did not generate those config files.

 

[NickD_3CX]

Yeah... changing the template in the Console on 15.5 SP1 did not generate those config files.

Starting from V15, these files are not generated and written to the disk, they are generated on the fly upon request, so you can't easily see their content.

If you do everything as per the guide I sent earlier you should be OK. when provisioning and not getting unexpected behavior after making changes.

 

[giwm]

Hmm... I thought I should still see them when navigating to the URL. Regardless, everything seems to back up and running now. Backups saved me. Thanks!