InfiniTec - Henning Krauses Blog

Don't adjust your mind - it's reality that is malfunctioning

Streaming Subscription - Design considerations

Commenter Mike had questions on some details of the article I wrote about Exchange streaming notifications (See the comments in this blog post). In the MSDN article, I wrote this:

Streaming notifications do not work this way. Instead, you can use a combination of notifications and the ExchangeService.SyncFolderItems method. The SyncFolderItems method gives you a snapshot of the changes that occurred in a particular folder. This method also returns a small cookie that contains information about the synchronization state. You can pass this synchronization state to subsequent calls of the SyncFolderItems method to get all changes that have occurred since that synchronization cookie was first issued. You should persist this synchronization state somewhere (either on disk or in a database) so that the application does not need to process all of the items in the folder gain.

I further outlined the steps an application should follow when using streaming subscriptions:

  • After your application starts, use the SyncFolderItems method to process all unprocessed items in the folder.
  • Create a streaming notification and connection as specified earlier in this article.
  • Use the SyncFolderItems method again to process all events that occurred since the last synchronization and before the subscription was activated.
  • On each OnNotification event, use the GetItem operation to get additional properties of the specified items.
  • Call the SyncFolderItems method periodically to update the local synchronization cookie.

This makes the application seemingly more complex than it needs to be because your application must be able to deal with different change notifications: Those from the streaming subscription and those from SyncFolderItems. Additionally, once a notification is received through the streaming subscription, the synchronization state from the last call to SyncFolderItems is stale. The application must now deal with the situation that the initial call of SyncFolderItems on an application restart might return changes which already have been processed by the application. The application needs to deal with this situation.

Mike asks whether it’s ok to ignore the item ids specified in a notification and just use the SyncFolderItems method on each notification. Using this approach, the synchronization state returned by the SyncFolderItems method would always be current and the whole application design would be more simple.

The answer is: It depends. If you have a low-volume application and your Exchange server is not used at full capacity, this might be ok. If you are writing an in-house application where you know everything about your infrastructure, this might be acceptable. But keep in mind that an application might run several years and the server load of your Exchange Server might go through the roof during the lifetime of your application. And if you are a software developer who sells his application to (hopefully) many customers, you don’t know anything about the performance situation on these servers. So it is best to conform to best practice and use the rules I outlined in the article.

Posted by Henning Krause on Tuesday, August 9, 2011 8:53 PM, last modified on Tuesday, August 9, 2011 8:53 PM
Permalink | Post RSSRSS comment feed

Comments (3) -

On 8/24/2011 5:18:41 PM Mike wrote:


Thanks for the detailed reply.

It would still appear that you would need to keep a list of processes ItemId's every time an email is process in the notification event handler. So you would have something like `IList<ItemId>` and each process email would get added to this list. Now, whenever the service syncs with Exchange you'd ignore the ItemId's in this list. After the syncing is complete you would clear your list of processed ItemId's and begin the process all over again. Arguably this with the last known sync state should be persisted somewhere.

On 9/1/2011 5:29:34 PM hkrause wrote:


Yes, you would need to store the in-between-syncstate somewhere...

On 3/28/2013 2:50:58 PM Danny wrote:



I made some use of the article you posted on MSDN (
When the onNotification event fires I copy the email to a specific subfolder of the user. With the syncitems I do the same. But emails that I got in the onNotification are also present in the syncitems result. Saving itemid's in onNotification and passing ignoreItems doesn't help. I still first  get mail in onNotification and then in syncitems. How can I resolve this?