Exchange and Daylight Saving Time, Part 2

Last week, I wrote about the upcoming change to start and end dates for daylight saving time (DST) in the United States and Canada, including some effects this transition will have on Exchange Server administrators ("Exchange and Daylight Saving Time, Part 1," February 8, 2007). I focused primarily on how to update the OS and server applications you use; this week I'll focus on the client and mailbox changes you'll need to make.

Let's look at which clients are affected by the DST change:

Exchange doesn't store a time zone with single appointments (i.e., ordinary, nonrecurring appointments). Instead, the appointment time is stored using Coordinated Universal Time (UTC), and the local time of the appointment is calculated using the time zone of the computer in which the appointment was created. Therefore, it's difficult to adjust the time of these appointments automatically during a time change.

There are two basic ways that you can update users' calendar data:

You can set both tools to modify either all appointments in the DST gap or only recurring appointments. No matter what you do, Microsoft recommends that you take precautionary measures such as printing out your weekly calendar for the gap period and updating your meeting location or subjects with the correct start time—all before you install any of the patches or run the time zone update tools.

The Exchange tool is single-threaded, so it will take the tool a long time to update large numbers of users. Microsoft has helpfully created a prepackaged virtual machine (VM) with the Exchange tool, which you can download from Microsoft's Web site. You can install several instances of the VM and process many appointments at the same time. In Microsoft's internal pilot of its DST update process, the company found that to update its 130,000 clients in a three-day period, it would need to run 10 instances of the VM, each averaging about 2.9 mailboxes per minute. You can read about Microsoft's pilot in "Exchange Time Zone Update Tool: Guidance from Microsoft IT." Because most of us have much smaller environments than Microsoft does, you can probably get by with fewer VM instances.

Of course, there's a third alternative for updating users' calendar data: Do nothing, and let your users clean up their calendars themselves. This is probably going to happen at many smaller organizations, but I don't expect it to be a popular choice given the disruption of work it could cause.

However, if you’re going to update your users’ data, it’s critical that you do two things: Update all your clients, including Windows Mobile devices, to ensure that an unpatched client doesn’t set appointment times back to their original, non-2007-DST values; and update the clients as soon as possible after updating the servers but before you adjust appointment times to reduce the risk that users will create appointments with a mix of patched and unpatched clients.

In addition to carefully reviewing Microsoft’s DST documentation, your best bet is to start alerting your users now to, as Microsoft puts it, "Consider any calendar items in the extended DST period to be suspect. If you are not sure, verify the correct time with the organizer." That's good advice—but don't be surprised if you find me an hour late (or early) for meetings!