If anyone a:wants to write code to accept meeting requests, and b:needs to have named properties in calendar items, this is what you need to know. 1. Just accepting meeting requests/cancellations is relatively easy; call GetAssociatedAppointment(), Update() on that appointment, voila. 2. Doing reschedules is a big pain. If you call GetAssociatedAppointment() on a meeting reschedule request, it deletes the meeting in your calendar and creates a new one. (this is documented, it turns out; I was wrong beforehand. Quoting from the docs for GetAssociatedAppointment(): If the meeting's organizer has sent an updated meeting request since you accepted the first request, CDO considers the existing AppointmentItem object in your calender folder to be out of date. When you call GetAssociatedAppointment, the existing appointment is deleted from your calendar folder, and GetAssociatedAppointment returns a new, updated AppointmentItem object. However, this new appointment is not stored in your calendar folder until you call its Update method. This delete-and-recreate process doesn't preserve any named properties you may have put on the meeting, of course. [as a side note, Outlook _does_ preserve named properties when you accept things using it] So the solution is to read any named properties you care about from the meeting in your calendar, _then_ call GetAssociatedAppointment, then put those named properties back. But how do you get at the corresponding meeting in your calendar without calling GetAssociatedAppointment? Well... In propset 6ed8da90 450b 101b 98da00aa003f1305, property IID=35, there's a binary property. (weird propset -- I think you could probably work out who wrote this bit of CDO/Outlook, because those last bytes are a MAC address if ever I've seen one.. Oh, and that's a real propset, not a CDO-munged one, so you'll need to byteswap as per usual if you want to use this in CDO. I'm not sure how to turn IIDs under 0x8000 into the CDO-formatted strings, I'll admit; a bit of trying and I gave up and went back to raw MAPI to do this). This property is the same on the meeting reschedule request in your inbox as it is on the meeting in your calendar. You can thus use this with a bit of filtering (and, for a nice change, filtering works here) to locate the meeting in your calendar, read properties out, all is well. [as another side note, the Exchange SDK helper function HrMAPIFindMsgByProp is broken, and infinite-loops if if finds any messages. It's easy enough to fix, and the source is in the platform SDK, thank heavens, but this is a little warning to save anyone else waiting and waiting and waiting and wondering why things are so slow..] So the next question, of course, is what happens with recurring meetings? Well, as we all know, recurring meeting instances are stored as attachments to the base meeting; get from an instance to the base meeting by going GetRecurrencePattern() and Parent() on the pattern, loop over the attachments, property 0x7ffc, time, is the start time of that instance, in _local_ time (ie not UTC as all other MAPI stuff would have it). Looking through a meeting reschedule request, though, we find a lot of properties which are for the _new_ time of the meeting -- but none for the original time before the reschedule -- so how do we know which meeting instance to open up? In the same propset as before, IID=3, there's another binary property. Bytes 17-20 of this property are an encoding of the date of the original date of this recurrence instance; call them A B C D for 17,18,19,20 A*256+B = year, C = month, D = day. We can then turn that into a time, search the list of attachments to see if any of them match up with this time (remembering that the attachment property for time does contain time-of-day info so you can't just do CompareFileTime, you have to manually compare year/month/day) and then get the relevant attachment -- open the attachment as a message, blah blah blah, all is well. Note: you can't have Outlook running during this stuff. If you do, then Outlook tentatively accepts the reschedule or somesuch nasty thing, which alters the attachment table, which means your code can't locate the original instance any more. Anyway. That's the fruits of the last few days of my life, dumped out here in case anyone else ever needs to know this stuff.. -- dan