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;EN-US;930241

The hotfix can be downloaded from here:

For anyone who has used the workaround outlined in:

932599  Information Store database does not mount with Event ID 9519 and 9518;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

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

"Send As" permission behavior change in Exchange 2003

Users cannot send e-mail messages from a mobile device or from a shared mailbox in Exchange 2000 Server and in Exchange Server 2003

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;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

- Matthew Byrd

Comments (104)
  1. BK says:

    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?


  2. JF says:

    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.

  3. MW says:

    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.

  4. lee says:

    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.

  5. Wayne says:

    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.

  6. Jeff25 says:

    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.

  7. Exchange says:


    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!

  8. Jason says:

    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:

    Sorry MS but not such a great job when you have two years to prepare.

  9. BK says:

    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:  

  10. tony says:

    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…

  11. tony says:


    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?

  12. paul says:

    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.

  13. FoutyTwo says:

    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.

  14. Anonymous says:

    This article was sent my way and looked pretty serious and possibly commonplace. There is no hotfix for

  15. Dan_IT says:

    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

  16. Exchange says:


    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).

  17. Larry Heier says:

    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.


  18. 0aussie0 says:

    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 …

  19. Myles says:

    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.

  20. Jennifer says:

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



  21. Steven says:

    Where are the ‘Step-by-Step’ instructions mentioned yesterday at 5:40? Those would be really helpful.

  22. Myles says:

    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!!

  23. Chris says:

    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.

  24. Todd says:

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

    /really confused

  25. Chris says:

    That looks like the one!  Thanks.  Someone needs to update; that’s what I’ve been checking.

  26. Todd says:

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

    Exchange 2003 SP1

    Exchange 2003 SP2

  27. Alice says:

    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?

  28. Mary says:

    What about clustered exchange servers????

  29. Larry Heier says:


    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?



  30. tony says:


    I’m assuming it would be handled as other patches would be. one at a time, offline first.

  31. Steven says:

    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?

  32. Gene says:

    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.

  33. Exchange says:


    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.

  34. jim says:

    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  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!


  35. Sean says:

    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 ?

  36. Anonymous says:

    Preserving Nickname Cache in Exchange Migrations Apple challenges Microsoft Exchange Google to Replace

  37. Matthew Byrd says:

    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.


  38. bpierini says:

    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"


    PRFFile set to C:newtestMsExTmzMSExTmz-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.



  39. mike says:

    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.

  40. bpierini says:

    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"


    PRFFile set to C:newtestMsExTmzMSExTmz-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.



  41. Bruce Roberts says:

    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 –

  42. KB says:

    Just ran the DST update on my server, THANKS MICROSOFT WHAT A PAIN IN MY BUTT

  43. goldfinger says:

    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!

  44. Matthew Byrd says:

    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.

  45. Kris says:

    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?

  46. Gene says:

    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.

  47. Simon says:

    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!

  48. Gene says:

    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.

  49. nicatnite303 says:

    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?

  50. John says:

    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

  51. goldfinger says:

    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!

  52. John says:

    I found this tool that will remove the application correctly and allow it to be reinstalled

  53. Sean says:

    @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 ?

  54. Jason says:

    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.


  55. Exchange says:

    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.

  56. Tanky_belle says:

    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?

  57. President Carter says:

    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.

  58. Dr. No says:

    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!

  59. JCLark says:

    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.

  60. Greg Lambert says:

    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)…

  61. JCLark says:

    I have it if you want it.  Email me at

  62. adam says:

    The link on the kb article page doesn’t work but you can do a search for the patch at which leads you to this page –

    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

  63. goldfinger says:

    KB article 930241 is at MS web site; however the link to download does not work.

  64. shawn says:

    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?

  65. Exchange says:

    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.

  66. Raymond says:

    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

  67. JaySee says:

    Hello. I have patched the OS for DST on all of our W2k3 Exch2k3 machines. One FE v7638.20, 3 BE 2×7650.28, 2×7638.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?

  68. Humayun says:

    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"

  69. President Carter says:

    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.

  70. Greg B says:

    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.

  71. CB says:

    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.

  72. goldfinger says:

    Does any one have a method to extract legacy DNs of the user mailboxes that are delimited by CRLF as explained in KB 930879?

  73. President Carter says:

    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, Column A will be the LegacyDNs.

  74. AK says:

    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 describing the same issue and it seems to have fixed the problem.

    Anyone else seen anything similar?

  75. alricthemad says:

    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?

  76. DSTDisapointed says:

    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

  77. DTS Insanity says:

    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.


  78. Anonymous says:

    The Microsoft Team has posted a blog on the DST Process here:

  79. Derekb says:

    I see in the Exchange Calendar update tool, they’ve removed the Exchange 5.5 references now…

  80. mikhail says:

    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!!

  81. tony says:

    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?

  82. 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?

  83. Jason says:

    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: 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.

  84. Ray Avila says:

    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.


  85. cschlegs says:

    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.

  86. Sean says:

    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?

  87. mikhail says:

    We just tested that here, Sean.  It worked fine from our blackberry devices.  We are running BES version 4.0, service pack 6.

  88. Anonymous says:

    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!…

  89. DeNero's waiting says:

    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 in Server 2003 SP1/Exchange 2003 SP2?

    Good luck to everyone. I think MS is really shooting themselves in the foot.

  90. BigBadJohnnyB says:

    So those of us running Exchange 2003 on Windows 2003 and running A/P clusters…

    I’m reading from various posts that you should patch the idle node first for both Windows and Exchange, reboot it once all that’s done, then slide services over to that guy, then patch up what was the active guy…

    Based on what I’m reading though, I’m wondering if I should be patching my live guy first, so that I can fall back on my un-666’ed server if my stores don’t come back. Does this make sense?

    Of course, that only works if this patch (the OS and 666 patches) aren’t doing anything to the store that an unpatched node can’t understand and mount. Seems to make sense to me… that’s why we need the tool to go in and invasively fix the stores data, because the patch itself isn’t doing anything to the store or store information, just the binaries of the "program" of Exchange and Windows. So if I turn off my passive node, patch my active server, and it all goes to hell – can I just shut down my active server and power on my passive and make him the new active?

    I realize that won’t fix the issue, but at least I’m not left with an unmountable store for an extended amount of time…

  91. shane says:

    We run a clustered Exchange 2003 SP1 Environment with an OWA server running Exchange 2003 SP1 both systems have been patched; however, there is a discrepency between in the calendar events that are viewed on OWA or the Outlook client.  Has anyone experienced this same problem and figured out the workaround on this?  Any help would be greatly appreciated.

  92. BigBadJohnnyB says:

    Shane – have you tried rebooting the OWA server? Even though its not supposed to need that, I think all the CDO DLL’s being updated might play into your problem, and those likely aren’t going to take effect until you reboot.

  93. Gene says:

    Did our Exchange server 2003 SP1 CDO patch tonight (before rebasing calendars because most of our OWA use was light).  After rebasing calendars, Outlook looked good but OWA was still off by (1) hour.  Found that if I accessed a calendar in OWA and opened a recurring event (opened the series) and just saved the appt, it then corrected itself.  Re-booting did not seem to fix this problem.

  94. NeedHelp says:

    I need a little help here. I ran the rebasing tool agianst our Exchange Server tonight and all ran fine, except for one mailbox that produces an error 0x8100270D. I can’t find more information on this. Does anyone know what is causing this error?

  95. ConfusionRains says:

    If we use the 4000.00$ MS patch on our Exch2000 server do we still have to update each mail boxes appointments?

  96. ConfusionRains says:

    Sorry for the double post.

    I forgot to ask, What exactly does the 4000.00$ patch do for MS Exchange. I think the KB is 928225 but I’m not sure.

  97. 7:00 OClock now and 7:00 DST- Quinn Brewer says:

    Is this not the same time in outlook?

    When running the process I see time jump 1 hour forward and then have to run the tzmove on the client pc to fix this issue. What is the point. I am a geek but I don’t need to prove to the company I can change time.

  98. DSTFRUST says:

    Has anyone have the soultion for "Unable Open mailbox – 0x8004011D" error? I have all the neccessary rights for the account used, and checked in Exchange System Manager and AD but still got the error. Any thoughts?

  99. Omar says:

    I have been assigned to handle the issue with the revised DST where I work. First I’ll say what we run, then what has happened so far.

    We have a Windows 2000 AD domain running four DCs, and an Exchange 2000 Server that I recently updated to Enterprise Edition.

    I have done the following to address DST 2007:

    – Created a registry file as per KB 914387 and imported into the registry of all Windows 2000 servers and workstations.

    – XP clients received the DST 2007 update through WSUS.

    – For the Exchange server, it was a multi-step process. First, I ran the Msextmzcfg.exe tool as per KB 930879 in extraction mode. This wrote all existing email accounts in the private store into an export file, then it allowed to select a timezone to be applied to all the discovered mailboxes. I excluded recurring appointments at the time that I ran it pending the outcome of the regular appointments on all the accounts.

    I granted myself "Send on Behalf of" permission for everyone using that GrandMailboxPermission script.

    After this finished, I used the Msextmzcfg.exe again in update mode. After modifying the INI file a bit so it knew where to look for what, it went through every single mailbox specified in the export file. It first tried to find a timezone file for each mailbox, and when it didn’t find it, it proceeded to set the timezone I specified previously.

    I did encounter this error on every mailbox:

    HrProcessInputFile:Processing Mailbox:/O=ISABELLA/OU=NYC01/CN=RECIPIENTS/CN=LEHMAEL1

    HrProcessMailbox:Timezone set to EASTERN STANDARD TIME.

    HrSpawnOLTool:Spawned worker process as pid – 1680.

    HrScanEventLogForSuccess:Success Event not found in Application log, treating as failure.

    HrProcessMailbox:Unable to process mailbox /O=ISABELLA/OU=NYC01/CN=RECIPIENTS/CN=LEHMAEL1 – 0x80004005

    HrProcessInputFile:Error Processing Mailbox:/O=ISABELLA/OU=NYC01/CN=RECIPIENTS/CN=LEHMAEL1 – 0x80004005

    However, after the utility finished running, users did encounter changes to their mailboxes. Some reported recurring all-day events changed to a specific time, resulting in calendar events spawning two days instead of one.

    Due to focusing on the mailboxes, I forgot to address the public store, and there are several items affected by DST 2007. Unfortunately, I can’t seem to find a way or a tool to effect the appropriate changes in it.

    So I guess I have several questions…

    Is there a way to run the update tool on the public store? Anyone figure this out?

    Why do I get failure messages when running the update tool on the mailboxes, or is this merely a false negative?



  100. Omar says:


    Thanks for the links, much appreciated.

    I had already tried what the video shows. After digging around, I realized that I was neither the owner nor the reviewer for many of the calendars in the public store. After applying those changes the tool ran beautifully.

    As for the Exchange tool, the problem was the missing DLL file. I copied it to the directory where I was running the tool from and that also went smooth.

    I’m having my boss check his calendar entries and so far it looks like everything is back in place, or at least most of it.

    Until the next Microsoft hurdle….

    Thanks for your help


  101. Clark says:

    After applying the DST patch some of our users would get a 500 error trying to use OWA.  I called Microsoft and they suggested appling  The description is "The Exchange 2003 database does not mount, and event IDs 9518 and 9519 are logged in the Application log" but it did resolve the issue.


  102. scooter says:

    I have users using OMA on their phones and even though our Exchange servers are patched their appointments are off by 1 hour.[1 hour earlier] If their appointments are checked in Outlook or OWA they are at the correct time. It is not the phone as we get the same results if we open OMA in a workstation IE.

    Called PSS and they acknowledged that this is an issue but there was no fix.

    How can Microsoft ignore this issue when it is part of the code?

    Will there be a fix or are my OMA users just going to have to wait till April 1st? Then deal with it Oct 28th?

    It would have been better to know this was an issue before having to test and prove it was ideed an issue and not only in my environment.

  103. Lynnie S says:

    Exchange 2003sp2, OS patched, cdo patched, 666’d. We have had so many issues with the aftermath of running the tool that we’ve worked around- too many to count, but here’s a new one: our Outlook 2007 users’ calendars are completely fubar’d. We’re seeing appointments that are randomly rebased- some done, some not given the same set of circumstances (like recurrence, originator, when made; like that). The scariest thing I’ve seen yet is these users’ appointments were screwed up in MAY!! Beyond the 3 week extended hell period! All day appointments that went from 12am-11:59pm were shifted forward 1 hour so that now the appointments go from 1am to 1am the next day, and the all day appointment now spans 2 days. What on earth to do about THIS??

Comments are closed.

Skip to main content