Hi can you please help, All my phones NOW show as an hour ahead of time. I'm running CCM4.0 Pub and Sub. Have Unity 4.0(5) in a UM enviroment. All the servers have the correct time, it's just the 7960/70 ip phones. I have tried to reset the devices but its not working.
Not the dreaded DST again! Can you tell us what method you used for the DST change. Did you do the manual workaround? Did you apply the DST Patches with OS changes? Did you use the SQL fix? Did you do the phone firmware upgrade for Java based phones like the 7970?
I'm also curious about the phone models you mentioned (7960/7970) as they should behave differently.
Let us know, so we can figure this out.
sounds more like CM DST Fix was not installed on the box, but a manual timezone change was made. If this is true, you should use the right timezone on the phones using (Date/Time Group)
OK I did not apply any patches to my CCM4.0(2a)cluster, because I didn't see any for that version and we were not going to upgrade to 4.1. I did run the patches for our Unity 4.0 Server and the 2003 patch. No firmware upgrade applied for my 7970/60 phones. Didn't do the SQL fix either. TAC after telling me that I didn't need a firmware upgrade, tells me yesterday that I needed one. I'm not sure about that at all. At rate, from within CCM I adusted my time zone to Central Time and that got my 300 users off of my back, until I come up with a better solution. We're planning an upgrade so I'm not sure I'll do anything. But thank you all.
Did you by any chance deselect the "Automatically adjust clock for daylight savings changes" back on March 11th, 2007 and not reselect on April 1st?
If you have the 7940/60 phones and didnt apply any patches. Try reselect the check above and manually changing the time back one hour. Then reset your phones.
I have a similar issue. CM's show correct time. I did a manual change and I have the older 7940/7960 models. I beleive all we need to do is to adjust the following.
For PST at -8:00 we need to switch that to -7:00 Arizona or Mountain time
For CST at -6:00 we need to switch that to -5:00 or Indiana or Eastern time zone
For EST at -5:00 we need to switch that to -4:00 or Atlantic or Canada time zone
Then reset the phones. This should turn the clock back on the IP phones one hour and will not affect the OS. I will be patching in a month or so and will need to change this back before October.
It appears that my Time Zone template is off in CallManager. I have a TAC case open but in the meantime I've just switched time zones to one that matches.
I was thinking the same thing, but if we (the ones with versions that don't have patches for them) leave them as they are, what's going to happen this fall when the time switches again, and next spring and forever after that....it's gonna be a manual switch every time DST rolls around.
I'm thinking about upgrading to at least 4.3 so I don't have to mess with it every time.
if you didn't apply any DST patches then that is the problem since the OS patch was
meant to change the time on the server (Windows time) and the CCM patch was meant to
change the TypeTimeZone table in SQL. The time of the phones is calculated with the
Windows time and the TypeTimeZone table. This SQL table has a field for the DST time.
There are some workaround for this:
A) Manual DB change:
1. Using SQL, enterprise manager, access the CCM database.
Find the database named "CCM03XX" that has the hand (like share hand) on it. Go into that
CCM Database's table "TypeTimeZone" and find the time zone(s) your phones use. For each
time zone you use, update the following fields:
"stddate" to "0/11/0/1,2:0:0:0"
"dstdate" to "0/3/0/2,2:0:0:0"
2. Restart the CCM service ("Cisco CallManager").
3. If you use an NTP service, restart it as well.
4. Check your phones, the time should be correct now.
NOTE: If you have CCM failover configured you'll need to reset the phones for the changes
to take affect, the best way to do it is by resetting them from the device pool.
B) Apply the appropiate standalone DST patch for your CCM version:
U.S. Daylight Savings Time Policy Changes Effective March 2007 - for Cisco CallManager
NOTE: Patch should only be applied to the PUB, since it only makes changes in the DB.
After you apply the patch you'll need to perform a cluster reboot.
C) Change the time on the CCM server one hour behind.
After the change you'll need to reset the phones.
I just got my ticket back from Cisco and here is what they wrote.
My Name is Manoj and will be assisting you with Service Request
XXXXXXXXX. I am sending this e-mail as an initial point of contact and
to give you information on how to contact me. Regarding the DST changes
you had mentioned that you did a manual time change on all call manager
servers. Here is a field notice that tells us to re-check the
"Automatically adjust clock for DST" box and manually set the server
clock to the current local time on each CallManager cluster node if you
had changed it manually for DST changes earlier.
I hope it helps. Please feel free to contact me if you have any questions.
We just did the change as per the Cisco link. We set the "Auto change for DST" box back to checked. As soon as we hit apply, it jumped the time forward an hour. We then manually changed the time back. This did not change on the phones until they were reset. The NTP server we are synching with has the correct time etc, and so I am hoping that it won't change the time based on time zones, but I don't think so.
On to planning for my patches to fix this issue. You all know how that procrastination goes!
We had the same issue here.. CCM v4.1(2) - I did the manual DST change via TZEDIT - same problem on the phones this morning, everything was an hour ahead. I went into the CCM and set the Date/Time Groups to one greater than they should have been. That fixes the time issue, but seriously, I'm not planning on messing with DST changes again.
Looking to upgrade to either CCM 4.3 or 5.1 - can't decide yet.
Thanks for posting back with your resolution! I wish everyone would take the time to do this, it really helps to know what does/doesn't work :)
5 points for this one!
Thanks for posting up this resolution in such a timely manner. This DST issue has been a real hassle, but having Cisco people like you to help us along has been a real bonus!
5 points from this end!