Sun ONE logo     Previous     Contents     Index     Next     
Sun ONE Calendar Server Installation Guide



Chapter 4   Migrating Calendar Server Data


This chapter describes the following Sun™ ONE Calendar Server 5.1.1 migration utilities:


ics2migrate Migration Utility

The ics2migrate migration utility can migrate both Calendar Server 2.x calendar data and LDAP user preferences to Calendar Server 5.1.1.

This section describes:

The migration from Calendar Server 2.x to 5.x is a one-way migration. You can migrate data from version 2.x to 5.1, but you cannot migrate version 5.x data to 2.x.

Migration Requirements

Calendar Server 2.x to 5.x migration requires the following hardware and software:

  • The source machine has the Calendar Server 2.x data that you plan to migrate.

  • The target machine is where the migrated data will be created. This machine must have Calendar Server 5.0 patch 4 (or later) installed.

    ics2migrate.exe. is located in the server-root\cal\bin directory.

The source machine and destination machine can be different servers or the same server. The following platforms are supported:

  • Solaris 2.6 (5.6) Operating Environment (or newer)

  • Windows NT 4.0 with Service Pack 6a

What Gets Migrated?

The following table lists the Calendar Server 2.x data and describes how ics2migrate migrates the data to Calendar Server 5.x.


Table 4-1    Migration of Calendar Server 2.x Data

Calendar Server 2.x Data

Migration Results for Calendar Server 5.x

Calendar Properties (calprops)    

Updates the Calendar Server calprops database.  

Events  

Updates the Calendar Server events database.  

Todos  

Updates the Calendar Server todos database  

Alarms  

Updates the alarms database while writing events and todos.  

The following table lists the Calendar Server 2.x LDAP attributes and describes how ics2migrate migrates the attributes to Calendar Server 5.x.


Table 4-2    Migration of LDAP Attributes 

Calendar Server 2.x LDAP Attribute

Calendar Server 5.x LDAP Attribute

nswcalUser *  

icsCalendarUser *  

nswcalCalID  

icsCalendar  

nswcalExtendedUserPrefs    

icsExtendedUserPrefs  

ceCalList **  

icsSubscribed  

ceAgendaList **  

icsSet  

ceDefaultAgenda **  

icsDefaultSet  

ceDefaultTZID **  

icsTimeZone  

ceFirstDayWeek **  

icsFirstDay  

* Objectclass

** Originally part of nswcalExtendedUserPrefs

Migration Process


Caution

Before you migrate, backup both your Calendar Server 2.x and 5.x calendar databases.


Prepare to Migrate

Follow these steps to prepare to migrate your data:

  1. On the target machine where Calendar Server is installed, log in as a user who has administration rights to the system:

    • On Solaris machines, log in as (or become) root, or as the user and group under which the Calendar Server is running that was specified during installation (such as icsuser and icsgroup).

    • On Windows NT machines, log in as an administrator with full administrator privileges.

  2. Locate the Calendar Server 2.x caldb.conf file. The default directory for this file depends on your platform:

    • Solaris machines: /var/opt/SUNWicsrv/csdb

    • Windows NT machines: server-root\var\csdb

  3. Change the first line in the caldb.conf file as follows:

    Old value:   caldb.version "1.0.0 [BerkeleyDB]"

    New value:   caldb.version= "1.0.0 [BerkeleyDB]"

  4. To ensure data integrity, stop all services for both Calendar Server 2.x and 5.x. For more information, see the respective Sun ONE Calendar Server Administrator's Guide on the documentation web site.

Migrate the Data

Follow these steps to migrate your data:

  1. Change to the server-root\cal\bin directory where ics2migrate.exe is located.

  2. Run ics2migrate using the following syntax:


To migrate both the Calendar Server 2.x database and LDAP user preferences

ics2migrate [-q] [-s def|none] [-f def|none] [-l min|max] source target


To migrate only the Calendar Server 2.x database

ics2migrate [-q] [-m db] [-s def|none] [-f def|none] [-l min|max] source target


To migrate only the LDAP user preferences

ics2migrate [-q] [-m ldap]


Note To display the syntax, type ics2migrate without any options.


Table 4-3 lists the ics2migrate options with a description of each option.


Table 4-3    ics2migrate Options 

ics2migrate Option

Description

[-q]  

Run in quiet mode. If the migration is successful, ics2migrate does not display information on the console. If the migration fails, ics2migrate displays only errors.

The default is verbose mode.  

[-m db|ldap]  

db - Migrate only the calendar database.

ldap - Migrate only the LDAP user preferences.

The default is to migrate both the calendar database and LDAP user preferences.  

[-s def|none]  

def - Grant scheduling access to only a user's default calendar.

none - Deny scheduling access to all users' calendars.

The default is to grant scheduling access to all calendars.  

[-f def|none]  

def - Grant free/busy access to only a user's default calendar.

none - Deny free/busy access to all users' calendars.

The default is to grant free/busy access to all calendars.  

[-l min|max]  

min - Log the minimum data migration statistics: calendar ID, primary owner, and number of events and todos for each calendar.

max - Log the maximum data migration statistics: minimal statistics plus the number of attendees and alarms for each event and todo.

ics2migrate logs statistics to ics2migrate.log in the server-root\cal\bin directory.

By default, ics2migrate displays migration statistics on the console and does not generate a log file.  

source  

Directory where the Calendar Server 2.x database files are located.

source is required for database migration if the -m db option is specified, or if the -m option is omitted.  

target  

Directory where the Calendar Server 5.1 database files are located.

target is required for database migration if the -m db option is specified, or if the -m option is omitted.  

Check the Migration Results

After you have finished the migration, check the results:

  • Check the ics2migrate.log file in the server-root\cal\bin directory for the following messages (depending on your migration choices):

    Database migration successfully completed
    LDAP user preference migration successfully completed

  • If you suspect a possible database corruption, run the csdb utility check command.

    The check command scans a calendar database for corruption. If the check command finds an inconsistency that cannot be resolved, it reports the situation in its output. If necessary, you can then run the csdb utility rebuild command to rebuild the calendar database (caldb).

    For documentation about the csdb utility check and rebuild commands, see the Sun ONE Calendar Server Administration Guide on the documentation web site.

Migration Examples

Migrate Both Calendar Database and LDAP User Information

Migrate both the LDAP user information and the Calendar Server 2.x database. The Calendar Server 2.x database is stored in the /var/opt/SUNWicsrv/2x_db directory and the 5.1 database is in the /var/opt/SUNWics5/50_db directory.

Grant scheduling and free/busy access to all calendars and log minimal migration statistics in a log file named ics2migrate.log in the server-root\cal\bin directory.

ics2migrate /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db -l min

Migrate in Quiet Mode

Perform the same migration as the previous example, except operate in quiet mode. ics2migrate does not display migration statistics on the console or generate a log file.

ics2migrate -q /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db

Migrate Only the Calendar Database

Migrate only the 2.x calendar database stored in the 2x_db directory (relative to the current directory) and create a 5.1 database in the /var/opt/SUNWics5/50_db directory.

ics2migrate -m db 2x_db /var/opt/SUNWics5/50_db

Migrate Only LDAP User Information

Migrate only the Calendar Server 2.x LDAP user information to version 5.1 format.

ics2migrate -m ldap

Migrate Both Calendar Database and LDAP User Information

Migrate both LDAP and calendar database information in the specified directories. Grant scheduling access only to each user's default calendar, deny free/busy access to all calendars on the server, and do not generate statistical information to a log file.

ics2migrate -s def -f none 2x_db 50_db


ncs4migrate Migration Utility

This section describes how to migrate Netscape Calendar Server 4.x calendar data to Sun ONE Calendar Server using the ncs4migrate migration utility.

Netscape Calendar Server 4.x calendars are also known as CS&T calendars for the developer Corporate Software & Technologies Int. Inc.

If you need a copy of the ncs4migrate utility, contact your Sun technical support representative or account manager. When you get ncs4migrate copy it to your server-root\cal\bin directory.

This section includes the following information:

Migration Requirements

The migration requires the following hardware and software:

  • Source machine — This machine (or machines) has the Netscape Calendar Server 4.0 (or later) data that you plan to migrate.

  • Target machine — This machine has the Calendar Server 5.0 database that you plan to migrate to. It should be running Calendar Server 5.0 Patch 4 (or newer).

The source machine and target machine can be different servers or the same server. The following platforms are supported:

  • Solaris 2.6 (5.6) or later Operating Environment

  • Windows NT 4.0 with Service Pack 6a

What Gets Migrated?

The following table shows how ncs4migrate migrates Netscape Calendar Server data to Calendar Server 5.0.

Table 4 Migration of Netscape Calendar Server 4.0 Data 



Netscape Calendar Server 4.0 Data Item

Calendar Server 5.0 Migration Results

Meetings, events, and notes of resources and users  

Migrated as events.  

Tasks  

Migrated as todos (tasks).  

Access (security) rights  

Ignored during migration. Designates and Designate Rights are not migrated.

For user's calendars and resource calendars, ncs4migrate uses the access control strings in the ics.conf file as follows:

For user's calendars, ncs4migrate uses calstore.calendar.default.acl and sets the privacy settings in the Calendar Server 5.0 calendar as:

  • Calendar owner: Availability, Schedule, Read, Delete, and Modify

  • All other users: Availability and Schedule

For resource calendars, ncs4migrate uses resource.default.acl and sets the privacy settings in the Calendar Server 5.0 calendar as:

  • Resource owner: Availability, Schedule, Read, Delete, and Modify

  • All other users: Availability, Schedule, and Read

For a description of privacy settings and how to change them, see the Calendar Express online Help.

Note Before you migrate, check the strings in the ics.conf file to make sure they are correct as follows:

The correct string for calstore.calendar.default.acl is:

@@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g;@^c^^g

The correct string for resource.default.acl is:

@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g;@^c^^g  

File attachments  

Ignored during migration; warning is generated in log file.  

Groups  

Not migrated.  

Migration Steps

Backup the Calendar Server 5.0 Database

Before you migrate, it is recommended that you perform these steps to ensure the integrity of your calendar database:

  1. Backup your calendar database using the csbackup utility (or another backup utility).

    For information about csbackup, see the Sun ONE Calendar Server Administrator's Guide.

  2. Run the csdb utility check command on your calendar database to check for any database corruption. If the check command detects any corruption, run the csdb utility rebuild command to rebuild the database.

    For documentation about the csdb and csbackup utilities, see the Sun ONE Calendar Server Administrator's Guide.

Prepare to Migrate

Before you run the ncs4migrate utility, perform these steps on the target machine:

  1. Log in as (or become) root or a user who has administrator rights to the system.

  2. Change to the server-root\cal\bin directory.

  3. Create a text file named ncs4dirpaths.dat and specify the fully qualified directory path to the Netscape Calendar Server 4.0 database. For example:

    /apps/ncs/calendar/unison/db/nodes/N0/perm

    To locate the directory that contains the Netscape Calendar Server 4.0 database, search for the unison.dbd file.

    If necessary, fulfill any requirements to allow ncs4migrate to access the node and read the directory where the Netscape Calendar Server 4.0 database is located.


    Note Do not use variables such as $CAL_HOME in the pathname. Variables are not be resolved during migration.


    For information about creating an ncs4dirpaths.dat file for data on multiple nodes, see Migrating Data From Multiple Nodes.

  4. If you plan to migrate selected users, create a user filter file named ncs4userfilter.dat in the server-root\cal\bin directory. ncs4userfilter.dat is a text file that specifies the users you want to migrate. Each line identifies a user in either of the following formats:

    • node-number:user id in Netscape Calendar Server calendar system (nscalxitemid attribute)

    • user's UID attribute

    For example, several entries in a ncs4userfilter.dat file might be:

    caluser1
    caluser2
    10000:00256
    10000:00257

    You can use both formats in the same ncs4userfilter.dat file.

  5. Make sure that the LDAP server is running.

  6. To prevent updates to the calendar database during the migration, stop the Calendar Server. The Netscape Calendar Server, however, can be either running or stopped.

You are now ready to migrate the Netscape Calendar Server 4.0 data.

Migrate the Data

On the target machine, perform these steps:

  1. While logged in as root or a user who has administrator rights to the system, change to the server-root\cal\bin directory (if necessary).

  2. Type ncs4migrate on the command line.

    The ncs4migrate utility then displays its welcome menu with the options shown in Table 5.

    Note: Although ncs4migrate displays the (E)xport and (I)mport options, these options are not supported and should not be used.


    Table 5    ncs4migrate Utility Options 

    ncs4migrate Option

    Description

    (E)xport  

    Export Netscape Calendar Server 4.0 calendar database to intermediate files.  

    (I)mport  

    Import the data from intermediate files into the calendar database.  

    (S)kip  

    Skip intermediate files. Just migrate one record at a time from Netscape Calendar Server 4.0 to Calendar Server 5.0.  

    (L)ogging = ON|OFF  

    Set Logging. Logging filename is ncs4migrate_yyyymmdd-hhmmss.log.
    Default is ON.      

    (V)erbose = ON|OFF  

    Set Verbose log. Default is OFF.

    To save disk space, we recommend leaving as OFF.  

    (D)ebug = ON|OFF  

    Set Debug log. Default is OFF.  

    (Q)uiet = ON|OFF  

    Set for screen output. Default is OFF.  

    (T)erminate = TRUE|FALSE    

    Terminate if a user in the Netscape Calendar Server 4.0 database is not in LDAP. Default is FALSE.  

    (O)nly = TRUE|FALSE  

    Migrate only users in the user filter file ncs4userfilter.dat.
    Default is FALSE.

    If O and M are TRUE, ncs4migrate migrates any event that has any participant in the filter file as either an owner or attendee. All attendees will have the event migrated to their calendars.  

    (M)igrate = TRUE|FALSE  

    Migrate users in the user filter file. Default is FALSE.  

    (B)ypass = TRUE|FALSE  

    Bypass migration for users in the user filter file. Default is FALSE.  

    (A)ny = TRUE|FALSE  

    Any combination of Netscape Calendar Server security access levels produces a grant in Calendar Server. Default is TRUE. FALSE means all 3 access levels need to be present; see (H)elp.  

    (U)ser  

    Display user filter file ncs4userfilter.dat.
    Use O option to turn filtering ON|OFF. Default is OFF.          

    (P)ath  

    Path file for Netscape Calendar Server 4.0 databases. Filename is ncs4dirpaths.dat.  

    (H)elp  

    Display Help screen  

    (E)xit  

    Exit the program.  

  3. From the ncs4migrate menu, specify the S option to migrate all users. Or, if you are migrating specific users in a user filter file (ncs4userfilter.dat), specify the O option.

  4. Monitor the migration log file to check the migration status. See Checking the Migration Log File for more information.

  5. After the migration is finished, check the migrated calendar database as described in Check the Migrated Data.


Migrating Data From Multiple Nodes
To migrate Netscape Calendar Server 4.0 data from multiple nodes, perform these steps on the target machine:

  1. While logged in as root or a user who has administrator rights to the system, copy the Netscape Calendar Server 4.0 database directory from each node to the machine where you plan to run ncs4migrate. (Each Netscape Calendar Server 4.0 directory should contain a unison.dbd file.)

    You can also migrate the Netscape Calendar Server 4.0 data directly from each node; however, you must first fulfill any requirements to allow ncs4migrate to access the Netscape Calendar Server 4.0 data on the other nodes.

  2. Change to the server-root\cal\bin directory.

  3. In the ncs4dirpaths.dat file, specify a directory pathname for data from all nodes. For example, the following ncs4dirpaths.dat file incudes directory paths for three nodes:

    /apps/ncs/calendar/unison/db/nodes/N0/perm
    /apps/ncs/calendar/unison/db/nodes/N1/perm
    /apps/ncs/calendar/unison/db/nodes/N2/perm

  4. To run the migration utility, type ncs4migrate on the command line.

  5. From the ncs4migrate menu, specify the S option to migrate all users. Or, if you are migrating specific users in a user filter file (ncs4userfilter.dat), specify the O option.

  6. Monitor the migration log file to check the migration status. See Checking the Migration Log File for more information.

  7. After the migration is finished, check the migrated calendar database, as described in Check the Migrated Data.


Checking the Migration Log File
The ncs4migrate utility generates a log file with the following name in the server-root\cal\bin directory:

ncs4migrate_yyyymmdd-hhmmss.log

where yyyymmdd-hhmmss is a timestamp that indicates when the migration started.

If the ncs4migrate utility is taking a long time to run, check that the log file is increasing in size as an indication that the utility is still running.


Note To prevent the log file from becoming too large, consider omitting the ncs4migrate verbose (V) option.


Check the Migrated Data

After the migration is finished, perform these steps on the target machine:

  1. Run the csdb utility check command to scan the calendar database to determine if any corruption has occurred. If the check command detects any corruption, run the csdb utility rebuild command to rebuild the database.

    For documentation about the csdb utility check and rebuild commands, see the Sun ONE Calendar Server Administration Guide on the documentation web site.

  2. If necessary, restart the Calendar Server.

    Users can access the migrated calendar database using Calendar Express.


csmig Migration Utility

The csmig utility migrates a calendar database that was created before the Calendar Server 5.1.1 release to a destination target database that supports the LDAP Calendar Lookup Database (CLD) plug-in. Calendars in the migrated database are then accessible using this plug-in. (New Calendar Server 5.1.1 deployments do not require this migration.)

The LDAP CLD plug-in provides horizontal scalability of the calendar database by allowing calendars to be distributed over a number of back-end servers. For information about the LDAP CLD plug-in, see the Sun ONE Calendar Server Administrator's Guide.

This document describes these topics:

csmig Functions

The csmig migration utility performs these functions:

  • 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 does not write to your existing calendar database.

  • csmig updates LDAP attributes for all relevant LDAP entries, including icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet, and uid (for resource calendars) . 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.

  • 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 jsmith doesn't have an owner, it will be converted to orphan:jsmith, if 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.

    For example, a calendar named football with owner bkamdar will be converted to bkamdar:football. A calendar tchang:soccer with the owner bkamdar will be converted to bkamdar:tchang_soccer. (Only one colon should be in the calid.) A resource calendar named auditorium:room1 will be converted to auditorium_room1.

csmig Requirements

The requirements for using csmig are:

  • Your calendar database must not be corrupted. Use the csdb check command to check your calendar database, and if necessary, run the csdb rebuild command to rebuild the database. For information about these commands, see the Sun ONE Calendar Server Administrator's Guide.

  • You must have sufficient disk space for the new destination target database and if applicable, your backup database.

  • To run csmig, you must login as (or become) root, or as a user (such as icsuser) who has administration rights to the system where Calendar Server is installed.

    You must also have privileges to manage the attributes of calendar users in the LDAP directory server that stores user preferences.

  • The Calendar Server must be stopped.

csmig Syntax

The csmig utility has the following syntax:

csmig [ -t DestinationDB ] [ -b Backend-DWPHost ]
      [ -o OutputFile ]  [ -e ErrorFile ] [ -m MappingFile ]
        -c calendarOwner -r resourceOwner { migrate|dryrun }

-t DestinationDB specifies the destination target database that csmig generates. The default is MigratedDB.

-b Backend-DWPHost specifies the name of the DWP back-end host server. This name must match the DWP back-end host server name specified in the ics.conf file.

-o OutputFile specifies an output file that captures the csmig output to the screen as well as any errors that occur. The default is MigrateOut.

-e ErrorFile is the file where csmig writes any errors or database entries that cannot be resolved. If database entries cannot be resolved, they are not written to the destination database. The default is MigrateError.

-m MappingFile specifies a mapping file for updating entries the LDAP schema. The mapping file provides a list of recommended modifications to the LDAP schema but does not perform the actual modifications to the schema.

-c calendarOwner specifies the owner for user calendars that don't have owners.

-r resourceOwner specifies the owner for resource calendars that don't have owners.

csmig Migration Steps

After you have installed Calendar Server 5.1.1 on all of the servers in your configuration, you must run csmig to migrate your existing Calendar Server and LDAP data to the new Calendar Server 5.1.1 and LDAP data, which is required for the LDAP CLD plug-in to work properly. Here are the recommended steps to migrate calendar data using csmig:

  1. Configure Your LDAP Directory Server-Adding indexes can greatly improve the performance of your migration and calendar searches on LDAP data.

  2. Perform a Test Dry Run-A dry run reports what csmig would do during a migration, but it does not migrate any actual data. After the dry run, you can correct any errors and determine a plan to handle any unresolved calendars.

  3. Migrate Your Production Data-During a production run, csmig migrates the calendar database (.db files) and LDAP data (user and group preferences data), icsSubscribed, icsCalendar, icsCalendarOwned, icsFreeBusy, icsSet, and uid (for resource calendars). After the migration, all calendar resources will have an LDAP entry created.

Configure Your LDAP Directory Server

To improve performance, consider adding the following two new indexes to the slapd.ldbm.conf file:

  • index icscalendar pres,eq,sub-Used by the migration process for searching the icsCalendar attribute.

  • index icscalendarowned pres,eq,sub-Not required for the migration process but is used to perform a calendar search on LDAP data (for a subscribe operation) when the LDAP CLD plug-in is enabled.

For information about creating indexes in the slapd.ldbm.conf file, refer to your directory server documentation.

Perform a Test Dry Run

A test dry run performed on a staging server reports what would be migrated, but it does not perform the actual migration of your production database. A dry run allows you to determine a plan for migrating your production database. For example, you can decide how you want to handle "orphan" calendars, which are calendars that don't have an owner.

To perform a test dry run using csmig, follow these steps:

  1. Log in as (or become) root or as a user (such as icsuser) who has administration rights to the system where Calendar Server is installed.

  2. Install Calendar Server 5.1.1 (if necessary) on the staging server.

  3. Copy a snapshot of your calendar database to the staging server.

  4. Install an LDAP server to mimic the production LDAP environment. Install a snapshot of the LDAP database on this server with the new indexes in the slapd.ldbm.conf file.

  5. Change to the server-root/cal/bin/ directory.

  6. Consider creating a catchall calid for user calendars that don't have an owner. For example, on Solaris systems, the following command creates a user with the calid of orphan:

    ./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan

  7. Stop the Calendar Server using the stop-cal command (if necessary).

  8. Run the csdb check command to check your database for corruption. If corruption is indicated, run csdb rebuild to rebuild the database.

  9. Run csmig with the dryrun option. For example, on a Solaris system, enter:

    ./csmig -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster dryrun

    This command assigns user calendars without an owner to orphan and resource calendars without an owner to calmaster.

  10. Check the output, mapping, and error files. Resolve any LDAP issues or errors that you find. Determine how you will handle any unresolved calendars before the actual migration. Several options are:

    • Delete any unneeded calendars before you migrate.

    • Assign owners to any unresolved calendars.

    • Allow csmig to assign owners to the calendars during migration using the -c and -r options.

  11. It is highly recommended that you migrate your calendar database on your staging server before you migrate your actual production calendar database. This steps allows you to see exactly how your data will be migrated and to correct any problems before you migrate your production database.

    For example, on a Solaris system, the following command migrates the calendar database to the /var/opt/SUNWics5/testcsdb/ directory:

    ./csmig -t /var/opt/SUNWics5/testcsdb/ -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster migrate

  12. After the test migration is finished, copy the migrated database to the /csdb directory specified by the caldb.berkeleydb.homedir.path parameter. Or, edit this parameter to point to the new location of the migrated database. Then perform these checks:

    • Run csdb check on the new calendar database. The number events and todos in the migrated database should match the pre-migration totals.

    • Search for icsCalendarOwned entries and make sure that the entries match the pre-migration number of calendars.

    • Login to Calendar Express and verify some of the calendars in the migrated database.

If the test migration is successful, you are ready to migrate your production database.

Migrate Your Production Data

To migrate your production database using csmig, follow these steps:

  1. Log in as (or become) root or as a user (such as icsuser) who has administration rights to the system where Calendar Server is installed.

  2. Change to the server-root/cal/bin/ directory.

  3. Stop the Calendar Server using the stop-cal command (if necessary).

  4. Backup the following data:

    • Calendar database (.db files).

    • LDAP data: slapd database directory and LDAP database.

    • ics.conf file. This step is not actually required, but it can be useful if you need to revert to your original configuration.

  5. Run csmig with the migrate option. For example, on a Solaris system, the following command migrates the calendar database to the /var/opt/SUNWics5/newcsdb/ directory:

    ./csmig -t /var/opt/SUNWics5/newcsdb/ -b sesta.com -o csmig.out -e csmig.errors -m csmig.log -c orphan -r calmaster migrate

  6. Check for any unresolved calendars in the error file and resolve them according to your plan from Step 10 under Perform a Test Dry Run.

  7. Copy the new migrated database to the /csdb directory specified by the caldb.berkeleydb.homedir.path parameter. Or, edit this parameter to point to the new location of the migrated database.

  8. Run the csdb check command to check your migrated database. If any corruption is indicated, run csdb rebuild to rebuild the database.

  9. Enable the LDAP CLD plug-in by making any necessary changes to the following configuration parameters in the ics.conf file:

    • service.dwp.enable = "yes"

    • service.dwp.port = "9779"

    • csapi.plugin.calendarlookup = "y"

    • csapi.plugin.calendarlookup.name = "*"

    • caldb.cld.type = "directory"

    • caldb.dwp.server.default = "default-server-name"

    • caldb.dwp.server.server-hostname.ip = "server-hostname" (for each back-end server including the local server)

    • caldb.cld.cache.enable = "yes" (if you want to use the CLD cache option)

    • caldb.cld.cache.homedir.path specifies the location of the CLD cache directory. The default is server-root/var/csdb/cld_cache.

      Check that this directory is correct, or if you want a different location for the CLD cache, modify this parameter.

    For information about setting configuration parameters for the LDAP CLD plug-in, see the Sun ONE Calendar Server Administrator's Guide.

  10. Restart the Calendar Server using the start-cal command.

  11. Log in to the Calendar Server and verify that your configuration is working by checking several of the migrated calendars. To disable alarms while you are making your checks, set each of the following parameters in the ics.conf file to "no":

    • caldb.serveralarms = "no"

    • caldb.serveralarms.dispatch = "no"

    • service.ens.enable = "no"

    • service.notify.enable = "no"

    • ine.cancellation.enable = "no"

    • ine.invitation.enable = "no"

    • service.admin.alarm = "no"

csmig Tips and Troubleshooting

The section describes the following tips and trouble shooting solutions:

 


The csmig dry run calendar owner is not the owner I want for a calendar
For example, a calendar named tchang:myCalendar has the owner as jsmith in the calendar database, and the csmig dry run shows the mapping as jsmith:tchang_myCalendar. I would like to keep this calendar name as tchang:myCalendar and assign the owner as tchang.


Solution
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 tchang's LDAP entry.


The LDAP calendar search doesn't work correctly
After migration, the LDAP calendar search is enabled, but the calendar search dialog does not return any results or returns only partial results.


Solution
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:

  • ldapsearch with filter (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))

  • ldapsearch with filter (icscalendarowned=*substr*)

Since the server uses the filter that includes icsCalendaruser objectclass, the LDAP server might have been deployed with the schema check disabled, and some calendar entries may have been provisioned without the icsCalendaruser objectclass.


The csmig dry run indicates duplicate calendar names
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


Solution
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.


How do I assign orphan calendars to different owners?
By default csmig assigns all orphan calendars to a single owner, but I would like to assign different owners for some orphan calendars.


Solution
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 calendar users to another back-end server?
How do I move users from one back-end server to another?


Solution
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 detailed steps about moving users, see the Sun ONE Calendar Server Administrator's Guide.


Previous     Contents     Index     Next     
Copyright 2002 Sun Microsystems, Inc. All rights reserved.

Last Updated August 30, 2002