[Rich Graves]

Two slightly different solutions for two slightly different use cases.

1) The general "Residential Calendar" and "Academic Calendar"

These calendars are and will continue to be maintained in a non-Zimbra content management system. We (i.e., Matt Bockol, not me) wrote some code to make a proper iCal feed out of it. We created a "web services group calendars" resource account that subscribes to the feed via iCal, set up a cron job to refresh that iCal feed periodically, and then re-share that calendar with everyone. Upon account creation, we mount the two public calendars at /Residential Calendar and /Academic Calendar using zmmailbox (see schemers' posts above). This is a lot faster than subscribing each individual user to the iCal feed.

2) Course schedules and Moodle one-offs

We chose to feed course schedule data into our Moodle LMS, and re-export it from there as a single iCal feed, not one feed (or share) per course. This required a moderate amount of coding, all external to Zimbra, to munge our student registration data and beat the alpha-quality iCal support in the latest version of Moodle into shape, but it's done now, and the code could be made available to other institutions on request.

We created two new Moodle REST URLs:

2a) List all users on the Moodle system (since not every Zimbra user is a Moodle user)

2b) Accepts two arguments: username and a sha1(secret key+username) digital signature (which along with source IP address serves as authentication, and discourages user A from stealing user B's iCal feed). Returns that user's iCal feed.

All users are subscribed to their own personal Moodle calendars URL, including the sha1 signature. The initial load of about 2,200 users' calendars took 7 hours. Incremental updates take about a half hour. We plan to refresh course schedules and force reload of the iCal feeds (see responses from Zimbra employees above) on a nightly basis.

We have just one problem with this system -- next post.