We’re down to less than a week to go.  Are your systems ready for the revised Daylight Saving Time (DST)?  Ours are, we think.  But who knows?  We are as prepared as can be, but mostly we’re at the mercy of our many vendors to tell us how their applications were written to handle date and time functions.  We’ve been ramping up for the time change over the last few months, and we’ll find out this weekend if the efforts paid off.  I suspect it will largely be a non-event.

Due diligence is required.  With little in-house development, our main course of action has been divvying up applications and verifying DST processes with respective vendors.  In most cases, thankfully, applications utilize the Operating System time zone information so patching the OS has been all that is required for many.   This meant most patching was applied to Microsoft platforms, but also included various UNIX flavors, Linux, network appliances and handheld devices.

Application grids were created to ensure no systems were missed.  Phone calls made, emails sent, web sites checked.  System downtimes scheduled for patching and reboots.  It’s been a fairly significant effort.  Here’s hoping the government decides it was all worth it and no further changes are necessary.

Microsoft.  Ah, Microsoft.  Most of my time has been spent with the mighty vendor from the West.  They were kind enough to distribute the OS fix via Windows Update for their most recent releases – Windows Server 2003 with SP 1 and Windows XP with SP 2.  (Vista was released with the correct time zone information.)  The problem, of course, is that most large enterprise environments still have a fair number of applications hosted on legacy Windows releases – Windows 2000 in particular and even a few NT 4.0 systems.  No worries.  Last year they found it in their hearts to offer a patch for the older Windows releases for a mere $40,000.  Luckily, there was the expected outcry from many customers and the price tag was cut to only $4,000.

Microsoft has a subtle way of nudging their customers, the public, other vendors and even competitors in the direction it wants them to go.  Don’t think for a second that Microsoft was doing us any favors by releasing a patch at a reduced price.  They should have done it as part of good public relations.  They would have done just that very thing 10 or 20 years ago.  No, the point was made by affixing a price to a required update and not making it available for download or as part of their automated patch services – the product support horizon is being progressively reduced with each new software release.  It’s in an administrator’s best interest to reduce the amount of time between upgrades for instances just like this DST issue.  Got the message?

We didn’t pay for the patch.  I doubt that many other customers did either.  It turned out that the time zone settings could be corrected through a manual Registry edit or by using the free Microsoft tool, tzedit.exe, to correct individual systems.  We found a third-party tool for a few hundred dollars that took a comma delimited list of host names and then checked for the correct values and patched if needed.  The convenience alone was worth that.  In a few days, the vast majority of our Windows servers and clients were patched.  No reboot was supposedly required, but we’ve found some instances where the opposite is true, especially if Java is present.

Our messaging environment required the most coordinated effort.  Patching Exchange was a multi-part affair that would require a separate lengthy post to delve into with much detail.  The process left a lot to be desired and I got the distinct impression that Microsoft representatives weren’t exactly on the same page when it came down to what the customer should expect.  The crux was that each user mailbox had to be logged into (via an automated tool or individually) and Calendar entries updated.  Meetings with a Meeting Organizer required meeting update requests be sent to all attendees.  Special consideration had to be given to Resource Mailboxes.  User confusion ensued but was tempered by much communication before the process began. 

Depending on which Microsoft tech support person we spoke to or which DST webcast we attended, each single instance of the tool (tzmove.exe) could process between 5 and 12 mailboxes per minute and the process may or may not significantly affect Exchange server performance.  We ran 4 instances of the Exchange Calendar Update tool during primary business hours without taking a noticeable performance hit and registered a healthy 13.5 mailboxes per minute per instance.  We noticed some odd behavior such as disabled user accounts sending out meeting updates but not appearing in their Sent Items folder, but all told it was more successful than expected.

That’s it.  We’re as ready as we’ll ever be.  I think the time change on March 11 will be a non-event.  How about you?  How much effort have you spent preparing for the revised DST?  Are you ready?