As of this morning, we all “sprang forward” an hour, three weeks earlier than we used to, at the direction of Congress. To save energy, Daylight Saving Time was moved up, so we can all save more daylight! Hooray! Saving is good, we should save more.
Seriously though, I’ve had to make adjustments to many of my clients’ computer systems so that they would correctly adjust their own clocks for the new DST changes.
On some old (Fedora Core 2) Linux servers, the change was a manual process, since there are no more patches available for this distribution (i.e. it has reached its “end of life”). More up to date releases, like Fedora Core 4, and Ubuntu 6.06 and later, either had the necessary changes built in, or were just an update command away. Very handy.
On the Windows side of things, it’s a similar story. If you have a current, supported version of Windows, say, 2003 or XP, and you have been running your Automatic Updates, you’re all set. But if you’re running Windows 2000 or Windows NT… hmm… it’s a different story.
Microsoft has provided several methods for adjusting the time zone settings on Windows 2000, which has been in “Extended Support” for nearly two years, there are no automatic updates to make these changes. As Microsoft says on their Extended Support page for Win2k,
“Microsoft is not ending support for Windows 2000. During the Extended Support phase, Microsoft continues to provide security hot fixes and paid support but no longer provides complimentary support options, design change requests, and non-security hotfixes.”
This means you must apply said patches or edit the registry, by hand. Obviously, this is just one more way to gently prod the consumer into purchasing the latest version of Windows, but I won’t go into that right now.
Microsoft provides instructions on how to update your Windows 2000 server in this knowledgebase article, which lists several methods to adjust the time zones. For a single computer, the simplest method seemed to use their new TZEdit tool, so that’s what I did on the handful of Windows 2000 servers I maintain.
Just for kicks, I also ran this tool on the last remaining Windows NT 4.0 server that we still have in production at a client’s location. Note that NT 4.0 is no longer in Extended Support – it’s reached its End of Life. We joke about what this means, and often wonder if we call Microsoft and want to discuss NT 4, if they’ll admit it ever even existed, but I digress. My point is that there is no mention of NT 4 now anywhere with respect to DST. There are no tools from MS on how to adjust its settings, there are no instructions on how to do it. “It’s dead, Jim,” so if you’re running NT 4, you’re on your own.
I decided to try the TZEdit program on this NT 4 box. To my surprise, it ran and seemed to make the changes correctly! Great! I also ran it on all of the Win2k servers.
This morning, I logged on to all of the servers that we maintain to make sure everything looked right. All of the Windows 2003 servers came through without a hitch, and properly adjusted their clocks. The Linux servers did likewise. The NT 4 machine (which, you’ll recall, is completely unsupported) did as well! Great!
Then I looked at the Windows 2000 servers.
The first one still said it was 9:34 AM. My clock said it was 10:34AM. Uh oh. I looked at the second server. Same thing. I logged on to another client location. Same thing. Another client location. Same thing. Not… good.
Basically, the tool appears to not work on any of these machines. Granted, I used the same tool on all of the machines, so if I managed to somehow screw it up, I’d have theoretically replicated the mistake across all of the machines, but this utility is pretty straightforward to use, so what’s the issue? And why on earth did it work on Windows NT 4.0, and NOT on Windows 2000? That is what I want to know.
Furthermore, the Microsoft documentation on this has been terrible. At first, I thought it was just me, but thank goodness that the guys over at Casting From the Server Room had very similar results. Curiously, some of the scripts that worked for us did not work for them, and vice versa, but the sentiments expressed on the MS documenation are mine exactly.
On my own test Exchange server, which has a 200MB message store and a whopping 3 (count ’em, 1,2,3) mailboxes on it, has been running the script to adjust calendar appointments for over two and a half hours now. Unfortunately, I’m apparently not alone, and will be in good company when I manually adjust all of our calendar appointments for each Exchange mailbox individually. Glorious.
Oh, and by the way, that patch for Exchange servers, which came down in Automatic Updates weeks ago? You’re not supposed to install it until AFTER you’ve run the calendar migration utility… “If you install the update that is mentioned in Knowledge Base article 926666 on the Exchange server before you update the mailboxes, recurring meetings that are created in Outlook Web Access are not updated by the Exchange tool. To resolve this problem, remove update 926666, run the Exchange tool, and then reinstall update 926666 on the Exchange server.” Thank you, Microsoft. That’s helpful. Almost as helpful as telling me this BEFORE I installed it, but not quite.