Calendar Server 6 and Calendar Server 7 Comparison and Coexistence

This information discusses some of the differences between Calendar Server 6 and Calendar Server 7 software, as well as some of the issues for a coexistent deployment.

Overview

Calendar Server 7 is Sun's next-generation Calendar Server, which supports the new standard for calendar access called CalDAV. Beyond the first release, this technology will evolve into much more than a calendar server.

Calendar Server 7 is a newly designed server and replaces the existing Calendar Server 6. Calendar Server 7 operates in a very different manner from Calendar Server 6. Though both servers use the standard iCal format for data, Calendar Server 6 supports only the WCAP protocol for data access, making it usable only with Sun-supplied clients and connectors. Calendar Server 7 supports the standard CalDAV access protocol, which makes it usable with Apple iCal, iPhone, Thunderbird Lightning, and any other CalDAV clients.

Note Currently, WCAP support for Sun Convergence and Connector for Outlook clients is still being developed in Calendar Server 7. This integration is planned for a future release of Calendar Server 7.

See What Is CalDAV and Why Use It? for more background information.

Architecture and Services

Calendar Server 6 was designed as a stand-alone application that consisted of multiple processes, including:

• csadmind - Manages alarm notifications and group scheduling requests
• cshttpd - Listens for HTTP commands from Calendar Server end users, receives the user commands, and returns calendar data
• csstored - Creates automatic backups of the calendar database
• csnotifyd - Sends notifications of events and to-do's (tasks)
• csdwpd - Manages calendar databases spread across multiple back-end servers within the same Calendar Server configuration

Calendar Server 7 is a servlet that you deploy into a web container (GlassFish Enterprise Server). Thus, Calendar Server 7 does not contain its own start and stop programs, unlike Calendar Server 6. (You start and stop Calendar Server 7 through the GlassFish Enterprise Server start and stop commands.) The administrative commands have been completely rewritten as well for Calendar Server 7. The Calendar 7 commands do not have one-to-one mapping to the Calendar Server 6 commands. For more information about Calendar Server architecture and design, see Introduction to Calendar Server 7.

For more information about administering Calendar Server 7 by using the davadmin command, see Calendar Server 7 Command-Line Utilities.

Calendar Server 6 used an embedded Berkeley DB database while Calendar Server 7 uses a separate mySQL database. This use requires separate installation, configuration, and maintenance of the calendar database, but easier maintenance by using mySQL Server specific tools.

Features

Some of the features that existed in Calendar Server 6 are still being developed in Calendar Server 7, including subscriptions, ACLs, resource calendars, and group calendars. Most of these features are expected to be supported in a future release of Calendar Server 7.

For a quick look at the features of Calendar Server 7, see What's New in Calendar Server 7.

Coexistence

You can install Calendar Server 6 and Calendar Server 7 on the same host. The two servers will not use each other's data. You can ensure communication of free-busy information and iMIP scheduling between the two servers by using the setup described in Creating a Calendar Server 6 and Calendar Server 7 Coexistent Deployment. You cannot use this setup in the Calendar Server 7 Beta release. Also, this setup does require that you install the latest Calendar Server 6 patch.

Installation and Configuration

For more information, see Communications Suite 7 Installation Scenario - Calendar Server 7.

Data Migration

A migration program is being developed to migrate Calendar Server 6 data to a Calendar Server 7 host. This migration program is not currently available in the first release of Calendar Server 7 but is planned for a future release.

Special User Accounts

Calendar Server 6.3 special accounts include the following:

• Calendar Server Administrator (calmaster) Account
• Superuser (root)
• Non-root User (icsuser, icsgroup)

Calendar Server 7 special accounts include the following:

• Calendar Server Administrator (calmaster) Account
• Calendar Server User and Group Accounts
• Superuser (root)
• mysql user and group
• GlassFish Administrator Account

Proxy Administrative Accounts

In Calendar Server 6.3, to enable administrators to administer user calendars, the default value for the following parameter in the ics.conf file is set as shown: service.http.allowadminproxy="yes"

There is no equivalent in Calendar Server 7. That is, you cannot disable administrative access to user calendars.

End-User Administration

Administrators with the proper permissions can add, delete, or modify user LDAP entries or resource LDAP entries by using the Delegated Administrator Utility (command-line) or Console (GUI). Calendar Server 7 requires Delegated Administrator 7 (patch version that ships with Communications Suite 7). Calendar Server 6.3 uses Delegated Administrator 6.4.

Additionally, when necessary, you can use ldapmodify to modify LDAP entries directly.

Both servers support Schema 1 and Schema 2. For more information, see Communications Suite Schema Reference and CalDAV LDAP Schema Reference.

Calendar Server 7 requires the new davEntity object class to set up multiple back-end hosts for horizontal scalability. Calendar Server 7 does not support the DWP protocol, which was used for distributing calendar data across multiple back-end hosts in Calendar Server 6.3.

Data Formats, Protocols, and Standards

The Calendar Server 6.3 data format is modeled after RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar).

Calendar Server 6.3 supports WCAP 3.0.

The main interface used by Calendar Server 7 to interact with the data repository is the CalDAV protocol, which is based on HTTP. Thus, any client that supports CalDAV, such as Apple iCal and Thunderbird/Lightning, can access Calendar Server 7. Calendar Server 7 will also partially support the legacy HTTP-based WCAP protocol for use by Connector for Outlook and Desktop Sync clients in an upcoming release.

Calendar Server 7 supports only a subset of the legacy WCAP protocol, with no guarantee of backward compatibility. Additionally, Calendar Server 7 supports the server-to-server iSchedule protocol, which means that it can also act as a client. The server also exposes the following HTTP-based services:

• Simple free-busy service
• Administrative browse UI

Finally, Calendar Server 7 offers a JMX based interface to query and alter the repository. This interface is primarily used by the davadmin command-line utility but can also be used by standard clients, such as Jconsole, and by custom JMX clients, either locally or remotely.

Access Control

Calendar Server 6.3 uses Access Control Lists (ACLs) to determine the access control for calendars, calendar properties, and calendar components such as events and to-do's (tasks).

Calendar Server 7 will support a similar rich access control mechanism in a future release.

Public APIs

Calendar Server 6.3:

• WCAP 3.0 - See the Sun Java System Calendar Server 6.3 WCAP Developer's Guide.
• ENS - See the Communications Suite Event Notification Service Guide.

Calendar Server 7:

• Calendar Server 7 WCAP Developer's Guide (Link not yet publicly available.)

Backup and Restore

When properly configured, the Calendar Server 6.3 csstored service creates automatic backups of the calendar database. You can configure Calendar Server 6.3 for automatic backups either during initial configuration or at a later time.

In Calendar Server 7, you use the davadmin db command to back up and restore the MySQL database. There is no automatic database function as there is in Calendar Server 6.3. You can write cron jobs for Calendar Server 7 deployments to perform incremental backups by using the davadmin db backup command.

Log Files

Calendar Server 6.3 maintains six types of log files:

• admin
• dwp
• http
• httpd access
• notify
• store

The default log location is /var/opt/SUNWics5/logs, which you can modify.

Calendar Server 7 maintains four types of log files:

• commands
• calendar
• scheduling
• telemetry

Each log file has its own configuration attribute that controls the log file location, maximum size, and log level. The default log file location is the logs directory, under the data and config directory that you enter during initial configuration. You can set the logging level for Calendar Server logs in the Application Server logs by using the Application Server Admin Console.

For more information, see Administering Calendar Server 7 Logging.

Maintaining Configuration Files

You change the Calendar Server 6.3 configuration by adding or editing parameters to the ics.conf file. You can find the ics.conf file in the following directory:

• For Solaris OS: /etc/opt/SUNWics5/cal/config
• For Red Hat Linux: /etc/opt/sun/calendar/config

You change the Calendar Server 7 configuration by using the davadmin config command.

Notifications and Reminders

Calendar Server 6 can be configured to use an external generic service called the Event Notification Server (ENS), which accepts reports of server-level events that can be categorized into specific areas of interest. This service also notifies other servers that have registered interest in certain categories of events. Calendar Server 6 uses ENS to send and receive alarm notifications that include the creation, deletion, or modification of calendar events and tasks, as well as general
operational warning and error messages.

Note The Calendar Server 6.3 software also contains support for Java Message Queue for notification, but csnotifyd does not subscribe to it. Thus, it is not part of the default alarms and notification system. For more information, refer to the Sun Java System Java Message Queue documentation.

Calendar Server 7 provides Java Message Service (JMS) notifications and email notifications for database changes and event or task email alarms. You can configure the server to produce JMS notifications for every database change and every alarm. If you choose, you can write your own subscribers to these notifications. In addition, Calendar Server 7 provides a subscriber program, which you can configure, that consumes the JMS notifications and sends email for database changes and email alarms.