DST 2007 tzmove hell, is this operation even necessary? 1

[jstevens]

I have been spending hours in trying to get msextmzcfg or msextmz to work in updating the time zone information for outlook appointments in exchange. I have not been successful and do not feel like waiting on hold for 4 hours with Microsoft. See other DST thread on my errors.

So I decided to take a computer that had the XP timezone patch installed and change the date to March 15.

Well, first off the time was not automatically adjusted even after reboot. The checkbox to auto update time for DST is checked. So I'm thinking, hmmm thats not good. The zone does change from Pacific Standard Zone to Pacific Daylight Zone.

The main reason for this test was to see the time for scheduled appointments. Appointments made before the tz patch was installed, did not change. They remained the same time.

Um, I thought this entire rigamarole process of running tzmove was to fix a problem of the time not being rolled forward one hour during the extended (new 4 week) DST periods?

According to KB931667

"Calendar items are created in Outlook by using Coordinated Universal Time (UTC) format. UTC is an international standard 24-hour timekeeping system. Time zone information for Outlook is obtained from the Windows operating system in which the calendar items are created and is obtained at the time that the calendar items are created.

For example, an 8:00 A.M. appointment on March 1, 2007 in Redmond, Washington is stored in Outlook as UTC 4:00 P.M. In this case, DST has not yet started, and Redmond time is eight hours behind UTC.

When an update is applied to the Windows operating system to accommodate the new DST definitions, the computer’s local time is changed to the extended DST time. However, the UTC is not adjusted when the local time on the computer is adjusted. Therefore, calendar items that are added to Outlook during the extended DST period are off by one hour."


So the correct assumption is that the computer I was on, by just changing the date on the computer (not connected to Internet time source) did not really update to DST even though the time control panel applet says the time zone is Pacific DST?

Well, I tried the same test on two more XP SP2 with Outlook 2003 computers, same results. The time was not automatically updated and the time of the appointments stayed the same.

Is my test not valid? Is tzmove necessary? If so, how and why does it work.

Am I just going crazy here?


Jason

 

[jstevens]

Upon further research I found that only if the computer rolls to the new zone on its own will it update the time. If one manually changes the date XP does not roll the time.

However, even when auto rolling, none of the events in the extended DST period change or are off.

I will be attempting to call MS again, hopefully their 4 hour wait times are over.

Jason

 

[KRPGroup]

My take on this whole process is if you do the OS updates and you can live with the apts during Mar 11-Apr1 being off by 1hr you don't need to run the TZmove.

This apt only seems be there to correct the time apts made prior to the OS update. I beleive after this first calendar glitch passes it will not be an issue, unless you are booking way into the future.

Just my perspective!

 

[jstevens]

Here is additional information and repost from another thread.


I have been spending hours in trying to get msextmzcfg or msextmz to work in updating the time zone information for outlook appointments in exchange. I have not been successful.

I decided to take a computer that had the XP timezone patch installed and change the date to March 11 and autoroll or to like March 13th, 15th. I exported a persons calendar items to a PST and took the machine off the domain and made standalone and off the Internet.

The zone does change from Pacific Standard Zone to Pacific Daylight Zone correctly. Time auto changes only if the computer auto rolls its time after 2am on the 11th. There is no longer a balloon pop up that says windows auto updated your time, but it did. If you manually change the date to the 13th or 15th, time is not auto adjusted but the time zone does adjust correctly.

The main reason for this test was to see if the time for scheduled appointments in the Outlook calendar would change or be incorrect. Appointments made before the tz patch was installed, did not change. They remained the same time. Now I am not sure if the export to a PST invalidates this test. Otherwise, one would have to change the date and time on their server. But then the time stamps on active directory objects would be all messed up and I don't have a test server environment to play with.

So if my testing is valid. I thought this entire rigamarole process of running tzmove was to fix a problem of the time not being rolled forward one hour during the extended (new 4 week) DST periods?

According to KB931667

"Calendar items are created in Outlook by using Coordinated Universal Time (UTC) format. UTC is an international standard 24-hour timekeeping system. Time zone information for Outlook is obtained from the Windows operating system in which the calendar items are created and is obtained at the time that the calendar items are created.

For example, an 8:00 A.M. appointment on March 1, 2007 in Redmond, Washington is stored in Outlook as UTC 4:00 P.M. In this case, DST has not yet started, and Redmond time is eight hours behind UTC.

When an update is applied to the Windows operating system to accommodate the new DST definitions, the computer’s local time is changed to the extended DST time. However, the UTC is not adjusted when the local time on the computer is adjusted. Therefore, calendar items that are added to Outlook during the extended DST period are off by one hour."

In my testing, appointment times are not off. Is my test not valid? Is tzmove necessary? If so, how and why does it work.


I am currently waiting on hold with MS so hopefully I can get some more authoritative answers.

The issues I am getting with the two exchange utilities and also their VB script is:

HrProcessMailboxTable:Unable find mailbox timezone:Error 0x80004005.

I get one or two successful dots when I run the vb script from KB 930879 but 99% fail with exclamation marks.

I will be using the domain login script method running tzmove.exe V2 with /quiet /onlycreatedprepatch

I would really hate to put this on for all of my clients, have it change the times for appointments and have them be off an hour due to this tool, if it is not really necessary.




Continuing testing, on the above test bed on Pacific Standard date of 3/7 I ran the tzmove utility. It found multiple items and updated them, pushing them back an hour. Which, is the wrong time. Lets say an appointment was originally scheduled at 8:00 am prepatch and supposedly was saved using the old UTC entry. Tzmove updates the entry which pushes back the entry by an hour?

Why is that happening? The appointment if it was scheduled at 8:00am, should never change as it is displayed on the calendar no matter what is happening in the background! When I change the date to Pacific DST and change the time, the appointment never goes back to its normally scheduled 8:00am time, it stays at 7 now even during DST extended period or after.

This seems to be not right and I am highly confused now. I would assume MS made TZmove for a reason, but from what I am seeing tzmove seems to be creating the problem. I have verified this exact same symptoms using outlook with exchange.

For events made after patch, if you run tzmove, it bumps them back an hour, to an incorrect time. Appointment made at 8:00am, run tzmove, appointment is now at 7:00am. Am I to just have faith that it will revert back to the correctly scheduled time of 8:00am after DST kicks in? I don't think so.

Just FYI there is a new hotfix for tzmove, KB933146 and this has a command line switch to only udpate prepatch entries. But, should this not be the default operation? If one installs the patches, and schedules appointments after the patch, should they not be stored correctly?

NO! By default they are pushed back an hour even after the patch is installed.



Ok, here is what I have found out so far. Microsoft is totally overwhelmed.

The issue with the UTC being wrong in the outlook calendar is ONLY FOR RECURRING APPOINTMENTS! Or so I'm told.

There is no issue with single instance as they do not record the time zone.

So, all that needs to be run is tzmove so that it updates only recurring appointments and does not mess with single instance. This of course IS NOT THE DEFAULT SETTING !!!! This cannot be set in the GUI of tzmove but only by command line option.

Incredible...

tzmove /quiet /onlyrecurring /onlycreatedprepatch

So if one was to run the exchange tool, then you want to make sure you extract recurring and only update recurring.

The question that was not answered (case is still open) if the problem is only with recurring appointments, then, why does the utility update single instance, and why is that the default setting?

My case is still open and once I find any more info I will post here. If someone already has this answered then please make an update here.


Microsoft KB931667 clearly states that both single instance and recurring appointments will be updated by the tool. However Microsoft support just told me that only recurring appointments that store the time zone data is what needs to be updated. If the Qarticle is wrong, then, that would explain all of the confusion.

I feel strongly that the Qarticles are wrong due to my testing and that only recurring appts need to be updated.

Even KB933146 released March 6th states that single instance calendar items before the DST2007 rules were applied need to be rebased.

Again my results are single instance calendar items made before the 2k7 rules are all bumped back one hour regardless and this is incorrect, they should not be.

Jason

 

[jstevens]

Additional testing. XP Sp2 without DST patch, scheduled recurring appointment. Installed DST patch. When rolling into DST the time is off only for the recurring appointments. So recurring appointments due have a problem, however, I am 90% certain that single instance appointments do not.

I hope I am wrong but it looks like everyone who is performing the Outlook and Exchange rebasing on single instance appointments are creating the error and incorrectly changing the time for the single instance appointments because it is only the recurring appointments that need to be rebased.

I hope I am wrong.

 

[KRPGroup]

I read somewhere that reoccuring apts have time zone data embedded in the apt and they do not need to be adjusted for this reason, single instance do not have TZ info.

 

[ShackDaddy]

Jstevens, I took your comments/work to the Exchange product group and asked them your basic question: whether in fact single-instance appointments need to be rebased.

The simple answer I got was: "ALL appointments are affected by DST."

My guess is (DUH!!) that to properly test your scenario, you'd actually need to roll the date of your Exchange server forward. Messing around with the client time probably isn't definitive.

ShackDaddy
Shackelford Consulting

 

[jstevens]

Thanks ShackDaddy,

Well, that is Microsofts answer, sortof. Is this exchange group with Microsoft or inhouse? The first handler I talked to at MS support after waiting 7 hours said that only Recurring appointments store DST info. This is what my testing proves. It is only recurring appointments that are off (DST info needs to be updated). In all of my testing single instance appointments are never off. I have tested both with Exchange and DST. The only thing I have not tested is rolling Exchange itself into DST. However I have been able to reproduce exactly the DST issue using a PST.

Single instance appointments are only screwed up when I run tzmove against them otherwise they are fine.

I am rolling out tzmove only updating recurring appointments to all of my clients at this point. If I have to go back and do single instance as well, so be it.

I know this sounds like a conspiracy but, I think it is.



If I turn out to be wrong, no biggie, but, if I am correct, oh boy.


Jason

 

[Vik20]

I asked my 50 users to run tzmove themselves. Most have not reported problems (yet), but I did witness one update where recurring items with invitees were an hour ahead in the delta period. Other recurring items and one-time items were OK.

I did:
Server OS patches
Workstation OS patches (xp/2k)
Exchange 2k3 Patch
tzmove w/ Outlook 2k3

 

[usereasy]

Yeah, this is getting really ridiculous with all the ms confusion.

Below is what the Exchange Calendar Update tool states on the microsoft site. It looks like the hour difference is going to affect all appointments both recurring and single instance after the times roll.

With some wonderful ms hype about the '07 version just "works" correctly.

Anyone had a chance to VMWare roll an exchange server and client to see what happened???

++++ Verbatim from MS Site ++++++++++++++++++++++++

Overview
Important

Before you run the Exchange Calendar Update tool, refer to Microsoft Knowledge Base article 930879, "How to address daylight saving time by using the Exchange Calendar Update Tool," for complete information about potential effects on your IT environment and user base.

After installing the Windows and Exchange daylight saving time (DST) updates, all old appointments (both recurring and single instance) that occur during the extended DST period will be incorrectly displayed as having moved back one hour. These appointments will need to be updated so that they display correctly in Outlook, Outlook Web Access, and CDO-based applications. The Outlook Time Zone Data Update Tool enables end-users to update their own calendars. (For Outlook 2007 the time zone update feature is built into the application.)

The Exchange Calendar Update Tool enables administrators to avoid the challenges involved with broadly deploying the Outlook tool to all users and ensuring that each user runs the tool correctly.

 

[jstevens]

Ok good news, I was wrong. In a live exchange environment one does need to rebase single instance appointments. They were off also.

Apparently when I copied the appointments out of the exchange store into a PST, that affected the results of my previous testing.

I will be running a complex login script update that runs tzmove in quiet mode that rebases single and recurring.

Since I was totally unsucessfull in getting the exchange tool on pretty much ever network I tried to run it on I am forced to use the outlook tool which is ok but there are many gotchas.

In my login script I issue a call to a main batch file and in that main batch file I make more calls to individual batch files that do the following.

Quiet install of windows installer service 3.1
Quiet install of the XP DST patch
Quiet install of tzmove
Quiet install of tzmove v2 update
Quiet run of tzmove on local machine with /onlyprepatch

I use some if exists to control reinstalling of tzmove and running of tzmove rebase tool if outlook does not exist.

Works fairly well. Would have been better to run the exchange tool against all mailboxes but I waited on the phone for 7 hours with Microshaft and only spoke with a handler helping out, not an actual exchange tech. Of course, no call back. I attempted to get into the online forum but could also not get in.

So much fun. Hope everything works out for everyone. I for one do not think we should be having to guess and hold our breath on this.

Jason

 

[ShackDaddy]

Did you ever read my walkthrough for this process? The error that you described getting isn't actually an indication of failure, and is normal for the process.

http://www.shackelfordconsulting.com/2007/03/using-exchange-calendar-update-tool-for.html

I've used the Exchange Calendar update tool in the way that I describe on six different networks this week. I know that 58Sniper used it too, on a 400-client network.

ShackDaddy
Shackelford Consulting