Sun Java Enterprise System 2005Q1 Upgrade and Migration Guide |
Chapter 4
Upgrading Components from Versions Predating Java Enterprise SystemThis 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 InformationYou 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 InformationYou 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 InformationTo upgrade from Application Server 6.x or Application Server 7, see Upgrading Application Server
Calendar Server Migration InformationIf 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.
- ics2migrate–Migrates data from iPlanet Calendar Server 2.x to 5.x. This utility is bundled with Calendar Server 5.1.1. Run this after installing 5.1.1.
- ncs4migrate–Migrates data from Netscape Calendar Server 4.x to 5.x. This utility is available at the migrations Web site. See Migration Web Site. Run this utility after installing 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:
- cs5migrate–Use this utility if you are not using the Connector for Microsoft Outlook, or you do not have recurring components in your existing calendar databases.
- cs5migrate_recurring–Use this utility if you have recurring components in your databases and you plan to use the Connector for Microsoft Outlook.
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.
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.
Table 4-1 Running the Calendar Server Migration Utilities
Previous Version
Procedure
iPlanet Calendar Server 2.x
Netscape Calendar Server 4.x
Sun ONE or iPlanet Calendar Server 5.x
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.
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 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 6 2005Q1 installed.
- ics2migrate utility–Before you migrate, first check with technical support or your account team to ensure that you have the latest version of the utility.
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.
The following table lists the Calendar Server 2.x LDAP attributes and describes how ics2migrate migrates the attributes to Calendar Server 6 2005Q1.
Migration Process
- Back up your calendar database using a utility such as csbackup, the Sun StorEdge Enterprise Backup software, or Legato Networker�.
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.
- Run the db_recover on your 2.x Berkeley Database.
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.
- Download and install Calendar Server 5.1.1.
Refer to the iPlanet Calendar Server 5.1 Installation Guide found at:
http://docs.sun.com/db/doc/816-5516-10- Upgrade the 2.x calendar database–run db_upgrade.
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- Migrate the data by running ics2migrate.
For instructions on how to run ics2migrate, see To Run ics2migrate.
- Check the migration results.
- Check the ics2migrate.log file 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 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
- On Solaris and other UNIX systems, login as the user and group under which Calendar Server is running, such as icsgroup and icsuser.
- If necessary, stop the 2.x Calendar Server.
- Back up your calendar 2.x database, if you have not already done so.
- Remove (delete) any old share (__db_name.share) or log (log.*) files from the following directories:
cal_svr_base/opt/SUNWics5/cal/lib/http
cal_svr_base/var/opt/SUNWics5/csdb
- Change to the Calendar Server 5.x directory where the utility is located:
cal_svr_base/opt/SUNWics5/cal/tools/unsupported/bin- 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.
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.
- 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:
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:
- Change to the directory where ics2migrate is located.
- Run ics2migrate using the syntax in ics2migrate Syntax.
- After migration, make sure that the caldb.berkeleydb.homedir.path parameter in the ics.conf file points to the migrated database.
- 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.
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 InformationTo upgrade to Directory Server 5 2005Q1, follow this high-level procedure:
- 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.
- Stop the previous version of Directory Server.
- Migrate configuration and user data from the previous version to Directory Server 5 2005Q1.
- 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 InformationYou 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:
- Ensure that the configuration directory server is running.
- Ensure that the port numbers of new instances of Directory Proxy Server do not conflict with those of the old instances.
- Do not modify the configuration in the configuration directory server while the migration is taking place.
- When you migrate the old SSL configuration, a new SSL configuration is created but the SSL parameters on the client side are cleared. Existing SSL configuration must be re-configured manually. Record your current SSL configuration before performing the migration.
Performing Migration
- Install Administration Server 5 2005Q1 on a separate server root.
Ensure that the port numbers of the new instances do not conflict with those of the old instances.
- Replace the encrypted password by the non-encrypted password in the tailor.txt file for the Java Enterprise System 2005Q1 instances.
- Launch the migration script:
# serverroot/bin/dps_utilities/migratefromidar50
-b backup-filename -o old-tailor-path -n new-tailor-pathThe following table describes the arguments used by the migration script:
- Manually reconfigure SSL if necessary.
- 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:
Instant Messaging Migration InformationTo 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 InformationPrevious 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 InformationTo 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 InformationMany 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 InformationTo 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 InformationTo upgrade to Sun Remote Services Net Connect 3.5, follow these steps:
- 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.
- Install Sun Remote Services Net Connect 3.5 using the Java Enterprise System installer.
Web Server Migration InformationYou 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 InformationThe 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.
In this case, the installer replaces the existing package-based installation of J2SE platform with the version compatible with Java Enterprise System.
During the replacement installation, you should stop other running applications that depend on J2SE platform. Reboot your system after installation to ensure that the new version of J2SE platform is recognized by all applications.
In this case, the installer adds an additional set of J2SE platform packages. After installation, you can use the pkginfo command to see these additional packages. For example:
In this example, the .2 suffix identifies the additional set of packages installed for Java Enterprise System. To get more information about one of the packages, use the pkginfo command with the -l option. For example:
# pkginfo -l SUNWj3rt.2
PKGINST: SUNWj3rt.2
NAME: J2SDK 1.4 runtime environment
CATEGORY: system
ARCH: sparc
VERSION: 1.4.1,REV=2003.07.09.05.20
BASEDIR: /usr/jdk/.j2se1.4.1_05
VENDOR: Sun Microsystems, Inc.
DESC: Java virtual machine and core class libraries
PSTAMP: hop-sparc20030709052032
INSTDATE: Oct 30 2003 16:11
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 647 installed pathnames
7 shared pathnames
64 directories
58 executables
104533 blocks used (approx)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.