UPDATE: We have now released the hotfix that corrects this issue for Exchange 2003 SP2. The article is: 930241 The Exchange 2003 database does not mount, and event IDs 9518 and 9519 are logge...
Updated Jul 01, 2019
Version 2.0
Blog Post
Just did an interesting experiment this morning with regards to DST and Exchange. We have a redundant server room located at an alternate location in our city. Last week I had applied the OS time patches to the servers in the redundant server room (DC on Server 2003 standard and Exchange server 2003 SP1 on Server 2003 standard). I also applied the CDO update for Exchange server 2003 SP1. This morning I went to an XP workstation and applied the time update to it. I then tested (4) different scenarios:
1. Looked at a test user’s calendar with server and workstation clocks set to 2/21/07 10:15 AM EST.
2. Adjusted the clocks to 3/11/07 1:50 AM EST and watched all three roll over to 2:00 AM and then quickly auto adjust to 3:00 AM.
3. Adjusted the clocks to 3/21/07 10:30AM EST (during period know as EDST).
4. Adjusted the clocks to 4/21/07 11:13 AM (during period known as DST).
In all (4) scenarios the test user’s calendar appts never shifted. All appts stayed the same even when viewing via OWA. None of the appts fell back or moved forward. I then installed the TZMOVE tool and started to run it against the test user’s mailbox. It told me that it found (20) appts that needed re-basing (but I just cancelled out at that point thinking it would just screw up his calendar as in other tests that I had done). I did not take time to look at the EDST period during November but thought that I would get the same results as #3 above.
Does anyone see any weakness in the test above. I know that we are an EST organization only and this may have something to do with it. I don’t recall Microsoft making any mention that the re-basing tool would NOT need to be run if you were a single time zone organization.
1. Looked at a test user’s calendar with server and workstation clocks set to 2/21/07 10:15 AM EST.
2. Adjusted the clocks to 3/11/07 1:50 AM EST and watched all three roll over to 2:00 AM and then quickly auto adjust to 3:00 AM.
3. Adjusted the clocks to 3/21/07 10:30AM EST (during period know as EDST).
4. Adjusted the clocks to 4/21/07 11:13 AM (during period known as DST).
In all (4) scenarios the test user’s calendar appts never shifted. All appts stayed the same even when viewing via OWA. None of the appts fell back or moved forward. I then installed the TZMOVE tool and started to run it against the test user’s mailbox. It told me that it found (20) appts that needed re-basing (but I just cancelled out at that point thinking it would just screw up his calendar as in other tests that I had done). I did not take time to look at the EDST period during November but thought that I would get the same results as #3 above.
Does anyone see any weakness in the test above. I know that we are an EST organization only and this may have something to do with it. I don’t recall Microsoft making any mention that the re-basing tool would NOT need to be run if you were a single time zone organization.