| Oracle® Communications Calendar Server Installation and Configuration Guide Release 7.0.5 E54934-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Calendar Server Installation and Configuration Guide Release 7.0.5 E54934-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how to migrate from Sun Java Calendar Server 6 to Oracle Communications Calendar Server 7.
Because the database formats differ between Calendar Server 6 and Oracle Communications Calendar Server (formerly known as Sun Java System Calendar Server 7), you must migrate your Calendar Server 6 user data. That is, you cannot directly upgrade from Calendar Server 6 to Oracle Communications Calendar Server. You use the Oracle Communications Calendar Server davadmin migration command to migrate the data.
The davadmin migration command 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. For more information on how Calendar Server uses Directory Server, see the topic on Calendar Server and Directory Server integration in Calendar Server Concepts.
Note:
Domain level ACLs are set in LDAP but using a different set of attributes and formats as described in Calendar Server Security Guide. The migration does not migrate domain level ACLs.The migration does not check such items as event invitees, 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 7 Coexistent Deployment."The migration utility performs the following sequence of events:
Communicates with the Calendar Server 7 host by using the JMX protocol and invoking the AdminMigration process.
Creates a log file for that migration task, which is returned to the davadmin client.
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.
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.
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.
First, the user's list of calendars and other preferences are fetched by using the get_userprefs command.
For each of the user's calendars, the calendar properties are fetched by using the get_calprops command.
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 database, 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.
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.
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.Any failed event or task is logged, and the migration task continues.
When migration is done, the calendar migration status is set in the migration log file, with more details on what was migrated.
The migration steps are repeated for every calendar of the user.
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.
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.
The configuration parameter, davcore.autocreate.rescalcomponents, 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 configuration parameters in Calendar Server System Administrator's Guide.
Migrating from Calendar Server 6 to Calendar Server 7 involves the following high-level steps:
Applying the most current Calendar Server 6 patch to fix migration-related issues.
Making a list of users to be migrated.
Informing users of migration window and down-time.
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:
Ensure that the icsDomainNames:non-default domain attribute is added to the default domain in the dc tree.
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.
Setting the service.http.migrationcompatible parameter to yes (and restarting the Calendar Server).
Readying the Calendar Server 7 deployment for migration by setting the required configuration options.
Running the populate-davuniqueid script to update users, groups, and resources in LDAP with the unique identifier attribute.
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.Performing a backup of the user calendars that are being migrated.
Creating a file with the list of mail addresses of users to be migrated or determining the LDAP filter to use.
Setting the Calendar Server 6 host to "Read Only" mode as described in "To Put a Database in Read-only Mode" in Sun Java System Calendar Server 6.3 Administration Guide.
Migrating users by running the davadmin migration script and with the user list file created or the LDAP base and filter.
The default action for davadmin migration is migrate and so can be omitted.
Verifying migration status.
For successfully migrated users, performing the following steps:
Deleting Calendar Server 6 calendars by running cscal delete -o uid.
Setting the LDAP attribute icsAllowedServiceAccess to -http:all.
Fixing and importing any failure log files.
Notifying migrated users and informing them how to access the Calendar Server 7 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 Calendar 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.
To export a certificate from a Calendar Server 6 host, run the following certutil command:
certutil -L -a -n alias_name -d CS6_config_directory > CS6_certificate_file.rfc
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
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
Restart Oracle GlassFish Server for these changes to take affect.
The davadmin migration command returns a log_tag string, which 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 -Glog_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, use the following command:
tail -f /var/opt/sun/comms/davserver/logs/davserver_migration/2010-06-29_153301/master_log
The root of the directory tree that holds the migration information is davserver_migration and defaults to the Calendar Server log directory. To store the migration information tree in a different directory, use the -l option.
Under the davserver_migration directory is a directory named by a time stamp. This directory is created each time that 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 migrated.
The user's directory contains a directory for each of that user's calendars, including the default calendar and any secondary calendars. The user's directory also contains 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. Use this information in these files to diagnose migration problems.
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 or 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.
To ensure that the 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.
Topics in this section:
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.
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 the 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:
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.
On the Calendar Server 6.3 host, check that the ics.conf file contains the following two parameters:
service.siteadmin.userid service.virtualdomain.support
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.
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.
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:
Change the Calendar Server 6.3 configuration parameters as previously described.
Stop and restart calendar services on the Calendar Server 6.3 host.
Rerun the migration.
Check the migration output to verify that some number of events were migrated.
Check the http.log file to ensure that the "denied access" messages no longer occur.
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.
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:
Reduce the value of davcore.serverlimits.maxmigrationthreads.
The default value is 2. Change the value to 2*(number of CPUs).
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.
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 must run multiple migration commands to complete the migration for the entire directory.
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.
If your migration produces errors similar to the following:
2010-04-20_094910/master_log:user@host.example.com Error parsing ical data for : 00000000000000000000000000000000486c05b900001c6b000001c400000532: failed to parse - Error at line 48:Illegal character in opaque part at index 27: user1@varrius.com\,user@example.com\,user1_smith@varrius.com
then you must 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.
For Error at line 32:I illegal character in scheme name at index 6: mailto\:mattp@example.com Change value to mailto:mattp@example.com
For Error at line 38:I llegal character in scheme name at index 6: mailto\:mailto\\\\\\\:mailto\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\:mailto\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\:ms104926@iplanet.com Change value to mailto:ms104926@iplanet.com
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:
Change the "other owners" by using the Calendar Server 6 cscal command with the -y option and space delimited user names.
For example:
./cscal modify -y "" uid ./cscal modify -y "1st owner 2nd owner ..."
The first command clears out the "other owners" field and the second sets it correctly.
On Calendar Server 7, delete the account that you migrated and run the migration again.
The section describes possible migration errors that you must 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
Failed to store component: F0095280-BC13-11D9-81F6-000A958EAC78
Error parsing ical data for: 3d6cd576000000a70000000a00000a55: failed to parse
Failed to store component: 9DE4F2DA-D020-11D8-9530-000A958A3252
Failed to store component: failed to parse - Error at line 84
Error parsing ical data for: F0076B82-BC13-11D9-81F6-000A958EAC78
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
validation error: PERCENT-COMPLETE with invalid value: -1
Edit PERCENT-COMPLETE to be between 0 and 100.
Error at line 52: Illegal character in opaque part of 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.
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.
00000000000000000000000000000000472defae0000696e000001460000129f: validation error: master non recurring
Construct an RRULE property and add it to the master component.
Illegal character in scheme name at index: =BASE64;VALUE=BINARY;X-SICS-FILESIZE=49665:ATTACHFMTTYP//MESSAGE/OLEXS1CSATTACHIAAA007110202XS1CSCLIENTIAAAec798b438d5469da5af862534819cf2XS1CSFILENAME/ENCODEIN//BASE64VALU//BINARYXS1CSFILESIZ/40AAAA
This error occurs when the attachment is missing. Edit the file and remove the line with the ATTACH property.
failed to parse - Error at line 52: [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.
|
 Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
