Exchange 2003 and DST fix (KB 926666)
Published Feb 13 2007 02:48 PM 12.6K Views

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&displa...

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

104 Comments
Not applicable
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!
Not applicable
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.

Not applicable
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.

Not applicable
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.
Not applicable
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.
Not applicable
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.
Not applicable
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!
Not applicable
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.
Not applicable
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  

Not applicable
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...
Not applicable
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?
Not applicable
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.
Not applicable
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.
Not applicable
This article was sent my way and looked pretty serious and possibly commonplace. There is no hotfix for
Not applicable
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.
Not applicable
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).
Not applicable
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
Not applicable
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 ...
Not applicable
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.
Not applicable
Um...is sp2 requuired before the patch to exchange is applied?  For various reasons, we haven't applied sp2 yet.

Thanks!
Jennifer
Not applicable
Where are the 'Step-by-Step' instructions mentioned yesterday at 5:40? Those would be really helpful.
Not applicable
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!!
Not applicable
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.
Not applicable
Chris, is this patch for Exchange 2003 SP1 different than the CDO patch you refer to?

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

/really confused
Not applicable
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.



Not applicable
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/
Not applicable
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?
Not applicable
What about clustered exchange servers????
Not applicable
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
Not applicable
Mary,

I'm assuming it would be handled as other patches would be. one at a time, offline first.
Not applicable
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?
Not applicable
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.
Not applicable
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.
Not applicable
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
Not applicable
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 ?

Not applicable
Preserving Nickname Cache in Exchange Migrations Apple challenges Microsoft Exchange Google to Replace
Not applicable
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
Not applicable
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: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.


thx


-bill


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


thx


-bill


Not applicable
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
Not applicable
Just ran the DST update on my server, THANKS MICROSOFT WHAT A PAIN IN MY BUTT
Not applicable
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!
Not applicable
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.
Not applicable
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?
Not applicable
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.
Not applicable
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!
Not applicable
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.

Not applicable
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?

Not applicable
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
Version history
Last update:
‎Jul 01 2019 03:24 PM
Updated by: