Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java Enterprise System 2005Q1 Upgrade and Migration Guide 

Chapter 4
Upgrading Components from Versions Predating Java Enterprise System

This chapter provides the procedures for migrating component products from versions prior to the first release of Sun Java™ Enterprise System (Java ES) software to the versions included in Java Enterprise System 2005Q1. For most component products, this chapter simply provides an overview of the migration process and directs you to the component-product documentation that contains complete migration procedures.

This chapter contains the following sections:

Access Manager Migration Information

You can upgrade to Access Manager 6 2005Q1 from Identity Server 6.0 or 6.0 SP1, or from DSAME 5.1.

First, upgrade to Identity Server 2003Q4 (6.1), by following the process in the Sun ONE Identity Server 6.1 Migration Guide:

http://docs.sun.com/doc/816-6771-10

After you upgrade to Identity Server 2003Q4 (6.1), follow the steps in Upgrading Access Manager in this guide.

Administration Server Migration Information

You can upgrade to Administration Server 5 2005Q1 from these previous versions:

In all cases, you should upgrade Administration Server at the same time as you upgrade Directory Server.

To upgrade a package-based installation of Administration Server 5.2, refer to Upgrading Administration Server, Directory Server, and Directory Proxy Server.

To upgrade a non-package-based installation of Administration Server 5.2, refer to the Sun Java System Directory Server 5 2005Q1 Installation Guide (http://docs.sun.com/doc/817-7608).

To upgrade Administration Server 4.x, 5.0 or 5.1, refer to the Sun Java System Directory Server 5 2005Q1 Installation and Migration Guide (http://docs.sun.com/doc/817-7608).

Application Server Migration Information

To upgrade from Application Server 6.x or Application Server 7, see Upgrading Application Server

Calendar Server Migration Information

If you are currently using a pre-Java Enterprise System version of Calendar Server, you may need to migrate the component databases and the LDAP database before you can upgrade to Calendar Server 6 2005Q1.

Several migration utilities can be obtained from technical support that bring your down-level databases up to the current version. A Migration Utility Overview is provided in this chapter to assist you in choosing the correct utilities to run.

This chapter contains the following sections:

Overview of Calendar Server Migration Utilities

This sections describes the migration utilities you need to use for two different conditions:

If Your Calendar Server Version Pre-Dates 5.1.1

If you have a version of Calendar Server that predates Calendar Server 5.1.1, you must bring your LDAP directory entries and your calendar database up to Calendar Server 5.1.1 levels before you install and configure Calendar Server 6 2005Q1. This means you will have to perform certain steps before and after installing Calendar Server 5.1.1, as shown in Migration Utility Overview.

If you currently have Calendar Server 2.x, or Netscape Calendar Server 4.x installed, the following migration utilities must be used (as needed) before installing Calendar Server 5.1.1.

If Your Calendar Server Version is 5.1.1

When you have migrated your pre-5.1.1 version system up to 5.1.1, or if you already have 5.1.1, you must uninstall 5.1.1 and then install Calendar Server 6 2005Q1. Then, run either cs5migrate or cs5migrate_recurring. To choose which of these two utilities to use, consider the following:

Both of these utilities migrate data from Calendar Server 5.x to 6.x. These utilities are available at the migrations Web site. See Migration Web Site.

Tip

A recurring component is one event or task that has multiple instances, such as a meeting that occurs weekly. If you do not know if you have recurring components in your calendar databases, call technical support for further instructions.

Migration Utility Overview

There are several steps that must be done before and after running the various migration utilities. Table 4-1 lists all the steps necessary to migrate your databases to Calendar Server 6 2005Q1 version.

Note

ics2migrate is bundled with the Sun ONE Calendar Server 5.1.1 download. And csmig and csvdmig are bundled with Sun Java System Calendar Server 6 2005Q1.

If you have Netscape Calendar Server 3.5, you must migrate to Netscape Calendar Server 4.x before using ncs4migrate. This migration utility is available from Sun’s technical support.

Table 4-1  Running the Calendar Server Migration Utilities

Previous Version

Procedure

iPlanet Calendar Server 2.x

  1. Run db_recover
  2. Download and install Calendar Server 5.1.1
  3. Run db_upgrade
  4. Run ics2migrate
  5. Uninstall Calendar Server 5.x
  6. Download and Install Calendar Server 6.x.
  7. Run cs5migrate/ cs5migrate_recurring

Netscape Calendar Server 4.x

  1. Download and install Calendar Server 5.1.1
  2. Run ncs4migrate
  3. Uninstall Calendar Server 5.x
  4. Download and Install Calendar Server 6.x.
  5. Run cs5migrate/ cs5migrate_recurring

Sun ONE or iPlanet Calendar Server 5.x

  1. Uninstall Calendar Server 5.x
  2. Download and Install Calendar Server 6.x.
  3. Run cs5migrate/ cs5migrate_recurring

Migration Web Site

To further assist you in making the proper choices for your particular site, additional information and the utility downloads can be obtained from technical support who will direct you to a Web site.

In some cases, you will be referred to Sun Microsystems Technical Support or Professional Services for assistance.

The documentation for ncs4migrate, cs5migrate and cs5migrate_recurring are available with in the migration package from technical support.

Note

Even though cs5migrate appears to be bundled with the Calendar Server product, if you try to run the utility, the following message appears:
!!!!!!!!!!PLEASE NOTE!!!!!!!!!!
To migrate to Calendar Server 6.0, please contact your Sun Microsystems Technical Support or Sales Account Representative to get the latest version of the utility.

ics2migrate

The ics2migrate utility migrates iPlanet Calendar Server 2.x calendar data and LDAP user preferences to Sun ONE Calendar Server 5.1.1.

This section describes:

Migration Requirements

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

The source machine and destination machines can be different servers or the same server. For a list of supported platforms refer to the Sun Java System Calendar Server Release Notes.

What Is Migrated?

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

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

Calendar Server 2.x Data

Migration Results for Calendar Server 6.0

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 6 2005Q1.

Table 4-3  Migration of LDAP Attributes 

Calendar Server 2.x LDAP Attribute

Calendar Server 6 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

  1. Back up your calendar database using a utility such as csbackup, the Sun StorEdge Enterprise Backup™ software, or Legato Networker�.

    2. Backing up your calendar database is always very important, but especially so in this process because db_upgrade (performed in Step 4) upgrades the database in place. If a problem occurs during the upgrade, your database could be left in an unrecoverable state.

  2. Run the db_recover on your 2.x Berkeley Database.

    3. Run the Berkeley DB db_recover utility to merge the log file transactions into the database before you convert it. If you do not use this utility, you will lose the unmerged transactions.

  3. Download and install Calendar Server 5.1.1.

    4. Refer to the iPlanet Calendar Server 5.1 Installation Guide found at:
    http://docs.sun.com/db/doc/816-5516-10

  4. Upgrade the 2.x calendar database–run db_upgrade.

    5. Calendar Server 5.1.1 requires Berkeley DB version 3.2.9 from Sleepycat Software. Before you run ics2migrate, you must upgrade to version 3.2.9 using the Berkeley DB db_upgrade utility. For instructions on how to run this utility, see To Run the db_upgrade Utility.

    For more information about the Berkeley DB utilities, refer to the following web site:
    http://www.sleepycat.com/docs/utility/index.html

  5. Migrate the data by running ics2migrate.

    6. For instructions on how to run ics2migrate, see To Run ics2migrate.

  6. Check the migration results.
    1. Check the ics2migrate.log file for the following messages (depending on your migration choices):

      2. Database migration successfully completed
      LDAP user preference migration successfully completed

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

      3. 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 Appendix D of the Calendar Server 6 2005Q1 Administration Guide at: http://docs.sun.com/app/docs/doc/819-0024.

    To Run the db_upgrade Utility
  1. On Solaris and other UNIX systems, login as the user and group under which Calendar Server is running, such as icsgroup and icsuser.
  2. If necessary, stop the 2.x Calendar Server.
  3. Back up your calendar 2.x database, if you have not already done so.
  4. Remove (delete) any old share (__db_name.share) or log (log.*) files from the following directories:

    5. cal_svr_base/opt/SUNWics5/cal/lib/http

    cal_svr_base/var/opt/SUNWics5/csdb

  5. Change to the Calendar Server 5.x directory where the utility is located:
    cal_svr_base/opt/SUNWics5/cal/tools/unsupported/bin
  6. Run the db_upgrade utility to upgrade your 2.x calendar database to version 3.2.9. If you are not in the same directory with the 2.x calendar database, use the -h option to point to the database files.

    7. You must run db_upgrade on all 2.x database files (alarms.db, calprops.db, events.db, and todos.db). You must also run db_upgrade on all front-end and back-end servers in your Calendar Server configuration, even if a server is not directly connected to a calendar database.

  7. Locate the Calendar Server 2.x caldb.conf file in the csdb directory with the database files and change the first line in the file as follows:

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

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

    If this file is not in the csdb directory, create it using a text editor and then set the first line to the new value.

    To Run ics2migrate

Follow these steps to run ics2migrate:

  1. Change to the directory where ics2migrate is located.
  2. Run ics2migrate using the syntax in ics2migrate Syntax.
  3. After migration, make sure that the caldb.berkeleydb.homedir.path parameter in the ics.conf file points to the migrated database.
  4. Run the csdb check command and, if necessary, the csdb rebuild command to rebuild your calendar database.
ics2migrate Syntax

You can choose to migrate either the calendar database or LDAP user preferences separately, or together. The syntax for each choice is shown, as follows:

Table 4-4 lists the options recognized by the utility, gives a description of each and the default value.

Table 4-4   ics2migrate Options 

ics2migrate Option

Description and Default Value

[-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 cal_svr_base/opt/SUNWics5/cal/sbin directory.

By default, ics2migrate displays maximum 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 a required option for migrating the calendar database (-m db option specified).

target

Directory where the Calendar Server 6.0 database files are located.

target is a required option for migrating the calendar database (-m db option specified).

Migration Examples

This section shows examples of the ics2migrate command line for the following types of migration:

Migrate Both Calendar Database and LDAP User Information

In this example, both the LDAP user information and the Calendar Server 2.x database will be migrated. In addition, since the -s and -f options are missing the defaults are taken. That is, all calendars are granted scheduling and free/busy access. Due to the presence of the -l min option, minimal migration statistics will be logged.

The Calendar Server 2.x database is stored in the /var/opt/SUNWicsrv/2x_db directory and the 6.0 database is in the /var/opt/SUNWics5/50_db directory.

The syntax for migrating both the calendar database and the LDAP user information follows:

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

Migrate in Quiet Mode

In this example, both the LDAP user information and the Calendar Server 2.x database will be migrated. In addition, since the -s and -f options are missing the defaults are taken. That is, all calendars are granted scheduling and free/busy access. Due to the presence of the -q option nothing will display on the console unless errors occur and then only error messages will appear. Because the -l option is not specified, maximum migration statistics will be logged.

The Calendar Server 2.x database is stored in the /var/opt/SUNWicsrv/2x_db directory and the 6.0 database is in the /var/opt/SUNWics5/50_db directory.

The syntax for migrating both the calendar database and the LDAP user information in quiet mode follows:

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

Migrate Only the Calendar Database

In this example, only the 2.x calendar database will be migrated. The 2.x calendar database is stored in the 2x_db directory (relative to the current directory), and the utility creates a 6.0 database in the /var/opt/SUNWics5/50_db directory.

The syntax for migrating only the calendar database follows:

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

Migrate Only LDAP User Information

In this example, only the Calendar Server 2.x LDAP user information is migrated to version 6.0 format. The utility is not in quiet mode, so utility status information is sent to the console.

The syntax for migrating only the LDAP user information follows:

ics2migrate -m ldap

Where to Go from here

Now that you have migrated your component databases and the LDAP database proceed to Upgrading Calendar Server.

Directory Server Migration Information

To upgrade to Directory Server 5 2005Q1, follow this high-level procedure:

  1. Install Directory Server 5 2005Q1 and Administrator Server 5 2005Q1 alongside the previous versions, on the same machine. When you do so, make sure to specify different values for the server root, administrative domain, and listener ports.
  2. Stop the previous version of Directory Server.
  3. Migrate configuration and user data from the previous version to Directory Server 5 2005Q1.
  4. Direct clients of the previous version to use the new version.

For the specific instructions to perform this procedure, refer to Chapter 2, “Upgrading From Previous Versions,” of the Sun Java System Directory Server 5 2005Q1 Installation and Migration Guide (http://docs.sun.com/doc/817-7608). When following these instructions, use the Java Enterprise System installer—not the Directory Server installer—when you are directed to install Directory Server.

Directory Proxy Server Migration Information

You can upgrade to Directory Proxy Server 5 2005Q1 from Directory Proxy Server 5.2 or from Directory Access Router 5.0 or 5.0 SP1.

To migrate from Directory Proxy Server 5.2 to Directory Proxy Server 5 2005Q1, refer to Upgrading Directory Proxy Server.

Upgrading from Directory Access Router 5.0 or 5.0 SP1

This section describes how to migrate from Directory Access Router 5.0 or 5.0 SP1 to Directory Proxy Server 5 2005Q1.

Preparing for Migration

Consider the following points before migrating from Directory Access Router version 5.0 or 5.0 SP1 to Directory Proxy Server 5 2005Q1:

Performing Migration

  1. Install Administration Server 5 2005Q1 on a separate server root.

    2. Ensure that the port numbers of the new instances do not conflict with those of the old instances.

  2. Replace the encrypted password by the non-encrypted password in the tailor.txt file for the Java Enterprise System 2005Q1 instances.
  3. Launch the migration script:

    4. # serverroot/bin/dps_utilities/migratefromidar50
    -b     backup-filename -o old-tailor-path -n new-tailor-path

    The following table describes the arguments used by the migration script:

    Argument

    Function

    -b

    Identify a backup file. A backup of the “ou=dar-config,o=NetscapeRoot” branch will be made for all configuration directories that appear in the new startup configuration file (specified with the -n flag). A numeric suffix (0..n) will be added to the file name specified to indicate which directory the backup belongs to. The suffix will be ’0’ for the first entry in the startup configuration file.

    -o

    Identify the path to the tailor.txt file of the Directory Access Router 5.0 or 5.0 SP1 instance.

    -n

    Identify the path to tailor.txt file of the Java Enterprise System 2005Q1 instance.

  4. Manually reconfigure SSL if necessary.
  5. Ensure that the following conditions exist. These conditions indicate that the migration was successful.
    • The last line of the migration output is “all done.”
    • The console is able to read the configuration.
    • The server starts after migration.

      • If the migration has failed, follow the instructions in Recovering From a Failed Migration.

Recovering From a Failed Migration

The migration has failed if any of the following conditions exist:

To recover from a failed migration, follow these steps:

  1. Restore the backup by using the ldapadd command (LDIF format), or by using the Directory Server console.
  2. If SSL was not configured in the previous Directory Access Router instance, restart the new instance of Directory Proxy Server.

Instant Messaging Migration Information

To upgrade to Instant Messaging 6 2005Q1 you must first upgrade to a previous Java Enterprise System version, Refer to Chapter 9, “Upgrading Components from Versions Predating Java Enterprise System,” of the Java Enterprise System 2004Q2 Installation Guide (http://docs.sun.com/app/docs/doc/817-5760).

Message Queue Migration Information

Previous versions of Java Enterprise System contained both Platform and Enterprise Editions of Message Queue. Java Enterprise System 2005Q1 only bundles Message Queue 3 2005Q1 (3.6) Enterprise Edition.

Upgrading from Message Queue 3.0.1 Through 3 2005Q1 (3.6)

To upgrade from Message Queue versions 3.0.1 through 3.6, follow the steps described in Upgrading Message Queue.

Note

Before upgrading Message Queue, familiarize yourself with the compatibility information in Message Queue.

Messaging Server Migration Information

To upgrade to Messaging Server 6 2005Q1, refer to Chapter 2, “Upgrading to Sun Java System Messaging Server,” of the Sun Java System Messaging Server 6 2005Q1 Administration Guide (http://docs.sun.com/doc/817-6266).

Portal Server and Portal Server, Secure Remote Access Migration Information

Many factors affect the procedure you should follow to upgrade to Portal Server 6 2005Q1 or Portal Server, Secure Remote Access 6 2005Q1. For a discussion of these factors, and the procedure you should follow to upgrade, refer to the Sun Java System Portal Server 6 2005Q1 Migration Guide (http://docs.sun.com/doc/817-5320).

Sun Cluster Migration Information

To upgrade to Sun Cluster 3.1 9/04, refer to Chapter 5, “Upgrading Sun Cluster Software,” of the Sun Cluster Software Installation Guide for Solaris OS (http://docs.sun.com/doc/817-6543). When following the instructions in this chapter, use the scinstall utility in the following directory in the Java Enterprise System distribution:

Product/sun_cluster/os-version/Tools

where os-version is Solaris_8 or Solaris_9.

Sun Remote Services Net Connect Migration Information

To upgrade to Sun Remote Services Net Connect 3.5, follow these steps:

  1. Uninstall the existing version of Sun Remote Services Net Connect. Use the instructions under “Uninstalling Net Connect” in Chapter 3 of the Sun Remote Services Net Connect Installation and Activation Guide, http://docs.sun.com/doc/916-1586.
  2. Install Sun Remote Services Net Connect 3.5 using the Java Enterprise System installer.

Web Server Migration Information

You can upgrade to Web Server 6 2004Q1 Update 1 Service Pack 2 from Web Server 6.0 or 6.0 SP1, or Web Server 4.1.

Upgrading from Web Server 6.0

To upgrade from Web Server 6.0 or 6.0 SP1, refer to Chapter 5, “Migrating from Version 6.0 to 6.1,” of the Sun ONE Web Server 6.1 Installation and Migration Guide (http://docs.sun.com/doc/819-0131-10).

Upgrading from Web Server 4.1

To upgrade from Web Server 4.1, refer to Chapter 6, “Migrating from Version 4.1 to 6.1,” of the Sun ONE Web Server 6.1 Installation and Migration Guide (http://docs.sun.com/doc/819-0131-10).

Shared Component Upgrade Information

The Java Enterprise System installer automatically checks for and informs you about any shared components that must be upgraded for Java Enterprise System compatibility. With the exception of the J2SE platform component, the installer upgrades shared components by replacing the previous version.

Caution

Do not upgrade shared components without first verifying that existing applications are compatible with the newer versions of the shared components.

Reboot your system after upgrading shared components to ensure that the new versions are recognized by all applications.

J2SE Platform Upgrade Information

When the Java Enterprise System installer detects an incompatible packaged-based installation of J2SE platform, it offers you the choice of upgrading the existing version or adding the new version as a second installation for use by Java Enterprise System components.

After installation, the /usr/jdk/entsys-j2se link refers to the version of J2SE platform that is compatible with Java Enterprise System, regardless of which choice you make.



Previous      Contents      Index      Next     

Part No: 819-0062-11.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.