Microsoft Exchange Calendaring Problems - A Current Perspective (Mar/2014)

Addressing Calendar Corruption, Lost Appointments, Duplicate Appointments in Exchange

Over the years, I've written what have become the authoratative guides on addressing calendar corruption, calendar delegate, missing appointment problems in Microsoft Exchange.  I've gotten a flurry of emails and calls over the past handful of months seeking assistance, so I figured it was time to update my blog post here with the latest.When I first blogged about the Exchange Calendaring problem, it was far before the masses were experiencing the problem, but the problem existed and I identified the problem being threefold:

  1. Microsoft Exchange (2003 and 2007 at the time) had issues with timesync and message sync tracking for calendar appointments.  Effectively when a calendar appointment was modified by multiple users or devices, Exchange did not apply changes in the order the changes were made.  Early versions of Exchange did not anticipate multiple authoratative writes to a single object in a manner that a world with multiple delegates and mobile devicess were making changes to the same appointment at similar times
  2. ActiveSync implementations by mobile vendors (Apple being the most visible mobile provider) had bugs where ActiveSync would hold on to a sync connection and not release it, or syncs weren't timestamping properly, or a well known bug where a mobile user who declines a single recurring meeting would have the entire recurring appointment thereafter deleted, etc.  These bugs from Apple in ActiveSync were most commonly the root cause of missing appointments and duplicate appointments.
  3. Calendar Delegates are the third problem I identified in calendar corruption and problems, and of the 3 is the one that doesn't have a hotfix or patch to solve the problem.  And as organizations with calendar delegates now working off multiple endpoints where the Exec has 3-4 devices and the Exec Admin has 3-4 devices, we are seeing a flurry of calendar problems pop up lately.

I wrote an update on the calendaring problem a few months after my first blog post with key updates. This is now 2014 update on where things stand relative to addressing calendar corruption and calendaring problems in Microsoft Exchange...

THE SOLUTIONSOLVING THE BACKEND PROBLEM - #1For organizations that are experiencing calendar problems that are still on older versions of Exchange, moving to the latest version of Exchange (or moving to Office 365) has eliminated the "backend" as being the problem.  HOWEVER, what I have seen are organizations doing partial migrations as well as bringing problemsome appointments forward into the new environment.I've seen organizations with Exchange 2007 or 2010 spin up an Exchange 2013 server and put the Execs and Exec Admins on the new server, but still experience calendaring problems.  The fact that you are on Exchange 2013 (or Office 365) is just part of the solution.  First of all, calendar problems are still impacted by #2 (device) and #3 (users), so moving users to the latest Exchange/Office 365 only addresses 1 of the 3 problems.  Secondly, for the organization that moves just some of the users to a new server, if other users in the org are still on an old Exchange 2007/2010 server, a person who sends a recurring appointment out of a buggy version of an iPad from their Exchange 2007 mailbox out to the Exec on Exchange 2013, the appointment will still adhere to the calendar corruption problems of the iPad and Exchange 2007.  If that sender deletes "this weeks meeting" in a recurring appointment from their buggy iPad, it will delete all other occurrences of the appointment as well.  We are seeing fewer and fewer of these instances as that iPad/iPhone bug was fixed 2-yrs ago (was in iOS 4.3 or earlier), however it is amazing how many times we go into an environment and find someone still sync'g with Exchange with iOS 4.x despite iOS 7.x being out these days...In addition to user and device problems against a "brand new Exchange 2013 environment", the other problem is that once a calendar appointment is corrupt, it will always be corrupt.  As the Exec's mailbox (with old corrupted calendar appointments) is migrated to a shiny new Exchange 2013 server, that mailbox still retains the older corrupt appointments.  Example, if a recurring appointment got corrupt and deleted all future instances of the appointment, and then that appointment is migrated to Exchange 2013, Exchange 2013 won't mysteriously re-insert in the recurring appointment meetings.  This is one of the most frustrating things in isolating this problem as corrupt appointments remain corrupt.What we have found works best is to jot down any time an appointment is wrong and then fix it by sending out a completely new appointment / recurring appointment to replace the old one.  And not simply update/resend the old appointment, I mean create a brand new appointment.  That new appointment will not bring along the problemsome issues.BUT, this is where the chicken and egg comes in to play...  The org that simply tried to solve this problem by moving just a handful of Execs/Admins to the latest Exchange but did nothing to address other users in the org, to address old versions of endpoint clients, nor address user interactions will only find the problem pops up again.  The sequence to solve this problem has been:

Yes, there is a solution to the calendaring problem organizations are experiencing, and I'd have to say that at least 2/3rd of the problem can be technically addressed.

Specific to the version of Microsoft Exchange, we have found as organizations have rolled into the latest release of Exchange 2013 or have moved their email to Microsoft Office 365 in the cloud, the "backend" problems of calendar corruption have been addressed.  Microsoft did patch and update Exchange 2007 and 2010 to address as much as they could on message and calendar sync, however Microsoft's rearchitecture of Exchange 2013 (and Office 365, built on Exchange 2013) minimizes the queue time and reconciles message write timing such that there's less of a delay and fewer changes that the backend is writing calendar appointments out of sequence and being part of the calendar corruption challenge.

  1. educate users / Execs / Exec Admins-Delegates first (and ask them to be diligent in their methodology, despite problems will still crop up from old stuff lingering in the calendars, keep to a clean routine)
  2. make sure endpoints are updated, no old devices or buggy versions of OS/iOS
  3. upgrade to the latest version of Exchange or to Office 365 in the cloud

As much as most orgs I run in to say they are certain their users are using the most current version, inevitably when we do a site assessment and check the ActiveSync logs on Exchange, we find all kinds of devices connected to Exchange.  Most commonly, we find the Exec has some old iPad that their kids occassionally use these days that everyone forgot about that is STILL registered to Exchange, and when the device gets connected to WiFi, all of a sudden that system sync's with Exchange and we've seen the device insert corruption into emails and calendar appointments.  Check the Exchange ActiveSync logs, it'll show which devices are connected and the version of client OS is in use.  Anything iOS v4.x really needs to be updated, and quite frankly anything iOS v5.x should be updated too.I don't see it too often these days, but anyone running Entourage email on Apple Macs should upgrade to Office 2011.  Early versions of Entourage quickly corrupted calendars because Entourage didn't recognized graphics and attachments in calendar appointments, and thus stripped them out and updated the appointment. That right there inserted corruption to any/all calendar appointments immediately.  However while we do find Mac users are running Office 2011, again, there's that old system the Exec has at home that their spouse uses these days mostly for Internet surfing that happens to still have an old copy of Entourage running on it, and every now and then that system syncs and corrupts calendars.  Checking the Exchange logs for syncs will identify the end devices connecting to Exchange, make sure you truly know which versions of endpoint client (mobile and desktop) are connecting to Exchange.SOLVING THE USER PROBLEM - #3The users are key to addressing calendaring problems in Exchange.  As I've related it in previous blog posts, the analogy I use is if we all shared a complex word processing document with lots of fonts, formatting, embedded graphics, special margins and borders and some of use Word 2013, some use Word Perfect, some use WordPad, some use Word 2007, some use Google docs, would ANYONE wonder why the document somehow lost its formatting, fonts got screwed up, margins got screwed up?  Every time you open that word processing document with a different word processor, you can assume "something" in that document will get screwed up.THAT is what is happening with calendars, plain and simple.  Calendar appointments commonly have embedded fonts and graphics (yes, your auto-signature at the bottom with the company logo, or the "please be green" graphic is part of the calendar appointment).  Recurring appointments, to this day, are foreign to a lot of calendar apps on mobile phones that simply think of an appointment as a single event, even prior to iOS 4.3, Apple didn't recognize recurring appointments properly.  So every time users open up, edit, change, decline an appointment from one device or another, they are effectively "editing" the appointment with a different calendar software program, no different than someone opening up a word processing document that doesn't support graphics, which strips out the stuff it doesn't understand, and saves the information with the edited (missing) information.SO, the request to users, especially those with delegates, is to minimize the number of different client endpoints (and different types of endpoints) in use.  If the Exec is using Outlook 2013, then the Exec Admin should run Outlook 2013. For accepting and declining appointments, if the Exec Admin is in charge of the calendar, then the Exec Admin should always accept and decline appointments, try to have the Exec themselves refrain from also accepting and declining appointments.Regarding this last point, when the Exec declines, and the Exec Admin accepts the appointment, which one is it?  You'd think it goes sequential, so if the Exec declines and THEN the Exec Admin accepts, that Exchange should ignore the 1st request, but wait, what if you first decline an appointment and later you realize you can attend the meeting and you accept, then the subsequent change should take affect.But the challenge is what if the Exec declines from their phone, but is in a fringe area and there's no signal.  The Exec Admin accepts from their desktop, so the acccept is registered as the current state.  The Exec's phone comes into signal range and the decline is processed, but Exchange sees the time of the decline as occurring BEFORE the accept, so Exchange ignores that change because it proceeds the decline, but wait, didn't we state that the last request should take place?  THIS is why calendaring is not a perfect science, and to confuse the matter even further, Microsoft and Apple have changed the behavior back and forth (and back and forth again) with varying versions of Exchange, iPhone/iPads, patches/updates, etc.  One version of iPad against one version of Exchange will have a different experience that another version of iPad against another version of Exchange.End of the day, the only thing that we've seen that has addressed this problem is to:


With the backend updated to the latest version of Exchange (or Office 365), ensure all endpoint devices are using the latest version of client software.  Whether that's the latest Outlook 2013 with service update for Windows, or the latest Office 2011 for Apple Macs, or the latest iOS for iPhones/iPads, or latest Android / Samsung / etc update for devices.

I hate calling it a "user problem" as that offends users, and quite frankly what users do day in and day out should NOT be the cause of these calendar corruption issues, however maybe politically speaking, this should be called "user contribution to the solution".  Quite frankly there are quirky things in the way that Microsoft, Apple, Google, etc all contribute to the problem, and end of the day, us users have to do our part to work around the quirks of the software...

  1. Keep calendar accepts/declines ONLY to 1 user.  If the Exec Admin is in charge of the calendar, ALL accepts and declines are ONLY done by the individual
  2. Keep calendar accepts/declines ONLY to 1 system.  Use a highly connected (desktop/laptop on the network) as THE device that'll accept/decline appointments.  Do not use mobile devices to accept, decline, edit, change appointments when more than 1 person is managing a calendar.  Because connectivity is not assurred, results are not consistent
  3. If you can't keep calendar accepts/declines to just 1 user and 1 highly connected system, then at least try to ensure that the Exec / Exec Admin system types to be the same (and if push comes to shove, keeping to the latest version of Microsoft Outlook on a Windows system (ie: Office 2013 for Windows)) as the default.


So I've now addressed the biggies to get your arms around the problem.  In sequence:

1 2 Page 1
Page 1 of 2
The 10 most powerful companies in enterprise networking 2022