Potential issues with DST patching
In working with the series of Daylight Saving Time patches that have been released, I wanted to highlight some of the issue that can be encountered. Thus far, I have found four issues that can be encountered. Each one is fairly unique, and some of them have been covered on the Exchange Team blog at the following link:
https://msexchangeteam.com/archive/2007/02/13/43520...
The first potential issue is that the Exchange DST CDO patch from KB926666 also includes an updated build of store.exe. This issue is documented in KB912918, and included a change to the Send As behavior. Prior to this fix, Full Mailbox Access also granted Send As rights. Due to customer requests, this behavior was changed. As a result, after applying the DST patch, you may have issues with mobile devices such as Blackberry or Goodlink devices. Note that this does NOT affect Windows Mobile devices using Exchange ActiveSync.
The second potential issue is that after applying the same Exchange CDO patch, your mailbox stores may not mount. Applying 926666 results in the Information Store service being restarted. The issue only appears to be present in limited situations, such as multi-domain environment in which well-known BUILTIN groups have been delegated rights in Exchange (e.g. Delegate BUILTIN\Administrators Exchange view-only admin rights at the Org level), and is caused because when the store starts up, it detects an ambiguous SID (which is, in fact, true). Well-known groups such as Administrators have the same SID regardless of the domain, and if there are multiple domains, when store tries to resolve the SID, it gets multiple results, and will then fail to mount the database. This is also documented in the Exchange Team blog, and the workaround is mentioned in KB932599.
The third issue that I've come across involves the Auto Accept Agent. The issue here is that the Auto Accept Agent will NOT allow double booking of meetings. Period. Yes, there are 2 settings in the autoaccept.config.xml to deal with conflicst, but those do not allow double bookings. They are settings that tell the Auto Accept Agent the percentage of conflicts it can allow (i.e. if it is set to 50, and you have 8 instances of a recurring meeting, no more than 4 can conflict before the entire request gets declined), and there is also the number of conflicts. Both work together, and whichever is the smaller value gets applied. In the above example, if you have conflicts set to 100, and percentage of conflicts set to 50, and using the same example of 8 instances of a recurring meeting, if there are 5 instances that conflict, it will be declined, even though the number of conflicts is set to 100. Why is this an issue with the DST patches? Well, when you run the Exchange Time Zone Update tool, or the Outlook Calendar update Tool, each one will send out updated meeting requests to all attendees if you are the organizer of a meeting. If your resource mailboxes are heavily booked (as they very likely may be), then the end-result is that when the updates are sent out, meetings will overlap. Because the Auto Accept Agent does not allow double bookings, some of those instances will be declined and will be removed from the Calendar. There are currently two workarounds to this. The first is that you can unregister your resource mailboxes from the Auto Accept Agent (effectively disabling AAA). Secondly, you can choose to not run the Time Zone update tools (Outlook or Exchange). Other workarounds are being tested as well, so stay tuned, both here and on the Exchange Team blog.
The fourth issue I have come across mainly deals with Exchange 2000 users who use Blackberry Enterprise Server. Since Blackberry uses CDO in it's operations, you need to apply the Exchange CDO patch on the BES server. Blackberry's current recommendation on how to address the DST issue is to simply update Exchange System Manger on the BES server to Exchange 2003 ESM, then apply the Exchange 2003 CDO patch. For many, that won't be an issue. However, be aware that if you are running Exchange 2000 in your environment, and you update ESM to 2003, it will install the Schema updates for Exchange 2003. Again, that may not be a big deal, but just be aware of it. Also, if you don't already have Exchange 2003 media, good luck getting them. Microsoft apparently pulled the Exchange 2003 eval download, and only has the Exchange 2007 eval software.
A final bit of quirky behavior I've run into with the Exchange Time Zone Update Tool. The KB article quite clearly states that you can't install it on your Exchange server. However, the testing I've done shows that this also extends to just the Exchange Management Tools. This means that if you are planning on running the tool on your workstation, and you have ESM installed, installing MSExtmz.msi will fail with an error stating that it cannot be installed on an Exchange server. This seems kind of dumb to me because pretty much all the MSI does is extract a few more files and add an entry to your Add/Remove programs (which in itself seems rather unnecessary). If this happens to you, you might try installing it on a machine without ESM, and then just copy the extracted msextmz.exe into the c:\msextmz directory on your workstation.