Sun Java Communications Suite 5 What's New

What's New in This Release of Calendar Server

Calendar Server 6.3 includes the following changes and new features:

Calendar Server Support in Delegated Administrator Console

In the past, provisioning Calendar Server for Schema 2 could be done with the Delegated Administrator Utility, but not with Delegated Administrator Console. Before this release, the Console was the Web graphical user interface for administering only Messaging Server . Now the Console can also be used to administer calendar LDAP entries. With the Console, you can add, delete, or modify LDAP entries for calendar users, groups, resources, and domains. New screens and menu items were added to the Console to support Calendar Server. For directions on how to use the interface, see the Delegated Administrator online help. Some information is also available in the Sun Java System Calendar Server 6.3 Administration Guide.

WCAP Attachment Support

Attachment support has been added to WCAP commands with the addition of new parameters and values.

While Communications Express, the Web user interface, does not support attachments yet, users of the Connector for Microsoft Outlook can now put attachments in their events and tasks, and can send attachments with invitations.

As part of attachment support, the following changes have been made to WCAP:

fetchattachment.wcap: a new command has been added to facilitate fetching of attachments. Only the attachment is fetched, not the event or task data itself.
deleteattach: a new argument for the storeevents command, used to delete existing attachments from an event or task without deleting the event or task itself.
fetchattach: a new parameter added to all fetch_by_* commands so that attachments can be returned as well as the event and task data itself.
sendattach: a new parameter for the storeevents command, used to specify whether the actual attachment is sent with the iTIP invitation, or not.
X-S1CS-CLIENT-ATTACH-ID: an X-Token containing the attachment's unique identifier. This X-Token is emitted only if the client supplied the attachment ID when the attachment was stored. Otherwise, the actual attachment is sent with the event.
The attachments argument can store a URL reference to attachments. These attachments are not stored in the data store.

For further information about attachments, see Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.

Support for LDAP Groups

It is now possible to create LDAP groups using Delegated Administrator. Groups have the following functionality:

A group is a list of users. The group does not “contain” the listed users. It is not a container.
A group can have a group calendar.
Invitations sent to a group reside on all the members' calendars, as well as the group calendar.
All members of the group share the same access rights to the group calendar.
There is no primary owner for a group calendar.

Multiple Domain Mode Only

Now all installations are automatically in multiple domain mode. Non-domain mode is not allowed. If your previous Calendar Server deployment did not use multiple domains, or even a single domain, you will now be required to have at least one domain, your default domain.

Configuration Program Enhancements

The configuration program has added screens for:

Creating Your Default Domain

Starting with this release, there will always be at least one domain under the root. This will be the default domain. Now you can specify the name of the default domain for your multiple domain environment in the configuration program.

Support of Distributed Calendar Server Databases

Now you can specify the names of the front-end and back-end machines for your distributed database environment, that uses the DWP protocol and the CLD plug-in. The calendar databases can be distributed over one or more back-end machines. These machines can be associated with one front-end machine. The new configuration program screens allow you to name the back-end machines and associate them with the front-end machine.

Email Address Field Added to Configuration Wizard Screen

In the default domain screen, a new field was added for the email address of the calendar super user (calmaster).

Recurrence Details Included in Email Invitations

For recurring events, email invitations sent to attendees now contain recurrence details.

Automatic Backup Process Now a Shared Library

The csstored.pl program is now a shared library.

Automatic Restart of Services Using Watcher

Calendar Server and Messaging Server now use the same stop and start mechanism. The start-cal and stop-cal commands are wrappers for a new internal service, csservice, which was introduced as part of the Watcher implementation. This service starts the Watcher, and then starts all other processes. The csservice program is aware of any dependencies the other services have, and in which sequence the services should be started.

Each registered service (process) opens a connection to the Watcher. If a process dies without properly disconnecting, the Watcher automatically restarts it. If the process dies twice in a defined interval, Watcher does not restart it. This timeout interval is configurable.

Additional Watcher information:

Calendar Server Services Monitored by Watcher

The Watcher monitors all of the services registered with it. For Calendar Server, the registered processes are: cshttpd, csadmind, csdwpd, dsnotifyd.

If csstored is enabled, that is, if the configuration parameter local.store.enable is set to "y", then csstored is also registered with the Watcher. When it is enabled, csstored must be successfully started before each service that accesses the store can be started. If it stops, then the dependent processes must be stopped an restarted also.

Configuring Watcher

Watcher is enabled by default. To manage the Watcher process, new parameters were added to the ics.conf file:

local.watcher.enable = "y": the start program (csservice) attempts to start the Watcher before any other services. If this parameter is set to "n", then the Watcher program is disabled.
service.autorestart = "y": the Watcher automatically restarts stopped services. If set to "n", Watcher does not restart stopped services. If this parameter is set to "n" , Watcher still monitors the services and sends failure or non-response error messages to the console and the cal_svr_base/data/log file.
local.autorestart.timeout = "600": the default time within which a second server failure triggers Watcher to stop trying to do a restart.
local.watcher.port: the default port is "49994"; however, if you have Messaging Server, it will also be listening on this port and will be in conflict with Calendar Server. To avoid possible conflict, it is safer to choose a different port for Watcher to listen on.

Watcher Logging

Watcher writes to two logs:

cal_svr_base/data/log: watcher sends failure notices and non-response error messages to the console. These messages are also written to this log.
cal_svr_base/data/log/watcher: watcher records all server stops and starts in this log file.

Automatic Restart in High Availability Deployments

If a server fails twice within the timeout period, the system stops trying to restart the server. In an HA system, Calendar Server is shutdown and a failover to the other system occurs.

Wrapper Scripts for csservice

The public interfaces to csservice are start-cal and stop-cal. This section shows the usage for each of these wrapper scripts and contains tables with explanations of their options and a list of components to be started or stopped.

start-cal Wrapper Script

The start-cal usage is as follows:

./start-cal [options...] [components...]

The following is the list of options:

-? or --help: Display this help list.
-d: Enable debugging mode.
-l: List active services.
-L: List enabled services.
-A: List all services.

This following is the list of components:

watcher

mfagent

ens

store

notify

admin

http

dwp

If no components are listed, start-cal starts all enabled services.

stop-cal Wrapper Script

The stop-cal usage is as follows:

./stop-cal [options...] [components...]

The following is the list of options:

-? or --help: Display this help list.
-d: Enable debugging mode.
-f: Force stop using SIGKILL. (This works only with UNIX® platforms.)

This following is the list of components:

watcher

mfagent

ens

store

notify

admin

http

dwp

If no components are listed, stop-cal stops all enabled services.

Monitoring Framework Integration

This section describes the Calendar Server implementation of the Monitoring Framework and covers the following topics:

Documentation of the Monitoring Framework and be found at itSun Java Enterprise System 5 Monitoring Guide.

How the Monitoring Framework is Implemented in Calendar Server

Calendar Server and Messaging Server both integrate minimally into the Monitoring Framework for Java Enterprise System. While the Monitoring Framework is running, it periodically checks the following attribute, operationalStatus , which can have the status of either OK, which means the system is running, or DOWN, which means the system is not running.

A new process, the Monitoring Framework agent (csmfagent), starts with system start up (start-cal). This is the first process started. The process instantiates an application and asserts its status as OK. It also catches SIGTERM and upon catching one, asserts status DOWN and exits.

Similarly, if the Watcher is configured and running, if any part of the system fails or becomes unresponsive, Watcher signals SIGTERM, which stops csmfagent.

Configuration of Calendar Server for Monitoring Framework

Edit the configuration file, ics.conf, to contain the following parameter:

local.csmfagent.enable = "y"

Configuring Monitoring Framework for Calendar Server

Perform the following two steps:

Copy /opt/SUNWcsgar/config/om.sun.cmm.cs.xml to /opt/SUNWmfwk/xml.
Stop and then restart the Manufacturing Framework process.

Installation Requirements

There are two requirements to be able to use the Monitoring Framework:

The Java Enterprise System Monitoring Framework (JESMF) must be installed.

If JESMF is not installed, csmfagent won't run.
Calendar Server must be able to find the necessary libraries.

Calendar Server finds the libraries using symbolic links in /opt/SUNWics5/lib .

The following are the JESMF libraries:

/opt/SUNWmfwk/lib/libMfTransaction.so

/opt/SUNWmfwk/lib/libMfRelations.so

/opt/SUNWmfwk/lib/libMflog4c.so

/opt/SUNWmfwk/lib/libMfMEServer.so

/opt/SUNWmfwk/lib/libmfBeepConnectorServer.so

/opt/SUNWmfwk/lib/libMfRserver.so

/opt/SUNWmfwk/lib/libMfMEInstrum.so

/opt/SUNWmfwk/lib/libMfDiscovery.so

/opt/SUNWmfwk/lib/libMfHashTable.so

/opt/SUNWmfwk/lib/libMflog.so

/opt/SUNWmfwk/lib/libasn1cebuf.so

/opt/SUNWmfwk/lib/libbeepcore.so

/opt/SUNWmfwk/lib/libbeepxmlutil.so

/opt/SUNWmfwk/lib/libbptostransport.so

/opt/SUNWmfwk/lib/libbptosutil.so

/opt/SUNWmfwk/lib/libbptoswrapper.so

/opt/SUNWmfwk/lib/libbputil.so

/opt/SUNWmfwk/lib/libcmm_native.so

/opt/SUNWmfwk/lib/libmfCserver.so

/opt/SUNWmfwk/lib/libmfNotificationProfile.so

/opt/SUNWmfwk/lib/libmfRequestResponseProfile.so

/opt/SUNWmfwk/lib/libmfTimers.so

/opt/SUNWmfwk/lib/libmfTimersJNI.so

/opt/SUNWmfwk/lib/libmfUtils.so

/opt/SUNWmfwk/lib/libmfber.so

/opt/SUNWmfwk/lib/libmfberj.so

/opt/SUNWmfwk/lib/libxmlglobal.so

Note –

Its possible not all of these files are necessary to implement Calendar Server's part of Monitoring Framework. This is just a list of all the JESMF libraries.

Transition to Message Queue for Notification Services

In this release, there are two notification services for event notifications and alarms: Sun Java System Message Queue (JMQ) and the Event Notification System (ENS). In a future release, the Communications Service products will use JMQ exclusively, and ENS will be removed. However, for this release, the Communications Services products (Messaging Server, Calendar Server, and Instant Messaging) still have internal dependencies on ENS, and you can continue to use ENS for notifications and alarms.

To use JMQ, rather than ENS, you must have Sun Java System Message Queue installed and configured. Install the product using the Sun Java Enterprise System installer. For information about configuring Message Queue, see theMessage Queue Documentation.

Calendar Server Configuration Parameters for JMQ

To configure Calendar Server for JMQ, you must add the following lines to the ics.conf file:

local.server.csmfagent.enable = "yes"

caldb.serveralarms.jmqlib = "/opt/SUNWics5/cal/lib/libmqcrt.so" (for Solaris)

Or,

caldb.serveralarms.jmqlib = "/opt/sun/calendar/lib/libmqcrt.so" (for Linux)

caldb.serveralarms.dispatchtype = "jmq"

caldb.serveralarms.jmqhost = "localhost"

caldb.serveralarms.jmqport = "7676"

caldb.serveralarms.jmqUser = "guest"

caldb.serveralarms.jmqPWD = "guest"

caldb.serveralarms.jmqTopic = "JES-CS"

Update Notification Properties

Each notification must have the following property: MQ_MESSAGE_TYPE_HEADER_PROPERTY . This property identifies what kind of notification it is.

In addition, notifications can have other properties as shown in the following table:

action: A string property that indicates the type of action this notification produces. This property can have the following values: "EMAIL", "AUDIO", "DISPLAY", "PROCEDURE", "FLASHING".
aid: A string property containing the alarm ID.
calid: A string property containing the calendar ID.
comptype: A string property indicating the type of component. The value is either "event" or "todo".
rid: An integer property containing the recurrence ID.
uid: A string property containing the component ID, that is either the event ID or the todo ID (task ID)

Update Notification Values

Notifications can be of two types: alarm notifications and update notifications for events and todos.

For alarm notifications, the value of MQ_MESSAGE_TYPE_HEADER_PROPERTY is simply "alarm".

For update notifications, the value of MQ_MESSAGE_TYPE_HEADER_PROPERTY depends on the type of action that triggered the notification. The following table lists the trigger actions and the corresponding values for this property.

Table 1–1 Update Notifications Values


Trigger	Update Notification Value
Deleting a calendar	`DELETECAL`
Modifying an event	`MODIFYEVENT`
Modifying a todo (task)	`MODIFYTODO`
Creating an event	`CREATEEVENT`
Creating a todo (task)	`CREATETODO`
Refreshing an event	`REFRESHEVENT`
Refreshing a todo (task)	`REFRESHTODO`
Replying to an event	`REPLYEVENT`
Replying to a todo	`REPLYTODO`

Organizers Can Now Receive Reply Notifications

Email notifications can now be sent to organizers when an attendee replies to an invitation.

Configure this feature by setting the ics.confparameter ine.reply.enable. Set it to "y" to enable the feature for the entire system. Set it to "n" to disable the feature. The feature is enabled by default.

The three reply types are: accept, decline, tentatively accept. The notification indicates whether the reply is to a single invitation or to an recurring event. The following new message format file parameters were added. The corresponding format files were also added:

calmail.imipeventacceptnotification.fname= "mail_eventacceptnotification.fmt"
calmail.imipeventdeclinenotification.fname= "mail_eventdeclinenotification.fmt"
calmail.imipeventtentativeacceptnotification.fname= "mail_eventtentativeacceptnotification.fmt"
calmail.imipeventacceptnotificationrecur.fname= "mail_eventacceptnotificationrecur.fmt"
calmail.imipeventdeclinenotificationrecur.fname= "mail_eventdeclinenotificationrecur.fmt"
calmail.imipeventtentativeacceptnotificationrecur.fname= "mail_eventtentativeacceptnotificationrecur.fmt"

Note –

This feature is not a user preference. That is, it is a system wide configuration parameter, so it applies to all users who send invitations.

For more information about configuring Calendar Server for email notifications, see To Enable Email Notifications in Sun Java System Calendar Server 6.3 Administration Guide, in the Calendar Server Administration Guide.

Attendees Can Now Modify Their Copy of an Event

Attendees now can modify information in an event on their calendar, including the summary and description.

Rename Tool Enhancement

The Calendar Server utility rename now renames deleted events.

Free-Busy Calculation Change

Declined events no longer show up as busy in free-busy calendars.

Disabling the Old Calendar Express UI

With earlier versions of Calendar Server, Calendar Express (the old user interface) was always enabled, even if you did not use the interface. Now it is possible to disable Calendar Express explicitly, using the new ics.conf parameter, service.http.ui.enable.

If you are upgrading from an earlier version of Calendar Server, the upgrade process adds the parameter to the ics.conf file set to "y". This allows the legacy user interface to continue to be used without any changes. However, if you wish to disable it, set this parameter to "n".

Since Calendar Express was deprecated, and is no longer automatically installed in a fresh installation, the parameter does not appear in the ics.conf file. The default internal setting is "n".

If you intend to use Calendar Express in a fresh installation, you must install Calendar Express and then add service.http.ui.enable="y" to the ics.conf file.

Installing on Mixed Hardware Platforms

In the past, for distributed database environments (DWP with CLD Plug-in), front-end and back-end processes had to be installed on the same hardware platform due to big endian-little endian problems. That is no longer true. Front-end and back-end processes can now be installed on different hardware platforms.

For example, a front-end machine could be an X-86 platform machine, while the back-end is a SPARC platform machine.

iTIP Compatibility

Messages sent by Calendar Server are now iTIP compatible (for Microsoft Outlook interoperability).

commdssetup.pl: New Option for a Password File Enhances Security

To enhance security, it is now possible to specify a password file rather than a text password when running commdssetup.pl. With the new -j <passwordfilename> option, you can protect passwords and enhance security. This is especially useful for scripts. If you have scripts that currently expose the password, and wish to change them, delete the -w < password> option and replace it with this new one.

Note –

This is a fix for problem #6392093.

csdb, cscal, csuser Relocated to cal/sbin

In earlier versions of Calendar Server, csdb, cscal, and csuser were found in the cal/bin directory, but now are located in the cal/sbin directory.

SSL Changes to ics.conf File

Due to changes in Calendar Server program code, the following changes have been made to the ics.conf file:

service.http.ssl.certdb.path deprecated in favor of local.ssldbpath. The path given should point to the config file ("/etc/opt/SUNWics5/config").
Instead of including the actual password to the certificate database in the ics.conf file, the password now resides in a file (sslpassword.conf) inside the config directory.

The proper format for a password in this file is:
```
Internal (Software) Token: password
```