Managing Daylight Saving Time (DST) changes in Exchange Server and Microsoft Outlook

By now it's become almost impossible not to have heard about the upcoming changes to Daylight Saving Time (DST) (yes, that's Saving, not Savings). If you're an IT pro, and especially if you're responsible for Exchange Server administration, you've probably reacted to all the news by reaching for the nearest bottle of Excedrin.

Not only does all this mean changes to the way Windows Server and Exchange Server operate, it also means changes to how scheduled events are stored in Exchange Server. Worse, the DST changes won't be automatically reflected in users' calendars -- they have to be adjusted manually.

The changes will most specifically affect anything that's been scheduled to fall between March 11, 2007 to April 1, 2007 and October 28, 2007 to November 4, 2007. (Of course, this doesn't count changes to events that have been scheduled for future years.)

Microsoft's response to this whole situation has been somewhat scattershot, since there's really no one utility a person can download to fix everything at once. Redmond's approach has been to deal with the problem in three discrete ways: the operating system level, the individual product level, and the application data level.

To that end, Microsoft has put together a Web page, Preparing for Daylight Saving Time changes in 2007, where it documents these issues. It's worth reading from top to bottom -- even if the level of detail may make your eyes glaze over!

While I can't spare you the trouble of having to read the document for yourself, here is a synopsis of the important issues as they pertain to Exchange Server and Microsoft Outlook.

The operating system level

The most important way the DST changes affect Windows itself is in the changes to the time zone definitions supplied with the operating system (OS). Windows Vista has already shipped with the appropriate changes, but Windows XP Service Pack 2, Windows Server 2003 and Windows Server 2003 SP1 (as well as several other Windows-derived products) all need to be updated.

These changes have been published as updates for Windows, as described in Knowledge Base article 931836, February 2007 cumulative time zone update for Microsoft Windows operating systems. (The update also includes rollups for many other individual time-zone update issues released previously.)

Some things to keep in mind:

• If you're using legacy or unsupported versions of Windows -- such as Windows 2000, Windows XP SP1 and Windows NT 4 -- there are no time-zone fixes available from Microsoft for these products. However, there are unofficial third-party fixes available, which allow manual updating of the time-zone information in unsupported Windows products.

• An earlier version of the Windows time-zone updates was made available at one point, via Knowledge Base article 924840, A test version of the 2007 global time zone update for Windows is available. If this update is present, it must be removed before being replaced with the production version.

• If DST definitions have already been applied to a given computer, there's a good chance any appointments booked from that computer may need to be selectively excluded from being modified. See the next section for more details.

The application level and the data level

Many individual products are affected by the DST change. But for the sake of this tip, we'll deal with the two most important ones to Exchange Server administrators: Exchange Server and Microsoft Outlook.

In most every case, you'll need to apply the update for Daylight Saving Time changes in 2007 for Exchange 2003 Service Pack 2, which addresses the way Exchange Server handles time zones.

But what about Microsoft Outlook appointments that fall within the affected time zones? There are two basic ways to handle that problem: fix it through Exchange Server administratively or let users fix it through Microsoft Outlook.

To make the changes through Exchange Server, Microsoft produced the Exchange Calendar Update Tool to automatically fix affected appointments across a whole organization. However, the Exchange Calendar Update (ECU) tool also has some quirks (shilling for bugs) of its own that you need to be area of:

• The ECU tool isn't run on the Exchange server itself, or on a system that has Exchange Server Manager running. This is the single biggest and most confusing thing about it. Most people assume it has to be run on the Exchange server. But what you need to do is pick a workstation that has Microsoft Outlook installed on it and run it from there, because it uses Microsoft Outlook's libraries to perform the changes.

  (You can't run an instance of Microsoft Outlook on an Exchange server, because both programs use different implementations of the same .DLLs. As such, they cannot be run side by side.)

• A note in the README.TXT for the file indicates that the program won't work if it's installed to the default directory -- C:\Program Files\MSEXTMZ. To get it to work, install it in another directory, such as C:\MSEXTMZ.

• Once installed, don't run the program that's in the directory to which you've installed it. The real program is stored in a completely different directory. Look in \Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool for tzmove.exe. (Note that the exact Office directory will vary depending on what version of Microsoft Office is installed.)

• The Exchange Calendar Update tool is single-threaded and may take a very long time to run in a large organization. To that end, it should be run during off-peak hours. It's also possible to run the ECU tool on multiple machines in parallel, with each machine only dealing with a specific user group; instructions on how to do this come with the tool itself.

• There's a chance that the tool may not deal properly with single-instance appointments, since such appointments have no time zone information. If a given user's installation of Windows was patched with the new DST definitions, and he then created single-instance appointments in his calendar after that, those appointments will be modified incorrectly. This is yet another reason why it's a good idea to make all the DST changes at once in a pre-allocated block of time.

• It's also probably a good idea to run off a full backup of the Exchange database before attempting to use the ECU tool.

The other approach to fixing calendar data is to let users make changes to their own calendars through the Outlook Time Zone Update Tool. This works best when you have a small and technically savvy set of users who can get hands-on guidance for how to use the tool, since it allows for much more selective changes to be made.

This approach also works best for people who have portable devices that will also need to have their calendars patched.

Finally, those who have started to deploy Outlook 2007 don't need to use the Outlook Time Zone Update Tool to make these changes, but the tool does grant more flexibility in making the changes than Outlook2007 itself.

DST via virtual machine

If you don't want to run the Exchange Calendar Update Tool on an existing machine, Microsoft has a slick workaround. You can download a virtual machine for the Microsoft Calendar Update Tool.

It contains an instance of Windows Server 2003, onto which you can install Microsoft Outlook and then run the Exchange Calendar Update Tool. (I haven't confirmed this, but I suspect the installed copy of Microsoft Outlook does not need to be activated to run the tool properly, so you can save yourself a desktop license.)

Note that the virtual machine will need to be formally joined to the domain before you can run the changes; and, you'll need to be running Virtual PC or Virtual Server somewhere in order for this to work.

Conclusion

There are few ways to anticipate a change this broad, even though the changes have been at least a year or more in the offing. One of the most important guidelines to follow when applying these fixes is to apply them all, top-to-bottom, in the shortest possible span of time.

In other words, do them all at once -- OS, application and data, in that order -- or not at all. Otherwise, you'll be facing even greater problems introduced due to mismatches between the operating system's time-zone data and the time-zone information in Exchange Server's appointments, and so on.

Do you have comments on this tip? Let us know.

About the author: Serdar Yegulalp is editor of Windows Insight, a newsletter devoted to hints, tips, tricks, news and goodies for all flavors of Windows users.

Related information from SearchExchange.com: