Living Without OnSyncSave and OnSyncDelete

Matt has a blog post asking for customer feedback on the removal of OnSyncSave and OnSyncDelete from the next version of Exchange. Go over there to read it, or check out this snippet:

I am working with the product team to discuss any scenarios where EWS notifications and Transport Agents might not be sufficient to replace synchronous store event processing in a custom solution. The Exchange development team and my Exchange support team are aware of the potential challenges arising from changing the development interfaces available. Between Exchange Web Services notifications and Transport Agents we feel that we can fill a lot of the gaps left by removing synchronous store event processing but we want to hear from you. Are there scenarios that you currently require synchronous event processing for right now? Please email me or leave a comment describing your scenario. Getting your feedback will help us prepare documentation, workarounds, or solutions that can mitigate the challenges presented by this change.

So if this is a concern to you, go over there and give him your feedback.

Comments

• Anonymous
  January 13, 2009
  Hi, what about the case where you need to prevent an email from being deleted to implement a "legal hold" senario? Thanks, Sam sbs1259@comcast.net

• Anonymous
  January 14, 2009
  Sam - don't tell me - tell Matt.

• Anonymous
  January 14, 2009
  Matt - I see you share my concern.  I'm wondering if it will be possible to have some code in the Exchange process that can front-end and pre-process EWS operations such as 'DeleteItem'.  This would allow for the implementation of a context based filter which could prevent the deletion of an email.  Sam

• Anonymous
  May 10, 2009
  I'm part of a government department with about 14000 Exchange objects split across 2 Exchange 2007 SP1 mailbox servers (CMS + SCR). We've got a requirement to support a new application that will generate up to 40,000 calendar appointments per week across users calendars . The issue we have is that there is a specific requirement to stop our users from moving or deleting these application generated calendar appointments. We were originally looking at using Sync events to check OnDeletes to stop users from messing with these appointments, but after finding out about the future of Sync events and the possible performance and stability impact on our environment we decided to look at using the Async (event notification) method. Our problem is that developers are claiming that if we attempt to use Async the delays in polling for changes and the requirement to develop a way to get the original application to generate a new appointment means that the solution would be unmanageable and have a greater performance on the environment. What are our options here? Is there another way to stop users deleting these items? Is there anything in the pipeline for Exchange 2010 where we could programmatically set object level security for Calendar items and stop users deleting items without the need for event checking?