Jaa

Outlook Requests Can't Get a Date

  • Artikkeli

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.

3:00 PM User1 on CLIENT_MACHINE_1 sends a meeting request to User2 on CLIENT_MACHINE_2.
3:01 PM User2 accepts the meeting request and the appointment is added to User2's calendar.
3:02 PM CDO 1.21 code runs on CDO121_MACHINE server and modifies the appointment on User1's calendar and sends the meeting request update (stamped 2:59 PM which is the current system time on CDO121_MACHINE) .
3:03 PM User2 receives the updated meeting request and Outlook displays the update as being out-of-date.

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:

  • in your processing, don't process meetings that have the timestamp later than the current system time on the machine your code is running on.
  • Push for your customer to keep machine times in their environments synchronized. This should at least minimize the impact. Clearly this won't account for scenarios where users are using home computers over a VPN or RPC/HTTP connection or using mobile devices that may have clocks synchronized to a different source.

Comments

  • Anonymous
    April 23, 2008
    PingBack from http://microsoftnews.askpcdoc.com/?p=4053

  • Anonymous
    March 31, 2009
    I have several clients that this is happening to.  Our exchnage svr 2003 is running cdo 1.2.1.  But as i look at its time compaired to the clients, it is only a fraction of a second behind.  can something like that cause issue?  Could this be a problem between the times on the client boxes or is this an exchange-outolok issue?

  • Anonymous
    April 03, 2009
    Sure - if you have code running on the Exchange server that uses CDO 1.21 to modify the appointments, then you could be experiencing this behavior.