As we head closer to March 11, which is when the extended Daylight Savings Time kicks in - 3 weeks earlier this time, thanks to the Energy Policy Act, here are answers to some more commonly asked questions.
This is not meant to be a comprehensive guide to DST 2007 (at least as of writing) - I have not covered details of how to run the Exchange Calendar Update Tool (MsExTmz.exe) in this post. The tool is covered quite well by Microsoft KnowledgeBase articles, in particular
KB 930879: How to address daylight saving time by using the Exchange Calendar Update Tool, and posts on the Exchange team blog.
Microsoft has updated its guidance in the past few days, and the relevant Microsoft KB articles have been updated accordingly. Keep an eye on the date and versions of the KBAs you refer to. These now include a change log as well - thanks to the folks who thought of including this within the KBA for this time-sensitive issue.
In this post, I’ll talk about the relevant patches/updates and the tools made available by Microsoft. I’ll also take a look at how time works, how appointments are booked, what rebasing does, what specifically needs to be updated, and then go through the order of doing things. Needless to say, the exact order of doing things has many folks in different states of confusion, and as I write the guidance on that appears to have been locked in.
- Through the rest of this post, I will refer to calendar items as
appointments - these can either be appointments created for yourself, or meetings where you invite others.
- I will also use the term
Microsoft Outlook Calendar Update Tool to refer to the Time Zone Data Update tool for Microsoft Office Outlook, and once again request the marketing folks and product groups at Microsoft to coin names that are no longer than 2-3 words (4 words being the hard limit... :) -
you could see the March 11 deadline for DST 2007 fly by you in the time it takes to say the Microsoft name for this tool.
1. KB 931836: February 2007 Cumulative Time Zone Update for Microsoft Windows operating systems:
What this does:
Updates time zone information/rules in the Windows operating system. Windows stores time zone information in the registry. This updates those time zones, and tells the OS when the extended DST time will start and end in 2007 (amongst other things).
Operating Systems: Windows Server 2003, and Windows XP SP2.
What about Windows 2000 and Windows XP prior to SP2: These OSes are no longer in active support. Refer to
KB 914387 - basically you'll have to hack the registry to update these OSes with DST 2007 time zone info.
2. Exchange Server CDO Patch: Exchange Servers have CDO installed. This is used by apps that use CDO - like OWA for instance, to perform functions like creating appointments. Third-party applications like RIM's BlackBerry Enterprise Server also use CDO.
CDO has timezone information embedded in it. As such, it is important to update CDO on Exchange servers. There are 2 versions of the CDO patch available:
KB 926666: Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 2
KB 931978: Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 1
Note: Computers running Exchange System Management Tools also have CDO installed, as do app servers like RIM's BlackBerry Enterprise Server (BES). These need to be updated as well.What about Exchange Server 2007? This is the latest version of Exchange, and it does not require any CDO updates. However, appointments in mailboxes on Exchange Server 2007 servers created using the old DST 2006 time zone rules will need to be rebased.
What about "legacy" Exchange versions, like Exchange 2000 for instance? These versions are not in active support as of now. You should contact your Microsoft Technical Account Manager (TAM)/rep to obtain any support or patches. Yes, there may be costs involved, and it's not the purpose of this post to delve into that, but I have commented about it in an earlier post. Apart from the CDO patch, appointments in mailboxes on these servers will also need to be rebased using either the Outlook or Exchange Calendar Update Tool.
3)
The Tools: There are two tools made available by Microsoft.
i)
Microsoft Outlook Calendar Update Tool/Time Zone Update Tool for Microsoft Outlook (
TZMOVE.EXE): This is the tool that can be used by end-users to rebase their own appointments. We will get into rebasing in a moment.
Downloads: 1)
Outlook Calendar Update Tool 2)
Update: Hotfix for the Outlook Calendar Update Tool (KB 933146, Revision 1.1, Feb. 28, 2007). Allows
force rebasing, rebasing Direct Booking resource mailboxes and Public Folders. Creates an item modification log.
ii)
Microsoft Exchange Calendar Update Tool (MsExTmz.exe): This is the tool that can be run by administrators to rebase appointments for a bunch of mailboxes. It's important to note that you shouldn't install this tool on your Exchange servers, nor on computers running Exchange System Management Tools. It requires Outlook to be installed on the computer you run this from. The tool is a
wrapper around the client tool TZMOVE.EXE - it calls TZMOVE and updates users' calendars as if they were running the client tool themselves, minus the UI that clients see which allows them to pick and choose which appointments to update.
Download:
Microsoft Exchange Calendar Update Tool v2.0 (date: 2/21/2007, all of 253 Kb)
When you download the Exchange Calendar Update Tool, there's an
automated configuration tool called MsExTmzCfg.exe that is also part of the package. What does this do? It walks you through the steps of extracting time zone information from mailboxes and creating the appropriate input files for the update tool to run. You can do without this one and configure everything manually, but this just makes it a lot easier, so it makes sense to use it.
How Time Works!Now let's take a look at how time works, and the problem at hand.
-
Time Zone definitions in registry: As noted earlier, time zone definitions, including details like when Daylight Savings Time (DST) will start and end, is stored in the registry.
-
Coordinated Universal Time: Most time related stuff is done using what is known as Coordinated Universal Time or UTC.
(No, the abbreviation is not CUT, and you can use any web search tools to find out why.... as a sidenote, this was formerly known as Greenwich Mean Time or GMT - both refer to the same time at longitude zero. The U.S. Naval Obeservatory site has more info on UT1, UTC and GMT. Not to veer too off-topic, UTC is not supposed to differ from UT1 by more than 0.9 seconds. For the purpose of this discussion, let's treat them as the same given the negligible difference.). Time servers that use protocols like
Network Time Protocol (NTP) use this notion of a universal time that everyone and their computers can sync their clocks to.
-
My Time Zone offset from UTC: Computers calculate local time as an offset to the UTC time, which can be trusted to be always accurate, regardless of what time zone you're in at the moment. UTC will remain the same.
If you remember setting up a Windows client or server OS, you may be familiar with the locale and time zone questions asked during setup. You can also view this by double-clicking the Windows clock and selecting the Time Zone tab. My time zone is Pacific Time, which during non-DST hours uses an offset of -8:00 from UTC. This means when the UTC time is 8:00 AM, my time is 8:00 AM - 8 hours = 12:00 AM (midnight).
Creating Appointments in Microsoft OutlookWhen you create an appointment in Microsoft Outlook, it is
created using UTC, which is calculated using the Time Zone information in the registry that would be in effect during that time (
e.g. 4:30 PM PST = 4:30 + 8:00 time zone offset = 12:30 A.M. UTC). Before 2007, we have been used to seeing Windows update its time automatically when the time zone rules change - twice a year, as it will this year as well.
Recurring and Single-Instance Appointments: There are two types of appointments as far as Outlook is concerned - those that occur only once, also known as
Single-Instance appointments, and those that occur regularly - let's say every week, starting from a particular date and ending on a particular date, called
Recurring appointments. Versions of Microsoft Outlook prior to Outlook 2007 have handled these differently.
-
Recurring Appointments save the time zone information within the appointment. This makes it much easier to figure out which time zone rules (DST 2006 or DST 2007 for instance) were used to create those appointments.
- Single Instance Appointments: These appointments, which only occur once, do not have any time zone information saved in them.
Additionally, it's important to note that as stated earlier, all time stuff works (or should work) based on UTC time. Both recurring and single-instance appointments are saved using UTC time.
The following screenshot shows MAPI properties of a recurring meeting that occurs at
4:30 PM PDT on March 12th. As you can see, the start and end times are UTC - 12:30 AM - 1:00 AM on March 13th! Single-instance meetings look somewhat similar - besides the recurrence, they don't have the TimeZone saved in the item as recurring meetings do.
How Outlook renders an appointment on your Calendar: When you view a Calendar in Microsoft Outlook, it looks at an appointment's Start and End times - and as the screenshot above shows, those are in UTC. It then looks up the time zone information from the registry of your computer, and determines your time zone's offset from UTC - let's say UTC -8:00, and renders the appointment at 4:30 PM on your Calendar. This allows folks from different time zones to schedule meetings with each other, and ensure those meetings show up at the correct local times in their time zone, not at 4:30 PM for everyone.
Dealing with DST: If the appointment were to occur at 2:00 PM during normal DST hours - which used to start on the first Sunday in April, Outlook would look up the DST rules in registry and be able to determine that. As a result, it would still show the appointment at 2:00 PM on that date - it would know that come first Sunday in April, the time zone offset from UTC would be -7:00 and not -8:00.
The good part is, we are used to dealing with this change every year, so it's not something unknown, like the Y2K bug. Further, it's not really a software bug as such - at some point the United States Congress decided it was a good idea to move the clock forward by one hour (i.e.
UTC -7:00 for those in Pacific time zone, known as Pacific Daylight Time)
three weeks ahead of time (and also move the clock backward by one hour - i.e. UTC -8:00 for Pacific time zone, known as Pacific Standard Time - a week later than usual), so we have more daylight and hopefully we'll end up using less energy. All well-intentioned stuff, I'm sure. What IT folks would have to go through to make this transition wasn't something that was on their minds at that point. :)
DST 2007: So, come March 11th, we will move our clocks forward by an hour. The Pacific Daylight Time, which would have otherwise started on April 1st this year, will start on March 11th instead. Similarly, it will end a week later - on November 4th this year, instead of October 28th. What are the implications of this?
1.
Tell Windows operating sytems about this change occurring 3 weeks sooner and ending a week later. This is what the Feb. 2007 Cumulative Time Zone Update does, for Windows Server 2003, and for client operating systems like Windows XP SP2.
2.
Rebasing Appointments: With the above in place, we should be OK, shouldn't we? Well, not really! This will work for all new appointments that we create using Outlook, but it does nothing for the existing appointments that we've already created using the DST 2006 rules, which assume DST will start on the first Sunday in April, as usual.
We will need to go back to all our appointments we created in our Calendars, and update them with this change. This process is called "
rebasing".
In the above instance, (before rebasing) our appointment at 4:30 PM on 3/12 had a start time of
12:30 AM to 1:00 AM UTC on 3/13. Using DST 2006 rules, that would be rendered using UTC -8:00, and show up at 4:30 PM. However, after updating our computer's time zone for DST 2007, we would be at DST -7:00 on March 11, and the appointment would've been rendered at 5:30 PM instead. The following screenshot shows how rebasing the appointment adjusts the start and end times so it gets rendered correctly - the start and end times were
changed to 11:30 PM on 3/12 and 12:00 AM (midnight) on 3/13 - UTC.
Let's take a look at what appointments will look like when created from a computer that has (old) DST 2006 rules, and how they will be rendered by Outlook once you do apply KB 931836 DST 2007 time zone update to the OS.
Click here to see the complete image if it's cut-off.As you can see, appointments created on a computer with the old rules appear an hour behind on the computer with DST 2007 time zone rules.
After rebasing these appointments, here's how Outlook will render them:
Click here to see the complete image if it's cut-off.The reverse is true
if appointments are created by users with new DST 2007 rules, but are viewed by meeting invitees or the organizer on computers with old DST 2006 rules.
Let's walk through the rebasing process and the impact it has. We will use the Outlook Calendar Update Tool (TZMOVE.EXE) for this exercise - the Exchange Calendar Update Tool also calls this client tool to actually perform the updates.
1. Install TZMOVE.EXE on a computer with DST 2007 time zone update (KB 931836) applied
2. TZMOVE finds appointments.
Notes:
-
Recurring meeting using new DST 2007 time zone at 12:00 PM does not get picked up by the tool - recurring meetings have time zone info embedded, the 12:00 PM meeting was created using the correct DST 2007 time zone.
- The old recurring meeting created using DST 2006 time zone does get picked up, and will get rebased.
- The
single-instance meeting at 9:00 AM created using DST 2007 rules also gets picked up and rebased! How long should you wait before applying the DST 2007 time zone update to all client computers and rebasing appointments. If you wait too long, here's what could happen - clients will inadvertently end up creating new appointments in the affected extended DST period using the new DST 2007 rules. When you rebase, these appointments get rebased as well. Here's what this could look like after rebasing:
Click here to see the complete image if it's cut-off.Update: The Outlook Calendar Update Tool can be patched with a new hotfix (KB 933146) discussed earlier in this post. The patched tool can then detect when the OS was updated with DST 2007 time zone info and only rebases appointments after that time, using the /ONLYCREATEDPREPATCH command line parameter. Alternatively, only appointments created before a certain date & time - expressed in UTC - can be rebased, using the /ONLYCREATEDPREPATCH:(utc time here) command line parameter.The
take aways from this:
1) Once new time zone rules are applied on client computers, we will need to rebase the old appointments so they are rendered in the correct time slot by Outlook.
2) Any new appointments created on an updated computer (with DST 2007 rules)
should not be rebased
3) To avoid #2, it's best to
rebase appointments as soon as users get the DST 2007 time zone update applied on their computers (else they may create new appointments using new DST 2007 rules before rebasing is done, which may result in the newer appointments being rebased wrongly!)4) As seen in the above examples,
simply having users insert the correct time in the meeting subject makes these appointments stand out if they're off by an hour or two - if possible, have your users do this. It will be of great help in getting through this process.
5) Going a step forward,
at least for important users like execs, have their assitants or the users themselves print out their calendars for this extended DST period (3 weeks from March 11 to April 1, hopefully you would have worked out the kinks by the time you get to the end of the DST period in the last week of October.
Which items will we rebase? Appointments created using old DST 2006 rules that occur during this "extended" DST period, which is the 3-week period prior to the first Sunday in April (i.e. March 11 - April 1), and the 1-week period between the last Sunday in October to the first Sunday in November (October 28th - November 4th).
Where do these items reside?1) The
default Calendar folder in user mailboxes on Exchange Server
2) Other "non-default" Calendar folders or sub-folders in user mailboxes
3) Perhaps in
PST files, if users use them. Important to note that Exchange knows nothing about content in your PST files.
4) In
Public Folders, if you have created any to store appointments.
5)
Resource Mailboxes: Resource mailboxes are mailbox-enabled user accounts created for booking resources like conference rooms, projectors, et al. These are set up to be booked automatically when users
invite them to meetings as resources. When rebasing appointments, if a resource is booked back-to-back, the rebased appointments will conflict with other appointments on the calendar through the rebasing process. It makes sense to configure them to accept these conflicts during the rebasing process.
There are two ways resource mailboxes can be setup:
-
Direct Booking: If using Direct Booking, an admin logs into a resource mailbox using Microsoft Outlook, and sets it up to a) Accept meetings automatically and b) automatically decline conflicting meeting requests. During rebasing, we should configure resource mailboxes to not decline conflicting meeting requests, by unchecking the latter, as shown below:
The patched
(with hotfix in KB 933146) Outlook Calendar Update Tool (TZMOVE.EXE) should be run using the
/FORCEREBASESUPPRESSALLUPDATES command line parameter against resource mailboxes that are configured for Direct Booking. Once rebased, you can revert the resource mailbox configuration to decline conflicting meeting requests.
-
Using the Auto-Accept Agent: The
Auto-Accept Agent is an add-on server-side tool that Microsoft released as a web download after the release of Exchange Server 2003. Unlike using Direct Booking (as shown above), which uses the resource's Free/Busy information, the Auto-Accept Agent actually looks up the resource mailbox' Calendar to determine if a resource is available or not. It also has additional functionality like stripping attachments, dropping non-calendar items, amongst other things. The Auto-Accept Agent uses an xml file for configuration - AutoAccept.config.xml. By default, this resides in \Exhsrvr\Agents\AutoAccept.
The patched Outlook Calendar Update Tool (TZMOVE.EXE) should be run using the
/FORCEREBASESUPPRESSALLUPDATES command line parameter against resource mailboxes that are registered with the Auto-Accept Agent.
3.
Updating Exchange Servers: Next, we will need to go and update our Exchange Servers. They will need the new time zone update rules for Windows Server OS (KB 931836), and the Exchange CDO patch - depending on the version of Exchange Server you're on (KB 926666 for Exchange 2003 SP2, KB 931978 for Exchange 2003 SP1, and as stated earlier - patches for any previous versions of Exchange that may be in use in your organization, if you 've obtained them from Microsoft).
The Order!Having talked about the issues, and I hope you understand them by now, let's take a look at the order of doing things. The guidance related to this has evolved and changed over the past few weeks and days. With that in mind, let's look at the order that Microsoft recommends we make these changes in, going by the recent guidance.
1.
Update Windows Servers (update: including Exchange servers) and Windows client operating systems with the February 2007 Cumulative Time Zone Update (KB 931836 for Windows Server 2003 and Windows XP SP2).
2.
Rebase Appointments3.
Exchange Servers: Apply the Exchange CDO patch to update the time zone embedded in the CDO components on Exchange servers (KB 926666 for Exchange Server 2003 SP2, KB 931978 for Exchange Server 2003 SP1)
Labels: Administration, DST 2007, Mailbox, Microsoft, Outlook, Tools
Exchangepedia Blog is read by visitors from all 50 US States and 150 countries world-wide
Permalink
0 Comments Post a comment
links to this post
I've been wanting to post about this for a few days now, and as we wind down towards the earlier onset of Daylight Savings Time this year, hopefully with most of us having dealt with DST 2007 issues already, there couldn't be a better time than this. If you haven't reached the finish line with your DST 2007 efforts yet, look at it as inspiration to get it done within the next 36 hours or so!
