Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Daylight Savings Time Update
- Thread starter fizhon
- Start date
- Thread starter
- #4
no, that's just where they put this document. After reading the document though, you will find recommendations to upgrade anything not current to the latest 3.2 (February) which is not even out yet,
below is from the document
To ensure complete synchronization of the time on IP Office phones it is recommended that IP Office systems running Release 3.0
through 3.2 software be upgraded to the 3.2 February Maintenance Release when available at:
IP Office systems running Release 2.1/3.0DT or 4.0 software do not suffer from a phone time update problem.
below is from the document
To ensure complete synchronization of the time on IP Office phones it is recommended that IP Office systems running Release 3.0
through 3.2 software be upgraded to the 3.2 February Maintenance Release when available at:
IP Office systems running Release 2.1/3.0DT or 4.0 software do not suffer from a phone time update problem.
The notice from Avaya that "unspecified" phones "could" experience time update issues and that only the newly released 4.0 and the even newer 3.2.55 can resolve the issue is Avaya arriving very late to the issue at hand. Of course if your customer base is on 2.1 or the wildly popular 3.0DT then you can rest at ease by simply patching windows. And of course rebooting the computer.
Well o.k. So everyone patches windows after business hours so a reboot doesn't affect daily business. Thats not too bad and the O.T. will spend nicely. But having to visit each site to upgrade to 3.2.55 or to 4.0 is absurd!
Some of you will undoubtedly try it remotely but I am honestly not that brave. I am positive that at least a handful of the 403's and a 406 or two out there will have to be revived via DTE. No thank you. I'll read about it later and thank the telecom gods that I resisted temptation.
There are too many variables and failure points and client software upgrades to perform that keeps this lucky ducky from attempting a mass upgrade to accomodate DST.
So its off to the lab to see exactly what happens and to decide which method to employ.
Windows:
1. Win 2000 has no patch unless you are a microsoft super duper extended hotfix support customer. SP4 only. Ummm...probably nearly no one has this...
2. You can grab the patch for 2003 or XP sp2 then reboot. Likely after hours unless your customer can withstand the outage albeit briefly.
3. You can use the microsoft tool timezone.exe with no reboot. IBM says that there are problems using this tool so...
4. You can use the microsoft tool tzedit.exe with no reboot required and it works with 2003, xp and 2000.
""""Apply the tzedit.exe process to your systems:
Exit out of applications.
Run the executable tzedit.exe using Start > Run, provide the full path, for example: c:\Program Files\TZEdit\tzedit.exe
Your current time zone should be highlighted. Click the Edit button.
Set Start Day to Second Sunday, March.
Set Last Day to First Sunday, November.
Click OK.
Click Close.
You need to change your time zone twice using the Windows Date and Time Control Panel.
From the Start menu, click Settings > Control Panel and then click Date and Time.
Click the Time Zone tab.
Select a different time zone and click Apply.
Now, select your time zone and click Apply, then click OK.
Restart your applications."""""
So tzedit sounds like the way to go. My lab showed that time changed perfectly in windows and cmos. Of course the instructions do say to close all applications first before using the tool. VMLite and wallboard server will have to be closed. Or do they? Time to reset the lab equipment and devise a bigger test and put a few weak links in the mix.
I cranked up a 403 loaded with 3.1.65, a vcm 4 and a PRI card connected to our house definity. Connected a 4406. 4424, 2420 and a 6408. I tested email timestamp via VMpro, Delta, CCV, wallboard server, pc wallboard, CCC reporting, Monitor, phonemanager and Outlook. Since all of our IPO installs use the vmpro computer as the timeserver I left manager running in the taskbar. All apps are running on one win 2003 server sp2. The lab exchange server is a separate computer...naturally.
I figured I'd go for broke so I decided to see what happens if I left all of the applications running when I used tzedit.
At 2:20pm I properly used tzedit to set DST for 2:30pm and waited. Windows updated precisely at 2:30. Monitor and pc wallboard and delta showed the new time approximately thirty seconds later. Well.. so far so good. A call to phonemanager showed the correct time. I dialed a shortcode which called vmpro and sent an email. The sent and receive times were correct. And CCC reports showed the new time.
Sadly none of the phones updated. Resetting an IP phone via monitor did not change the time. Reconnecting a digital phone from and to its port did not change the time. So I suppose it was time to be patient. Perhaps the midnight maintenance would resolve the issue or perhaps IPO would request time later and fix the time. Surely a reboot or a power cycle would fix it...I hoped.
An hour later I went home. Three hours later I called our helpdesk and they checked the phones and all phones showed the correct time.
Well there you have it. I now have a game plan for better or for worse. I will perform DST without rebooting windows or IPO and without upgrading IPO or closing IPO applications. I only wish I had more phones to test with particularly in light of Avayas upgrade advise.
Your mileage may vary and I did not test IMS or conf center or contact store etc.
BTW,, anyone know which "phones" avaya was referring to?
Well o.k. So everyone patches windows after business hours so a reboot doesn't affect daily business. Thats not too bad and the O.T. will spend nicely. But having to visit each site to upgrade to 3.2.55 or to 4.0 is absurd!
Some of you will undoubtedly try it remotely but I am honestly not that brave. I am positive that at least a handful of the 403's and a 406 or two out there will have to be revived via DTE. No thank you. I'll read about it later and thank the telecom gods that I resisted temptation.
There are too many variables and failure points and client software upgrades to perform that keeps this lucky ducky from attempting a mass upgrade to accomodate DST.
So its off to the lab to see exactly what happens and to decide which method to employ.
Windows:
1. Win 2000 has no patch unless you are a microsoft super duper extended hotfix support customer. SP4 only. Ummm...probably nearly no one has this...
2. You can grab the patch for 2003 or XP sp2 then reboot. Likely after hours unless your customer can withstand the outage albeit briefly.
3. You can use the microsoft tool timezone.exe with no reboot. IBM says that there are problems using this tool so...
4. You can use the microsoft tool tzedit.exe with no reboot required and it works with 2003, xp and 2000.
""""Apply the tzedit.exe process to your systems:
Exit out of applications.
Run the executable tzedit.exe using Start > Run, provide the full path, for example: c:\Program Files\TZEdit\tzedit.exe
Your current time zone should be highlighted. Click the Edit button.
Set Start Day to Second Sunday, March.
Set Last Day to First Sunday, November.
Click OK.
Click Close.
You need to change your time zone twice using the Windows Date and Time Control Panel.
From the Start menu, click Settings > Control Panel and then click Date and Time.
Click the Time Zone tab.
Select a different time zone and click Apply.
Now, select your time zone and click Apply, then click OK.
Restart your applications."""""
So tzedit sounds like the way to go. My lab showed that time changed perfectly in windows and cmos. Of course the instructions do say to close all applications first before using the tool. VMLite and wallboard server will have to be closed. Or do they? Time to reset the lab equipment and devise a bigger test and put a few weak links in the mix.
I cranked up a 403 loaded with 3.1.65, a vcm 4 and a PRI card connected to our house definity. Connected a 4406. 4424, 2420 and a 6408. I tested email timestamp via VMpro, Delta, CCV, wallboard server, pc wallboard, CCC reporting, Monitor, phonemanager and Outlook. Since all of our IPO installs use the vmpro computer as the timeserver I left manager running in the taskbar. All apps are running on one win 2003 server sp2. The lab exchange server is a separate computer...naturally.
I figured I'd go for broke so I decided to see what happens if I left all of the applications running when I used tzedit.
At 2:20pm I properly used tzedit to set DST for 2:30pm and waited. Windows updated precisely at 2:30. Monitor and pc wallboard and delta showed the new time approximately thirty seconds later. Well.. so far so good. A call to phonemanager showed the correct time. I dialed a shortcode which called vmpro and sent an email. The sent and receive times were correct. And CCC reports showed the new time.
Sadly none of the phones updated. Resetting an IP phone via monitor did not change the time. Reconnecting a digital phone from and to its port did not change the time. So I suppose it was time to be patient. Perhaps the midnight maintenance would resolve the issue or perhaps IPO would request time later and fix the time. Surely a reboot or a power cycle would fix it...I hoped.
An hour later I went home. Three hours later I called our helpdesk and they checked the phones and all phones showed the correct time.
Well there you have it. I now have a game plan for better or for worse. I will perform DST without rebooting windows or IPO and without upgrading IPO or closing IPO applications. I only wish I had more phones to test with particularly in light of Avayas upgrade advise.
Your mileage may vary and I did not test IMS or conf center or contact store etc.
BTW,, anyone know which "phones" avaya was referring to?
On my own machine, I found this in the TZLog, any ideas what it means? I AM SET TO SYNC WITH AN INTERNET TIME SERVER.
A new Tool Operation started at Time 09:01:32 on 2/15/2007
Query ToolUsedCount : 27
---------------Parsing Command Line Parameters--------------
Reading TimeZone To Edit : Central Standard Time
Reading DayLight Start Date :-
Month = 3 DayofWeek = 0 Day = 2 Hour = 2 Minute = 0 Seconds = 0 MilliSeconds = 0
Reading Standard Start Date :-
Month = 11 DayofWeek = 0 Day = 1 Hour = 2 Minute = 0 Seconds = 0 MilliSeconds = 0
Found Global Update Flag
-----------Parsing Completed Successfully-------------------
Preparing to Modify TimeZone "Central Standard Time"
Loading information of TimeZone "Central Standard Time"
Successfully loaded timezone information
Querying MasterFlags_27 :Not found
Saving Timezone settings "Central Standard Time" which is to be Modified for undo
Setting Value TimeZone_27 :Succeeded
Setting Value TZI_Uninstall_27 :Succeeded
Successfully saved TimeZone "Central Standard Time" settings for Undo
Setting Value MasterFlags_27 :Succeeded
Preparing to Modify TimeZone "Central Standard Time"
Successfully Modified TimeZone settings of "Central Standard Time"
Edited TimeZone settings, trying to set new settings through SetTimeZoneInformation()
New settings have taken effect
Edited Timezone "Central Standard Time" Successfully
Querying MasterFlags_27 :Succeeded
Setting Value MasterFlags_27 :Succeeded
Querying MasterFlags_27 :Succeeded
Set ToolUsedCount : 28
-----------SuccessFully completed Tool Operation------------
------------------ End Of Tool Operation -------------------
--------------------------------------
A new Tool Operation started at Time 09:01:32 on 2/15/2007
Query ToolUsedCount : 27
---------------Parsing Command Line Parameters--------------
Reading TimeZone To Edit : Central Standard Time
Reading DayLight Start Date :-
Month = 3 DayofWeek = 0 Day = 2 Hour = 2 Minute = 0 Seconds = 0 MilliSeconds = 0
Reading Standard Start Date :-
Month = 11 DayofWeek = 0 Day = 1 Hour = 2 Minute = 0 Seconds = 0 MilliSeconds = 0
Found Global Update Flag
-----------Parsing Completed Successfully-------------------
Preparing to Modify TimeZone "Central Standard Time"
Loading information of TimeZone "Central Standard Time"
Successfully loaded timezone information
Querying MasterFlags_27 :Not found
Saving Timezone settings "Central Standard Time" which is to be Modified for undo
Setting Value TimeZone_27 :Succeeded
Setting Value TZI_Uninstall_27 :Succeeded
Successfully saved TimeZone "Central Standard Time" settings for Undo
Setting Value MasterFlags_27 :Succeeded
Preparing to Modify TimeZone "Central Standard Time"
Successfully Modified TimeZone settings of "Central Standard Time"
Edited TimeZone settings, trying to set new settings through SetTimeZoneInformation()
New settings have taken effect
Edited Timezone "Central Standard Time" Successfully
Querying MasterFlags_27 :Succeeded
Setting Value MasterFlags_27 :Succeeded
Querying MasterFlags_27 :Succeeded
Set ToolUsedCount : 28
-----------SuccessFully completed Tool Operation------------
------------------ End Of Tool Operation -------------------
--------------------------------------
Not sure completely but I will take a stab at it.
The first section parse shows what tzedit reports as DST. The second parse is probably you adjusting windows timezone.
Where it says Day it should say Week. Aside from that the numbers look right
Reading DayLight Start Date :-Month = 3 DayofWeek = 0 Day = 2 Hour = 2 Minute = 0 Seconds = 0 MilliSeconds = 0
March-
Reading Standard Start Date :-Month = 11 DayofWeek = 0 Day = 1 Hour = 2 Minute = 0 Seconds = 0 MilliSeconds = 0
tzedit uses this verbage:
Old end of DST = First Sunday of April
New end of DST = April 1, 2007 2:00am or Month = 04 DayofWeek = 0 Day(should be Week and not Day)= 1 Hour = 2 etc
Second Sunday of March Will now be: March 11, 2007
Last Sunday of October Would have been: October 28, 2007
First Sunday of November Will now be: November 4, 2007
The registry hex equates to this:
00 00 - is the Year from a 1900 time base.
0A 00 - The first byte is the Month (January is 01).
00 00 - The first byte is the DayOfWeek (Sunday=0).
05 00 - The first byte is the Week (starts at 1 and 5 means last).
03 00 - The first byte is the Hour.
00 00 - The fist byte is the Minute.
00 00 - The first byte is the Seconds.
00 00 - the first byte is the Millisecond.
The first section parse shows what tzedit reports as DST. The second parse is probably you adjusting windows timezone.
Where it says Day it should say Week. Aside from that the numbers look right
Reading DayLight Start Date :-Month = 3 DayofWeek = 0 Day = 2 Hour = 2 Minute = 0 Seconds = 0 MilliSeconds = 0
March-
Reading Standard Start Date :-Month = 11 DayofWeek = 0 Day = 1 Hour = 2 Minute = 0 Seconds = 0 MilliSeconds = 0
tzedit uses this verbage:
Old end of DST = First Sunday of April
New end of DST = April 1, 2007 2:00am or Month = 04 DayofWeek = 0 Day(should be Week and not Day)= 1 Hour = 2 etc
Second Sunday of March Will now be: March 11, 2007
Last Sunday of October Would have been: October 28, 2007
First Sunday of November Will now be: November 4, 2007
The registry hex equates to this:
00 00 - is the Year from a 1900 time base.
0A 00 - The first byte is the Month (January is 01).
00 00 - The first byte is the DayOfWeek (Sunday=0).
05 00 - The first byte is the Week (starts at 1 and 5 means last).
03 00 - The first byte is the Hour.
00 00 - The fist byte is the Minute.
00 00 - The first byte is the Seconds.
00 00 - the first byte is the Millisecond.
- Status
Similar threads
- Locked
- Question
