Exchange and Daylight Saving Time—Again!

I didn't intend to write about updating Exchange for the daylight saving time (DST) change again this week, but there's still so much confusion around it that I wanted to share some problems—and solutions—experienced by early adopters of Microsoft's update strategy. Of course, "early" in this context is relative; as I write this, there are about 19 days until DST goes into effect, and that's not a lot of time considering that nearly every Windows client in North America needs to be patched.

First, many users have reported problems after installing the DST patch for Exchange. There are two primary problems: not being able to mount mailbox stores after the patch is applied and losing permissions on shared mailboxes. The problem of mounting mailbox stores is caused by ambiguous SIDs on the object in the msExchMasterAccountSID attribute or in the sIDHistory attribute. The fix for this class of problems is detailed in the Microsoft article "Information Store database does not mount with Event ID 9519 and 9518." The problem with permissions on shared mailboxes is usually due to what I call the BlackBerry Effect; applying any hotfix later than release 7650.23 to the store will cause a change in the way shared permissions are evaluated (see "Permission Changes Surprise Mobile Device Administrators," May 9, 2006). Some sites haven't applied any hotfixes since before May 2006 when this fix was released, and now they're running into problems.

Second, if you're using resource mailboxes, apparently the Exchange Time Zone Update tool makes a big mess. Neither the Auto Accept Agent nor direct-booked Outlook resources will correctly accept meeting updates generated by the tool. Microsoft is aware of the problem and lists some workarounds on the Microsoft Exchange Team Blog. For now, if you're using resource mailboxes, you should probably hold off on running the Exchange or Outlook update tools.

Third, it's still a good idea to take precautionary measures such as updating your meeting subject or location fields with the correct start time. Doing so is a hassle, and you shouldn't have to do it—but better to prepare now than regret it later!

Fourth, Microsoft started distributing the DST patch for Windows through Windows Update and Microsoft Update on February 13. Apple started pushing its own client DST patch last week as well. However, you're still on your own for updating Windows Mobile clients; versions prior to Windows Mobile 6.0 don't include an automatic update mechanism.

Finally, a couple of astute readers asked why Microsoft waited so long to get out a fix for this problem; after all, the company has known the DST changeover was coming. I don't have a good answer for that. None of the Microsoft product teams involved—Windows, Exchange, and Outlook—have done a good job of clearly communicating what needs to be done. I say this despite the flood of information that Microsoft's been issuing—primarily because they keep changing or extending their guidance. (If it's any consolation, lots of other companies are having similar problems.) Thank goodness this change isn't likely to repeat itself any time soon. The upheaval does give ammunition to the swelling number of people who have been arguing that DST should be abolished altogether.