Novell is now a part of Micro Focus

OPEN CALL: Dealing with Daylight Saving Time 2007

Novell Cool Solutions: Tip

Digg This - Slashdot This

Updated: 7 Mar 2007

It's coming faster than you think. The new congressionally mandated changes to the start and stop dates of Daylight Saving Time are throwing the IT world a serious curve ball.

If you have ZENworks Patch Management, you're home free. (See this article for more info.) Please take a minute to let us know how you are using ZENworks Patch Management to fix the problem, so others can learn from your example.

But even if you're not so lucky to have an automated solution, we'd love to hear from you too. How are you preparing for the change? Are you pretty well ready by now, or do you have a hard month of work ahead of you? Do you use any other ZENworks products to help? Let us know what you're doing. As usual, you'll earn Novell Rewards points for everything we publish, so bring them on.

How We're Dealing With DST

Humzah Khaial

Once again Novell ZENworks saves the day. Using the TZedit.exe (1) utility to manually modify the time zone on one of our Windows 2000 Professional workstations, and export the registry keys in (2) and (3), we then were able to automate the new Daylight Saving Time registry modification to all our Windows 2000 Professional workstations using a Novell ZENworks application with the registry keys imported and the application forced to run once. We have also found that by applying the Windows XP Professional DST patch and exporting the registry keys in (2) and (3), we were able to automate the editing of the timezones to be used on Windows 2000 workstations.

(1) The Tzedit.exe utility is available on any Microsoft Windows Resource Kit.
(2) [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones]
(3) [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]

I hope this helps someone avert the crunch.

Robert Parlett

We are still running on Win2K so there is no officially supported patch from Microsoft unless you pay for extended hotfix support. There is a manual way to do this in Win2k using a Microsoft-supplied utility called tzedit which is available here.

We tried capturing the registry changes that tzedit made with snapshot, but the NAL application that we distributed only half worked. It turns out that we still had to manually click on the timezone tab in the Date/Time Properties box before it would completely work.

We ended up using a freeware 3rd party utility from which is available here.

We copied it to a network share and manually created a run-once NAL application that runs this exe as an unsecure system user with the /qinstall parameter. This runs silently and does exactly what we need it to.

Christopher Farkas

I've created a NAL application to push the registry changes for all my (NON SP2) PCs. I'm using NAL's ability to push in registry changes and not push a *.reg file either. XPsp1, sp2, Win2k etc. Then I use "shutdown.exe" <windows native file> to restart the PC.

For XP SP2, I'm pushing out the patch with the same methodology that I do normal patches. I'd doing this instead of the registry entries, because I like how the patch puts in an Event Log under Applications. If you want to check that your PC is patched you can run Dumpel.exe (MS free download) against your Event Logs and have it filter out the event and append it to a report file that you can view.

Here is an example of what I'm doing.

c:\utils\dumpel.exe -c -l application -m wsh -t >>

This all works under ZENworks 4x and 6x.

Web access, running the Novell patch on it (basically a reinstall).

The day we have this occur, we are sending an e-mail out to all our users to tell them that any appointments set from now on for that time period will be "good". Anything that was set prior to this for that period will be off. We're suggesting to all the users that the person that SET the appointment be the one to fix it. Also as a failsafe method, we are asking them to put the Time into the subject line.

I'm also letting the patch go out to our Windows servers thru WSUS.

Jamy Smith

Spectrum Health uses WSUS for a patching solution, however there is no patch for Win2k or prior versions of Windows. To get around this I built a ZENworks App object that will be a forced run for all Win2k boxes in our environment.

The app object implements the reg file and vbs detailed in mskb914387. Look at Method 1 Steps 1 & 2. Remember to change the first line in the REG file to REGEDIT4 in order to do a direct import of the file into your app object.

Create a vbs file with the contents of the script detailed in the KB and then have your App object run
%*WINSYSDIR%\wscript.exe with the parm \\server\share\blah.vbs.
Associate the app object appropriately and presto changeo your Windows 2000 boxes are now compliant with DST2007.

Joe Marton

Well since I'm not using ZENworks Patch Management, to roll out Microsoft patches I simply use ZENworks Desktop Management. I create app objects for each patch with a naming scheme of Install-KBxxxxxx-MSxx-xxx using the knowledgebase & MS bulletin numbers there, i.e. Install-KB911280-MS06-025. Each Microsoft patch installs a key under HKLM\SOFTWARE\Microsoft\Updates\Windows XP, so I create a Distribution Rule in ZENworks that checks for that key and only makes the app available if the key does not exist. Then it's a matter of making the app a force run and configuring the appropriate command-line parameters for patch installation.

Here is how my DST patch looks:

Install-KB928388-DST (no associated MS bulletin I could find) 

HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP3\KB928388 is the key it looks for. 

Command-line switches: /passive /warnrestart:10 

Those switches allow the progress meter to be displayed but otherwise is an automated install, and it will automatically restart the PC after installation but give a 10-second warning. You could use /norestart instead of /warnrestart if you don't want the PC to restart after patch installation.

Scott Kiser

We don't use ZENworks Patch Management, but we do use ZENworks; also we still use Windows 2000, and Microsoft announced that no patch was forthcoming for time zones for Win2K.

I did a little digging: turns out that time zones are defined in the registry in Windows 2000, in exactly the same way as they are defined in Windows XP, BTW. So, I fired up ConsoleOne and created a new application object to distribute the following keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones\Eastern Standard Time]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones\US Eastern Standard Time]

Then I associated the app object with both Windows XP and Windows 2000 PCs. Voilá!

Jules Kremer

We've not yet implemented ZENworks Patch Management. We're using Windows Update Services (with all its problems and challenges...) and approved all timezone-related patches. If there are workstations failing to install it through WSUS, it is enforced by the ZENworks InstallShield distributed application. (Some MS patches fail to install for some reason, msi installation usually works fine.)

Most of those timezone patches actually do not hurt us this year, only if someone is going on a holiday and wants to use webmail.

A couple of years ago the Daylight Saving Time shifted in our region for about a month, and it gave us some problems. The workstations were updated, but we had complaints from users who had problems with appointments in their calendar. For some reason they were shifted for an hour. It was hilarious, but also annoying.

The user's mailbox had the correct timezone selected through the webmail interface, but the problem disappeared when they selected it again and reconfirmed it. Problem gone. We created an Captivate demo for it and put it on our intranet helpdesk site.

John Fuge

Here is a procedure I wrote for admins who are maybe not as experienced in deploying applications and knowing the results. This is a good chance for less experienced ZENworks admins to step up and get the job done for DST. I tried to make this a click-by-click Getting Started kind of guide.

Read the Guide here >

Sue Anderson

We are running ZENworks 6.5 and 7 with no Patch Management. We are using NALs to push the DST changes to our machines. We are also making an icon available for each OS on our web page for those machines that might not be in ZENworks yet.

  1. For the NALs, I took one PC of each OS and ran TZedit.exe for that OS or for XP used the Microsoft patch. TZedit can be found on the resource disk or in some cases on the install CD for each OS. Once the local machine is updated, open the registry and export two keys:
    • Local Machine\Software\Microsoft\WindowsNT\CurrentVersion\TimeZones\pick your time zone here.
    • Local Machine\System\CurrentControlSet\Control\TimeZoneInformation
  2. Import these keys into a NAL for each OS. I'm using a force run, and hidden distribution. It flashes for maybe a second, so the help desk has been notified in case they get calls.
  3. Now go to ZENworks Asset Management and use it to get a list of your machines with OS and whatever other information you want. Start adding machines to the NALs. This will only work if the machines are on for 12 or more hours or your users reboot.
  4. Our tree is quite large so at the 4 major branches I made a set of NALs. That will put under 1,000 machines in each NAL. I'm logging the successful distribution so I can send it to the local Administrators.

Using ZENworks is a lot easier for us to get distant machines updated, since some of our machines would require several hours of driving to reach them or a small army of Techs to remote into each machine.

Hope this helps.

Dave Loeffler

We are currently using a program called timezone.exe (downloaded from Microsoft) through NAL. The NAL copies the timezone.exe file to the local workstation and then runs C:\Options\Timezone\timezone.exe with the parameters: /s 02:0:2:03 02:0:1:11. Set the NAL to Run Once and Force Run on all workstations.

Scott Fitzhugh

I have all our school district's 275 NetWare 6.5 servers set up with ZENworks Server Management's Tiered Electronic Distribution (TED). I set up a distribution that copied the DSTShift.nlm to the SYS:SYSTEM of each server. It also had a Post-Distribution command included which ran that same NLM on the server. This took care of almost all of my servers, so I only had to manually copy & run the NLM on the handful of remaining older NetWare servers in the tree that do not have TED on them. Saved me a ton of time.

Steven Parankewich

Scott Kiser's method doesn't work! More is required. Publish the following as it properly sets the DST with ZENworks for Desktops 4, 6, 6.5 or 7. If you do not use the .vbs section it simply will go back to default on reboot.

Create the following .reg file and import into a ZENworks Application under Distribution > Registry:


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Alaskan Standard Time]
"Display"="(GMT-09:00) Alaska"
"Dlt"="Alaskan Daylight Time"
"Std"="Alaskan Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Atlantic Standard Time]
"Display"="(GMT-04:00) Atlantic Time (Canada)"
"Dlt"="Atlantic Daylight Time"
"Std"="Atlantic Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Central Standard Time]
"Display"="(GMT-06:00) Central Time (US & Canada)"
"Dlt"="Central Daylight Time"
"Std"="Central Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Eastern Standard Time]
"Display"="(GMT-05:00) Eastern Time (US & Canada)"
"Dlt"="Eastern Daylight Time"
"Std"="Eastern Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Hawaiian Standard Time]
"Display"="(GMT-10:00) Hawaii"
"Dlt"="Hawaiian Daylight Time"
"Std"="Hawaiian Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Mountain Standard Time]
"Display"="(GMT-07:00) Mountain Time (US & Canada)"
"Dlt"="Mountain Daylight Time"
"Std"="Mountain Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Newfoundland Standard Time]
"Display"="(GMT-03:30) Newfoundland"
"Dlt"="Newfoundland Daylight Time"
"Std"="Newfoundland Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Pacific Standard Time]
"Display"="(GMT-08:00) Pacific Time (US & Canada); Tijuana"
"Dlt"="Pacific Daylight Time"
"Std"="Pacific Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\US Eastern Standard Time]
"Display"="(GMT-05:00) Indiana (East)"
"Dlt"="US Eastern Daylight Time"
"Std"="US Eastern Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\US Mountain Standard Time]
"Display"="(GMT-07:00) Arizona"
"Dlt"="US Mountain Daylight Time"
"Std"="US Mountain Standard Time"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\W. Australia Standard Time]
"Display"="(GMT+08:00) Perth"
"Dlt"="W. Australia Daylight Time"
"Std"="W. Australia Standard Time"

Here is the most important step to make it work.

Under Distribution Options > Distribution Scripts > Run After Distribution:

Set objSh = CreateObject("WScript.Shell")

'Get the StandardName key of the current time zone
szStandardName = objSh.RegRead("HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\StandardName")

'Enumerate the subkeys in the time zone database
const HKEY_LOCAL_MACHINE = &H80000002
Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
szTzsKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones"
objReg.EnumKey HKEY_LOCAL_MACHINE, szTzsKeyPath, arrTzSubKeys

'Step through the time zones to find the matching Standard Name
szTzKey = "<Unknown>"
For Each subkey In arrTzSubKeys
    If (objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & subkey & "\Std") = szStandardName) Then
        'Found matching StandardName, now store this time zone key name
        szTzKey = subkey
    End If

If szTzKey = "<Unknown>" Then
       'Write entry to the Application event log stating that the update has failed to execute
       objSh.LogEvent 1, "DST 2007 Registry Update and Refresh failed to execute on this computer.  Time zones failed to enumerate properly or matching time zone not found."
       Wscript.Quit 0
End If

'Launch control.exe to refresh time zone information using the TZ key name obtained above 
objSh.Run "control.exe timedate.cpl,,/Z" & szTzKey

'Get current display name of refreshed time zone
szCurrDispName = objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & szTzKey & "\Display")

'Write entry to the Application event log stating that the update has executed
objSh.LogEvent 4, "DST 2007 Registry Update and Refresh has been executed on this computer." & chr(13) & chr(10) & chr(13) & chr(10) & "Current time zone is: " & szCurrDispName & "."

Script Engine Location: %windir%\system32\wscript.exe

Extension: .vbs

I personally prefer applying against workstations and make Availability Dependant on OS Windows 2000 or XP with Run Once.

Tony Steffen

I am using ZENworks 7 and using a similar method to previous suggestions using the steps from Microsoft. See and create the 3 files and use Method 1: Change the time zone settings on multiple networked computers. Have the application run the DST2007Update_Win2k.cmd. That will call the other two files mentioned in Microsoft's tid.

Make a folder on the server where users will have rights called Daylight to place all your files.

This will adjust for Central Daylight Time Change.

Create a ZENworks app called Daylight Savings and associate it to users. Under Run put in the path where the three files are stored and execute DST2007Update_Win2k.cmd. Under "Availability" click Add and Registry and browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Central Standard Time\Dynamic DST. Tell the App if key does not exist Run the Application.

I created a second Application called DST Message that looks for the same Registry Key and if it exists Display the message that their Daylight savings time has been updated and they need to fix their GroupWise Appointments (per TID 3768695 DST Changes and GroupWise End User Action required). I used the Cool Solutions tool called Reminder.exe, which requires the user to click OK and displays a nice big yellow box to let the user know they have to change their GroupWise Calendar information.

You can chain these two applications together but you will need to remove the "Availability" requirement on the DST message application to have them run at the same time, or if you have already updated some users you can run the DST message application separately and look for the change in the registry.

Have fun.

Gary R. Burns

We used ZENworks Patch Management to deploy the DST update to all of our systems running Windows 2000 and XP. Used the DSTSHIFT.NLM on all of the NetWare servers.

Updated GroupWise on the servers to 6.5.7. We use GroupWise 6.5 and have a lot (several thousand) of calendar entries that were adjusted by using the ADJAPPT.EXE program. We took each Post Office down and ran the program to adjust the calendars back to the correct times. The program was written for 5.x, but worked fine on 6.5. I tested it on backups of the post offices before running on the live post offices.

Ran GWCHECK before running ADJAPPT.EXE and then ran it again after it was complete to make sure everything was ok.

We use GWEXTRANET from Messaging Architects to display our calendars on the web. Having someone modify each calendar entry would have taken a very long time. Also have several users who have fifteen or more entries for each day, and that would have taken them a considerable amount of time to adjust all the appointments.

Christopher Farkas

I use marker files that I write out to the HDD so that it only runs once per PC/Server.

Don't forget that "run once" means once per user while on an NT/2k, etc., flavored machine. We have users sharing multiple machines and try to cut down on the amount of times an app reruns on the same PC.

Joe Sears

We were "lucky" in that we have migrated a large portion of our workstation to Windows XP SP2 already so we only needed to apply the MS patch provided by Microsoft. For this we used our standard patch management solution. We then used ZENworks Asset Management (ZAM) to report on compliance and remediate any workstation that required it.

For our legacy workstations, which are not using ZENworks or ZAM, we used a login script in our old tree to import the registry keys generated using the tzedit. We can only hope we go all our legacy systems with this method since we have no reporting capabilities, but we are confident.

For JVM I wrote a PERL script that we compiled into an exe and push to our XP workstation in an AO. We forced the AO to all workstations and set an availability requirement of environment variable USERNAME does not exist. This way we can be sure it will not run while JAVA is open. If JAVA is open the tzupdate.jar does not work. The script searches the registry for any versions on JVM installed and runs the update using the JAVAHOME found in the registry. It excludes 1.3 since it does not work on any version of 1.3.

I also wrote a reg key to our section of the registry for reporting (we create a KEY under HKLM to store info about the workstation like DESKTOP/LAPTOP, Build Version, etc., so we can control AO or report on workstations using ZAM). The script also worked for our legacy system in the login script. It logs to c:\NalCache\Company Name folder, if the script reads the word "Failed" in the log it writes the log to a central share with the workstation name so we can try to remediate the issue.

Here is my PERL Code:

#~ Script to determine what versions of JAVA are installed and to update 
them for DST
#~ The script works best if copied locally to the workstation with the 
#~ and the script and jar file are in the same folder (i.e. 
#~ Created by Joe Sears 1/26/2006

#~ Path to the tzupdate file
$plogPath="c:\\NalCache\\Logs"; #local log path
$flogPath="\\\\CENRAL SHARE"; #Central log path
$computername=$ENV{COMPUTERNAME}; #Read Computer name environment variable

#~ Check to make sure the NALCache log directory exists, if not it is 
created (for Legacy systems)
if (-e "c:\\NALCache\\Logs"){ 
    mkdir "C:\\NALCache\\";
    mkdir "c:\\NALCache\\Logs\\";
#~ Setup Environment for the script to red the registry using 
Tie::Registry Module and the / delimiter
use Win32::TieRegistry ( Delimiter=>"/", ArrayValues=>1 );

        $Registry->Delimiter("/");                  # Set delimiter to 
        $userKey= $Registry->{"LMachine/Software/JavaSoft/Java Runtime 
Environment/"}; #Sets the base registry to read
        @key_names = $userKey ->SubKeyNames;  #Reads the sub keys into an 
    #~Pushes the current time into the log array
    push (@log, "$computername\n");
    push (@log,"$now\n");
    #~ Iterates through the key array
    foreach (@key_names){
        chomp $_;
        $next = $Registry->{"LMachine/Software/JavaSoft/Java Runtime 
Environment/$_"}; #set the base reg key to the key plus the sub key in the 
        $value= $next->GetValue("JavaHome"); #reads the value of the java 
home key
        #~ If Statement to check if the "value" of the java home key 
starts with c:, if so the value is used as the path
        #~ to run java.exe with the tzupdater.jar file and rights to a log 
file in nalcache\logs folder
        if ($value=~/^C:/){
            if ($value!~/1.3/){
                $txUp=`\"$value\\bin\\java\" \-jar $tzpath \-u \-v`;
    #~ Stamps the registry to HKLM\Software\Commerce with the string of 
JVMUPdate with a value of 1
    $rtKey->{"COMPANYKEY/"}= {
        "/JVMUpdate", => "1",
    #~Put a space at the end of the log
    push @log, "\n";
    #~check the log array for the word failed.
    $failed = grep /failed/i,@log;
    print @log;
    #~create local log
    open (LOG, ">>$plogPath\\$computername-tzupdater.log");
    print LOG @log;
    close LOG;
    #~Create Failed log on network if log array contains the word failed.
    if ($failed!~"0"){
        open (FLOG, ">>$flogPath\\failed-$computername.log");
        print FLOG @log;
        close FLOG;
sub now{
    #~ Creates time stamp for logging
        #~ printf TIME "%4d-%02d-%02d 
        return sprintf "%4d-%02d-%02d 

David Herde

Got ZENworks Patch Management...
The good folks at PatchLink wrote the 'prior to XP' hacks.
I sent it out today.

Paul E. Gemmill

We don't have to worry about daylight savings time as we run all our computers set to Greenwich Mean Time. This saves a lot of trouble and means all our computers are consistent and it makes it easy to deal with overseas clients. Besides, we don't really believe that the Sun moves to the whims of Congress. If you want more Sun in the afternoon - get up earlier.

Brian Snipes

We use GroupWise 7, ZENworks 7 and Advansys Formativ. I modified an example Formativ applet that Advansys had so that users could print out a list of their calendar item between those 2 dates giving them a deadline to have it done by. Then immediately after the deadline pushed out the DST patch with ZENworks and had the users change the appointments that didn't match their printout. Worked very well.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates