It might just be me, but the sounds of bitter complaints by users whose calendars have been thrown into confusion by some combination of user error, Exchange server bug, and client mess-up appear to have quietened recently. At least, my mailbox is less full of sad tales of corrupted meetings or failed appointments. Things must be improving.

Office systems that include time management functionality have been around for a very long time and we have enjoyed the vicissitudes of their malfunctions for most of that time. Digital Equipment Corporation’s ALL-IN-1 Office Automation system offered scheduling features in 1982. Its V2.0 release was updated at the behest of the White House in 1984 to allow for minute-by-minute appointments for President Reagan and his senior staff.

Thirty years ago we had a much simpler environment to manage. Few people had email and all used wired terminals to connect to their accounts on timeshared computers. It was much easier to code the basics of time management such as setting up a meeting, sending out notices of that meeting, and handling the responses.

The first versions of Exchange used Schedule+ calendaring to maintain backward compatibility with Microsoft Mail. Once the first versions of Outlook (1997) came along to replace the original “Exchange Viewer” client, Exchange provided native time management. We were still in the era of wired terminals and the new challenge was interoperability. Not only between different email and calendaring systems, but even between different versions of Exchange. The different views of what an appointment or meeting was across various email servers contributed to some angst. The introduction of the iCalendar format has helped to solve the interoperability issue between different electronic calendars, but only relatively recently.

User expectations of time management were also growing as features such as delegate access were added. Multiple access to a single calendar is absolutely a wonderful idea from a user perspective but it creates many challenges, especially when you factor in different clients. Performance is also problematic when clients have to open multiple calendars. The worst example I have encountered is an administrator who was expected to manage the calendars of sixteen managers. Suffice to say that she had plenty of opportunities to brew coffee as Outlook struggled to cope with the load.

Mobile clients have a natural affinity to calendars. If you are on the road, you need to know what is in your calendar, and a mobile client that has no access to calendar is hamstrung. Early BlackBerry devices certainly could get to user calendars and cheerfully proceeded afterwards to wreak havoc on calendar items. We’re still seeing corrupt calendar items (“bad items”) dropped by the Mailbox Replication Service when mailboxes are moved on Exchange 2010 and 2013 servers. To be fair to RIM, some of the protocols used by Exchange were either difficult to understand (like MAPI) or badly documented. Microsoft now publishes full specifications on the different protocols and interfaces used by Exchange and that seems to have helped.

Telling someone about a protocol is one thing. Expecting them to use it properly is another. ActiveSync (EAS) is the best example. The EAS protocol documents are available to developers to help them work out how mobile clients should interoperate with Exchange. But a long history exists of mobile clients messing up user calendars, most notably the splendid efforts of several versions of Apple iOS to impose its will on the server, as in the infamous “calendar hijacking” issue in late 2012.

iPhone and iPad devices are terrifically popular as a percentage of mobile devices found in Exchange deployments, a fact that possibly influenced Microsoft’s decision to buy Acompli and its excellent iOS client over Thanksgiving. Apple and Microsoft have worked hard to improve the client-server communications between iOS and Exchange and apart from a recent hiccup with iOS 8.1, the updates have generally been better. Because of the work done on the server, the improvement is generally felt across the spectrum of mobile clients. Sure, bumps will happen along the road, but it is true that mobile clients are much better today at dealing with complex calendaring operations than they were in the past.

Thirty years of computer-based time management has taught us a lot. In terms of Exchange, I think you need to keep three basic principles in mind as you design or execute deployments in order to minimize the risk of things going wrong. These are:

• The newer the client, the better. Generally speaking, the most recent versions of Outlook and mobile clients are better at dealing with all aspects of calendaring.
• The newer the server, the better. Microsoft has poured effort into bullet-proofing Exchange so that malfunctioning clients can’t impact the server. Most of this work has happened since Exchange 2010 SP2. You benefit by using Exchange 2010 SP3 (with the latest roll-up update). Exchange 2013 and Exchange Online also include code to keep the demands of clients under control.
• Be sensible in user placement. The basic idea is to keep users who work together on the same server. If someone needs to manage calendars, all the mailboxes for those calendars should be on the same server. You create risk once you distribute operations. For instance, having an administrator located on Exchange Online attempting to manage multiple on-premises calendars is a recipe for disaster. Sure, it will probably work. But note that word…

Going back to ALL-IN-1, even though we had hard-wired terminals connected to central computers, we had problems with time management at that point too. I got a support call to go to the White House once but never made it. All because I was an “alien.”  Oh well…

Follow Tony @12Knocksinna