• 1. London, UK
  • 2. New York, NY
  • 3. Sydney, Australia
  • 4. Melbourne, Australia
  • 5. Moscow, Russia
  • 6. Singapore
  • 7. Paris, France
  • 8. Chicago, IL
  • 9. Hong Kong
  • 10. Houston, TX
Bharat Suneja

Monday, February 11, 2008

The last time we took a look at the timezone changes was when the August 2007 cumulative time zone update was released (Read previous post: "DST 2007: August 2007 Cumulative Timezone Update for Windows operating systems"). The August 2007 update included new timezone data for Caucasus Standard Time, Armenian Standard Time, New Zealand Standard Time, GTB Standard Time, and Jordan Standard Time. Some updates were minor - such as changing the display name of a time zone.

In December, Microsoft released another time zone update - KB 942763: December 2007 cumulative time zone update for Microsoft Windows operating systems. Changes:
- Arabic Standard Time: Adjusts DST start and end dates for Baghdad time zone
- Australia: Central Australia, Eastern Australia and Tasmania Standard Time - these start and end on the same day.
- Egypt Standard Time: Adjusts DST start and end dates for Cairo time zone
- Israel Standard Time: Adjusts DST start and end dates for Jerusalem
- South America: E. South America Standard Time, Central Brazilian Standard Time - Adjusts DST start dates and end dates for the Brasilia time zone and for the Manaus time zone
- Venezuela Standard Time: Adds a new time zone for the Caracas time zone

Updates in the above list reflect the latest time zone changes made around the world after the Aug. 2007 Cumulative Timezone Update was released. If you've already applied the previous updates affecting your locale, and rebased appointments, the latest update will not change anything for you.

Also note, this is a cumulative update. It includes all previous timezone updates.

Related posts:
- DST 2007 Rollup Post

Labels: , , ,

Tuesday, August 21, 2007

In case we all forgot about the DST 2007 nightmare (read previous post: "DST 2007: Understanding what needs to be done and how to do it") we had to live through earlier this year, this update serves as a reminder. It hasn't really been that long! :)

Microsoft has released a new timezone update - August 2007 Cumulative Timezone Update.

Relax, we don't need to go through the same drill of rebasing appointments again (and I apologize for even mentioning it just as the chain of events is beginning to fade from our collective memory). The new changes in this update don't impact most parts of the world.

The previous update - KBA 931836 February 2007 Cumulative Timezone Update has been superseded by KBA 933360 August 2007 cumulative time zone update for Microsoft Windows operating systems.

On 8/21/2007 this new KBA has been updated. The hotfixes for various Microsoft operating systems are dated between 10th & 18th July, 2007. The following new time zone changes are included:
Caucasus Standard Time: Display name changed, time zone changes removed
Armenian Standard Time: New time zone created
New Zealand Standard Time: DST start and end times changed because of new law passed in New Zealand after the Feb. 2007 Cumulative Timezone Update
GTB Standard Time: Display name for GTB Standard Time corrected to include Bucharest
Jordan Standard Time: Just like New Zealand, changes to DST start and end dates based on law passed after the Feb. 2007 Cumulative Time Zone Update was released.

While we're on the subject, we continue to inch towards the end of the extended DST 2007 period - that happens on Sunday, the 4th of November this year.

What will be even more interesting than the memorable DST change this year is the Dept of Energy's report to Congress about how much energy we actually ended up saving because of this change (read previous post "DST 2007: Energy Policy Act of 2005 - the few lines...").

Don't forget to thank Rep. Fred Upton (R-MI) and Rep. Ed Markey (D-MA) for this!

Labels:

Friday, April 20, 2007

Following DST 2007 patches, Exchange's Message Tracking Center displayed times that were an hour off (though the actual times logged in the Message Tracking log were correctly logged in UTC), as noted in previous post titled "DST 2007: Exchange's Message Tracking off by an hour".

Microsoft recently released a hotfix to correct this rendering issue - KB 933902: E-mail messages that are tracked in Exchange System Manager display an incorrect tracked time. The hotfix updates EXADMIN.DLL to version 6.5.7652.21. The hotfix is available from Microsoft PSS/CSS.

Labels: ,

Tuesday, April 03, 2007

It seems the early verdicts are in, and as predicted by various experts, including the Department of Energy [read previous post "DST 2007: DoE isn't convinced new DST will save energy!"], we didn't end up saving much energy in the first three weeks of this extended Daylight Savings Time to justify this shift, and all the pain that IT pros went through to prepare for it.

According to News.com, "..other than forcing millions of drowsy American workers and school children into the dark, wintry weather thee weeks early, the move appears to have had little impact on power usage". Read more in the report titled "Daylight saving shift fails to curb energy use" on News.com.

Come December, when it's time for DoE to report to Congress about the energy saved as a result of this switch [read previous post "DST 2007: Energy Policy Act of 2005 - the few lines..."], it's quite likely the Energy Policy Act, 2005 will get a huge thumbs down. Are you ready to move back to the "normal" DST schedules come 2008? :)

Labels:

Tuesday, March 20, 2007

 

DST 2007: Why we needed to rebase appointments

Posted by Bharat Suneja at 6:08 PM
I thought I wouldn't need to post about DST 2007 issues after it kicked in on Sunday March 11th this year, but apparently that doesn't seem to be the case.

In a previous post (that I've referred to a number of times now) titled "DST 2007: Understanding what needs to be done and how to do it", I explained how computers keep time and how Outlook creates appointments.

While taking a break from the MVP Summit schedule earlier last week, I came across this eWeek article by Peter Galli titled "Time Change Brings 'Nightmare' Issues with Outlook, Calendars". The article quotes Robert Rosen, CIO of the National Institutes of Health's National Institute of Arthritis and Musculoskeletal and Skin Diseases. "Microsoft in particular requires operating system patches and then Outlook calendar modifications. That makes no sense. If they were storing in Coordinated Universal Time, the operating system patch should have fixed the calendars automatically".

After some reflection, I've gone from that line of thought, to a more logical explanation.

Rosen's line of thought, and mine to some extent when this thing started - if Outlook stores appointments in UTC, which is a universal time that shouldn't change, appointments should always be rendered at the correct time by merely telling the OS when DST starts and ends.

Here's why that line of though isn't correct: users don't book meetings using UTC. They do using their local time - let's say 4:30 PM Pacific time.

When saving the appointment, Outlook uses the time zone in effect on the day of the meeting to calculate the UTC Start Time and End Time. For the 4:30 PM appointment on March 12th, 2007, using the time zone in effect according to the older DST schedule, which would still be Pacific Standard Time or UTC -8:00, the UTC Stard and End times would be 12:30 - 1:00 AM on March 13th, 2007. Here's what the appointment looks like originally.
(Note: A recurring meeting is shown in the screenshot, with the CommonStart and CommonEnd properties so they can be captured on the same screen along with the time zone property - Bharat)



The operating system (OS) is told about this new DST schedule (by applying KB 931836 time zone update).

Now, the appointment Start and End time, though saved in UTC, end up being wrong! UTC 12:30 -1:00 AM on March 13th, 2007, turns out to be 5:30 - 6:00 PM Pacific time on March 12th, according to the new DST 2007 schedule.

Thus the need for "rebasing" those appointments occurring in the affected DST period, which actually adjusts the UTC start and end times of those meetings so they get rendered correctly (in local time) by Outlook. Here's what the 4:30 PM appointment on 3/12/2007 looks like after rebasing.


If users scheduled meetings using UTC to start with - a difficult task that would certainly impact the productivity and increase user frustration - meetings would always have a constant UTC time, irrespective of local time. (As a sidenote, this would have its own implications... but I'd rather not go into more details at this point, now that the DST 2007 change is behind us :-).

Labels: , , ,

Friday, March 09, 2007

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!

Never before have IT folks been as affected by as few lines (..and we're not talking about lines of code here.. :) written by lawmakers.. if you look up the Energy Policy Act of 2005, Section 110, here's all you'll find:

SEC. 110. DAYLIGHT SAVINGS.
(a) AMENDMENT.—Section 3(a) of the Uniform Time Act of 1966
(15 U.S.C. 260a(a)) is amended—
(1) by striking ‘‘first Sunday of April’’ and inserting ‘‘second Sunday of March’’; and
(2) by striking ‘‘last Sunday of October’’ and inserting ‘‘first Sunday of November’’.
(b) EFFECTIVE DATE.—Subsection (a) shall take effect 1 year
after the date of enactment of this Act or March 1, 2007, whichever
is later.
(c) REPORT TO CONGRESS.—Not later than 9 months after the
effective date stated in subsection (b), the Secretary shall report
to Congress on the impact of this section on energy consumption
in the United States.
(d) RIGHT TO REVERT.—Congress retains the right to revert
the Daylight Saving Time back to the 2005 time schedules once
the Department study is complete.


I can't help but smile at the enormous impact the above lines have had on our lives in the past few weeks and days!

We have two Congressmen - Rep. Fred Upton (R-MI) and Rep. Ed Markey (D-MA) to thank for this!

Repeat after me: "We will save energy, lower crime and traffic fatalities, have more recreation time and see increased economic activity, by switching to DST three weeks earlier and delaying the switch back to standard time a week later than what we've been doing since 1966. Day light saving will bring a smile to everybody’s faces, and IT's efforts were a small price to pay for this...." :)

... Er.. Congressmen, would this account for the recreation time us IT folks lost because of this? :)

What could be worse? Come December, the Department of Energy submits a report saying we didn't save much energy, and certainly nowhere close to what was estimated. Another Act or Amendment to this one mandates we need to switch back to the regular DST schedule!

Labels: ,

Thursday, March 08, 2007

 

DST 2007: Is there an Outlook DST "patch"?

Posted by Bharat Suneja at 2:33 PM
There seems to be some confusion about whether Outlook itself has a DST 2007 patch.

As noted in a previous post "DST 2007: Understanding what needs to be done and how to do it", there's the Outlook Calendar Update Tool - TzMove.exe ("Time Zone Data Update Tool for Microsoft Office Outlook" in Microsoft-speak). This is a tool to rebase existing appointments so they show up correctly on users' calendars after they've applied the time zone update to the operating system (KB 931836). As such, it's not really a patch.

Then there's the Outlook 2003 CDO patch (Outlook 2003 Post-SP2 hotfix) - KB 932962. This is the client-equivalent of the Exchange CDO patch (KB 926666 for Exchange Server 2003 SP2, KB 931978 for Exchange Server 2003 SP1), according to Microsoft's DST 2007 blog.

Do all Outlook users need this? No.

CDO is not installed by default on clients running Outlook, and isn't generally required.

However, some applications that use (client-side) CDO to access Outlook's Contacts and Calendar install this version of CDO on the client. If you're using one of those apps, for instance the contact-management app ACT, you should update the CDO component by applying KB 932962 on the client computer.

This updates CDO.DLL to version 6.5.7651.61 (and updates a few other files as well).

Labels: , ,

 

DST 2007: The order of things, again!

Posted by Bharat Suneja at 8:16 AM
As we wind down towards the DST 2007 deadline, I've still been getting quite a few questions about this in the past day or two. This has been covered and repeated quite a bit over the past few days, but here it is once again.

Here's what Microsoft recommends on its DST 2007 web site:
1. DST 2007 Time Zone Update (KB 931836) on Windows servers
2. DST 2007 Time Zone Update on Windows clients
3. Exchange Server DST Update (KB 926666 for Exchange Server 2003 SP2, KB 93
4. Rebase appointments

Environments which rely heavily on OWA:
1. DST 2007 Time Zone Update on Windows servers
2. DST 2007 Time Zone Update on Windows clients
3. Rebase appointments
4. Exchange Server DST Update

From a Microsoft DST 2007 chat earlier yesterday:
Lakshmy [MSFT] (Expert):
Q: [596] Can any expert from MSFT confirm this? What's the exact order of things? Are there any issues at all with applying KB 926666 Exchange CDO patch *last* after rebasing appointments?

A: Apply Windows Server OS DST Patch first.
Please follow following patching order for DST patching...
1. Install OS patch on servers (931836)
2. Install OS patch on clients (931836)
3. Rebase calendar appointments (using TZMove (931667) / TZMove update 933146 / Exchange tool 930879)
4. Install Exchange DST patch for CDO (926666)
In organizations where OWA is not used to schedule appointments, step 4 can be performed before step 3, *if desired*. Please see [Microsoft's DST 2007 Blog url]; for more details.

(I've recommended the later order in an earlier post titled " DST 2007: Understanding what needs to be done and how to do it". I haven't come across any information about specific issues when following that order.

It's important to ensure that appointments created using new DST 2007 time zone rules - these are the ones users create after their computers are updated with KB 931836 time zone update - do not get rebased wrongly, which can be done by either having clients run the Outlook Calendar Update Tool using the /ONLYCREATEDPREPATCH option, or using that option when running MsExTmz.exe with a UTC time when clients received their KB 931836 time zone update for the OS. - Bharat)

Labels:

Wednesday, March 07, 2007

Zenprise held a webinar titled "Updating Daylight Savings Time for BlackBerry & Exchange" on Friday March 23rd. The archived webinar is now available on the Zenprise web site [registration required].

Labels: , ,

 

Switching your Linux systems to the new DST

Posted by Bharat Suneja at 8:33 AM
Over on Linux-Watch, Steven Vaughan-Nichols shows you how to update Linux systems for DST 2007.

As a sidenote to the above, Windows systems also use NTP (Network Time Protocol) to synchronize clocks to reliable time sources. This is required in Active Directory environments, for Kerberos v5 authentication.

In an AD domain, all client computers and member servers synch time with their authenticating Domain Controller (DC), which in turn synchs with the DC that has the PDC Operations Master role (aka "PDC Emulator" FSMO role in prev versions). The PDC operations master DCs synch to the PDC Operations Master in their parent domain, following the domain hierarchy. The PDC Operations Master in the root domain should be synched with a hardware time source like the computer's CMOS clock, or a reliable external time source. Ref: KB 816042: How to configure an authoritative time server in Windows Server 2003

Labels: ,

 

DST 2007 Rollup Post

Posted by Bharat Suneja at 7:46 AM
If the navbar link on the left doesn't get you quickly to the DST 2007 post you want to, here's a list of all DST 2007 posts on this blog:

- DST 2007: December 2007 cumulative time zone update for Microsoft Windows operating systems
- DST 2007: August 2007 Cumulative Timezone Update for Windows operating systems
- DST 2007: Hotfix released for Exchange Server 2003 Message Tracking issue
- DST 2007: As predicted, we didn't save much energy afterall!
- DST 2007: Why we needed to rebase appointments
- DST 2007: Energy Policy Act of 2005 - the few lines...
- DST 2007: Is there an Outlook DST "patch"?
- DST 2007: The order of things, again!
- DST 2007: Exchange's Message Tracking off by an hour
- Switching your Linux systems to the new DST
- DST 2007: DoE isn't convinced new DST will save energy!
- CNet News.com: IT pros battle clock and code in time change
- DST 2007: I rebased appointments and nothing moved!
- DST 2007: Script to export Calendar items (before you rebase!)
- DST 2007: Updating Front-End Servers
- DST 2007: Heading into the weekend... list of relevant links
- DST 2007: Clarification on using /ONLYCREATEDPREPATCH option
- Where is TZMOVE.EXE?
- DST 2007: Hotfix for Outlook Calendar Update Tool
- DST 2007: Understanding what needs to be done and how to do it
- DST 2007: Microsoft Exchange Calendar Update Tool and Outlook Cached Mode
- DST 2007: Microsoft Exchange Calendar Update Tool v2.0
- DST2007 CDO patch: Hotfix released for Store not mounting issue
- DST 2007 and Exchange 2000: Patch For A Price?

From the Exchange Team Blog:
- Daylight Saving Time Correction for Microsoft Office Outlook Calendars - Help desk guidelines
- Video: How to rebase a Resource Calendar using the Outlook Time Zone Update tool and the /FORCEREBASESUPPRESSALL switch
- Video demos for running Exchange and Outlook DST 2007 tools
- DST and resource mailboxes - Auto Accept Agent and Direct Booking
- How to find public folder calendars and their owners?
- Step by step run of the Exchange Calendar Update Configuration Tool (MSExTMZCFG.EXE)
- Exchange 2003 and DST fix (KB 926666)

Labels:

The Department of Energy isn't convinced changing the clocks will make a dent in energy consumption! In an e-mail to TIME magazine, DoE press secretary Craig Stevens writes: "The jury on the potential national energy-savings of extending daylight saving time is still out. Our preliminary report, based on decades-old information, indicates a very small amount of energy savings."

The DoE will keep tabs on energy consumptions during the next nine months, and calculate exact savings at the end.

What's more - if it's found that we're not saving enough energy, the Energy Policy Act of 2005 reserves the right to revert to the old DST!

(The Energy Policy Act does have some good provisions, like the $3400 tax credit for hybrid cars, but it will be remembered most - particularly by IT folks - for what's known as the Upton Amendment introduced by Congressman Fred Upton of Michigan, to extend Daylight Saving Time, originally by 2 months! - Bharat)

More in Kristina Dell's short but well-written snippet on TIME.com - Daylight Saving: Glitches Ahead.

Labels: ,

Monday, March 05, 2007

A report from Erica Ogg at CNet News.com, aptly titled "IT pros battle clock and code in time change".

I'm trying to find the humor in all this, and this report provides it: "Microsoft acknowledges that the instructions for updating aren't exactly credit card-size." :)

Further: "BlackBerry Pearl user (user name not published here, in Erica's report linked below) said in an e-mail interview that when she received the patch from her carrier, she initially thought it was junk mail. Nonetheless, she installed the software." Yes, the kind of users we all have, and love to have! :)

Read the entire report on CNet News.com.

Labels: , , ,

 

DST 2007: I rebased appointments and nothing moved!

Posted by Bharat Suneja at 12:19 PM
It's natural to question what the rebasing tools did - after you rebased items, they didn't seem to move them! Appointments show up in their correct time slots.

Wasn't this what you wanted to see - appointments appear in their correct time slots? :)

I've covered this in a previous post titled "DST 2007: Understanding what needs to be done and how to do it", and I'll briefly explain what happens once again.

- User workstation has older DST 2006 time zone rules, all appointments created using those rules
- DST 2007, and the appointments we talk about are those occurring in the "extended" DST 2007 period, which as you may know by now is the period between March 11-April 1, because we're moving clocks forward by an hour 3 weeks earlier than usual, and between Oct. 28-Nov. 4 2007 - because we're moving clocks back by an hour a week later than usual. Let's refer to these as the affected appointments.

1. User workstation gets KB 931836: This updates the time zone definitions in the operating system's registry. It changes *when* the computer will switch to Daylight Savings Time, and when it'll switch back. Now, all those old appointments in the affected period appear an hour later. These are the appointments we need to rebase.
(Computers with old DST 2006 time zone, i.e. ones without KB 931836 update applied, will still show these at the correct times).

2. Appointments created while the KB 931836 time zone is applied (and occur during the affected period): These appointments will appear correctly. NO REBASING REQUIRED.

3. Appointments rebased using the Outlook Calendar Update Tool or the Exchange Calendar Update Tool. What this does - changes the Start and End times - which are in UTC/GMT (again, covered in previous post)

4. On computers with KB 931836 applied:
- Old appointments rebased, show up at the correct time
- If new appointments rebased wrongly, these show up one hour early

On computers without KB 931836 applied
:
- Old appointments rebased, show up an hour early in Outlook
- New appointments (if) wrongly rebased, show up two hours early

Regardless of when rebasing is done, recurring items do not get rebased wrongly. These have the time zone embedded in the item which prevents them from being wrongly rebased by any of the rebasing tools.

Also note, appointments rebased once will not get rebased again when you run either tool.

Labels: , ,

MIIS (Microsoft Identity Integration Server) MVP Jason Sherry recently shared this script to export Calendar items, which should come in handy to export items from the affected "extended" DST period, before you start rebasing items.

In case something goes wrong during rebasing and appointments are off by an hour or two before or after their actual scheduled time, the output from this script should serve as a handy reference to determine the actual appointment times.

(Of course, as noted a few times earlier throughout my posts, adding the meeting time to the subject line of each meeting during this affected period should go *a long way* in "defending" yourself from any rebasing-related issues... however, the simplest solution is quite frequently the first one to be dismissed by many folks, including users and IT pros... - Bharat)
Meeting times in subject field of Calendar items

The script also has an option to disable Direct Booking of resource mailboxes while you rebase items. The account running this script should have Full Mailbox Access or Receive As permissions on mailboxes, (and just like requirements for the Exchange Calendar Update Tool - the account should not have Exchange Full Admin delegated to it, which creates a Deny ACE for Full Mailbox Access for the account).

The script uses MAPI, and like the rebasing tools - it should be run from a computer with Outlook installed.

Std. disclaimers from Jason: the script is a work in progress, please test in a non-production environment and use at your own risk.

Download ExportCalendar.vbs from here.

Download and read the documentation before you proceed.

Labels: , , ,

Saturday, March 03, 2007

 

DST 2007: Updating Front-End Servers

Posted by Bharat Suneja at 10:35 AM
Another common question related to the DST updating process: do I need to do anything on my Front-End Exchange servers?

Front-End servers do need the Feb. 2007 Cumulative Time Zone Update (KB 931836), and the Exchange CDO patch (KB 926666 for Exchange Server 2003 SP2, KB 931978 for Exchange Server 2003 SP1).

When do we need to apply these? Preferably at the same time as the Back-End servers (during a scheduled maintenance window, the exact order shouldn't matter as much. Normally you apply any service packs or hotfixes to Front-End servers first).

Actual rebasing tools to modify Calendar items are run against mailboxes, so these can be said to be running against Back-End servers.

Labels: , ,

Friday, March 02, 2007

Some of us will probably be working on DST 2007 issues over the weekend.

Here's a list of some quick links to get you to relevant web pages for Microsoft KBAs, downloads, and BlackBerry DST 2007 resources.

(My list of DST 2007 posts can be accessed from the navbar link on the left side of this post - Bharat)

Windows OS Time Zone Updates:
1. 931836: February 2007 cumulative time zone update for Microsoft Windows operating systems, v6.5 date: 2/28/2007
Update 08/21/2007: KBA 931836 has been superseded by KBA 933360 August 2007 cumulative time zone update for Microsoft Windows operating systems. On 8/21/2007 this new KBA and the accompanying hotfix have been updated to include the following time zone changes:
Caucasus Standard Time: Display name changed, time zone changes removed
Armenian Standard Time: New time zone created
New Zealand Standard Time: DST start and end times changed because of new law passed in New Zealand after the Feb. 2007 Cumulative Timezone Update
GTB Standard Time: Display name for GTB Standard Time corrected to include Bucharest
Jordan Standard Time: Just like New Zealand, changes to DST start and end dates based on law passed after the Feb. 2007 Cumulative Time Zone Update was released.
2. 914387: How to configure daylight saving time for the United States in 2007 (For Windows 2000, WinXP RTM), v18.0 date: 2/28/2007

Exchange Server CDO Patches:
3. 926666: Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 2, v12.3 date: 3/2/2007
4. 931978: Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 1, v3.0 date: 2/20/2007

Rebasing Tools:
5. Microsoft Office Outlook Tool: Time Zone Data Update Tool for Microsoft Office Outlook
TZMOVE.EXE version 1.0 2/19/07 8.3 Mb
6. Microsoft Exchange Calendar Update Tool
v2.0 KB 930879, 2/21/2003, 253KB
7. 933146: Description of the hotfix package for the Time Zone Data Update tool for Microsoft Office Outlook, v1.1 date: 2/28/2007
8. DST Virtual Machine image v1.0 : Virtual Machine for Microsoft Exchange Calendar Update Tool (still v1.0 of the tool last time I checked - Bharat)
9. DST Update for Windows Mobile PocketPC

HOW TO Articles:
10. 930879: How to address daylight saving time by using the Exchange Calendar Update Tool
v17.0 date: 3/1/2007
11. 931667: How to address the daylight saving time changes in 2007 by using the Time Zone Data Update Tool for Microsoft Office Outlook, v9.0 date: 2/27/2007
12. Prepare Outlook calendar items for daylight saving time changes in 2007

Issues:
13. 932599: Information Store database does not mount with Event ID 9519 and 9518, v6.0 date: 2/28/2007
14. 930241: The Exchange 2003 database does not mount, and event IDs 9518 and 9519 are logged in the Application log – HOTFIX for same issue as KB 932599, v3.0 date: 2/23/2007
15. 912918: Users cannot send e-mail messages from a mobile device or from a shared mailbox in Exchange 2000 Server and in Exchange Server 2003, v13.0 date: 2/15/2007

Misc.:
16. Preparing for Daylight Saving Time changes in 2007, Last Reviewed: 2/26/2007
17. Exchange Server and Daylight Saving Time (DST) 2007 - Scott Schnoll

BlackBerry:
18. Daylight Saving Time 2007 resource page on BlackBerry.com
19. Updating your BlackBerry Environment to Support DST 2007 Changes (detailed PDF Doc on blackberry.com)
20. RIM "Set Send As" Permission tool
21. RIM's DST 2007 Query tool (queries BlackBerry database for hand-held device versions)

Labels: , , ,

Update on the previous post titled "DST 2007: Hotfix for Outlook Calendar Update Tool", and the patched Outlook Calendar Update Tool (KB 933146) from PSS.

KB 933146 states:
We recommend that you do not use the /ONLYCREATEDPREPATCH command-line option with the Exchange Calendar Update Tool (MsExTmz.exe). The /ONLYCREATEDPREPATCH command-line option uses the local operating system as the basis for its logic. Therefore, all calendars would be rebased using the information from the computer where the Exchange Calendar Update Tool was run and probably would not apply to the user mailboxes that are being rebased.

However, you can use the /ONLYCREATEDPREPATCH option when rebasing items using the Exchange Calendar Update Tool (MsExTmz.exe).

An email clarification from PSS : When doing the above, you should ensure the computer that you're running the tool from has the Feb. 2007 Cumulative Time Zone Update (KB 931836) applied, or explicitly specify a UTC time. The tool will rebase Calendar items occurring in the affected extended DST period that were created before KB 931836 was applied to the computer (that you're running the tool from), or before the UTC time specified (if using it with the UTC time option).

Take aways from the above clarification:

- If using the former option (not specifying a UTC time), be aware that the tool will check the local computer's time zone and when the DST 2007 time zone update (KB 931836) was applied to that computer, not on the computer of the user whose mailbox is being processed.

- When using this option, depending on when the time zone update was applied to user workstations, all items may or may not get rebased correctly.

For instance,
i) If the time zone update was applied to a user workstation before you rebase Calendar items using MsExTmz.exe, and the user created new items after the time zone update was applied - those items will get rebased as well. Wrongly so in this case.
ii) If the user workstation does not have the time zone update, only items created before the time that the admin's computer got the time zone update will get rebased - leaving all appointments created after that time untouched.
iii) If specifying the UTC time with the option, appointments created before the time specified will get rebased, irrespective of whether they were created using the old time zone rules or the updated DST 2007 rules.

Labels: , ,

Thursday, March 01, 2007

 

Where is TZMOVE.EXE?

Posted by Bharat Suneja at 6:34 PM
Just installed the Outlook Calendar Update Tool and can't locate it in the Windows Start menu (All Programs, or in the Microsoft Office program group)?

After installation, the tool starts running and shows the start-up screen. If you've already run it once or chose to run it at a later time, here's where you'll find it on computers with Outlook 2003:
\Program Files\Microsoft Office\Office 12\Office Outlook Time Zone Data Update Tool

(On computers with Microsoft Office 2007 installed, you can also access the Outlook 2007 time zone tool from within Outlook | Tools | Options | Calendar Options | Time Zone | Change Calendar Time Zone)

Labels: , , ,

 

DST 2007: Hotfix for Outlook Calendar Update Tool

Posted by Bharat Suneja at 11:29 AM
As noted in previous post titled "DST 2007: Understanding what needs to be done and how to do it", Microsoft has released a hotfix for the Outlook Calendar Update Tool (aka "Time Zone Update tool for Microsoft Office Outlook").

This addresses some key issues mentioned in the previous post, and adds some new command line options:
1. Avoid rebasing single-instance items created after DST 2007 updates are applied to the OS: Again, as noted in my previous post, if users create appointments after the OS gets its DST 2007 time zone update but before existing items are rebased, such new single instance items also end up getting rebased - wrongly so. (The same does not apply to recurring items, which do not get rebased wrongly - as explained in the previous post - Bharat)

After this new hotfix is applied to the tool, it provides two options to avoid that:
- you can use the patched TZMOVE.EXE with /ONLYCREATEDPREPATCH option. The patched tool determines when the DST 2007 time zone update (KB 931836) is applied on the computer, and does not rebase any items created after that time.
- you can manually specify a time in UTC - the patched tool only rebases items created before that time. This is done using the /ONLYCREATEDPREPATCH switch with a UTC time (the cut-off time when the OS possibly would have received the DST 2007 time zone update) in the format yyyy-mm-ddThh:mm:ssZ, so it looks like the following:
TZMOVE.EXE /ONLYCREATEDPREPATCH:2007-03-01T18:00:00Z
(The above will rebase items created before 12:00 noon on March 1st, 2007. Since this uses the local computer's time zone, Microsoft recommends that you do not use this option when running the Exchange Calendar Update Tool).

2. Force rebasing of calendar items and suppressing meeting updates (that occur because rebasing changes the meeting times):
- Why do we need to force rebase appointments? Well, by default, the rebasing tool will only update meetings for which you (or rather, the account being used to run the tool) are the organizer. The force rebase actually forces updates of all appointments, regardless of who the organizer is.
- The options are /FORCEREBASESUPPRESSALLUPDATES - does not send meeting updates to anybody, or /FORCEREBASESUPPRESSEXCHANGEUPDATES - sends meeting updates only to invitees/attendees who are not in your Exchange Org.

3. Rebasing of Public Folder calendar items: You can now update Public Folders from the command line.

4. Rebasing of calendar items in folders other than the default Calendar folder, from the command line.

5. Do a what-if analysis!: The patched tool lets you use a new /REPORTINGMODE option, which simply logs any changes that would have been made if you ran the tool in Update mode. Now you can look at the Application log and determine if it would have picked up/rebased all the items that required rebasing, or if it would have missed anything.

More details in KB 933146.

Labels: , ,

Wednesday, February 28, 2007

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 Outlook

When 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 Appointments
3. 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: , , , , ,

Monday, February 26, 2007

This seems to be a source of confusion judging from the questions asked in the few Microsoft webinars/conference calls I attended throughout last week on the DST 2007 issue, and the webinar held by Zenprise on Friday that also covered guidance about updating BlackBerry devices and BlackBerry Enterprise Server for DST 2007: do I need to ensure Outlook users are not using Cached Mode when running this tool?

For the record, the guidance related to Microsoft Outlook 2003/2007 not being in Cached Mode is only for the computers that you're running the Microsoft Exchange Calendar Update Tool from. (You can run the tool from more than one computers to rebase appointments for different sets of users). It does not impact users - they can continue to use Outlook 2003/2007 Cached Mode.

Labels: , ,

Friday, February 23, 2007

For those glued to the DST 2007 issue, this may not come as a big surprise, but judging by the questions I had at this morning's webinar held by Zenprise for DST issues, apparently not a lot of folks are aware that version 2.0 of the Exchange Calendar Update Tool is now available on microsoft.com.

Amongst other things, v2.0 takes care of some memory leak issues that required restarting the earlier tool, and as a welcome relief, a huge performance boost as well! The new tool can reportedly process between 7 to 15 mailboxes a minute, (depending on your environment and factors like number of items in the mailbox).

Microsoft discussed this in a webinar/conference call yesterday. IT folks who haven't started rebasing users' calendar items yet - and this group has a clear majority at the moment, imo (many folks are still assessing the tools, running tests, and trying to nail down the process, as the deadline to move the the extended Daylight Savings Time looms on the horizon - Bharat) - will breathe a little easier.

Labels: , , ,

Thursday, February 22, 2007

After applying the DST 2007 CDO patch for Exchange (includes Store.exe v 06.05.7651.61) on Exchange Servers 2003 SP2, the Store does not mount. This happens in environments with more than one domain where a well-known SID like BUILTIN\Administrators is included in Exchange permissions, and the Store.exe is version v06.05.7651.26 or later.

KBA 930241 outlines a workaround to identify and remove the well-known SID from the ACLs, something one wouldn't look forward to when the Store's down.

Microsoft has released a patch to fix this issue, available from PSS. Refer to KBA 930241 for more info.

Labels: , ,

Wednesday, February 21, 2007

 

DST 2007 and Exchange 2000: Patch For A Price?

Posted by Bharat Suneja at 8:55 AM
IT folks in many organizations still on Exchange 2000 are upset about the fact that Microsoft isn't providing the DST 2007 CDO patch for Exchange 2000 for free, unlike the ones for Exchange 2003. (Exchange Server 2007 does not require it).

If you're still on Exchange 2000, and upset about the price-tag of this patch, and ongoing support costs, consider the following:
- Exchange 2000 is now in extended support, after five years of being in mainstream support:
Microsoft's support policy for Exchange 2000
- Exchange has undergone two major product releases/updates (Exchange Server 2003 & 2007) since then.
- Moreover, the DST issue is not a product vulnerability or security issue. It was the government's doing, thanks to the Energy Policy Act of 2005, and the issue was non-existent when Exchange 2000 (and also Exchange Server 2003) was released.
- In many environments, the cost of upgrading to a currently-supported Exchange version (Exchange Server 2003 or Exchange 2007), even after factoring in the cost of new hardware, may be lower than the ongoing support costs and costs of downtime. (If you run a perfect Exchange operation where outages *never* happen, this doesn't apply to you.. :)
- In smaller, single-server environments with low number of users (let's say SBS-type environments) - the cost of this patch alone could possibly buy you a new server and Exchange license.

Labels: , , ,