What's so bad about iCal server?

I thought I’d share a little technical detail regarding issues you can face implementing the built-in Mac OS X Server iCal service and why options such as Kerio Connect are so appealing.
To start off, its probably worth me describing a few different uses for computerised calendars. These are generally:

  • Syncing events between multiple devices
  • Seeing whether colleagues are available for meetings
  • Sending them event invitations that pop into their calendars automatically
  • Adding attachments to events

 

So where can you store your calendars?

Most people will be familiar with iCal on the Mac and the calendar app on their iPhone or iPad. A few years back, an individual either had to use a syncing service such as MobileMe 🙁 or sync calendar data using iTunes via USB.
The natural progression was to use a central server to store the calendar data. MobileMe started this with its switch to CalDAV (which broke my link to Daylite calendar syncing BTW but thats another story). iCloud is the latest and greatest offering from Apple that provides a very neat, server based calendar solution, free of charge. This is all fine for home users but what about businesses?
This is where a Mac OS X server should fit in. We are often asked by our customers to install a Mac mini server with the iCal service so that the business owner can centralise and control the diaries for the users. They also have benefits such as the ability to see free / busy data to determine if people can make it to a meeting they are scheduling.
 

So where does it go wrong?

Since its release, the Mac OS X server iCal service has required the server it resides on to be an Open Directory Master (hosting an LDAP directory). I did experiment setting up an iCal server on a standalone system and things like free / busy data and event invitations did not work at all.
When a user creates a basic event, everything works ok. The problems start when a user invites someone else to the event. CalDAV (being a documented standard) uses common field names in the event files (e.g. “ORGANIZER”, “ATTENDEE”, “LOCATION” etc). Although Mac OS X server sticks to these field names, there is a big difference in the field values. Taking the “ATTENDEE” field as an example, whereas most other CalDAV servers, including Kerio will store the contact information as “mailto:user@domainname.com”, Mac OS X server will store it as “mailto:urn:uuid:920BB15E-103B-495B-B316-5EEA417786AD”. As you can probably tell, “urn:uuid:920BB15E-103B-495B-B316-5EEA417786AD” is not an email address. As the event invitation system uses email as its communication method, on anything other than the Mac OS X server, this is going to cause problems.
 

Why does this happen?

When you add an invitee to an event, the Mac server looks the user up in its LDAP directory. If the user is found, it will use the UUID of the user instead of the email address (a lot of the time it won’t know the email address of the user). It is worth me pointing out that organisers and attendees are only added in this format if the user exists on the Mac OS X server you are connected to. If I add an invitee that is on another Calendar system, perhaps at another company, the entry is added in the correct format.
 

And why is this bad?

In a nutshell, there are two types of issues that can occur (actually there are a lot more but to avoid boring you to death I will only describe two here). Firstly, when the invitee receives the event invitation (assuming they are on another, separate Calendar system), when they pick their response (accept / decline etc…) their calendar client will attempt to send a response email. It will take one look at the “urn:uuid:920BB15E-103B-495B-B316-5EEA417786AD” and say “that is not an email address”.
The second issue is when you try to get away from the OS X iCal server (in an attempt to stop these issues). All of the events you have already created will have these bad attendee entries embedded. Not only that, but the “ORGANIZER” (i.e. you) will no longer be recognised as the creator of the event, rendering it completely un-editable.
 

To sum up…

If your users just want to keep their diaries in sync across their devices, and maybe look up the availability of other people, Mac OS X server will be fine. If they want to invite other users to events (or if you think they may need to in the future), I would look at alternatives such as Kerio Connect.
 
What to know more about our Mac Support services? Then check out the range of solutions we  offer to support Macs in business and the home.