*** New Defect CSCsy25150 for DST

Unanswered Question
Mar 8th, 2009
User Badges:
  • Green, 3000 points or more

Hi guys,

A quick update for DST


Symptom:

Certain models of Cisco IP Phones (first generation) fail to get the time information from tCisco Unified Communications Manager server component. Cisco IP Phone Models: 7920, 7960,7940,7921,7910,7936,7937,7912



Conditions:

Any first generation IP Phone registered to Cisco Unified Communication Manager 5.1.X and above where Daylight Savings Time changes are in affect.


Workaround:

1. Using CUCM Admin go to: System---Date / Time Group

2. Create new Date / Time group with one hour extra of local time.

3. Go to System --- Device pool

4. Create a New Device pool and assign the (one hour extra Date time group) to this device pool.

5. Assign the new Device pool to and Cisco IP Phones that are displaying the incorrect time.


We are working for a patch more updates soon


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (15 ratings)
Loading.
Rob Huffman Mon, 03/09/2009 - 05:57
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Hey Gonz,


Thanks for taking the time out of your busy day to post this up! It is painful to see more DST problems creeping up, for sure. Especially on the "newest" CUCM Versions :(


Thanks for the "Heads-Up" buddy.


You Rock!


Huff

jasondrisc Mon, 03/09/2009 - 06:07
User Badges:

Hello,


I would also like to tag in and add a big thanks for this post. Unfortunate situation, but I was able to apply the workaround before the majority of our users got in the office. Saved the Help Desk and myself a TON of phone calls.


Regards,


Jason

luisrolocq Mon, 03/09/2009 - 12:21
User Badges:

Hi Jason

Do you mind leting me know how did you set up the time zone to have one hour ahead of regular time in the especified phones



alexjr Mon, 03/09/2009 - 06:39
User Badges:

I would also like to give a big thanks for the post. We noticed this problem this morning.

A customer would like to know when the patch is coming out. If you are able to post a date as soon as you know, I will greatly appreciate it. Thanks for your time again.

gonzalezel Mon, 03/09/2009 - 07:25
User Badges:

How would you add the extra local time. If I am in Central time would I just create a new time group in Eastern time to get that extra hour?

jasondrisc Mon, 03/09/2009 - 07:31
User Badges:

In our environment we have a lot of different device pools so what I did is changed the time zone reference directly in the date/time group and reset from there.


17roush Mon, 03/09/2009 - 07:40
User Badges:

That is what I had to do with select sites. But others I can not touch because they have a mixture of 7940s, 7941s, 7960s, and 7962s

astinus Mon, 03/09/2009 - 07:40
User Badges:
  • Bronze, 100 points or more

Is this related to a time of day partition routing issue as well? Have couple customers on 6.1.2 and 6.1.3 reporting that their time period/time schedule settings are off by an hour even though the server has the correct time.

jasondrisc Mon, 03/09/2009 - 08:00
User Badges:

I opened a TAC case after reading the initial thread in this conversation and this is the response I received:

The phones display wrong time because of this bug CSCsy25150 : 7960 and other phones incorrect time after DST on March 08,2009


Symptom:

----------

Certain models of Cisco IP Phones fail to get the time information from the Cisco Unified Communications Manager server component.

Cisco IP Phone Models: 7905, 7910, 7912, 7920, 7921, 7925, 7935, 7936,7937, 7940, 7960


Time of Day routing will also be an hour behind.

Conditions:

------------

Any first generation IP Phone registered to Cisco Unified Communication Manager 5.1.X and above where Daylight Savings Time changes are in affect.

-and/or-

Cisco Unified Communication Manager 5.1.X and above where Time of Day routing is being used



Workaround:

-------------

1. Using CUCM Admin go to: System---Date / Time Group

2. Create new Date / Time group with one hour extra of local time.

3. Go to System --- Device pool

4. Create a New Device pool and assign the (one hour extra Date time

group) to this device pool.

5. Assign the new Device pool to and Cisco IP Phones that are displaying

the incorrect time.


NOTE: This workaround action will need to be reversed on 03/15/2009 as the

CUCM time update will occur. Please plan to change your Device pools back

to

the original Date / Time group accordingly.


HTH

kelvin.blair Mon, 03/09/2009 - 08:25
User Badges:
  • Silver, 250 points or more

Please advise.. I need to know if this includes the Time of Day Routing also. I've had some of my customers report issues with ToD routing. One customer in particular have the later model phones and phones had correct time. However, the TOD routing was not turning off correctly.


Also, another customer who is running the 7960's also reported the issue.


Please advise if this issue also effects the ToD schedules.


thanks!

kelvin.blair Mon, 03/09/2009 - 08:34
User Badges:
  • Silver, 250 points or more

Oops Missed that one line item.

Michael Owuor Mon, 03/09/2009 - 08:34
User Badges:
  • Cisco Employee,

Hi Kelvin,


Time of Day routing is indeed also affected by this issue.


Regards,

Michael.

kelvin.blair Mon, 03/09/2009 - 08:37
User Badges:
  • Silver, 250 points or more

ok.. Now time to figure out how to just time the ToD schedules Time-Zone without affecting the phones. I have one customer where the time is correct on the phones but ToD is affected. In the earlier versions of CM, you could change the Time Zone by going to the time period. However,

I'm just now starting to look for it.. in 6.X and 7.X..


kelvin.blair Mon, 03/09/2009 - 08:39
User Badges:
  • Silver, 250 points or more

ok.. made my change. For those who have the same problem. Change the timezone under the partition where the schedule is placed. This will fix the TOD problem until it is patched.



hauchinango Mon, 03/09/2009 - 07:46
User Badges:

I am getting tired of this!!!! Everytime the clocks change I end up looking incompetent. Enough of this!

jhindmarsh Mon, 03/09/2009 - 10:44
User Badges:

I agree. I thought we were done with this the last time they changed the DST rules!

mhendren925 Mon, 03/09/2009 - 10:49
User Badges:

I went ahead and did the workaround since I have less than 20 7940/60 phones out of the 500 phones here. No problem implementing it.

Matthew Bryant Mon, 03/09/2009 - 10:56
User Badges:

We can send a man to the moon 40 years ago, but we can't make a phone that changes its time during DST...


I have a huge amount of affected phones and all my device pools are set up by building and floor, so it would take a lot of work to redo these phones...any idea on a time line for a patch?

metuzuner Mon, 03/09/2009 - 11:28
User Badges:

Has Cisco been slacking lately? This is really bad for the reputation.

ealves-crhc Mon, 03/09/2009 - 12:13
User Badges:

It would seem that if you are running UCM Express then this fix would be a snap but if you have 500 + phones in multiple pools as well as MGCP devices then your sunk so much for 1/2 Million in SmartNet contracts. Come on TAC this issue has been in effect since 2005 it's 2009 and next year the DST time change happens March 14. What surprises do you have in store for us next year?

mightyking Mon, 03/09/2009 - 14:39
User Badges:

Hello All,

My issue is not with the phones but with the Time Period Routing and Time Schedule. Would the new page take care of this issue as well?


Thanks,


MK

I'm in the same boat as you. There is too big a mix of devices to apply this workaround. I've been getting hammered today from the Help Desk and end users because of a stupid issue like DST that worked in older versions of CallManager. Thanks for nothing Cisco. Post a patch the natives are restless!

Lucas Phelps Mon, 03/09/2009 - 14:53
User Badges:

Agreed Matthew,


This workaround is a huge pain in the ass for us as well.


We've told our users to deal with the wrong time until the fix is released or until March 15th when it fixes itself (which will probably happen sooner than the fix is released).


luisrolocq Mon, 03/09/2009 - 12:08
User Badges:

Can you please let me know how do you manage the time to put one hour ahead? or do we need to use a time zone that has one hour ahead of local time. if that is the case wich one is it I don't seem to find a time zone that has only one hour ahead of me

luisrolocq Mon, 03/09/2009 - 12:41
User Badges:

Thanks for the replay

I have selected in the drop down menu the Atlantic Standard/Daylight Time - (GMT-4) but still no luck, all my 7940's and 60's are not updating after using the work around. I created the new group, i created the new device pool and assigned the affected phones to that poll for nothing.

Any sugestion to have this working till the patche is released

c.hulcher Mon, 03/09/2009 - 12:43
User Badges:

Did you reset the phones after assigning them to the new pool?


I reset my phones from CST/CDT to EST(Indiana) and after the reset the phones show the correct time.

ealves-crhc Mon, 03/09/2009 - 12:53
User Badges:

Sorry the info would have been predicated on what your UTC offset was to start with. I should have asked first.

ealves-crhc Mon, 03/09/2009 - 12:51
User Badges:

Have you reset the device pool?


As a test of this workaround we created a new pool IT-Test added selected test CP79x0 phones into the pool created new date time group called it No-EST set the time zone to Atlantic Standard/Daylight Time (GMT-04:00) Atlantic Time.


This fixed the x0 phones and broke the x1 phones


According to TAC engineer the x1 phones use UTC format x0 phones use UCM date/time group settings

luisrolocq Mon, 03/09/2009 - 15:01
User Badges:

Yes I have reset the new created Date/time group, the new device pool and the ip phones assigned to the new pool

still no luck

Just resuming to make sure i have followed the procedure correctly.


First, In call manager Administration page under system, Date time group we create a new Date time group whit a time zone 1 hour ahead of current time in my case i used Atlantic Standard/Daylight Time - (GMT-4:00)Atlantic

Second we create a new device pool and in the Roaming Sensitive Settings, under the option Date/Time group we use the new created Date/Time group

Third we go to the IP phones that have not updated and assign the new device pool, then reset the phone and acording to most of the users in this topyc, boom time gets updated. Well not in my case if i'm missing something i would really appreciate the help


loganseth Mon, 03/09/2009 - 12:55
User Badges:

Just wanted to extend my props to Gonzalo for the original posting. Like many others have posted, it saved us a bunch of time.


For us, we have 500 phones, mixed 40s, 60s, 70s, 41s, 61s, so while the conversion was not completely painless, this post helped us 'pull the band-aid off fast' rather than slowly over the course of the day.


So thank you, G, for the quick band-aid rip...now if only we could get Cisco to stop stabbing us in the leg...

Matthew Bryant Mon, 03/09/2009 - 13:22
User Badges:

I am in the same boat...


Plus, I am using those device pools to set up my paging zones for our IPCelerate paging server, so it would be chaos to try and make all those changes

Lucas Phelps Mon, 03/09/2009 - 15:16
User Badges:

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)

gonzalezel Mon, 03/09/2009 - 14:25
User Badges:

What am I looking for to see if replication is working correctly?

Rob Huffman Mon, 03/09/2009 - 16:17
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Thanks Gonz!!


Your support here is superb as always! +5 points for your always helpful nature.


Cheers!

Rob

olighec Mon, 03/09/2009 - 17:18
User Badges:

Just applied the patch and it worked perfectly. My job would sure be a lot more difficult without Netpro!

luisrolocq Mon, 03/09/2009 - 18:16
User Badges:

Trying to apply the patch and when using RTMT to make sure that Database replication is working properly I'm not sure where to check to validate this,can you please give me a hand so I can verify that Database replications is working?

I have checked the logs and found one error with a service that was not running but after restarting the service no more error logs.

George Thomas Mon, 03/09/2009 - 19:04
User Badges:
  • Blue, 1500 points or more

If you are using 6.1 or higher you can view the replication status in Cisco Unified Reporting.

metuzuner Tue, 03/10/2009 - 04:57
User Badges:

Hi luisrolocq,


Login to RTMT and select 'Service -> Database Summary' from the CallManager menu up top. In the bottom of that screen you'll see a table where all the nodes in your cluster are listed. If replication status shows "2" for each node then replication is good. Also see below:


0 (Not Started)-No subscribers exist or the Database Layer Monitor service is not running and has not been running since the subscriber was installed.

*


1 (Started)-Replication is currently being setup.

*


2 (Finished)-Replication setup is completed and working.

*


3 (Broken)-Replication failed during setup and is not working.

*


4-Replication is not setup correctly.



Have a nice one.

mightyking Tue, 03/10/2009 - 06:46
User Badges:

Hello All,

My issue is not the phones because the phones are all 7941, 7961 and 7971. The issue is with the Time Period Routing and Time Schedule. Will the patch take care of this issue as well?


Thanks,


MK

luisrolocq Tue, 03/10/2009 - 08:54
User Badges:

Thanks for your help, patch was a success and I'm up to speed again

Actions

This Discussion