csmig migrates both user and resource calendars in the current calendar database (*.db files) specified by the caldb.berkeleydb.homedir.path parameter. In the new destination target database, csmig updates entries required by the LDAP CLD plug-in in the calendar properties (calprops), events, todos (tasks), and group scheduling engine (GSE) database files.
csmig writes only to the destination target database; it does not update your existing calendar database.
csmig assigns an owner to each calendar in the calendar database and maps each calendar ID (calid) to an owner, if needed. All default calids are kept as is, and no changes are made. Other calendars are mapped as follows:
User calendars that don’t have valid owners will be owned by the user passed to csmig by the -c option. For example, if calendar ID jsmith doesn’t have an owner, it will be converted to orphan:jsmith, where orphan is specified as the -c option.
Resource calendars that don’t have an owner will be owned by the resource user passed to csmig by the -r option.
If a resource calendar has any colons (:) in the name, the colons are converted to underscores, so that the migrated name has only one colon.
For example, a calendar named football with owner bkamdar will be converted to bkamdar:football. A calendar named tchang:soccer with the owner bkamdar will be converted to bkamdar:tchang_soccer. A resource calendar named auditorium:room1 with an owner admin1 will be converted to admin1:auditorium_room1.
csmig updates LDAP attributes for all relevant LDAP entries, including icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet, and for resource calendars, uid. csmig creates the icsDWPHost attribute for each calendar in the LDAP directory server database. icsDWPHost specifies the host name of the back-end server where a calendar resides.