DST problems on 6.1

Unanswered Question
Mar 9th, 2009

You guessed it. The time on the phones is wrong!

Im set for NTP reference to hit my Domain Controller, which was patched and has the proper time on it. However the phones rae still an hour behind.

I have reset the date/time group 3 times now with no luck.

Help

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Same problem here on 6.0.

7970 phones show the correct time, but we only have two of those. All the rest of our phones are 7940/7960 phones and they are all displaying the time one hour behind after DST went into effect this weekend. All of the device pools are using CMLocal, and CMLocal is configured properly with an accurate NTP reference. Even the server shows the correct date, time, and timezone when I do "show status" from an SSH console.

I opened up a TAC case. Waiting to hear back.

cplatt01 Mon, 03/09/2009 - 04:38

Same issue here, and I applied the latest firmware to my phones as well as reset NTP.

Anonymous (not verified) Mon, 03/09/2009 - 04:47

Nice.

I even set up a unique device pool and date/time group and cant get it to work either.

Is there a patch for the new DST times that need to be applied?

Here is the response I received from TAC:

This issue has been analyzed, root cause has been identified and defect is

opened :

"CSCsy25150: CUCM timezone DST date corner case"

This issue has been observed with following CUCM versions :

5.0(X),5.1(X),6.0(X),6.1(X),7.0(X)

and following IP Phone models seem to be effected:

7905, 7910, 7912, 7920, 7921, 7935, 7936, 7937, 7940, 7960

While waiting for the fix to be available, you need to apply following

workaround :

1. From CCMADMIN go to > System > Date / Time Group

2. Create new Date/Time group, name it 'DST-Workaround'

3. Configure a Timezone which is 1 hour ahead of your current timezone.

4. From CCMADMIN go to > System > Device pool

5. Create a New Device pool, name it 'DST-Workaround'.

6. Assign to this device pool the Date/Time group created under step 1.

7. Assign the new device pool to the IP Phones that are displaying the

incorrect time.

8. Restart the CCM service on all nodes.

Development is currently working on a patch and we expect it to be available

later this week.

By the way, I have quite a large number of phones in quite a few device pools. It has actually been easier just to create the new date/time group and re-assign all of my device pools to the temporary date/time group and reset devices.

Anonymous (not verified) Mon, 03/09/2009 - 05:29

nice.

Yeah I just realized it was only my 7960's that are affected. All the 7962's are cooking with gas.

Thanks.

cplatt01 Mon, 03/09/2009 - 06:59

Agreed...that is what I did. I can't believe that this happened...surprised by Cisco...

Lucas Phelps Mon, 03/09/2009 - 08:01

Also surprised by Cisco's slip on this one. Seems like a pretty largly affected audience.

This is affecting all of my 7940 devices, 7941's are working great.

-Lucas

priedman1 Mon, 03/09/2009 - 08:04

Hi everyone,

I just got this from TAC too...

"...There are a few options for this issue:

1) Do nothing. The time on these phone models will be wrong the rest of this week, and will then correct themselves on Sunday Mar 15.

Important notes :

1. In case the system is not patched with the fix for this defect before 03/15/2009 and above workaround has been implemented, the device pools assigned to these phones need to be manually changed back to the original device pools on that day (03/15/2009).

2. In case the system is patched with the fix for this defect before 03/15/2009 and above workaround has been implemented, the device pools need to be manually"

HTH

Pete

Lucas Phelps Mon, 03/09/2009 - 08:11

What affect does restarting the CCM service have on a live production network?

Also, do I need to create a new device pool for each of my offices? Or if I throw all of my devices into one device pool..is it going to restrict calling from one office to another?

Michael Owuor Mon, 03/09/2009 - 08:24

Restarting the CCM service will be disruptive. Calls will get dropped for the duration of the restart.

If you put everything into one device pool, there might be other unintended consequences. The suggested workaround of changing the Date/Time Group might be a good one if you want to minimize changes. That way you can easily revert to your original configuration once the dust settles.

Hopefully testing on the fix will be completed shortly and the fix posted.

Regards,

Michael.

Lucas Phelps Mon, 03/09/2009 - 08:41

Mowour,

Thanks for the advice on the easier workaround. However, if we have some devices (7940's) that are affected, and some that are not (7941's) then changing the date/time group is probably not going to work..right?

metuzuner Mon, 03/09/2009 - 08:57

Kcoe, create a date/time group and device pools for each location. Then, use a query in BAT to make changes to only 10/12/35/36/40/60 (first generation IP phones). That way you can keep your 41s untouched.

Michael Owuor Mon, 03/09/2009 - 09:00

Hi Lucas,

You are right. For clarification, you only want to change the date and time for just the 1st and 2nd generation phones. If you create a date/Time Group and Device pool, assign only the affected phones to the new Device Pool.

Regards,

Michael.

metuzuner Mon, 03/09/2009 - 08:37

We just applied the temp workaround (creating new date/time group and device pools). You do NOT need to restart the CCM services (at least on 6.1(2); just restart (not reset) the phones after applying the device pool changes using BAT.

nbernhardt Mon, 03/09/2009 - 08:08

Has anyone noticed if the ATA186's were effected? I have a client who's overhead paging system is driven by an ATA connection and their over-head ringing was active an hour longer than normal.

CHRIS CHARLEBOIS Mon, 03/09/2009 - 12:25

I don't know if the ATA186 is effected, but that doesn't matter. The ATA does not control the timing of incoming calls. I assume you are making that determination based on Time Schedules assigned to a partition and that, form my experiences, is effected. The quick fix for that is to specify a time zone that in one hour earlier in the Partition Configuration Page.

Lucas Phelps Mon, 03/09/2009 - 15:18

The patch file is available for all versions of CommManager/CallManager 5.x to 7.x.

The patch file is the same for all the versions. However, to make sure you get the correct one, go to:

1) Support

2) Download Software

3) Voice and Unified Communications Software

4) To access Voice Software downloads, click HERE.

5) Expand IP Telephony > Call Control > Cisco Unified Communications Manager (CallManager) > Choose your version.

6) Then select 'Unified Communications Manager/CallManager Utilities'

7) Then expand the '1.1' folder and you will find the 'UCM COP Files'. This is your emergency patch. Read the release notes and apply.

Note: Requires a restart of the CCM service (drops calls)

Actions

This Discussion