Printable Calendar Server 7 Update 1 Information

Skip to end of metadata
Go to start of metadata

This documentation applies to Communications Suite 7 Update 1 at the time of its release. The most up-to-date documentation is available at the Communications Suite Documentation Home.

Printable Calendar Server 7 Update 1 Information

Contents

Introduction to Calendar Server 7

Oracle Communications Calendar Server for CALDAV Clients (formerly Sun Java System Calendar Server), was completely rewritten in version 7 to support CalDAV, the calendar access protocol standard. The Calendar Server servlets are deployed within a web container and access data stored in MySQL Server. In addition, Calendar Server (beginning with Version 7 Update 1) supports the WCAP protocol for use with clients such as Convergence.

For a description of features and functionality, see What's New in Calendar Server 7. For an overview of the differences between Calendar Server 6 and Calendar Server 7, see Calendar Server 6 and Calendar Server 7 Comparison and Coexistence.

Topics:

Calendar Server Software Architecture

The following figure represents the Calendar Server 7 software architecture.

Calendar Server Software Architecture

Components of a Calendar Server Deployment

Clients and Servers

The Calendar Server deployment provides the repository for calendar and address book data, and also acts as a file storage. The main interface with the repository is the CalDAV protocol, which is based on the HTTP protocol. CalDAV clients execute on end-user computers or on mobile devices, including:

  • Thunderbird + Lightning extension (CalDAV)
  • Apple iCal (CalDAV)
  • Windows Explorer or Apple Finder (WebDAV)

The server portion also provides partial support for the legacy HTTP-based WCAP protocol for use by Convergence.

The following figure shows the Calendar Server clients and components.

Calendar Server Components

"This figure shows the clients

Calendar Server supports only a subset of the legacy WCAP protocol, with no guarantee of backward compatibility. Additionally, Calendar Server 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 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.

User Repository

Data is organized within each Calendar Server repository by subject or by entity, that is, by LDAP user, resource, or group. Each subject has one home collection (similar to a UNIX home directory), which is the parent of all service-specific collections for that subject, including:

  • Calendar collections
  • Address book collections
  • Generic file storage collections
Note
Currently, Calendar Server only uses Calendar collections and not Address book and File Collections.

For example, the following URLs represent a single repository for calendar user smith:

http://davserver.example.com/dav/home/smith/
http://davserver.example.com/dav/home/smith/MyDefaultCalendar/
http://davserver.example.com/dav/home/smith/SomeOtherCalendar/
http://davserver.example.com/dav/home/smith/MyDefaultAddressBook/
http://davserver.example.com/dav/home/smith/mypic.jpg

Calendar Server 7 Front-End and Back-End Servers

In its default configuration, the Calendar Server 7 actually consists of two different components:

  • Stateless J2EE based front end
  • MySQL back end

You can locate both components on the same host or separate the components onto multiple hosts.

In a multiple-host deployment, a many-to-many relationship exists between front-end instances and back-end instances. Each front end has access to all the MySQL back ends. As a consequence, each front-end host has access to all users' data.

Multiple front ends can be grouped together, either by using a simple load balancer or by using the GlassFish Cluster functionality.

Note
For session-based protocols (for example, WCAP), sessions are not synchronized among front-end hosts. The load balancer is responsible for ensuring that a particular session "sticks" to a particular front-end host.

For more information on deploying multiple Calendar Servers, see Calendar Server 7 Horizontal Scalability and Multiple Hosts Scenarios.

Document Store

The following feature is available starting in Calendar Server 7 Update 1.

The document store is used to store large data in the Calendar Server, such as calendar events and todos with large attachments. CalDAV and Convergence clients are able to retrieve these attachments over HTTP.

The document store can either be local or remote. When the store is local, it runs as part of a Calendar Server instantiation. For example, the local document store could be part of a Calendar Server front end installation or part of a single host installation providing both front-end and back-end functionality. A Calendar Server with a local document store accesses the file systems directly. A Calendar Server with a remote document store accesses the documents by using HTTP.

The default directory for the document store is /var/opt/sun/comms/davserver/db. You can configure this by changing the store.dav.*.dbdir parameter. If at some point you move the document store, you need to migrate the data.

To configure the document store, see Configuring the Oracle Communications Calendar Server for CALDAV Clients Document Store. To migrate the document store, see To Migrate the Document Store.

What Is CalDAV and Why Use It?

CalDAV, also called Calendaring Extensions to WebDAV, is an Internet standard that enables client access to scheduling information on a remote calendar server. WebDAV, also called Web-based Distributed Authoring and Versioning, is a set of extensions to the Hypertext Transfer Protocol (HTTP) that enables users to collaboratively store, edit, and manage files on remote World Wide Web servers. The WebDAV protocol makes the web a readable and writable medium that enables users to create, change, and move documents on a remote server. WebDAV is useful for authoring the documents that a web server serves, but it can also be used for storing files on the Web, permitting access to the the files from anywhere.

Until recently, the calendaring world has lacked any highly adopted standards. Different vendors have used their own proprietary protocols to coordinate their clients and servers. For example, previous versions of Sun Java System Calendar Server used the proprietary WCAP protocol.

CalDAV, described in RFC 4791, was approved as an IETF standard in March 2007. RFC 4791 and its extensions provide interoperable exchange of calendaring and scheduling information between all servers and clients conforming to these standards. The CalConnect group maintains a list of supported CalDAV clients.

By supporting CalDAV, calendaring solutions enable a wide spectrum of client choices as well as more flexibility for calendar synchronization solutions, including those offered by Notify and Synchronica.

Calendar Server 6 and Calendar Server 7 Comparison and Coexistence

This information discusses some of the differences between oracle Communications Calendar Server (formerly Sun Java System Calendar Server 6) and Oracle Communications Calendar Server for CALDAV Clients 7 software, as well as some of the issues for a coexistent deployment.

Topics

Overview

Calendar Server 7 is Oracle'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 Oracle-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
WCAP 7.0 support for Convergence is available starting with Calendar Server 7 Update 1.

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

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

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. Also, this setup does require that you install the latest Calendar Server 6 patch.

Installation and Configuration

Release Description
Calendar Server 6.3 Installing and configuring Calendar Server 6.3 consists of the following high-level steps:
  1. Installing the software by using the Communications Suite 6 installer
  2. Running the Communications Suite 6 Directory Server Setup script, comm_dssetup.pl, to configure Sun Java System Directory Server
  3. Running the Calendar Server configuration program (csconfigurator.sh) to initially configure your site's specific requirements and to create a new ics.conf configuration file
  4. Customizing your system by editing parameters in the ics.conf file
Calendar Server 7 Installing and configuring Calendar Server 7 consists of the following high-level steps:
  1. Installing and configuring the GlassFish application server as the web container
  2. Installing the Calendar Server 7 software and MySQL Server software by using the Communications Suite 7 installer
  3. Running the Communications Suite 7 Directory Server Setup script, comm_dssetup.pl, to configure Sun Java System Directory Server
  4. Creating and setting up the MySQL Server database
  5. Running the Calendar Server 7 configuration program (init-config) to initially configure your site's specific requirements

For more information, see Installation Scenario - Oracle Communications Calendar Server for CALDAV Clients.

Data Migration

Migrating Calendar Server 6 data is available in Calendar Server 7 Update 1. See Migrating From Sun Java System Calendar Server 6 to Oracle Communications Calendar Server for CALDAV Clients.

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 5545, 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 support a new version of the WCAP protocol for use by Connector for Outlook and Desktop Sync clients in an upcoming release. Calendar Server 7 supports 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 Update 1 supports a similar rich access control mechanism. See Administering Calendar Server Access for more information.

Public APIs

Calendar Server 6.3:

Calendar Server 7:

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 Oracle Solaris: /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.

What's New in Oracle Communications Unified Communications Suite
Version 7 Update 1

This document summarizes the features in Oracle Communications Unified Communications Suite 7 Update 1 that are new or have been enhanced since Sun Java Communications Suite 7 was originally distributed in September 29, 2009, for the following components:

Oracle Communications Unified Communications Suite Products and Components
Version 7 Update 1
Product Version
Oracle Communications Messaging Exchange Server 7 Update 4
Oracle Communications Instant Messaging Server 8 Update 3
Convergence 2
Oracle Communications Calendar Server for CALDAV Clients 7 Update 1
Delegated Administrator for Oracle Communications Unified Communications Suite 7 (latest patch)
Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite 7.3 Update 1 (latest patch)
Oracle Communications Calendar Server 6.3 (latest patch)
Indexing and Search Service for Oracle Communications Unified Communications Suite 1 Update 1
Sun Java System Communications Sync Removed
Messaging Server HA Agent (MS_SCHA) 7
Calendar Server HA Agent (CS_SCHA) 6.3
Instant Messaging HA Agent (IM_SCHA) 7.3
Dssetup for Oracle Communications Unified Communications Suite (comm_dssetup) 6.4 (latest patch)

This document contains the following sections:

What's New in Communications Suite 7 Update 1

Communications Suite 7 Update 1 includes the following changes and new features:

Upgrading to Communications Suite 7 Update 1

If you choose to upgrade to Communications Suite 7 Update 1, see Communications Suite Upgrade Guide.

Certificate-based Authentication Support

Certificate-based authentication is a new feature available in Oracle Communications Calendar Server, Convergence, and Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite.

Messaging Server has supported client certificate authentication since before version 5.2. This version of Messaging Server supports dynamic Certificate Revocation Lists (CRL) updates. The dynamic CRL updates feature is available as a set of patches that you can apply to Messaging Server 7 update 3. See Certificate Based Authentication for Messaging Server.

Message Queue Configuration Saved After Upgrade

In previous releases, if the Communications Suite installer listed Oracle GlassFish Message Queue as a component to be upgraded, you needed to redo the configuration in your /etc/imq/imqbrokerd.conf file after the upgrade. This is no longer required, because now the Message Queue configuration is automatically retained during an upgrade.

What's New in Convergence 2

Convergence 2 includes the following changes and new features:

Customization Enhancements

To customize Convergence, be sure to install Convergence 2 Patch 1, which is now available. With the patch you are able to modify:

  • the UI
  • Widgets
  • Themes

To customize your Convergence UI, refer to Convergence Customization Guide.

Note
While you were able to customize themes in Convergence 2, the method for theme customization has been modified in Convergence 2 Patch 1. If you have either already customized themes in Convergence 2, or you have yet to customize your themes, refer to the instructions in Customizing Themes and Banner in Convergence 2.x.

In this release, themes have significantly changed. In addition, you no longer need to modify CSS files for basic customization, making the process more streamlined. For example, refer to the updated reference information for theme.json, the customization file for storing theme customizations.

Because of the differences between Convergence 1.x and Convergence 2 customizations, you cannot retain your Convergence 1.x when you upgrading to Convergence 2. Instead, you must recreate your customization in Convergence 2 following the steps described in Customizing Themes and Banner in Convergence 2.x. Upgrading from Convergence 2 is more straightforward: you can retain the customization information in the c11n directory. However, if in future releases, new variables are added to the dojo template file or to specific themes, you will need to add those values to your theme.json files as well as any new images.

To customize themes, see the newly updated Customizing Themes and Banner in Convergence 2.x.

Calendar Server 7 Update 1 Support

Support for an updated Web Calendar Access Protocol (WCAP) version 7.0 enables Calendar Server 7 Update 1 and Convergence integration. In the Convergence UI, Share Calendar and Privacy Settings can access either Calendar Server 6.3 or Calendar Server 7 Update 1 without client setting or option modifications.

To enable Calendar Server 7 Update 1 Support, see Enabling Calendar Server 7 Update 1 Support.

Dojo Port

In this release, the Dojo version in the product was upgraded from .9 to 1.3.2.

See http://docs.dojocampus.org/ for Dojo documentation.

Improvements to Attachment Search and View

The attachment folder search allows users to find attachments in their mailbox. To enable attachment folder search, Indexing and Search Service (ISS) must also be enabled. The folder search interface has an icon style grid containing all the attachments from a user's mailbox. By selecting attachments, the end user can perform actions on the item. Additionally, the user can narrow down attachments by specific criteria with Filtering options.

To enable Attachment Search and View, see Enabling Indexing and Search Service.

Certificate-based Authentication

Certificate-based authentication was introduced to enable end user authentication in Convergence. See Setting Up Certificate-based Authentication.

Proxy Authentication Support

You can enable Proxy Authentication support in Convergence. See Configuring Convergence for Proxy Authentication.

New Icon Toolbars

New toolbars were created which contain icons for the following common Convergence tasks:

  • Common icons (found above each component's toolbar): New Mail, New Event, New Task, and New Contact
  • Address Book: New Address Book, New Contact, New Group, Rename Personal Address Book Group, Delete Group/Contact, and Import/Export Group/Contact
    This figure shows the Convergence Address Book icon toolbar in the UI.
  • Calendar: Create or Subscribe to Calendar, Calendar Properties, Delete or Unsubscribe Calendar, Toggle Mini Calendar, and Import/Export Calendar
    This figure shows the Convergence Calendar icon toolbar in the UI.
  • Mail: Create or Subscribe to a Folder, Folder Properties or Sharing, Rename Folder, and Delete Folder
    This figure shows the Convergence Mail icon toolbar in the UI.

Create New Folder While Selecting Folder

End users can create new folders in the mail folder selection dialog. New folder functionality in mail folder selection occurs in the following locations:

  • General Tab
    • Copying Sent Messages
    • Deleting Mail Messages
    • Saving Drafts
  • Mail Filters Tab
    • Move message to and copy message to drop down
  • New Account Tab
    • POP account folder that collects messages

Schedule Calendar Resources

In addition to modifying the field organization and spacing in the New Event form, end users can schedule resources with a separate search field and text box for resource look-up. People and resources are invited separately from one another.

New Calendar Event and Task Types

When end users create new events or tasks, they can mark events and tasks as public, private, or displaying only date and time. They can also select the type of event or task from a number of categories such as Business, Conference Call, Seminar, Personal, and so on.

Calendar print functionality in daily and weekly views has changed between Convergence 1.x and Convergence 2

If you print daily or weekly calendars, they print as an agenda-style format instead of a grid-style format. The agenda-style calendar is better at showing the details of an event, particularly when there are multiple events or overlapping events in a single day.

If you choose to print a month view calendar, it prints in a grid-style format.

Note
You are still able to view daily and weekly calendars in Convergence in both grid-style as well as agenda-style formats.

Check Box Next to Email in Message List

Check boxes have been added to the message list in the mail window.

Enabling and Disabling Message Preview

An end user can change preferences in Options to hide the preview pane in the message list. By default, message preview is enabled.

An administrator can also turn off the mail preview pane for all users on an entire site. This overrides any action by an end user to enable the preview pane. If the Administrator enables preview pane (the default), then the end user may override the preference to disable the preview pane.

See the mail.enablemsgpreview option for more information about enabling and disabling message preview.

Multi-user Chat

Convergence 2 supports multi-user instant messaging conferences (chats). This functionality enables XMPP users to exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). Features of multi-user chat include:

  • Conferencing tools, including room rosters, invitations, private conversations, and transcripts

See the online help packaged with the Convergence Client for Oracle Communications Unified Communications for information on enabling multi-user chat.

Instant Messaging Conversations in Tabs

In previous versions of Convergence, Instant Messaging (IM) chats were opened in new browsers. Beginning with Convergence 2, end users can launch IM chats in different tabs within the same browser.

Address Book Enhancements

Beginning with this release, administrators can support multiple corporate directories. Unlike personal address books which are created by end users, corporate directories are configured by administrators. See Configuring Corporate Directories.

Additionally in this release, end users can manage multiple Personal Address Books. They can also select or delete multiple contact entries in their Personal Address Book through keyboard shortcuts and check boxes.

What's New in Messaging Server 7 Update 4

Messaging Server 7 Update 4 includes the following changes and new features:

Third-Party Authentication Server Support

Beginning with version 7 Update 4 Patch 22, Messaging Server now provides support for third-party authentication servers by supporting a protocol designed to integrate third-party authentication services. For more information, see: Third-Party Authentication Server Support.

Support for In-place Upgrade of 32-bit to 64-bit Messaging Server

You can now do an in-place upgrade from 32-bit to 64-bit Messaging Server using commpkg upgrade. Previous versions of commpkg upgrade did not provide this option.

Support for Messaging Server 64-bit on Red Hat Linux 5

You can now upgrade a Red Hat Linux 5 installation to a more scalable 64-bit implementation. However, the Message Queue (MQ) library is not yet available for Red Hat Linux 5 64-bit, so Red Hat Linux 64-bit is not compatible with Indexing and Search Service for Oracle Communications Unified Communications Suite nor with other uses of Java MQ notifications. However, the Messaging Server's event notification system (ENS) is fully supported on this platform. Until a 64-bit version of MQ is available on Red Hat Linux 5, you can deploy on the Solaris operating system (OS), which is now 64-bit only, or you can use the deprecated Red Hat Linux 32-bit version of Messaging Server if Indexing and Search Service or Java MQ support is required.

Red Hat Linux 5 Update 3 64-bit Installation Requirements

Because it uses the default installation cluster for Red Hat Linux 5 Update 3 64-bit, Messaging Server does not require any additional RPMs to run. The %packages section of the kickstart file (anaconda-ks.cfg) for the default installation is as follows:

Sendmail Is Disabled on Solaris OS and Red Hat Linux

When you run configure, you are now informed that sendmail is disabled. This functionality can be disabled if you use the --ignoreSendmail option when running configure.

IMAP IDLE Command

This version of Messaging Server enables IMAP IDLE by default, using the Event Notification Service (ENS). No configuration is required. In addition, IMAP IDLE now only works using ENS, because the ability to use IMAP IDLE with JMQ has been removed. For existing installations, customers should, at a minimum, ensure that the ENS server is enabled by setting the configutil parameter local.ens.enable to 1 and restarting the Messaging Server:

configutil -o local.ens.enable -v 1

The following configutil parameters are now marked OBSOLETE and are no longer valid:

service.imap.ensidle
service.imap.idle
service.imap.idle.jmq.library
service.imap.idle.jmqhost
service.imap.idle.jmqpassword
service.imap.idle.jmqport
service.imap.idle.jmqtopic
service.imap.idle.jmquserid
local.store.notifyplugin.enshost
local.store.notifyplugin.ensport
local.store.notifyplugin.enseventkey
local.store.notifyplugin.noneinbox.enable

Customers may remove these obsolete parameters from their configuration, although the only impact is to maintain a clean configuration.

Options can be removed by using the -d switch with configutil. For example:

configutil -o service.imap.ensidle -d

Customers who do not use ENS or JMQ for external notification systems can also delete local.store.notifyplugin, because an appropriate default value is now configured.

ENS Security Improvements

The new ENS server now supports two options to control TCP access to the ENS server (service.ens.domainallowed and service.ens.domainnotallowed). These options work the same way as the equivalent options for POP, IMAP, and HTTP. These options replace the functionality of the ENS_ACCESS environment variable that was included in the legacy ENS server.

MeterMaid Improvements

MeterMaid has been enhanced to offer Greylisting support. Greylisting is a technique that you can use to help Messaging Server reduce spam. See Implementing Greylisting by Using MeterMaid for more information.

Sieve Date and Index Extensions

The Sieve Date and Index extensions RFC 5260 are now fully supported. See also Features Introduced in Messaging Server 7 Update 4 for other changes to sieve handling.

SASL and High-Performance User Lookup and Authentication (HULA)

Messaging Server no longer depends on a Sun-private fork of CMU libsasl (SUNWsasl package) for authentication services. The entire Messaging Server product now uses the modern HULA library that has been used by the MMP for several releases for authentication. This change will enable faster implementation of consistent authentication-related features in the future, as well as some behavior changes:

  • Improved logging and error text for authentication and authorization failures.
  • After a user's password changes, authentication with the new password works immediately.
  • The new option to simplify SMTP configuration that requires SSL/TLS prior to password login, service.smtp.plaintextmincipher, works like service.imap.plaintextmincipher).
  • The new option for HTTP proxy authentication to IMAP server, local.http.replayformat, works like the MMP's replayformat setting. This enables configurations where the internal UID is not used for login 6404489.
  • DIGEST-MD5, which was deprecated for several releases, has been removed.
  • The undocumented backwards compatibility for PMDF's security.cnf was removed to make it easier to identify configuration errors. Equivalent functionality is provided with sasl.* configutil settings.
  • The undocumented backward compatibility for the SIMS 4.0 inetSubscriberStatus and inetAuthorizedServices attributes was removed to simplify access control (these attributes are now ignored). The inetUserStatus, mailDomainAllowedServiceAccess, and mailAllowedServiceAccess attributes provide equivalent functionality.
  • The undocumented backward compatibility for the NMS 4.x nsmsgDisallowAccess and mailAccessDomain attributes was removed to simplify access control (these attributes are now ignored). The mailDomainAllowedServiceAccess and mailAllowedServiceAccess attributes provide equivalent functionality.
  • Support for the POP3 AUTH command with no arguments to list authentication mechanisms (a feature replaced by the POP3 CAPA command in RFC 2449, published in 1998) was removed to enable simpler support for new authentication mechanisms.

Dynamic Certificate Revocation Lists (CRL) Updates

Messaging Server has supported client certificate authentication since before version 5.2. This version of Messaging Server supports dynamic Certificate Revocation Lists (CRL) updates. The dynamic CRL updates is available as a set of patches that you can apply to Messaging Server 7 Update 3.

New defragment Channel Options

The defragment channel now has a channel option called MAX_PARTS. MAX_PARTS determines the maximum number of parts that a message can have and still be reassembled. The maximum is 100,000; the default is 1000.

ignoremessageencoding and ignoremultipartencoding Channel Options

The ignoremessageencoding and ignoremultipartencoding channel options now affect MIME processing done by the conversion, SMS, calendar, and user-written channels.

LDAP Security Improvements

To improve product security, the LDAP SSL client (enabled by local.ugldapusessl) now validates the LDAP server certificate by default and fails if the server's certificate cannot be validated. Use configutil -o local.ldapcheckcert -v 0 to turn off LDAP SSL certificate validation.

The configure utility now supports LDAP SSL. This is done by including the --ssl switch when configuring LDAP. You should store the LDAP server certificate or CA as a trusted peer or CA in cert8.db (using certutil) in the directory which will be used for Messaging Server product configuration (the default location is /var/opt/sun/comms/messaging64/config).

Using IPv6 with Messaging Server

You can use IPv6 with Messaging Server. See Using IPv6 with Messaging Server for details.

Enhancements to the MTA's BURL Support

BURL has been enhanced to support additional configuration regarding its behavior. See BURL Support for SMTP SUBMIT.

nslog Provides Additional Log File Functionality for Dispatcher and Job Controller (CR 6185167 and CR 6191669)

The capability of nslog to handle log file rollover can now be used with Dispatcher and Job Controller.

To enable this functionality, set the USE_NSLOG=1 option in the beginning of the dispatcher.cnf or job_controller.cnf file. You can then set up the logfile.dispatcher.x or logfile.job_controller.x configutil options to control the various logging characteristics. This uses the additional functionality provided by the logfile configutil options, including log file rotation and expiration.

When this functionality is enabled, the Dispatcher log file is named dispatcher by default instead of dispatcher.log-x. Similarly, the Job Controller log file is named job_controller by default instead of job_controller.log-x.

IMAP ID Command (CR 6339827)

The ID extension to IMAP allows the server and client to exchange identification information on their implementation to make bug reports and usage statistics more complete. IMAP ID information is logged to the imapd log file at info level. This means the client ID information is not logged unless you use configutil -o logfile.imap.loglevel -v info (or a more verbose logging level). For more information about the ID extension, see RFC 2971.

Support for IPv6 Data Type for MeterMaid Tables (CR 6823375)

IPv6 addresses can now be used as lookup keys in MeterMaid tables when you set the metermaid.table.*.data_type configutil parameter to ipv6.

SMTP Server Rejects STARTTLS When Followed by Additional Commands

In Messaging Server 7 Update 4 Path 21, the SMTP server rejects STARTTLS if there are additional commands piggybacked on it in the stream. The purpose of this is to avoid certain attacks.

MTA and MMP Minor Features

A number of smaller features were also introduced in this release. See: MTA and MMP Minor Features.

What's New in Calendar Server 7 Update 1

Calendar Server 7 Update 1 includes the following changes and new features:

Support for an Updated WCAP Protocol Version 7.0

Web Calendar Access Protocol (WCAP) is a command-based system consisting of client requests and server responses for transmitting calendaring data. WCAP returns calendaring data using the HTTP protocol. In most cases, Calendar Server receives data through URL-encoded arguments to the commands.

WCAP commands consist of five general categories of usage:

  • Creating calendars
  • Storing, retrieving, and managing calendar properties
  • Storing, retrieving, and managing calendar data
  • Scheduling
  • Retrieving calendar information of other users

Calendar data is always stored in Standard iCal format in the calendar database. But you can retrieve this calendar data by using WCAP commands with the fmt-out parameter set to text/calendar, text/json, or text/xml. The default format is text/calendar which outputs in standard iCal format as defined in RFC5545.

WCAP is a command-based system consisting of client requests and server responses for transmitting calendaring data. WCAP returns calendaring data using the HTTP protocol. In most cases, Calendar Server receives data through URL-encoded arguments to the commands.

WCAP enables Calendar Server 7 Update 1 and Convergence 2 integration.

For more information, see Calendar Server WCAP Developer's Guide.

Implicit Scheduling

Calendar Server 7 Update 1 supports implicit scheduling, in which the server has the capability to add invitations that arrive in the calendar inbox to the user's default calendar without any client intervention. This implementation is based on the latest CalDAV scheduling draft. Invitations created by using the WCAP protocol always lead to implicit scheduling. Storing an event with attendees automatically triggers invitations to all attendees.

Support for CalDAV and CardDAV Autodiscovery

Calendar Server 7 Update 1 supports the .well-known URI concept as defined in Locating CalDAV and CardDAV services for CalDAV clients to access the Principal URI without having to specify the entire URI. That is, access to / (root) or /.well-known/caldav/ is redirected to the /dav/principals/ URI.

Invitation of LDAP Groups

Calendar Server 7 Update 1 supports the ability to invite entire groups in the LDAP directory as one attendee. The group is maintained as one attendee in the organizer's calendar, but the Scheduling Service expands the group and adds each member as a recipient of the invitation. When storing the invitation in each recipients' calendar, that recipient is added as an ATTENDEE, which is referenced as a member of the group. When a recipient replies, that recipient is added as an individual ATTENDEE, also referenced as member of the initial group in the organizer's calendar. This feature can be used to invite both static and dynamic groups in LDAP.

Access Control Support

Calendar Server 7 Update 1 enables you to set and make use of the access control list (ACL) feature to determine access control for scheduling, calendar properties, and calendar components such as events and "todo's" (tasks). An ACL consists of one or more access control entries (ACE), which are strings that collectively apply to the same calendar or component. In this release, access control management is restricted to the WCAP and davadmin interfaces.

Document Store

Calendar Server 7 Update 1 introduces the document store, which is used for storing calendar attachments. The document store can be local or remote. Essentially, the document store is file-system-based storage with a built-in web server front-end that is used by the Calendar Server to store and retrieve documents.

Support for Resource Calendars

Calendar Server 7 Update 1 supports special handling of resource calendars. A resource in the context of scheduling is any shared entity that can be scheduled by a calendar user but does not control its own attendance status. For example, you would use a resource calendar for such items as conference rooms and video equipment. Some of the related features are auto-acceptance of invitations, declining invitations that could result in conflicting multiple bookings for the same time slot, and so on.

The davcore.autocreate.calattendantresourceflags configuration options control the settings on a new resource calendar. You change the settings for a resource by using the davadmin account command and set_accountprops WCAP command.

Calendar Subscription Support

Calendar Server 7 Update 1 provides the capability for one user to subscribe to other users' calendars on the server and maintain a subscription list, for easy access. The ability to subscribe, list subscriptions, and unsubscribe is limited to the WCAP access for this release, since a standard CalDAV way does not yet exist.

You can use the WCAP command subscribe_calendars.wcap to subscribe, unsubscribe_calendars.wcap to unsubscribe, and list_subscribed.wcap to list your subscriptions.

CalDAV clients can access other calendars to which a logged-in user has access by explicitly providing the URLs.

Property-based Search Filtering

Certain calendar properties were indexed to enable faster search based on those filters. The WCAP filter parameter of the fetch command uses this feature. See Filter Parameter for more information.

Enhancements and Changes to davadmin

  • The calresource operation has been renamed to calcomponent.
  • The migration operation has been added for migration of data from Calendar Server 6.3 to Calendar Server 7.
  • The account operation has been added to enable listing, deletion, and properties modification of user accounts.
  • The calendar operation has been enhanced to enable setting of more calendar properties.

WebDAVSync Enhancements

The WebDAVSync support was enhanced to match the latest draft. An extension to the WebDAV spec, WebDAVSync defines a protocol for HTTP clients to query an overview of the data changes on the HTTP server, enabling the clients to efficiently synchronize their local data cache with the server.

Secure LDAP Connection

You can configure Calendar Server 7 Update 1 to communicate with Directory Server over SSL. See the necessary configuration changes as described in Oracle Communications Calendar Server for CALDAV Clients Post Configuration.

Migration From Sun Java System Calendar Server 6.3

The davadmin migration command enables you to migrate Calendar Server 6.3 data to Calendar Server 7 Update 1. See Migrating From Sun Java System Calendar Server 6 to Calendar Server 7 for more information on how to perform the actual data migration.

Public and Private Events and Tasks Filter

Calendar Server supports the iCal CLASS property and behaves as follows.

When creating a new event or task, a user can specify whether the event or task is Public, Private, or Time and Date Only (confidential):

  • Public. Anyone with read permission to the user's calendar can view the event or task.
  • Private. Only owners of the calendar can view the event or task.
  • Time and Date Only. These are confidential events and tasks. Owners of the calendar can view the event or task. Other users see it just as a busy slot when requesting freebusy information.
Note
In Calendar Server 6.3, you can set the calstore.filterprivateevents parameter to filter or not filter Private, and Time and Date Only (confidential) events and tasks. Calendar Server 7 does not provide a way of disabling filtering private and confidential events and tasks. That is, Calendar Server 7 always filters (recognizes) Private, and Time and Date Only (confidential) events and tasks.

What's New in Calendar Server 6.3

This version of Calendar Server 6.3 includes bug fixes only.

What's New in Indexing and Search Service 1 Update 1

Indexing and Search Service 1 Update 1 includes the following changes and new features:

Scalability Improvements

Real-time event processing has been improved, allowing at least an order of magnitude higher indexing rate.

Office 2007 Open XML File Format Support

The Office 2007 Open XML File Format (docx, xlsx, pptx) is now supported. These attachments are categorized in the atdoc, atxls, and atppt attachment types along with the Word, Excel, and PowerPoint Binary File Format attachments (doc, xls, ppt) that were previously supported.

Apple iWork File Format Support

Apple iWork (Keynote, Pages and Numbers) files are now supported. These attachments are categorized into the new iwork attachment type.

New Attachment Types: ataudio, atvideo, atcompress, atimage

To categorize more attachment types, new types have been added for audio, video, image, and compressed file formats.

Attachment Search Available for All Attachment Types

All attachment types (for example, atplain, athtml, and new attachment types such as ataudio) can now be searched by type in attachment (contentFormat=attachmentOnly) searches. In Indexing and Search Service 1, only atjpeg, atpdf, atodf, atdoc, atppt, atxls, and atvsd were searchable by type in attachment searches.

Attachments No Longer Saved to Attachment Store

Attachment files are no longer saved to the attachment store. Instead, search results include body part information for pointing back to the attachment file residing on the Messaging Server store.

Search Timeout Can Be Client-Specified

A new search query parameter, timeoutmsec, allows a timeout to be set per search query.

New issversion Utility

The new iss-base/bin/issversion utility reports versioning information.

Admin CLIs Are Now Symlinked Into and Executable From the iss-base/bin Directory

For convenience, the admin command line interfaces are now symlinked into and executable from the iss-base/bin directory.

issadmin.sh Now Has --threads and --continueonerror Options for --accountlist Actions

The new --threads option enables issadmin.sh --accountlist actions to be performed in parallel across a set of threads. The new --continueonerror option enables issadmin.sh --accountlist actions to continue on error. (By default, the first account in an --accountlist action that finds an error terminates the remaining actions.)

issadmin.sh Now Has --listactiveservices and --stopservice Actions

The new command line options, --listactiveservices and --stopservice, enable services that are running to be listed and terminated if necessary.

New indexSvcFork.sh Script to Replace indexSvcFork.pl

The utility which supports bootstrapping a set of users in parallel has been rewritten for improved performance.

svc_control.sh stop No Longer Persistent Across Reboots

In Indexing and Search Service 1, if the services were stopped after a reboot, they would remain stopped. This behavior was changed in Indexing and Search Server 1 Update 1 to make svc_control.sh stop a temporary action, not persistent across reboots.

A commpkg upgrade Now Requires That postpatch_restart.sh Be Run Manually After the Upgrade

Because the postpatch process might be interactive, you must now manually run postpatch_restart.sh if you upgrade to this release by using commpkg upgrade.

Accounts Must Be Rebootstrapped After the Upgrade

Although Indexing and Search Service 1 indexes are backward-compatible with this release, you should rebootstrap all user accounts after upgrading to Indexing and Search Service 1 Update 1 to index the new attachment types and other changes in this release.

What's New in Instant Messaging 8 Update 3

Instant Messaging 8 Update 3 includes the following changes and new features:

Shoal for Conferences Across Server Pools

Instant Messaging 8 Update 3 enables the use of Shoal group messaging to broadcast conference messages across the server pool. You can now send conference messages across the server pool even if you have not used Shoal for auto-discovery or across subnets. For more information, see Using Shoal for Conferences Across Server Pools.

XEP 0191 - Simple Communications Blocking Protocol Support

This protocol enables you to block communications with selected users in an instant messaging system. You can block communications from contacts using any XEP-0191-compliant client. For more information, see XEP 0191.

What's New in Delegated Administrator 7

This version of Delegated Administrator 7 includes bug fixes only.

What's New in Connector for Outlook 7.3 Update 1

Connector for Outlook 7.3 Update 1 includes the following new features:

  • Folder size and quota
  • Support for Windows 7
  • Support for Apple iPhone

What's New in DSsetup 6.4p6

This version of DSsetup contains the following new features and bug fixes:

  • The sunMaxGroups is now correctly defined in the sunDelegatedOrganization objectclass, which is used by Delegated Administrator.
  • A new search directory for LDAP utilities is available in the Directory Server 7 zipped version.
  • The default schema type is now schema 2.
  • The message pertaining to Access Manager has been removed. You can now use schema2 without Access Manager.

Oracle Communications Calendar Server for CALDAV Clients
Version 7 Update 1

These Release Notes contain important information available at the time of the general release of Oracle Communications Calendar Server for CALDAV Clients, including:

About Calendar Server 7 Update 1

See Introduction to Calendar Server 7.

What's New in This Release of Calendar Server for CALDAV Clients 7 Update 1

See the What's New document.

Requirements for Calendar Server for CALDAV Clients 7 Update 1

Calendar Server for CALDAV Clients 7 Update 1 Installation Notes

See the Communications Suite Installation Guide for information on installing Calendar Server for CALDAV Clients 7 Update 1.

Calendar Server for CALDAV Clients 7 Update 1 Upgrade Notes

The database schema is not compatible between Calendar Server 7 and Calendar Server 7 Update 1. As no upgrade tool exists, you must use the following steps to upgrade:

  1. Export all data into ics files.
  2. Create a database backup.
    For example:

    where caldav is the database name.
    If you need to read the data in this backup file, restore it to a Calendar Server 7 host by running the following command:

    Then export the required data.

  3. Shut down Calendar Server services.
  4. Reinitialize the database.
    Use the initDB.sh script.
    Usage:
    initDB.sh [host] [database]
    

    If host or database are not specified, the script uses localhost and caldav.
    The initDB.sh script initializes the MySQL Server database by dropping tables, thus destroying all Calendar Server data. In the script, make these changes:

    • All -umysql should be changed to -umysql-username.
    • All -pmysql should be changed to -pmysql-usermysqlpassword.
  5. Run the commpkg upgrade command to upgrade to the Calendar Server 7 Update 1 software.
  6. Restart Calendar Server.
  7. Import the data.

Calendar Server for CALDAV Clients 7 Update 1 Compatibility Issues

Connector for Microsoft Outlook for Oracle Communications Unified Communications Suite is not supported with this release of Calendar Server for CALDAV Clients.

Problems Fixed in This Release of Calendar Server for CALDAV Clients 7 Update 1

6846562

Schema 1 support for CalDAV Server.

6740679

[Appleical]Task creation with Due Date creates 403 error mismatch: DTSTART floating = false.

6791801

[AppleiCal]get http 403 when modifying an instance to add an attendee.

6879002

davadmin calresource import fails for events with ORGANIZER.

6879006

davadmin calresource import fails for events with ATTENDEES.

6811845

MKCOL with weird body should fail; extended MKCOL support not complete.

6930872

"davadmin calcomponent list" fails if summary field is null.

6953853

Add davadmin command-line parameter for enabling tracing instead of logging level.

6904301

Cannot modify a recurrence event.

6907331

Changing responses throws exception in log.

6926791

Create calendar with description containing like break make calendar unavailable.

6952381

DavException in calendar log when searching for calendar to subscribe to.

6931683

Event notification are received even when user option is not enabled.

6929248

Exception is seen in calendar.log file when privacy settings is set on user.

6928504

LDAPDN.equals is not handling case sensitivity correctly.

6926195

Manage permissions are granting owner permissions to all user's calendars.

6920766

Need to be able to set Calendar Attendant flags through davadmin.

6839625

Need to implement davadmin account delete.

6933905

Notification settings to default calendar should apply to inbox too.

6909847

Problem with rights to other calendars.

6907322

Recurrence data are lost if you open in edit mode.

6951272

SearchCalPropsHandler LDAP or home collection search failed. The minimum search string length is 3.

6953468

Switch davadmin version to use build version.

6888870

Update DavServiceImpl to log the readable user id instead of the internal unique id.

6946099

By default resource calendar is inaccessible to another user.

6891177

davadmin account delete fails due to new default collections.

6920682

davadmin calendar create does not set acl.

6953467

davadmin calendar list should display only the default calendar and secondary calendars.

6866014

davadmin calendar/calresource cannot handle user account under non-default domain.

6965242

davadmin: path to truststore (secure connection) is required when using -F option but not on command line.

6920768

Need to be able to set owner for resource calendar using davadmin.

6716693

Should have option to use ldap proxy auth when querying principals namespace.

6933908

Some davadmin command for users in non-default domain fails.

Problems Fixed in Patch 3

The following table lists the bugIDs that are fixed in Patch 3.

BugIDs Fixed in Calendar Server 7 Update 1 Patch 3

BugID
Former Sun CR
Description
  7022418 CalDAV reminder email subject line garbled (locale french)
12307308 7015367 The list_subscribed.wcap command returns a failure when one of the subscribed users is removed from LDAP

6891672 Automatic purge of inbox, outbox entries
12307646 7016986 Problem migrating resource calendar where one of the owner is no longer in LDAP
12307674 7017181 The davadmin migration should use calid to migrate events
12307676 7017183 Localization bundles are taken from the wrong place
12300889 6983229 Email notifications should be disabled for resources by default
  6909419 Multiuser support for get_schedperms.wcap
  6916344 The set_schedperms.wcap command accepts self as part of acl and returns as part of get_schedperms.wcap
12309293 7026561 Build timestamp from davadmin -V displays in 12 hr clock

6945985 Extract Content-ID and store as X-S1CS-CLIENT-ID when attachments are uploaded to an event
12309650 7028778 Changing reoccurring event single instance start-time to later time causes error
12348602   Inviting an LDAP group through Convergence fails and the event is never sent out from Calendar Server
12305730 7003292-2204190 Fine level migration logs should go to Migration log file
12302913 6975726-2201531 Move MessageException logger from EmailHandler to consumer class and lower log level
12309452 7019553-2207675 The storeevents.wcap returns error 60 when an instance of meeting moved to a different time
12309108 7015109-2207382 The storetodos.wcap ignores status parameter
12309107 7011405-2207381 Updating attendee part-stat status information fails from the organizer
12309106 7011352-2207380 The get_accountprops.wcap returns errno:94 for users with no schedule permissions
12306265 7005022-2204777 Migration needs to handle CS6 in non-virtualdomain mode too
12302765 6989792-2201331 Timerange based query on the scheduling inbox does not return anything
12301641 6891672-2200228 Automatic purge of inbox, outbox entries
12309653 6945985-2207829 Extract Content-ID and store as X-S1CS-CLIENT-ID when attachments are uploaded to an event
12309927 7020806-2208008 Attendee/organizer mail addresses must be canonicalized during migration
12305732 7006773-2204192 Migration fails if calmaster password contains a semicolon
12309572 7028137-2207756 Patch install breaks the configuration, if configuration was changed after installation
12308874 6916494-2207131 Multibyte subject/mailbody in calendar email notifications is garbled
12309538 7028096
Migration fail with - Validation exception: multiple components with same uid but different date type
12309520 7028057
Migration fail with - PERCENT-COMPLETE with invalid value: -1
12306355 7011191-2204904 The davadmin command strip fails update ACE when used with -f option
12309853 7029972 Internal server error while exporting data using wcap
12367256 7014697 Need to define specifc invalid sync token error for fetchcomponents_by_lastmod.wcap

Known Issues and Limitations in Calendar Server for CALDAV Clients 7 Update 1

These Release Notes contain important information available at the time of the general release of Oracle Communications Calendar Server for CALDAV Clients.

6821041

davadmin config command takes invalid value for notification.dav.smtpport

6748104

Event request notification is not displaying the modified time correctly for modification of a single occurrence of a recurring event

6957963

notifemail and notifrecipient properties are inconsistent between davadmin commands

The davadmin account command uses the following parameters:

  • notifemail - Email notification enable flag (0 = disabled, 1 = enabled).
  • notifrecipients - Recipients of email notifications. Multiple values are separated by a space.

The davadmin calendar uses the following parameters:

  • notifemail - Notification enable/disable boolean. Default true.
  • notifrecipient - Space separated list of notification addresses. Default is account's email address.

The two commands should use the same values and property key words.

6724653

Separate our consumer logs from Application Server logs

6737896

Add support for Apple iCal private events

6795953

The entries about loglevel should only allow valid input to "DEBUG/INFO/FINEST/FINE"

6808801

The davadmin config command takes invalid values to log.dav.*.maxlogfiles

6822646

Delete range of all day recurring events fails if the range includes an exception

6834023

Error while modifying a single instance of recurring event in Thunderbird

6868370

Convergence calendar busy information is not shown for All Day in WCAP co-deployment scenario

6930726

iCal/Lightning require relogin to get synced deleted event/Todo's

6934312

The davadmin calcomponent export command with the -i option exports the user's entire calendar instead of the particular URI

6920439

Calendar Server should give a better error message for not doing LDAP provisioning
Calendar Server 7 does not do its own provisioning. You must use Delegated Administrator or direct LDAP provisioning. You need to add the following LDAP classes for your Calendar Server deployment:

  • objectClass: icsCalendarUser
  • objectClass: nsManagedPerson

6943472

Logging in as calmaster might result in DavException "Recipient is on another internal server"
This situation occurs if your deployment is using the davcore.scheduling.localuserattr value (usually davStore) to determine if a user is a Calendar Server 7 enabled user and this attribute is not ste for the administrative user entry in LDAP.

Workaround: Add the required attribute to the administrative user's LDAP entry.

6930726

Lightning 1.0 beta1 requires relogin to get synced deleted event/Todo's

6947374

'Error parsing ical data: User Owners could not be found' while doing migration

This message indicates that a user specified that was specified in the access control list or in subscription list no longer exists. You can ignore this error message.

6943226

Apple iPhone STATUS not being taken into account when invitation event canceled by organizer

When an iPhone 3.x user gets an invitation from a Lightning user, there is no option to accept, reject, or decline the event. Additionally, when the inviting user deletes the event, the iPhone user does not receive an event notification, nor is the event deleted from the user's calendar. The event is in read-only mode. This issue is fixed starting with the iPhone 4 release.

6932487

Check Availability functionality is not clear in case of introp
"All day event" freebusy info is always returned in Zulu.

6962306

Notification producer need to post a special msg to instruct consumer to fetch large msg themselves
This results in a warning message in the log file: "JMS provider fails to write the message due to some internal error."

6847281

Cannot add a new back-end host to configuration

6974743 (Fixed in Calendar Server 7 Update 1 Patch 2)

Backslash not properly escaped in calendar names

6984442

Error accessing shared calendar using CalDAV clients

Attempting to access a shared calendar by using Thunderbird Lightning plugin (1.0b2 or 1.0b3pre) fails due to 404 error. In the case of iCal accessing shared data, the user gets an error the other user's inbox was not found. If there are other calendars that the user does not have access to, errors might occur about those calendars as well. However, the user is able to display the contents of the calendars to which permission was granted.

Scenario:
For user A to access user B's calendar:

  1. In Convergence, user B grants user A read, read/write, or owner privilege through the Share panel.
    Alternately, an administrator can do the same by running the davadmin calendar command to set ACLs.
  2. To view the newly shared calendar of user B, user A creates a new calendar or account on the client, explicitly entering user B's calendar URL (for Lightning) or principal URL (for iCal), depending on what a particular client takes.

Redistributable Files for Calendar Server for CALDAV Clients 7 Update 1

This release of Calendar Server for CALDAV Clients does not contain any files that you can redistribute.

Installation Scenario - Oracle Communications Calendar Server for CALDAV Clients
Version 7 Update 1

Topics:

Overview of This Scenario

The following installation information describes how to install and configure Oracle Communications Calendar Server (CalDAV Server) version 7 Update 1. It assumes you have already made your architectural and design decisions. For example, it assumes that you know the total number of servers in your deployment, the number of front-end and back-end servers, and so on. If you are still in the planning or evaluating process, see the following documents:

Assumptions

This scenario shows how to install Calendar Server 7 Update 1 on a separate host. It is based on the Install Calendar Server 7 Update 1 leaf in the Communications Suite Installation Flowchart. The scenario makes these assumptions:

  • You are deploying Communications Suite on a single host or Solaris zone, or multiple hosts or Solaris zones.
  • A Directory Server host is already installed.

Which Software Components and Downloads Do You Need?

  • Communications Suite: Calendar Server, MySQL Server (installed as a dependent product for Calendar Server when you run the Communications Suite Installer)
  • Application server web container for Calendar Server: GlassFish
  • LDAP server: Directory Server

Installing and Configuring a Calendar Server 7 Update 1 Deployment

The tasks to install a Calendar Server 7 Update 1 deployment are as follows:

Note
If you are installing a Calendar Server 7 Update 1 front end on one host and a Calendar Server 7 Update 1 back end on a separate host, note the following installation differences:
  • If you don't have an existing MySQL server, install one by prefixing the Calendar Server 7 Update 1 option with a tilde ({~}) to indicate that you only want to install the shared component dependencies of that product.
  • Uncheck the dependency of MySQL when installing the Calendar Server 7 Update 1 software.
  • Configure MySQL Server.
  • Configure Calendar Server 7 Update 1.
To Check Requirements for Calendar Server 7 Update 1

See Requirements for Calendar Server 7 Update 1.

To Get the Software
  1. Go to Get the Software.
    From this site, download Communications Suite 7 Update 1. Also download Sun GlassFish Enterprise Server 2.1.1 and Directory Server (6.3.1 or 7), which are required for Calendar Server 7 Update 1.
    Solaris SPARC: sges_ee-2_1_1-solaris-sparc-ml.bin
    Solaris x86: sges_ee-2_1_1-solaris-i586-ml.bin
    Red Hat Linux: ges_ee-2_1_1-linux-ml.bin
  2. Continue with the next task.
To Install Directory Server

See Installation Scenario - Directory Server.

To Install and Configure Sun GlassFish Enterprise Server 2.1.1

See Installation Scenario - GlassFish Server.

To Install the Calendar Server and MySQL Server Software
  1. Make sure you have met the pre-installation requirements.
  2. To install Calendar Server, run the Communications Suite installer.
    The installer is a single unified utility called commpkg. It installs (but does not configure) the Communications Suite products. commpkg does all the necessary preparation work before installing the product software on the system. Run the following command:
    ./commpkg install
    

    For more information, see commpkg install Usage.

  3. Select Calendar Server 7 Update 1 and proceed with the installation.
    MySQL Server is automatically selected as a dependent product. If you need to install just MySQL Server (for a multi-host deployment with a MySQL Server back-end host), type ~option number.
    The default installation directory for Calendar Server 7 Update 1 is /opt/sun/comms/davserver.
  4. If the installer detects older versions of LDAP tools, you are prompted to change them.
    You must answer y, otherwise, during the initial configuration (running init-config), the ldapmodify command does not run.
    Shared component LDAPCSDK6 has a different pkg version installed
    Description: ldap c sdk 6
      Current pkg Version (SUNWldapcsdk-libs): 6.00,REV=2005.11.29.16.11
      To be installed pkg version (SUNWldapcsdk-libs): 6.00,REV=2006.12.11.00.35
      Product Version: 6.0
    Note that changing pkg versions is irreversible
    On the other hand, if you do not change it,
    some products may not work properly
    An alternative is to start over and do a multi-install using --altroot
    
    Do you wish to change pkg versions for LDAPCSDK6 [n] : y
    
    Shared component LDAPCSDK6 Tools has a different pkg version installed
    Description: ldap c sdk 6 Tools
      Current pkg Version (SUNWldapcsdk-tools): 6.00,REV=2005.11.29.16.11
      To be installed pkg version (SUNWldapcsdk-tools): 6.00,REV=2006.12.11.00.35
      Product Version: 6.0
    Note that changing pkg versions is irreversible
    On the other hand, if you do not change it,
    some products may not work properly
    An alternative is to start over and do a multi-install using --altroot
    
    Do you wish to change pkg versions for LDAPCSDK6 Tools [n] : y
    
  5. If you want to install only the Calendar Server front end, to connect to remote Calendar Server back end(s), then you can remove the MySQL packages, which aren't needed on the Calendar Server front end.
    • For example, on Solaris OS:
      pkgrm mysql
      pkgrm SUNWcomms-mysql-marker
      
    • For example, on Red Hat Linux:
  6. Continue with the next section.
To Initialize and Configure MySQL Server

You can either run the following steps in this section or run the config-mysql script to prepare a new MySQL installation for use with the Calendar Server 7 Update 1. For more information on running the config-mysql script, see Running the Oracle Communications Calendar Server config-mysql Script.

Caution
You must use the MySQL connector version packaged with Calendar Server. Do not use a different version.

The Communications Suite installer has already created a mysql group and a mysql user, and installed the MySQL Server software. The Solaris OS default base directory (basedir) is /opt/mysql/mysql. The Red Hat Linux default base directory (basedir) is /usr and the data directory (datadir) is /var/lib/mysql.

Note
When necessary, the following instructions show where commands differ between Solaris OS and Red Hat Linux.
  1. Initialize the database.
    1. Remove the pre-created data, for example:
      # rm -rf /opt/mysql/mysql/data
      # rm -rf /var/lib/mysql
      
    2. Create an initial database, for example:
      • On Solaris OS:
        # /opt/mysql/mysql/scripts/mysql_install_db --user=mysql --ldata=/var/mysql
        
      • On Red Hat Linux:
        # /usr/bin/mysql_install_db --user=mysql --ldata=/var/lib/mysql
        

        Substitute a different directory for /var/mysql if desired.

  2. If the MySQL configuration file, /etc/my.cnf, is absent, create it with the following content:
    Change basedir and datadir if needed. Make sure there are no extra spaces if you cut and paste the path.
    • For Solaris OS:
      [mysqld]
      basedir = /opt/mysql/mysql
      datadir = /var/mysql
      default-storage-engine = InnoDB
      character-set-server = utf8
      
    • For Red Hat Linux:
      [mysqld]
      basedir = /usr
      datadir = /var/mysql
      default-storage-engine = InnoDB
      character-set-server = utf8
      
  3. Install startup script.
    • For Solaris OS:
      # cp /opt/mysql/mysql/support-files/mysql.server /etc/init.d/mysql
      
    • For Red Hat Linux:
      # cp /usr/share/mysql/mysql.server /etc/init.d/mysql
      
  4. Start MySQL Server.
    # /etc/init.d/mysql start
    Starting MySQL
    . SUCCESS!
    
  5. Change the MySQL root password.
    • On Solaris OS:
      # /opt/mysql/mysql/bin/mysqladmin -u root password '<password>'
      
    • On Red Hat Linux:
      /usr/bin/mysqladmin  -u root password '<password>'
      

      Replace 'password' with the appropriate password to use for the root user.

  6. Run the secure MySQL installation (disables remote root access, removes anonymous users, removes test databases, and so on).
    • On Solaris OS:
      # /opt/mysql/mysql/bin/mysql_secure_installation
      
    • On Red Hat Linux:
      /usr/bin/mysql_secure_installation
      
  7. Create the MySQL user and caldav database based on the sample session that follows.
    The following examples use 'caldav' as the MySQL user name and 'caldav' as the database name. You can use different names.
    Replace 'localhost' with the calendar server host name if the MySQL server is on a remote host (or use '%' for any host). Also replace 'password' with the appropriate password to use for the caldav user.
    See MySQL CREATE USER syntax.
    # /opt/mysql/mysql/bin/mysql -u root -p
    Enter password:
    mysql> CREATE DATABASE caldav CHARACTER SET = UTF8;
    mysql> CREATE USER 'caldav'@'localhost' IDENTIFIED BY 'caldav';
    mysql> SET PASSWORD FOR 'caldav'@'localhost' = PASSWORD('caldav');
    mysql> GRANT ALL ON caldav.* TO 'caldav'@'localhost';
    mysql> exit
    
  8. Configure MySQL to start automatically upon system reboot.
    1. Option 1:
      # ln /etc/init.d/mysql /etc/rc3.d/S99mysql
      

      If you need to add the stop scripts, use the following command:

      # ln /etc/init.d/mysql /etc/rc0.d/K48mysql
      
    2. Option 2:
      Configure MySQL to run with Solaris Management Facility (SMF).
      See the following links for information on how to configure MySQL to run with Solaris Management Facility (SMF):
  9. Continue with the next section.

Configuring Calendar Server 7 Update 1

See Oracle Communications Calendar Server for CALDAV Clients Initial Configuration.

Configuring Calendar Server With Multiple Hosts

See Configuring Multiple Calendar Server Back-end Hosts.

Verifying the Calendar Server Configuration

See Configuring CalDAV Clients for Calendar Server 7.

Configuring the Calendar Server Document Store

See Configuring the Oracle Communications Calendar Server for CALDAV Clients Document Store.

Running Calendar Server 7 Update 1 Post-Installation Tasks

After installing and configuring configuring Calendar Server 7 Update 1, you might need to perform post-installation tasks, such as the following:

  • Configuring Calendar Server for a Secure Deployment
  • Changing User uuid
  • Enabling the Apple iCal Autocomplete Feature

See Oracle Communications Calendar Server for CALDAV Clients Post Configuration for more information.

(Optional) Enabling Telemetry Logging in Calendar Server 7 Update 1

To log all protocol interactions, you can force all telemetry logs by setting the service.dav.telemetry.forcetelemetry parameter to true. Do not use this setting unless required as it generates lots of data.

To enable telemetry logging at a reduced level, set the service.dav.telemetry.filter parameter. This parameter takes a comma separated list of request URIs that should be logged. For example:

  • /wcap/ logs all WCAP access.
  • /dav/home/caluser1/ logs all Calendar Server access to caluser1's account.

Troubleshooting

See Calendar Server 7 Troubleshooting.

For More Information
See Calendar Server 7 Configuration Parameters for configuration parameters and values. See Administering Calendar Server 7 Logging for how to enable logging. See davadmin config for how to set configuration parameters by using the davadmin command.

Creating a Calendar Server 6 and Calendar Server 7 Coexistent Deployment

This information describes how to set up Calendar Server 7 (CalDAV Server) in an existing Calendar Server 6 deployment, where calendar users exist in both the Calendar Server 7 and Calendar Server 6 environments. In such a deployment, you enable both free-busy lookup and iCalendar Transport-Independent Interoperability Protocol (iTIP) invitation between the two Calendar Server deployments. That is, users should have the capability to check free-busy information of users on any server, and the capability to invite any user. Invitations to users on a different server would be delivered by using iTIP.

Topics:

To Configure the Calendar Server 7 Environment

Perform the following steps on the Calendar Server 7 host.

  1. Change to the cal-svr-base/config directory and either edit or create the ischeduledomainmap.properties file.
  2. Add a line that contains your domain name and the Calendar Server 6 URL to connect to for Calendar Server 6 user inquiry. If the Calendar Server 6 host is set up for multiple front ends and back ends, you can use any front-end server information.
    For example:
    example.com=http://cs6server.example.com:8080/ischedule/
    
  3. Use the davadmin config command to define the davcore.scheduling.localuserattr parameter.
    This parameter indicates the presence of which attribute determines if a user is local to Calendar Server 7. The recommended value is davStore.
    For example:
    davadmin config -W pw_file -o davcore.scheduling.localuserattr -v "davStore"
    

    The pw_file is a file containing the MySQL password for db commands, and the GlassFish administrator password for all other commands.

  4. Use the davadmin config command also to add the same value to the attributes to search list, by adding it to the value for the davcore.uriinfo.subjectattributes parameter.
  5. On the Directory Server, use an LDAP client to verify that the LDAP attribute defined in Step 3 is present for all users who are on the Calendar Server 7 server. Also verify that the attribute is not present for users on the Calendar Server 6 host.
    If using davStore and it is a simple single back-end deployment, populate it with the value defaultbackend.

To Configure the Calendar Server 6 Environment

Perform the following steps on the Calendar Server 6 host.

  1. Patch the server to the following:
    • 121657-37 - Solaris SPARC
    • 121658-37 - Solaris x86
    • 121659-37 - Red Hat Linux
  2. Edit the ics.conf file as follows:
    For Solaris OS, edit /etc/cal-svr-baseSUNWics5/config/ics.conf.
    For Red Hat Linux, edit /etc/cal-svr-base/calendar/config/ics.conf.
    • Set service.http.caldavcompatible = "yes".
    • Set the option for free-busy redirection to point to the Calendar Server 7 server's free-busy URL. If the Calendar Server 7 servers have a multiple front-end and back-end setup, use any front-end's information.
      For example:
      service.wcap.freebusy.redirecturl = "http://cs7server.example.com:8080/davserver/wcap/get_freebusy.wcap"
      
    • Disable autoprovisioning by setting the value of local.autoprovision, user.invite.autoprovision, group.invite.autoprovision, and resource.invite.autoprovision to "no".
      For example, the changes resemble the following:
      service.http.caldavcompatible = "yes"
      service.wcap.freebusy.redirecturl = "http://cs7server.example.com:8080/davserver/wcap/get_freebusy.wcap"
      local.autoprovision ="no"
      user.invite.autoprovision = "no"
      group.invite.autoprovision = "no"
      resource.invite.autoprovision = "no"
      
  3. If you migrated Calendar Server 6 calendars, back up then delete the migrated calendars on the Calendar Server 6 host.
    For example, to delete the calendar, perform the following:
    ./cscal delete -o <uid>
    
  4. Restart the Calendar Server 6 server, for example:
    cd /opt/sun/comms/calendar/SUNWics5/cal/sbin
    ./stop-cal
    ./start-cal
    

About This Configuration

This section contains the following topics:

About the Calendar Server 7 Configuration

When a scheduling invitation or free-busy request comes to a Calendar server 7 host, the server tries to determine if each of the invitees are local, by performing a directory lookup. If the server option davcore.scheduling.localuserattris set, the server additionally checks if the attribute specified by that option is set for each of the invitees found in the Directory. If the attribute is set, the user is considered local to the Calendar Server 7 host. If the attribute is not set, the user is assumed to be on the Calendar Server 6 host.

If a user is on the Calendar Server 6 host, for scheduling free-busy lookup, the server uses the Calendar Server 6 host information in ischeduledomainmap.properties and contacts the Calendar Server 6 host to make an iSchedule Freebusy request.

Sample request:

>> Request <<

   POST /ischedule/ HTTP/1.1
   Host: cs6server.example.com
   Content-Type: text/calendar
   Content-Length: xxxx

   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Sun Microsystems/Sun Calendar Server 7.0-0.13//EN
   METHOD:REQUEST
   BEGIN:VFREEBUSY
   DTSTAMP:20040901T200200Z
   ORGANIZER:mailto:cs7user@example.com
   DTSTART:20040902T000000Z
   DTEND:20040903T000000Z
   UID:34222-232@example.com
   ATTENDEE;CN=Cal7 User:mailto:cs7user@example.sun.com
   END:VFREEBUSY
   END:VCALENDAR

The response is incorporated into the scheduling free-busy response made by the Calendar Server 7 host. If a user is on a Calendar Server 6 host, for scheduling an invitation, an iMIP invitation is sent by the Calendar Server 7 host.

About the Calendar Server 6 Configuration

On a Calendar Server 6 host, if service.http.caldavcompatible is set to "yes", on a scheduling free-busy request, if the invitee calendar is not found on the local database, a free-busy redirect URL is returned as configured through the service.wcap.freebusy.redirecturl parameter.

On a scheduling invitation request, if the invitee calendar is not found on the local database, an iMIP invitation is sent.

Oracle Communications Calendar Server for CALDAV Clients Administration Guide

This guide explains how to administer Calendar Server for CALDAV Clients and its accompanying software components.

Topics:

Administering Calendar Server 7

This section contains the following topics:

Stopping and Starting Calendar Server

To stop and start the Calendar Server process, you stop and start the GlassFish Server container in which Calendar Server is deployed. The following examples assume a default GlassFish Server installation with Calendar Server deployed in domain1.

  • To stop Calendar Server:
  • To start Calendar Server:

Starting and Stopping the Document Store

The document store was introduced in Calendar Server 7 Update 1.

  • To start the document store server:
  • To stop the document store server:

Administering GlassFish Enterprise Server 2.1

Calendar Server 7 depends on GlassFish Enterprise Server 2.1 as a web container. See the GlassFish Enterprise Server 2.1 documentation for details on administering Glassfish Enterprise Server. The following Glassfish Enterprise Server documentation links are also provided to help you get started:

Provisioning Calendar Server Users

Calendar Server uses Directory Server to store and retrieve user and resource information and to perform authentication. Before you can store Calendar Server information in Directory Server, you need to prepare Directory Server by running the comm_dssetup script, as described in the installation documentation.

You can provision Calendar users and resources in Directory Server either by using LDAP tools or by using Delegated Administrator. Calendar Server supports the same LDAP schema used by Calendar Server. Some additional object classes and attributes were added for Calendar Server, as described in Messaging Server and Calendar Server LDAP Attributes. Currently, only the davStore attribute is used. A Calendar Server deployment must have the following attributes defined:

  • mail
  • nsUniqueId
To Provision Calendar Users Automatically Upon Login

Since auto-creation of calendar accounts happens when users log in to Calendar Server, you create users by provisioning the users in LDAP then providing instructions for logging in. The following parameters configure the defaults for auto-creation:

davcore.autocreate.calcomponents
davcore.autocreate.defaultcalendar
davcore.autocreate.displaynameattr
davcore.autocreate.emailnotificationaddressattr
davcore.autocreate.enableemailnotification

For more information, see Calendar Server 7 Configuration Parameters.

To Provision Calendar Users By Using Delegated Administrator

See Provisioning for Calendar Server Users for information.

To Remove Calendar Users
  1. Set the icsStatus attribute for users being deleted to "removed" or "inactive."
  2. Run the davadmin account command to delete the user.
  3. Run the Delegated Administrator commadmin domain purge command to remove the user's LDAP entry.

When you remove a calendar user by running the davadmin account delete command, the back-end resources for the user are deleted. However, the LDAP entry for the user remains with the icsStatus attribute set to active. Thus, you need to set the icsStatus attribute to "removed" so that running the Delegated Administrator commadmin domain purge command removes the user's LDAP entry.

Administering Resource Calendars

The following features documented in this section were introduced in Calendar Server 7 Update 1.

Entities that can be scheduled but that do not control their own attendance status are called resources. You provision resources in LDAP by using Delegated Administrator. In Calendar Server, calendars for resources are auto-created upon invitation. You can also create them either by using the davadmin calendar command or by using CalDAV or WCAP calendar creation commands.

You can manage resource accounts and calendars just like user accounts and calendars. In addition, you can set the resource account owner by using either the davadmin account or set_accountprops.wcap commands.

To control the maximum booking window for a resource, set the davcore.scheduling.maxbookingwindow parameter. (The default is one year). This parameter affects all resources. You cannot currently set a booking window on individual resources.

To Provision Resource Calendars (Command Line)

Example:

To Provision Resource Calendars (GUI)
  1. Log in to Delegated Administrator.
  2. Select the organization in which to create the resource calendar.
  3. Click the Calendar Resources tab.
  4. Click New.
    The New Calendar Resource page is displayed.
  5. Type your resource information and save.
    In a multiple back-end deployment, make sure that you type the correct Calendar Store.

Configuring Scheduling Options

Calendar Server processes incoming invitations and delivers them to recipients, including delivery to default calendars for internal recipients, without any extra client interaction. If you need Calendar Server to perform additional checks and processing during scheduling, configure the attendantflag of the recipient's inbox by using either the davadmin account command or the set_accountprops.wcap command.

The attendantflag properties are:

  • Auto Decline of Recurring Meetings. You can disallow recurring meetings for some resource calendars. Any invitation for a recurring meeting received on such a calendar is declined, regardless of its availability.
  • Auto Decline on Scheduling Conflict. Calendar Server performs an upfront freebusy check on internal recipients and rejects the invitation if the scheduling results in a conflict and the recipient is set up to auto decline on conflict.
  • Auto Accept of invitation. Calendar Server can automatically accept incoming invitations if the recipient is set up for it.

Default settings of the flag are determined by the following configuration options:

  • davcore.autocreate.calattendantuserflags: default value for users (0 = no auto accept, no auto decline booking conflict, no recurrence check on invitations)
  • davcore.autocreate.calattendantresourceflags: default value for resource calendars (3 = auto accept invitation and auto decline on booking conflict)

Administering Calendar Server Access

Calendar Server uses Access Control Lists (ACLs) to determine access control for calendars and scheduling.

The following features documented in this section were introduced in Calendar Server 7 Update 1.

This section contains the following topics:

Overview of ACLs

An Access Control List (ACL) consists of one or more Access Control Entries (ACEs), which are strings that grant a particular level of access. ACEs collectively apply to the same calendar or component, or in the case of scheduling, to an account. Each ACE in an ACL must be separated by a semicolon. Multiple ACE strings can apply to a single calendar or a single account.

ACLs are denied unless explicitly granted. Some control access is "built-in" to Calendar Server. For example, calendar owners have full access to their calendars. Granting of a particular ACE means implicitly granting anything considered a "lower" ACE.

ACEs function in the following way:

  • More specific access rights override other access rights.
  • Access rights granted to a specific user are more specific than rights granted to a user as member of a group.
  • Rights granted as part of the "all" users setting are considered least specific.
  • If a user is a member of multiple groups, the highest level of access granted individually by any one of the groups is the access level of the user.
  • Calendar Server access control does not take into consideration nesting levels within each group.

You set Calendar Server access controls by using either the davadmin command or WCAP commands. Calendar Server uses the acl parameter to facilitate storing of the ACE strings. The acl parameter is a semicolon-separated list of ACE strings.

Calendar Access Controls

You can set the following four levels of calendar access controls on each calendar collection:

  • none (level n)
  • read (level r)
  • read+write+delete (level w)
  • read+write+delete+manage (level a)

An ACE is granted to all (@), user, or group. Definition of "all" is made server-wide through the davcore.acl.calendaranonymousall configuration option. If set to false, "all" does not include unauthenticated users.
Users and groups are represented by their mail address.

In the following example:

all users get read access, userA@example.com gets read, write, delete, and manage access, and all members of groupA@example.com get read, write, and delete access.

The davcore.acl.defaultcalendaracl configuration option defines a default ACL for all calendar collections. You can change this value by using the davadmin config command. Calendar Server 7 uses default ACLs for all calendars for which ACLs are not explicitly set.

Scheduling Access Controls

You can set scheduling permissions for an account, which are used for checking a user's freebusy information, inviting a user, and inviting on behalf of a user. The four levels of scheduling access levels are as follows:

  • none (level n)
  • freebusy (level f)
  • freebusy+schedule_invite (level s)
  • freebusy+schedule_invite+manage (level m)

An ACE is granted to all (@), user, or group. Definition of "all" is made server-wide through the davcore.acl.calendaranonymousall configuration option. If set to false, "all" does not include unauthenticated users.

You define a default ACL for all calendar inbox collections by using the davcore.acl.defaultschedulingacl configuration parameter.

To invite someone else, you need to have a scheduling right of at least s for that user, and calendar access right of at least w to that user's calendar.

Retrieving Access Control Information

You use the davadmin command or WCAP commands get_calprops.wcap, search_calprops.wcap, and get_accountprops.wcap to retrieve the access control rights of a logged-in user to a particular calendar, or user. The ACL itself is viewable by owners, administrators, and those users with manage rights only. All other users can get their access rights through the X-S1CS-MYRIGHTS property that is returned by the get and search commands. The value of this property is either calendar-level rights (n, r, w, or a); or scheduling rights (n, f, s or m), depending on the WCAP call.

Configuration Parameters for Access Control

The following table describes the configuration parameters that Calendar Server uses for access control.

Access Control Configuration Parameters
Parameter Description  
davcore.acl.defaultcalendaracl Specifies the default access control settings used when creating a new calendar. The default is: ""
davcore.acl.defaultschedulingacl Specifies the default access control used for scheduling that is set on a scheduling inbox creation (from the server configuration option). The default is: @:s
davcore.acl.calendaranonymous Determines if all (@) includes anonymous principals for calendar access. The default is: true
davcore.acl.schedulinganonymous Determines if all (@) includes anonymous principals for scheduling access. The default is: true

See Calendar Server 7 Configuration Parameters for more information on these access control configuration parameters.

Command-Line Utilities for Access Control

Use the davadmin calendar to get or set calendar ACLs for calendars and the davadmin account command to get or set scheduling ACLs for access control.

WCAP Commands for Access Control

Use get_accountprops.wcap and set_accountprops.wcap to access and set an account's scheduling rights. Use get_calprops.wcap and set_calprops.wcap to access and set the access rights to a calendar. Use search_calprops.wcap to view a user's "MYRIGHTS" (privilege level of access to other users' calendars).

Inviting LDAP Groups

The following features documented in this section were introduced in Calendar Server 7 Update 1.

You can invite entire groups in the LDAP directory as one attendee. The group is maintained as one attendee in the organizer's calendar, but the Scheduling Service expands the group and adds each member as a recipient of the invitation. When storing the invitation in each recipients' calendar, that recipient is added as an ATTENDEE, which is referenced as a member of the group. When a recipient replies, that recipient is added as an individual ATTENDEE, also referenced as member of the initial group in the organizer's calendar. This feature can be used to invite both static and dynamic groups in LDAP.

The following configuration options control this feature:

  • davcore.serverlimits.maxgroupexpansion - Limits the the level of nested group expansion. By default, it is 3 (three levels deep)
  • davcore.serverlimits.maxattendeesperinstance - For scheduling, limits the number of members as a result of group expansion. The default is 1000.
  • davcore.ldapattr.dngroupmember=uniquemember, davcore.ldapattr.urlgroupmember=memberurl, and
    davcore.ldapattr.mailgroupmember=mgrprfc822mailmember - Specify the various type of LDAP group memberships. davcore.ldapattr.dngroupmember is used for group members specified as a DN, which denotes static membership. davcore.ldapattr.urlgroupmember is used for group members specified through an LDAP filter, which denotes dynamic membership. davcore.ldapattr.mailgroupmember is used for group members specified through an email address.
    Note
    If you have your own schema elements that follow the semantics of the preceding default settings, you could add those attributes to the corresponding list by using a space delimited fashion.

Calendar Server 7 Administration Utilities

See Calendar Server Command-Line Utilities.

Administering Calendar Server 7 Logging

Calendar Server 7 maintains four types of log files:

  • commands - Stores information about requests that are sent to the server and information related to each operation performed to satisfy those requests. The commands log contains servlet and core operation classes entries that are designed to help you monitor requests to the server and help diagnose problems.
  • errors - Stores error and debug-level information that is supplied by the server for use in diagnosing problems.
  • scheduling - Stores information on scheduling actions, showing when invitations are enqueued and dequeued.
  • telemetry - Stores entire Calendar Server servlet request and response transcripts.

Each of these files has a suffix of .#, which is a rollover number indicating that the log file was filled to its maximum capacity and was rolled over to another file. The lowest numbered log file is the newest.

Each log file has its own configuration attribute that controls the log file location, maximum size, and log level.

The Calendar Server log files are kept separate from the GlassFish Enterprise Server log files. The GlassFish log files are maintained in the ${APPSERVER_DOMAIN}/logs directory, where ${APPSERVER_DOMAIN} is the path to the respective container's base directory, for example, /opt/SUNWappserver/domains/domain1/. Even though the container's log file is the root log file, information that is logged to the Calendar Server's log files is not logged to the container's log file. Calendar Server sets its logToParent flag to false by default, preventing logging of information to the container log file. Deployments can change that by setting the logToParent configuration option to true.

To Configure Calendar 7 Log Files
Calendar Server Log File Parameters
Parameter Description
log.dav.name.logdir Specifies the log file directory path
log.dav.name.loglevel Specifies the log level:
  • SEVERE: Logs catastrophic errors.
  • WARNING: Logs major errors or exceptions with the system.
  • INFO: Logs general informational messages. This is the default level. Any information logged at this level is placed in the log file.
  • FINE: Logs general debugging and tracing information to show the higher level flow through the code or more detailed information about a problem.
  • FINER: Logs finer grain details than FINE.
  • FINEST: Logs the finest grain details of code flow or problem information. Turning on logging at this level could cause massive amounts of data to be put into the log file, making it hard to parse.
log.dav.name.logtoparent Sets a flag to enable logging to the GlassFish Enterprise Server log file, in addition to the Calendar Server logs
log.dav.name.maxlogfiles Specifies the maximum number of log files
log.dav.name.maxlogfilesize Specifies the log file's maximum size

Where name can be commands, errors, scheduling, or telemetry, depending on which log file type you want to configure. Note that the name to use to get the Calendar logs is errors.

To View the Document Store Logs

The document store logs are located in the datadir/logs directory. Change to this directory to view the log files.

To Set the Logging Level for Calendar Server 7 Logs in GlassFish Enterprise Server

You can set the logging level for Calendar Server logs in the GlassFish Enterprise Server logs, using the Admin Console.

  1. In a browser, access the Admin Console, for example:
  2. Type the administration user name and password, specified when you installed the product, and click Log In.
  3. In the Admin Console, click the Logging tab.
  4. Click the Logging Settings tab.
  5. At the bottom of the page add a logger and set its level by clicking the Add Properties button.
    For the Name, the logger should have the root logger name, com.sun.comms, or a package name, such as com.sun.comms.davserver.core. For the Value, type any of the following values (listed from highest to lowest):
    • SEVERE
    • WARNING
    • INFO
    • CONFIG
    • FINE
    • FINER
    • FINEST
    • OFF
      Messages at the selected level or higher appear in the log. The default level is INFO, so the log will contain messages of INFO, WARNING, or SEVERE levels.
  6. When done, click Save.

The following table explains the scheduling codes in the scheduling log file.

Codes Used in Scheduling Log Files
Code Description
E Enqueuing of an inbound scheduling message
J Rejection of attempted enqueue
DL Successful dequeue for a local recipient
DE Successful dequeue for an external (iSchedule) recipient
DM Successful dequeue for an iMIP recipient
QE Temporary failure to dequeue for an external (iSchedule) recipient
QM Temporary failure to dequeue for an iMIP recipient.
R Permanent failure to dequeue

Customizing Notification and Reminders for Java Message Queue Consumers

The following table shows the SMTP configuration parameters.

Notification Configuration Parameters
Name Description
notification.dav.enableemailnotif Enable server-wide email notification.
notification.dav.enablejmsnotif Enable server-wide JMS notification.

You can enable or disable these parameters by using Jconsole or the davadmin utility. You do not need to restart the server for a change to these parameters to take effect.

When customizing formatting files, know that Calendar Server inserts the entire iCal raw data as one field (%{ical}) to replace, and the entire template is a well-formatted MIME message. Java can parse it as a entire content, and thus, Calendar Server does not need to parse the file line-by-line.

Configuring a Secure LDAP Connection

Like other applications, Calendar Server and GlassFish Server use the LDAP protocol to read from and write to Directory Server. The default is to communicate LDAP data by "unsecured" transmission. You can configure your Calendar Server deployment to use Secure Sockets Layer (SSL) for secured transmission of data. You do so by installing a Certificate Authority (CA) certificate on the GlassFish Server then configuring Calendar Server to use LDAP for SSL.

To Configure Calendar Server for Secure LDAP
  1. Configure GlassFish Enterprise Server to use a CA signed certificate for SSL.
  2. When performing this task, note the following.
    • Not all GlassFish domains use the same security key store.
      GlassFish may end up using either the NSS security library and associated key store for certificates, or it may use the Java Key Store instead. The keystore that GlassFish uses is initially determined by the GlassFish "Profile:" Enterprise, Developer, or Cluster. The Enterprise profile uses NSS, while the Developer and Cluster use Java Key Store.

      You can specify the profile when you create a new domain. However, the initial domain defaults to a profile depending on the version of GlassFish installed along with possible configuration specifications.

      The To Configure GlassFish Enterprise Server to Use a CA Signed Certificate for SSL procedure assumes the Enterprise version of GlassFish, which uses the NSS security library and includes the certutil utility.

      If you want to use a profile with Java Key Store, review the Java Key Store documentation on the tool "keytool." Use a newer version of keytool from Java 6.

      The key store is configured during creation of the domain. Although both sets of key store files may be present in the config directory, only the chosen key store is configured with common CA certificates and the GlassFish password. Thus, for example, if Java Key Store is configured, and you try to generate a certificate request with certutil, you may get an I/O error because the NSS database is not initialized with the GlassFish password.

      Though it should not be necessary, if you need to change the key store password, use the asadmin command, not the certutil utility.
    • Certificate request generation depends on generating the request with the key store database in the domain's config directory.
    • GlassFish installs with a default self-signed certficate named s1as. This should already be configured for SSL, and so SSL can be tested before adding a valid certificate. However, many clients warn that the SSL certificate cannot be trusted, and other clients may simply not work.

      Some older versions of FireFox report a "connection was interrupted" error when the certificate is self-signed or otherwise not valid.
  3. Configure Calendar Server to use LDAP for SSL.
    • In step #2, while running davadmin config to process the davadmin commands:
      Processing the configuration file can take time and can result in multiple messages to restart GlassFish. Wait until all the commands are finished processing before restarting GlassFish. Otherwise, some configuration parameters might not be processed, leaving SSL partially configured.

Backing up and Restoring Calendar Server Data

See Best Practices for Backing Up and Restoring Databases in Calendar Server Deployments.

Troubleshooting Calendar Server

See Calendar Server 7 Troubleshooting.

Administering the MySQL Database

The following links provide information about administering MySQL. For more information, consult the MySQL documentation directly.

Configuring CalDAV Clients for Calendar Server 7

Topics:

Prerequisites

  1. Users need to be provisioned in Directory Server. For more information, see Automatically Provisiong Calendar Server 7 Users and Provisioning for Calendar Server Users.
  2. Obtain the following information on your Calendar Server 7 deployment:
    • GlassFish Enterprise Server host name and port where Calendar Server 7 is installed
    • base-uri
    • user identifier (email address or uid@domain)

Configuring CalDAV Clients

This section contains the following tasks:

To Configure Apple iCal for Calendar Server
  1. Launch iCal.
  2. Choose Preferences menu from the Main menu.
  3. To add an account, click the accounts tab in Preferences, then click the '+' sign.
  4. Type a name for your calendar in the Description field.
  5. Type your user name and password.
  6. Click the server options and type the principal URI, for example:
    http://example.com:3080/dav/principals/jsmith@example.com/
    In this example, the default URI of / was used during initial configuration.
    The general format is:
    http://glassfish-host:glassfish-port/base-uri/principles/user-identifier/

where:
base-uri is the deployment URL you enter during initial configuration
user-identifer is an email address, uid@domain, or just uid in the default domain

To Configure Lightning 0.9 for Calendar Server

These instructions assume that you have already installed at least Mozilla Thunderbird 2.0.0.x on your client machine.

  1. Download Lightning 0.9 to your client machine.
    See http://www.mozilla.org/projects/calendar/releases/lightning0.9.html.
  2. Download, but do not execute, the appropriate binary for your client platform.
    If the downloaded file is a zip file, unzip it.
  3. Create a Thunderbird profile as follows:
    1. In Mozilla Thunderbird, choose Add Ons or Extensions from the Tools menu, depending on the version of Thunderbird.
    2. Click the Install button.
      A file chooser is displayed.
    3. Navigate to the previously downloaded (and perhaps unzipped).XPI file, select it, and click OK.
    4. In the Software Installation dialog box, click Install Now.
    5. Click Restart Thunderbird.
    6. Click the Calendar icon in the lower left corner of the Thunderbird UI.
    7. Choose File-->New-->Calendar.
      If this selection is grayed out, you might need first to open the default calendar in Thunderbird.
    8. Choose On the Network.
    9. Choose CalDAV.
    10. Type the URL of the calendar, for example:
      http://example.com:3080/dav/home/jsmith@example.com/calendar/
      In this example, the default URI of / was used during initial configuration.
      The general format is:
      http://glassfish-host:glassfish-port/base-uri/dav/home/email-address/calendar/
    11. Type your name, choose a color scheme, choose to set alarms or not, and select your email address.
    12. Type your user name and password for the CalDAV server.
      A confirmation dialog box informs you that your calendar has been created.
    13. Click Finish.
      The new calendar appears in the listing of calendars on the left side of the Thunderbird UI.
  4. Lightning 0.9 has CalDAV scheduling capability but it is turned off by default. Turn on the following configuration preferences for CalDAV scheduling to work by using the Config Editor.
    • calendar.itip.notify
    • calendar.caldav.sched.enabled
      Windows: Tools-->Options-->Advanced-->Config Editor
      UNIX: Edit-->Preferences-->Advanced-->General
To Configure Lightning 1.0 beta for Calendar Server

These instructions assume that you have already installed at least Mozilla Thunderbird 2.0.0.x on your client machine.

  1. Download Lightning 1.0 beta 1 to your client machine.
    See http://www.mozilla.org/projects/calendar/lightning/download.html.
  2. Download, but do not execute, the appropriate binary for your client platform.
    If the downloaded file is a zip file, unzip it.
  3. Create a Thunderbird profile as follows:
    1. In Mozilla Thunderbird, choose Add Ons or Extensions from the Tools menu, depending on the version of Thunderbird.
    2. Click the Install button.
      A file chooser is displayed.
    3. Navigate to the previously downloaded (and perhaps unzipped).XPI file, select it, and click OK.
    4. In the Software Installation dialog box, click Install Now.
    5. Click Restart Thunderbird.
    6. Click the Calendar icon in the lower left corner of the Thunderbird UI.
    7. Choose File-->New-->Calendar.
      If this selection is grayed out, you might need first to open the default calendar in Thunderbird.
    8. Choose On the Network.
    9. Choose CalDAV.
    10. Type the URL of the calendar, for example:
      http://example.com:3080/dav/home/jsmith@example.com/calendar/
      In this example, the default URI of / was used during initial configuration.
      The general format is:
      http://glassfish-host:glassfish-port/base-uri/dav/home/email-address/calendar/
    11. Type your name, choose a color scheme, choose to set alarms or not, and select your email address.
    12. Type your user name and password for the CalDAV server.
      A confirmation dialog box informs you that your calendar has been created.
    13. Click Finish.
      The new calendar appears in the listing of calendars on the left side of the Thunderbird UI.
To Troubleshoot Lightning

If Thunderbird has trouble remembering a previous account (see the yellow alert icon next to an account), try deleting the calendar, restarting Thunderbird, then recreating the account.

To Configure a Demo CalDAV Account on iPhone OS 3.0

The iPhone 3.0 default configuration panel is very simple (server name, user name, password), but it makes the following assumptions that might be valid for a production system but not for a demo server:

  • Use of standard ports (443 or 80)
  • SSL is the default
  • Account URL follows a fixed pattern: http(s)://server name/principals/users/username/

Demo servers usually run on non-standard port numbers and they do not always own the full namespace, leading to account URLs (actually principal URL) that look more like the following:

http://caldav.example.com:3080/dav/principals/username/

Typing this kind of URL can be very tedious and error prone, especially given that the advanced configuration panel offers just a tiny text box.

The following procedure simplifies the configuration process, assuming that you have a mail account configured already.

  1. From your usual desktop client, email the principal URL to yourself.
    Check that the URL is valid (by using a regular browser) before sending it.
    The principal URL varies across servers. It is the same that you might have configured if you are using the Apple iCal client (iCal --> Preferences --> Accounts --> your CalDAV account --> Server Settings --> Account URL).
  2. Copy the URL from the iPhone Mail App.
    1. From the iPhone Mail App, open the email.
    2. Press and hold on the URL in the message.
      You should be asked whether you want to open or copy the link.
    3. Select copy.
  3. Navigate to the CalDAV account creation panel.
    Settings --> Mail, Contacts, Calendars --> Add Account... --> Other --> Add CalDAV Account
  4. Type the server information.
    1. Tap on the Server field.
      A Paste button should appear on top of the text field.
    2. Press Paste.
      The full URL is shown. The client accepts a full URL in the server name field.
  5. Type the user name and password.
    1. Go to the User Name field. The full principal URL is replaced by the server name only, which is to be expected.
    2. Type your password and tap Next.
      The client indicates "Verifying CalDAV account", then "Account verified".
  6. You can now use the Calendar application.

Support for .well-known URI

Calendar Server 7 Update 1 supports the .well-known URI concept as defined in RFC5785 for CalDAV clients to access the Principal URI without having to specify the entire URI. That is, access to / (root) or /.well-known/caldav/ is redirected to the /dav/principals/ URI.

Exporting and Importing Calendars

This section contains the following tasks:

To Export a Calendar
  1. Open any Calendar view.
  2. Choose File-->Export Calendar.
  3. Select the calendar.
  4. When prompted to save the file, use the iCalendar format (the default is html).
To Import a Calendar
  1. Open any Calendar view.
  2. Choose File-->Import Calendar.
  3. Select the exported file.

CalDAV Client Issues

See Troubleshooting CalDAV Clients.

Calendar Server 7 Command-Line Utilities

Topics:

Overview of the davadmin Command-Line Utilities

Calendar Server provides a number of command-line utilities for administering the server. These utilities run under the umbrella command, davadmin, which is a simple shell script. The davadmin utility is installed in the cal-svr-base/sbin directory with user or group bin/bin permissions.

Note
The davadmin command-line utilities administer aspects of the server and do not affect any LDAP entries.

The syntax of the davadmin command is the following:

The operation can be one of the following five arguments.

davadmin Class of Operations
Argument Description
version Prints version of the server.
account Performs operations that affect the entire user or resource account.
config Performs configuration operations, such as print a particular option, set a particular option, or list all options. Some configuration operations require that you restart Calendar Server. See Calendar Server 7 Administration Guide#Stopping and Starting Calendar Server for more information.
calendar Performs calendar collection operations, such as create a collection, modify a collection, or delete a collection.
calcomponent

The calcomponent argument replaces the calresource argument starting in Calendar Server 7 Update 1.


Performs resource operations, such as listing resources that meet a specified criteria, importing resources, or deleting resources.
calresource

This argument is valid for Calendar Server 7.


Performs resource operations, such as listing resources that meet a specified criteria, importing resources, or deleting resources.
db Performs database related operations, like back up and restore the database.
migration

This argument is available starting in Calendar Server 7 Update 1.

Performs migration of Calendar Server 6 data to Calendar Server Server 7 Update 1.

Each operation supports a list of additional parameters to pass information to the server. Some common options used by all operations (except davadmin db operations) are described in the following table.

Note
Any option that contains special characters needs to be enclosed in quotes ("") so that they are passed "as is" to the davadmin command.
Common Options
Short Option Long Option Description Required or Optional
-u adminuserid --userid MySQL user ID for db commands, GlassFish Administrator user ID for all other commands. Required unless you provide it through a CLI file by using the -F option, or you are displaying usage by using the -h option.
-W passfile --passwordfile File containing MySQL password for db commands, GlassFish Administrator password for all other commands. Required unless you provide the password by using the -F option or by displaying usage by using the -h option. If you don't provide this information, you are prompted for the password.
-F file --clifile File with bootstrap information that you use to specify command-line options so that they don't have to be entered at the command line. Each line in the bootstrap file is in the form property=value.
For possible properties see the Clifile Properties table.
Required unless all necessary information is provided on the command line or in the davadmin.properties file. See Options Precedence for more information on priority order of options, the clifile and the davadmin.properties file.
A path to the clifile file can also be specified by the DAVADMIN_CLIFILE environment variable.
-H host --hostname Server host name. Optional. Defaults to localhost.
-p port --port GlassFish administration port (JMX connector port) and MySQL port for db commands. The GlassFish administration port can be found in the domain's domain.xml file or in the Administration Console (Configuration->Admin Service->system). Optional. Defaults to 3306 for db commands and 8686 for other commands.
-s path --secure Path to the truststore file used for a secure connection (HTTPS). Optional. Required if GlassFish is running in secure mode. Not applicable for db commands.
-t password --securepasswordpath Path to the file that contains the password for the truststore used for secure connection. Optional. Required only if the GlassFish truststore requires it. Not applicable for db commands
-e --detail Verbose output. Mostly used if a command returns an error.
Optional.
-q --quiet Quiet mode for scripts. Optional.
-h --help Help for that particular operation. Optional.
-V --version Lists version of davadmin utility. Optional. Usable only by itself and not with other options.

Each operation can have its own specific options, as the following sections show.

Clifile Properties

The following table describes the possible properties in the bootstrap file (clifile):

Property
Description
userid GlassFish Administrator user ID.
password GlassFish Administrator password.
hostname Server host name.
port Glassfish administration port (JMX port).
secure Path to the truststore file used for a secure connection (HTTPS).
securepassword Password for the truststore used for secure connection. Only needed if the GlassFish truststore requires it.
dbuserid MySQL database user ID.
dbpassword MySQL database user password.
dbhostname Hostname where the database server resides.
dbport Port on dbhostname for access to the database.
database Specifies the name of the DAV store to be saved or updated.
docstore Specifies the document store (remote store specified as host:port or local store by fully qualified path to root of document store)
migrationadminuser Administrative user to authenticate to Calendar Server 6 host.
migrationadminpassword The Calendar Server 6 administrative password.
migrationserverport Server and port information to connect to the Calendar Server 6 host from which data needs to be migrated. The format is server:port.
Options Precedence

You can provide options to the davadmin command by:

  • Using the command line
  • Using the clifile
  • Including them in davadmin.properties file

Any user can create a clifile. Only root user can use davadmin.properties file. The davadmin.properties file is installed in the config directory of the installation (default location is /var/opt/sun/comms/davserver/config).

When you run the davadmin command, any option that you include on the command line takes precedence over any like option in the clifile or the davadmin.properties file. Use of the clifile or the davadmin.properties file is mutually exclusive. If you use the clifile, use it for any option that is not on the command line. If you run the davadmin command as root and do not supply a clifile, the davadmin.properties file is used for any option that is not on the command line.

The davadmin.properties file usually contains options for userid, hostname, port, secure, dbhost, dbport, and dbuserid.

account Operation

The davadmin account command must be followed by one of the following actions.

Actions for account Operation
Command Description
delete Deletes an account.
list Lists properties of an account.
modify Modifies an account.

The account operation is followed by these parameters.

Options for account Operation
Short Option Long Option Description
-a account --account Required. Principal account information provided as email address. You can also supply the account information with the DAVADMIN_ACCOUNT environment variable.
-y property --property Comma-separated list of all property=value options for the specified calendar.
Possible properties include:
acl - The scheduling privileges set on the account. For more information about ACLs, see Administering Calendar Server Access.
attendanceflag - Flag controlling behavior on invitation. Possible values are:
   0 - no autoaccept, no booking conflict check, no recurrence check on invitations.
   1 - autoaccept invitations
   2 - autodecline if invitation results in booking conflict.
   3 - autoaccept invitation and autodecline on booking conflict.
   4 - autodecline recurring meeting invitations.
   5 - autoaccept invitations and autodecline recurring meeting invitations
   6 - autodecline recurring invitations and invitations that cause a booking conflict.
   7 - autoaccept invitations, autodecline recurring invitations and invitations that cause a booking conflict.
notifemail - Enable or disable email notification (0 = disable, 1 = enable). The default is 1.
notifrecipients - Space-separated list of notification addresses.
owner - Email address of the primary owner of resource calendar accounts. This option cannot be used on user accounts.
-h --help Displays davadmin account usage help.

config Operation

At least one of the following options must be provided, unless you are displaying usage by using the -h option. See Calendar Server 7 Configuration Parameters for the complete list of configuration parameters.

Options for config Operation
Short Option Long Option Description
-o option --option Configuration option name. Gets the optional value if specified without -v. Sets the option value if specified with a -v.
-v value --value Configuration option value.
-l --list Lists all configuration options.
-f file --file Local file with list of configuration option=value entries for setting.
-h --help Description of config option if specified with -o. Otherwise, usage of davadmin config.

calendar Operation

The davadmin calendar command must be followed by one of the following actions.

Actions for calendar Operation
Command Description
create Creates a calendar collection. Autocreates the account, if it does not exist.
modify Modifies a calendar collection.
delete Deletes a calendar collection.
list Lists an account's calendars or details of a particular calendar (if the -n option is provided).

The calendar operation is followed by these parameters.

Options for calendar Operation
Short Option Long Option Description
-a account --account Required. Principal account information provided as email address. You can also supply the account information with the DAVADMIN_ACCOUNT environment variable.
-n collection --name Calendar collection name. If this option is provided, information about the calendar is displayed. If this option is not provided, all the account's calendar names are listed.
-y property --property Comma-separated list of all property=value options for the specified calendar.
Possible properties include:
displayname - The displayed name. Defaults to the name of the calendar.
calendar-description - Description string. No default.
supported-calendar-component-set - Space-separated list of supported components. The default is VEVENT VTODO VFREEBUSY.
notifemail - Notification to enable or disable (true/false). The default is true.
notifrecipient - Space-separated list of notification addresses.

The following properties are available starting in Calendar Server 7 Update 1.


wcaptzid - The timezone tzid set on the calendar, for example, America/Los_Angeles.
acl - The access control string set on the calendar.
-f file --file Local commands input file for batch operation.
Each line has colon-separated entries for account information, calendar name, and property list. For example:
user1@example.com:testcal:calendar-description=user1's test cal,notifemail=false
-h --help Displays davadmin calendar usage help.

calcomponent Operation

The calcomponent argument replaces the calresource argument starting in Calendar Server 7 Update 1.

The davadmin calcomponent command must be followed by one of the following actions.

Actions for calcomponent Operation
Command Description
list Displays a summary of all of the resources in a calendar or the specifics of one resource.
delete Deletes a resource or all of the resources in a calendar.
import Imports resource data into a calendar.
export Exports resource data from a calendar.

The calcomponent operation is followed by these parameters.

Options for calcomponent Operation
Short Option Long Option Description
-a account --account Required. Principal account information provided as email address. You can also supply the account information with the DAVADMIN_ACCOUNT environment variable.
-n name --name Calendar collection name. The default is the principal's default calendar.
-y property --property Comma-separated list of all property=value options for specified calendar.
Possible properties include:
type - The component type or types. Possible values are VEVENT and/or VTODO. If you use both VEVENT and VTODO, enclose them in double quotes and separate them with a space.
start - The start of a time range used in the search. The format of this value is yyyymmddThhmmssZ. This value is in Zulu time. (The T is a separator between the day and time.)
end - The end of a time range used in the search. The format of this value is yyyymmddThhmmssZ. This value is in Zulu time. (The T is a separator between the day and time.)
-h --help Displays davadmin calcomponent usage help.
-i --uri URI of resource to request entire content.
-r --force Forces a delete operation so that you are not prompted for confirmation. This option is generally needed for scripts.
-m --import-path Path to the file on the server machine, containing data to be imported.
-x --export-path Path to the file where the exported data is to be stored.

db Operation

The davadmin db command must be followed by one of the following actions.

Actions for db Operation
Command Description
backup Backs up a database.
restore Restores the contents of a database.
list List contents of a backup file.

The db operation can be followed by these parameters in addition to the common parameters:

Options for db Operation
Short Option Long Option Description Command
-d --database Specifies the name of the DAV store to be saved or updated. backup, restore, list
-k --bkfile Specifies the path of the file where the database information is to be saved. Required. backup, restore, list
-b --bkfactor Specifies blocking factor used during backup. The default is 20. backup, restore, list
-T --token Specifies the incremental backup token or start time in milliseconds. backup
-D --domain Domain name for per domain backup. backup
-a --account User account email value for per user backup. backup
-i --ipath Specifies the internal path for partial list or restore. restore, list
-c --contents List the resources and header. list
-A

This option is available starting in Calendar Server 7 Update 1.

--docstore Specifies the document store (remote store specified as host:port or local store by fully qualified path to root of document store) backup, restore

migration Operation

The following feature documented in this section is available starting in Calendar Server 7 Update 1.

For more information on migrating from Sun Java System Calendar Server 6 to Oracle Calendar Server 7, see Migrating From Sun Java System Calendar Server 6 to Oracle Communications Calendar Server for CALDAV Clients.

The migration option supports all davadmin common options. In addition, the migration option supports the following options:

Options for migration Operation
Short Option Long Option Description Required
-a --account Principal account information of the user to be migrated, provided as email address. Required unless batch mode is used and account information provided in files.
-X --migrationadminuser Administraive user to authenticate to Calendar Server 6 host. Required unless information is provided in clifile.
-x --migrationadminpasswordpath Path to file that contains the Calendar Server 6 administrative password.
Required unless information is provided in clifile.
-L --migrationserverport Server and port information to connect to the Calendar Server 6 host from which data needs to be migrated. The format is server:port. Required unless information is provided in clifile.
-l log-directory --logpath Logs information about the migration status. Optional. Defaults to the Calendar Server 7 log directory.
-f --file Local input file for batch operation. Each line contains the email address for an account. Optional if using the -a option for single user migration, or an LDAP base URL is provided by using the -B option.
-S --clientssl Use SSL when making client connections. Optional.
-B --baseuri Base URL in LDAP. All users under the URL are migrated. Required if -a or -f options are not specified.
-R --ldapfilter User search filter in LDAP. Default is objectclass=icsCalendarUser.
Optional.
-T --starttime Start date for events and tasks to be migrated. The format of this value is yyyymmddThhmmssZ. This value is in Zulu time. (The T is a separator between the day and time.) Optional.
-c --capture Captures trace information and details regarding the migration.
Optional. Useful if migration fails but produces a large amount of output.
-G --tag Log tag to use to check status. This is the path to the master log file that is output when the migration command is executed.
Required for status check.
-h --help Usage of davadmin migration. Optional.

For more information, see Migration Logging.

The clifile that is provided through the -F option can be used to provide entries for migrationadminuser, migrationadminpassword, and migrationserverport. Note that the long option for -x is --migrationadminpasswordpath, a path to the password file, but the entry in the clifile is migrationadminpassword, since it is just a password.

Tool-Only Options

Two options, -V and -h, can be used without any operation specified. The -V option prints the version of the command-line utility. The -h option prints the general usage.

Exit Code

The tool exits with exit code 0 on success and 1 on failure.

Examples

The calcomponent argument replaces the calresource argument starting in Calendar Server 7 Update 1.

  • To display the current Calendar Server version:
  • To show all configuration parameters:
  • To show the current setting for the error log:
  • To set the error log to accept "finest" messages:
  • To create an additional calendar with the given name for the specified user account:

The name, which is a required parameter, builds the new calendar's URI and sets its display name.

  • To list a summary of the calendar specified by name:
  • To delete a calendar specified by name:
  • To list the calendar resources in the user's default calendar:
  • To display the contents of a particular calendar resource:
  • To list only a calendar's tasks:
  • To list all calendar resources from March 3, 2009 through March 4, 2009:
  • To delete the event resources from March 3, 2009 through March 4, 2009, assuming that the local time zone is Pacific Time:
  • To perform a full database backup:
  • To perform a full backup for a particular user:
  • To perform an incremental backup:
  • To perform a full backup for a particular domain:
  • To perform a restore from a backup file:
  • To perform a restore of a deleted event:
  • To perform a migration of user1's calendar:
  • To perform a migration of a list of users using the clifile for most of the input values.
  • To create and list the account for a user:
  • To delete an account:
  • To set the scheduling rights on John Smith's account to allow Jane Doe to schedule events and everyone else to just do free busy checks:
  • To set the access rights on John Smith's default calendar to give Jane Doe all rights and only read rights to everyone else:

JConsole

The data and operations exposed by the MXBeans in the CalDAV server are accessible and modifiable by using JConsole. All Admin Beans can be found under com.sun.comms.davserver.adminutil.

AdminAccountMXBean Operation

Provides deleteAccount, listAccount, modifyAccount, and checkConnection operations.

AdminCalComponentMXBean Operation

Provides getCalComponent, deleteCalComponent, importCalComponent, exportCalComponent, and checkConnection operations.

AdminCalendarMXBean Operation

Provides createCalcollection, modifyCalCollection, deleteCalCollection, getCalCollection and checkConnection operations.

AdminConfigMBean Operation

You use the getConfigParam and setConfigParam operations to get and set configuration options. The AllConfigParams operation provides a list of the configuration parameters. The value in JConsole is displayed as a "java.lang.String[]" array and double-clicking this field shows the individual parameters.

AdminMigrationMXBean Operation

Provides checkStatus, migrate, and checkConnection operations.

AdminMiscMBean Operation

The version attribute of this MBean provides the server version.

If GlassFish is running in a secure mode, JConsole needs to be started with the truststorepath (-Djavax.net.ssl.trustStore) and optionally truststorepassword (-Djavax.net.ssl.trustStorePassword) passed in.

Calendar Server 7 Configuration Parameters

The following table lists the configuration parameters and descriptions for Calendar Server 7. See the config command for information on how to update or change configuration parameters.

Note
The information on this page is generated automatically. Any changes made to this page will be overwritten the next time the information is updated. If you would like to request a change to this information, use the Comments feature. All comments will be considered.
Parameter Description
base.ldapinfo.cachesize Size of the LDAP Authentication cache.
Syntax: integer
Default: 1000
base.ldapinfo.cachettl Time to live (in seconds) of cached LDAP Authentication info.
Syntax: integer
Unit: seconds
Default: 60
base.ldapinfo.dcroot Root of DC tree (Schema 1) or of the domain and users tree (Schema 2) in Directory Server
Syntax: string
Default: o=isp
base.ldapinfo.defaultdomain Default domain
Syntax: string
Default: demo.example.com
base.ldapinfo.loginseparator Character(s) to be used as login separator (between userid and domain)
Syntax: string
Default: @
base.ldapinfo.schemalevel Schema level
Syntax: integer
Default: 2
base.ldapinfo.searchfilter This is the search filter used to look up users during authenticationwhen one is not specified in the inetDomainSearchFilter for the domain. The syntax is the same as inetDomainSearchFilter (see Communications Suite Schema Reference).
Syntax: string
Default: (uid=%U)
base.ldapinfo.serviceadmindn DN of single admin in LDAP in absence of admin group.
Syntax: string
Default:
base.ldapinfo.serviceadminsgroupdn DN of service admins group in LDAP
Syntax: string
Default:
base.ldapinfo.userattrs Space separated list of LDAP attributes to retrieve from user entries during the authentication phase.
Syntax: string
Default: mail ismemberof
base.ldapinfo.authldap.binddn Distinguished Name to use when authenticating.
Syntax: string
Default:
base.ldapinfo.authldap.bindpassword Password to use when authenticating.
Syntax: password
Default:
base.ldapinfo.authldap.ldaphost Space-delimited list of host names. Each host name may include a trailing colon and port number.
Syntax: string
Default: localhost:389
base.ldapinfo.authldap.ldappoolrefreshinterval Length of elapsed time until the failover directory server reverts back to the primary directory server. If set to -1, don't refresh.
Syntax: integer
Unit: minutes
Default: 1
base.ldapinfo.authldap.ldappoolsize Maximum number of connections for this pool.
Syntax: integer
Default: 10
base.ldapinfo.authldap.ldapport Port number to which to connect. Ignored for any host name which includes a colon and port number.
Syntax: integer
Default: 389
base.ldapinfo.authldap.ldaptimeout Timeout for all LDAP operations.
Syntax: integer
Unit: seconds
Default: 60
base.ldapinfo.authldap.ldapusessl Use SSL to connect to the LDAP host.
Syntax: boolean
Default: false
base.ldapinfo.ugldap.binddn Distinguished Name to use when authenticating.
Syntax: string
Default:
base.ldapinfo.ugldap.bindpassword Password to use when authenticating.
Syntax: password
Default:
base.ldapinfo.ugldap.ldaphost Space-delimited list of host names. Each host name may include a trailing colon and port number.
Syntax: string
Default: localhost:389
base.ldapinfo.ugldap.ldappoolrefreshinterval Length of elapsed time until the failover directory server reverts back to the primary directory server. If set to -1, don't refresh.
Syntax: integer
Unit: minutes
Default: 1
base.ldapinfo.ugldap.ldappoolsize Maximum number of connections for this pool.
Syntax: integer
Default: 10
base.ldapinfo.ugldap.ldapport Port number to which to connect. Ignored for any host name which includes a colon and port number.
Syntax: integer
Default: 389
base.ldapinfo.ugldap.ldaptimeout Timeout for all LDAP operations.
Syntax: integer
Unit: seconds
Default: 60
base.ldapinfo.ugldap.ldapusessl Use SSL to connect to the LDAP host.
Syntax: boolean
Default: false
davcore.acl.aclcachesize Maximum number of ACL entries kept in cache. Entries are removed from the cache only when this maximum is reached or when any of the acl configuration parameter is changed. Can be set to 0, indicating no cache.
Syntax: integer
Default: 1000
davcore.acl.aclcachettl Maximum amount of time (in seconds) that an ACL entry can be kept in cache.
Syntax: integer
Unit: seconds
Default: 60
davcore.acl.calendaranonymousall If true, map '@'(all) in calendar acls to authenticated and unathenticated users. If false, map '@'(all) in acl to just authenticated users.
Syntax: boolean
Default: true
davcore.acl.defaultcalendaracl ACL to set when creating a new calendar collection (using the WCAP format).
Syntax: string
Default:
davcore.acl.defaultresourcecalendaracl ACL to set when creating a new calendar collection for a resource (using the WCAP format).
Syntax: string
Default: @:r
davcore.acl.defaultresourceschedulingacl ACL for user permissions to be set when creating a new calendar inbox collection for a resource (using the WCAP format).
Syntax: string
Default: @:s
davcore.acl.defaultschedulingacl ACL for user permissions to be set when creating a new calendar inbox collection (using the WCAP format).
Syntax: string
Default: @:s
davcore.acl.schedulinganonymousall If true, map '@'(all) in scheduling acls to authenticated and unathenticated users. If false, map '@'(all) in acl to just authenticated users.
Syntax: boolean
Default: true
davcore.autocreate.calattendantresourceflags Calendar attendant flags to set on resource scheduling inbox.
This value can be altered by the presence of the icsAutoAccept and icsDoubleBooking attributes.
The value is a bitmask of the following:
0x01: autoaccept.
0x02: decline on conflict.
0x04: decline recurring meetings.
Syntax: long
Default: 3
davcore.autocreate.calattendantuserflags Calendar attendant flags to set on users scheduling inbox.
This value can be altered by the presence of the icsAutoAccept and icsDoubleBooking attributes.
The value is a bitmask of the following:
0x01: autoaccept.
0x02: decline on conflict.
0x04: decline recurring meetings.
Syntax: long
Default: 0
davcore.autocreate.calcomponents Supported calendar components set for a new calendar on autocreation.
Syntax: string
Default: VEVENT VTODO VFREEBUSY
davcore.autocreate.defaultaddressbook Name of default addressbook, created during autocreation.
Syntax: string
Default: addressbook
davcore.autocreate.defaultcalendar Name of default calendar, created during autocreation.
Syntax: string
Default: calendar
davcore.autocreate.displaynameattr LDAP attribute, whose value is used to set Display Name, during autocreation.
Syntax: string
Default: cn
davcore.autocreate.emailnotificationaddressattr LDAP attribute, whose value is used to set Email Notification address, during autocreation.
Syntax: string
Default: mail
davcore.autocreate.enableemailnotification Enable email notification, for this account.
Syntax: boolean
Default: true
davcore.homeuri.*.backendid Once it is determined that a uri matches the pattern, this backendid template is used to identify the backend hosting this resource.
The template can reference the $1, $2,... variables saved during the pattern matching, as well as references to LDAP attributes of the subject matching the subjectfilter, using the ${attrname} syntax or the ${attrname,defaultvalue} syntax. If this parameter is not set, the uriinfo.backendidtemplate is used.
Syntax: string
Default:
davcore.homeuri.*.rank When multiple uri patterns are configured, this value determines in which order those uri patterns should be evaluated. A lower number indicates that this pattern should be evaluated first.
Syntax: integer
Default: 1
davcore.homeuri.*.subjectdomain Once it is determined that a uri matches the pattern, this domain template is used to identify the subject owning with this resource.
The template can reference the $1, $2,... variables saved during the pattern matching. For example, if the subjectdomain is set to "$2", and using the uri in the uripattern example, the domain of the subject will be "example.com".
Can be empty indicating the default domain.
Syntax: string
Default: $2
davcore.homeuri.*.subjectfilter Once it is determined that a uri matches the pattern, this LDAP filter template is used to identify the subject owning with this resource.
The template can reference the $1, $2,... variables saved during the pattern matching. For example, if the subjectfilter is set to "(mail=$1@$2)", and using the uri in the uripattern example, the LDAP filter will become "(mail=john@example.com)".
Can be empty, indicating that this namespace is not associated with a particular subject.
Syntax: string
Default: (mail=$1@$2)
davcore.homeuri.*.uripattern Regex pattern to be matched by the uri.
This pattern can contain regex groups (identified by () parenthesis) which will be saved into $1, $2,...
The last regex group identifies the local path if there is any.
For example, if the pattern is "^/home/([^/]+)@([^/]+)(/\z|/.*)", the uri /home/john@example.com/calendar/ will match that pattern. $1 will be set to the value "john", $2 will be set to the value "example.com" and the local path will be "/calendar".
Syntax: string
Default: ^/home/([^/]+)@([^/]+)(/\z|/.*)
davcore.ldapattr.commonname Common name attribute.
Syntax: string
Default: cn
davcore.ldapattr.davstore Logical backend id attribute.
Syntax: string
Default: davStore
davcore.ldapattr.dngroupmember Attributes for members in an LDAP group.
Syntax: string
Default: uniquemember
davcore.ldapattr.groupobject Space separated list of Objectclass values indicating an LDAP group.
Syntax: string
Default: groupofuniquenames groupofurls inetmailgroup
davcore.ldapattr.icsautoaccept LDAP attribute to use to determine whether autoaccept should be turned on.
The attribute value can be 1 (autoaccept) or 0 (no autoaccept).
It is used only during autocreate.
Syntax: string
Default: icsAutoAccept
davcore.ldapattr.icsdoublebooking LDAP attribute to use to determine whether doublebooking is allowed.
The attribute value can be 1 (double booking allowed) or 0 (no double booking allowed).
It is used only during autocreate.
Syntax: string
Default: icsDoubleBooking
davcore.ldapattr.icsstatus Calendar Service status attribute.
Syntax: string
Default: icsstatus
davcore.ldapattr.mail Mail attribute.
Syntax: string
Default: mail
davcore.ldapattr.mailalternateaddress Alternate mail attribute.
Syntax: string
Default: mailAlternateAddress
davcore.ldapattr.mailgroupmember Attributes for members in an LDAP group.
Syntax: string
Default: mgrprfc822mailmember
davcore.ldapattr.memberattr LDAP attribute listing the groups the entry is a member of.
Syntax: string
Default: ismemberof
davcore.ldapattr.preferredlang Language attribute.
Syntax: string
Default: preferredLanguage
davcore.ldapattr.resourceobject Space separated list of Objectclass values indicating an LDAP resource.
Syntax: string
Default: icsCalendarResource
davcore.ldapattr.resourceowner LDAP attribute to use to determine the owner of a calendar resource (e.g. conference room).
The attribute value must be a DN.
It is used only during autocreate.
Syntax: string
Default: owner
davcore.ldapattr.uid User ID attribute.
Syntax: string
Default: uid
davcore.ldapattr.urlgroupmember Attributes for members in an LDAP group.
Syntax: string
Default: memberurl
davcore.otheruri.*.backendid Once it is determined that a uri matches the pattern, this backendid template is used to identify the backend hosting this resource.
The template can reference the $1, $2,... variables saved during the pattern matching, as well as references to LDAP attributes of the subject matching the subjectfilter, using the ${attrname} syntax or the ${attrname,defaultvalue} syntax. If this parameter is not set, the uriinfo.backendidtemplate is used.
Syntax: string
Default:
davcore.otheruri.*.rank When multiple uri patterns are configured, this value determines in which order those uri patterns should be evaluated. A lower number indicates that this pattern should be evaluated first.
Syntax: integer
Default: 1
davcore.otheruri.*.subjectdomain Once it is determined that a uri matches the pattern, this domain template is used to identify the subject owning with this resource.
The template can reference the $1, $2,... variables saved during the pattern matching. For example, if the subjectdomain is set to "$2", and using the uri in the uripattern example, the domain of the subject will be "example.com".
Can be empty indicating the default domain.
Syntax: string
Default: $2
davcore.otheruri.*.subjectfilter Once it is determined that a uri matches the pattern, this LDAP filter template is used to identify the subject owning with this resource.
The template can reference the $1, $2,... variables saved during the pattern matching. For example, if the subjectfilter is set to "(mail=$1@$2)", and using the uri in the uripattern example, the LDAP filter will become "(mail=john@example.com)".
Can be empty, indicating that this namespace is not associated with a particular subject.
Syntax: string
Default: (mail=$1@$2)
davcore.otheruri.*.uripattern Regex pattern to be matched by the uri.
This pattern can contain regex groups (identified by () parenthesis) which will be saved into $1, $2,...
The last regex group identifies the local path if there is any.
For example, if the pattern is "^/home/([^/]+)@([^/]+)(/\z|/.*)", the uri /home/john@example.com/calendar/ will match that pattern. $1 will be set to the value "john", $2 will be set to the value "example.com" and the local path will be "/calendar".
Syntax: string
Default: ^/home/([^/]+)@([^/]+)(/\z|/.*)
davcore.principalsuri.*.backendid Once it is determined that a uri matches the pattern, this backendid template is used to identify the backend hosting this resource.
The template can reference the $1, $2,... variables saved during the pattern matching, as well as references to LDAP attributes of the subject matching the subjectfilter, using the ${attrname} syntax or the ${attrname,defaultvalue} syntax. If this parameter is not set, the uriinfo.backendidtemplate is used.
Syntax: string
Default:
davcore.principalsuri.*.rank When multiple uri patterns are configured, this value determines in which order those uri patterns should be evaluated. A lower number indicates that this pattern should be evaluated first.
Syntax: integer
Default: 1
davcore.principalsuri.*.subjectdomain Once it is determined that a uri matches the pattern, this domain template is used to identify the subject owning with this resource.
The template can reference the $1, $2,... variables saved during the pattern matching. For example, if the subjectdomain is set to "$2", and using the uri in the uripattern example, the domain of the subject will be "example.com".
Can be empty indicating the default domain.
Syntax: string
Default: $2
davcore.principalsuri.*.subjectfilter Once it is determined that a uri matches the pattern, this LDAP filter template is used to identify the subject owning with this resource.
The template can reference the $1, $2,... variables saved during the pattern matching. For example, if the subjectfilter is set to "(mail=$1@$2)", and using the uri in the uripattern example, the LDAP filter will become "(mail=john@example.com)".
Can be empty, indicating that this namespace is not associated with a particular subject.
Syntax: string
Default: (mail=$1@$2)
davcore.principalsuri.*.uripattern Regex pattern to be matched by the uri.
This pattern can contain regex groups (identified by () parenthesis) which will be saved into $1, $2,...
The last regex group identifies the local path if there is any.
For example, if the pattern is "^/home/([^/]+)@([^/]+)(/\z|/.*)", the uri /home/john@example.com/calendar/ will match that pattern. $1 will be set to the value "john", $2 will be set to the value "example.com" and the local path will be "/calendar".
Syntax: string
Default: ^/home/([^/]+)@([^/]+)(/\z|/.*)
davcore.reverseuri.*.backendid Backend id on which to apply this reverse mapping. There should be only one mapping per backend.
Syntax: string
Default:
davcore.reverseuri.*.uritemplate Canonical form of the URI prefix for this backend.
This template should have a corresponding uripattern. It should not end with a slash.
The template can reference LDAP attributes of the subject, using the ${attrname} syntax or the ${attrname,defaultvalue} syntax. The ${domain} syntax can be used to reference the domain of the subject.
If no template is defined for a given backend, the uriinfo.defaulthomeuritemplate config parameter is used.
Syntax: string
Default:
davcore.scheduling.includememberinattendee If set, scheduling messages would include the MEMBER=group attribute in the ATTENDEE property where group is the LDAP group which this attendee is a member of. The default is set to false in order to accommodate compatibility with Leopard Apple iCal.
Syntax: boolean
Default: false
davcore.scheduling.ischedulebackendid iSchedule Backend identifier. If not set, incoming iSchedule requests are disabled.
Syntax: string
Default:
davcore.scheduling.itiptransmittablexprops Space separated list of iCalendar X- properties that are transmittable via iTIP.
All other X- properties are not transmitted between organizer and attendees.
Syntax: string
Default: X-S1OC-OWNER-APPT-ID X-S1OC-TZID X-S1OC-OUTLOOK-SENDER-EMAIL X-S1OC-OUTLOOK-SENDER-CN X-S1OC-OUTLOOK-ACCEPTED-BY-NAME X-S1OC-OUTLOOK-EVENT-REPLY-TIME
davcore.scheduling.localuserattr Local Dav server identifier attribute in LDAP. If not set, all users found in LDAP are considered local. For deployments with multiple servers, that can only partially interoperate, this option must be set to a valid LDAP attribute. (For example: davStore). Then, users with a valid value for that attribute in LDAP, are considered local. Others are considered remote. Make sure the same attribute is added to davcore.uriinfo.subjectattributes values.
Syntax: string
Default:
davcore.scheduling.maxbookingwindow specifies the number of days calendars that dont allow doublebooking can be booked in advance.
Syntax: integer
Unit: days
Default: 365
davcore.scheduling.rejectinactiverecipients When set to true, recipients of scheduling messages who have their icsStatus set to inactive will be treated as unknown recipients. Otherwise, those recipients will be treated as iMIP recipients.
Syntax: boolean
Default: false
davcore.scheduling.synchronousdelivery If set, scheduling messages (invitations, replies, cancel,...) will be delivered synchronously on submit. This option should not be set under normal circumstances.
Syntax: boolean
Default: false
davcore.serverdefaults.tzid Default TZID to return when a calendar collection does not have one explicity set.
Syntax: string
Default:
davcore.serverlimits.httpconnecttimeout HTTP connection timeout value(in milliseconds), when connecting to another server
Syntax: integer
Default: 5000
davcore.serverlimits.httpsockettimeout HTTP Socket timeout value(in milliseconds), when connecting to another server, and waiting for data
Syntax: integer
Default: 5000
davcore.serverlimits.maxattendeesperinstance Maximum number of ATTENDEE properties in any instance of a calendar object resource stored in a calendar collection.
Syntax: long
Default: 1000
davcore.serverlimits.maxcalendarcontentlength Maximum size of a calendar resource.
Syntax: long
Unit: bytes
Default: 200000000
davcore.serverlimits.maxcontentlength Maximum size of a resource. Might be overwritten for certain types of content (e.g. text/calendar).
Syntax: long
Unit: bytes
Default: 200000000
davcore.serverlimits.maxgroupexpansion Maximum nested level of group expansion
Syntax: integer
Default: 3
davcore.serverlimits.maxhttpredirects Maximum number of HTTP Redirects to follow, when connecting to another server
Syntax: integer
Default: 3
davcore.serverlimits.maxmigrationthreads Maximum number of threads to create when running migration.
Syntax: integer
Default: 2
davcore.serverlimits.maxresults Maximum number of resources returned by a single fetch operation (WebDAV PROPFIND, CalDAV Reports, WCAP fetch or export, etc...).
A value of 0 means no limit.
Admins are not affected by this limit.
Syntax: integer
Default: 10000
davcore.serverlimits.maxsearchtimerange Maximum bounded search range in days.
Syntax: long
Unit: days
Default: 3660
davcore.serverlimits.maxuploadcontentlength Maximum size when uploading data. This affects operations that let you create multiple resources in one request (e.g. import). It does not affect regular PUT.
Syntax: long
Unit: bytes
Default: 20000000
davcore.serverlimits.migrationtimeout Maximum number of hours to wait before terminating a migration.
Syntax: integer
Default: 8
davcore.serverlimits.minsearchcharacters Minimum number of characters allowed in a text filter search.
Syntax: integer
Default: 3
davcore.serverlimits.templocktimeout Maximum amount of time to wait for a temporary lock when doing write operations.
Syntax: integer
Unit: seconds
Default: 60
davcore.uriinfo.backendidtemplate The backendid template is used to identify the backend hosting the home of a given subject.
The template can reference LDAP attributes of the subject, using the ${attrname} syntax or the ${attrname,defaultvalue} syntax.
Syntax: string
Default: ${davStore,defaultbackend}
davcore.uriinfo.defaultdavuriprefix Canonical form of DAV URI prefix for WebDAV based protocols.
This prefix corresponds to one of the the DavServlet specific path (e.g. /dav) as defined in web.xml.
It should not end with a slash.
Syntax: string
Default: /dav
davcore.uriinfo.defaulthomeuritemplate Canonical form of a subject home URI prefix.
This template should have a corresponding uripattern. It should not end with a slash
The template can reference LDAP attributes of the subject, using the ${attrname} syntax or the ${attrname,defaultvalue} syntax. The ${domain} syntax can be used to reference the domain of the subject.
Syntax: string
Default: /home/${mail}
davcore.uriinfo.defaultprincipaluritemplate Canonical form of a subject principal URI prefix.
This template should have a corresponding uripattern. It should not end with a slash.
The template can reference LDAP attributes of the subject, using the ${attrname} syntax or the ${attrname,defaultvalue} syntax. The ${domain} syntax can be used to reference the domain of the subject.
Syntax: string
Default: /principals/${mail}
davcore.uriinfo.emailsearchfiltertemplate LDAP Filter used when searching a subject by email address.
The %s token will be replaced by the email value to search.
Syntax: string
Default: |(mail=%s)(mailalternateaddress=%s)
davcore.uriinfo.fulluriprefix Full url prefix to use wherever a full url is required. It should not end with a slash.
This prefix is used, among other things to construct attachment urls embedded in calendar resources.
Modifying this parameter won't change full urls in already existing calendar resources.
If ssl is used, the hostname part of this prefix should match the host name associated with the certificate.
Syntax: string
Default: {{ http://localhost

}}

davcore.uriinfo.ldapcachesize Maximum number of subjects (LDAP users, resources and groups) kept in cache when mapping URIs and subjects. Entries are removed from the cache only when this maximum is reached or when any of the uriinfo configuration parameter is changed. Can be set to 0, indicating no cache.
Syntax: integer
Default: 1000
davcore.uriinfo.ldapcachettl Maximum time (in seconds) that subjects (LDAP users, resources and groups) are kept in cache when mapping URIs and subjects.
Syntax: integer
Unit: seconds
Default: 60
davcore.uriinfo.permanentuniqueid Name of an LDAP attribute present in the LDAP entry of all subjects (users, groups, resources,...) and defining a permanent and unique identifier for each subject.
The attribute value is used internally to do the mapping between the subject LDAP entry and its repository. As such, it should remain constant for the lifetime of the subject LDAP entry and it should be unique (at least within the subject domain).
!!! WARNING !!! Changing this configuration parameter will result in data loss once users repository have been created.
Syntax: string
Default: nsUniqueID
davcore.uriinfo.principalsrootcollection Defines the root collection of all principals in their canonical form. (without any prefix). This parameter is used to return the WebDAV DAV:principal-collection-set property.
Syntax: string
Default: /principals/
davcore.uriinfo.subjectattributes Space separated list of LDAP attribute names to retrieve when doing a search for users, group or resources.
Syntax: string
Default: cn davstore icsstatus mail mailalternateaddress nsuniqueid owner preferredlanguage uid objectclass ismemberof uniquemember memberurl mgrprfc822mailmember
davcore.uriinfo.subjectsearchfilter LDAP Filter used when a user is searching for other users.
The %s token will be replaced by the search string.
Syntax: string
Default: (|(uid=%s*)(cn=*%s*)(mail=*%s*))
davcore.uriinfo.subjectsearchfilterminimum The mimimum number of characters allowed for the search string.
Syntax: integer
Default: 3
davcore.uriinfo.uricachesize Maximum number of resolved uris kept in cache. Entries are removed from the cache only when this maximum is reached or when any of the uriinfo configuration parameter is changed. Can be set to 0, indicating no cache.
Syntax: integer
Default: 10000
davcore.uriinfo.uricachettl Maximum time (in seconds) that resolved uris are kept in cache.
Syntax: integer
Unit: seconds
Default: 60
log.dav.commands.logdir Directory path for log files
Syntax: filepath
Default: logs
log.dav.commands.loglevel Specify the log level for the Command log
Syntax: loglevel
Default: INFO
log.dav.commands.logtoparent Flag to enable logging to the Application Server log file, in addition to the davserver logs.
Syntax: boolean
Default: false
log.dav.commands.maxlogfiles Maximum number of log files
Syntax: integer
Default: 10
log.dav.commands.maxlogfilesize Maximum size of each log file
Syntax: integer
Unit: bytes
Default: 2097152
log.dav.errors.logdir Directory path for log files
Syntax: filepath
Default: logs
log.dav.errors.loglevel Specify the log level
Syntax: loglevel
Default: INFO
log.dav.errors.logtoparent Flag to enable logging to the Application Server log file, in addition to the davserver logs.
Syntax: boolean
Default: false
log.dav.errors.maxlogfiles Maximum number of log files
Syntax: integer
Default: 10
log.dav.errors.maxlogfilesize Maximum size of each log file
Syntax: integer
Unit: bytes
Default: 2097152
log.dav.scheduling.logdir Directory path for log files
Syntax: filepath
Default: logs
log.dav.scheduling.loglevel Specify the log level for the Command log
Syntax: loglevel
Default: INFO
log.dav.scheduling.logtoparent Flag to enable logging to the Application Server log file, in addition to the davserver logs.
Syntax: boolean
Default: false
log.dav.scheduling.maxlogfiles Maximum number of log files
Syntax: integer
Default: 10
log.dav.scheduling.maxlogfilesize Maximum size of each log file
Syntax: integer
Unit: bytes
Default: 2097152
log.dav.telemetry.logdir Directory path for log files
Syntax: filepath
Default: logs
log.dav.telemetry.loglevel Specify the log level for the Command log
Syntax: loglevel
Default: INFO
log.dav.telemetry.logtoparent Flag to enable logging to the Application Server log file, in addition to the davserver logs.
Syntax: boolean
Default: false
log.dav.telemetry.maxlogfiles Maximum number of log files
Syntax: integer
Default: 10
log.dav.telemetry.maxlogfilesize Maximum size of each log file
Syntax: integer
Unit: bytes
Default: 2097152
notification.dav.configdir Directory path for notification configuration files or format files
Syntax: filepath
Default: config/templates
notification.dav.enableemailnotif Enable server-wide email notification
Syntax: boolean
Default: true
notification.dav.enablejmsnotif Enable server-wide JMS notification
Syntax: boolean
Default: true
notification.dav.smtpauth SMTP-AUTH access control mechanism flag
Syntax: string
Default: false
notification.dav.smtphost SMTP host
Syntax: string
Default:
notification.dav.smtppassword SMTP password
Syntax: string
Default:
notification.dav.smtpport SMTP port
Syntax: string
Default: 25
notification.dav.smtpstarttls SMTP start tls flag
Syntax: string
Default: true
notification.dav.smtpuser SMTP user
Syntax: string
Default: user
service.dav.propfinddavheadervalue Value of the HTTP Dav header value to return in all PROPFIND responses.
Syntax: string
Default: calendar-auto-schedule
service.dav.telemetry.filter Space separated list of request URI that a particular request should match (start with) to be logged by telemetry (e.g. "/dav/home/jsmith/calendar/ /dav/home/jdoe/calendar/").
Syntax: string
Default:
service.dav.telemetry.forcetelemetry Force telemetry for all users. Warning: this generates a lot of data and should not be used on a production system.
Syntax: boolean
Default: false
service.wcap.maxsessions Maximum number of resolved uris kept in cache. Entries are removed from the cache only when this maximum is reached or when any of the uriinfo configuration parameter is changed. Can be set to 0, indicating no cache.
Syntax: integer
Default: 10000
service.wcap.sessiontimeout Number of seconds before expiring a session.
Syntax: integer
Unit: seconds
Default: 1800
store.dav.*.attachstorehost Attachment store host.
Syntax: string
Default:
store.dav.*.attachstoreport Attachment store port.
Syntax: integer
Default: 8008
store.dav.*.backendid Backend identifier.
Syntax: string
Default:
store.dav.*.dbdir Directory path for dav store.
Syntax: filepath
Default: data/db
store.dav.*.jndiname JNDI name pointing to this backend's JDBC DataSource, as defined in the J2EE container (e.g. "jdbc/defaultbackend".
Syntax: string
Default:
store.dav.*.purgedelay Set the delay between deletion of a resource and its actual removal (purge) from the backend. Setting this value too low may cause sync clients to do a full resync too often.
Syntax: long
Unit: seconds
Default: 2592000

CalDAV LDAP Schema Reference

Eventually, this information should become part of Communications Suite Schema Reference. For now, here are the schema additions and changes for Calendar Server 7.

Topics:

New CalDAV Object Class

Calendar Server 7 introduces one new object class, davEntity.

davEntity

Supported by Calendar Server 7
Superior Class top
Object Class Type auxiliary
OID 1.3.6.1.4.1.42.2.27.9.2.139

Definition

Common DAV object.

Required Attributes

None.

Allowed Attributes

mail, davStore, davAllowedServices, davEventNotification, davEventNotificationDestination, davTimeZone

Updated Calendar Server Object Classes

Calendar Server 7 updates the following three object classes:

New CalDAV Attributes

Calendar Server 7 introduces the following five new attributes:

davStore

Origin Calendar Server 7
Syntax cis, single-valued
Object Classes davEntity
OID 1.3.6.1.4.1.42.2.27.9.1.936

Definition

Logical back-end ID. Used only if you have multiple Calendar Server back-end hosts.

Example

davStore: backend1

davAllowedServices

Origin Calendar Server 7
Syntax cis, single-valued
Object Classes davEntity, icsCalendarDomain
OID 1.3.6.1.4.1.42.2.27.9.1.937

Definition

List of allowed services. If no value is specified, then all services are allowed.

Example

davAllowedServices: caldav

davTimezone

Origin Calendar Server 7
Syntax cis, single-valued
Object Classes davEntity
OID 1.3.6.1.4.1.42.2.27.9.1.938

Definition

The default time zone for this DAV object. Specifically, a valid time zone from the list found in Standard Time Zones.

Example

davTimezone: America/Chicago

davEventNotification

Origin Calendar Server 7
Syntax cis, ASCII, single-valued
Object Classes InetMailUser, davEntity
OID 1.3.6.1.4.1.42.2.27.9.1.939

Definition

Enables DAV JMS notifications.

Example

davEventNotification: True
davEventNotification: False

Calendar Server Deployment Planning

Topics:

Oracle Communications Calendar Server for CALDAV Clients Deployment Architecture

The following components are required for a Calendar Server deployment:

  • GlassFish Enterprise Server (web container for Calendar Server)
  • Calendar Server (CalDAV server)
  • Directory Server (LDAP store)
  • MySQL Server (calendar store)
  • SMTP server, such as Messaging Server, for notifications

Calendar Server itself is stateless. To achieve a highly available calendar environment, you can deploy multiple instances of Calendar Server to be managed by a GlassFish cluster.

In addition, you can deploy multiple MySQL database instances (davStore user LDAP attribute). For monitoring, administration, tuning, and backup and restore, you use the native MySQL tools and utilities.

Planning for Multiple Calendar Server Hosts

Using multiple Calendar Server hosts can help in the following ways:

  • Avoiding network latency and unnecessary bandwidth consumption by positioning the server closer to the client (geographically distributed environment).
  • Scaling horizontally by distributing users onto different machines, thus avoiding possible bottlenecks in terms of I/O, memory, CPU, and backup time. A very large deployment can also be geographically distributed.

The smallest unit of data that can be migrated from one server to another corresponds to a single subject's repository.

MySQL Based Deployment

This figure shows MySQL Server deployed for Calendar Server 7.

If you deploy Calendar Server with other applications in the same GlassFish Enterprise Server web container, you have an additional context root in the URI:

http://calendar-server-host-name:port_context-root/dav/principals/email-address/

Example: http://example.com:3080/app1/dav/principals/jsmith@example.com/

Calendar Server Logical Architecture

  • Single-Tiered Calendar Server Architecture. You can deploy all components to a single host.
  • Two-Tiered Calendar Server Architecture. You can deploy Calendar Server with the front-end davserver component installed on a separate host and the MySQL Server back end installed on another host.
  • Two-Tiered, Multiple Server Calendar Server Architecture. You can install multiple front-end davserver hosts and multiple back-end MySQL Server hosts. You can also install the document store onto a separate host.

Mapping Calendar Users to Back-End Servers

As described in Front-End and Back-End Servers, you can distribute the DAV repository across multiple DAV server instances. The smallest unit of data corresponds to a single subject (user or group) home collection and all its descendants. When a user issues a Calendar Server request, the front-end host handling the request must determine on which back-end MySQL host the targeted resource resides. This is the role of the davstore identifier.

About the davstore Identifier

The mapping between front ends and back ends is indirect:

  • Each Calendar Server front-end instance is configured with the list of opaque back-end identifiers, called "davstore IDs." One davstore ID is configured per back-end MySQL host database.
  • A Java Naming and Directory Interface (JNDI) name is associated with each davstore ID is (it is also in the Calendar Server configuration), for example: jdbc/davstore id.
  • The GlassFish Enterprise Server's web container hosting the server is configured with corresponding JNDI resources containing the actual back-end information, for example, server names, ports, database names, and credentials.
  • At startup, the server does a JNDI lookup for each davstore ID value in its configuration.

A single MySQL Server instance can contain multiple SQL databases. Each davstore ID identifies one of those SQL databases, not the MySQL Server instance as a whole.

You can back up each back-end store by using replication, file system backups, or by using the davadmin backup command. See Best Practices for Backing up and Restoring MySQL Databases in Calendar Server Deployments for more information.

davstore LDAP Attribute

You can add the davStore LDAP attribute to users' and resources' subject entries to associate those users and resources with a particular back-end Calendar Server store. The value of the davStore attribute is equal to one of the davstore IDs defined in the server configuration. davstore is single valued. If a davstore is not present, a server configurable default davstore ID is used.

Calendar Server users use only one attribute for all data types (calendar, address book, and files). This arrangement does not prevent a deployment from using different repositories for the different types of data. The only restriction associated with using a unique attribute is that all users with the same davStore value are hosted on the same repository.

Note
The Calendar Server installation and configuration supports only one front-end/back-end deployment. You need to perform some additional steps to set up the multiple-server scenario. See Calendar Server 7 Horizontal Scalability and Multiple Hosts Scenarios for more information.

Calendar Server Tuning

See Calendar Server 7 Performance Tuning.

Unable to render {include} Couldn't find a page to include called: Calendar Server 7 Horizontal Scalability

Best Practices for Backing Up and Restoring MySQL Databases in Calendar Server Deployments

This information is intended for use by Calendar Server 7 installations that use the MySQL database for the calendar store.

Topics:

Overview

Calendar store backup and restore is one of the most important administrative tasks for your Calendar Server deployment. You must implement a backup and restore policy for your calendar store to ensure that data is not lost if problems such as system crashes, hardware failures, or accidental deletion of information occur.

This information describes your options for backing up and restoring the calendar store (MySQL database and the attachment store). You need to understand the pros and cons of these solutions to make the proper choice for your deployment.

Calendar Server Backup and Restore Techniques

The section describes the recommended ways to back up the Calendar Server data store.

Using davadmin db backup

Calendar Server provides the davadmin db backup command to back up the calendar server data.

Pros:

  • Supports partial backup and restore.
  • You can also use backup and restore to migrate data from one Calendar Server host to another.

Cons:

  • The davadmin db backup command is relatively slow.

ZFS Snapshots

Use ZFS snapshots to produce an atomic snapshot of the file system containing the MySQL database and the attachment store. Then use zfs send or a third-party file system backup software to back up the snapshot. See http://docs.sun.com/app/docs/doc/819-5461/gavvx?a=view.

Pros:

  • Performance is better than davadmin db backup.

Cons:

  • This method does not support partial backup and restore.
Note
You cannot backup the Calendar Server store by backing up the active MySQL database and the Calendar Server data directory while Calendar Server is running. If you do so, bad data will result.

MySQL Backup and Restore Techniques

The following methods backup the MySQL database only. For general information about MySQL backup and restore, see http://dev.mysql.com/doc/refman/5.1/en/backup-and-recovery.html.

Calendar Server 7 Troubleshooting

Troubleshooting Tips

Begin troubleshooting by making sure that the GlassFish Enterprise Server web container is running and that Calendar Server is deployed. You can use either the GlassFish Admin Console or the asadmin command-line utility.

To Use the asadmin Command-line Utility to Specify GlassFish Port

If you have more than one GlassFish instance installed, use the asadmin -p to specify the instance's administrative port number.

To Use the GlassFish Admin Console to Check davserver Status

  1. Start the console.
  2. Navigate to Web Applications under the Applications tab.
  3. Make sure that davserver is deployed and enabled.

To Use the asadmin Command-line Utility to Check davserver Status

  • Run the following command:

To Troubleshoot davserver

  1. If davserver is not enabled, check the GlassFish log, server.log, in the /opt/SUNWappserver/domains/domain1/logs or equivalent directory.
  2. If davserver is deployed and enabled but clients have trouble connecting, check the davserver log, calendar.*, in the /var/opt/sun/comms/davserver/logs or equivalent directory.
    To increase the log level, use the davadmin command, for example:

To Troubleshoot a Failing davadmin Command

  • If a davadmin command fails to run, use the -e option to get more details about the failure.
    For example:
    # ./davadmin version
    Enter Admin password:********\*
    DAV server connection failed. Is the server running?
    # ./davadmin version \-e
    Enter Admin password:********\*
    JMXconnection exception for url service:jmx:rmi:///jndi/rmi://commsuite.example.com:46633/jmxrmi - Exception creating connection to: 1.1.1.1; nested exception is:
    java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl)
    

This example shows SSL errors. In this case, you would make sure that the truststore file pointed to by the command through the -s option, or the commandfile option, or the default one, if none were specified explicitly, exists and is valid. The default truststore file, .asadmintruststore, is located in the config directory.

To verify:

  1. As root, run an asadmin command on the GlassFish Server host on which Calendar Server is deployed.
    An .asadmintrustore file is created under the root (/) directory.
  2. Make sure that this file is the same as the one in the Calendar Server config directory.

To Troubleshoot Back-end Errors

If you find a back-end error, make sure MySQL Server is running by pinging the JDBC connectionpool.

  1. Start the GlassFish Admin Console.
  2. Go to Resources->JDBC Resources->Connection Pools.
  3. Choose the caldavPool and perform a ping.
  4. If the ping fails, check the Pool properties to make sure they are all correct.
  5. You can also perform a command-line ping as follows:
  6. Even if you ping the pool, sometimes Calendar Server is not able to load the back end. In this case, you see errors similar to the following:
  7. To see the pool and resource data clearly, view GlassFish configuration file, for example:
  8. If cause of error is not clear, delete and recreate the Connection Pool and JDBC resource by using the asadmin command, for example:

    If you recreate the JBDC resource, be sure to use the same user name and password that you initially used to create the resource.
    Restart the Application Server after recreating the Connectionpool and resource

To Import a Convergence ics File

You might see the following error when importing an ics file that was created in Convergence. The following example is for Calendar Server 7.

# ./dist/davadmin calresource import -u admin -W passwordfile -a caluser6@example.com -m convergence_caluser6_2.2.ics
Unable to import the resource into 'calendar'. DUE: 20090905T000000Z is before or equal to DTSTART: 20090905T000000Z

Starting with Calendar Server 7 Update 1, the calcomponent argument replaces the calresource argument.

This is likely a Convergence problem, since it creates the todo by setting DTSTART and DUE to the same time. Note that this is due to the restrictions as described in RFC5545. The description section states that DUE must be later than DTSTART.

The workaround is to manually fix the iCal data to have DTSTART before DUE.

To Search for Other Users if the System Fails

Calendar Server 7 uses proxy authentication to Directory Server, which enables you to retrieve information on other users on the system of interest. For this to work properly, you must configure Directory Server for domain level proxy access in the domains in which the user information resides. Make sure that the LDAP ACI on the domain nodes are set for proxy, for example:

Common Errors in Log Files

This section presents common errors that you might see in the Calendar Server 7 log files.

Using the Same Start and End Date for an Event

Same UID Already in Use

No Specification of Content-type Header

Deleting a Non-existing File

Posting to Calendar Collection Without Filename

Using a Non-implemented HTTP Method

For more information, see Administering Calendar Server 7 Logging.

Using the Browser Servlet

You can use a web-based user interface to view an account's properties stored in collections and resources. You might find this helpful when troubleshooting calendar problems.

To access this "browser servlet," take any valid dav uri and replace the dav prefix following davserver with browse. For example, in a browser, change the following

http://example.com:3080/davserver/dav/home/smithj/calendar/

to

http://example.com:3080/davserver/browse/home/smithj/calendar/

The servlet returns a a view of the account's properties stored in collections and resources. You can navigate among properties and delete them as well. The servlet also has some import function if you want to use a server side import instead of a client side import.

Tip
When viewing multiple accounts, clear your browser cache before viewing the next account.

Troubleshooting CalDAV Clients

This section describes client issues.

Lightning

  • Lightning does not support more than one calendar account. It allows only one account per server at a time.
  • Lightning 0.9 does not support multiple reminders for single events. Lightning 1.0 beta 1 does support multiple reminders.
  • Lightning is not able to create an account if the user name contains special characters.
  • If Lightning 1.0 beta1 is installed with Thunderbird 3, and you try to go back to Thunderbird 2 and Lightning 0.9, when starting Thunderbird the following error occurs:
    The Calendar data in your profile was updated by a newer version of Lightning, and continuing will probably cause the information to be lost or corrupted. Lightning will now be disabled and Thunderbird restarted.
    

    To fix:

  1. Export all your calendar data in iCalendar format.
  2. Remove the calendar database storage.sdb file from your profile.
  3. Restart the Thunderbird and import the iCalendar file.
  • Thunderbird on Solaris OS needs to be reloaded twice to get the newly created Todo.
  • Inviting users on Thunderbird for Solaris OS and checking their availability does not show free/busy check properly. Instead, the invitee is always shown as free even when the invitee is busy.
  • Calendar import is failing with Thunderbird on Windows and Solaris OS. The failed import displays the "Modification_failed" error message. Logging back in to the profile loads the imported data to the calendar.

Apple iCal

  • Apple iCal adds its own default reminder to an event if you select the "Add a default alarm to all new events and invitations" option. Thus, if calendar1 exports the event (with no reminder) and calendar2 imports it, the imported reminder has a default alarm set.
  • Apple iCal is not able to create an account if the user name contains special characters.
  • If the event is created with "Repeat on Weekdays only" option from Lightning or Convergence, the Apple iCal will convert it to "Every day" and display it.

iPod touch

The following information was found with iPod touch 3.1.3 firmware.

Supported Features:

  • Event is supported.
  • Reminders are supported with iPod touch, up to a maximum of two reminders for a single event.
  • Recurrence is supported.
  • iPod touch client enables you to a create duplicate calendar.

Unsupported Features:

  • Todos.
  • [AppleiPhone]STATUS not being taken into account when invitation event canceled by organizer.
  • Invitations can be viewed by not accepted, declined or rejected.
  • When the organizer of the event cancels the event, invitees do not have any information that event is cancelled.
  • Attachments.
  • Free/Busy.
  • Availability check.
  • Import-Export functionality.
  • Share/Subscribe of calendar.

Known Issues

Apple iPhone STATUS not being taken into account when invitation event canceled by organizer

When an iPod touch user gets an invitation from a Lightning user, there is no option to accept, reject, or decline the event. Additionally, when the inviting user deletes the event, the iPod touch user does not receive an event notification, nor is the event deleted from the user's calendar. The event is in read-only mode.

Unable to render {include} Couldn't find a page to include called: Writing a JMS Consumer for Calendar Server 7 Notifications

Configuring Multiple Calendar Server Back-end Hosts

This information describes how to configure multiple Calendar Server back-end hosts. For conceptual information, see Calendar Server Front-End and Back-End Servers.

Topics:

High-Level Steps

The high-level steps to configure multiple back-end Calendar Server hosts include:

  1. Creating the new MySQL database and gathering the MySQL host names, ports, and other database names
  2. Gathering back end Calendar Server host names, ports, and data base names
  3. Planning your naming conventions for davStore IDs, JBDC connection pools, and JBDC resources
  4. Adding the davstore IDs to LDAP
  5. Adding the JBDC connection pools and associated JBDC resources to GlassFish Enterprise Server
  6. Verifying the connection from GlassFish Enterprise Server to the Calendar Server back end
  7. Editing the cal-svr-base/davserver/config/davserver.properties file
  8. Restarting GlassFish Enterprise Server

To Configure Multiple Calendar Server Back-End Hosts

  1. Create the new MySQL database.
    See to Install the Calendar Server and MySQL Server Software.
  2. Add values for the davstore attribute to the Directory Server LDAP.
    • If you are using Delegated Adminstrator to create a new Calendar Server 7 user, the attribute is added by Delegated Administrator.
    • If you are adding the attribute to an existing Calendar Server 7 user, use an LDAP tool such as ldapmodify.
      Note
      Once the attribute is set, and user is in use, do not change the attribute. A change requires migrating the user's existing data.

      For more information, see: davstore attribute

  3. Add the JBDC connection pools and associated JBDC resources to GlassFish Enterprise Server for the back-end hosts.
    • Command line:
      Use create-jdbc-connection-pool and create-jdbc-resource. For example:

      For more information, see http://docs.sun.com/app/docs/doc/820-4497/create-jdbc-connection-pool-1?l=en&a=view.

    • GlassFish Server Admin Console:
      1. From the Tree of Common Tasks, click the Resources.JDBC.Connection Pools node.
      2. Click New and set the following properties:
      • Name: poolname
      • Resource Type: javax.sql.DataSource
      • Database Vendor: MySQL
      1. Click Next.
      2. Set the following properties and be sure that the URL property is either not set or set correctly.
        You can also delete all default properties and keep just the following six properties.
        • databaseName: name
        • portNumber: port
        • networkProtocol: jdbc
        • serverName: localhost (or your MySQL server host name)
        • user: mysql
        • password: password
      3. Save.
      4. Go to Resources -> JDBC -> JDBC Resources to create the JDBC resource for the connection pool.
      5. Select New and type the following information:
        • JDNI Name: jdbc/backend1
        • Pool Name: poolname (same poolname as before)
        • Status: check Enabled
  4. Verify the connection.
    You can test the connection to the back-end host by clicking Ping as shown in the following screen shot. Click Connection Pool and you should be be able to see this selection.
    This figure shows the GlassFish Admin Console for configuring connection pools.
  5. Edit the cal-svr-base/davserver/config/davserver.properties file and add the following entries:
    store.dav.<backend1>.backendid=<backend1>
    store.dav.<backend1>.jndiname=jdbc/<backend1>
    

    where backend1 is the JBDC resource that you created for the corresponding connection pool.

  6. Restart GlassFish Enterprise Server, for example:
    # /opt/SUNWappserver/bin/asadmin stop-domain domain1
    Domain domain1 stopped.
    # /opt/SUNWappserver/bin/asadmin start-domain domain1
    Starting Domain domain1, please wait.
    Log redirected to /opt/SUNWappserver/domains/domain1/logs/server.log.
    Please enter the admin user name>admin
    Please enter the admin password>adminpass
    Please enter the master password>adminpass
    

Examples: Creating Connection Pools for Non-Default Calendar Server Back Ends

This section contains the following topics:

To Use the GlassFish Admin Console to Create a Connection Pool for Non-Default Back Ends

This example uses the GlassFish Admin Console to create a connection pool caldav1Pool and JDBC resource jbc/backend1.

  1. Select New and type the following information.
    • Name: caldav1Pool
    • Resource Type: javax.sql.DataSource
    • Database Vendor: MySQL
  2. Click Next.
  3. Set the following properties and be sure that the URL property is either not set or set correctly.
    You can also delete all the default properties and keep just the following six properties.
    • databaseName: caldav1
    • portNumber: 3306
    • networkProtocol: jdbc
    • serverName: localhost (or your MySQL server host name)
    • user: mysql
    • password: mysql
  4. Save.
  5. Select the pool and use the Ping button to test the pool.
    If ping was not successful, you can delete all the default properties and keep just the six properties previously mentioned. Then retry the ping.
  6. Create JDBC resource for the connection pool.
    Go to Resources -> JDBC -> JDBC Resources.
  7. Select New and type the following information:
    • JDNI Name: jdbc/backend1
    • Pool Name: caldav1Pool
    • Status: check Enabled

To Use the Command Line to Create a Connection Pool for Non-Default Back Ends

This example uses the command-line interface to create a connection pool caldav1Pool and JDBC resource jbc/backend1.

Multiple Back-ends Flow of Information

The following figure shows a multiple back-end configuration consisting of a single front end and two back ends.

Calendar Server 7 Multiple Back Ends Configuration

This figure shows a multiple host Calendar Server 7 back-end configuration.

The information flow is as follows:

  1. Users log in to Calendar Server.
  2. LDAP attribute davstore is read, indicating which back end the user is associated with.
  3. The davstore attribute is mapped to one of the store.dav.xx.backendid values in the davserver.properties file.
  4. The corresponding JNDI name (store.dav.xx.jndiname) is obtained.
  5. This points to a JDBC Resource associated with the MySQL back-end database.
  6. The JDBC Resource points one of the JDBC Connection pools.
  7. The user gets a Calendar Server database connection.

For example, in the preceding figure, assume that user1 has a davstore attribute set to backend1. This would be mapped to the following:

store.dav.backend1.backendid=backend1
store.dav.backend1.jndiname=jdbc/backend1

The JNDI name would be obtained from:

store.dav.backend1.jndiname=jdbc/backend1

This, in turn, resolves to the following JDBC Resource:

Name=jdbc/backend1
ConnectionPool=caldav1Pool

Next, the following JDBC Connection pool is obtained:

ConnectionPool=caldav1Pool

Name=caldav1Pool
DB=jdbc:mysql://mysql1.example.com:3306/caldav1

Finally, user1 is given a connection to the MySQL back-end host with the caldav1 database.


This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related software documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all
appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open Company, Ltd.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

This product includes software developed by Computing Services at Carnegie Mellon University (http://www.cmu.edu/computing/).

Labels:
include include Delete
caldavserver caldavserver Delete
todo todo Delete
printable printable Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.