Exchange Outlook Calendaring Problems (lost meetings, delegate problems, etc)

Solving Exchange Outlook Calendaring Delegation Lost Meeting Problems

Its been over a year since I originally blogged this problem with Microsoft Exchange and Outlook, and the problem has expanded even greater, and thus an updated blog post here.  The problem has to do with organizations having calendar appointments and meeting requests “disappear”, get corrupt, meeting delegates (boss/assistant) having challenges with appointments showing up, disappearing, reappearing, etc.

Bottomline, this is a KNOWN problem if you have the following:

  • Microsoft Exchange (2003, 2007, or 2010)

  • Outlook (2003, 2007, or 2010)

  • Apple iPhones / iPads

  • And potentially Apple Macs (running Entourage or Outlook 2011)

  • And potentially RIM Blackberries

In short, it is a combination of bugs in all of these products along with users who get frustrated and do workarounds that further exasperate the problem that causes the problem.

Good thing, there is a FIX!  I blogged about this issue over a year ago () and have updated the blog post continuously with updates on fixes and workarounds.  In the past year, the consulting firm I run (Convergent Computing, has implemented this methodical process to completely eliminate calendaring problems in dozens of organizations representing hundreds of thousands of calendars.

The bad thing, it’s not a simple 1 time fix.  You can’t just throw on a patch and the problem goes away.  It’s also not solely a technical solution, it actually requires the full support of PEOPLE, PROCESS, and TECHNOLOGY to solve the problem.  Let me clarify…

As I noted, the root of the problem are bugs in Microsoft Exchange and Outlook, AND bugs in Apple iPhones and iPads, AND bugs in the Blackberry Enterprise Server (BES).  All of these bugs are clearly documented in my NetworkWorld blog post I reference above.  In that post, I give the specific Microsoft, Apple, and RIM tech articles.  If you ask Microsoft, Apple, RIM, they do acknowledge these are known bugs, and the bugs are fixed when you apply the noted updates.  So technologically, everyone has access to the fixes to the problem, so why can’t you just apply the bug fixes and the problems go away?

That’s where the People and Processes come in to play…

The bug fixes only fix the problem from here forward on the server/devices that have been updated.  THREE issues that we have repeatedly found to “break” the success of the solution:

1) As much as all current devices get updated, the minute some Exec or Admin goes out and buys a shiny new iPad or iPhone and configures it to sync their email, that new (unmanaged / un-updated) device corrupts calendars again.  Apple CONTINUES to ship their devices with older versions of the iOS and as such, while everything was working, the problem pops up again

2) Or, everything is working fine and then IT sets up a new Exchange server (adds a new server to improve performance / capacity, or adds a new site with new servers), but IT forgets to patch and hotfix the new server.  Soon afterward, the problem with calendars pop up again

3) Or, in several cases, the Executive (or the Admin) has a system/device “at home” that no one in IT is aware of that they sync their calendars.  And this hasn’t happened just once, it happens all the time, the occasional sync by a home device corrupts all the work IT has done to patch/update all “known” devices

These are all PROCESS things.  The ONLY fix that’ll guarantee an organization it has control over its systems/devices is to put in place a very methodical systems management / device management policy.  It means your network won’t allow just anyone to sync from any system or ActiveSync from any phone with any iPad, iPhone, Blackberry, Microsoft Outlook for Windows, or Entourage for the Mac system/device.  With system/device management support, you only allow authorized systems/devices to access and sync with Exchange.  There are several applications available to provide this type of policy-based device control including variations of Microsoft System Center Configuration Manager (SCCM), Casper, AirWatch, etc.  The policy has to block access by default, check the version of iOS / Outlook / Windows / ActiveSync / Mac / etc, patch/update the system/device, and THEN allow the system/device to sync.  When you have 100% control of 100% of all systems/devices connecting to your network, then you can now be confident that you have Technology and Process covered in this solution.

Now on to the PEOPLE part of this solution.  We’ve talked about people, process, and technology for years, this is one of those instances where PEOPLE play a part in the solution.  It’s not good enough in this problem solution to just run around and patch the 2-3 (or 10-20) systems/devices you know of to solve the problem.  As I noted, if you don’t control the onboarding of systems/devices and the Executive or their Admin buys a new iPad/iPhone and screws up their calendar, then they lose confidence in IT and the solution and they quit doing their part.  We’ve seen it dozens of times and going to say you MUST manage the systems/devices before you tell everyone the problem has been fixed because the problem WILL arise again if you don’t have control over the technology and processes in IT as noted above.

The people aspect is all about Confidence and active Participation. 

For the Participation piece, as I note in my 2010 blog post, users CANNOT accept/decline meeting appointments or modify meeting appointments from their mobile devices!  This is the hardest thing in convincing an Executive or the Admin that is the delegate, and you MUST have a discussion with the Execs/Admins.  Let me use an analogy…  You are probably all aware that you can’t share the same Word document or Excel spreadsheet at the same time.  If you try to access a file on a network share at the same time, the 2nd person accessing the file gets a notice that the file is locked and in use by someone else, you can only access the Word/Excel file “read only”.  If two people SAVE the same Word docs at the same time, the last person to write the Word doc “wins”, meaning that whatever the first person had written gets overwritten.  This is very clear to most individuals, AND it applies to Outlook emails as well.

If two people open the same calendar appointment at the same time, one person accepts, one person declines, which appointment is locked into the person’s calendar?  Unlike a Word doc where it’s pretty clear the overwrite writes over the document, for calendar appointments, the Accept gets published back to to the sender, and the Decline deletes the meeting.  Here’s where the bugs come in to play, as an example, with the Apple iOS bug that was fixed just this Spring (2011) with iOS 4.3, prior to that bug fix, a Decline by the iPad/iPhone user for a single meeting instance will actually Delete ALL re-occuring appointments for that meeting.  A very frustrating problem is where bugs in Exchange and Outlook had differing effects where in some instances the Accept would Accept the meeting, and some instances a Decline after an Accept would not Decline the meeting once the iPad/iPhone/Mac/Outlook system/device sync’d.  It is this inconsistency that causes frustration because what used to work one way immediately changes when a patch or update is applied and now the problem works the other way.

The reason iPads/iPhones/Blackberries are causing this problem (and why this wasn’t a problem for a decade and is now a problem in the past year or so) is the proliferation of mobile sync’ing devices (by the way, this also includes Android phones and Pads, so this isn’t “just” an Apple/RIM device thing).  The problem with mobile devices is all about timing on the sync.  If one device Accepts the meeting appointment at say 9am on their iPhone, and a delete Declines the meeting at 9:10am on a PC, but the iPhone is out of signal range and doesn’t sync the meeting until say 9:30am, what happens to the meeting?  Between 9:10am-9:29am everyone thinks the meeting has been declined and potentially sends a new meeting invite for a different time.  At 9:30am the meeting is Accepted once the iPhone is in signal range.  So now what’s the end result of that meeting?  Declined because of the 9:10am decline?  Accepted because of the 9am Accept that was sync’d finally at 9:30am?  Or changed based on a new meeting sent between 9:10am-9:29am???  Unlike a Word doc where write requests are checked realtime, currently the way ActiveSync works on mobile phones, there is no “real time checking” on meeting appointments.  This will need to be addressed in future versions of Windows / Exchange / ActiveSync / Macs / iPads-iPhones / etc.  But for now, we need to deal with it… (and by the way, this problem exists in other email systems as well, anything that allows a mobile / disconnected device has the same root problem, so don’t think that dropping Exchange and going to something else will solve your problem…)

Along the same line, you have to also realize that once a meeting appointment is corrupt, it remains corrupt, even after patching/updating.  If your Executive’s recurring appointment was deleted because of an iPad/iPhone bug, having the Exec Admin forward a copy sitting in their calendar to the Exec doesn’t make the problem go away, in fact you just forwarded a corrupt meeting to the Exec.  You need to “clean-up” meetings.  Any recurring appointment that is flakely (appears on some calendars, doesn’t appear on others) should be resend AFTER all devices are patched/fixed.  Again, a People process where you have to educate people that corrupt appointments will always remain corrupt and you have to resend new ones.

Back to the PEOPLE process, if users find processes to be inconsistent, then they lose confidence and quit doing their part of the fix.  So if you tell the users to NOT use their iPads/iPhones/Blackberry to accept/decline appointments, but then they add a new iPad without you knowing it and the problems persist.  Users then stop doing their part thinking that “hey, IT told me to not accept on my iPad, but the problem continues” and that loss of confidence causes the users to then start accepting/declining appointments on their mobile devices again, and now no matter whether you got the Technology/Process in place at a later date, the People are not participating.  The problem never goes away…

Again, we have been 100% successful in making the calendaring problem go away in environments where we walk through this methodical process.  The problem is fixable, follow the guidance distilled from my 2010 blog post and hopefully a little better clarified here.

Copyright © 2011 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022