Blog Entry

Here we go again. This year some of the Australia territories decided to change the end of their DST periods by one week.  We are currently planning on how we tackle this.  We have 2 basic choices and some variations on the theme - do the same as we did for the US or the same as we did for New Zealand.  To summarize the options that we are looking at:

Option 1

For the recent New Zealand DST changes we worked with OMNI to get a blanket license for their Riva product and a custom build DST module.  This module attached to each mailbox and inserted a search folder with a fixed set of criteria.  Basically it searched for all SENT appointments in the mailbox that fell inside of those extra weeks of DST.  The user could then go to this folder and selectively resend those appointments that needed resending.

There are a couple of modifications that we can make to the query:

Option 2

Same as #1 except it will show both SENT and RECEIVED appointments and users are given instructions to only move the ones they SENT and notify the other senders to resend theirs

Option 3

Same as #1 except if you know that all workstations were patched on the same day that you can give this date as an extra parameter and the search folder will only display appointments SENT or RECEIVED before that date.  This has an additional benefit - as other senders resend their appointments they 'disappear' from the search results.

The downsides of all 3 of these options are the same.

1.  Users need to check ALL the appointments to see if they are accurate

2.  As a sender resends their appointments the search folder will either double up on the sent items, or will not show the newly sent item (for #3)

If we chose one of these options then we will likely do it in GWCheck instead of licensing Omni's RIVA again.  We have enough lead time and a release vehicle in SP3.

Option 4

We do another version of GWCheck, like we did for the US change.  This GWCheck can look at the Timezone definition on any appointment, sent or received.  If the Timezone definition is incorrect then the GWCheck will intelligently move the appointment to the correct time and place a hidden flag on the item.  If the timezone information is missing or correct then the appointment is not moved.  The details escape me on this last point, but those that were not moved had a different hidden flag applied - the part I can't remember was if it was just those that had missing timezone information, or all.

It then created 2 search folders that searched on the hidden flags - one you show users what was moved, and one to show them what was not, so that they could selectively resend them.

The Timezone information is placed on any appointment created with the latest Windows client (6.5.6 and newer I seem to remember), the latest Linux/Mac clients (7.0.2?), WebAccess (possibly also 7.0.2, but it may be 7.0.3) and SOAP clients (7.0.3?).  The prior exceptions, though we should be doing it globally now, was on posted appointments.  So, if your users are using the latest windows client then we can probably intelligently move 80-90% of appointments, if they are working like the rest of us do - so they only need to review 10-20% of their total.

So after having explained all of that I have spoken to a number of customers in Australia and the overwhelming feedback was  to go with one of the first 3 options and not attempt to move any appointments.  The reasons given were that it was less confusing for the users to not have appointments moved for them so that they could be sure that they had checked them all themselves.  It was also felt that most users won't yet have appointments in the problem period and Microsoft released the workstation updates in a patch in December - we are defendant on this patch for the DST calculations.  As this was done quite early if that patch was applied there will be very few problematic appointments.

So my question to the rest of you is if this seems like some reasonable assumptions and if this is the way to go?