Programmers who write applications which interact with the calendaring functions unfortunately, are tearing their hair out and cursing their fates.
We've built Rhino, an Exchange (server-side) solution to intercept and process calendar messages. The solution uses a synchronous an Exchange event sink. The event sink understands certain rules (via an XML file) that allow the system admin to :
- Process meeting requests, replies, or both;
- Skip managed resources;
- Process requests as tentative, accept, or decline, and show the meeting as free, busy, or out of office
- Process replies - keep/delete accepts/declines/tentatives or any reply with a reply from the end user.
- All replies are processed to update the owner's tracking tab.
We manage the messages at the server side using CDOEX (version 6.5.7638.1) and EXOLEDB (version 6.5.7650.7) embedded within a synchronous event sink. This event sink works as designed when clients are connected to the Exchange server without Cached Mode.
The problems that we are seeing is that the sink generates an Outlook Sync Issues "Conflicts" when clients use outlook in 'cached exchange mode'. i.e. clients see message on the meeting ... "You made changes to another copy of this item. This is the most recent version...."
Also when an Outlook meeting owner attempts to update one occurrence of the meeting, and changes the location, or adds an agenda, the meeting owner's calendar doesn't always get updated with the changes that he/she just made (e. g., the agenda gets lost, the location disappears from the subject line annotation in the calendar view, but still exists in the meeting detail view); and agendas are never received by the end user, until the meeting owner updates the same meeting occurrence twice.
Clients most frequently see this conflict message when they update meetings, or change a single occurrence of a recurring meeting.
What is going on here:
This is a bug in the ICS (Incremental Change System) for Exchange 2003 in cached mode.
Steps to reproduce:
- Create a Synchronous event sink in VB 6 using the event sink wizard from the exchange SDK.
- Add in code to detect and process calendar messages (see MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_cdo_processing_meeting_request_responses.asp
- Compile the code, register the event sink on your system mailboxes
- Create a recurring meeting using Outlook in Cached Exchange mode.
- Have that “guest” accept the meeting
- Open an occurrence of the meeting, and change the location, agenda, etc. Send an update, then switch to the inbox.
- Have the “guest” accept the update.
- Open the Guest’s response message (in your inbox)
- Switch to the calendar and open the meeting (you should see a conflict)
We've added the VB source code for main module as a comment to this post. The VB Project is available to those who request it.
Remedies we have tried already:
Microsoft support suggested their Auto Accept Agent that is implemented as an asynchronous event sink, but again you need to install this on every mailbox:
883130 The Auto Accept Agent Deployment and Administration Guide is now available
903290 You should not register a resource mailbox for Auto Accept Agent in Exchange 2003 when you set up a resource for direct booking in Outlook
Note: The auto accept agent is also an async OnSave agent.
- Don't use cached mode with Outlook 2003 (This isn't an acceptable solution)
- Asynchronous sinks (We tries these and it still generates conflicts, aside from which they need to be registered on each mailbox)
- Direct booking (Really geared towards resource mailboxes)
- Server-side rules could be set up to try to handle this (Again this would have to be implemented on every mailbox where we want this functionality -- more complex administration overhead)
We're implementing an Outlook best-practices client-side COM+ add-in for Outlook 2003 / 2007. Please feel free to contact us if you want to try it out.