FYI: DST 2007 exposes those who misuse CDO 1.21

A couple notes from the field as we enter the window of time that is DST 2007...

Due to the security dialogs added to CDO 1.21 in the Outlook 2000 timeframe many people started to copy CDO 1.21 from an Exchange installation for us on client machines and application servers.  As I have blogged about before the Outlook and Exchange CDO builds are somewhat different and we definitely don't support mixing components from Exchange and Outlook.  So you shouldn't be installing Outlook and Exchange on the same machine or copying CDO.dll from one machine to the other for any reason.

If you have, DST 2007 will likely expose it...

CDO 1.21 carries its own timezone information and therefore all versions of CDO would need an update to properly work with the DST 2007 changes.  If you have copied CDO.dll from another computer and registered on your machine our update will have no way of knowing it is there to update it.  If you have installed Outlook and Exchange on the same machine only one of the CDO libraries can be registerd (usually last installed wins).  If you install the Outlook update it will look at the install path to update files which may not be the registered components and the CDO.dll that your application uses will not be updated for DST.

If you find that you have applied CDO updates to an application server and it doesn't appear to acknowledge the time zone change you might want to search for CDO.dll and see if you have copied and registered CDO in another directory.  You can also search the registry for "MAPI.Session" which is the root CDO 1.21 object that will indicate where the CDO.dll that is currently registered is installed.  If it is not the default application path ("C:\Program Files\Exchsrvr\bin\" for Exchange server installs and "C:\Program Files\Common Files\System\MSMAPI\1033\" for Outlook client installs) then we can't update it.

...This also applies to CDO for Windows (CDOSYS, cdosys.dll) and CDO for Exchange (CDOEX, cdoex.dll) which have their own time zone databases as well...

...Updated 3-12-2007 1:45 PM EDT...just fixed some grammar and sentence structure, added file names for CDOSYS and CDOEX...

Comments (3)

  1. We find this problem frequently on Blackberry (BES) servers – somebody installs the ESM to get MAPI and CDO on the box, but they decide to go a step further and shoot themselves in the foot by copying CDO.dll to system32 and regsvr32’ing it from there.

    The fix is to whack all copies of CDO.dll that aren’t in the exchsrvr/bin directory and regsvr32 that one. If any rogue copies of CDO.dll are left in system32, Blackberry will load them, no matter which CDO is registered.

  2. SYMPTOMS: ======================== I recently assisted with a CDO 1.21 DST related issue where custom

  3. Disk Performance Testing with Jetstress 2007 Installing Exchange 2007 into a Small Business Server 2003

Skip to main content