How Microsoft Botched DST 2007

Well, March 11 has come and gone. The mini-Y2K has passed. As expected, nothing major has gone wrong, but there are many minor glitches, and people will be missing a lot of meetings for the next few weeks. After a huge push by IT folk (I've personally put in about 100 hours on DST remediation), we've passed the hump, but Microsoft has a lot of seriously peeved customers. The question is, do they realize just how annoyed we are?

Design Flaws

Before I go into the problems with Microsoft's handling (or mis-handling) of the DST transition, I suppose I should touch upon some underlying design flaws in Microsoft's products which contributed to the issue, and, admittedly, limited Microsoft's ability to respond to the issue in a timely manner.

• Windows Boxes Tick Local Time - Due to the desktop-centric origins of Microsoft's offerings, the system clocks on Windows boxes tick local time (a design flaw shared by OpenVMS), instead of ticking UTC. Systems which tick UTC instead of local time, such as Unix and related operating systems (including Mac OS X), only have to worry about DST issues in the presentation layer.
• Exchange Calendar Data Stored in UTC - Ordinarily, storing Calendar data in UTC would be a good thing, except that combining this with the aforementioned fact that Windows systems tick local time makes rebasing (correcting Calendar items for changes in DST rules) problematic. This is because differing DST rules may be in effect between the time that the Calendar item is created and the time it is displayed. When the item is created, local time is translated to UTC. When the item is subsequently displayed, UTC is translated to local time, potentially (as in this case) under different DST rules. Remember, when we shift in and out of DST, we don't want the local time of an appointment to change, just the underlying UTC time. If a meeting was at 10:00am before, it should still be at 10:00am after DST kicks in. So why bother with the translation to UTC?
  
• Multiple Timezone Data Fields Associated With Exchange Mailboxes - Exchange Calendar objects have timezone data associated with them. Specifically, there are four timezone fields: OWA timezone, CDO timezone, Outlook timezone, and recurring meeting timezone. ( Please note that if rebasing is performed after the Exchange server is patched, the OWA timezone data is not correctly updated. Unfortunately, this guidance was not provided until fairly late in the process. More on that later.) So, why four fields (not all of which are properly readable by the rebasing tools)? Only a handful of people in Redmond likely know why.
• Windows Stores Only One Set Of DST Rules - Most other operating systems are capable of simultaneously storing multiple sets of DST rules, including specifications of when given rules take effect. This is why most Unix vendors were able to release DST updates shortly after the energy legislation mandating this change was passed in 2005. However, Windows can only store one set of DST rules at any given time, so Microsoft had to wait until after DST ended in the fall of 2006 to release DST patches containing the 2007 rules.
  

Microsoft's Response: Belated and Incoherrant

With these fundamental design flaws out of the way, we can now go on to discuss Microsoft's tardy and uncoordinated response to this issue.

I've already touched upon the reason why Microsoft was unable to release the OS-level DST patch until November of 2006 (well behind other OS vendors), but that is no excuse for the fact that the Exchange patch was not available until January, nor were the rebasing tools available until February, and, as mentioned earlier, the guidance for using them kept changing right on through into March. All of these tools should have been fully completed, debugged, and documented in time for release in November, instead of forcing IT departments all across the nation to go into a last minute scramble to prepare for March 11.

This lack of coordination and preparation raises some troubling questions: were the OS and Exchange engineers even coordinating their efforts? Why were the tools not all released at the same time? Why were they not properly tested, leading to changes in vendor guidance for their deployment at the eleventh hour (after it was too late for most of us)?

Speaking of testing, the Exchange Calendar Update Tool is extremely buggy. Not only does it not reliably correct Calendar items (a weakness shared by the Outlook Update Tool for which it serves as a wrapper), but it does not properly extract all four timezone fields for all users. I wasted nearly two weeks on the phone with Microsoft PSS trying to resolve the 0x80004005 errors that the tool was generating whenever I tried to extract timezone data for the users on my Exchange server, only to eventually learn that the solution was to only attempt to extract timezone info for recurring meetings. In other words, when running msextmz.exe, the msextmz.ini file should always have ExportTimezones set to zero or commented out. Just use the ReadCalendarTimezones value for running in export mode. In other words, don't bother trying to use the tool to correct anything other than recurring meetings.

To top everything off, when the tool runs in update mode, it spawns a new Outlook instance for each mailbox being updated, instead of simply using the underlying MAPI libraries. This to me demonstrates the last-minute approach that was taken in putting this tool together.

A Bad Idea Implemented Badly

Of all of the brilliant ideas that Ben Franklin had, Daylight Saving Time, well, wasn't one of them. Sure, it made sense in a world lit only by fire where candles were precious comodities, but it makes little sense in our modern world of 24 hour lifestyles, not to mention the energy lost having to run air conditioning longer in the hot south.

Congress may have had good intentions when they extended DST in the U.S. Energy Policy Act of 2005, but any energy savings that may have been realized have been more than offset by lost productivity. Businesses, especially their IT departments, have had to put countless projects on hold to address this situation, and Microsoft's late and lackluster efforts in this area have certainly not helped matters.

Note: This article is written primarily from the perpective of an IT administrator. For an end-user viewpoint, take a look at http://www.webware.com/8301-1_109-9689890-2.html?tag=nefd.aof .