Welcome to Exchange Team Blog Sign in | Join | Help
Search
BlogsVideosPhotosFiles

Syndication

This Blog

Post Categories

Archives

Exchange 2003 and DST fix (KB 926666)

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 logged in the Application log
http://support.microsoft.com/default.aspx?scid=kb;EN-US;930241

The hotfix can be downloaded from here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=2A835A09-8E57-4027-A488-1E61C4B43A10&displaylang=en

For anyone who has used the workaround outlined in:

932599  Information Store database does not mount with Event ID 9519 and 9518
http://support.microsoft.com/default.aspx?scid=kb;EN-US;932599

You can apply the hotfix from 930241 and revert your permissions back to how they were before the application of the DST fix and the implementation of the workaround.

--------------------------------------------------------------------------------

As everyone in the US IT industry is now aware, there will shortly be a change to Daylight Saving Time here in the US. DST will be starting three weeks earlier and ending one week later. So in order to accommodate this change Microsoft has released a number of hotfixes both for windows and for various Microsoft applications that are affected by this change. One such fix is the CDO DST update for Exchange 2003:

Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 2
http://support.microsoft.com/kb/926666

In Exchange 2003 (as was the case with all previous version of Exchange) any new hotfixes that are released contain all previous hotfixes. This is because Exchange fixes are built on top of each other to ensure that we don't have hundreds of "special" version of Exchange components; and that all pieces of the product will continue to work properly. The side effect of this is that when a major fix comes out like the DST fix our customers may end up having some unexpected changes to their systems if they have not been keeping up with server hotfixes.

In the case of the 926666 fix, there are two primary issues that our customers are running into.

First, the DST fix includes a previous fix to the Send As behavior of Exchange 2003. The Send As behavior was changed in Exchange 2003 to move it to a more secure model when it was determined that the current model allowed for unexpected levels of access based on permissions assigned. To check if you are going to be affected by this change you should locate Store.exe in your "Exchsrvr\bin" directory. If the Version is lower than 7650.23 then when you apply the DST fix you will need to be concerned with the Send As behavior change.

The following articles document the Send As changes and what you will need to do to adjust for it much better than I can do here:

New Exchange fixes may disrupt Blackberry, Goodlink and other services
http://msexchangeteam.com/archive/2006/04/28/426707.aspx

"Send As" permission behavior change in Exchange 2003
http://support.microsoft.com/kb/895949/

Users cannot send e-mail messages from a mobile device or from a shared mailbox in Exchange 2000 Server and in Exchange Server 2003
http://support.microsoft.com/kb/912918

The other problem that you might encounter after applying the 926666 DST fix is that your database might not mount and generate an error when trying to mount. You will see events 9519 and 9518 with error codes 0x89a in the application log on the server. This is caused by a previous unrelated fix that was made for Exchange 2003. The above update to this post has the hotfix information. 

In the short term, we have published a public KB article that describes this store mount issue and provides a work around that should work for the vast majority of customers that are affected by this problem:

932599 Information Store database does not mount with Event ID 9519 and 9518
http://support.microsoft.com/default.aspx?scid=kb;EN-US;932599

Over all it is in your best interest to apply the DST fix for Exchange 2003 sooner rather than later. The sooner you get it on your system the less "fix up" will be needed of existing appointments.

For More information on the DST changes in please see:

Daylight Saving Time Help and Support Center
http://support.microsoft.com/gp/cp_dst

- Matthew Byrd

Published Tuesday, February 13, 2007 11:48 AM by Exchange
Filed Under: , ,

Comments

 

BK said:

Thanks for the Blog!  I understand that the recommendation is to apply the DST hotfix on Windows server, apply hotfix to workstations, update the Exchange CDO,  then run Time Zone Update Tool to update calendars.  However, I can't seem to get more information the time between servers and workstations are getting patched.  Could you answer a couple of questions for me?

Below are my questions:
1.  Can I update OS patch to Exchange servers a week before I run Exchange rebasing tool?
2.  Also, do I update the Exchange CDO patch with the Windows patch at the same time or wait the minutue before I run Exchange rebasing tool?

Thanks!
February 13, 2007 3:15 PM
 

JF said:

Sorely disappointed with the "speed" at which the DST fix has come down the pipe for Exchange. I find the whole process poorly documented and confusing to say the least. I feel sorry for anyone who has to manage a very large infrastructure.

February 13, 2007 3:28 PM
 

MW said:

I agree with JF. This is a nightmare and the documentation leaves a lot to be desired. FYI the link provided for "932599 Information Store database does not mount with Event ID 9519 and 9518" is broken.

Am I mistaken in stating that any appointments I accepted from others during that occur during the time period will be wrong if the originator does not have their Outlook fixed? Oops I better call my Dentist!

I hope MS realizes what a burden this is going to be. I only have 400 users and 2 Exchange servers but already I have spent a lot of hours setting up test environment, preparing documentation, meeting with IT staff etc. Worse than Y2K? Maybe because this is real.

Better documentation would be welcome. Like, how does this actually tie in to CRM? What are the steps when CRM Outlook client is installed. I could go on and on.

Sorry to rant, I'm very frustrated as you can tell.

February 13, 2007 4:21 PM
 

Lee said:

You've definitely got it right (JF) about larger organizations.  I have thousands of mailboxes to deal with and it's hairy to say the least.  Since many of our recurring appointments were scheduled just before the beginning of the year, releasing these patches 6 months ago would've been the best benefit.

It comes down to making the decision on whether or not it's worth running the update tool given the multitude of different situations out there.
February 13, 2007 4:28 PM
 

Wayne said:

This patch works fine for me.  However, I cannot get the Exchange Data Update Tool to function.  I have a Exchange 2003/Windows 2003 environment.  No Windows 2000 or Exchange 2000.

I stop msextmzcfg.exe from running (before clicking finish) because it appears that only one user will be updated.  I look in the logs and see

Unable find mailbox timezone:Error 0x80004005

A corrected article or blog post with step by step directions on how to use the tool would be helpful.
February 13, 2007 4:49 PM
 

Jeff said:

Painfully, those of use who are _still_ using Exchange 2000 (and Windows 2000) are left out in the cold. I have 32 remote servers running both and I'm not happy about the lack of support for this issue.
February 13, 2007 5:06 PM
 

Exchange said:

BK,

1. I would not suggest to apply the Windows fixes so far in advance of running the rebasing tool, at least not the client OS fix. That is becasue the newly created meetings (within that week) will also get moved by the rebasing tool even though they will look correct from the client side. If you have so much time between client OS fixes and rebasing tool, then client rebasing tool should be used and the users should choose not to modify the appointments created within that last week.
2. You should apply the OS patch 1st, then CDO patch and then run the rebasing tool. You should be able to do all of those rapidly one after the other.

MW, I think that #1 above adressed your question about if appointments created in the mean time will be broken or not? I have also fixed the URL to the KB, sorry about that!
February 13, 2007 5:19 PM
 

Jason said:

We decided to not even bother with the Exchange rebasing tool. I counted 11 different "issues" in the article (kb930879) and those are just the ones Microsoft knows about. Also we are using a 3rd party patch for Windows 2000 which seems to work better the the Microsoft solution. Not sure MS will let me post the link but here it goes:

http://www.intelliadmin.com/blog/2007/01/unofficial-windows-2000-daylight.html

Sorry MS but not such a great job when you have two years to prepare.
February 13, 2007 5:22 PM
 

BK said:

Thanks for the reply!

There's an event you may find it useful this Friday:

Updates to DST Product Solutions and MSIT's Approach for Microsoft
Link to register: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032327824  
February 13, 2007 5:27 PM
 

Tony said:

I have a fe/be situation, with clustered nodes in the backend. I understand that the FE doesn't house any mailbox data, but the pre-reqs for the backend require serious updates. I haven't patched in awhile so you can imagine my "fear". Do I apply the OS patches via Windows update to the FE first, and then Backend, then update the FE with the Exchange time zone patch, then the backend clusters, then run the CDO from the server? Can I run the patches on the offline nodes first, then move the resources and then update the other servers? Craziness...
February 13, 2007 11:52 PM
 

Tony said:

correction:
on order of deployment question:

FE windows update > BE windows update (offline nodes, move resources, other nodes, virtual servers)> FE Exchange Time zone patch (CDO) > BE Exchange Tme Zone patch(CDO) (offline nodes, move resources, other nodes, virtual server)>  and then calendar update tool?
February 14, 2007 12:25 AM
 

Paul said:

I am disappointed with MS's handling of this as well.  The change is less than a month away, but the client CDO update still isn't available, server hotfixes are still being updated, KB articles are being revised almost daily, and everyone is not singing the same song.  The public webcast yesterday contradicted some info we've been getting from Alliance and Premier, and introduced some entirely new pain points for us.  Why wasn't the Exchange update tool written with asynchronous multithreaded WebDAV so it would run faster than only 3 mailboxes a minute?  I am quite surprised at the way this entire situation has been handled.
February 14, 2007 10:16 AM
 

FoutyTwo said:

It must be nice to work at Microsoft.  They didn't have to worry about patching 2000 or 2003 because they released Exchange 2007 as their own fix.

Forget the consumers and enterprise users once again.  Looks like someone should have spent part of 2006 planning for patching rather than testing out the future of JET.  Looks like DST was left behind just like SQL for Exchange.
February 14, 2007 10:44 AM
 

Joel Stidley's Exchange and PowerShell Blog said:

This article was sent my way and looked pretty serious and possibly commonplace. There is no hotfix for
February 14, 2007 11:16 AM
 

Dan said:

Has anyone actually successfully run the Exchange rebasing tool by following all of the instructions included in the KB! Are you kidding me! I am extremely disappointed in Microsoft's support on the DST changes. Last minute hack job. We encountered several error messages while attempting to run the tool, and there is zero support for this tool at support.microsoft.com.
February 14, 2007 5:28 PM
 

Exchange said:

Dan,

Within few hours I plan on posting (here on the blog) a "Step by step" on how to run the tool as well as some gotchas that we have learned in Support Services (including most common errors and what causes them).
February 14, 2007 5:40 PM
 

Larry Heier said:

In Microsoft's defense, most vendors are late to the game with these patches.  We can all thank Uncle Sam for this one imho.

Anyway I wanted to concur with my colleagues above.  I've got a few clients happily on Exchange 2000 and one migrating off of Exchange 5.5 and even though the patches are done, you have to pay $4,000 to get them.  At the very least, doesn't it make sense for Microsoft to release these Exchange specific patches for these products to keep their customers happy.  I usually defend Microsoft to a lot of the Linux/Apple lovers out there but this is a great example where Microsoft could shine by giving these legacy version patches available for free.

Just my 2 cents.
Larry
February 14, 2007 7:18 PM
 

Aussie said:

I would like to express my great disappoint with DST patching as well. At least the US now has a patch to deploy.

Western Australia entered DST last December 3rd and will be leaving DST in March. As yet there is still no CDO patch! Bugger getting a patch before starting DST, what about getting one before DST finishes!!

We have a large investment in Exchange 2003, with many resource mailboxes using the MS auto accept sink. Most areas have hidden the resource mailboxes from the GAL and reverted to using a pad and pen for room bookings.

I do understand the need for advance warning, which the WA government didn't provide much of to vendors. However the focus on Exchange 2007 over the much, much larger 2003 install base is also disappointing.

sigh ...
February 14, 2007 8:53 PM
 

Myles said:

I totally agree, MS has screwed up once again.

"I've got a few clients happily on Exchange 2000 and one migrating off of Exchange 5.5 and even though the patches are done, you have to pay $4,000 to get them.  At the very least, doesn't it make sense for Microsoft to release these Exchange specific patches for these products to keep their customers happy.  I usually defend Microsoft to a lot of the Linux/Apple lovers out there but this is a great example where Microsoft could shine by giving these legacy version patches available for free."

totally agree, i needed to migrate a client of mine from Exchange 5.5 to 2003 but i couldn't due to a nice bug in the migration software and Exchange 5.5. The only way to get the hotfix that MS had available was to...oh wait, i couldn't, Exchange 5.5 was end of life so there was "noone available who could send me the patch". So my client is stuck on Exchange 5.5. The only fix was to migrate my Clients to Exchange 2003.

The woman in "customer services" was unable to comprehend that this was in fact the whole reason i was asking for the bloody hotfix in the first place. Utterly useless an no customer service.

Once a piece of software has become end of life MS should just release ALL of the hotfixes regardless of their quality (do microsoft even care about the quality of anything?), you dont support it anyway so if people install the hotfix and it goes wrong it is their own tough luck!

As for this patch MS has released, it is extremely shoddy, i have 1 client currently in a downtime situation because there is no fix thanks to some other crappy patch MS released that does not work once this patch has been installed. You guys need to sort this out. If you want the world to keep trusting your software and shunning the trusted and stable platform known as Linux you have to make your software and patch management a lot better (even though Vista is supposed to be the best desktop os I still had to install 13 patches before the official release date!!) and when you do find problems at least test the patch so you know it works before releasing it.

Utterly rubbish patch management by MS.
February 15, 2007 8:38 AM
 

Jennifer said:

Um...is sp2 requuired before the patch to exchange is applied?  For various reasons, we haven't applied sp2 yet.

Thanks!
Jennifer
February 15, 2007 8:44 AM
 

Steven said:

Where are the 'Step-by-Step' instructions mentioned yesterday at 5:40? Those would be really helpful.
February 15, 2007 10:28 AM
 

Myles said:

Yes you NEED SP2 for Exchange 2003 installed before you can install this patch. I am guessing you are safe.

I was able to fix my client's problems by removing the SELF attribute from the ACL on both the public store and the Mailbox store. The both mount now and all things are good!!
February 15, 2007 10:30 AM
 

Chris said:

The main Microsoft DST page says that there will be a CDO patch for Exchange 2003 SP1 "in February."  Since SP2 appears to cause more problems than it fixes, I'm hoping this patch will be released before we run out of time.
February 15, 2007 11:18 AM
 

Todd said:

Chris, is this patch for Exchange 2003 SP1 different than the CDO patch you refer to?

http://support.microsoft.com/kb/931978/

/really confused
February 15, 2007 11:35 AM
 

Chris said:

That looks like the one!  Thanks.  Someone needs to update http://support.microsoft.com/gp/dst_topissues#A6; that's what I've been checking.

February 15, 2007 12:04 PM
 

Todd said:

Whew... I'm breathing easier (I too have SP1 at many sites). Here you go folks:

Exchange 2003 SP1
http://support.microsoft.com/kb/931978/

Exchange 2003 SP2
http://support.microsoft.com/kb/926666/
February 15, 2007 12:37 PM
 

Alice said:

I run W2k server with Exch 2k and outlook 2k.  Here is what I have gleaned from the far too many conflicting and changing resources on this topic:
update the OS
update Exchange 2k with the Exch DST Update tool, which costs $4000
update mailboxes with the Exch Calendar Update tool

However, what we will probably do is update the server & client OS's, then just run the outlook calendar update tool.

Does anyone know if that will serve the same purpose?
February 15, 2007 3:08 PM
 

Mary said:

What about clustered exchange servers????
February 15, 2007 4:04 PM
 

Larry Heier said:

Hello,

I have a question running the rebasing tool.   When you run either the server or client version, will the recurring and one off meetings cause the meeting participants to receive messages to accept/reject the meetings again?  

So theoretically all meetings booked within 3/11 and 4/1 will cause all a flood of messages to each attendee across the board?

thanks,
Larry
February 15, 2007 4:09 PM
 

Tony said:

Mary,

I'm assuming it would be handled as other patches would be. one at a time, offline first.
February 15, 2007 4:26 PM
 

Steven said:

Here's a dumb question. After running .bat that MsExTMZCFG creates, what do you look for in the msextmz.log to see if the tool worked? Do we just assume that it worked if error log is blank?
February 15, 2007 6:13 PM
 

Gene said:

We too use Exchange server 2003 SP1.  We have not upgraded to SP2 for various reasons (including the fact that we tried to install the original IMF after SP1 and it just hosed up our system on 3 install attempts- thought that SP2 with integrated IMF would do the same).  The problem with the CDO patch for SP1 is that Microsoft will not support if there are problems (I was told yesterday by the folks at  Microsoft support that they don't support SP1 any longer-even though they put out a patch for it).  So if you install the CDO patch for SP1 and it messes up your Exchange server (it womped my OWA on a test server), Microsoft will not help you.  I wish that a third party vendor would quickly enter this fray and offer a decent, reliable solution.
February 15, 2007 8:35 PM
 

Exchange said:

Gene,

Well - that's the 1st time I hard of this I must say and I work very close to support group. We just released this version of the fix a week ago, there is no way that we do not support customers that install it.

If someone from MS tells you that this is not supported - please have them email me internally (i linked to my Bio - click on Exchange link in this comment), I want to understand what is going on. The KB mentions nothing of this.
February 15, 2007 8:47 PM
 

Jim said:

Hi Everyone:

Last night I had the honor of swimming through the sea of Exchange, BES and the DST update and here's what bit me in the butt and how to address it.

First things first, Microsoft really should state that this will impact BES and other apps and not as they've said "May Affect".  In my opinion that it's weak writing that they did to not draw attention to the fact that the change they are forcing out will break these other apps.

My first mistake was that I read MS KB article 912918 with the current mindset.  The article points out that store.exe version 6.5.7650.xx and later are affected by the Send As permission change.  I looked at my server which was running 6.5.7638.xx and felt that I was in the clear.  The factor that I left out was that my store.exe version after installing the patch is 6.5.7651.61, which will be impacted.

In reading the articles there is a way to block some of these changes, but as it was a late night, I cannot find it.  I do have the solutions from Microsoft on how to deal with this issue.

Grant the BES Service account Send As permissions to all standard users:
Open ADUC and access the properties on the domain mydomain.com  and add the BES service account with Send As permissions on User Objects.  This should be done on all domains that have BES user accounts.

907434 - Priveledged Accounts settings are applied differently:
If you have a BES account that is a member of a Priveledged group (domain admin, dhcp admin, etc..) the ADMINSDHOLDER is a security template that applies a specific set of security permissions to all Priveledged accounts.  This is done to help prevent the admin accounts from being compromised.  You will have to run the DSACLS command listed in kb 907434 on each domain to grant the BES service account Send As permissions to the template.

After making these changes you will need to down the BES services for at least 20-30 minutes to clear the cache.  Further, it took my environment 2 hours to fully replicate the settings in to the AD, Information Store and BES Router.  I don't know why it took so long as the primary systems are in the same site, but it did.

Have patience and I hope this saves all of you the sleep I missed out on.

Good Luck!
Jim
February 16, 2007 12:00 PM
 

sean said:

One question with respect to the bug filed for 926666, store mount problems:

i ran dsacls.exe against all of my stores and see that it has some of the well-known groups inherited.  is this a problem ? or are we only looking for well-known groups granted explicit rights ?

February 16, 2007 12:40 PM
 

subject: exchange said:

Preserving Nickname Cache in Exchange Migrations Apple challenges Microsoft Exchange Google to Replace
February 19, 2007 4:40 AM
 

Matthew Byrd said:

In Response to Sean;

The thing to realize that I admit is not massivly clear in the article is that you are not affected by the Well known accounts issue unless you have multiple domains.  If you are in a single domain structure this will not affect you.

To more directly address your concern about inherited vs explicti.  The answer is you have to deal with BOTH.  The check algorithm does not care if the group is inheritied or explict.  If it is defined on the store it will be checked.

-Matt
February 19, 2007 9:42 AM
 

bpierini said:

has anyone seen this error - and more importantly, a workaround? i have diligently followed every step of several documents, and cannot get by this, nothing much in the logs, this is from the "msextmz.log"
Processing Mailbox:/O=EXCH3-7/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=BH
PRFFile set to C:\newtest\MsExTmz\MSExTmz-BH-0x0FA37CEF.PRF.
Spawned outlook process as pid - 3048.
Unable Open mailbox - 0x8004011D.
Error Processing Mailbox:/O=EXCH3-7/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=BH - 0x8004011D

This occurs with every mailbox.
thx
-bill
February 19, 2007 7:51 PM
 

Mike said:

http://support.microsoft.com/kb/930879/en-us

This just came out.  It looks like Microsoft has added support for Exchange 2000 and 5.5.

Guess there has been a lot of pressure for this.  I know I sure needed it.
February 20, 2007 12:33 AM
 

bpierini said:

has anyone seen this error - and more importantly, a workaround? i have diligently followed every step of several documents, and cannot get by this, nothing much in the logs, this is from the "msextmz.log"
Processing Mailbox:/O=EXCH3-7/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=BH
PRFFile set to C:\newtest\MsExTmz\MSExTmz-BH-0x0FA37CEF.PRF.
Spawned outlook process as pid - 3048.
Unable Open mailbox - 0x8004011D.
Error Processing Mailbox:/O=EXCH3-7/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=BH - 0x8004011D

This occurs with every mailbox.
thx
-bill
February 20, 2007 10:08 AM
 

Bruce Roberts said:

Hi, I'm a smaller shop. W2003 and Exchange 2003 with 2 servers FE and BE. The SP2 hotfix for DST KB926666 took my info stores completely offline. After some searching I did find this KB article - Information Store database does not mount with Event ID 9519 and 9518. That is exactly what happened to me. But, I am only a single domain shop and I only saw appropriate user accounts with delagated access in system manager. I don't know why my servers both tripped this error - and now i'm waiting for the hotfix to the hotfix. I could use some more detail on how resolve the problem detailed by KB932599. Bruce Roberts - broberts@jfwhite.com
February 20, 2007 10:51 AM
 

KB said:

Just ran the DST update on my server, THANKS MICROSOFT WHAT A PAIN IN MY BUTT
February 20, 2007 11:49 AM
 

goldfinger said:

When can we get the hotfix for EventID 9519 and 9518 for DST patch?
This way we won't break the IS on clients network with working mail servers!
February 20, 2007 2:17 PM
 

Matthew Byrd said:

The hotifx is still in the works.  I have requested an update from our development group but have not seen anything new on this.  From the progress of the bug it should be releasing very soon.
February 20, 2007 4:58 PM
 

Kris said:

What exactly does choosing the timezone for a mail account do when running the exchange tool to fix calendars.  We have users from multiple time zones using one server located in a central site.  If we decide to use the Exchange Calendar Update Tool not the client tool and choose the wronge time zone, what can happen?
February 20, 2007 4:58 PM
 

Gene said:

I watched a Microsoft webcast today (2/20/07) where they mentioned that the previously suggested patching order has been changed especially if you have heavy users of OWA.  Sounds like they are also re-working the TZMOVE tool and the server side wrapper to make it work better especially with resource calendars.  I still can't imagine why a multi-billion dollar company like Microsoft put together a cheap little wrapper that uses paths to "TZMOVE", "Outlook" and batch file commands.  You would think that they would understand how critical Exchange calendaring is and provide a professional server side tool to use.  I continue to test with TZMOVE on the client side and it only correctly adjusts about 50% of recurring appts.  I may just skip TZMOVE and have users correct their own entries.
February 20, 2007 9:10 PM
 

Simon said:

I updated my Windows 2003 system, THOUGHT I also ran the CDO fix (maybe I didn't??), ran the calendar updates with the Exchange wrapper/TZMOVE tool (100% success with 170 mailboxes, better than I had hoped for). All the XP updates are applied through WSUS, so I'm in pretty good shape.

However, webmail (OWA) still shows the wrong time info for dates between March 11 and April 1st. (Outlook is fine, Mobile 5 devices with updates applied are fine). I re-ran the CDO fix (Exchange with SP2) but still no change. Any ideas what might be wrong?

Despite the slow start, thanks for all the work lately!
February 21, 2007 11:21 AM
 

Gene said:

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.

February 21, 2007 12:45 PM
 

nicatnite303 said:

I have asked Microsoft this in webcasts, and posted on this site as well... and not surprisingly, I have not received any official response. Maybe I will have better luck here:

For those of us who have Exchange Servers in the US, but have customers located outside the US, what specific time zones do we need to run the Exchange Update tool against. In last Friday's webcast they mentioned that you didn't need to run the Exchange tool against any "non-affected" TZ's, but then didn't give guidance as to what specifically those were.  They stated that some 40+ TZ's made adjustments, but we are unsure if that means we need to run the Exchange Tool against those as well... and if so, what are they?

February 21, 2007 2:39 PM
 

John said:

New tool Ver 2
Installed ok on one system the other - " Unable to install becouse of a previous version of Microsoft Exchange Calender Update Tool ...... Unistall and run setup again"
I have done this and pored through the registry 3 time. Reinstalled the old ver, tried to go over top, ..... same thing
February 21, 2007 7:04 PM
 

goldfinger said:

This version 2 tool I think is useless until hotfix is available for event ID 9518,9519 of IS. Can't use this tool when the store is not mounted!
February 21, 2007 8:22 PM
 

John said:

I found this tool that will remove the application correctly and allow it to be reinstalled
http://support.microsoft.com/kb/290301
February 21, 2007 8:31 PM
 

sean said:

@matt byrd:

thanks matt.  unfortunately we have an empty root and another domain, so we are multi.  let me pose this question:

if i have installed 926666 in my environment and not had this problem, and i assume further that i have not played with any permissions at the storage group/db level (ie, i let all my sg/db inherit from the admin group and org ACLs), then i should not have this problem, correct ?
February 22, 2007 12:17 AM
 

Jason said:

I have one question......

Is it a MUST that I run the Exchange Calendar Update Tool?  Or can I have users just delete the calendar entries that are an hour off and recreate them?

That "Tool" does not give me a good feeling, and neither did MS support.

Thanks
February 22, 2007 11:29 AM
 

Exchange said:

goldfinger: You should still be able to manually clean up the account that cause the problem in the 1st place as mentioned in the article.

Jason - if you wanted to do that, that would work, yes, s long as server and clients are patched before you created new apointments.
February 22, 2007 12:59 PM
 

Tanky_belle said:

I installed 926666 and the store wouldn't mount as has been documented on this blog. We don't delegate to any common accounts so the fix wouldn't apply. 4 hours of adsiedit.msc later I ended up rolling back the patch. We use OWA so need the fixes it contains.

Will there be a new version of the 926666 patch which doesn't kill the mailbox store and if so will it be available before the new DST start date?
February 22, 2007 3:36 PM
 

President Carter said:

I just spoke with an MS rep who said the patch for 92666 that fixes unmountable Mail Stores (KB 932599) will be released at end of business today.
February 22, 2007 3:38 PM
 

Dr. No said:

Very confusing to say the least. Question: I'm using Exchange 2000 in my environment. Looks like I need to run the Exchange Time Zone Update tool for multiple users (KB930879), but there is also KB 926666 (Exchange Server update). Do I really need KB 926666? This is the one that Microsoft wants to charge you on.............can you say Y2K Junior!
February 22, 2007 4:04 PM
 

JCLark said:

My MS rep said the hotfix is on the servers waiting to get downloaded.  Here is a link the the new kb he sent me.
http://support.microsoft.com/?kbid=930241.
February 22, 2007 5:13 PM
 

Greg said:

I just tried getting the hotfix via my Technet Online Concierge and the rep said it wasn't available yet. This was as of 4:37 (PST)...
February 22, 2007 7:38 PM
 

JCLark said:

I have it if you want it.  Email me at ladyiguanacc@yahoo.com.
February 22, 2007 7:47 PM
 

Adam said:

The link on the kb article page doesn't work but you can do a search for the patch at download.microsoft.com which leads you to this page -

http://www.microsoft.com/downloads/details.aspx?FamilyID=2a835a09-8e57-4027-a488-1e61c4b43a10&DisplayLang=en

Hope this helps!
Also, nicatnite303 mentioned that in last Friday's webcast it was said that you do not have to run the Exchange Calender Update Tool against non affected timezones. Is this correct? We're in the UK, so we don't have to run this tool, right?

TIA Adam
February 23, 2007 4:04 AM
 

goldfinger said:

KB article 930241 is at MS web site; however the link to download does not work.
February 23, 2007 9:43 AM
 

Shawn said:

Same here.
    Still waiting for MS to fix the broken link for KB article 930241. Anyone know of a mirror site that might be hosting this new hotfix?
February 23, 2007 11:43 AM
 

Exchange said:

I have just updated the above post with the links to the KB article and the direct link to the hotfix location. We are fixing that bad download link in the KB too.
February 23, 2007 11:47 AM
 

Raymond said:

Hello, i have small business server with exchange built into it do i have to just update small business server or do i have to do both fixes for daylight savings time
February 23, 2007 12:59 PM
 

JaySee said:

Hello. I have patched the OS for DST on all of our W2k3 Exch2k3 machines. One FE v7638.20, 3 BE 2x7650.28, 2x7638.20. It’s a mess I know. About 300 Win client OSs have been patched also. Didn’t realize everything needed to happen in the same time frame when I started this thing, was just following the order I thought was correct. Server OS, client OS, Exchange patch, mailbox tool.

So now users are seeing incorrect times on their appointments.

Should I go ahead and run the kb926666, then the just released kb930241 if my stores don’t mount, and then run the exchange tool (Msextmzcfg.exe) on all mailboxes, and if so just for just recurring appointments?

Or leave as is and let the damage be done?
February 23, 2007 7:56 PM
 

Humayun said:

Hi, I have been reading this blog and I am all confuse as the rest of you and I am looking for the proper sequence and KB updates to fix the DST on W2K3 SP1 and Exchange 2003 SP2 cluster (2 node cluster A/P) along with BES for Exchange ver 4.1. Also XP SP2 and outlook 2003. I have found the link below title "Daylight Saving Time Help and Support Center"

http://support.microsoft.com/gp/cp_dst

February 23, 2007 8:48 PM
 

President Carter said:

It would be very nice to have a tool for Public Folders.  I am currently analyzing our Public Folder environment, trying to work out a plan, and it looks like we have approximately 500 calendars.  I'm running across permissions issues galore (those alone seem to be impossible to wrap my head around), and any time I run the tool I get "No appointments, meetings or reminders were found that need to be moved to the new time zone."  However, as I'm looking at the calendar there are clearly DOZENS of appointments in the DST delta window.

After over a week of banging my head against the wall on this, I'm starting to regret not using this time to simply plan for upgrading our Exchange environment to 2007.  Maybe this is the true, underhanded plan (kidding).

Thanks for the hard work Exchange Team... I'm sure (or at least hope) you're all working at least as many hours as I am.
February 26, 2007 10:22 AM
 

Greg B said:

Hi, when running the Exchange Calendar tool did anyone find an answer for the 80004005 errors other than running the Outlook calendar tool. We tried over the weekend but had no success with the Exchange tool and now are looking at trying again next weekend. We also had the Send As issues with BES with the CDO patch and ended up reversing this patch.
February 26, 2007 10:27 AM
 

CB said:

My plan is to let users update their own Outlook with tzmove.exe. The OS patch has been deployed via WindowsUpdate as critical so they are all going to install it first and then update with tzmove.

My only question is the timing of it all. If users update their own OS and run tzmove before I install the patch on the Exchange server will that muck everything up?

The server-side update tool (msextmzcfg) is not really an option. Too many users to update without being able to make sure it is working properly.
February 26, 2007 10:30 AM
 

goldfinger said:

Does any one have a method to extract legacy DNs of the user mailboxes that are delimited by CRLF as explained in KB 930879?
February 26, 2007 3:04 PM
 

President Carter said:

Yes, Goldfinger use the MSEXTMZCFG.exe tool against your exchange server.  Then, use Excel to remove the extra data (msextmzcfg's output is in tab-delimited format) from your output files.  When you open the files in Excel (or OO.org), Column A will be the LegacyDNs.
February 26, 2007 3:16 PM
 

AK said:

After installing 926666 on our Exchange 2003 server, OWA "partially" broke.  Login worked and the main interface looked fine, but any attempt to open any item would return "500: Internal Server Error."  I could open items through OMA and see them properly.

I uninstalled 926666 after finding a posting in microsoft.public.exchange.admin describing the same issue and it seems to have fixed the problem.

Anyone else seen anything similar?
February 27, 2007 10:29 AM
 

alricthemad said:

I ran the patches with out issue here
Win2K3 Standard SP1, Exchange 2K3 Standard SP2, Outlook 2003.
Workstations were updated manually. XP update the Outlook update tool.

The only problem I have is shared calendars. Not all appointments are showing correctly.

Is anyone else seeing this problem?
February 27, 2007 1:44 PM
 

DSTDisapointed said:

I ran the Exchange Calendar Tool
Errors with the 0x80004005 during the first step on all but 19 Mailboxes
Then I get the 0x8004011D when running the Batch File on all but the 19 Mailboxes
When you look in the Output.txt file, those 19 are the only one showing up  with the Eastern Standard Time Zone...
The remaining mailboxes are getting the message stating Unable to Find TimeZone...
This is not fun and is not working
I have tried the GrantMailboxPermission.vbs but it does not put the Mailboxes from the Output.txt
I am lost
March 1, 2007 10:04 AM
 

DTS Insanity said:

After countless hours spent pouring over updates and patches and new patches and new versions of tools and fixes for patches and fixes for fixes for patches (you get the idea) ALL systems are patched HOWEVER we have inconsistencies with appointments when veiwed from different systems (Windows 2000, Server 2003, and XP Pro) using Outlook 2003 or OWA.  Nothing makes sense...these are not recurring appointments just single instance.

HELP!!!!!!!!!!!!!!!!!!!!!!!!!!!!
March 1, 2007 2:04 PM
 

hied_northeast said:

The Microsoft Team has posted a blog on the DST Process here: http://msexchangeteam.com/archive/2007/02/13/435208.aspx
March 1, 2007 3:39 PM
 

Derekb said:

I see in the Exchange Calendar update tool, they've removed the Exchange 5.5 references now...
March 1, 2007 6:00 PM
 

Mikhail said:

We spent 3 hours on hold waiting for a MS tech yesterday, then 7 hours working on the solution.  Finally, we seem to have the exchange tool working.  This is not an easy fix!!
March 2, 2007 12:41 PM
 

Tony said:

I'm in the same boat as DTS Insanity, but when I ran the updated rebase tool on a client during my round 2 clean up, it found calendar items for a user that it didn't find when I ran it on the server side the first time.

Also, the MS people on this blog only answer questions you can find on the faqs. How come there is never a response to the more advanced questions?
March 2, 2007 1:11 PM
 

Derek said:

What order do we run everything in?  I have the Windows 2003 OS patch, then the Excahge Calendar tool, then the Exchange 2003 SP2 DST Patch.  Is this correct?
March 5, 2007 2:09 PM
 

Jason said:

Derek, If you're reading KB930879, I'm reading it the same as you. I just got done running the Calendar Update Tool on my BE servers (saw both the 0x8004011D and 0x80004005 errors) and plan on running the CDO patch tomorrow night.

If all goes horribly awry, MS does offer "server down critical LAN outages or escalated, "business down" customer situations." If the patches mess you up, go to the source for assistance.

See: https://partner.microsoft.com/US/program/programoverview/40023584 and look under "Support My Customers." You will need to sign up as a Registered Member (if you're not already) but the assistance is well worth it (IMO).

Good luck to all.
March 5, 2007 6:14 PM
 

Ray said:

After reading all these threads, I wonder if MS provides a step by step solution on how to handle the DST changes.

For example, how to check the current system is  using the old/new DST.
how to update the exchange server, how to update the client side (outlook etc)

I did Linux update for DST months ago. And the whole procedure was clear and easy to implement. Hope the same for MS.

Thanks.
March 6, 2007 11:39 AM
 

cschlegs said:

so is there an answert o this problem or what?  my colleges and i are still sitting here scratching our heads trying to figure out why the tools provided do not work.  We are getting the "no appointments, or whatever need to be modified message.
March 6, 2007 2:47 PM
 

sean said:

We've completed patching as per all best practices but still have encountered one problem.  When creating meetings on a Blackberry device (thourhg BES) or even on a windows mobile device the meeting shows up one hour ahead in Outlook. All BB's, mobile devices, desktops, servers, exchange, Bes and mailbox patches have been applied. Checked with another company who also thought they were fully patched and they are experiencing the same symptoms. Anyone else seen this or have any ideas?
March 6, 2007 3:05 PM
 

Mikhail said:

We just tested that here, Sean.  It worked fine from our blackberry devices.  We are running BES version 4.0, service pack 6.
March 6, 2007 4:58 PM
 

Absoblogginlutely said:

We received an email from Verizon to inform us that the Monitorsync software that synchronizes Exchange with Verizon's web service (and then cellphones) also needs a patch for daylight savings time. Great timing with less than a week to go!...
March 6, 2007 11:29 PM
 

DeNero's waiting said:

Perfect timing for our Admin to leave us. Now I am stuck with this task. I plan on running the Outlook tool for each user individually. I know it ounds insane, but we have to hold our users' hands for everything and running the server tool is out of the question. Can any of you tell me how I can go about setting up the Admin profile to have full access to all mailboxes