There exists a scenario in which attendees to a meeting in Outlook will receive an updated meeting request from the originator that appears to be "out-of-date." In the InfoBar, Outlook will display a message that says "This request is out-of-date." If the attendee attempts to accept the meeting request, they get an error dialog box. Now, this is expected if there was an update that was made but a later update was already made - that's sort of what that functionality in Outlook was designed for. However, in this scenario, you see a new meeting request and very shortly after you get an update to the same meeting. It's clear that the update didn't come before the original request, so how can it be out-of-date?
This scenario exists where an appointment is modified by an application using CDO 1.21. In order to get the problematic behavior, the machine running the CDO 1.21 code has to have the clock set to a time earlier than the client machine. If CDO 1.21 modifies the appointment and sends updates within the time delta between the two machines, the update will appear to Outlook to be earlier than the original request.
Imagine the scenario:
CLIENT_MACHINE_1 and CLIENT_MACHINE_2 have a current system time of 3:00 PM.
CDO121_MACHINE has a current system time of 2:57 PM.
The problem boils down to a difference in meeting update behavior between Outlook and CDO 1.21. There's a sequence number property on meeting requests that Outlook increments each time an update is made to a meeting. Outlook examines this sequence number first when deciding which update is newest - this code was put in place for scenarios like this primarily for pop3 clients, which only use sequence number. The timestamp is used as a secondary factor in deciding which is newer. CDO 1.21 wasn't designed with some of these modern calendaring scenarios in mind and doesn't (and won't ) support incrementing the sequence number - it's simply copied over as are most props.
So...if everyone just synchronizes their clocks to the same time server often enough, we'll all be happy :).
If you have CDO 1.21 code which causes this to occur to some of your clients, here are a few ideas that you can try:
Many of you have been using the Custom Calendar Provider samples created by Stephen Toub and I:
Stephen Toub - Custom Calendar Providers for Outlook 2003
Custom Calendar Providers for Outlook 2007
The development team has finally documented pretty much everything you need to know in order to build your own STSSync provider (to replace SharePoint as our code samples do). The documentation is included in many of the newly documented Open Protocol specifications:
[MS-OUTSPS] Lists Client Sync Protocol Specification
I'm excited to see what you do with this!