Sun Java Communications Suite 5 Release Notes

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 in Calendar Server 6.3

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

Users of the Universal Web Client (Communications Express) and the Connector for Microsoft Outlook can 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 deprecated attachments argument, found in the storeevents and storetodos commands, can store URL references to attachments stored outside the Calendar Server data store. This way of using attachments remains for backward compatibility in this release but will be removed from the distribution in a future release.

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

Support for LDAP Groups in Calendar Server 6.3

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 By Default in Calendar Server 6.3

In the earliest versions of Calendar Server software, there was no domain structure. All user and group LDAP records resided under the root. Then in later versions, you could choose to establish one or more domains, called variously hosted domains or virtual domains. With the release of Calendar Server 6.3 software, all installations are required to use multiple domain mode by default. That is, you must have at least one domain, a default domain, that resides under the root domain. All user and group LDAP entries must reside under this default domain, or you can choose to have more domains. When you are in multiple domain mode, each canonical domain must containing unique user and group IDs. For more information on multiple domains, see theSun Java System Calendar Server 6.3 Administration Guide, specifically Chapter 10, Setting Up a Multiple Domain Calendar Server 6.3 Environment, in Sun Java System Calendar Server 6.3 Administration Guide.

The configuration program, csconfigurator.sh, which you must run to create the runtime environment, will prompt you for the name of your default domain. If that domain does not exist, the program will create it for you.

If your previous Calendar Server deployment did not use multiple domains, or even a single domain, you need to move user and group LDAP records under the new default domain.

To create additional domains in a Schema version 2 environment, use Sun Java System Delegated Administrator Console or Utility. For more information about Delegated Administrator, refer to the Sun Java System Delegated Administrator 6.4 Administration Guide.

If you use Schema version 1 and you are not migrating to Schema version 2, you can use the Calendar Server utility csdomain to create additional domains.

Calendar Server 6.3 Configuration Program Enhancements

The configuration program has added screens for:

Creating Your Default LDAP 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 in Calendar Server 6.3

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

csstored Now a Required Process in Calendar Server 6.3

The csstored daemon now manages the various Calendar Server databases. Because each service that accesses the store depends on the successful start of this store service, it should remain running on all servers, both front-end and back-end, whenever the Calendar Server system is running. The regular start-up and shut-down commands, start-cal and stop-cal, start and stop csstored along with the other daemons.

In earlier versions, if you were not configuring automatic backups, you did not need to run the PERL script, csstored.pl. The script could be started and stopped at will. The PERL script has been discontinued in favor of the csstored daemon. It is no longer optional to run this daemon, whether you decide to configure automatic backups or not.

Previously, you could disable the script from running by setting the ics.conf parameter local.store.enable to "no". However, now, csstored must always be enabled, with local.store.enable set to "yes", which is the default.

Automatic Restart of Calendar Services Using Watcher

Calendar Server and Messaging Server now use the same stop and start mechanism. The start-cal command starts the watcher process, and then starts all other processes. The watcherprocess 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, csnotifyd, and csstored.

The daemon csstored must be enabled. Be sure to set the configuration parameter local.store.enable to "y" . The enabling of csstored was optional in the previous version of Calendar Server, but now it is required. The csstored daemon must be successfully started before each service that accesses the store can be started. If it stops, then the dependent processes must be stopped and restarted also.

Configuring Watcher in Calendar Server 6.3

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 in Calendar Server 6.3

Watcher writes to a single log, cal-svr-base/data/log/watcher.log , which contains the following information:

Failure notices and non-response error messages that were sent to the administrative console.
Records of all server stops and starts.

Automatic Restart in High Availability Deployments in Calendar Server 6.3

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.

Starting and Stopping Calendar Server 6.3 Using 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 for Calendar Server 6.3

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

ens

store

notify

admin

http

dwp

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

stop-cal Wrapper Script for Calendar Server 6.3

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 in Calendar Server 6.3

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

You can find more information about Java Enterprise System Monitoring Framework in the Sun 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/com.sun.cmm.cs.xml to /opt/SUNWmfwk/xml.
Stop and then restart the Manufacturing Framework process.

Monitoring Framework Installation Requirements for Calendar Server 6.3

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 –

This is a list of all the JESMF libraries. It is possible that not all of them are necessary to implement the Calendar Server portion of the Monitoring Framework.

Transition to Message Queue for Calendar Server 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. In addition you must write your own notifications, as no notifications provided by Calendar Server 6.3.

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"

Message Queue Update Notification Properties for Calendar Server 6.3

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).

Message Queue Update Notification Values in Calendar Server 6.3

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. Table 2–2 lists the trigger actions and the corresponding values for this property.

Table 2–2 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`

Event Organizers Receive Reply Notifications by Email in Calendar Server 6.3

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.

Attendee Copies of Events Can Be Modified

The WCAP interface has been altered to allows an attendee's copy of calendar events to be modified, including the summary and description fields.

Rename Tool Enhancement

The Calendar Server 6.3 utility rename includes deleted items when renaming a calendar's data.

Free-Busy Calculation Change in Calendar Server 6.3

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

Disabling the Old Calendar Express UI in Calendar Server 6.3

With earlier versions of Calendar Server, Calendar Express (the old user interface) was automatically installed and enabled. You could not disable it, even if you did not use the interface. If you are upgrading to Calendar Server 6.3, the upgrade process adds service.http.ui.enable="y" to the ics.conf file. This keeps the old UI enabled if you want to use it, no further action is necessary.

To disable Calendar Express, set the value of service.http.ui.enable to "n" in the ics.conf file.

Calendar Express UI Not Automatically Installed in Calendar Server 6.3

Calendar Express is no longer installed automatically in a fresh install. If you are performing a fresh install of Calendar Server 6.3, but want to use Calendar Express as your user interface, you must explicitly install it using the Communications Suite 5 installation program. Then you must configure it by adding service.http.ui.enable="y" to the ics.conf file. (The default internal setting is "n" for fresh installs, so you must explicitly set it to "y".)

If you are upgrading from an earlier version of Calendar Server, the upgrade process adds the parameter to the ics.conf for you, with the value 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".

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 in Calendar Server 6.3

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

comm_dssetup.pl: New Option for a Password File Enhances Security in Calendar Server 6.3

To enhance security, it is now possible to specify a password file rather than a text password when running comm_dssetup.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.

Calendar Server 6.3 Utilities csdb, cscal, and 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 for Calendar Server 6.3

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
```