We have been warned about bug CSCvo62469 and that it might cause the phones at our European offices to spring forward a week early this year.
The fix is to install ciscocm.CSCvo26979-CSCvo62469-Workaround_C0002-1.cop.sgn. The readme is here.
After installing the cop, I can see that TZData.csv has updated, but the readme doesn't mention whether we need to reset the phones. Does anyone know?
For the record, applying the .cop changed the "4" to "5" as indicated below:
# Looks better following patch: admin:file search tftp TzDataCSV.csv Brussels Searching path: /usr/local/cm/tftp/TzDataCSV.csv Searching file: /usr/local/cm/tftp/TzDataCSV.csv "TIMEZONE_EUROPE_BRUSSELS","Europe/Brussels","60","0/3/0/5,02:00:00:00","0/10/0/4,03:00:00:00","60","Europe/Brussels" # SQL result was good pre and post cop file: admin:run sql select dstdate from typetimezone where enum='27' dstdate =================== 0/3/0/5,02:00:00:00
Thanks in advance for any assistance.
Solved! Go to Solution.
I have a customer running 11.5(1)SU5 with the 8945 IP Phone, and we can get the time to change by powering off and on the phone after installation of the COP file to all servers in the cluster.
Just to clarify, you must physically remove the cable from the back of the phone - though shutting an interface or disabling PoE may have the same effect.
A full factory reset has not been necessary.
Alternatively, it may be worth while changing the Date Time Group of a single handset to see if this alters the time as well.