Daylight Saving Glitch an Exchange Bugbear Microsoft Exchange Deals with Early DST Andy Patrizio
Microsoft Exchange administrators might be losing more than one hour of sleep this weekend as a result of the early Daylight Saving Time. But Microsoft says things are going according to plan.
Daylight saving time begins on the second Sunday of March this year, rather than the first Sunday in April; it will end on the first Sunday in November instead of the last Sunday of October.
This is an Exchange problem because daylight saving time changes are programmed into systems' internal clocks, and those developed before the 2005 law have the wrong dates in them. Therefore, old hardware and operating systems are still operating on the April/October date change rather than March/November.
Info-Tech Research Group is reporting that a number of Exchange customers are realizing that the fixes for Exchange aren't going very well.
Last year, Microsoft released the original version of its Exchange date update tool, tzmove.exe, but the update didn't address resource calendars or public folders, according to Darin Stahl, research team lead at Info-Tech.
Microsoft issued a hotfix in mid-February, which was successful, but not every administrator may have realized the problem. If they ran tzmove.exe before the hotfix, then their systems may not be fully up to date.
As a result, companies that ran tzmove.exe and thought they were done might be in for a surprise come Monday.
"There's a number of users who thought they were good to go and were not aware that a new version had been released. This was a tool that should have been refined and functioned on all calendar items last November, not 20 days ago," Stahl told internetnews.com.
In its defense, Microsoft simply said it was an improvement and not a fix to tzmove.exe. "We exposed additional functionality of the tool so that people could go ahead and rebase public folders. So I think we enhanced it rather than fixed a problem," said M3 Sweatt, chief of staff for the Windows core operating system at Microsoft.
Sweatt added that the original release of tzmove didn't perform to Microsoft's satisfaction, so the revision also improved performance.
He said he's been holding weekly webcasts to discuss the DST change since January. Crowds measured 1,500 or more initially, but the most recent Webcast was down to 60 people, which he interpreted to mean most administrators have gotten over the hump and applied the fixes.
Stahl also noted there are some problems with Microsoft's documentation. There are three separate fixes for the time change for Windows Server OS, Exchange, and Outlook, and they have to be done in a particular order. Knowledge Base entry 930879 has the proper order, but 931667 has them out of order.
Stahl didn't fault Microsoft for that, though. "Microsoft is a large company with lots of documents with lots of people weaving it all together. It's amazing they keep it all together," he said.
This alert has led to some hyperbole and inevitable comparisons to the Y2K bug (define). However, it's nowhere near an apples-to-apples comparison, as this is a fix anyone can make. All a person needs to do is apply the patches from the vendors, or at worst alter their system clock manually. It's not like sifting through millions of lines of code to make date changes.
However, there is the real risk of business damage, and liabilities could occur from applications performing their processing at the incorrect time, the company wrote. It went on to say that patches for major operating systems and other infrastructure components appear to be readily available.
Windows Vista and Office 2007 already programmed the adjustment, but Office 2003 and prior versions, as well as Windows XP and older operating systems, do not have this fix. The Office 2003/XP and Windows XP fixes were made available last month as part of Patch Tuesday.
Gartner has sent out an advisory to its clients not to downplay the risk. "Few IT organizations have any formalized risk assessment and remediation program in place to address the potential impact of this time modification," it wrote.
"Because code changes will usually not be required and most applications take their time from the underlying operating system (and hence only this needs to be patched), the overall remediation effort will pale in comparison to that of Y2K," concluded the Gartner report.
Most of the major computing companies are also on the ball in getting fixes out. Sun Microsystems (Quote) has a Web page set up as a central repository for its fixes to Solaris 8, 9 and 10.
HP (Quote) also has an information page set up for its customers, and Novell (Quote) has a page featuring its ZENworks patch management software.
