Managing your Coming Calendar DST Update Storm: Using Rhino to Auto-Accept

If you are not worried about Meeting Updates for the coming DST change in Exchange, please skip to some other blog.


You can use the Sumatra Utilities /a flag to accept updates (though we'd recommend this mainly for conference rooms and resources).


The Rhino Event Sink can automatically accept for all users on your back end servers. As an event sink it operates as the meeting updates arrive server-side on the user's inbox. This means updates can be accepted or tentatively accepted with NO USER INTERVENTION.

It differs from the Microsoft Auto-Accept Agent in that the AAA is asynchronous and must be registered on each mailbox. Rhino is a synchronous event sink and needs to be registered only once on each back-end server. Rhino also gracefully handles the situation where users have Delegates to respond to calendar invitations.







You can use Rhino with some caveats:

1. Rhino can Accept or Tentatively Accept -- but it does not recreate the original response if it were a Decline. We do not have this restriction during a calendar server migration but we have complete control over that situation and we got the same advance notice you all did of the Microsoft DST Update method.


2. If you are running Cached Exchange Mode do not enable "Replies" processing, that will result in users getting conflict messages due to an Incremental Change System (ICS) issue in Exchange 2003 sp2


3. You can limit Rhino processing to a defined Group.
4. Exchange 2003 only (Sorry Exchange 2000 users but the Sumatra Utilities will happily work in that environment).

Calendar Conflicts in Cached Exchange Mode in 2K3 sp2

Administrators universally agree that cached exchange mode in Exchange 2003 is a good thing providing added value and reliability to their infrastructure.

Programmers who write applications which interact with the calendaring functions unfortunately, are tearing their hair out and cursing their fates.

The situation:

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 problem:

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:

1. Create a Synchronous event sink in VB 6 using the event sink wizard from the exchange SDK.
2. 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
3. Compile the code, register the event sink on your system mailboxes
4. Create a recurring meeting using Outlook in Cached Exchange mode.
5. Have that “guest” accept the meeting
6. Open an occurrence of the meeting, and change the location, agenda, etc. Send an update, then switch to the inbox.
7. Have the “guest” accept the update.
8. Open the Guest’s response message (in your inbox)
9. 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
http://support.microsoft.com/default.aspx?scid=kb;EN-US;883130
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
http://support.microsoft.com/default.aspx?scid=kb;EN-US;903290

Note: The auto accept agent is also an async OnSave agent.

Non-viable options:

• 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)

Our solution:

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.