Migrating From Sun Java System Calendar Server 6 to Calendar Server 7

Skip to end of metadata
Go to start of metadata

Migrating From Sun Java System Calendar Server 6 to Oracle Communications Calendar Server

This functionality is available starting with Oracle Communications Calendar Server 7 Update 1.

Introduction to Migrating

Because the database formats differ between Calendar Server 6 and Oracle Communications Calendar Server (formerly known as Sun Java System Calendar Server 7), you need to migrate your Calendar Server 6 user data. That is, you cannot directly upgrade from Calendar Server 6 to Oracle Communications Calendar Server. Oracle Communications Calendar Server provides the davadmin migration utility to migrate the data.

The davadmin migration utility migrates all relevant Calendar Server 6 data and properties, including calendar data, invitations, ACLs, subscriptions, and so on. There is no migration or updating of LDAP data stored in the Directory Server. Instead, Calendar Server 6 calendar-related properties, such as notifications, previously stored in LDAP, are now stored in the Oracle Communications Calendar Server back-end database, which can be either MySQL Server or Oracle Database (as of Calendar Server 7 Update 2). For more information on how Calendar Server uses Directory Server, see Calendar Server and Directory Server Integration.

Note
Domain level ACLs are set in LDAP but using a different set of attributes and formats as described in Managing Domain Access Controls. The migration does not migrate domain level ACLs.

The migration does not check such items as event invitees, or event owners or delegated owners. The migration transfers whatever information is found in the LDAP directory to the Oracle Communications Calendar Server database. Additionally, if you migrate the same user multiple times, the user does not end up with duplicate events in the migrated calendar.

The calendar data migration process assumes the following conditions:

  • You can allow a reasonable amount of downtime to complete the migration.
  • You can perform a trial run to check results before doing the actual migration.
  • You can examine and fix events and todos that failed to migrate, by manually updating ics files and importing them.
    In general, when fixing and importing make sure the values that used to be "calid" are changed to their "mail" equivalent in all ics components.
  • Any updates to already scheduled events are not implicit after the migration.
  • If your deployment consists of multiple domains, ACIs are configured to enable the Calendar Server administrator ID, set by the service.siteadmin.userid configuration parameter (default is calmaster), for search and read access to non-default domains.
Note
You can also have a coexistent deployment of Calendar Server 6 and Calendar Server 7 hosts. For more information, see Creating a Calendar Server 6 and Calendar Server 7 Coexistent Deployment.

How the Migration Works

The migration utility performs the following sequence of events:

  1. Communicates with the Calendar Server 7 host by using the JMX protocol and invoking the AdminMigration process.
  2. Creates a log file for that migration task, which is returned to the davadmin client.
  3. The AdminMigration process invokes the Migration Service, which gets the list of users to be migrated from LDAP or passed in from the migration client, and builds a list of users.
  4. Starts a migration thread for each user in the list, until it reaches the serverlimits.maxmigrationthreads setting. Each migration thread then performs the migration. When done, each thread is reassigned a new user.
  5. Each migration thread uses the Migration HTTP client and authenticates to the Calendar Server 6 host by using the provided administrator settings and gets a session ID. This session ID is reused for all further WCAP requests to the Calendar server 6 host, for this particular user.
    1. First, the user's list of calendars and other preferences are fetched by using the get_userprefs command.
    2. For each of the user's calendars, the calendar properties are fetched using the (get_calprops) command.
    3. Then using the fetch_by_range command events/tasks uids and type, for the specified period are fetched.
      A map of the uids is made and individual fetches (fetch_event_by_id or fetch_todos_by_id) are done to get actual data. Fetch is done with the recurring=1 flag set, to get the master and exceptions as one record. This data is stored in the user's Calendar Server 7 back-end, as specified by the LDAP davStore attribute. The fetched data is massaged to fit the format for the Calendar Server 7 host before being stored. Different mapping helper functions perform the data massaging.
  6. The user's calendar is autocreated before adding any events or tasks. The fetched calendar properties are mapped and used to update the properties of the newly created calendar.
  7. The migration does not overwrite or duplicate any calendar data. When the migration service tries to write and finds an already existing calendar entry, it just ignores it and continues.
    Note
    If a calendar being migrated from Calendar Server 6 already exists on Calendar Server 7 because it was previously migrated or was explicitly created in Calendar Server 7, the migration resets the calendar's properties to that of the values of the original Calendar Server 6 calendar.
  8. Any failed event or task is logged, and the migration task continues.
  9. When migration is done, the calendar migration status is set in the migration log file, with more details on what was migrated.
  10. The migration steps are repeated for every calendar of the user.
  11. When done with one user, the migration thread removes the user from the user list map and picks up the next unmarked user in the list, if any.

Notes:

  • You migrate all accounts (users and resources) either by providing the migration command with the accounts' mail addresses, or by specifying the LDAP base and filter that finds the information on the users and resources in LDAP. Resource calendars are not migrated by just migrating the resource owner but by explicitly migrating the resource account itself.
    Resource Owner
  • In Calendar Server 7 Update 3, the migration sets the owner of a resource to the value of the primary owner. If the primary owner is not set, the migration uses the LDAP owner field. If there is no LDAP owner, the migration does not set an owner for the resource. (Bug 13942095)
  • An account cannot be partially migrated. The process migrates all calendars under that account, as well as subscription lists, calendar settings such as access controls, owner list, notification settings, freebusy settings, and so on.
  • Because subscription lists are migrated without checking if the calendars pointed to are migrated as well, some broken subscription links could result until all calendars have been migrated.
  • Calendar Server 7 Update 3 introduces a new configuration parameter, davcore.autocreate.rescalcomponents. It enables migrated resource calendars to allow the VEVENT and VTODO components that were permitted in Calendar Server 6. (The default value for this parameter is VEVENT.) To ensure that Calendar Server 6 resource calendars correctly have all their VEVENT and VTODO information migrated to Calendar Server 7, set this parameter to VEVENT VTODO before doing the migration, if your deployment has resource calendars that contain more than just events. For more information, see Calendar Server 7 Configuration Parameters.

High-Level Migration Steps for Administrators

Migrating from Calendar Server 6 to Oracle Communications Calendar Server involves the following high-level steps:

  1. Applying the most current Calendar Server 6 patch to fix migration-related issues
  2. Making a list of users to be migrated
  3. Informing users of migration window and down-time
  4. In a multiple domain deployment for LDAP Schema 1 environments, if not already done, configuring LDAP ACIs so that the Calendar Server administrator ID, set by the service.siteadmin.userid configuration parameter (default is calmaster), has search and read access to non-default domains
    For example:
    1. Ensure that the icsDomainNames: non-default domain attribute is added to the default domain in the dc tree.
    2. Ensure that the icsExtendedDomainPrefs: domainaccess=cal_svr_admin_id@defaultdomain^a^r^g attribute is added to the non-default domain in the dc tree.
  5. Setting the service.http.migrationcompatible parameter to yes (and restarting the Calendar Server)
  6. Readying the Calendar Server 7 deployment for migration by setting the required configuration options
  7. Running the populate-davuniqueid script to update users, groups, and resources in LDAP with the unique identifier attribute (populate-davuniqueid is available starting in Calendar Server 7 Update 3)
  8. Updating the LDAP attribute davStore for each user being migrated, to indicate which back-end Calendar Server 7 host to use
    Note
    Not setting this attribute means the back-end host is local to the Calendar Server 7 installation.
  9. Performing a backup of the user calendars that are being migrated
  10. Creating a file with list of mail addresses of users to be migrated or determining the LDAP filter to use
  11. Setting the Calendar server 6 host to "Read Only" mode as described in To Put a Database in Read-only Mode
  12. Migrating users by running the davadmin migration script and with the user list file created or the LDAP base and filter
    For more information, see davadmin migration. The default action for davadmin migration is migrate and so can be omitted.
  13. Verifying migration status
  14. For successfully migrated users, performing the following steps:
    1. Deleting Calendar Server 6 calendars by using cscal delete -o uid
    2. Setting the LDAP attribute icsAllowedServiceAccess to -http:all
  15. Fixing and importing any failure log files
  16. Notifying migrated users and informing them how to access the Calendar Server 7 deployment

Migrating From an SSL-enabled Calendar Server 6 Deployment

For a Calendar Server 7 host to communicate with a Calendar Server 6 host over SSL, the Calendar Server 7 host needs to have the Calender Server 6 host's certificate available. You do this by exporting the certificate from the Calendar Server 6 host and importing it into the Java runtime environment that is used by the Calendar Server 7 host.

  1. To export a certificate from a Calendar Server 6 host, run the following certutil command:

    where:

    alias_name Specifies the alias name of the certificate in the Calendar Server 6 Application Server NSS database
    CS6_config_directory Specifies the path to the Calendar Server 6 host's config directory
    CS6_certificate_file.rfc Specifies the path to the output file for the certificate
  2. Once you have the .rfc file, transfer it to the Calendar Server 7 host and import it into the Java runtime environment that is used by Calendar Server 7.
    The Java runtime file that holds the certificates is called cacerts. It should have a path similar to /usr/jdk/latest/jre/lib/security/cacerts. The import command used to update the cacerts file is:
      keytool -import -alias alias_name -keystore /usr/jdk/latest/jre/lib/security/cacerts -file CS6_certificate_file.rfc
  3. You must restart GlassFish Server for these changes to take affect.

Migration Logging

The davadmin migration command returns a log_tag string, which is is the path to the master_log file on the server host that contains the current state of that migration. The current state includes a list of migrated users and migration status. This master_log file is synchronously updated as the migration progresses.

The davadmin migration status -G log_tag command returns the contents of this master_log file and can be used to view the current state of the migration. You can also view the master_log file by using UNIX commands such as cat, tail, vi, and so on. The migration is finished when the last line in the master_log file is "Migration complete."

Here is an example log_tag string:

/var/opt/sun/comms/davserver/logs/davserver_migration/2010-06-29_153301/master_log

To view this file while the migration is in progress, you could use the following command:

The root of the directory tree that holds the migration information is davserver_migration and defaults to the Calendar Server 7 log directory. To store the migration information tree in a different location, use the -l option. This option tells davadmin where the directory should be placed. The structure of the davserver_migration tree is the following:

Migration Logging Root Directory
Time Stamp Named Directory
User Level Directory
Calendar Level Directory
Calendar Detail Information
davserver_migration        
  Migration time stamp for each migration
     
    master_log    
    Directory for each user being migrated
   
      Default calendar name
 
        calendar_log
        .ics files (if migration failed for any event or todo)
      Any secondary calendar name
 
        calendar_log
      trace_information  
        Files containing results of commands used to obtain old calendar data from the Calendar Server 6 host. Use this information to diagnose migration problems.

Under the davserver_migration directory is a time stamp named directory. This directory is created when you start a migration operation and the time stamp reflects when you started that migration.

The time stamp named directory contains the master_log file and a directory for each user being migrated.

The user's directory contains a directory for each of that user's calendars and a trace_information directory if the -c option was used on the command line. The trace_information directory contains files that show the results of commands issued to the Calendar Server 6 host.

Each calendar directory contains the calendar_log file and .ics files. The calendar_log contains information about the migration of that particular calendar. The .ics files contain the iCalendar data for any event/todo that failed to migrate. If a migration failed, you might be able to fix the iCalendar data in these .ics files and import them into the new calendar.

Set the Calendar Server 7 log level to FINE during migration, for easy detection of issues.

Use the -c or --capture flag to further debug issues that might come up during migration. Migration logging can be quite verbose and takes up lots of disk space.

How the Migration Reformats the Calendar Server 6 Data

To ensure that the Oracle Communications Calendar Server data store does not accept non-iCal compliant data, the migration program manipulates or reformats migrated data as follows.

  • Email alarms require a description and summary. If either or both are missing, a new value is constructed from the event or task's summary and added.
  • Display alarms require a description. If missing, a new value is constructed from the event or task's summary and added.
  • Organizer and attendee values are corrected to be valid mailto: URIs.
  • If an event's dtend is not after its dtstart, or if they are not of the same type (date only or timed), the bogus dtend is discarded and a new one is constructed. If dtstart has a date only value, the new dtend is one day after the dtstart. If the dtstart is a timed value, the new dtend is one hour after the dtstart.
  • If a todo has a dtstart that is after its due date, or if the value type of both properties do not match, the bogus dtstart is discarded. A new dtstart with the same value as due is added.
  • If a recurring todo has no dtstart, a new one is constructed and added. If due exists, the new dtstart is the same as due. If no due exists, dtstart is set to the current time.
  • If a priority field is missing, it is added for todos with attendees.
  • If dtstart is missing or is bogus, the relative alarm trigger values of todos, relative to due, are set.
  • Time strings in events and todos are converted from Zulu to values in their original timezones, and the relevant vtimezone information is included.
  • A new alarm attendee property is added for explicitly setting SMS alarms that were set by using the X-S1CS-SMS-EMAIL property.
  • Unending recurring series are truncated to a count specified by X-NSCP-RECURRENCE-BOUND in the Calendar Server 6 host, to retain the same recurrence behavior.
  • If dtend is before or equal to dtstart, it is discarded and a new one is created. For all day events, the new dtend is equal to dtstart plus 1 day. For timed events, the new dtend is equal to dtstart plus one 1 hour.

Troubleshooting the Migration

Topics in this section:

Count Reported by Tools Differs

The count reported by the Calendar Server 7 migration utility, for example, "Migrated 341 events in: jsmith," is different from the count reported by some Calendar Server 6 tools, such as csexport ("number of events=1436"). This difference occurs because most of the Calendar Server 6 tools report number of events in expanded mode (where each instance of a recurring event counts as one), while the migration utility reports the number of events in master plus exception mode.

No Events Migrated When The Calendar Contains Events

If your migration completed successfully but did not migrate events or tasks from a calendar that does contain events or tasks, check to see if the calmaster ID has permission to access the calendar events and tasks for that user.

For example, if user1 on Calendar Server 6.3 resembles the following:

# ./cscal -v list user1
user1@example.com: owner=user1@example.com status=enabled
...
number of events=27
number of tasks=0
number of deleted events=0
number of deleted tasks=0
number of deleted recurring events=0
number of deleted recurring tasks=0

but when migrated to Calendar Server 7 produces following:

# ./davadmin migration -u admin -a user1@example.com -X calmaster -L cs6server.example.com:80

[user1@example.com] Creating calendar user1 with name: null
[user1@example.com] Migrated 0 events and 0 tasks in: user1
[user1@example.com] Subscribed to
[user1@example.com] Migration completed successfully.

you should perform the following steps:

  1. On the Calendar Server 6.3 host, look in the http.log file log for entries similar to the following. Such entries indicate that the calmaster ID is denied access to user1's data:
    [20/Nov/2011:15:54:11 -0800] cs6server cshttpd[14567]: Account Information: login [123.10.10.10] calmaster plaintext sid=DCGF1veS5U8
    [20/Nov/2011:15:54:11 -0800] cs6server cshttpd[14567]: General Error: ac: Fetchcomponents: User "calmaster" denied access on fetching from calendar "user1".
    [20/Nov/2011:15:54:11 -0800] cs6server cshttpd[14567]: General Error: calstore_fetchcomponents_by_range(): call to ac_fetchcomponents() returning err = 13.
    [20/Nov/2011:15:54:11 -0800] cs6server cshttpd[14567]: General Error: calstore_fetchcomponents_by_range(): db error (pError->iErr) = 28.
    
  2. On the Calendar Server 6.3 host, check that the ics.conf file contains the following two parameters:
    service.siteadmin.userid
    service.virtualdomain.support
    
    1. For non-virtual domain data, the parameters should be set to the following values:
      service.virtualdomain.support = "no"
      service.siteadmin.userid="calmaster"
      

      Here, calmaster is an example. Use your site's Calendar Server administrator ID.

    2. For virtual domain data, the parameters should be set to the following values:
      service.virtualdomain.support = "yes"
      service.siteadmin.userid="calmaster@example.com"
      

      Again, calmaster@example.com is an example. Use your site's Calendar Server administrator ID.

  3. If the two Calendar Server 6.3 configuration parameter values are not consistent, then permission problems arise and the Calendar Server administrator ID is not allowed access to the calendars that are to be migrated.

To correct the problem:

  1. Change the Calendar Server 6.3 configuration parameters as previously described.
  2. Stop and restart calendar services on the Calendar Server 6.3 host.
  3. Rerun the migration.
  4. Check the migration output to verify that some number of events were migrated.
  5. Check the http.log file to ensure that the "denied access" messages no longer occur.

Exception on creation of userpref Error

If your migration produces intermittent errors similar to the following:

2010-04-23_155050/master_log:[zw127108@gotmail.example.com ] Exception on creation of userpref command for zw127108@gotmail.example.com : URI build exception: Invalid query

then rerun the migration for the failed user.

Back-end Error

If your migration produces errors similar to the following:

[user@host.example.com] Validation exception: backend throws an error (com.sun.comms.davserver.backends.BackendException: SQL error: Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.(INTERNAL_STORE_ERROR)) while doing nodeExists on  dav/home/user@host.example.com/calendar/dropbox/00000000000000000000000000000000405ce44e000063da0000003100004aa0/ while storing: 00000000000000000000000000000000405ce44e000063da0000003100004aa0

then you might need to do the following:

  1. Reduce the value of davcore.serverlimits.maxmigrationthreads.
    The default value is 2. Change the value to 2*(number of CPUs).
  2. Change the MySQL connection pool size.
    The default is 32. Change this value to  4*(number of threads). To change this value, edit the /etc/my.cnf and increase the MySQL max_connection setting, for example, max_connections = 200.

LDAP Error

If your migration using an LDAP filter produces an error like:

LDAP search failure: error result

then your filter might be too broad and you might be running into an LDAP search limit exceeded issue. Try narrowing down your filter.
For example, if your filter was:

./davadmin migration -u admin -X calmaster -L cs6.example.com:8080 -B "o=dirbase" -R "objectclass=icscalendaruser"

change it so that it resembles the following:

./davadmin migration -u admin -X calmaster -L cs6.example.com:8080 -B "o=dirbase" -R "(&(uid="a*")(objectclass=icscalendaruser))"

If you use this approach, you need to run multiple migration commands to complete the migration for the entire directory.

Read Timed Out Error

If your migration produces errors similar to the following:

2010-04-19_151418/master_log:[user@host.example.com] Exception on creation of http://host-cs.example.com:80: Read timed out

then you might need to increase the httpconnectiontimeout configuration options.

To do so, change the davcore.serverlimits.httpconnecttimeout and davcore.serverlimits.httpsockettimeout options by using the davadmin config command.

Error Parsing iCal Data

If your migration produces errors similar to the following:

then you need to fix the line giving the error in the ics file located in the migration directory and import it.

You can use either the davadmin import or client import commands to import the file.

The following examples provide other potential errors of this type.

Error Parsing iCal Data Example 1

Error Parsing iCal Data Example 2

Error Parsing iCal Data Example 3

.

Owner Property Error

If the migration log shows the message "FAILED TO SET OWNER PROPERTY" when migrating a resource, there might be a problem with the "other owners" of the resource that you are migrating. A known issue with the Calendar Server 6 csresource create command could have caused the "other owners" field to be created incorrectly.

If you did the migration using the -c option, the log directory contains a trace_information directory for the resource. In the trace_information directory, search the getcalprops* file for the X-NSCP-CALPROPS-OWNERS line. If this line contains a comma separated list of users, these "other users" were set up incorrectly in Calendar Server 6. There should be one X-NSCP-CALPROPS-OWNERS line for each of the "other owners" for the resource.

If this is the case, correct the problem as follows:

  1. Change the "other owners" by using the Calendar Server 6 cscal command with the -y option and space delimited user names.
    For example:

    The first command clears out the "other owners" field and the second sets it correctly.

  2. On Calendar Server 7, delete the account that you migrated and run the migration again.

Other Migration Errors

The section describes possible migration errors that you need to individually fix and import. The failed ics files are located under the calendar subdirectory for individual users. Fix then import these files either by using the davadmin import command or by having the end users import their own files. In general, when fixing and importing make sure the values that used to be "calid" are changed to their "mail" equivalent in all ics components.

Topics in this section:

Multiple Components with the Same uid but Different Date Type: DATETIME_WITH_TZ, DATETIME_UTC

This error happens if two separate events or tasks end up with the same uid and the dtstart/dtend types do not match. Separate out the events into two separate ics files and import.

For example, this event:

BEGIN:VCALENDAR^M
PRODID:-//Sun/Calendar Server//EN^M
METHOD:PUBLISH^M
VERSION:2.0^M
X-NSCP-CALPROPS-LAST-MODIFIED:20031101T061300Z^M
X-NSCP-CALPROPS-CREATED:20010418T022506Z^M
X-NSCP-CALPROPS-READ:999^M
X-NSCP-CALPROPS-WRITE:999^M
X-NSCP-CALPROPS-RELATIVE-CALID:user@example.com^M
X-NSCP-CALPROPS-NAME:Business^M
X-NSCP-CALPROPS-PRIMARY-OWNER:user@example.com^M
X-NSCP-CALPROPS-TZID:America/New_York^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@@o^c^wdeic^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@@o^a^rsf^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@^a^^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@^c^^g^M
X-NSCP-CALPROPS-RESOURCE:0^M
X-S1CS-CALPROPS-ALLOW-DOUBLEBOOKING:1^M
X-NSCP-WCAP-ERRNO:0^M
BEGIN:VEVENT^M
UID:3bcdec24000054d40000000d00000db5^M
DTSTAMP:20100503T225631Z^M
SUMMARY: Meeting^M
CREATED:20011029T161741Z^M
LAST-MODIFIED:20091009T200936Z^M
PRIORITY:0^M
SEQUENCE:0^M
CLASS:PUBLIC^M
STATUS:CONFIRMED^M
TRANSP:OPAQUE^M
RRULE:FREQ=MONTHLY;WKST=MO;COUNT=41;INTERVAL=1;BYDAY=1FR^M
DTSTART;TZID=America/New_York:20011102T083000^M
DTEND;TZID=America/New_York:20011102T123000^M
X-S1CS-RECURRENCE-RDATELIST:20020405T133000Z^M
.....
END:VEVENT^M
BEGIN:VEVENT^M
UID:3bcdec24000054d40000000d00000db5^M
RECURRENCE-ID:20020405T133000Z^M
DTSTAMP:20100503T225631Z^M
SUMMARY:A Bday^M
DTSTART;VALUE=DATE:20020410^M
DTEND;VALUE=DATE:20020411^M
CREATED:20011017T203756Z^M
LAST-MODIFIED:20091009T200335Z^M
PRIORITY:0^M
SEQUENCE:0^M
CLASS:PUBLIC^M
STATUS:CONFIRMED^M
TRANSP:TRANSPARENT^M
X-NSCP-ORIGINAL-DTSTART:20020405T133000Z^M
X-NSCP-LANGUAGE:en^M
X-NSCP-DTSTART-TZID:America/New_York^M
X-NSCP-TOMBSTONE:0^M
X-NSCP-ONGOING:0^M
X-NSCP-GSE-COMPONENT-STATE;X-NSCP-GSE-COMMENT=REQUEST-COMPLETED:131074^M
END:VEVENT^M
....

END:VCALENDAR

can be split to the first master event with its timed exceptions and a new master event for the all day event:

BEGIN:VCALENDAR^M
PRODID:-//Sun/Calendar Server//EN^M
METHOD:PUBLISH^M
VERSION:2.0^M
X-NSCP-CALPROPS-LAST-MODIFIED:20031101T061300Z^M
X-NSCP-CALPROPS-CREATED:20010418T022506Z^M
X-NSCP-CALPROPS-READ:999^M
X-NSCP-CALPROPS-WRITE:999^M
X-NSCP-CALPROPS-RELATIVE-CALID:user@example.com^M
X-NSCP-CALPROPS-NAME:Business^M
X-NSCP-CALPROPS-PRIMARY-OWNER:user@example.com^M
X-NSCP-CALPROPS-TZID:America/New_York^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@@o^c^wdeic^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@@o^a^rsf^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@^a^^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@^c^^g^M
X-NSCP-CALPROPS-RESOURCE:0^M
X-S1CS-CALPROPS-ALLOW-DOUBLEBOOKING:1^M
X-NSCP-WCAP-ERRNO:0^M
BEGIN:VEVENT^M
UID:3bcdec24000054d40000000d00000db5^M
RRULE:FREQ=YEARLY
DTSTAMP:20100503T225631Z^M
SUMMARY:Camille Bday^M
DTSTART;VALUE=DATE:20020410^M
DTEND;VALUE=DATE:20020411^M
CREATED:20011017T203756Z^M
LAST-MODIFIED:20091009T200335Z^M
PRIORITY:0^M
SEQUENCE:0^M
CLASS:PUBLIC^M
TRANSP:TRANSPARENT^M
X-NSCP-LANGUAGE:en^M
X-NSCP-TOMBSTONE:0^M
X-NSCP-ONGOING:0^M
X-NSCP-GSE-COMPONENT-STATE;X-NSCP-GSE-COMMENT=REQUEST-COMPLETED:131074^M
END:VEVENT^M
END:VCALENDAR

Failed to store component: F0095280-BC13-11D9-81F6-000A958EAC78: validation error: PERCENT-COMPLETE with invalid value: -1

Edit PERCENT-COMPLETE to be between 0 and 100.

Error parsing ical data for: 3d6cd576000000a70000000a00000a55: failed to parse - Error at line 52:Illegal character in opaque part at index 27: MAILTO:user.one@example.com\n

Remove the trailing {{n} character or any other character that would be illegal in an email address.

Failed to store component: 9DE4F2DA-D020-11D8-9530-000A958A3252: validation error: Calendar must contain at least one component

In this case, the ics file resembles the following:

BEGIN:VCALENDAR^M
PRODID:-//Sun/Calendar Server//EN^M
METHOD:PUBLISH^M
VERSION:2.0^M
X-NSCP-CALPROPS-LAST-MODIFIED:20031101T061545Z^M
X-NSCP-CALPROPS-CREATED:20030916T095049Z^M
X-NSCP-CALPROPS-READ:999^M
X-NSCP-CALPROPS-WRITE:999^M
X-NSCP-CALPROPS-RELATIVE-CALID:user@example.com^M
X-NSCP-CALPROPS-NAME:User One^M
X-NSCP-CALPROPS-LANGUAGE:en^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@@o^a^r^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@@o^c^wdeic^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@^a^sf^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@^c^\^g^M
X-NSCP-CALPROPS-ACCESS-CONTROL-ENTRY:@^p^r^g^M
X-NSCP-CALPROPS-RESOURCE:0^M
X-S1CS-CALPROPS-ALLOW-DOUBLEBOOKING:1^M
X-NSCP-WCAP-ERRNO:59^M
END:VCALENDAR^M

You may ignore the file as the event does not exist any longer.

Failed to store component: 00000000000000000000000000000000473defae0000696e000001460000129f: validation error: master is non recurring

Construct an RRULE property and add it to the master component.

Failed to store component: 9708780fccab40f18ace29226ef42a8e: validation error: failed to parse - Error at line 84:Illegal character in scheme name at index: =BASE64;VALUE=BINARY;X-S1CS-FILESIZE=49665:ATTACHFMTTYP//MESSAGE/OLEXS1CSATTACHIAAA007110202XS1CSCLIENTIAAAec798b438d5469da5af862534819cf2XS1CSFILENAME/ENCODIN//BASE64VALU//BINARYXS1CSFILESIZ//40AAAA

This error occurs when the attachment is missing. Edit the file and remove the line with the ATTACH property.

Error parsing ical data for: F0076B82-BC13-11D9-81F6-000A958EAC78: failed to parse - Error at line 51:[EXDATE] Unparseable date: "20000220"

This should not happen as long as the Calendar Server 6 host is patched with the most current Calendar Server patch. However, it you do see this error, edit the EXDATE property line and add VALUE=DATE EXDATE;VALUE=DATE:20000220.

Labels:
caldavserver caldavserver Delete
migrating migrating Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 05, 2012

    The defaults for davcore.serverlimits.httpconnecttimeout and davcore.serverlimits.httpsockettimeout are 5000ms. What should you set this to if you are getting timeout errorshttps://wikis.oracle.com/display/CommSuite/Migrating+From+Sun+Java+System+Calendar+Server+6+to+Calendar+Server+7?showComments=true&showCommentArea=true#MigratingFromSunJavaSystemCalendarServer6toCalendarServer7-ReadTimedOutError

    1. Sep 05, 2012

      It depends on the deployment. We have had to up it to 20000 in our stress tests.

  2. Sep 05, 2012

    Is there a way with davadmin migration to migrate everything from cs 6 to cs7 without having to specify the email addresses?

    1. Sep 06, 2012

      Use an LDAP filter as shown in the example./davadmin migration -u admin -X calmaster -L cs6.example.com:8080 -B "o=dirbase" -R "(&(uid="a*")(objectclass=icscalendaruser))"

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.