Reported Problems in Calendar Server 6.3 (Sun Java Communications Suite 5 Release Notes)

Sun Java Communications Suite 5 Release Notes

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

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.

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.