There are variations to this where Blackberry, iPhones, and other full access devices also change the attributes of the appointment rendering changes to the appointment that cause the appointment to never end up (or automatically removed) from a person's calendar. More details below.
Blackberry Enterprise Server (BES)
I noted problems with Blackberry devices and services in their impact on Exchange performance in my previously posted article, the problem with BES is a huge source of problems for calendaring as well. The problem with BES is that it was designed to act as a user's Outlook, listen/look for changes in emails and calendar appointments, and automatically forward the changes to the Research in Motion (RIM) network to a Blackberry device, a great solution built 10+ years ago when only a handful of executives and salespeople in an org had Blackberries, and people sent "a couple dozen emails" in a day. But this process has gone effectively unchanged, and roll forward a decade when organizations now have hundreds of Blackberry devices managing users who are sending/receiving dozens/hundreds of emails in a day, the BES server using MAPI communications just can't keep up (note: RIM/Blackberry will be changing the architecture of their BES server in a major upcoming release to use secured Exchange Web Services that will address these problems and concerns, however for now, we're stuck with BES and MAPI, a highly inefficient and insecure method of communications).
Note: My reference to "insecure" is the fact that BES uses a single "administrator" password to access ALL mailboxes of users with Blackberry devices and this security hole has been used to breach the security of Blackberry user accounts because anyone in IT can use the BES administrator account to effectively open and read anyone's mailbox with absolutely no security audit trail to determine who accessed an individual's mail. But this is a separate topic to address.
Specific to calendaring problems, BES is well known to take on the load of what appears to be 4 users for every Blackberry device on the network (http://technet.microsoft.com/en-us/library/aa996376(EXCHG.65).aspx and puts significant load on a single server against Exchange. During peak times, Blackberry servers with as few as 500 devices connected to it can exceed the I/O capability of Exchange causing messages to be delayed by 5-10 minutes as they are queued up on the Blackberry server and in Exchange. This delay easily reachs 10-15 minutes during a migration when an organization has some mailboxes on say Exchange 2003 or Exchange 2007, and other mailboxes on Exchange 2010 as the overtaxed Blackberry server now has to cross the Exchange boundary between server types to check on messages, route messages, validate messages, etc.
This delay time is not the problem, it's what happens "during" the delay that is typically human related that ties into my first bullet on Exchange calendaring across platforms (Outlook 2003 / 2007 / 2010, Apple Mac and Windows, iPhones/iPads, etc). As a scenario, a desktop user sends a meeting request to several users, of which desktop recipients immediately get the meeting request and accept the request. The Blackberry user, due to the delay in sending and receiving during peak times across a migration boundary has delays in their receipt of the meeting request, requests a change in the meeting, and sends a reply that might not get back to the originator for 5-15 minutes. By then others have accepted the request while the change occurs, which a desktop user might request a different change which now the Blackberry user is 2 request changes behind.
The timing factor causes calendar appointments to get out of sync leading to common Calendar errors such as "Cannot update the appointment because the corresponding item in the folder you synchronized does not match the item" or "Conflicting edits have been made to the same item. To resolve this conflict, select the item in the list below you wish to keep and then choose..." This occurs for just normal senders and recipients of calendar appointments with BES in place. When the originator of the meeting (or a delegate of the meeting) gets this conflict of meetings and chooses one versus the other appointment, effectively the user is choosing to keep 1 appointment and delete another appointment, which then sends a meeting deletion to all users connected to that appointment (which as noted earlier in this post, in split calendar appointment scenarios caused by cross-platform errors, one of the meeting appointments could go to Mac users with a different meeting appointment going to Windows users, thus creating differences in results dependent on the client the user is running).
In a manager/delegate situation, the problem is even worse as both the manager and delegate have full read/write/edit capabilities to appointments so that when a delegate accepts a meeting of their boss on a Blackberry device, or changes a meeting request of their manager from a Blackberry device, the delay time back to Exchange changes the attributes of the meeting request effectively modifying a portion of the meeting, not the entire meeting, which creates the sync, attribute, conflict errors noted above.
Solution: For Blackberry devices in a manager/delegate calendar sharing environment, it is best to NOT use the Blackberry device to manage meeting requests of shared delegates (ie: don't accept, reject, change, or create meetings as a delegate of another individual from a Blackberry device). Effectively do ALL delegate calendar management from a desktop computer running the EXACT same version of Outlook as the manager. If the manager is running Outlook 2007, the delegate should do all calendar accepts/rejects/edits from a computer running Outlook 2007. If the manager is running a Mac, the delegate should do all calendar accepts/rejects/edits for that manager on a Mac. Any time a different version/platform of operating system or mail client is used, calendar corruption can occur.
I note "can occur" as the problem happens most frequently when the Blackberry server and Exchange server(s) are busy and queue times lengthen, and the problems don't always occur late in the afternoon or evening when IT is trying to debug the problem, no one is on the network, and the problem doesn't show up. The problems occur most frequently when the Blackberry server is at its highest capacity. Check the Blackberry message queue to see when message transfer and processing is delayed due to message queue build-up.
Exchange 2010 Bug
For organizations that have migrated to Exchange 2010 and having odd calendar delegate problems, there was a bug that was introduced in Exchange 2010 with Roll-up 1 (in December 2009) and persisted until it was fixed in Roll-up 4 (in June 2010). The problem has to do with how meeting delegates accepted or rejected meeting invites. If a delegate is the delegate managing multiple calendars and a meeting is sent to multiple "Managers", only ONE copy of the meeting invite will be received by the delegate (historically, alphabetically so that the "first" invite is received), and subsequent invites are "lost". So only 1 of the "Managers" accept the invitation and all others end up in limbo, typically the meeting just doesn't show up in the person's calendar even though the assistant knows they accepted the invite (unfortunately the assistant accepted the only copy of the invite received, not ALL of the invites for all of the people the assistant is delegate for because this Exchange bug didn't send multiple copies of the meeting invite as Exchange should have). Similarly, if the Manager and the Delegate get invited to the same meeting, only 1 of the invites will be received by the delegate, either for the Manager or for the delegate, but not both. So only 1 of the two will end up accepting the invitation and the invite won't end up on one of the two individual's calendar.
This bug was fixed in Roll-up 4 in June 2010 and addresses this problem, however for several months, and for many organizations rolling out Exchange 2010, this error still haunts them as an inconsistent quirk. Quite frequently, this error still occurs when organizations have some systems updated with the latest Exchange roll-out, but not all systems have been updated to Roll-up 4 or more current, and as such, the quirky nature of this problem is inconsistent dependent on the roll-up level of the server the user is accessing. For more information, see http://support.microsoft.com/kb/982378.
Performance Issue with Exchange Calendaring
A specific item to note about Exchange calendaring access is one that involves Exchange calendar access performance. Users complain that accessing the calendar of another indivividual takes a lot time (upwards of 20-30 seconds). A default setting in Outlook 2007 and Outlook 2010 when a user is running Cachemode for Outlook is a setting that caches "Shared Folders". It is selected by default and when a user opens another person's calendar, it downloads the other person's entire calendar so that it does a Cachemode on other user's calendars. This is great if you work offline and want to potentially look at someone else's calendar, however when a user is online, each and every time another calendar is open, Outlook goes out to the other user's calendar, checks for changes, and does a complete calendar synchronization before the user's calendar is visible. This is frequently reported as "slow performance for calendar access" as it can be 5, 10, 20 seconds before a user's calendar appointments are visible.
The solution to this problem is to turn off the caching of Shared Folders by going into the Outlook profile (File / Info / Account Settings in Outlook 2010; or Tools / Options / Account Settings in Outlook 2003 or 2007), click on the Advanced Tab, and uncheck the Download Shared Folders checkbox as shown in the graphic below.
Other Issues with Calendaring in Outlook and Exchange
There are several other issues inter-related between calendaring problems and Exchange performance problems. Take a look at the posting I refer to at the start of this post about Exchange/Outlook performance, specifically server hardware / LAN-WAN performance issues and the Frequently Asked Questions.
Hopefully this is a place to start when trying to understand why calendaring in Exchange is inconsistent, and know there are fixes and solutions to them ALL as we have helped dozens of organizations better understand why the problems exist so that the organizations can fix the problems and ultimately end up with a 100% reliable calendar environment in Exchange.
iOS Fix Solves Duplicate / Missing Calendar Issues in iPads/iPhones
{Added 5/11/2011} Apple fixed a long standing "bug" in their iOS with v4.3 in April 2011. All previous versions of the iOS on iPads and iPhones created a situation where recurring calendar appointments would be completely deleted if a user simply deleted just a single occurrence. This bug fix specifically mentions interactions of problems between iPads/iPhones and Blackberry/BES devices. See http://support.apple.com/kb/TS3714
Frequently Asked Questions:
Q: How come all of a sudden these calendar problems have become a big thing?
A: Calendaring and Exchange performance issues ballooned up June/July of 2010 due in part to a bug in the iPhone 4.0 operating system that effectly locked up access for mobile users cause delays of mobile devices to Exchange and overall performance issues to Exchange in general (see my blog post http://www.networkworld.com/community/OutlookPerformanceInExchange or Apple technote http://support.apple.com/kb/TS3398 for more details). I call this the straw that broke the camel's back, although other factors such as more and more Apple Macs popping up on networks (particularly with executives, while their admins are running Windows), more use of Blackberries, etc. Basically little by little the problem has grown until the iPhone problem has caused hundreds of companies to contact me in the past 5 weeks alone on these issues
Q: All of our executives and their assistants have Windows-based systems (no Macs), and all of the execs have gotten rid of their Blackberries and now use iPhones or Windows Mobile devices, yet we still have calendar problems, what's up?
A: Key things to check is that your execs and assistants are running the exact same version of Outlook (if Outlook 2007, then make sure you are 100% Outlook 2007 between execs and assistants), if an assistant is running Outlook 2003, or Outlook 2010, basically a different version of Outlook, that matters. Additionally, we have found in many cases where an assistant is using a Blackberry to accept meeting invites of executives, that as noted is a known problem. Lastly, check your Blackberry server and see if your execs and admins truly have had their Blackberry accounts removed. I have seen several cases where the execs and assistants got rid of their Blackberries months earlier, yet the user's Blackberry account was never deleted, so effectively the Blackberry server is still grabbing calendar appointments and sending them off to RIM to go to never neverland. Make sure you have a clean deprovisioning process for devices once a user stops using the device. (same goes true with ActiveSync, I've seen orgs where a user never deleted their old Windows Mobile or iPhone device, and to this day the Exchange server is sending calendar appointments out to several ActiveSync devices for the user despite the user only having 1 device)