Chapter 4
Migrating iPlanet Calendar Server Data
This chapter describes how to migrate calendar data server to iPlanet Calendar Server 5.1:
Migrating From iPlanet Calendar Server 2.x
The ics2migrate migration utility can migrate both iPlanet Calendar Server 2.x calendar data and LDAP user preferences to Calendar Server 5.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:
What Gets Migrated?
The following tables show how ics2migrate migrates Calendar Server 2.x data and LDAP user preferences.
Table 4-1 Migration of Calendar Server 2.x Data
|
Calendar Server 2.x Data
|
Migration Results
|
|
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.
|
Table 4-2 Migration of LDAP User Preferences
|
Calendar Server 2.x Attribute
|
Calendar Server 5.x 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
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.
Locate the Calendar Server 2.x caldb.conf file. The default directory for this file depends on your platform:
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]"
|
To ensure data integrity, stop all services for both Calendar Server 2.x and 5.x. For more information, see the respective iPlanet Calendar Server Administrator's Guide on the iPlanet documentation web site.
Migrate the Data
Change to the server-root\cal\bin directory where ics2migrate.exe is located.
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 describes the ics2migrate options.
Table 4-3 ics2migrate Options
|
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 iPlanet Calendar Server Administration Guide on the iPlanet 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
Migrating From Netscape Calendar Server 4.x
This section describes how to migrate Netscape Calendar Server 4.x calendar data to iPlanet 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.
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:
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:
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, iPlanet recommends that you perform these steps to ensure the integrity of your calendar database:
Backup your calendar database using the csbackup utility (or another backup utility).
-
For information about csbackup, see the iPlanet Calendar Server Administration Guide on the iPlanet documentation web site.
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 iPlanet Calendar Server Administration Guide on the iPlanet documentation web site.
Prepare to Migrate
Before you run the ncs4migrate utility, perform these steps on the target machine:
Log in as (or become) root or a user who has administrator rights to the system.
Change to the server-root\cal\bin directory.
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.
If you plan to migrate selected users, create a user filter file named ncs4userfilter.dat in the same 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.
Make sure that the LDAP server is running.
To prevent updates to the calendar database during the migration, stop the iPlanet 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:
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)
Type ncs4migrate on the command line.
-
The ncs4migrate utility then displays its welcome menu with the options shown in Table 5:
Table 5 ncs4migrate Utility Options
|
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.
|
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.
Monitor the migration log file to check the migration status. See Checking the Migration Log File for more information.
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:
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.
Change to the server-root\cal\bin directory.
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
To run the migration utility, type ncs4migrate on the command line.
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.
Monitor the migration log file to check the migration status. See Checking the Migration Log File for more information.
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 directory where the binary is located (default is server-root\cal\bin):
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:
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 iPlanet Calendar Server Administration Guide on the iPlanet documentation web site.
If necessary, restart the Calendar Server.
-
Users can access the migrated calendar database using Calendar Express.