Polycom phones used to be soo easy to update (and thus purchase), now they are not.
All your beautiful markup parameters have all been replaced by different non-backwards compatible ones, and the answer seems to be "run your files through our configuration program, don't try to do them manually" .... NOPE
I can scarcely describe the gravity and frustrating overburden that this situation now entails.
1) Thousands of phones that now can't be easily updated.
2) No easy way to provision new fleets without massive programming re-writes.
Our whole business model is now in tatters.
I'm looking at HUNDREDS OF HOUR OF WORK, PERHAPS MORE reprovisioning the fleet, and re-designing our configuration software.
I had already prior advised you of certain pre-requisites in regards of provisioning a phone.
I am unaware of the marketing reference and therefore cannot comment on this statement.
Going back to the SIP 3.1 admin guide the page 3 - 15 (and others) mentions how to provision a phone. It explains the example naming and suggest a name of phone[MACaddress].cfg.
Throughout the document it explains that changes are saved to local flash and backed up to <Ethernetaddress>-phone.cfg on the boot server.
The SIP 3.2 Admin Guide specifically makes users aware (Page 3 - 17):
Do not use [MACaddress]-phone.cfg as the per-phone filename. This filename is used by the phone itself to store user preferences (overrides).
UCS 3.3.0 in addition introduced a new file called [MACaddress]-weg.cfg and is used for any overwrite settings added via the web interface.
Again above files is a standard used since the very beginning and throughout the further development of the software and the change from SIP to UCS additional enhancements where made.
Since UCS 3.3.0 the phone no longer requires to load the sip.cfg and the phone1.cfg.
This improves the bootup time of the phones immensely and also ensure that customers no longer need to keep track of different revisions of the above files as they now simply can use individual parameters to provision the phones.
If they wish not to provision phone from a server they can now simply make changes via the web interface or the phone gui without the need of having a server.
The -phone.cfg and -web.cfg files are relevant for troubleshooting as the priority of parameters is as follows (lowest to highest).
Provisioning server files => Web Interface changes => Phone GUI changes
This structure has been used, to my personal knowledge, since day one.
In order to enable users to simply upgrade from SIP 3.2.x or older to UCS 3.3.0 a disclaimer, that must be acknowledged before being able to download the software, is shown and highlights the changes in the attached hyperlinks.
These clearly outline the reason for these changes and provide a tool called cfcUtility.
The next major step was the introduction of UCS 4.0.0 which in addition required a new Updater process to upgrade to the latest phone software version.
Any configuration files in the correct UCS 3.3.0 format or later will simply work. Using pre UCS 3.3.0 Parameter will show an error message and need to be manually corrected.
For simplicity our Phones support substitution keeping the maintenance and amount of individual configuration files to a minimum.
In addition a Polycom reseller always should be consulted for support related incidents and End Users always have the possibility to work with a Polycom sales engineer or purchase Polycom professional services.
I kindly ask you again to ensure you are consulting the relevant disclaimers, matching Admin guides and in addition software release notes to avoid disappointment and be aware of the caveats.
Polycom Global Services
I tried to delete this post but am prevented.
I updated to 3.3.5 with no issue, same config files and everything.
Reports made to the incompatibilites seem to be exagerated, I read them and assumed the worts but my test proves that it was A-ok.
Perhaps the 4.0 firmware is borked as you say however,
Also, not letting me edit the main post is irritating.
I was goign to ammend it to notify people that 3.3.X is not all as drastic as some are claiming, oh well!