Sun Java Communications Suite 5 Release Notes

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

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.