Skip to ContentSun and Oracle Channel Sun How to Buy Log In

Sun Java Communications Suite 5 Release Notes

View this book in:

Contained Within

Find More Documentation

Featured Support Resources

Download this book in PDF (1405 KB)

Chapter 2 Sun Java System Calendar Server 6.3 Release Notes

Version 6.3

These Release Notes contain important information available at the time of the general release of Sun Java^TM System Calendar Server 6.3 including:

Note –

A patch is available at Sun Solve for this version of Calendar Server. For more information, see Important Upgrade Patch Information for Calendar Server 6.3.

Read these Release Notes before you install and configure Calendar Server.

Calendar Server Release Notes Revision History

Table 2–1 Sun Java System Calendar Server Release Notes Revision History


Date	Description of Changes
June 8, 2007	Added the following section: Messaging Server Operating System Requirements
May 25, 2007	Problem 6560681 added. When upgrading to Calendar Server 6.3 from an older version, need to perform a workaround to avoid problem behavior. For the workaround, see Known Issues and Limitations in Calendar Server.
April 27, 2007	Re-release of these release notes to add more information to the What's New topic about the changes to `csstored`.
April 2007	Re-release of these release notes to add `configurator.sh` bug, problem number 6542989.
March 2007	Revenue Release of these release notes (Version 6.3)
September 2006	Beta Release Notes

About Calendar Server 6.3

Calendar Server is a scalable, web-based solution for centralized calendaring and scheduling for enterprises and service providers. Calendar Server supports user calendars for both events and tasks as well as calendars for resources, such as conference rooms and equipment. For a list of new features, see the following section, What's New in This Release of Calendar Server.

Calendar Server offers a graphical user interface, Communications Express. It also offers customers the flexibility to use the Web Calendar Access Protocol (WCAP) to access calendar data directly in either text/calendar or text/xml format.

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

Deprecated and Removed Features for Calendar Server 6.3

For Sun Java System Calendar Server 6.3 , the following features have been deprecated:

The Calendar Express graphical user interface (GUI) has been deprecated in favor of the Communications Express GUI and will be removed from the distribution in the the next major feature release. Move to Communications Express as soon as possible.
The WCAP attachments parameter, used by both storeevents and storetodo, has been deprecated. For backward compatibility, this parameter is still honored. But in a future release this parameter will no longer be recognized. Change any scripts you have using this parameter.
The cstool utility that you use for monitoring Calendar Server activity has been removed in the Calendar Server 6.3 release.
Calendar Server software is no longer available for Windows and HP-UX platforms.

Requirements for Calendar Server 6.3

This section describes the hardware and software required and recommended for this release of Calendar Server.

Product Version Compatibility Requirements for Calendar Server 6.3.

Calendar Server is compatible with the product versions listed in this section:

Table 2–3 Product Version Compatibility Requirements for Calendar Server 6.3.


Product	Version
Sun Cluster	3.1
Sun Java System Directory Server	5.1, 5.2, 6.0
Sun Java System Message Queue	3.7
Sun Java System Access Manager (formerly called Identity Server)	Legacy 6.x): Supports Access Manager 6 features, including the Access Manager 6 Console and directory information tree (DIT). If you are installing Access Manager with Portal Server, Messaging Server, Calendar Server, Delegated Administrator, or Instant Messaging, you must select the Access Manager Compatible (6.x) installation type.
Sun Java System Web Server	7.x
Sun Java System Application Server	8.2

NSS Version Requirements for Calendar Server6.3

Calendar Server 6.3 requires the use of the shared security component NSS version 3.9.3.

For more details about product version dependencies, see the Sun Java Enterprise System 5 Installation Guide for UNIX and Sun Java Enterprise System 5 Release Notes for UNIX

Calendar Server Hardware Requirements and Recommendations

Approximately 500 MB of disk space for typical installation. For production systems, at least 1 GB.
128 MB of RAM. For production systems, 256 MB to 1 GB for best performance.
RAID storage for fast access (recommended for large databases).

Calendar Server Software Requirements and Recommendations

This section describes the software required and recommended for this release of Calendar Server.

Calendar Server Operating System Requirements

Solaris^TM 10 Operating System (SPARC® Platform Edition, x86 Platform Edition)
Solaris 9 (5.9) Operating System (SPARC Platform Edition, x86 Platform Edition)
Red Hat Enterprise Linux Advanced Server (32-bit version), versions 3 (all updates) and 4 (all updates)
Calendar Server software is no longer supported on Windows and HP-UX platforms.

Recommended Browsers for Client Computers

See Communications Express Browser Requirements in Chapter 6, Sun Java System Communications Express 6.3 Release Notes.

Important Upgrade Patch Information for Calendar Server 6.3

At general release of Communications Suite 5, the following Calendar Server 6.3 product upgrade patches are as follows:

Platform	Patch Number (English)	Patch Number (Localized Languages)
Solaris, SPARC	121657–17	117010-26
x86	121658–17	117011-26
Linux	121659–17	117852-26

You can find the most current product patches at Sun Solve. For how to find patches on Sun Solve, use the following procedure:

How to Find Patches on SunSolve

For the current list of required patches for Sun Java System Calendar Server, go to:

http://sunsolve.sun.com

Select either “Patches” or “Patch Portal”.

Follow the Sun Java System Calendar Server links.

As operating system patch requirements change and patches to Java Enterprise System components become available, updates will be made available on SunSolve, initially in the form of recommended patch clusters.

Calendar Server Installation Notes

This section contains information you should know before you install Calendar Server 6.3, including:

Caution –

Calendar Server does not support Network File System (NFS) mounted partitions. Do not install or create any part of Calendar Server; including executable, database, configuration, data, temporary, or log files on an NFS-mounted partition.

Calendar Server Linux Platform Support

Java Enterprise System runs on the Linux platform. The major differences in user experience will be the path names where product directories are installed. The Linux platform installs into a different directory than the Solaris platform.

The following table shows the default installation directory paths for Solaris and Linux:

Solaris Default Directories	Linux Default Directories
`/opt/SUNWics5/cal/` (`cal-svr-base`)	`/opt/sun/calendar` (`cal-svr-base`)
`/etc/opt/SUNWics5/config`	`/etc/opt/sun/calendar/config`
`/var/opt/SUNWics5/`	`/var/opt/sun/calendar`

Tip –

In the documentation, the default installation directory for Calendar Server is referred to as cal-svr-base.

OS Patches

You must apply the required operating system patches before installing Calendar Server. For a list of required patches, see the Sun Java Enterprise System 5 Release Notes for UNIX.

Required Privileges

To run the Sun Java Enterprise System installer or the Calendar Server 6.3 configuration program on Solaris Systems, you must log in as or become the superuser ( root).

Linux Package Names

Install Calendar Server 6.3 using the Sun Java Enterprise System installer. The Java Enterprise System installer installs the Sun component product packages, including Calendar Server 6.3, and the shared components that are used by the various products.

The following table lists the Linux package names for the various Calendar Server related components.

Component	Package Name
Calendar Server	`sun_calendar-core` `sun-calendar-api`
Localized Packages:
Spanish	`sun-calendar-core-es`
Korean	`sun-calendar-core-ko`
French	`sun-calendar-core-fr`
Chinese	`sun-calendar-core-zh_CN`
German	`sun-calendar-core-de`
Japanese	`sun-calendar-core-ja`
Taiwanese	`sun-calendar-core-zh_TW`

Upgrading From an Earlier Version of Calendar Server 6

You can't upgrade to Calendar Server version 6.3 using the Sun Java System Communications Suite installer. You must use the patchadd process.

For more information about upgrading Calendar Server 6.3, see Sun Java Communications Suite 5 Upgrade Guide.

Upgrading Your Calendar Database

After you have upgraded to Calendar Server 6.3, you must upgrade your databases also, using various database tools named in this section. More information about the migration tools can be found in the Sun Java System Calendar Server 6.3 Administration Guide.

This section contains the following topics:

Upgrading from an Earlier Version of Calendar Server

If the version of your previous Calendar Server software predates version 5.1.1, first call technical support for assistance in migrating your databases to be Calendar Server 5.1.1 compatible. You can not migrate directly to any of the Calendar Server version 6 releases. In the process recommended by technical support, you will be required to install Calendar Server 5.1.1. After your database files are Calendar Server 5.1.1 compatible, install Calendar Server 6.3 and run the following database tools in the order listed.

cs5migrate

Run this utility to upgrade your databases from version 5.1.1 to version 6.2 level. This is an intermediate step that is required before you run the csmigrate utility to bring it up to version 6.3 level. The cs5migrate utility can be found in the sbin directory after you install Calendar Server 6.3.

You must specify the -r option. The cs5migrate utility then creates master and exception records for all recurring events and tasks. Going forward these records will be automatically generated by Calendar Server.

This utility performs the following changes to your databases:

Migrates your Calendar Server 5.1.1 LDAP database to be Calendar Server 6.2 compatible.
Migrates your Berkeley Data Base to version 4.2.
Writes the migration status to csmigrate.log log file.
Writes errors to csmigrateerror.log log file.

csmig

Run this utility so the LDAP CLD plug-in works properly.

csvdmig

Run this utility to convert your non-domain calendar databases to single domain databases compatible with a multiple domain environment.

csmigrate

Now that your Calendar Server Databases are in version 6.2 mode. run the csmigrate utility to migrate your Calendar Server 6.2 databases to be compatible with Calendar Server version 6.3.

You can find the csmigrate utility, along with other administrative tools, in the sbin directory of your newly installed Calendar Server 6.3 software. For more information on csmigrate , see Sun Java System Calendar Server 6.3 Administration Guide.

Caution –

If you are upgrading from a much older version of Calendar Server that was configured for limited virtual domain mode or has multiple instances of Calendar Server on the same machine, contact your Sun Microsystems, Inc. sales account representative for an evaluation of your migration requirements and to ensure that you have the specific migration utility that supports those requirements.

And, as always, never migrate your database without first performing a full backup.

Upgrading Your Calendar Server Version 6.0, 6.1, or 6.2 Databases to be Calendar Server Version 6.3 Compatible

Run csmigrate to upgrade your calendar databases to version 6.3 level.

Calendar Server Postinstallation Configuration

After installing or upgrading to Calendar Server 6.3 and before you can use Calendar Server, you must configure it as follows:

Run the Directory Server Setup Script (comm_dssetup.pl) to configure Sun Java System Directory Server for Calendar Server schema. For instructions, refer to Chapter 8, Directory Preparation Tool (comm_dssetup.pl), in Sun Java Communications Suite 5 Installation Guide.
Run the Calendar Server Configuration Program (csconfigurator.sh ) to configure your site’s specific requirements. For instructions, refer to the Sun Java System Calendar Server 6.3 Administration Guide.

Where to Find Calendar Server Data and Program Files

The following table shows where to find various files and programs referred to in the documentation for both the Solaris and Linux platforms:

File Names	Solaris Locations	Linux Locations
Administrator utilities: `start-cal,` `stop-cal,` `csattribute,` `csbackup,` `cscal,` `cscomponents,` `csdb,` `csdomain,` `csexport,` `csimport,` `csmonitor,` `csplugin,` `cspurge,` `csrename,` `csresource,` `csrestore,` `csschedule,` `csstats,` `cstool,` and `csuser`	`/opt/SUNWics5/cal/sbin`	`/opt/sun/calendar/sbin`
Migration utilities: `csmig` and `csvdmig`	`/opt/SUNWics5/cal/sbin`	`/opt/sun/calendar/sbin`
Configuration files: `ics.conf,` `version.conf,` `counter.conf,` and `sslpassword.conf`	After installation, files are located at: `/opt/SUNWics5/cal/` `config-template` During configuration, the various files from the above directory are moved to the locations specified by the configuration options you choose. The default location is: `/etc/opt/SunWics5/config`	After installation, the files are located at: `/opt/sun/calendar/` `config-template` During configuration, the various files from the above directory are moved to the locations specified by the configuration options you choose.
Mail formatting (*.`fmt)` files	After installation, the files are located at: `/opt/SUNWics5/cal/` `config-template` After configuration, the files are located at: `/etc/opt/SUNWics5/ config/language` where language is en, de, es, fr, ja, ko, zh-TW, or zh-CN.	After installation, the files are located at `/opt/sun/calendar/` `config-template` After configuration, the files are located at: `/etc/opt/sun/calendar/config/` `language` where language is en, de, es, fr, ja, ko, zh-TW, or zh-CN.
Library (.so) files SSL utilities: `certutil` and `modutil`	`/opt/SUNWics5/cal/lib`	`/opt/sun/calendar/lib`
Session database	`/opt/SUNWics5/cal/data/ http`	`/opt/sun/calendar/data/http`
Counter statistics files: `counter` and `counter.dbstat`	`/opt/SUNWics5/cal/lib/ counter`	`/opt/sun/calendar/lib/ counter`
`timezones.ics` file	`/opt/SUNWics5/cal/config`	`/opt/sun/calendar/config`

Tuning Directory Server Performance for Calendar Server

To improve the performance of your LDAP directory server, especially if you are using calendar searches of the LDAP directory consider the following items:

Indexing the LDAP Directory Server Attributes

To improve performance when Calendar Server accesses the LDAP directory server, add indexes to the LDAP configuration file for various attributes.

The configuration program, comm_dssetup.pl, will optionally do the indexing for you.

Tip –

To see the performance difference indexing can give you, perform the following test:

Before indexing, time how long it takes to run the following LDAP command:
ldapsearch -b "base" "(&(icscalendarowned=* user*)(objectclass=icsCalendarUser))"
Where base is the LDAP base DN of the directory server where the user and resource data for Calendar Server is located, and user is the value that an end user can enter in the Calendar Search dialog.
Run indexing for icsCalendarOwned.
Again run the following LDAP command, and time it:
ldapsearch -b "base" "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"
Where base is the LDAP base DN of the directory server where the user and resource data for Calendar Server is located, and user is the value that an end user can enter in the Calendar Search dialog.
Compare the times. There should be a measurable time difference.

Checking and Setting the Size Limit and the Look Through Limit Parameters

To determine if the Look Through Limit (nsslapd-lookthroughlimit) and Size Limit (nsslapd-sizelimit) parameters are set to appropriate values, try the following command:

ldapsearch -b "base" "(&(icscalendarowned=*
user ID*)
(objectclass=icsCalendarUser))"

where base is the LDAP base DN of the directory server where the user and resource data for Calendar Server is located, and user ID is the value that an end user can enter in a calendar search dialog in Communications Express.

If the LDAP server returns an error, the nsslapd-sizelimit or the nsslapd-lookthroughlimit parameter might not be large enough. Follow these guidelines to set these parameters:

Ensure that the value for the nsslapd-sizelimit parameter in the slapd.conf or equivalent file is large enough to return all the desired results; otherwise, truncation can occur, and no results will be displayed.
Ensure that the value for the nsslapd-lookthroughlimit parameter in the slapd.ldbm.conf or equivalent file is large enough to complete a search of all the users and resources in the LDAP directory. If possible set nsslapd-lookthroughlimit to -1, which causes no limit to be used.

Communications Express Using Schema 1

There are two issues with Schema 1 in Communications Express:

If you are running Communications Express with Sun LDAP Schema 1, before running the Communications Express configuration program, you must add the DC root node to your LDAP using ldapmodify. The entry should look like this:
```
dn: o=internet
 objectClass: organization
 o: internet
 description: Root level node in the Domain Component (DC) tree
```
The calendar utility used to provision users in Schema 1, csuser, was designed for Calendar Express and does not enable a user for Address Book service as is needed for Communications Express.

Calendar Server Provisioning Tools

There are two tools for provisioning users, groups and domains for Calendar Server: The Delegated Administrator and Calendar Server utilities. Delegated Administrator has two user interfaces: the Console, a graphical user interface, and the Utility, a command-line interface. For information on Delegated Administrator, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide. Instructions on use of the Console can be found in the Delegated Administrator Console online help.

For information on the Calendar Server utilities, see the Sun Java System Calendar Server 6.3 Administration Guide.

Caution –

Do not attempt to provision users through the Access Manager Console. Though it is possible to create users and assign them a calendar service, do not use this method as results will be unpredictable and will negatively impact your deployment.

Calendar Server Documentation Updates

Calender Server 6.3 includes the following documentation. Part numbers are in parentheses.

Sun Java System Calendar Server 6.3 Administration Guide (819-4654)
Sun Java System Calendar Server 6.3 WCAP Developer’s Guide (819-4655)

Note –
The Developer's Guide document has been reorganized for this release. All chapters not dealing with WCAP were removed. The removed material, covering CSAPI and the AuthSDK, had not been updated for several releases. If you have need to refer to the material in the deleted parts, see an older version of the guide, such as Sun Java System Calendar Server 6 2005Q4 Developer’s Guide.
Sun Java System Communications Express 6.3 Administration Guide (819-4440)
Sun Java System Communications Express 6 2005Q4 Customization Guide (819–2662)
Sun Java System Delegated Administrator 6.4 Administration Guide (819-4438)
Sun Java Communications Suite 5 Schema Reference (819-4437)
Sun Java System Communications Services 6 2005Q4 Schema Migration Guide (819-2656)
Sun Java Communications Suite 5 Event Notification Service Guide (819-4435)

Communications Express Online Help is available on the interface.

Delegated Administrator Console Online Help is available on the interface.

Calendar Server 6.3 documentation is available on the following Web site:

http://docs.sun.com/coll/1313.2

Sun Java Enterprise System Technical Note: Sun Java System Calendar Frequently Asked Questions (819–2631) This FAQ document has not been updated for this release.

Calendar Server Compatibility Issues

The following table lists the known incompatibilities between Calendar Server6.3 and earlier versions.

Incompatibility	Impact	Comments
Access Manager now has two install types: Legacy and Realm.	At installation, you must choose Legacy as the install type on the following panel: `Access Manager: Administration (1 of 6)`	If the wrong Access Manager is installed, you will not be able to run Delegated Administrator.
The Directory Preparation Tool `(comm_dssetup.pl)` under `/opt/SUNWics5` doesn't work.	`comm_dssetup.pl` is now in its own package installed in `/opt/SUNcomds` for Solaris, and `/opt/sun/comms/dssetup` for Linux Existing scripts that specify the old path need to be updated.	To install the package, be sure the Directory Preparation Tool is selected in the appropriate installer panel.
The configuration program for the Delegated Administrator has changed.	Install Delegated Administrator and run the configuration program. The current program is located at: for Solaris, `/opt/SUNWcomm/sbin/config-commda` for Linux `/opt/sun/comms/config-commda`	Upgrade to the new Delegated Administrator when installing this version of Calendar Server.
This release of Communications Express is incompatible with the previous version of Calendar Server.	If you upgrade Communications Express, you must also upgrade Calendar Server.	This also applies to Messaging Server.
Due to a change in the way packaging is done, Calendar Express must do string substitution at runtime.	Significant Performance Degradation	Call technical support to receive a script you can run before starting Calendar Server operations. The script performs all the required string substitutions. Calendar Express is deprecated and will not be included in a future release of Calendar Server. This problem will not be fixed.
Due to a program code change in SSL processing, the following parameter no longer works: `service.http.ssl.certdb.path`	Scripts and configuration files still using the old parameter to point to the SSL directory will not work. SSL is not enabled.	A new parameter was added to the `ics.conf` file: `local.ssldbpath = "/etc/opt/SUNWics5/config"`
Password to certificate database is no longer held in `ics.conf` parameter: `service.http.ssl. certdb.password`	SSL password can't be found. Error message: `General Error: http_ssl_init(): SSL initialization failed.`	Password to certificate database is now found in the following file located in the `config` directory: `sslpassword.conf` Format of password is: Internal (Software) Token:`password`
Non-domain environments no longer allowed.	Scripts that modify LDAP entries must now include a default domain.	When Calendar Server is installed and configured, it runs a silent conversion program on all LDAP entries to add the default domain you specified. Requests that come in (WCAP commands) without the domain will be automatically assumed to be for the default domain. But any scripts you run that directly modify LDAP entries must include the new default domain.
The `service.admin.calmaster.userid` and `service.admin.calmaster.cred` parameters in the `ics.conf` file are not used anymore.	You cannot set the Calendar user preferences and credentials using these old parameters.	The `service.admin.calmaster.userid` parameter is changed to `service.siteadmin.userid` and `service.admin.calmaster.cred` parameter is changed to `service.siteadmin.cred`. In case of an upgrade these parameters are migrated by the patch scripts.
Windows and HP-UX versions of Calendar Server are no longer available.	The only operating system platforms supported by server-side Calendar Server software are Solaris and Linux.	This does not effect client-side software, such as the Connector for Microsoft Outlook. See the individual client component Release Notes for a list of supported operating systems.

Problems Fixed in This Release of Calendar Server

The list that follows are problems reported fixed for the Beta version of Calendar Server 6.3:

4845346

csuser delete only deletes the default calendar.

4962061

Directory manager password stored as plain text in file ics.conf.

4963237

Users provisioned before configuring hosted domains cannot create events.

5060833

Processes disabled in the calendar configuration file will not stop when the stop command is issued.

Related to problem number 6216869. If you start a process (such as enpd) and then disable it in the ics.conf file, when stop-cal is issued, the system will not stop the disabled process.

6179278

Hot backup log files not purged according to configuration settings.

6203605, 6245878, 6246230

Administrators can't delete a domain from LDAP.

commadmin domain purge does not remove entries with deleted as their icsStatus. They must have removed as the status. The recommended Calendar Server utility, csclean, does not change the icsStatus to removed .

6210830

deletecomponents_by_range removes todos even though the due date is outside the delete range.

6210906

deletetodos_by_range.wcap does not honour dtstart, treats it as dtstart=0.

6216869

DWP does not stop when the stop command is issued.

Related to problem number 5060833. If DWP is disabled while the DWP process is running, stop-cal will not stop it. stop-cal should stop all services rather than just those enabled.

6268143

RFE: within a group the members of the group are showing only calid and not display name

6283756

Event notification emails have long lines, violating RFC 2822.

6286886

Calendar Server should not bundle certmap.conf file as it is not required. The file is intended for client-based SSL authentication which Calendar Server does not support.

6371337

cshttpd dumps core when calling set_calprops.wcap .

6377803

If Directory Server is Schema 2, and no domain has been created, the Calendar Server configuration program will display an error message and not allow the configuration against such a Directory Server.

Note –

This was fixed for the GUI version of the configuration program only. For the command-line version, you must created the domain in Delegated Administrator before configuring Calendar Server.

6391020

Misleading error message logged for Calendar Server.

6397674

csmigrate should create directory if it doesn't exist.

6402557

csclean did not remove user's calendar. No warning about reason.

6404071

WCAP errno returns a value of 60 when user tries to invite user on a different domain, with cross domain searches enabled.

6411890

proxyauth needs to be turned on by default.

6412007

Two email notifications sent when one instance of a event chain is modified.

6414650

The csmigrate migration utility hangs if ENS notifications are on.

6424254

The cshttpd process enters an infinite loop when calling the storeevents command.

6426426

Migration tool needs to create ldap_cache and cld_cache in the new database directory.

6399756

Calendar backup complains about not having enough disk space. Documented calculation wrong?

Calculation was correct, but archive and hotbackup directories need to be moved outside the csdb directory.

4964857

csdomain has no property to change LDAP attribute inetdomainstatus. This command is deprecated and will not be updated.

50755906

An index should be added for InetDomainBaseDN.

5029444

comm-dssetup needs to add more indexes.

6494477

caldb.calmaster parameter changed to "**UNKNOWN**" when reconfiguring silently.

Known Issues and Limitations in Calendar Server

This section contains tables that list of the more important known issues at the time of the Calendar Server 6.3 release:

Calendar Server Known Limitations

The following limitations are known at this time:

Problem Encountered with High Availability After Upgrading from an Older Version of Calendar Server to Calendar Server 6.3

If you use the high availability feature (using the Calendar Server HA package SUNWcsics), then after you upgrade from an older version of Calendar Server to the Calendar Server 6.3 version, you need to perform the following workaround to avoid problem 6560681.

Workaround:

Manually remove the SUNWscics package that comes with Calendar Server 6.3.
Use pkgadd to add the SUNWscics package bundled with the Java Enterprise System software.

Configuration Program Puts Wrong Value in DWP ics.conf Parameter

If you are deploying Calendar Server with front-end and back-end servers, which requires the use of the DWP protocol, the configuration program asks you to add the host name of the back-end server. When it stores this value in the ics.conf parameter caldb.dwp.server.hostname.ip , it stores it as an IP Address instead of the fully qualified host name that should be stored there. This means that the system can't find the back-end server.

Workaround:Replace the IP Address with the fully qualified back-end server host name. This can be done by simply editing the ics.conf file, which is a text file.

Correct instructions on what values to use for this and other parameters used to configure front-end and back-end servers can be found in Chapter 5, Configuring Calendar Database Distribution Across Multiple Machines in Calendar Server Version 6.3, in Sun Java System Calendar Server 6.3 Administration Guide in the Sun Java System Calendar Server Administration Guide.

This problem is reported as problem number 6542989 in the following section of this Release Note: Reported Problems in Calendar Server 6.3 .

After Upgrade, Can't Login on Linux Platform: “Backend Host Unresolvable”

On the Linux operating system, after upgrading to Calendar Server 6.3, there are error messages in the http.log file after running start-cal:

cshttpd[2984]: General Error: caldb: 
caldb_pvt_isLocalUrl: hostname of hostname.xyz.com is not resolvable.  
Please check that hostname is correct and that hostname resolver is correct.

Also, after attempting to log in, the following error message is given:

Backend Host Unresolvable
Please try again

Fix: This problem is fixed in Calendar Server 6.3 Update 1, patch number 121658-17.

This is the same as problem number 6516438 in the following section:Reported Problems in Calendar Server 6.3 .

Duplicate Parameters in Configuration File

Duplicate parameters are allowed in the configuration file, ics.conf . This can lead to some confusion about the value of the parameter. To determine which instance of a parameter is used by the system, find the last instance in the file. The system uses the value of the last instance of the parameter that it finds when processing the file.

Best practices: Add all changes to the end of the ics.conf file in a section labeled something like # My Parameter Changes. To keep a history of changes made, add a comment describing the reason for the change, and the date.

Periodically, comment out old changes that are no longer used, or if you do not care about a history of changes, delete old unused duplicates, leaving only the latest change in the file.

Performance Regression for Deprecated User Interface

In this version, string substitution in XSL files is no longer being done in a preprocessing step of packaging. Therefore, the strings are substituted in real time, which degrades performance for the Calendar Express user interface.

Workaround: You can perform the string substitution before running Calendar Server by processing all of the XSL files and manually inserting the correct language strings. To perform the substitution, you need to add the perl script (xslvarparser.pl ) that can be found in the { CAL_SERVER_BASE}/tools/unsupported/bin directory. Instructions to run the script are provided in the script itself.

For your convenience, the instructions provided in the script are as follows:

Use the perl script xslvarparser.pl to substitute variables in the XSL files to speed up XSL rendering.
Copy this file to the /opt/SUNWics5/cal/html directory, which is default on Solaris.
And then run it as $ perl xslvarparser.pl.
The resulting files are put under an out directory in each locale.
Replace the XSL files in each locale by the files in the out directory.

Note –
It is recommended that you save the original files before doing this substitution.

This issue is the same as described in problem number 6385495 in Reported Problems in Calendar Server 6.3 .

Removing all Instances of Multi-Valued User Preferences

Each set_userprefs command removes only one instance of a multi-valued preference.

Workaround: To remove all instances of a multi-valued user preference, you must issue one set_userpref command per instance.

For example: Perform a get_userprefs to list all of the user preferences. If there are multiple values for a preference, such as icsSubscribed , then you must issue one set_userprefs command to delete the preference for each of the values listed.

Finding Installed Patches in a Clustered Environment

There is no cluster specific showrev command that will show what is installed on the individual nodes of the cluster. (This is a generic problem, not just Calendar Server specific. You would run into the same difficulty with any product installed on a global file system.)

This is a problem when you want to update Calendar Server. You need to apply the patch to every node where Calendar Server was already installed. In addition you can’t apply the patch to a node if Calendar Server hasn’t already been installed on it. If you don’t know which nodes have Calendar Server installed and which do not, at the least, it will be confusing and cost you time trying to discover where Calendar Server is installed.

Workaround: Run the following command to see all of the nodes where Calendar Server is installed: pkgparam -v SUNWics5 | grep ACTIVE_PATCH

Pop-up Blockers

Certain Calendar Server windows will not display if you have a pop-up blocker enabled.

Workaround: Disable pop-up blockers for the Calendar URL to ensure all Calendar Server windows will display.

Exception: Neither the Norton Inet Security AD_BLOCKER nor the Mozilla built-in POP_BLOCKER will affect Calendar Server windows.

Provisioning Users for Communications Express in Schema 1 Mode

The csuser utility does not enable users it creates for Address Book.

Workaround: Enable the user using ldapmodify.

Multiple Domains (Hosted Domains)

The configuration program, csconfigurator.sh, configures only a single domain.

Workaround: If you need a multiple domain calendar environment (called either Virtual Domains or Hosted Domains), you must do two things:

Enable hosted domains.
Add the domains yourself using Delegated Administrator, or the csdomain utility if you are still using Sun LDAP Schema 1.

See Chapter 10, Setting Up a Multiple Domain Calendar Server 6.3 Environment, in Sun Java System Calendar Server 6.3 Administration Guide and Chapter 13, Administering Calendar Server Domains, in Sun Java System Calendar Server 6.3 Administration Guide.

Calendar Server Does Not Expire LDAP Cache Data

(Issue Number 4777792) Cache can fill up, causing errors. Calendar Server does not expire the LDAP cache data.

Workaround: Periodically remove contents of file. Then restart Calendar Server.

Must Enter Both Fully Qualified and Non-fully Qualified Host Names in Configuration File

The configuration file asks for the hostname twice. Once fully qualified and the second time not fully qualified. For example:

caldb.dwp.server.skate.red.sesta.com.ip = "skate.red.sesta.com" 
caldb.dwp.server.skate.ip = "skate" 
caldb.dwp.server.test12.red.sesta.com.ip = "test12.red.sesta.com" 
caldb.dwp.server.test12.ip = "test12"

Non-RFC Compliant Data in X-Tokens Must be Quoted

If there is non-RFC compliant data in an X-Token, it must be quoted. For example, a colon in an X-Token must appear as ":".

Users Not Validated Before Being Added as Secondary Owners.

The Calendar Server utility cscal does not validate users before adding them to the owners list as secondary owners.

Migration Utility Does Not Update Owners Calendars.

The Calendar Server migration utility csmig does not update icsSubscribed with the owners calendars.

Cannot Automatically Purge Obsolete Cached LDAP Data.

This must be done manually.

The enpd Process Crashes When Opening and Closing Connections Rapidly and Concurrently

The Event Notification Service has been deprecated. This will not be fixed. Use the Sun Java System Message Queue product in its place.

Events are Unexpectedly Deleted.

When a user modifies an event and chooses the option to modify today’s event and all future events, all previous events are deleted and will no longer display in the UI.

Cannot Use SSLv2 Client.

SSL initialization fails in SSLv2 mode. Unable to make use of SSLv2 client.

Calendar Utilities Fail If No DC Tree is Present.

For Schema 1, you must create the DC tree nodes prior to creating or otherwise managing calendars.

Calendar Server Utilities Send Vague Error Messages.

Error messages are vague because the error message originates several levels down and could be caused by many different circumstances. The next higher level program does not interpret the error message before bubbling it up to the level above it.

Leading White Space in Description Disappears When Stored.

If you start a description with a leading blank, the blank is not stored with the text and will not appear when the event is displayed.

Can't Enable or Disable SSL on a Per Domain Basis.

This is an RFE that has not been implemented for this release.

(Linux Only) Calendar Server Does Not Restart on Reboot.

Remaining lock files prevent it from restarting. Delete the lock files before restarting.

Lock files can be found in the following directory:

/opt/sun/calendar/lib/lock/__db.001

Events Between March 11, 2007 and April 1, 2007 Off by One Hour

By law the Daylight Savings Time changeover dates were changed. The Calendar Server 6.3 software contains the new corrected timezone tables. All events and tasks created going forward will have the correct times. However, the preexisting events and tasks that fall between the old and new changeover dates will be off by one hour. This problem occurs twice for each year you have in your calendar, once for the Spring Standard Time to Daylight Savings Time changeover, and again when the Fall Daylight Savings Time to Standard Time changeover occurs.

This is the same problem as problem number 6502376 described in Reported Problems in Calendar Server 6.3 , later in this document.

Fix:The standard fix for this problem is to allow users to adjust the times for any events in their calendars that are effected.

There is a fix program that technical support can supply by request.

Import of Calendar Data Only Works for Data from the Same `calid`

You can not use the import function to move data between calendars. It can only be imported into the same calendar (same calid) that it was exported from.

This limitation is the one documented as number 6461183 in the Reported Problems in Calendar Server 6.3 section of this document.

Reported Problems in Calendar Server 6.3

The following is a list of problems reported on the product:

4972249

For a hosted domain environment, csexport requires the calid to be fully qualified. For example, in the format uid@domain.

6244958

State file not created.

When csconfigurator.sh is called with the -saveState option, the state file specified doesn't include a path the state file is not created. For example:

/opt/sun/calendar/sbin/csconfigurator.sh -saveState cs.state

Workaround: Always specify the full path name, where the state file should be created.

6289810

Invitations Status by default should be “Accepted” for resource calendars.

Invitations Status by default should be "Accepted" for resource calendars. Since resource calendars cannot accept invitations, it is possible that users who are subscribed to resource calendars will not see these invitations (if users choose to view only accepted invitations in Communications Express->Options->Calendar view).

Workaround:The server level autoaccept is determined by the ics.conf parameter resource.invite.autoaccept = "yes". It can also be determined on a per resource level using the icsAutoaccept LDAP attribute.

6312605

Problem with recurring events.

Sending in dtstart and dtend parameters with non-date-field modifications (using storeevents) causes data corruption.

Workaround: Do not provide dtstart and dtend on modify store commands that require non date field modifications.

6377803

Note –

This was fixed for the GUI version of the configuration program only. For the command-line version, you must created the domain in Delegated Administrator before configuring Calendar Server.

6391883

After upgrading from Java ES 2005Q1, single sign-on using Access Manger does not work. For example, when you log in to the Portal Server desktop and then try to access the Calendar Server, the login page appears instead of being automatically authenticated through single sign-on.

Workaround:There is no workaround for this problem.

6393241

After upgrading a Calendar Server deployment that includes front-end and back-end installations, communicating using DWP, attempts to start the front-end installations fail, generating various errors in the log. This problem occurs because the cache directories were not copied to the new installation.

Workaround:Copy the cld_cache and ldap_cache directories from /var/opt/SUNWics5/csdb.old to /var/opt/SUNWics5/csdb. Then, set the owner and group of the new directories to icsuser and icsgroup.

6428959

Database log files accumulating in csdb.

The store daemon is not reading the correct configuration file parameter. It is looking for caldb.berkeley.*.enable which does not exist. It then takes the default for circular logging which is disabled. This also causes other troubles, including hot backup not to happen. The correct ics.conf parameter is caldb.berkeleydb.*.enable.

Workaround:Restart services. csstored takes care of the log accumulation problem by removing the accumulated log files.

6461183

Can not use export/import to move data between calendars with different calids. The data imported must have the same calid as the calendar you are importing to.

6470688

csrestore don't take care about personal user calendar.

After creating a personal calendar and successfully running a backup, manually delete the personal calendar. Then, restore the personal calendar using the restore command. From the log files, you can view that the calendar has been successfully restored. But, cannot be able to see or manage personal calendar when logging to the UWC or Calendar Express interface. The problem is that csrestore does not take care about the user LDAP entries, subscribed, or own calendar.

Workaround:Manually edit or delete the multi valued attribute, icsSubscribed for each user, which was deleted and restored using csrestore.

6479810

Session database corruption causing login failures and excessive session timeout messages.

Workaround:

Stop the services
Remove the session database
Start the services

6494811

There is no JMQ client bundled with Calendar Server packages. Use the JMQ client from the installed Messaging Server. Failing to install the JMQ client could result in abnormal termination of the admind process when JMQ is enabled.

Workaround:Copy the JMQ client from the Messaging Server bundle.

6502376

Calendar events off by 1 hour from March 11, 2007 to April 1, 2007

This happens because the dates for switching to Daylight Savings Time and back to Standard Time have been changed in order to extend the Daylight Savings Time period. The changeover dates now occur earlier in the Spring (March) and later in the Fall (November) than in earlier years. The timezone file distributed with Calendar Server 6.3 was updated to reflect these changes.

For Communications Express, which uses JVM timezone information instead of the Calendar Server timezone file, you must update your JVM to get the new timezone changes. Sun recommends using the latest Sun Java SE JDK/JRE update release as the preferred vehicle for delivering both timezone data updates and other product improvements such as security fixes. Use the JVM update program as described in the following document:

http://java.sun.com/javase/tzupdater_README.html

After your timezone information has been updated, events scheduled before the timezone update will show a one hour discrepancy for the days between the old and new changeover dates.

There is a fix executable available from technical support by request.

Another approach is to simply ask your users to update the times on their events that fall between the old and new changeover dates. Or, run your own script to process the database for those few events that need updating.

6503200

Location of LDAP tools have changed

If you have installed the earlier (beta) version of Java Enterprise System, you need to remove the SUNWldapcsdk-tools package prior to installing the released (RR) version of Java Enterprise System 5. This is due to the change in location of the SUNWldapcsdk-tools package in the released version. If you do not remove this package and try to start up Calendar or Messaging server after installing the released version, you will get the error message:

Could not find .../bin/ldapsearch utility
Please install the ldapcsdk-tools package

This error message is due to the change in the location of LDAP tools.

Workaround:Remove the SUNWldapcsdk-tools package prior to installing the released version of Java Enterprise System 5. To check the SUNWldapcsdk-tools version, run the command pkgparam -v SUNWldapcsdk-tools VERSION.

Note –

You must have a version that is 6.00,REV=2006.12.11.00.08 or later. Otherwise, you will get an error message that the LDAP search utility is not found.

Use the pkgrm SUNWldapcsdk-tools command, to remove the SUNWldapcsdk-tools package.

If you have already run the Java Enterprise System 5 installer, you can manually remove the SUNWldapcsdk-tools package and install it using the command:

cd <jes5_distro>/Solaris_sparc/Product/shared_components/Packages
  pkgadd -d . SUNWldapcsdk-tools

6505032

Can't start csmfagent server on Linux platform.

Calendar binaries can't locate the shared libraries for the Monitoring Framework on Linux version. The proper path for the monitoring framework files is: /opt/sun/mfwk/share/lib, but Calendar Server is expecting it to be in /opt/sun/calendar/lib.

Workaround:Add a symbolic link to the proper library in the Calendar Server library, as shown in the following example:

# cd /opt/sun/calendar/lib 
# ln -s /opt/sun/mfwk/share/lib/*.so .

Another way to do this is to start calendar services from the Monitoring Framework library, for example: /opt/sun/mfwk/share/lib

6516438

On Linux platform, after upgrading to Calendar Server 6.3, can't log in.

This is patched in Calendar Server 6.3 Upgrade 1, patch number 121658-17. For more information about this problem, see the following section of these Release Notes: Calendar Server Known Limitations.

6542989

When you use the configuration program to set up a back-end server, it erroneously places the IP Address, instead of the fully qualified host name, into the following parameter:

caldb.dwp.server.hostname.ip

You must edit the ics.conf file to correct the parameter value, otherwise the system can't find the back-end server. The correct value is the fully qualified host name of the back-end server.

6560681

The high availability package, SUNWcsics, requires some updates to work correctly. The package used in the Java Enterprise System software bundle is correct. Until a patch is available to fix this problem, you must use the following workaround:

Manually removed the SUNWcsics package from your Calendar Server distribution.
Do a pkgadd, using the SUNWcsics package from the Java Enterprise System software distribution.

Redistributable Files for Calendar Server

Sun Java System Calendar Server 6.3 contains the following set of files for which Sun Microsystems, Inc. grants you a non-exclusive, non-transferable, limited license to reproduce and distribute in binary form.

In addition, you may copy and use but not modify the listed header files and class libraries solely to cause your resulting binaries to be able to interface with Sun’s software APIs.

Sample code is provided solely for reference purposes pursuant to creating the above mentioned binaries.

All the redistributable files for Calendar Server are for the plug-in API, known as CSAPI. The API is described in the Sun Java System Calendar Server 6 2005Q4 Developer’s Guide at:

http://docs.sun.com/coll/1313.2

In the following files, cal-svr-base is the directory into which Calendar Server was installed. The default for Solaris is /opt/SUNWics5/cal , for Linux it is /opt/sun/calendar

Redistributable files are found in various subdirectories of cal-svr-base/csapi :

authsdk Redistributable Files

The following are the redistributable files in this subdirectory ( cal-svr-base/csapi/authsdk/):

cgiauth.c

expapi.h

login.html

nsapiauth.c

bin Redistributable Files

The following are the redistributable files in this subdirectory ( cal-svr-base/csapi/bin/):

libcsapi_xpcom10.so

libicsexp10.so

classes Redistributable Files

The following are the redistributable files in this subdirectory ( cal-svr-base/csapi/classes/):

ens.jar

jms.jar

include Redistributable Files

The following are the redistributable files in this subdirectory ( cal-svr-base/csapi/include/):

`IIDS.h`	`nsCom.h`	`nsMacRepository.h`
`csIAccessControl.h`	`nsDebug.h`	`nsProxyEvent.h`
`csIAuthentication.h`	`nsError.h`	`nsRepository.h`
`csICalendarDatabase.h`	`nsHashtable.h`	`nsString.h`
`csICalendarLookup.h`	`nsIAtom.h`	`nsTraceRefcnt.h`
`csICalendarServer.h`	`nsICaseConversion.h`	`nsVector.h`
`csIDBTranslator.h`	`nsICollection.h`	`nsUnicharUtilCIID.h`
`csIDataTranslator.h`	`nsID.h`	`nsXPComCIID.h`
`csIMalloc.hplugins`	`nsIEnumerator.h`	`nsXPComFactory.h`
`csIPlugin.h`	`nsIEventQueueService.h`	`nscore.h`
`csIQualifiedCalidLookup.h`	`nsIFactory.h`	`pasdisp.h`
`csIUserAttributes.h`	`nsIPtr.h`	`publisher.h`
`mozIClassRegistry.h`	`nsIServiceManager.h`	`subscriber.h`
`mozIRegistry.h`	`nsIServiceProvider.h`	`xcDll.h`
`nsAgg.h`	`nsISizeOfHandler.h`	`xcDllStore.h`
`nsCOMPtr.h`	`nsISupports.h`
`nsCRT.h`	`nsISupportsArray.h`

plugins Redistributable Files

This directory (cal-svr-base/csapi/plugins/) has redistributable files in the following subdirectories:

accesscontrol Redistributable Files

The following redistributable files are found in this subdirectory ( cal-svr-base/csapi/plugins/accesscontrol/ ):

csAccessControl.cpp

csAccessControl.h

csAccessControlFactory.cpp

authentication Redistributable Files

The following redistributable files are found in this subdirectory ( cal-svr-base/csapi/plugins/authentication/ ):

csAuthentication.cpp

csAuthentication.h

csAuthenticationFactory.cpp

datatranslator Redistributable Files

The following redistributable files are found in this subdirectory ( cal-svr-base/csapi/plugins/datatranslator/ ):

csDataTranslator.cpp

csDataTranslator.h

csDataTranslatorFactory.cpp

userattributes Redistributable Files

The following redistributable files are found in this subdirectory ( cal-svr-base/csapi/plugins/userattributes/ ):

csUserAttributes.cpp

csUserAttributes.h

csUserAttributesFactory.cpp

samples Redistributable Files

This directory (cal-svr-base/csapi/samples/) has redistributable files in the following subdirectories:

samples/authentication Redistributable Files

The following redistributable files are found in this subdirectory ( cal-svr-base/csapi/samples/authentication/ ):

authlogon.c

authlogon.h

authtest.c

csAuthenticationLocal.cpp

csAuthenticationLocal.h

csAuthenticationLocalFactory.cpp

samples/datatranslator Redistributable Files

The following redistributable files are found in this subdirectory ( cal-svr-base/csapi/samples/datatranslator/ ):

csDataTranslatorCSV.cpp

csDataTranslatorCSV.h

csDataTranslatorCSVFactory.cpp

samples/ens Redistributable Files

The following redistributable files are found in this subdirectory ( cal-svr-base/csapi/samples/ens/):

apub.c

asub.c

rpub.c

rsub.c

samples/userattributes Redistributable Files

The following redistributable files are found in this subdirectory ( cal-svr-base/csapi/samples/userattributes/ ):

csUserAttributesDB.cpp

csUserAttributesDB.h

csUserAttributesDBFactory.cpp