The section describes the following tips and trouble shooting examples:
A calendar named tchang:myCalendar has the owner jsmith in the calendar database, and the csmig dry run shows the mapping as jsmith:tchang_myCalendar. However, you would like to name this calendar tchang:myCalendar and assign the owner as tchang.
Before the migration, use the cscal utility to change the owner of the calendar tchang:myCalendar to tchang. Once this is done, the migration will map this calendar to tchang:myCalendar and add icsCalendarowned to the LDAP entry for user ID tchang.
After migration, the LDAP calendar search is enabled, but the calendar search dialog does not return any results or returns only partial results.
Enabling the LDAP calendar search allows Calendar Server to search (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)).
Manually run two different searches on the LDAP data with the following filters and compare the output:
LDAP search with filter (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))
LDAP search with filter (icscalendarowned=*substr*)
Since the server uses the filter that includes icsCalendarUser object class, the LDAP server might have been deployed with the schema check disabled, and some calendar entries may have been provisioned without the icsCalendarUser object class.
The csmig dry run mapping file and output file indicate that there is a duplicate calendar name. For example, in the original database, jsmith owns the following calendars:
basketball with 5 events
jsmith:basketball with 10 events
The dry run indicates that during a migration, the two calendars will be merged, and the resulting calendar will be jsmith:basketball with owner jsmith and 15 total events
The output file will include the following warning message:
Error modifying calendar properties, error=2
If you don’t want the two calendars to be merged, change the owner of basketball to a user other than jsmith before the migration. This will preserve the data integrity of the two separate calendars.
By default csmig assigns all orphan calendars to a single owner, but I would like to assign different owners for some orphan calendars.
csmig doesn’t accept the mapping file in the command line. However, you can assign owners to the orphan calendars in the original database before the migration. Check the dry run mapping file for all orphan calendars. Then use the cscal utility to assign owners to the orphan calendars before the migration. Run csmig in dryrun mode again to verify the new owners.
How do I move users from one back-end server to another?
To move a calendar user, you export each of the user’s calendars on the original server and then import the calendars on the second server. After the calendars are moved, you can delete the calendars on the original server. For instructions on how to move calendars, see Managing User Calendars.