Free/Busy Appointments Missing After Using CDO 1.21 to Access Calendar


If you have written or use an application that uses CDO 1.21 (cdo.dll) that accesses your Calendar and you have users who complain that some recurring appointments are not appearing in Free/Busy in Outlook, this may be for you.


When a recurring appointment is created in Outlook, you may not realize that really this is just a singular message in the MAPI store. We commonly refer to this as the _Master_ appointment. Whenever a client application or API looks for appointments in your calendar, it will expand the Master appointment into several instances according to the recurrence pattern you set when you made it a recurring appointment. These instances of the recurring appointment are interpreted - they don't actually exist in the store.


When you make a change to one of these instances, such as changing the start time or the location, or if the instance is deleted, an _exception_ item is created. The exception item is a copy of many of the properties of the master appointment which is then attached to the master appointment. When the messaging infrastructure expands the master, this exception item is included in the expansion algorithm so that when expansion occurs, you see your changes or deletions appropriately.


The other change that occurs when you create an exception item is that the recurrence pattern is modified on the master appointment. The recurrence pattern is a binary MAPI property stored on the master appointment message. This binary property stores the details of the recurrence pattern as well as information regarding exception items. It is not supported to modify this property directly. You can find code available on the Internet to reverse engineer this property and modify it, but this is strictly unsupported by Microsoft.


What happens in cases where this property has been improperly modified or otherwise corrupted is that one or more messaging systems (Outlook, CDO, Exchange) are unable to properly expand the appointment.


This is the root cause of the issue described in the first paragraph. In one case I saw recently, the recurrence pattern had been improperly modified. Outlook and OWA clients could see the appointment just fine, with one exception. There were appointments missing in Free/Busy. We were able to determine that if Outlook was the last application to publish free/busy - that is, make a change to the calendar which caused free/busy information to be republished, then the recurring appointments would appear just fine. If a certain CDO 1.21 application was the last to access the calendar, then the appointments vanished from Free/Busy.


After doing some troubleshooting, I was able to determine that the Free/Busy symptom was just a symptom of a much larger problem. When I would get the Items collection from the calendar folder, that collection did not contain my problem appointments (not even the Master appointment). When CDO 1.21 would go to publish free/busy, it would get the collection of rows from MAPI (which contained the appointment) but would then attempt to expand the recurring instances. It detected a problem with the recurrence pattern (which Outlook didn't care about or check for) and would essentially ignore that appointment. That is why the appointment did not appear in Free/Busy - CDO was ignoring it altogether.


Moral of the story - respect the recurrence blob.

Comments (3)
  1. djmitchella says:

    I don’t understand this — "If a certain CDO 1.21 application was the last to access the calendar, then the appointments vanished from Free/Busy."

    CDO1.21 has support for recurring meetings, so how could it break the recurrence data? If someone was using ExMAPI and poking at the named property by hand, sure.

    Or is this one of the various bugs in older versions of CDO1.21 where CDO itself breaks things?  (or is this someone trying to use the ENTRYID prefix hack to fool cdo1.21 into getting at appointments in non-standard calendar folders or something? Even that shouldn’t break the recurrence data, though)

  2. pcreehan1 says:

    No, CDO 1.21 was not breaking the recurrence data – it was mearly picking up on a corrupted recurrence blob set by *something* (I don’t know what the something was). There are places on the internet where folks have attempted to reverse engineer the property and set it. And for the most part, it does work as long as you’re only using Outlook to view it. In this case, some part of the stream was not what CDO 1.21 was expecting and it returned a corrupted data HResult which caused CDO to ignore that appointment (and therefore all of its instances). I believe CDO was behaving by design and Free/Busy is just the victim.

  3. djmitchella says:

    Okay, that makes sense. I know about the reverse engineering stuff, I posted the first (public, I guess) stab at this lot, but I was only doing read-only code, so I don’t know about creating things.  Cain Random finished it off from there, and I think he’s the guy who worked out (most of, it sounds like..) the extra bits required to create recurrences.

    (the only reverse engineering I’ve done for creating things was (non-recurring) task requests, which had its own set of excitement..)

Comments are closed.

Skip to main content