CDO: Always a Bridesmaid

Suppose you’ve scheduled an meeting and sent out meeting requests to a number of recipients. Some of those recipients don’t like the time you’ve scheduled for the meeting and decide to propose a new time. At this point, you will receive a message with message class "IPM.Schedule.Meeting.Resp.Tent". This message will contain information about the proposed new time, which Outlook will then tag on to the meeting when it processes the response.

Now – suppose you also have some CDO based code that also tries to process this meeting response using GetAssociatedAppointment and Update. CDO knows about this message type, so it can read the tentative response off of it and update the meeting. And here’s the problem – CDO doesn’t like proposals. Or, more accurately, CDO doesn’t know anything about the propose new time feature, so it doesn’t know anything about the properties used to implement it. So when CDO updates the meeting during the processing of the response, it ends up wiping out the properties that controlled the proposal feature! Before CDO touched the meeting, you could look at it in Outlook and see an Infobar indicating that new times were proposed. And switching over to the Scheduling Assistant, you could view and select the new time. After CDO’s done with the meeting, nothing indicating there was a proposal is left.

Some more technical details: The proposed new times are stored on the meeting on the recipient table, with a set of properties written to each recipient row indicating their proposal. To read about these properties, look for PidTagRecipientProposedStartTime in [MS-OXOCAL]. CDO isn’t deliberately wiping any properties. Instead, it knows it needs to add PidTagRecipientTrackStatus, also in [MS-OXOCAL], to the recipient. Not knowing about the proposal properties, the new row CDO constructs for ModifyRecipients doesn’t contain them. So the effect is, if the properties were there before, they’re not there now.

Other than avoiding CDO, no simple workaround for this issue is known. A savvy developer armed with [MS-OXOCAL] might try reading the recipient table off before allowing CDO to touch the meeting, then go in and fix it up.

Comments (0)

Skip to main content