Summer clock in Israel for 2006

Summer clock (Daylight Savings Time or DST) in Israel for 2006
On the 30th of March 2006 Israel will be switching to Daylight Savings Time (aka “Summer clock”). For those of you who don’t know, because of various political reasons, the Israeli government keeps shifting the DST entry and exit points each year, which causes a great pain in the back-end for us IT people.
That’s right ! Israel is rather special when it comes to summer clock – the actual dates of summer clock’s beginning and ending are decided every year in Knesset, so we, the sysadmins, every year have to update our environment with the new settings.
Since 2005 a law exists that regulates the beginning and end of the DST period in Israel. The law tells us when the DST period begins based on the international calendar, but because of religious reasons, the exit point of the DST is based upon the Hebrew lunar calendar (the DST always ends at 2 AM on a Sunday between Rosh Ha’Shana and Yom Kippur Hebrew holidays).
This year’s dates are:

• Beginning: Last Friday of March, or March 30th, 2006 at 2 AM
• End: Sunday, October 1st 2006 at 2 AM

Note for Exchange users: Make sure you read the Calendar Issues later in this article BEFORE applying any changes.
Note for Windows Vista users: Using the following method on the latest (or any, I didn’t check) build of Windows Vista might cause some issues with the time zone settings. You will need to import the following [this_link_has_been_removed] instead.

Method #1 – Tzedit

The common practice is to use tzedit.exe utility from the NT4/Windows 2000 Resource Kit, which updates the registry on the machine you run the tool on. This is particularly important in international organizations which have branch offices in Israel, or Israeli companies that have branches in other time zones.
You will need to run the tool on ALL the computers in your network. No, running it on the DCs and servers alone won’t do.

Method #2 – A Registry file

You could import the following [this_link_has_been_removed] instead of using Guy’s [this_link_has_been_removed] tool, however you will need to find a method of importing it to all your network computers.
Using this method is relatively easy, but you’ll need to configure a logon or startup script of some sort for the computers to perform the importing of the REG file.

Method #3 – TZ2006

As in 2005 (read Summer clock in Israel for 2005), Guy Teverovsky, an Israeli Directory Services MVP (webmaster and moderator of our AD Forum) has created a utility that will help sysadmins in making the change to the Jerusalem Time Zone more easily.
Using this utility allows the administrator to “push” the time zone settings to all the network computers without having to configure logon or startup scripts.
Like last year, Guy has created a tool called [this_link_has_been_removed] (5 kb). The application requires .NET Framework, which you can get from HERE.
Usage:

Updates the computer with Israel Daylight Savings settings for year 2006
tz2006.exe [hostname] [/restore]
 /? Displays this help.
 /restore Restores Microsoft's original settings.
Running the executable without arguments will update localhost to new Daylight Savings set
tings.

You can update a remote host by running something like:

Or you can restore the Microsoft's original settings by running:

Some caveats:

	
You need .NET Framework on the computer you are running the application from. Updating remote hosts does not require .NET framework on remote hosts.
	
Because this is .NET code, it has to be executed from local drive or it will throw an exception about missing privileges, hence if you are intending to put it in logon/login/startup script, make sure to copy the EXE to the client and execute it from local drive.
	
The application forces "Jerusalem (GMT+2)" time zone on the client.
	
You need to run the application from local hard drive. .NET applications invoked from network drive run with restricted privileges.
	
If you are updating remote host, your account has to have write access to the relevant keys (being in Administrators group of the remote host is more than enough) and Remote Registry service has to be running on the remote host (duh!!)
	
The tool will not work on Windows 9x clients - do not even try ! I do not work with those and have not tested the application on 9x. Sorry, get yourself a real OS.

Refreshing the Time Zone settings on the client computers
You need to refresh the TZ settings on the client computers in order for it to take effect. You can do so by using one of the following methods:

	
Reboot the machines
	
If the users that are logged on to the machines have local admin rights they can run the following command:

	
If the users  that are logged on to the machines have local admin rights they can temporarily change the Jerusalem Time Zone to something else (whatever comes first), click on Apply, then return to Jerusalem.

 



  




Updating many clients at once
If you want quick and dirty way to update some remote hosts in the AD, you can wrap the app with a simple batch script:

for /F "usebackq delims==" %%i IN (`"dsquery computer ou=clients,dc=domain,dc=local -o rdn"`) do (
 echo Updating computer: %%i
 tz2006.exe %%i
)
for /F "usebackq delims==" %%i IN (`"dsquery computer ou=clients,dc=domain,dc=local -o rdn"`) do
 w32tm.exe /resync /computer:%%i /nowait

Copy the above text into a new .BAT file (do not forget to change the LDAP search base to reflect the target AD).
If you’d like to just update your server machines, for example, you could use the DSQUERY command in a different way (thanks to Amit from the Tapuz forums):

dsquery * dc=domain,dc=co,dc=il -scope subtree -filter "(&(&(objectCategory=computer)(|(operatingSystem=Windows 2000 Server)(operatingSystem=Windows Server 2003))))" -attr cn -limit 0 >c:computer.txt
for /f %%i in (c:computer.txt) do w32tm.exe /resync /computer:%%i /nowait

Again, copy the above text into a new .BAT file and do not forget to change the LDAP search base to reflect the target AD.
Important note: Please test it before running against some several hundred hosts. We have tested it on several computers and the 2005 version Guy has written last year has been proven to do the trick, but there is always a chance of some stupid error or unexpected client behavior (i.e. we have no idea what will happen to guest OS-s when updating WMWare or VS host).

Calendar Issues

Because of the different Israeli DST timeframe each year, Israeli users face an issue with recurring appointments and scheduled meetings in their Exchange and personal calendars.
Only appointments that are created after the new time zone has been applied will be displayed as expected during the overlap period. Any appointments that are created before a new operating system time zone has been applied will be displayed incorrectly during the overlap period.
Before applying this fix or any other registry-based fix please make sure you hard-print your calendar. You don’t need all of it, just the next 6 moths. Saving a backup copy won’t do because after you make the changes, any time you will open the backup version it will also be affected by the changes in the DST.
The problem
All meetings and scheduled appointments that fall between the following dates (overlap period) will be moved one hour ahead of the original time the meeting was scheduled:

• March 31 to April 6 2006

Here is a screenshot of these dates BEFORE the change:

Here is a screenshot of the same dates AFTER the change:

All meetings and scheduled appointments that fall between the following dates will be moved one hour prior to the original time the meeting was scheduled:

• October 1 to October 7 2006

Here is a screenshot of these dates BEFORE the change:

Here is a screenshot of the same dates AFTER the change:

The solution
After performing the changes in the DST for 2006 you will need to modify the appointments that were shifted. Microsoft recommends that you modify any appointments that were created during the overlap period in successive years by using either of the following methods:

• Export the appointments to a .csv file before you modify the operating system time zone, delete existing appointments in the overlap period, and then re-import them after the operating system change. For more information about how to change the time zone without changing appointment times in Outlook, see the Microsoft Knowledge Base articles that are listed at the end of this section.
• Manually modify each appointment in the overlap period in each successive year after the operating system time zone has been changed back.

Navigate to the above dates and make the necessary changes in the calendar by manually shifting the appointments one hour back or one hour forward, based upon the original time these appointments were scheduled to take place. You must instruct your users to perform this task, or use an automated method that invokes scripts and edits the user’s calendars. Because the time difference is only one week, unless your network consists of hundreds of clients I suggest you perform the task manually.
You might want to look into this great Blog post made by Glen Scale from Australia: Updating appointments that are 1 hour out because of the Commonwealth Games Timezone Changes. He has some great information about this issue (yes, Australians face a similar problem in the year 2006), and has a nice script that might work for you.

Support

No support of any sort will be given for this script/tool or for any other script/tool found on the Petri.co.il website for that matter. If you need to contact us with any support issues, feedback or suggestions regarding the tool(s) and script(s) found on this page please write an e-mail to THIS address.

Download

Download [this_link_has_been_removed] (5 kb)
Download the manual [this_link_has_been_removed] (1 kb)
Download [this_link_has_been_removed] (30 kb)

Links

Guy’s Windowmaker’s Blog
Glen’s Exchange Dev Blog