The Goal:
I am developing an application that requires integration with Microsoft Exchange and Office 365. I have had about two years experience working with various Exchange integrations and this application requires advanced synchronization capabilities in order to fulfill the business requirements. To properly accomplish the requirements, I need to sync calendar updates from the Exchange server into my application and allow two-way synchronization between my application and the Exchange server. This simply means when an update occurs on the Exchange server, my application will reflect that update and when an update occurs in my application it will be updated within the Exchange system.
The Problem:
I am able to accomplish this goal for single meeting instances by using the Managed API’s method called “SyncFolderItems” and the “ExchangeService” class. This method is designed to only give changes that have occurred since the last time my application synced with the Exchange server. This is great and it allows me to only download the calendar items that are modified after a synchronization event instead of looping all of the items I have downloaded and determining if an item has changed within the Exchange server.
This method will return created, updated, and deleted calendar items. During the process of getting the calendar items, I store the unique identifier for each meeting instance in my application so that there is a relationship between my application’s entity and Exchange’s entity. This makes the performance of synchronization fast and prevents my application from having to manage the sync state of each item coming from the Exchange server, EXCEPT for calendar items that are a part of a reoccurring meeting.
What I have discovered, through hours of troubleshooting, is that the unique identifier for a reoccurring calendar item within Microsoft Exchange CHANGES. I couldn’t believe it, I didn’t want to believe, and I still can’t believe it! How does a server application have a unique identifier that CHANGES!?! To me this means that it is NOT an identifier, but an arbitrary value that is associated with a data element. I felt like I discovered a phantom bug, which caused me to question why Microsoft would do this. Based on my findings, it appears that the unique identifier of a reoccurring calendar item is determined by the “DATE” that the calendar item is scheduled on. For example, if I have an instance of a meeting scheduled for 02/05/2014 at 10:00am and move it to 02/05/2014 at 11:00am, the unique identifier will not change. However, if I have an instance of a meeting scheduled at 02/05/2014 at 10:00am and move it to 02/06/2014 at 10:00am, Exchange will produce a different identifier for the same calendar item. Nevertheless, if I were to move that same calendar item back to its original time, then the original identifier would be used again. Yep my head was spinning after that realization as well.
After that discovery, I felt that I could still use the “SyncFolderItems” method mentioned above expecting Exchange to inform my application that it deleted a calendar item and added a new calendar item. (Sigh) I was wrong again. Exchange interprets this scenario as an update event, and therefore never informing my application that the identifier of a calendar item has changed.
My Solution:
After hours of searching through the internet and Microsoft’s website, I didn’t find any solution to the issue. I was hoping for a different method to use, or perhaps a property that contained the OLD ID somewhere, but I was unable to locate such a solution. I found a Stack Overflow post that seemed very similar to my issue but it was unclear of what was done to solve the problem. Unfortunately, my solution resulted in managing the sync state of my reoccurring calendar items and checking with the Exchange server to see if those items were still valid. If the calendar items were no longer valid, I removed the calendar items from my application.
I hope this post helps someone and prevents them from spending hours searching for a solution. I think Exchange needs to have a better “exchange” process in the way it handles updates for reoccurring calendar items. If someone has a better solution than the one presented here, please let me know.
Microsoft you are still a great company and Exchange is still a great product.