Cool Blog: DST Issues and Solutions
Novell Cool Solutions: Feature
By Ken Muir
Digg This -
Posted: 6 Mar 2007
DST issues have absolutely been the hot topic the last few weeks in the IT industry. All computers systems of any type are subject to potentially adverse affects of these changes to when DST starts and ends. For the IT Messaging Administrator, Calendars are the focus of concern. Worse-case scenario, people may miss meetings because they show up 1 hour off on their calendars.
In my last blog entry and in numerous communications from Novell Technical Support and GroupWise Product Management/Marketing we have highlighted the manual steps that are involved in ensuring that appointments are adjusted correctly. We have some good news that will help ease the manual burden placed on everyone!
When I met with my team back in November to discuss this issue, we determined that it would be impossible to write a utility that would guarantee the successful conversion of ALL appointments within the time period in question. This is due to the fact that there are appointments throughout the system that are created via many different email clients and many different versions. We decided that a clear list of manual steps would be the best and cleanest approach.
Based on customer feedback, we quickly realized that this was not the best approach. Customers would rather have a utility that would fix the majority of the appointments accurately than have to fix all of them manually. I fully take the blame for this decision although I will certainly still argue the logic behind the original decision. It basically comes down to giving our customers what they ask for. So this is what we are doing now.
We are targeting releasing a tool on March 1st that will resolve this issue for the majority of appointments. Here is a list of what the tool is, and is NOT:
Many of the GroupWise clients place the Time Zone definition when the appointment was created in the actual appointment record. We can programatically key off this TZ definition and determine if an appointment needs to be adjusted. Not all appointments have this required information. We know that all GroupWise Windows clients since 6.5 provide this required information on all sent and received appointmens (but not personal appointments). WebAccess created appointments do not. Most versions of our Linux/Mac client do provide this information. Appointments that have come in via iCAL do not. Appointments created from some mobile devices do not. BOTTOM LINE - since the vast majority of our customers use the GroupWise Windows client and are on version 6.5 or newer, we can adjust the majority of the appointments.
The tool is actually an option in GWCheck which all our adminstrators are familar with. There are two modes this can be run in:
The first option will ONLY adjust appointments that have the necessary information as described in #1. This is the safest and most conservative mode.
The second option allows for the adjustment of all appointments created before a given date. This is a great option if the post office only contains US users, and you know exactly when all your Windows workstations were patched with the Microsoft TZ patch. For those using MS auto update, very likely, this was Friday of last week. For those using the better solution in ZENworks, you know exactly when you patched or when you will patch your machines. Supply this date, and we will adjust all appointments prior to the date - both those appointments that were stamped and those that are not. The caution here is that supplying a date implies that all appointments that are not stamped came from affected time zones, which means we may actually adjust an appointment that was already correct.
You may also run any of the above options against a specific list of users rather than the entire post office.
The tool ONLY needs to be run against ALL backend post offices. It does NOT need to be run at each client. This is a far superior solution, given that you don't have to distribute and execute it from the client.
The tool will also adjust the definition of each user's "work day," so it shows the correct times as well. (Otherwise this would be off an hour, too).
For updating NetWare or Windows POAs, the tool is executed from a Windows adminstrative workstation and remotely connects to the server. For POAs running on Linux, you will run the tool from the server console.
The tool may be run multiple times. When an appointment is adjusted via the tool, it marks the appointment so it will not get adjusted again.
The tool will also create a "Query folder" called "TZChange2007" in each user's cabinet that will display all calendar items that occur during the impacted weeks of 2007. (If you are not sure what the impacted weeks are, please refer to the NTS TIDs). This will give each end user a single place where they can look at a listing of all their appointments and double check that they are correct. The nice thing about doing this folder is that the end user won't have to know what weeks are impacted. It's all in one place, where they can quickly see a summary of each item and adjust/resend if necessary. They can delete this folder when they are satisfied that the appointments are correct.
FOR MOBILE USERS - all Mobile email solutions have patches either available or on the way. This includes BlackBerry and the GroupWise Mobile Server. Likewise, most of the actual Mobile Operating Systems (PALM, Windows Mobile) need to be updated. Honestly speaking, I am most concerned about mobile devices having incorrect times. There are too many moving parts in the mobility story for ANY vendor to have a high degree of confidence. Please review all the TIDs in this area to ensure you are patched adequately. It is also VERY likely that all mobile users will have to reset their devices.
FOR CACHING USERS - this is VERY important. Caching or Remote users will have one additional issue to deal with. While this tool does make the necessary adjustments in the database, there is an issue with the way we sync appointments down to the cached mailbox where the "end" time will still show up as the original end time. This means that a one hour meeting will show up as a two hour meeting (but the start time will be correct). Users have a few options: one is to just live with this for the three weeks in question. Another is to "re-prime" their cache. This is quite easy but takes time. There are a few more options that we are exploring, so look for them when we release the tool.
Finally, again I emphasize that no matter what approach is taken, there is still some very important communications that need to happen to your end users. They must excercise a certain amount of caution with their calendars during this period. If there is questions about the start time, they should double check it with the meeting scheduler. Some companies are going as far as asking people to put the start time in the subject line (sucha s "Core Team Meeting - 8AM MST"). These are good and prudent approaches.
The great team in Novell Technical Services is ready to help you through this. My entire engineering team is at their disposal should any difficulties arise. You can rest assured that every measure has been taken to help you and that additional preperations are taking place to ensure we are ready as the tool is delivered and when March 11th and 12th come.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com