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

• Anonymous
  December 17, 2007
  The comment has been removed

• Anonymous
  December 17, 2007
  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.

• Anonymous
  December 19, 2007
  The comment has been removed