This incremental-migration scenario makes the following assumptions:
Messaging and Calendar Server are running in a two-tiered, multiple-server environment.
You are running user-developed applications (such as provisioning tools or scripts you have created at your site) that rely on Schema 1 and that cannot be converted immediately to use Schema 2
This scenario uses the sample distributed environment shown in Migration Steps
Server downtime is minimized. At any given time, most servers are running and available.
Most of the LDAP directory is available to the servers and for provisioning.
You migrate the LDAP directory in stages, selecting individual domains for migration.
The overall migration time is extended.
While the directory is in Schema 2, compatibility mode:
User-developed applications can continue to use the LDAP directory exactly as if it were still in Schema 1.
Messaging and Calendar servers can continue to use the directory exactly as if it were Schema 1.
User-developed provisioning tools that rely on Schema 1 can only work on existing directory data.
This migration process is the most complex of the scenarios; it is more complex than a direct migration to Schema 2, native mode, or an incremental migration to native mode. The schema migration must be performed twice.
For a discussion of the conditions best suited for migrating your installation incrementally, see Deployments Suitable for Incremental Migration.
The following steps outline how to migrate a two-tiered, multiple-server environment to Schema 2, native mode in stages.
Upgrade Back-end Server 1 (B1) from version 5.x to version 6 (if you have not already done so). Server B1 is shown in the example in Migration Steps.
For information about upgrading Messaging Server, see Upgrading Messaging Server to Version 6
For information about upgrading Calendar Server, see Upgrading Calendar Server to Version 6
Be sure that Server B1 is still configured for Schema 1.
During the server upgrade, you run the Communications Services Directory Server Setup Perl script, comm_dssetup.pl. The script asks you to specify the schema version Directory Server will use:
Specify Schema 1.
Set comm_dssetup.pl -t option as follows: -t 1
You only need to run the comm_dssetup.pl once for each Directory Server used by the Messaging and Calendar servers, although it does no harm to run the script more than once.
For information about running comm_dssetup.pl, see Running the Directory Server Setup Script
Install Access Manager 6.1 or later.
Follow the Access Manager installation instructions in the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.
Before you run the Java Enterprise System installation program, gather the information needed to install Access Manager with a provisioned directory.
For details, see theAccess Manager: Provisioned Directory Information in Sun Java Enterprise System 2005Q4 Installation Reference.
During the installation, you are asked if you want Access Manager to use an existing provisioned directory. Answer yes.
The installation program asks you to specify the following parameters associated with your directory:
Organization Object Marker Class: Object class defined for the organization in the existing provisioned directory. The default value is SunManagedOrganization.
Organization Naming Attribute: Naming attribute used to define organizations in the existing provisioned directory. The default value is o.
User Marker Object Class: Object class defined for users in the existing provisioned directory. The default value is inetorgperson.
User Naming Attribute: Naming attribute used for users in the existing provisioned directory. The default value is uid.
After you install Access Manager, configure Access Manager to operate with the existing directory.
Follow the steps in “Chapter 4, Configuring Access Manager With an Existing Directory Server” in Sun Java System Access Manager 6 2005Q1 Migration Guide.
Do not provision your LDAP directory with Access Manager tools before you have migrated the directory to Schema 2. The Messaging and Calendar servers cannot recognize any new domain information provisioned by Access Manager tools until you perform the migration to Schema 2 and reconfigure the servers for Schema 2.
Install and configure the Communications Services Delegated Administrator console and utility (commadmin).
Use the Sun Java Enterprise System Installer to install Delegated Administrator.
After the installation, you must run the Delegated Administrator configuration program, config-commda.
For details, see Chapter Chapter 3, Configuring Delegated Administrator, in Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.
Back up Domains 1 and 2 in the LDAP directory.
Migrate Domains 1 and 2 of the LDAP directory from Schema 1 to Schema 2, compatibility mode. (Server B1 uniquely manages Domains 1 and 2.)
Use the Schema Migration utility, commdirmig, to perform the migration.
Use the -d Domain option to migrate Domains 1 and 2.
Do not provision Domains 1 and 2 while commdirmig is running. You can provision other domains in the directory.
For information on running the commdirmig utility and on the utility options and syntax, see Chapter 3, Using the Migration Utility.
You do not have to reconfigure the Messaging and Calendar servers to use Schema 2, compatibility mode.
When the LDAP directory has been migrated to Schema 2, compatibility mode, the servers should continue to be configured to use Schema 1.
Configure Access Manager to use Schema 2, compatibility mode by enabling Access Manager to use the DC Tree:
Start Access Manager Console as a user with administrator rights.
Click the Services Configuration tab.
Select Administration Services -> Global.
Check the box next to Enable Domain Component Tree.
Click Save.
For more information about these steps, see the Sun Java System Access Manager 7 2005Q4 Administration Guide
C check that the Access Manager configuration properties file contains the correct DC Tree root suffix value by opening the configuration properties file, AMConfig.properties. The default location of the file is /opt/SUNWam/lib
The com.iplanet.am.domaincomponent property in the AMConfig.properties file sets the value of the DC Tree root suffix. If the value is incorrect, edit it and save the file.
Restart Access Manager
For more information, see the Sun Java System Access Manager 7 2005Q4 Administration Guide
Use the ldapmodify tool to add the inetdomain object class to all DC Tree nodes. (For example: dc=com,o=internet.)
Stop and restart the Administration Server.
You can use the following commands:
/usr/bin/mpsadmserver stop |
/usr/bin/mpsadmserver start |
Verify that the following processes are functioning properly:
The upgraded server is working with the migrated domains
Provisioning can take place successfully
Repeat Migration Steps through Migration Steps for:
Server B2
Domains 3 and 4 in the LDAP directory
Repeat Migration Steps through Step Migration Steps for:
Server B3
Domains 5 and 6 in the LDAP directory
Upgrade Front-end Server 1 (F1) and Front-end Server 2 (F2) from version 5.x to version 6 (if you have not already done so).
For information about upgrading Messaging Server, see Upgrading Messaging Server to Version 6
For information about upgrading Calendar Server, see Upgrading Calendar Server to Version 6
Run the comm_dssetup.pl script. The script asks you to specify the schema version Directory Server will use:
Specify Schema 2, compatibility mode. (You do this because you have already migrated all domains in the directory to Schema 2, compatibility mode.)
Set comm_dssetup.pl -t option as follows: -t 1.5
For information about running comm_dssetup.pl, see Running the Directory Server Setup Script
Upgrade your user-developed applications (in-house provisioning tools or scripts) to use Schema 2, native mode.
You do not have to perform this step (or the remaining steps). The Messaging and Calendar servers can continue to operate with Schema 2, compatibility mode, as long as your user-developed applications rely on the Schema 1 directory structure.
However, we recommend that you convert your applications to use Schema 2 at some time.
When you have converted the user-developed applications, proceed with the following steps:
Back up Domains 1 and 2 in the LDAP directory.
Migrate Domains 1 and 2 from Schema 2, compatibility mode, to Schema 2, native mode.
Use the Schema Migration utility, commdirmig, to perform the migration.
Use the -d Domain option to migrate Domains 1 and 2.
Do not provision Domains 1 and 2 while commdirmig is running. You can provision other domains in the directory.
For information on running commdirmig and on the utility options and syntax, see Chapter 3, Using the Migration Utility
Do not remove the DC Tree for Domains 1 and 2 until all domains in the directory have been migrated to Schema 2, native mode, and all dependencies on the DC Tree are removed.
Configure Access Manager to user Schema 2, native mode:
Start Access Manager Console as a user with administrator rights.
Click the Services Configuration tab.
Select Administration Services -> Global.
Uncheck the box next to Enable Domain Component Tree.
Click Save.
When the Enable Domain Component Tree box is not checked, Access Manager ignores the DC Tree root suffix value held in the com.iplanet.am.domaincomponent property in the AMConfig.properties file.
For more information about these steps, see the Sun Java System Access Manager 7 2005Q4 Administration Guide .
Once you enable Access Manager to use Schema 2, native mode, you can only provision in the domains that have been migrated to Schema 2, native mode. Do not provision new entries in the domains that are still in Schema 2, compatibility mode.
Reconfigure Server B1 to use Schema 2, native mode.
For information about reconfiguring Messaging Server, see Configuring Messaging Server for Schema 2
For information about reconfiguring Calendar Server, see Configuring Calendar Server to Use Schema 2
Stop and restart the Administration Server.
You can use the following commands:
/usr/bin/mpsadmserver stop |
/usr/bin/mpsadmserver start |
Verify that the following processes are functioning properly:
The reconfigured server is working with the migrated domains
Provisioning can take place successfully
Repeat Migration Steps through Migration Steps for:
Server B2
Domains 3 and 4 in the LDAP directory
Repeat Migration Steps through Migration Steps for:
Server B3
Domains 5 and 6 in the LDAP directory
Reconfigure Server F1 and Server F2 to use Schema 2, native mode.
For information about reconfiguring Messaging Server, see Configuring Messaging Server for Schema 2
For information about reconfiguring Calendar Server, see Configuring Calendar Server to Use Schema 2
If you wish, remove the DC Tree (the defunct Schema 1 directory elements).
Do not remove the DC Tree until you have verified that the migration was completed successfully (as described in the preceding “verify” step).
You can use an LDAP command-line tool to remove the DC Tree.
This step is optional. The DC Tree is not used in Schema 2, but it does no harm to leave the deprecated DC Tree in the LDAP directory after Schema 2 is in place.